2022-03-31 14:45:11 +00:00
|
|
|
# Example repository for customizing a Stackspin cluster
|
2022-03-30 17:04:47 +00:00
|
|
|
|
2022-03-31 14:45:11 +00:00
|
|
|
Example boilerplate for a custom [flux](https://fluxcd.io/) repository
|
|
|
|
|
which can be added to a [Stackspin](https://stackspin.net) cluster.
|
|
|
|
|
The main use-case is to add additional applications
|
|
|
|
|
which are not integrated into Stackspin (yet).
|
2022-03-30 17:04:47 +00:00
|
|
|
|
2022-03-31 14:45:11 +00:00
|
|
|
For a more advanced example
|
|
|
|
|
see the [flux2-kustomize-helm-example](https://github.com/fluxcd/flux2-kustomize-helm-example)
|
|
|
|
|
repository.
|
2022-03-30 17:28:59 +00:00
|
|
|
This repo's directory structure is similar to the `flux2-kustomize-helm-example`
|
|
|
|
|
one.
|
2022-03-30 20:11:12 +00:00
|
|
|
|
|
|
|
|
## Basic configuration
|
|
|
|
|
|
|
|
|
|
We'll start with a very basic configuration:
|
|
|
|
|
|
|
|
|
|
* It uses a public git repo
|
|
|
|
|
* No secrets are included
|
|
|
|
|
* No forking/modifications needed, install as it is
|
|
|
|
|
|
|
|
|
|
Apply it to your cluster:
|
|
|
|
|
|
|
|
|
|
```sh
|
|
|
|
|
basic/install.sh
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
List the resource created by this flux repo:
|
|
|
|
|
|
|
|
|
|
```sh
|
2022-04-13 06:46:20 +00:00
|
|
|
kubectl -n stackspout get gitrepositories
|
|
|
|
|
kubectl -n stackspout get kustomizations
|
|
|
|
|
kubectl -n stackspout get helmreleases
|
|
|
|
|
kubectl -n stackspout get pods
|
2022-03-30 20:11:12 +00:00
|
|
|
```
|
|
|
|
|
|
2022-03-31 14:45:11 +00:00
|
|
|
Show output of the single app applied, [podinfo](https://github.com/stefanprodan/podinfo)
|
2022-03-30 20:11:12 +00:00
|
|
|
|
|
|
|
|
```sh
|
|
|
|
|
curl --resolve podinfo.local:80:CLUSTER_IPV4_ADDRESS http://podinfo.local
|
|
|
|
|
```
|
2022-03-30 20:32:31 +00:00
|
|
|
|
|
|
|
|
## What's next ?
|
|
|
|
|
|
2022-03-31 15:15:08 +00:00
|
|
|
There are two ways of using a custom flux repo to host your custom config/apps
|
|
|
|
|
on a Stackspin cluster.
|
2022-03-31 14:45:11 +00:00
|
|
|
|
2022-03-31 15:15:08 +00:00
|
|
|
### A) Manage secrets manually
|
|
|
|
|
|
|
|
|
|
This approach is easier to start with,
|
|
|
|
|
because you don't need to configure your cluster to handle encrypted secrets
|
|
|
|
|
and access to a private git repository.
|
|
|
|
|
|
|
|
|
|
* Fork this repository into a public git repo, cloneable via `https://`
|
|
|
|
|
|
|
|
|
|
### Everything in version control, including secrets
|
|
|
|
|
|
|
|
|
|
* Fork this repository into a private git repo, cloneable via `ssh://`
|
|
|
|
|
* [Configure flux to use ssh instead of https for cloning](https://fluxcd.io/docs/components/source/gitrepositories/#ssh-authentication)
|
|
|
|
|
* You shouln't rely solely on transport encryption for your git repository
|
|
|
|
|
but rather end-to-end encrypt your secrets.
|
|
|
|
|
Different methods are available for flux:
|
|
|
|
|
* [Sops](https://fluxcd.io/docs/guides/mozilla-sops/)
|
|
|
|
|
[Sops section in flux2-kustomize-helm-example](https://github.com/fluxcd/flux2-kustomize-helm-example#encrypt-kubernetes-secrets)
|
|
|
|
|
* [Sealed Secrets](https://fluxcd.io/docs/guides/sealed-secrets/)
|
