GitLab system composes with GitLab Server and GitLab Runner.
GitLab Server is the source and image repo single site (or other architecture depending).
GitLab Runner is the supporting tool to execute the CI / CD jobs and is able to be installed in lots different systems / environments.
Tips for DevOps with GitLab system:
1. For GitLab server,
If self-managed tier, install with Domain Name and certificate with HTTPS to provide GitLab container registry and well connections to GitLab Runners.
2. For GitLab runner,
An GitLab server can connect to many other GitLab runners with different application situations.
I had tried 3 types of GitLab runner:
- "shell" executor:
This type is the very conventional type to work in an environment with all supporting from bare machine. You have to prepare all necessaries (including git, compiler, builder, ... etc) and apply shell commands to build your application.
- "docker" executor:
This type is the basic docker environment to let your application build / run / deploy in a clean container environment. You are unable to use docker related commands such as: docker info, docker build, docker run to execute a docker. You are only able to use the built container environment as a clean starting point and close at the end.
- "docker" executor with socket binding:
This type is the advanced docker environment which lets you to proceed any docker related commands. It is recommended to apply this type if you want to build an image cleanly and execute during your CI / CD pipeline. This is the preferred method to build and run your applications with docker build and docker run commands.
Note:
a. "docker" executor with dind (docker in docker):
This is another type to execute docker commands in a docker environment. It is very straight forward thinking to execute a docker inside a docker environment. But there are some flaws to use this type from a docker developer view: https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/
This type is like the parent-child relationship. You have one docker running and inside it, you start another docker. So the second docker is the child and the first one is the parent. This could go into nested problem. This type likes the "scale up" case.
b. "docker" executor with socket binding:
This is the recommended way to run docker commands from a docker environment. Though it seems still has some problems?
This type is like the sibling relationship. You have one docker running. Then you ask this docker to help you to create another running docker parallel. So you will see lots docker containers concurrently from the monitor. It likes the "scale out" case.
The debate could be continued.
