Building, Securing, and Deploying a Go App with GitLab CI/CD EP 1: Getting Started with GitLab CI/CD and Docker-in-Docker

Introduction

Welcome to the first episode of our CI/CD journey!
In this guide, I’ll help you understand how to automate your software development using GitLab CI/CD. We’ll also talk about a key concept called Docker-in-Docker—but don’t worry, I’ll break everything down in simple steps.

By the end of this post, you’ll know:

• What GitLab CI/CD is and why it’s useful
• What a pipeline is (and why we need one)
• How Docker and Docker-in-Docker help us build and test code in CI/CD

Ready? Let’s dive in!

---

1. What is GitLab CI/CD?

CI/CD stands for Continuous Integration and Continuous Deployment.
It’s a way to automate all those repetitive tasks that happen after you push code—like checking for errors, running tests, and even deploying your app.

GitLab CI/CD is a feature of GitLab (a platform for hosting your code), which lets you build these automation “pipelines” right alongside your code.

Why use it?

• Saves time: No more manual testing or deployment
• Catches bugs early: Automated checks run every time you push code
• Works for every project: From small scripts to big apps

---

2. What is a Pipeline?

A pipeline is just a series of steps (called “jobs”) that run automatically every time you push code.
Each job does one thing—like checking your code style, running tests, or building your app.

Think of a pipeline like a factory assembly line:

• First, your code is checked for errors
• Next, it’s tested
• Then, it’s built and sent where it needs to go

Here’s what a simple pipeline might look like:

• Lint: Check your code style
• Test: Run your tests
• Build: Make your app ready to run
• Deploy: Send your app to a server

In GitLab, you control your pipeline with a special file called .gitlab-ci.yml.

---

3. What is Docker and Docker-in-Docker?

Docker is a tool that lets you package your app and everything it needs to run (like code, settings, libraries) into a “container.”
Containers are like lightweight, portable computers for your app—they make sure it runs the same way everywhere.

Docker-in-Docker (DinD)
Usually, Docker runs on your computer or server. But in CI/CD, you often need to use Docker inside another Docker container—this is called Docker-in-Docker.

Why do we use it in CI/CD?

• So the pipeline can build, test, and run containers automatically—without needing a full server for each job
• It keeps your builds isolated and clean

Visual Example:
Imagine a Russian nesting doll—one Docker container (the CI job) runs another Docker container (your app or build).

Breakdown of the Image

• Big Blue Creature (CI Job):
  Represents a CI (Continuous Integration) job or runner. In most CI/CD platforms (like GitLab CI, GitHub Actions, Jenkins, etc.), jobs are executed in containers or virtual machines.

• Small Docker Whale Inside:
  Inside the CI job, you see the familiar Docker whale. This shows that the CI job itself is running a Docker daemon inside the CI environment.

• Containers/Blocks Inside the Whale:
  These represent your app or build containers, which are being created and managed inside this inner Docker daemon.

Note:
Docker-in-Docker is super useful, but it does have some security considerations. For beginner projects, it’s usually just fine!

---

4. Setting Up Your GitLab Project

Let’s get started step by step:

A. Create a New Project

4.1.1) Go to GitLab and log in (sign up if you don’t have an account).

4.1.2) Click the **“New project” button.**

4.1.3) Select how you want to create your project

4.1.4) Name your project and choose your settings (public or private).

B. Push Your Local Project to GitLab

Now that your project is created, let’s upload your code from your computer to GitLab.

4.2.1) Open your terminal and navigate to your project folder

   cd path/to/your/project

4.2.2) Initialize a Git repository (if you haven’t already):

   git init

4.2.3) Add the GitLab repository as a remote:
Replace YOUR-USERNAME and YOUR-PROJECT with your actual GitLab info.

   git remote add origin https://gitlab.com/YOUR-USERNAME/YOUR-PROJECT.git

4.2.4) Change branch master to main

   git branch -M main

Optional If your Auto generate Gitlab repo have readme.md you can pull it down and have it modifies before push it back as well

git pull origin YOUR-PROJECT-BRANCH

For example

git pull origin develop

4.2.5) Add, commit, and push your code:

   git add .
   git commit -m "Initial commit"
   git push -u origin master

That’s it! Your code is now on GitLab, and you’re ready to start using CI/CD.

---

C. Explore the Interface

• The sidebar lets you see your code, pipelines, CI/CD, and more.

• Under “Build”, you’ll see pipelines and jobs as you build them.

---

5. Your First .gitlab-ci.yml File

This file tells GitLab how to run your pipeline.
Let’s start with a basic version that just runs Docker commands (using Docker-in-Docker):

image: docker:latest

services:
  - docker:dind

stages:
  - build

build_image:
  stage: build
  script:
    - echo "Hello from inside Docker-in-Docker!"
    - docker version
    - docker info

• image: docker:latest: Use Docker in the pipeline.
• services: - docker:dind: Start the Docker-in-Docker service so we can use Docker commands.
• stages: - build: We’ll just have a build stage for now.
• The job build_image just prints out Docker info to show it works.

How to use:

1. Copy and paste this into a file called .gitlab-ci.yml in the root of your project.
2. Commit and push your code.
3. Go to your project’s CI/CD → Pipelines page and watch your first pipeline run!

---

6. What’s Next?

Now you’ve created your first pipeline and learned what Docker-in-Docker is all about!

In the next episode, we’ll:

• Set up Go on the pipeline
• Add linting to automatically check your code style
• Store and view lint reports

Stay tuned—and congrats on starting your CI/CD journey!

---