CI/CD pipeline

Intro

@rbrem @pstauffer If Kubernetes is too much for confirm/blueprints/cloner#5 (closed), I suggest we use this Traefik proxy.

I prepared some things. Have a look at the following:

• The official Traefik docs
• Our config
• Our pipeline
• Our Dockerfile & Compose File

What's working

That's working right now:

• The Dockerfile
• The Compose File
• The static Traefik config
• The dynamic routing config for the API & dashboard
• The PROXY_HOST environment variable to have the API & dashboard only on a single host
• Redirect from http to https

What's to improve

The following things need to be improved:

CI Runner

• There's a CI file
• There are currently no runners
• I did this on purpose, since we need a runner on the new machine (confirm/blueprints/cloner#5 (closed)), which is not ready yet

I suggest we do this:

• Install a runner
• Register it with the dev tag (allow only jobs with the dev tag then)
• Make it available to the whole confirm group by default
• Update the CI file and add the dev tag to the deploy job

Multiple instances

• The CI file is currently only deploying one single proxy
• We can probably deploy multiple proxies, for example one for freaks as well

Since the repo & config is quite "dynamic", we only have to make a few changes to the CI file:

• Create a .deploy job template
• Create a new deploy job for each instance, extending the .deploy job template
• Remove the PROXY_HOST variable from the global scope
• Add a PROXY_HOST to each job (e.g. proxy.confirm.ch & proxy.freaks.io)

SSL

• There are currently only self-signed SSL certificates installed
• I suggest we use Let's Encrypt, since it's integrated into Traefik
• Here are the official docs
• Remember, LE has a rate limits
• We can probably avoid that by using wildcard SAN's

DNS / Hostnames

We don't have a proper DNS naming scheme yet, except for *.dev.confirm.ch. Since we're doing now more and more deployments and since we've Let's Encrypt, I suggest the following naming schemes:

• *.review.confirm.ch: Review environments (i.e. feature branches)
• *.testing.confirm.ch: Main testing environment (i.e. master branch)
• *.release.confirm.ch: Release environment (i.e. release-* branches)
• *.confirm.ch: Production environment (i.e. tags)

For example, if we've a project called "Foo Bar" it would work like this:

• Pushing a feature branch results in deployments to {some-weird-sha-string}.review.confirm.ch
• Pushing / merging to the master branch results in deployments to foobar.testing.confirm.ch
• Pushing a release branch results in deployments to foobar.release.confirm.ch
• Pushing a tag results in deployments to foobar.confirm.ch

There might be some projects without tags (e.g. this proxy), then master would directly be deployed on the production environment:

• Pushing a feature branch results in deployments to {some-weird-sha-string}.review.confirm.ch
• Pushing / merging to the master branch results in deployments to foobar.confirm.ch

Alternatively to this naming scheme, we can also move the "environment" / scope to the front of the domain, and the project to the middle:

• {some-weird-sha-string}.{foobar}.confirm.ch: Review environments (i.e. feature branches)
• testing.{foobar}.confirm.ch: Main testing environment (i.e. master branch)
• release.{foobar}.confirm.ch: Release environment (i.e. release-* branches)
• {foobar}.confirm.ch: Production environment (i.e. tags)

However, this means we've to create new DNS entries for each project (*.foobar.confirm.ch). My last knowledge about BIND was, you can create subdomains (e.g. *.foobar.confirm.ch IN CNAME dev.confirm.ch), but you can't do sub-subdomains or alike (e.g. *.*.confirm.ch IN CNAME dev.confirm.ch). This naming scheme also means we've to request a new SSL certificate for each project, which means applying more labels to the project's Docker image/container.