2020-04-03: Learning Gitlab in Container
How to become familiar with setting up Gitlab locally within a Container, and my experience as I progress.
Source
https://github.com/geircode/learning_gitlab
Start Gitlab
Do this to start Gitlab in containers:
git clone https://github.com/geircode/learning_gitlab
cd learning_gitlab
cd run-gitlab-server
docker-compose -f docker-compose.yml up -dGo to http://localhost:8080
Create new password for “root” user
After trying to login in with “root” user and I got this 404 error:
But when trying a clean URL: http://localhost:8080/, it worked!
Whohoo! My very own local Gitlab:)
Create a project
1. Create a new project called “awesome-sauce” and add a readme file
2. Clone your own repo!
git clone http://localhost:8080/root/awesome-sauce.gitAwesome!
Add Gitlab CI to build the repository
Following the guide at https://docs.gitlab.com/ee/ci/quick_start/README.html
1. Creating a simple .gitlab-ci.yml file
image: "alpine"
before_script:
- echo before_script
task_1:
script:
- echo task_1
task_2:
script:
- echo task_22. git commit the changes
3. Authenticate to own repository to git commit. Fun fun.
But did the CI Pipeline run? => http://localhost:8080/root/awesome-sauce/pipelines
Add a Git Runner to Gitlab CI to build the repository
The “docker-compose” file that specify the containers running looks like this:
And running docker ps shows that there is a Gitlab runner running in a container already.
Inspired by this post => https://gitlab.com/gitlab-org/gitlab-foss/issues/50851
1. Get the registration token. Go to http://localhost:8080/root/awesome-sauce/-/settings/ci_cd
2. Register a Gitlab runner into Gitlab
Since this is a linux shell script, run this either from WSL or from inside a workplace Container with Docker CLI installed.
2 Run the script from within a worksplace container
2.1 Go to the root folder of the repository and run the “docker-compose.build.up.bat“ script to start the “learning_gitlab“ container
Open a CMD in Windows:
2.2 Open a terminal to the container
PS: You need to change the “registration_token“ in the script before running.
Understanding gitlab-runner register
What are these options, where do they come from and where are they documented?
They are part of the Gitlab Runner Configuration, and documented in https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnersdocker-section.
So instead of manipulating the config.toml file, these options can be given as command line parameteres to the function “gitlab-runner register“.
Find docs for “docker-network-mode“
1. Search for “network_mode“ in the docs. PS. See the UNDERSCORE, because all config in the docs are specified with underscore, but the command line parameteres must be with dash.
Since this option belongs to the “docker” section, the parameter then becomes prefixed with ‘docker’ with underscore: “docker_network_mode“.
This particular option causes all the gitlab runner helper containers which are the ones that ones that do all the work, to be part of the same docker network as the gitlab server and is then able to pull git repositories.
But where is the complete list of parameteres the “gitlab-runner register” command line?
It’s not possible to find this in gitlab.com, but run “gitlab-runner register --help” to see what options that are available:
The docs however “hides” inside the source code => https://gitlab.com/gitlab-org/gitlab-runner/-/blob/master/common/config.go#L52
The options that are available for “gitlab-runner register“ function is the 'env' variable in the DockerConfig:
Go ahead with the example “network-mode“, this will be:
Just transform this to UNDERSCORE and this will be the command line option.
This also means that it is possible to add the env variable to the shell before running the gitlab-runner register” command as a alternative way to add parameteres to the function.
Persisting the new repository in Gitlab.com
The “awesome-sauce” repo is also stored in Gitlab.com and that means that is also runs the pipeline here. That way we can check if the pipeline is actually working.
https://gitlab.com/geircode/awesome-sauce
1. Check if the pipeline is working as intended: https://gitlab.com/geircode/awesome-sauce/pipelines
Monolithic Gitlab Container
The container running is not built according to Container Best Practice which is to adheer to the single responsibility pattern and that is to do one thing, and do this one thing properly. The Gitlab container is running these at least these services:
GitLab/Gitaly
GitLab/GitLab Exporter
GitLab/GitLab Grafana
GitLab/GitLab Shell
GitLab/Migrations
GitLab/Sidekiq
GitLab/Unicorn
In a Container world, all these services would run in seperate containers.
To remedy this, Gitlab has specified this official Helm chart for running Gitlab in Kubernetes => https://docs.gitlab.com/charts/
Looking into the Container to see how much it is actually running:
Wow! Usually there are only 3-5 live processes inside a container. This is not good and not best practice.
Why stuff everything inside a single Container?
Why not run seperate services in docker-compose classic or Docker Swarm? Oh well.
Gitlab docs for running in Containers
https://docs.gitlab.com/ce/install/docker.html
https://docs.gitlab.com/omnibus/docker/#install-gitlab-using-docker-compose
How to use docker-compse to install Gitlab
Gitlab docs sources
Project | Path |
|---|---|
| |
| |
| |
|