Commit 4d38694b authored by Varac's avatar Varac

Merge branch '482-increase-interval-between-automatic-updates' into 'master'

Resolve "Increase interval between automatic updates"

Closes #482

See merge request !209
parents 2e84d662 74d3963c
......@@ -32,11 +32,13 @@
# # Delete resources originally created by Flux when their manifests
# # are removed from the git repo.
# --set syncGarbageCollection.enabled=true
# # Set the interval between checks for updates in the git repo to 1 hour.
# --set git.pollInterval=1h
# # Helm release name
# flux
# # Chart name
# flux
shell: helm upgrade --install --repo "" --namespace oas --version 0.16.0 --set git.url="{{ git_url }}" --set git.branch="{{ git_branch }}" --set git.path="{{ git_path }}" --set git.readonly=true --set registry.excludeImage='*' --set sync.state="secret" --set syncGarbageCollection.enabled=true flux flux
shell: helm upgrade --install --repo "" --namespace oas --version 0.16.0 --set git.url="{{ git_url }}" --set git.branch="{{ git_branch }}" --set git.path="{{ git_path }}" --set git.readonly=true --set registry.excludeImage='*' --set sync.state="secret" --set syncGarbageCollection.enabled=true --set git.pollInterval=1h flux flux
- name: Install helm-operator
......@@ -49,9 +51,20 @@
# --namespace oas
# --version 0.3.0
# --set createCRD=true
# # Reconcile actual helm releases with HelmRelease objects with this
# # interval.
# --set chartsSyncInterval=20m
# # Update HelmRelease objects' status with this interval.
# --set statusUpdateInterval=30s
# # Helm release name
# helm-operator
# # Chart name
# helm-operator
shell: helm upgrade --install --repo "" --namespace oas --version 0.3.0 --set createCRD=true --set chartsSyncInterval=20m --set statusUpdateInterval=30s helm-operator helm-operator
shell: helm upgrade --install --repo "" --namespace oas --version 0.3.0 --set createCRD=true helm-operator helm-operator
- name: Install fluxctl via snap
- flux
command: snap install --classic fluxctl
creates: /snap/bin/fluxctl
......@@ -106,3 +106,89 @@ have developed a [local storage
provisioner]( that
automatically provides persistent data on the VPS running OAS to an application
that requests it.
## Automatic updates
OpenAppStack has an auto-update mechanism that performs unattended upgrades to
applications. [Flux]( is the system running in the cluster
that is responsible for these updates.
Technically, flux is split up in two components: `flux` and `helm-operator`.
`flux` watches a git repository (or subdirectory thereof) for [source
that prescribe which application versions should be installed, and stores a copy
of those prescriptions inside the cluster as a Kubernetes manifest (of kind
`helm-operator` watches those in-cluster `HelmRelease` manifests, checks whether
the listed applications are already installed – including correct versions and
other settings – and performs any actions that are necessary to make sure that
the cluster state matches the prescriptions: installing new applications,
upgrading others.
Which git repository is watched by flux, is configurable. For typical
production OpenAppStack deployments, this is set to be
`` – the `HelmRelease` files
are stored in the `flux` directory. The OpenAppStack team considers available
upstream updates (say an update to Nextcloud). If the new Nextcloud version
passes our tests, the team changes the corresponding application description
file in the git repository (in this case `flux/nextcloud.yaml`) to reference the
new version. OpenAppStack deployments that are configured to watch this git
repository will see the change, record it in the in-cluster `HelmRelease`
manifest, and have their `helm-operator` perform the Nextcloud upgrade.
### Local development
When developing OpenAppStack, it's nice to be able to change the application
versions for your development cluster only, without affecting production
clusters. One way to do that is to set the `flux_source.repo` and/or
`flux_source.branch` ansible variables to point to another branch of the
`` repository, or to a different
To make this easier, we included a way to serve up a git repository with
`HelmRelease` manifests from the cluster itself, so you don't need an external
Gitlab or Github project. This feature is disabled by default, and can be
enabled by setting the `local_flux` ansible variable to `true`. If enabled, this
will change several things:
* when you run the OpenAppStack bootstrap ansible playbook from your
workstation, the current contents of the `flux` directory from your
workstation are copied to a directory (`/var/lib/OpenAppStack/local-flux`) on
the OpenAppStack host machine; also, a git commit is created in that directory
on the host machine from these updated contents;
* as part of the OpenAppStack installation, an nginx instance is deployed that
serves up the contents of `/var/lib/OpenAppStack/local-flux` over http;
* `flux` is configured to read the `HelmRelease` files from that git repository,
served by the in-cluster nginx. In particular, the `flux_source` variables are
ignored if `local_flux` is enabled.
The `local-flux` feature is also used by our CI pipeline, in order to be as
similar as possible to a production installation, in particular using `flux` and
`helm-operator` for the installation process, while still being completely
separate from the production applications versions as prescribed by the master
repository at ``.
#### Triggering an update
Both `flux` and `helm-operator` check at regular intervals (currently 1 hour
and 20 minutes, respectively) whether there is an upgrade to perform. If you
don't want to wait for that after making a change, you can trigger an update:
* to let `flux` re-read the `HelmRelease` files from the git repo (be it the
OpenAppStack master one, a `local-flux` one, or yet another one), log in to
the host machine and do
$ fluxctl --k8s-fwd-ns=oas sync
If there are any changes to `HelmRelease` manifests, `helm-operator` is
notified of that through the Kubernetes API and should act on them more or
less instantly (though the actual installation or upgrade could take quite a
while, depending on what needs to be done).
* If, for some reason, the `HelmRelease` manifests are still in sync between git
repository and cluster, but you'd still like to let `helm-operator` check
whether these `HelmRelease`s match what's actually installed, you can force
that by deleting the `helm-operator` pod:
$ kubectl delete pod -n oas -l app=helm-operator
A new `helm-operator` pod should be created automatically, and in our
experience will do a reconciliation run soon.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment