docker

Developing on Windows was challenging before Microsoft introduced WSL 2. Running Linux Virtual Machines with SMB/CIFS shares mounted into Windows was the best solution I could come up before there were tools like Vagrant. But all these solutions have one common problem. They mounted a Windows volume in Linux or visa versa which resulted in (very) poor I/O performance. Fortunately, WSL 2 resolves all these issues by running Docker and IDE’s like Jetbrains IntelliJ, PyCharm and PHPStorm in WSL 2.

I try to automate almost everything. I use Docker to containerize in-house developed software and run these containers on CentOS 7 machines. When you’re using a modern CentOS 7 version, the XFS filesystems are configured correctly with d_type support activated. But when you want to run Docker containers on an older version of CentOS 7, d_type support could be disabled causing a lot of trouble when you’re chowning and chmoding files in a container: files are not found or skipped, etc.

My continuous integration and continuous delivery pipeline use Docker containers and a private Docker registry to distribute and deploy my applications automatically. Unfortunately, the Docker command-line tool can’t really control the Docker registry, actually, it is only capable of pushing and pulling image (tags). This is a bit frustrating because, when you’re using your continuous integration pipeline to build containers, push them to the registry, and pull them again to run the QA, the registry will eat up all your disk space due the images are never removed. To clean up your ‘mess’, you have to remove the images manually, but it’s way cooler (and simpler) to use the Docker registry API for this job.

Number one challenge when you are using Docker in production environments is storage. On you local development machine it is possible to mount a local directory path into your docker container, but in production environments, this isn’t an option because you don’t know if the path exists and if the docker container is always running on the same node. A solution is NFS, and when using Rancher, Rancher-NFS.

Do you want to use Docker containers in production on a CentOS 7 machine, but you think it is hard? Then have a look at Rancher! Rancher is a container management platform to deploy docker containers in a production environment very easily.

As a developer, I used GitHub a lot to store my (private) projects. This works great, but I do miss the CI integration as done by GitLab. I could use public services like Travis, but they do charge for private projects.

Because we’re using GitLab and GitLab CI at work I wondered how much work it would be to setup my private GitLab server on my Rancher environment. In this blog post, I will share the results with you.