OVERVIEW OF THE TASK
Set up a Docker-based GitLab CE instance and GitLab Runner using Docker Compose to create a local CI/CD environment. The task involves defining services in a docker-compose.yml file, configuring persistent storage, exposing GitLab on a local port, and registering the GitLab Runner to execute CI/CD pipelines. Finally, verify the setup by running a test pipeline with a sample project.

PREREQUISITES
Ensure Docker and Docker Compose (version 3.8 or higher) are installed and running on your system. Use “docker –version” to verify Docker installation and “docker-compose –version” to check the Docker Compose version. Your system should have at least 4GB of RAM (8GB recommended) and 10GB of free disk space for GitLab data and logs.

Step 1
Open your VS Code or any IDE of your choice and create a docker-compose.yml file. Add the following configuration:

General overview

version: '3.8'
Specifies the version of the Docker Compose file format being used. Version 3.8 is compatible with modern Docker Compose features.
services:
Defines the list of services to be run. In this case, it includes gitlab-server and gitlab-runner.

gitlab-server Service
image: 'gitlab/gitlab-ce
'
Specifies the Docker image to use for the GitLab Community Edition (CE) server. The latest tag ensures the most recent version is pulled.
container_name: gitlab-server
Assigns a human-readable name (gitlab-server) to the container for easier management.
environment:
Configures environment variables for the GitLab container:
GITLAB_OMNIBUS_CONFIG: Contains GitLab's configuration settings.
external_url ‘http://localhost8088’: Sets the URL for accessing the GitLab instance.
nginx['listen_port'] = 8088: Configures the port Nginx listens on inside the container.
gitlab_rails['initial_root_password']: Sets the initial root password for the GitLab admin user.
puma['worker_processes'] = 0: Disables Puma's cluster mode to reduce memory usage.
volumes:
Maps directories on the host machine to the container for persistent storage:
./gitlab/config:/etc/gitlab: Stores GitLab's configuration files.
./gitlab/logs:/var/log/gitlab: Stores log files.
./gitlab/data:/var/opt/gitlab: Stores application data (e.g., repositories and database).
ports:
Maps port 8088 on the host to port 8088 in the container for external access.

gitlab-runner Service
image: gitlab/gitlab-runner

Specifies the Docker image for GitLab Runner using a lightweight Alpine-based image.
container_name: gitlab-runner
Assigns a human-readable name (gitlab-runner) to the container.
volumes:
Maps the Docker socket from the host to the container:
/var/run/docker.sock:/var/run/docker.sock: Allows the runner to interact with the Docker daemon on the host for building and running containers.

When you install Docker, two key parts are set up:
Docker Client: This is the part you interact with. It’s like a remote control that lets you give instructions to Docker.
Docker Server (or Daemon): This is the "engine" that does all the heavy lifting. It listens for instructions from the client, like "create a container" or "start a container," and carries them out.
How They Talk:
The Docker client and server communicate with each other through a "socket," which is like a special phone line between them.
This socket can either be:
Over the network: If the client and server are on different computers, they send messages over the internet or a local network.
Through a file: If both the client and server are on the same machine, they use a special file as their communication channel.
The Special File:
When Docker is running on your computer, it creates a file called /var/run/docker.sock.
This file acts like a hotline for the client and server to talk to each other.
Because they use a file for communication, Docker can also allow its tools (like the client) to run inside a container. This is why you can manage Docker from within another Docker container.
Why It Matters:
This setup makes Docker very flexible. By sharing the docker.sock file, you can:
Use Docker from inside other containers.
Manage containers on the host machine as if you were directly using Docker on it.

Step 2
Run the command docker-compose up to start the containers. Once the containers are up, you can access the GitLab UI at http://localhost:8088 in your web browser. It may take 5–6 minutes for the interface to fully load, and you might encounter a 502 error during this time, depending on your network speed. After the UI is loaded, you will be prompted to sign in. Use the username root and the password specified in your docker-compose.yml configuration.

Login and create a project
Step 3
Configuring a runner: To configure a runner, navigate to Admin > CI/CD > Runners to obtain the registration token.
Click on ‘New instance runner’ to generate a token. And configure the runner using this steps

Once you have finished configuring your GitLab Runner, you can open the config.toml file, where you should see an output similar to the following:

concurrent = 1
check_interval = 0
connection_max_age = "15m0s"
shutdown_timeout = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "docker"
  url = "http://localhost:8000"
  id = 2
  token = "your_token"
  token_obtained_at = 2024-09-10T16:58:14Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    MaxUploadedArchiveSize = 0
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    tls_verify = false
    image = "node"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock"]
    network_mode = "host"
    shm_size = 0
    network_mtu = 0

This configuration defines the runner settings, including the URL, token, executor type (in this case, Docker), and various other Docker-specific options like the image to use and volume mounts.
Then navigate to Admin > CI/CD > Runners to check the runner

Step 4
Now navigate to your project and create a .gitlab-ci.yml file

stages: Defines the stages of the pipeline. In this case, we have a test stage.
test_node_version: A job within the test stage that checks the Node.js version.
image: Specifies the Docker image to use for the job. node:20-alpine is used here, which matches your Docker configuration.
script: Contains the commands that will run within the container. In this case, node -v outputs the Node.js version installed in the container.
tags: Specifies the GitLab Runner tag to identify which runner will execute the job.

Now, commit the changes to your repository and trigger the pipeline to run.