✨(playbook) introduce static services

[madmatah]

Purpose

As explained in #417 , the current blue/green deployment mechanism adds a suffix (deployment stamp) to the name of the services exposed by applications.

This has raised several issues because it is not possible to use service names in the settings of another app because the name will change as soon as the service is redeployed.

Proposal

Services with suffixes are helpful because they allow components of a deployed application to communicate with each other while also ensuring that the application stack is consistent within the same version.

I propose to keep them, otherwise each component of an application must be aware of their current state (green or blue) to communicate with other components. And it's hard to do that without any reconfiguration during a switch between blue/green version. We don't want that.

In addition to the current mechanism, I propose to introduce "static services".
Each static service is declined in 3 versions (service-previous, service-current and service-next) that points to the right version of a deployment.

It can be used by another application because its name doesn't change.

The switch (or any deployment related task) is now patching static services instead of routes.
Routes are now pointing to the corresponding service (e.g., route A-previous points to service A-previous).

A static service can of course exist without any route.

There is a new playbook init_services.yml that initialize static services.
Static services are defined in files matching static-svc*.yml

TODO

• POC with richie
• Improve switch and rollback playbooks to avoid downtime (addressed in 🐛(playbook) avoid downtime during switch or rollback #434)
• Inventory of the nice-to-have static services per application

Per application :

• Update route templates
• Add static service for each route
• Add other static service if needed and patch applications using them.

[madmatah]

FYI I've not removed the forum route.

I propose to do that later to ease the migration process.

[jmaupetit]

I would have preferred substituting existing SVCs by static ones without introducing a new semantic / object. Do you think we must keep B/G SVCs?

[madmatah]

I'm afraid you need to copy the explanations in your PR description to a documentation somewhere in the project!

@sampaccoud
I added basic documentation about supported kubernetes/openshift entities in docs/developer_guide/concepts.md.

I described static services and their purpose inside.

[madmatah]

I just added an Upgrade.md file to document the upgrade process.

[madmatah]

@lunika I patched deploy_patch_cronjob.yml because I had an error while testing the upgrade process after merging the cronjob feature.
Can you please review this part ?

[madmatah]

I changed the base branch of this PR to target migration-to-k8s, the branch that we'll use to work on our Openshift to Kubernetes migration.

Maybe I should remove the Upgrade.md file because it's not relevant anymore.

[madmatah]

@sampaccoud Thanks for your feedback, I just pushed all your suggestions!

[sampaccoud]

Looks GTM. Just to make sure, mailcatcher and flower are not handled in this PR although they have routes. I suppose they have no B/G.

[madmatah]

Looks GTM. Just to make sure, mailcatcher and flower are not handled in this PR although they have routes. I suppose they have no B/G.

@sampaccoud 🎉 🙏

About mailcatcher and flower app, your assumptions are correct, you can see in their vars/settings.yml the following :

is_blue_green_compatible: false