Docker CI 알아보기

KANS 스터디 1주차 Docker CI 알아보기

💡 KANS 스터디
CloudNet에서 주관하는 KANS(Kubernetes Advanced Networking Study)으로 쿠버네티스 네트워킹 스터디입니다. 아래의 글은 스터디의 내용을 기반으로 작성했습니다.

스터디에 관심이 있으신 분은 CloudNet Blog를 참고해주세요.

들어가며

컨테이너 기반의 애플리케이션을 운영하고 있다면, CI 과정에서 컨테이너 이미지 빌드가 필요하다. 여기서는 Docker 기반으로 이미지를 빌드하는 방법을 알아본 후 직접 작업해보며 빌드 과정에서 발생할 수 있는 문제점을 살펴본다. 마지막으로 Kaniko와 같은 대체방안을 살펴보며 마무리한다.

Docker CI

Docker CI를 위해선 컨테이너 내부에서 Docker를 사용할 수 있어야한다. 이를 위해 DinD(Docker in Docker) 혹은 컨테이너 내부에서도 docker를 조작할 수 있게 socket 마운트가 필요하다.

DinD는 컨테이너 내부에서 Docker 컨테이너를 실행하는 것을 의미한다. 예를 들어, GitLab Runner는 기본적으로 컨테이너기반이다.

docker는 socket 기반으로 통신한다. 그렇기에 docker가 사용하는 socket을 마운트하면, docker와 통신할 수 있다. 우선 docker.socket에 대해 살펴보자.

socket

docker는 Unix domain-socket을 사용한다. socket을 통해 docker daemon과 통신하므로 Host에 있는 docker socket을 사용할 수 있다면, 컨테이너 내부에서도 docker를 사용할 수 있다.

tcp를 사용하게 설정하면, 다른 서버에서도 docker 데몬을 사용할 수 있지만 k8s라는 좋은 방법이 있다.

lsof /run/docker.sock
COMMAND  PID USER   FD   TYPE             DEVICE SIZE/OFF  NODE NAME
systemd    1 root   40u  unix 0xffff966d51faddc0      0t0 31848 /run/docker.sock type=STREAM
dockerd 3966 root    4u  unix 0xffff966d51faddc0      0t0 31848 /run/docker.sock type=STREAM

DinD vs mount docker.socket

이제 본격적으로 DinD와 socket 마운트 방식을 비교하자. docker community와 jpetazzo Post에서 DinD와 docker.socket mount의 차이가 잘 정리되어있다. 간단하게 요약하면, 아래와 같다.

1. --privileged 로 인해 SElinux와 같은 보안 모듈과 충돌할 수 있다.

2. 내부 Docker는 COW 시스템 위에서 실행되기에 여러 파일시스템 조합이 작동되지 않을 수 있다.

   ex) AUFS on top of AUFS

3. 도커 컨테이너에서 컨테이너를 생성해도, Host Docker에서 컨테이너가 생성되므로 캐시 효율성이 높아진다.

결론적으로 보안상, 성능 차원에서 DinD보다 socket mount 방식이 강력히 추천된다. 이제 socket mount 방식으로 컨테이너안에서 이미지를 빌드하는 방법을 알아보자.

실습

환경

Jenkins를 컨테이너 기반으로 가동하고, 해당 컨테이너에 socket을 마운트하여 컨테이너 이미지를 빌드한다.

• Jenkins 컨테이너 생성

docker run -d -p 8080:8080 -p 50000:50000 --name jenkins-server --restart=on-failure -v jenkins_home:/var/jenkins_home -v /var/run/docker.sock:/var/run/docker.sock -v /usr/bin/docker:/usr/bin/docker jenkins/jenkins

아래의 명령어를 수행하면 Init 비밀번호를 확인할 수 있다.

docker exec -it jenkins-server cat /var/jenkins_home/secrets/initialAdminPassword

• docker api 가능여부 확인

docker api 사용가능여부 확인해보면 정상적으로 사용할 수 있는 것을 알 수 있다.

docker exec -it --user 0 jenkins-server docker ps
CONTAINER ID   IMAGE             COMMAND                  CREATED          STATUS          PORTS                                                                                      NAMES
86170af3b1ab   jenkins/jenkins   "/usr/bin/tini -- /u…"   44 seconds ago   Up 43 seconds   0.0.0.0:8080->8080/tcp, :::8080->8080/tcp, 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp   jenkins-server

• 이제 root가 아닌 jenkins 유저도 docker를 실행할 수 있도록 권한을 부여한다.

docker exec -it --user 0 jenkins-server bash
root@8266345972f8:/# groupadd -for -g $(stat -c '%g' /var/run/docker.sock) docker
root@8266345972f8:/# usermod -aG docker jenkins

실제 Jenkins 유저로 접속하여 API를 확인한다.

docker ps
CONTAINER ID   IMAGE             COMMAND                  CREATED       STATUS       PORTS                                                                                      NAMES
8266345972f8   jenkins/jenkins   "/usr/bin/tini -- /u…"   1 hours ago   Up 1 hours   0.0.0.0:8080->8080/tcp, :::8080->8080/tcp, 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp   jenkins-server

서버의 IP주소의 8080 포트로 접속하면, 아래와 같이 Jenkins를 확인할 수 있다.

젠킨스 CI

docker pipeline pulgin을 설치 후 아래와 같은 간단한 파이프라인을 만든다.

pipeline {
    agent any

    stages {
        stage('Create Dockerfile and a.txt') {
            steps {
                script {
                    // a.txt 파일 생성
                    writeFile file: 'a.txt', text: "This is a simple file."
                    
                    // 간단한 Dockerfile 생성
                    writeFile file: 'Dockerfile', text: """
                    FROM alpine:latest
                    COPY a.txt /a.txt
                    CMD ["cat", "/a.txt"]
                    """
                }
            }
        }

        stage('Build Docker Image') {
            steps {
                script {
                    // Docker 이미지 빌드
                    docker.build("simple-jenkins-image")
                }
            }
        }

        stage('Run Docker Image') {
            steps {
                script {
                    // 빌드된 이미지를 실행하고 a.txt 파일의 내용을 출력
                    docker.image("simple-jenkins-image").inside {
                        sh 'cat /a.txt'
                    }
                }
            }
        }
    }

    post {
        always {
            echo 'Cleaning up...'
            // 필요 시 클린업 코드 추가
        }
        success {
            echo 'Build completed successfully!'
        }
        failure {
            echo 'Build failed!'
        }
    }
}

Job을 시작하면 아래와 같이 잘 동작한다.

또, 호스트 서버에서 이미지 확인할 수 있다.

root@MyServer:~# docker image ls
REPOSITORY             TAG       IMAGE ID       CREATED          SIZE
simple-jenkins-image   latest    f6943e3910a7   59 seconds ago   7.8MB
jenkins/jenkins        latest    fd13cb1b7315   2 days ago       471MB
alpine                 latest    324bc02ae123   5 weeks ago      7.8MB

대안 방법

컨테이너 이미지 빌드에 Docker 자체를 사용하지 않는 방식이 존재한다.

kaniko

DinD는 도커자체에서 sudo 권한이 필요하므로, 컨테이너가 root 권한을 가지며 이는 보안상 좋지 않다. 이를 위해 Kaniko가 나오게된다. 루트 권한없이, 컨테이너 이미지를 빌드할 수 있는 도구이다. 구글에서 만들었으며, 윈도우 컨테이너 이미지는 지원하지 않는다고 한다.

출처: https://blog.nashtechglobal.com/deep-dive-into-kaniko-understanding-the-architecture-and-workflow/

GitLab으로 CI/CD를 구성했을 때, DinD는 root 권한이 필요하여 별도로 Runner에 privileged 옵션을 허용해줘야 했다. 이는 보안상 좋지 않고, GitLab에서도 이를 권장하지 않는다. 별도로 Kaniko에 대한 GitLab 가이드 문서가 있다.

또 다른 빌드도구로는 Buildkit, Buildah가 있다고 한다. 해당 포스트에서 잘 정리되어있다.