Here's an example. To set up Flux you run these couple commands:
helm repo add fluxcd https://charts.fluxcd.io
kubectl apply -f https://raw.githubusercontent.com/fluxcd/helm-operator/master/deploy/crds.yaml
kubectl create namespace flux
helm upgrade -i flux fluxcd/flux \
--set [email protected]:user/some-repo \
--namespace flux
that sets up Flux. Flux is now watching the repo you told it there in the last command.
If you don't use a predefined key, you just grab the SSH key Flux created and add it to your repo.
Then to deploy something like NextCloud, you need these two files. The first creates a namespace for nextcloud. Not a requirement, but makes sense. The second is a HelmRelease file that the Flux Helm Operator uses to read the Helm chart for NextCloud.
apiVersion: v1
kind: Namespace
metadata:
name: nextcloud
apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
name: nextcloud
namespace: nextcloud
annotations:
fluxcd.io/automated: "true"
filter.fluxcd.io/chart-image: "glob:*"
spec:
releaseName: nextcloud
chart:
repository: https://nextcloud.github.io/helm/
name: nextcloud
values:
replicaCount: 2
any other values here to override in the chart
that's it. You now have a fully automated system that will automatically deploy the new updates to your NextCloud pods. You can disable the auto updates by removing the annotations and then manually update the container versions by adding the version in the HelmRelease. Once it's approved, then Flux will update the containers.
You also have have a deployment that created a replicaset of your pod because you defined 2 for your replicacount. So any traffic entering your cluster will be split between both replicas (or more if you define more). By default, k8s does a rolling update. So pods aren't all killed at once. The first pod will be terminated and a new one spun up with the updates. When it's live, the second will be terminated and recreated with the updates. So your service stays live during updates.
It's that easy. It shouldn't take you more than 10 minutes to set Flux up. And then the rest is the specific things you need the apps to do. Like with NextCloud the type of database, if you want ingress or not, those kinds of options.
Containers and container orchestrators help literally every business from small to giant enterprises developing hundreds to thousands of internal microservices.
I don't even have some things installed on my system anymore. I'll just run a container to use a specific tool and kill the container when I'm done. You can even have full dev environments packaged up in a contianer and have VSCode deploy itself in the container so you have a consistent development environment across different users. And that happens literally with the push of a button in VSCode.
