berlingskemedia/docker.php repository overview

⁠Docker image for php7.4

This image can run both php-fpm and php cli for consumers.

By default it will start php-fpm and listen on port 9000.

If you want to run a consumer/worker it can be started linke this:

docker run --restart=always -d berlingskemedia/docker.php php bin/console sqs:multiple-consumer --env=prod -q

Each worker/consumer must run in its own container and the process must stay in foreground (ie. should not deamonize)

⁠Mutable Git tags

⁠Current situation

Since production deploys are handled by Puppet, all docker image names are hardcoded in Puppet repository. If we used only immutable Git tags, this would mean a new image tag with every change. That in turn would cause a necessity of updating puppet code, which in turn would mean involving devops (CO) team into each such release. Having "mutable tags" - simulated by Git branches - removes the need of involving devops team into releases.

⁠Bright future ahead of us

We are convinced that Git tags are actually the way to go, but we cannot get there just yet - first we need to replace Puppet with some other solution. Then we will be able to change the workflow and update this document.

⁠Workflow

Since this repo cannot use immutable Git tags for deployment at this moment, we must use branch names for versioning. Branches used in Dockerhub builds:

• testing
• staging
• production

So, anytime a new code appears in one of these branches, a webhook triggers a new build in Dockerhub⁠. Then a new docker image appears there, tagged according to branch name:

• berlingskemedia/docker.php:testing - used in bm.env.symfony⁠ repo for building dev and QA environments
• berlingskemedia/docker.php:staging - used in puppet⁠ repo for building staging environments
• berlingskemedia/docker.php:production - used in puppet⁠ repo for building production environments Note: these tags are mutable, i.e. previous version is overridden with the new one.

When filing a new Pull Request, please specify master as parent branch. When the PR is merged to master, delete existing testing branch and create a new one with the same name, in order to trigger a build of berlingskemedia/docker.php:testing on Dockerhub. Then, after the new image is tested in QA environment deploy it to staging and then production:

• Create a Git tag from master branch, name it release-${YYYYmmddHHii} (this represents date and time) and push it to origin, e.g. git tag release-202109251330, then git push origin release-202109251330.

This will trigger a build on Dockerhub, which will make this build available in case we need to rollback to this one in future.

• Delete existing staging and production branches and create new ones from master with the same names as before, in order to trigger builds of staging and production image tags on Dockerhub.
• ssh to running staging instances, run docker pull berlingskemedia/docker.php:staging and then sudo reboot.
• Verify if it all works; if it does then repeat the steps on production, obviously using :production tag.

⁠Rollback scenario

In case the new image causes problems on production, rollback the following way:

• Get the previous version of the image, tagged with release-${YYYYmmddHHii}, e.g. release-202109011045
• Tag that previous version with :production tag, e.g. docker tag berlingskemedia/docker.php:release-202109011045 berlingskemedia/docker.php:production
• Login to Dockerhub: docker login, pass your credentials
• Push the new production tag to Dockerhub: docker push berlingskemedia/docker.php:production
• Follow deployment instructions the same way as if it was a brand new image. In case of trouble on staging, proceed the ame way, obviously using :staging tag instead of :production

⁠Why delete and recreate branches instead of merging master with them?

To keep the same commit hash, which is used when building docker image. Having the same hash will speed up the process.

⁠Risk of faulty deploy

Note: at the time, when QA has a new version, which is not yet on staging and production, there is a risk of a faulty deploy. This is because application packages are built on QA server. A package build using one image, which is then run on some other PHP image (which is not identical to the original one), can cause unexpected side effects. Therefore, testing new image on QA should either cause a code freeze, or happen during one (or on Friday ;)).