Intro
[주제] 개발 빌드 환경 구성 및 Docker 빌드 자동화
CI 도구를 통해 소스 관리하고 master로 Pull Request가 되면 어플리케이션을 도커로 빌드 자동화, 레지스트리에 등록
1) GitHub 레포지토리에 Continuous integration 연동
2) 소스코드가 변경이 되면 CI도구 (AWS CodeBuild)가 자동으로 도커로 빌드
3) 빌드 된 도커 이미지를 자동으로 DockerHub레포지토리에 등록
CI란
Continuous Integration, 지속적인 통합.
CI란 팀의 구성원들이 작업한 내용을 정기적으로 통합하는 것을 의미한다.
개발자들은 여러명이 협업하여 각자 개발을 하게된다. 그렇게 팀 단위로 개발을 하다보니 소스 버전 관리 툴을 이용한 소스 코드의 Merge과정은 각자의 개발 사정과 서로의 코드를 Merge하면서 코드의 호환성, 개발환경의 호환성 등의 문제를 생각해야하면서 매우 까다롭게 되었다.
때문에 개발자들은 주기적으로 코드를 Commit하고 build하고 Test를 하면서 Merge의 효율을 높이게 되었고, 이 과정이 빈번하게 발생하여 이를 ‘자동화’하게 된다.
이를 위해 Workflow에서 코드가 Commit되면 build하고 이를 Test해보고 마지막으로 master에 Merge되는 일련의 과정을 자동화하는데 다양한 서드파티 서비스를 활용하여 진행해왔고 해당 CI도구로는 Github Actions, AWS CodeBuild 등이 있다.
CI 시스템의 핵심요소
CI Server : 빌드 프로세스를 관리하는 서버
SCM(Source Code Management) : 소스코드 형상 관리 시스템으로 Git이 여기에 속한다. 소스코드의 개정과 백업 절차를 자동화하며, 오류 수정 과정을 돕는다. 팀 프로젝트의 경우 각자 수정한 부분을 전체가 자동으로 동기화 할 수 있는 시스템이다.
Build Tool : 컴파일, 테스트, 정적 분석 등을 실시해 동작가능한 소프트웨어를 생성하는 도구로 Maven이 이에 속한다. SCM에 있는 소스코드를 가져와 컴파일하여 실행 가능한 파일로 만드는 일련 과정을 일컫는 말이다.
Test Tool : 작성된 테스트 코드에 따라 자동으로 테스트를 수행해주는 도구로 빌드 툴의 스크립트에서 실행된다.
CI의 시나리오
▶ 개발자가 본인 컴퓨터에서 소스 작성하고 빌드 및 테스트 수행
▶ 개발자가 형상관리 저장소에 소스를 업로드
▶ CI 서버가 형상관리 저장소에서 변경 내역을 감지하고 다운로드
▶ CI 서버는 다운로드 한 소스를 스크립트에 의해서 빌드 및 테스트 과정 수행
▶ 빌드 및 테스트 결과를 CI 서버에 저정하거나 담당자에게 알림
▶ CI 서버는 형상관리 저장소의 변경 사항을 계속해서 감지
CI의 장점
▶ 별도의 디버깅 과정 없이 통합 시발생하는 문제점 파악 가능
▶ 소스의 결함으로 인한 문제점을 조기에 발견
▶ 소스의 변경으로 인하여 다른 모듈과의 충돌을 조기에 발견
▶ 변경된 모든 소스에 대한 단위테스트 결과를 빠르게 확인 가능
▶ 올바르지 못한 프로젝트의 진행방향을 조기에 발견
▶ 최종 릴리즈 전에 가능한 많은 문제점을 발견할 수 있음
▶ 개발중인 소프트웨어를 언제라도 배포 가능
CI 솔루션
Jenkins – CI툴로 500여가지가 넘는 플러그인을 온라인으로 간단히 인스톨 할 수 있는 기능을 제공 대신 호스팅을 직접해야하기 때문에 서버 운영 및 관리 비용이 발생
Travis – GitHub에서 인수, GitHub와 연동이 되며 YML 파일을 통해 설정이 쉽다. 단, Jenkins에 비해 플러그인의 종류가 적다.
GitHub Action
GitHub Action은 github에서 제공하는 CI/CD툴로 yml파일을 작성하여 build와 test, 배포를 자동으로 처리하는 도구이다.
yml파일의 작성 전 사전작업
1. docker에서 access token을 생성한다.
실제 docker image를 docker repo에 올리기 위해 docker에 접근하는데 사용하는 password역할을 하는 token이다.
2. github에 setting에서 secrets에 access token과 docker name을 등록한다.
access token과 docker name은 docker repo에 접근하는데 활용하는 key로써 보안을 중시해야한다. 때문에 github에서 secrets로 위의 내용들을 등록하고 secrets 변수로써 활용하여 보안에 신경쓴다.
dockerhub에서 account setting > security에 들어가면 access token생성이 있다.
다음으로 github repo에 들어가서 settings > secrets에 가면 왼쪽과 같은 창이 뜬다.
여기서 New repository secret을 클릭하여 왼쪽에 secrets와 같이 생성해준다.
(이때 secret의 이름은 변수명이 되고, value값에 위에서 생성한 token값과 docker repo의 본인 계정명을 넣는다.)
yml파일 작성
github repo의 Actions탭으로 들어가서 New workflow를 생성한다.
다양한 template들이 많을텐데 여기서 우리는 docker로 연계할 것이기에 위 docker image template을 클릭한다.
기본적인 template을 활용하여 필요없는 부분은 삭제하고 필요한 부분만 첨가하여 작성한다.
name: Publish to DockerHub
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
# push와 pull_req때 jobs가 진행됨
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
# Login a DockerHub except on PR
# https://github.com/docker/login-action
- name: Log into DockerHub
uses: docker/login-action@v1
with:
username: ${{ secrets.DOCKER_HUB_USERNAME }}
password: ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}
# push된 docker image의 tags와 label을 추출
- name: Extract metadata (tags, labels) for Docker
id: meta
uses: docker/metadata-action@v3
with:
images: ${{ secrets.DOCKER_HUB_USERNAME }}/docker-test
# Build and push Docker image with Buildx (don't push on PR)
# https://github.com/docker/build-push-action
- name: Build and push Docker image
uses: docker/build-push-action@v2
with:
context: .
file: ./Dockerfile
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
# 위에 metadata에서 추출한 tag, labelTest
이제 테스트를 한번 해보자
git branch 생성
index.html을 수정 후 push
test1을 master에 병합
위의 사진을 보면 기존에 없었던 master tag를 가진 새로운 image가 자동으로 docker hub에 올라온 모습을 볼 수 있다.
지난번 index에 Docker test라고만 적혀있던것이 publish가 추가되면서 제대로 반영되었다는 것을 확인할 수 있다.
▶ 참고
https://docs.docker.com/ci-cd/github-actions/
https://backlog.com/git-tutorial/kr/stepup/stepup2_7.html
https://waaan.tistory.com/13
https://velog.io/@adam2/GitHub-Actions-%EB%A1%9C-%ED%92%80%EB%A6%AC%ED%80%98%EC%8A%A4%ED%8A%B8-test-%EA%B2%80%EC%A6%9D%ED%95%98%EA%B8%B0
