11.2.도커를 이용한 빌드 인프라스트럭처 구축하기

직접 빌드 시스템 구축

  • 이미 신뢰성 있는 매니지드 서비스를 무료로 사용할 수 있기 때문에 인프라스트럭처를 구축하려는 사람은 많지 않을 것이다.
  • 하지만 소스 코드와 패키징된 이미지를 내부 네트워크 밖으로 반출하기가 꺼려지는 상황이라면 이상적인 해결책이 된다.
  • 필요한 세 가지 컴포넌트는 상업용으로 운용 가능한 수준의 몇 가지 오픈 소스 소프트웨어를 사용, 이들 모두 명령 한 번이면 설치 가능하다.
  • 형상 관리 기능을 제공하는 Gogs, 이미지 배포를 맡을 오픈 소스 도커 레지스트리, 자동화 서버로는 젠킨스(jenkins)가 있으며, 이들 모두 명령 한 번이면 설치할 수 있다.
  • Gogs: 형상 관리 기능을 제공
  • 도커 레지스트리: 이미지 배포 담당
  • 젠킨스: 자동화 서버
➜ cd ch11/exercises/infrastructure
➜ docker-compose -f docker-compose.yml -f docker-compose-linux.yml up -d

포트 * Gogs: 3000 * 도커 레지스트리: 8080 * 젠킨스: 5000

Gogs, 도커 레지스트리, 젠킨스

이들 도구는 각각 서로 다른 수준의 자동화를 제공한다는 점에서 흥미롭다.

Gogs * Gogs는 자동화 수단이 딱히 없다. 컨테이너로 Gogs를 실행했더라도 수동 설정이 필요하다.

도커 레지스트리 * 레지스트리 서버는 특별한 추가 설정 없이 컨테이너에서 동작 * 이미지 태그에 도메인 registry.local:5000을 포함하면 바로 이미지를 푸시할 수 있다.

젠킨스 * 자바 애플리케이션으로 컨테이너 실행 시 젠킨스를 실행하는 스크립트와 함께 도커 이미지 형태로 패키징할 수 있다. * 이 스크립트는 젠킨스 실행 외에도 플러그인 설치, 사용자 등록, 파이프라인 작업 생성 등 다양한 용도로 활용할 수 있다. * 기능 추가를 위해 플러그인을 사용 * 플러그인은 수동으로 설치할 수도 있고 도커 파일에 스크립트를 포함시켜 자동으로도 설치 가능

Gogs 사용

  1. http://localhost:3000 접속
  2. 처음 나타나는 페이지는 초기 설치 페이지로. 모든 값이 제대로 설정돼 있으므로 스크롤을 내려 Install Gogs를 클릭한다.
  3. Register 버튼을 클릭해 새로운 계정 생성 (diamol으로 고정, 젠킨스에 설정된 CI 작업에 Gogs 사용자명이 diamol)
  4. 로그인 후 새로운 코드가 푸시되면 자동으로 CI 작업이 실행되는 코드 저장소를 생성. http://localhost:3000/repo/create 에 웹 브라우저로 접근한 다음 diamol이라는 이름으로 코드 저장소를 생성한다.

젠킨스 사용

  1. http://localhost:8080 접속
  2. 사전에 diamoL이라는 작업이 설정돼 있으며 이전의 작업이 실패한 상태
  3. ID: diamol, PW: diamol로 로그인
  4. 젠킨스 서버의 CI 작업이 실패한 상태인 이유는 코드를 가져오기로 설정된 Gogs의 Git 저장소에 아직 아무 코드도 없기 때문, Gogs에서 생성한 저장소를 새로운 원격저장소로 추가하고 코드를 푸시
  5. 젠킨스 서버는 1분에 한 번씩 이 코드에 변경이 있었는지 확인하다가 변경이 발견되면 CI 파이프라인을 실행한다.
# 원격저장소 추가 및 코드 푸시

git remote add local http://localhost:3000/diamol/diamol.git
git push local

도커 컨테이너 CI 파이프라인 장점

  • 전체 CI 파이프라인이 도커 컨테이너를 통해 실행되므로 다음과 같은 이점이 있다.
  • 도커에서 실행된 컨테이너는 도커 API, 그리고 같은 도커 엔진에서 실행된 컨테이너와 연결된다.
  • 젠킨스 이미지에는 도커 CLI와 젠킨스 컨테이너 설정을 위한 컴포즈 파일을 포함하고 있기 때문에 도커 명령을 실행하면 호스트 컴퓨터에서 실행 중인 도커 엔진으로 전달한다.
  • 도커 CLI는 기본적으로 로컬 컴퓨터에서 실행 중인 도커 API에 접속을 시도한다.
  • 이때 이 통신 과정은 호스트 컴퓨터 안으로 국한된 채널을 사용하는데, 리눅스 환경에서는 소켓을 사용하고 윈도 환경에서는 명명된 파이프(named pipe)를 사용한다.
  • 이 채널은 컨테이너에서 바인드 마운트로도 사용할 수 있으므로 CLI가 컨테이너 안에서 실행됐다면 실제 통신은 호스트 컴퓨터의 소켓이나 명명된 파이프를 통해 이뤄진다.
  • 이러한 상황을 이용하면 컨테이너에서 실행된 애플리케이션이 도커를 통해 다른 컨테이너를 찾아 달라고 요청하거나 새로운 컨테이너를 시작하고 종료하는 등의 일이 가능해진다.
  • 하지만 컨테이너에서 실행 중인 애플리케이션이 호스트에서 동작 중인 도커의 모든 기능에 접근 가능하다는 점에서 보안 문제가 생길 수 있으므로 신뢰할 수 있는 도커 이미지에만 적용해야 한다.

정리

  • 젠킨스 컨테이너가 도커 및 도커 컴포즈 명령을 실행할 수 있게 도커 엔진과 연결할 수 있도록 하고, 같은 도커 네트워크에서 동작하는 컨테이너인 Git 서버와 도커 레지스트리에는 DNS를 통해 연결한다.
  • CI 프로세스는 애플리케이션을 빌드하도록 하는 명령 하나만을 내릴 뿐이고, 나머지 복잡한 일은 Dockerfile 스크립트와 도커 컴포즈 파일에 정의된 대로 진행된다.

links

social