Docker-compose bundle

To host and configure all microservices, we are using Kubernetes in production and docker-compose in development. Docker-compose enables easier configuration and maintenance for local development and e2e testing. The docker-compose bundle is generated in the jore4-flux repository and the built bundle is hosted in the jore4-tools repository.

Below, you can see the flows of how the docker-compose bundle is created and how it is used.

(Auto-)update docker bundle

The docker bundle is generated based on the common.yaml and e2e.yaml value files using gomplate.

• To update some environment variables or docker image versions, just do the changes accordingly in these value files.
• Call the ./development.sh generate script to generate the docker-compose.yml and external secret files.
• Commit the changes to the jore4-flux repository, the CI automation will create a tar.gz file and store it at the jore4-tools repository as a release.

Note: there's a github workflow in the jore4-flux repository that checks for docker image changes in Docker Hub once an hour. If there are any new image versions, it will automatically update the common.yaml values file, generate a new bundle and create a pull request with these changes.

Docker bundle in e2e tests

When a microservice (e.g. jore4-ui) has changes and a pull request is created, the following github workflow is executed:

• A new version of the jore4-ui docker image gets built and pushed to Docker Hub.
• The workflow downloads the latest stable version of the docker bundle from the jore4-tools repository.
• The docker bundle gets patched and the newly created version of the jore4-ui image is used in place of the version set in the docker bundle.
• We run the e2e tests in this patched setup, thus verify that the new jore4-ui version is compatible with the rest of the microservices.

Docker bundle in local development

The docker bundle is also a good solution if you wish to reuse the existing docker images for dependencies when you are developing your own microservice. See the jore4-tools repository on how to download the bundle and pin microservice versions on demand.

Autoupdate HTTPS certificate

We are using an App Service Certificate to provide us with SSL certificate for the HTTPS communication. This is a "star" certificate, works for the *.jore.hsl.fi domain. App Service Certificates are renewed by Azure automatically, the latest version is always stored in the associated key-vault (hsl-jore4-common / star-jore-hsl-fi-certificate)

Preliminary configurations:

• The play-configure-certificate playbook in jore4-deploy creates a Certificate (hsl-jore4-prod-cert) entity within the hsl-jore4-prod-appgw and associates it with the star-jore-hsl-fi-certificate secret in the key-vault.
• The hsl-jore4-prod Kubernetes ingress uses AGIC to automatically configure the Application Gateway whenever the ingress rules change. For this scenario, it tells the hsl-jore4-prod-appgw Application Gateway that the hsl-jore4-prod-cert should be used for the HTTPS listeners.

The certificate auto-update process goes as follows:

1. The App Service Certificate (star-jore-hsl-fi-certificate) gets automatically updated by Azure
2. Its value gets automatically pushed to the key-vault secret (star-jore-hsl-fi-certificate), as a new value
3. The preconfigured Application Gateway (hsl-jore4-prod-appgw) keeps polling the key-vault every 4 hours to see if there's a new value in the secret. When there's a new one, it's value is updated to the AppGW Certficiate hsl-jore4-prod-cert.
4. The value of the hsl-jore4-prod-cert gets updated in the HTTPS listeners.