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:
Besides being big fans of Mark Shust's Docker Configuration for Magento project as I already blogged about, we also love Traefik, the Cloud Native Edge Router. I discovered Traefik years ago and try to use it wherever we can. Depending on the project's goals we either use the open-source version or the enterprise edition. Disclaimer: I am Traefik Ambassador, so I might be a bit biased :)
We are big fans of Mark Shust's Docker Configuration for Magento project. We use a lot of our projects, the ones we start from scratch as well for ones that we have taken over and have some weird setup in place that we simply cannot get to work.
For quite a while I wanted to upgrade the Docker setup for the open-source Force Login module we develop for Magento 2. We were using a very old version of Mark Shust's Docker Configuration for Magento setup. Since there were a lot of changes how things work nowadays, the upgrade was not simple and came with a few side-effects. The latest version of the setup requires Magento to be checkout out locally and to be mounted in the container. If you develop a Magento application that totally makes sense, but for our module, it felt it makes more sense to have the Magento application code in the container as it used to be in the old setup. This led to a bunch of changes that I'll cover below.
When setting up Rancher via its Docker container, you are not able to configure SSL termination out-of-the-box. Instead, the Rancher documentation gives some advice on how to set up SSL termination via nginx or Apache. But why would you install such a service on the host when Rancher is running in a container? Ideally the SSL proxy would also run in a container. Searching on Docker Hub for a solution, I found the dictcp/rancher-ssl image that provides exactly that. The set up is trivial.
We are running Rancher in combination with the in-built load balancer HAProxy. For each of our customers, our application is provided as a single container, many on the same physical server instance. Each of the customers' applications can be accessed via different URLs, so the usage of the HAProxy as the routing component part of the load balancer makes sense.
Linking Docker containers can be done in various ways. In my recent attempt of playing with Docker and our GitLab Review Apps setup, I experimented with different methods to figure out what would work best. These are the different options I played around with:
I wasn't really happy with the current approaches of dealing with different Dockerfiles and docker-compose.yaml files for development and production containers. I don't really see the point of managing multiple configuration files, building a few intermediate containers when the only difference between a development image and a production image is that the code is copied into the image during build. Adding files on every build is also not an ideal solution as you could potentially ship an old version of the application when you miss running a docker build after you made your final changes.