DEV Community: Md. Abu Raihan Srabon

Automating Docker Image Versioning, Build, Push, and Scanning Using GitHub Actions

Md. Abu Raihan Srabon — Tue, 17 Dec 2024 15:47:28 +0000

Introduction

In a previous blog post, Beginner’s Guide: Build, Push, and Deploy Docker Image with GitHub Actions, we explored how to set up a GitHub Actions workflow for building, pushing, and deploying Docker images. This guide takes it a step further by adding semantic versioning, cleaner build workflows, and vulnerability scanning to the CI/CD pipeline. By implementing these improvements, you can better automate Docker image lifecycle management with a robust and professional workflow.

Why This Update?

The updated workflow introduces several notable enhancements:

Semantic Versioning: Automatically bump Docker image versions based on commit messages.
Improved Docker Build and Push: Cleaner setup with GitHub Container Registry (GHCR).
Security Scanning: Use Trivy to scan Docker images for vulnerabilities before deployment.

This workflow ensures version control, clean tagging, and improved security measures in an automated CI/CD pipeline.

Complete GitHub Actions Workflow

Here is the updated GitHub Actions YAML workflow:

Key Improvements and Explanation

Semantic Versioning

Managing Docker image versions can become tedious, especially in collaborative projects. Semantic versioning automates version bumps based on commit messages:

Default Behavior: Increments the patch version.
Custom Increments:
- Add bump: major in a commit message to increment the major version.
- Add bump: minor in a commit message to increment the minor version.

Code Explanation:

- name: Determine Version Bump Type
  id: determine-bump-type
  run: |
    echo "level=patch" >> $GITHUB_ENV
    if git log -1 --pretty=%B | grep -q 'bump: major'; then
      echo "level=major" >> $GITHUB_ENV
    elif git log -1 --pretty=%B | grep -q 'bump: minor'; then
      echo "level=minor" >> $GITHUB_ENV

Here, the script scans the latest commit message for keywords and determines the version bump level.

Clean Docker Build and Push to GHCR

The Docker image is built and pushed to GitHub Container Registry (GHCR), making it easier to manage images natively in GitHub.

Steps:

Log in to the GHCR using GitHub credentials.
Build and tag the image with the new version and latest tag.

Code Example:

- name: Build and Push Docker Image
  uses: docker/build-push-action@v6
  with:
    context: ./php-8.2
    file: ./php-8.2/Dockerfile
    push: true
    tags: |
      ghcr.io/${{ github.repository }}:${{ needs.semver.outputs.new_version }}
      ghcr.io/${{ github.repository }}:latest

Vulnerability Scanning with Trivy

Security is critical for containerized applications. Trivy scans the built Docker image for vulnerabilities before deployment. It exits with an error if vulnerabilities are found, ensuring only secure images are deployed.

Code Explanation:

- name: Run Trivy Vulnerability Scan
  uses: aquasecurity/trivy-action@0.28.0
  with:
    scan-type: 'image'
    image-ref: ghcr.io/${{ github.repository }}:${{ needs.semver.outputs.new_version }}
    format: 'table'
    exit-code: '1'
    ignore-unfixed: true
    vuln-type: 'os,library'

scan-type: image: Scans the built image.
exit-code: 1: Fails the workflow if vulnerabilities are detected.
ignore-unfixed: true: Ignores vulnerabilities without known fixes.

Conclusion

This enhanced GitHub Actions workflow adds automation, cleaner versioning, and security scanning to your Docker CI/CD pipeline. By leveraging semantic versioning, Docker builds with GHCR, and vulnerability scanning via Trivy, you can ensure efficient, secure, and manageable image deployments.

For a practical implementation, you can refer to the complete workflow in my GitHub repository.

If you're new to GitHub Actions or Docker automation, check out my earlier blog post for foundational concepts: Beginner’s Guide: Build, Push, and Deploy Docker Image with GitHub Actions.

Happy automating!

Beginner’s Guide: Build, Push, and Deploy Docker Image with GitHub Actions

Md. Abu Raihan Srabon — Sun, 10 Nov 2024 14:04:25 +0000

In this post, we’ll introduce GitHub Actions and explain how to use them for automating Docker image builds, pushing images to a self-hosted registry, and deploying them to a remote server. This guide is tailored for beginners who want to start simple and expand their knowledge over time.

What’s GitHub Actions?

GitHub Actions is a powerful tool for automating software workflows directly within your GitHub repository. It allows you to build, test, and deploy your code directly from GitHub. You define your automation tasks as YAML files within your repository, and these tasks run on GitHub’s hosted servers (or self-hosted runners if you prefer).

Why use GitHub Actions?

Seamless integration with GitHub repositories.
Customization: Create workflows tailored to your project needs.
Ease of use: Simple YAML configuration.

What This Script Does

The given GitHub Actions script automates the CI/CD pipeline for building, tagging, and pushing a Docker image to a self-hosted registry, then deploying it to a remote server. Let’s dive into the main sections of the script and understand how each part works.

a. Checking Out the Code

- name: Checkout Code
  uses: actions/checkout@v3

This step clones the repository into the GitHub Actions runner, enabling the workflow to access your project files.

b. Setting Up Docker Buildx

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v2

Docker Buildx allows the runner to build multi-platform images and use advanced build features.

c. Configuring and Logging into the Docker Registry

- name: Add Registry to /etc/hosts
  run: |
    echo "${{ secrets.HOSTS_ENTRY }}" | sudo tee -a /etc/hosts

- name: Configure Docker for Insecure Registry
  run: |
    sudo mkdir -p /etc/docker
    echo '{ "insecure-registries": ["https://harbor.example.com"] }' | sudo tee /etc/docker/daemon.json
    sudo systemctl restart docker

- name: Log in to Docker Registry
  uses: docker/login-action@v2
  with:
    registry: harbor.example.com
    username: ${{ secrets.DOCKER_USERNAME }}
    password: ${{ secrets.DOCKER_PASSWORD }}

These steps set up Docker on the runner to connect to the self-hosted Harbor registry. It configures Docker to treat the registry as an insecure source (use this cautiously) and logs in using provided credentials.

d. Tagging with a Date-Time-Based Version

- name: Generate Date-Time-Based Tag
  id: generate_tag
  run: |
    new_version=$(date -u +"v%Y.%m.%d.%H%M%S")
    echo "Generated tag: $new_version"
    echo "version=$new_version" >> $GITHUB_ENV

This step creates a version tag based on the current UTC date and time, ensuring unique version identifiers for each image build.

e. Building and Pushing the Docker Image

- name: Build Docker Image
  run: |
    PROJECT_NAME=$(echo "${GITHUB_REPOSITORY}" | cut -d'/' -f2)
    docker build -f .docker/Dockerfile \
      -t harbor.example.com/${{ vars.PROJECT_NAME }}/$PROJECT_NAME:${{ env.version }} -t harbor.example.com/${{ vars.PROJECT_NAME }}/$PROJECT_NAME:latest .
  env:
    GITHUB_REPOSITORY: ${{ github.repository }}

- name: Push Docker Image
  run: |
    PROJECT_NAME=$(echo "${GITHUB_REPOSITORY}" | cut -d'/' -f2)
    docker push harbor.example.com/${{ vars.PROJECT_NAME }}/$PROJECT_NAME:${{ env.version }}
    docker push harbor.example.com/${{ vars.PROJECT_NAME }}/$PROJECT_NAME:latest
  env:
    GITHUB_REPOSITORY: ${{ github.repository }}

This section builds the Docker image using the Dockerfile and tags it with both the generated version and latest. It then pushes the images to the Harbor registry.

f. Deploying to a Remote Server

- name: Deploy to Remote Server
  if: success()
  env:
    SSH_HOST: ${{ secrets.SSH_HOST }}
    SSH_USERNAME: ${{ secrets.SSH_USERNAME }}
    SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
    DEPLOY_COMMANDS: ${{ secrets.DEPLOY_COMMANDS }}
  run: |
    echo "${SSH_PRIVATE_KEY}" > /tmp/private_key
    chmod 600 /tmp/private_key
    ssh -o StrictHostKeyChecking=no -i /tmp/private_key ${SSH_USERNAME}@${SSH_HOST} "${DEPLOY_COMMANDS}"
  shell: bash

Finally, this step connects to a remote server via SSH and runs the deployment commands specified in the GitHub secret DEPLOY_COMMANDS. This helps automate the release process.

Below is an image of the complete GitHub Actions script:

What We Have Accomplished by Running This Script

By running this GitHub Actions workflow, we have:

Automated the process of checking out code and setting up Docker on a GitHub-hosted runner.
Built a Docker image from the code and tagged it with both a version and latest.
Pushed the Docker image to a self-hosted Harbor registry.
Deployed the image to a remote server using secure SSH commands.

This streamlines the CI/CD process, making development and deployment faster and more reliable.

Link to GitHub Gist

For an easy reference and to adapt this workflow to your needs, you can find the complete script here on GitHub Gist.

Feel free to use this template as a starting point for automating your Docker workflows and deployment pipelines. With GitHub Actions, you can achieve seamless automation with just a few configuration steps!

Step-by-Step Guide to Setting Up Jenkins on Docker with Docker Agent-Based Builds

Md. Abu Raihan Srabon — Mon, 15 Jan 2024 13:07:47 +0000

Part 1: Introduction to Docker and Jenkins, Setting Up Jenkins on Docker

Introduction to Docker and Jenkins

Hello there! If you're stepping into the world of DevOps or are a Senior Software Engineer looking to dip your toes into automation, this section is a gentle introduction to two powerful tools: Docker and Jenkins.

Docker - Simplifying Environments: Docker is a tool that uses containerization to make it easier for you to develop, deploy, and run applications. Think of it as a virtual box where everything your application needs to run (code, runtime, system tools) is packaged together. This means no more 'it works on my machine' issues, as Docker ensures consistency across environments.

Jenkins - Automating the Boring Stuff: Jenkins is like a helpful robot for software teams. It automates parts of the software development process, particularly those repetitive tasks like building, testing, and deploying code. With Jenkins, you can focus more on writing great code and less on the process of getting that code into production.

Why Are We Talking About Both? Combining Docker and Jenkins can significantly streamline your development workflow. Docker provides a consistent environment for Jenkins to operate in, making your CI/CD pipelines more efficient and less prone to environment-related issues.

Remember, everyone starts somewhere, and questions are a sign of a great learner. Whether you're a beginner in DevOps or an experienced engineer new to automation, this guide aims to make your journey into Docker and Jenkins as smooth as possible. Let's get started and unlock the potential of these tools together!

Installing Docker and Jenkins

In this section, we'll cover the basic steps for installing Docker and setting up Jenkins using a Dockerfile and docker-compose.yml. This setup ensures a smooth and consistent environment for your Jenkins instance.

Installing Docker:

Download Docker:
- For Windows and Mac: Download Docker Desktop from the official Docker website.
- For Linux: Follow the instructions specific to your Linux distribution on the Docker installation guide.
Install Docker:

Follow the installation guide for your operating system on the Docker website. This typically involves running an installer or executing a few commands in the terminal.
Verify Installation:

Open a terminal or command prompt and run docker --version to ensure Docker was installed successfully.

# docker --version
Docker version 24.0.7, build afdd53b

Setting Up Jenkins in Docker:

For Jenkins, we will use a custom Dockerfile and docker-compose.yml to create a Docker image with Jenkins installed. Here's a step-by-step guide:

Prepare the Dockerfile:

# Jenkins JDK 17, JDK 11 is being deprecated
FROM jenkins/jenkins:latest-jdk17

USER root

RUN apt-get update && apt-get install -y lsb-release

RUN curl -fsSLo /usr/share/keyrings/docker-archive-keyring.asc \
  https://download.docker.com/linux/debian/gpg

RUN echo "deb [arch=$(dpkg --print-architecture) \
  signed-by=/usr/share/keyrings/docker-archive-keyring.asc] \
  https://download.docker.com/linux/debian \
  $(lsb_release -cs) stable" > /etc/apt/sources.list.d/docker.list

RUN apt-get update && apt-get install -y docker-ce-cli

RUN apt update && apt install tzdata -y

ENV TZ="Asia/Dhaka"

USER jenkins

The provided Dockerfile sets up Jenkins with JDK 17 and installs Docker inside the Jenkins container. This setup allows Jenkins to run Docker commands, which is crucial for Docker Agent-based builds.

Understanding the Dockerfile:

The Dockerfile begins with the latest Jenkins image with JDK 17.
It installs the necessary packages and Docker CLI inside the container.
The timezone is set to 'Asia/Dhaka', which you can adjust as per your requirement.

Setting Up docker-compose:

version: '3.8'
services:
  jenkins:
    build: 
      context: .
      dockerfile: .docker/Jenkins/Dockerfile
    image: jenkins-jdk-17
    container_name: jenkins-jdk-17
    privileged: true
    user: root
    restart: always
    ports:
      - 8080:8080
      - 50000:50000
    volumes:
      - jenkins_home:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock
      - /usr/bin/docker:/usr/bin/docker

volumes:
  jenkins_home:
    name: jenkins_home

The provided docker-compose.yml file defines the Jenkins service, using the image built from our Dockerfile.
It sets the container to run in privileged mode with root user, ensuring that Docker commands can be executed within Jenkins.
Ports 8080 and 50000 are exposed for Jenkins web UI and agent connections.
Volumes are used for persisting Jenkins data and for Docker socket binding, allowing Jenkins to control Docker on the host.

Building and Running Jenkins Container:

Navigate to the directory containing your Dockerfile and docker-compose.yml.
Run docker-compose build to build your Jenkins image.
Once the build is complete, run docker-compose up to start Jenkins.
Jenkins should now be accessible at http://localhost:8080.

Accessing Jenkins:

On your browser, go to http://localhost:8080 to access the Jenkins web UI.

Follow the initial setup wizard to configure Jenkins. You will need the initial admin password, which can be found in the Jenkins console logs or inside your Jenkins container at /var/jenkins_home/secrets/initialAdminPassword.

Pic: collect initial admin password from console.

Pic: Jenkins UI for initial admin password

Pic: Plugins Selection page (we will move forward with defaults).

Pic: Default plugins are being installed.

Pic: Setup Jenkins URL (This URL will be used to configure projects)

Pic: admin user setup.

Pic: Jenkins Home page.

Additional Resources:

For a more detailed Docker installation guide, visit the Docker documentation.
To understand more about Jenkins and Docker, explore the official Jenkins documentation.

GitHub Repository:

For the complete Dockerfile, docker-compose.yml, and additional configuration files, you can visit the GitHub repository: https://github.com/aburaihan-dev/jenkins-in-docker. This repository contains all the necessary files and instructions to get your Jenkins on Docker up and running.