« Previous 1 2 3
Continuous integration with Docker and GitLab
Assembly Line
Working with Shell Scripts
Basically, each shell script should call precisely the commands that execute the correspondingly named build process. In the pre_cleanup
step, pre_cleanup.sh
is designed to ensure that the Runner does not already have a Docker container with the same name as the container to be built – it would be impossible to launch a new container otherwise on running test.sh
.
Similarly, pre_cleanup.sh
ensures that a Docker image does not exist with the same name and version in the Runner's local image list; otherwise, the build would again fail.
All commands that build the container belong in build.sh
– first of all, Docker build
and possibly additional necessary commands (Figure 3). The most interesting part is certainly test.sh
. Here, you have the possibility to define arbitrary tests in shell syntax so that you can check whether the automatically built container is really working as intended.
For example, if you want the container to launch Nginx on port 80 and port 443, a for
loop in combination with netstat
or ss
could check whether an existing Nginx instance actually opens a TCP/IP socket within 30 seconds of the Docker run
call. The IP addresses of the loopback interface (e.g., 127.127.127.127.127) are ideal for this test. The Docker run
call must of course be filled with appropriate parameters, and the Docker container itself must be able to use these environment variables.
The output behavior of the shell script is also very important: It must return 1
immediately if it encounters an error. If the tests run successfully, it should return
at the end, so that GitLab CI can check off the test as "successful" in its database. Uploading the image to the Docker registry with upload.sh
is now possible. However, you should make sure you not only upload the image, but also set an appropriate tag.
Incidentally, you can track GitLab CI/CD jobs live by opening the web interface, navigating to the respective project and clicking CI/CD . GitLab lists both the Pipelines (Figure 4) and the Jobs (Figure 5). If a test goes wrong, GitLab informs you – by email, as well.
Where's the Beef?
If you've built Docker images before, you might be asking yourself where the Dockerfile got to. After all, it contains all the relevant statements for Docker build
. Clearly, besides the various CI scripts, you still need all the other files that you would need without CI – first and foremost, the Dockerfile.
Conclusions
GitLab CI and its Docker integration prove to be a very practical GitLab add-on. If you use GitLab anyway and want to build Docker containers, you should take a close look at GitLab CI, especially if you do not want to distribute your apps with Docker but are looking for a very lean and efficient method to operate deep infrastructure components.
Infos
- "Security issues when dealing with Docker images" by Nils Magnus, ADMIN , issue 39, 2017, pp. 18-21, http://www.admin-magazine.com/Archive/2017/39/Security-issues-when-dealing-with-Docker-images/
- GitLab docs: https://docs.gitlab.com/ee/README.html
- Container Linux: https://coreos.com/os/docs/latest
- Ignition for Container Linux: https://coreos.com/ignition/docs/latest/
- GitLab Runner for Debian-based systems: https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh
- GitLab Runner for RPM-based systems: https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh
- GitLab CI documentation: https://docs.gitlab.com/ee/ci/yaml/
« Previous 1 2 3
Buy this article as PDF
(incl. VAT)