As part of our move to kubernetes, we need to be able, at least for the transition period, to deploy mediawiki to kubernetes at the same time we deploy it to the main cluster. This means that scap sync (and its various variations) should deploy also to kubernetes for the time being.
Deployment workflow
1 - code is prepared in /srv/mediawiki-staging by a scap command, that also builds the corresponding docker images, and publishes them to the docker registry. This procedure also commits a series of yaml files to the git repository at /etc/helmfile-defaults/mediawiki/release. Sync-masters in scap should probably also sync this repository. These yaml files will all have the following format:
main_app: image: 'restricted/mediawiki-multiversion:<tag>' mw: httpd: image_tag: 'restricted/mediawiki-webserver:<tag>'
The various files might include different flavors of the mediawiki-multiversion image, based on configuration (see below). The file names will be in the form <namespace>-<release>.yaml, see below on how they can be extracted.
2 - Instead of suggesting to scap pull on one debug server, we should have a "scap sync-debug" stage that does deploy just to the debug servers and the debug namespaces on kubernetes (again coming from configuration).
3 - scap sync* would work like now, with the difference that:
- while deploying to the canaries, we should also deploy to the combination of clusters, namespaces indicated in a configuration key (see below) to the release canary.
- canary checks will need to use a better logstash query than the one used today. I think introducing a more fine-grained set of servergroups variables will help here.
- When deploying to all appservers, we would need to deploy to to the same cluster/namespaces, but to release main
4 - A rollback can be achieved by reverting the last change in the repository described above, or using the traditional process described above.
Configuration
We will need a series of configuration keys:
- k8s_releases_dir - the directory where the releases repository is located.
- k8s_clusters - the list of clusters to deploy to.
- k8s_deployments_file - a file path for a yaml file containing the data structure described below.
This file will contain a list of dictionaries dictionary built as follows:
--- - namespace: mwdebug release: pinkunicorn canary: mw_flavour: debug web_flavour: production debug: true - namespace: parsoid release: parsoid canary: parsoid-canary mw_flavour: production web_flavour: production ...
where:
- namespace is the k8s namespace
- release is the helmfile release name
- mw_flavour to indicate if we want the "main" image (-publish, hopefully changing to production soon) or the "debug" image (-debug), or any other flavour we might be building in the release file for this namespace.
- web_flavour same thing, but for the webserver image.
- debug (boolean) if this is a debug namespace or not
- canary (optional) is the name of the canary helmfile release
as for "how to release to k8s", the best way to achieve it is probably running helmfile -e <cluster> -l <release> sync using /srv/deployment-charts/helmfile.d/services/<namespace> as the current working directory. Some relevant code can be found in the current autodeployment script