Sometimes one may face the need to restart a Docker container because it does not react anymore. While there are dozens of possible ways to accomplish this, I want to show the one we recently started to incorporate into our setups.
Sometimes, mostly for smaller customers, we deploy staging and production environments on the same machine. Not an ideal setup, but doable. Thanks to Docker the different instances can live in isolation, except of course when one instance takes the server down, the other instance is also affected.
Back in 2020 I published our customized Magento development setup with Mark Shust's Docker Configuration for Magento and Traefik version 1. Since Traefik version 2 is now out for a while, I decided to upgrade our setup. This blogpost covers the different steps I took.
Not being happy with our current Docker build process in one of our projects, I was researching how to optimize the process.
Recently, I wanted to improve our CI build pipelines with some custom-built Docker images for our PHP projects. To make sure I can reuse the image in as many of our projects as possible, I wanted to compile and install as many PHP extensions as possible.
Whilst preparing and testing our Docusarus instance, I realized that the RSS feed URL used by our old blog system did not work anymore because Docusaurus generates the content in a different way.
Simply put, error 1062 is caused when MySQL finds a DUPLICATE of a row you are trying to insert. I sometimes hit this error when importing database dumps of applications that have been in production for a long time. The “fix” is easy: Find the duplicate data and delete it. Depending on your database structure it might not be that easy though. I that case, I configure MySQL to ignore those errors, for local development I find that approach acceptable. For dockerized setups, you can pass a “sql_mode” flag to the container which then will be interpreted by the MySQL server during startup. The docker-compose configuration that works for me looks like this:
Testing GitLab CI build pipelines can be a bit annoying. You must make your changes, commit and push them to kick off the CI pipeline. Then you have to wait a while for the result to show up and start over again if something went wrong. If your CI runners are busy, you keep waiting and waiting for the next free slot. Luckily, it is possible to run GitLab CI jobs completely locally. After installing the gitlab-runner package locally, you can execute a job like this: