10. 도커와 DevOps

DevOps, Pipeline

DevOps는 Development와 Operations의 합성어이다.
DevOps는 애플리케이션과 서비스를 빠른 속도로 제공하기 위한 문화, 철학, 방식, 도구를 모두 포함한다.

DevOps는 컨테이너, CI/CD, 자동화, MSA, IaC 등의 개념과 연관이 있다.
컨테이너는 개발자의 개발 환경과 배포 환경과의 차이를 줄여 빠르고 안정적인 배포가 가능하다.

Docker와 CI/CD 파이프라인

파이프라인은 소스코드에서 시작해서 배포 환경 관리까지의 모든 프로세스를 자동화하는 것을 의미한다
파이프라인이 없을 경우 사람이 직접 빌드 및 배포를 수행해야 하고, 휴먼 에러가 발생하고 표준화가 어려워진다.

CI-CD 파이프라인은 CI 파이프라인과 CD 파이프라인으로 나눌 수 있다.

CI(Continuous Integration)

• 지속적 통합, 배포 가능한 아티팩트(Jar/Image)를 빌드하는 단계
• 배포환경에 배포할 수 있는 아티팩트를 만드는 단계를 자동화하는 것을 의미한다.
• 일반적으로 컨테이너 환경에서는 이미지를 빌드하고 Push하는 단계까지 자동화하는 것을 의미한다.

CD(Continuous Delivery/Deployment)

• 지속적 배포, 실제 환경에 아티팩트를 배포하는 단계
• CI 파이프라인에서 생성된 아티팩트를 실제 환경에 배포하는 것을 자동화 한다.

GitHub Actions

GitHub는 파이프라인을 구성하고 자동화할 수 있는 GitHub Actions를 제공한다.
GitHub에 소스코드를 푸시하면 GitHub Actions에서 CI/CD 파이프라인을 자동으로 실행시킬 수 있다.

보통 이미지를 빌드할때 실습용 PC에서 도커 빌드 명령을 사용해서 이미지를 빌드했다.

이렇게 이미지를 빌드하거나 운영 환경에 배포하려면 도커가 설치되어 있는 PC가 필요하다.

GitHub Actions를 사용하면 GitHub가 빌드용 서버를 임시로 빌려주기 때문에 개발자의 PC나 별도의 빌드용 서버가 없이 파이프라인을 실행할 수 있다.

 

GitHub Actions를 사용하기 위해선 별도의 GitHub 계정이 필요하다. 
실습용 소스를 Fork한 뒤 자신의 레파지토리에서 파이프라인을 실행한다.

파이프라인은 .github/workflows 안에 있는 YAML 파일로 구성된다.

.github/workflows 에 있는 YAML 파일들은 깃허브가 자동으로 파이프라인이라고 인식한다.

YAML 파일 한개당 파이프라인을 의미하는 워크플로우가 한 개씩 만들어진다.

GitHub Actions 용어

러너

• 파이프라인이 실제로 실행되는 서버를 러너라고 부른다.
• 파이프라인은 일반적으로 특정 조건이 만족되면 자동으로 실행되기 때문에 이 자동화된 작업을 실행해 줄 서버가 필요하다.
• 깃허브는 무료 러너를 제공해주고 있다. 하지만 일정 시간 이상으로 사용하면 비용을 지불해야 한다.

워크플로우

• 서버에서 실행되는 파이프라인의 실제 작업을 의미
• 워크플로우는 파이프라인과 동일한 개념으로 보면 된다.
• 워크플로우 폴더에 있는 파일 한 개와 동일한 개념이다.

작업

• 하나의 워크플로우는 여러 개의 작업으로 구성되어 있다.

스탭

• 하나의 작업은 여러 개의 스탭으로 구성되어 있다.
• 이러한 작업들은  워크플로우 파일 안에서 코드 형태로 작성되어 있다.

트리거

• 워크플로우는 트리거라는 실행 조건을 걸 수 있다.
• 트리거는 워크 플로우를 자동으로 실행시켜주는 조건을 의미한다.
• 특정 조건이 만족했을 때 트리거가 발생해서 워크플로우를 자동으로 실행한다.
• 트리거는 특정 요일에 특정 시간에 자동으로 실행되게 할 수도 있고 소스 코드를 푸시했을때 발동되도록 지정할 수도 있다.

정리

깃허브 액션에서는 러너와 워크플로우, 트리거를 활용해서 파이프라인을 정의할 수 있다.

GitHub Actions 문법

워크플로우 파일은 docker-compose와 마찬가지로 yaml 문법을 사용한다.

워크플로우 파일은 크게 세 가지 파트로 구성되어 있다.

첫 번째 name 부분은 파일이 만드는 워크플로우의 이름을 지정한다.

두 번째 on 부분은 워크플로우가 실행되는 조건인 트리거를 지정한다.

마지막으로 jobs 부분에는 실제 워크플로우의 내용을 작성해 주면 된다.

• jobs 바로 아래 단계에 있는 부분이 하나의 작업을 생성하는 부분이다.
  • docker-compose를 작성할 때 여러 개의 컨테이너를 작성한 것과 동일한 패턴이다.
  • jobs 아래에는 생성할 작업의 이름을 작성 해주면 된다.
• runs-on 이라고 되어 있는 부분이 해당 작업을 실행할 서버인 runner를 지정하는 부분이다.
  • 특별한 경우가 아니면 최신 버전의 ubuntu를 지정하는 것이 권장된다.

• 마지막으로 steps 부분이 작업을 구성하는 step을 지정하는 부분이다.
  • 이 step에 구체적으로 어떤 작업을 실행할지를 지정하게 된다.

Trigger

트리거는 ON 부분에 설정한다.

트리거는 시간 트리거와 푸시 트리거가 있다.

시간 트리거는 특정시간이 되었을때 자동으로 워크플로우를 실행시키는 트리거이다. schedule을 사용하면 된다.

schedule 아래에 cron 부분에 시간을 표현하는 cron 문법으로 작성된 문자열을 줘서 트리거를 설정할 수 있다.

푸시 트리거는 소스 코드의 변경 사항이 푸시 되었을 때 자동으로 워크플로우를 실행한다.

push 트리거에서는 on 밑에 push를 추가하면 된다.

하지만 push만 있으면 모든 변경 사항이 발생할 때마다 트리거가 발생한다.

그래서 좀 더 구체적으로 조건을 지정할 수 있다.

먼저 특정 브랜치에 대한 push가 일어날 때마다 트리거하려면 push 아래에 branches를 추가하고 트리거할 브랜치의 이름을 지정하면 된다. 그리고 특정 폴더에 대한 변경사항에만 트리거를 걸려면 push 아래에 paths를 추가하면 된다.

다음으로 특정 태그가 붙은 커밋만 트리거하려면 tags 속성을 추가하면 된다.

위 예시는 08-CICD 브랜치에서 leafy-backend 폴더에서 일어난 변경사항 중에서 커밋의 dev로 시작하는 태그가 붙어있는 변경 사항만 워크플로우 트리거가 일어난다는 의미다.

Checkout step

작업의 step을 정의하는 방법과 많이 사용되고 있는 steps에 대해 알아보자.

모든 작업은 러너에서 실행된다.

개인 PC에서 직접 이미지를 빌드할 때는 이미 PC에 도커를 설치하고 소스 코드를 다운받은 상태이기 때문에 바로 이미지를 빌드하고 푸시 할 수 있다. 그런데 러너는 깃허브에서 임시로 빌려오는 서버이기 때문에 많이 사용되는 도커나 Git 같은 도구만 설치되어 있는 상태로 실행이 된다. 하지만 여기에 사용자의 소스코드는 없기 때문에 애플리케이션을 빌드하는 파이프라인을 작성할때 가장 처음해야 하는 것이 소스코드를 다운받는 것이다. 소스코드가 필요하지 않은 작업이면 이 step을 사용하지 않아도 되지만 소스코드로 빌드가 필요한 작업이면 꼭 이렇게 체크아웃 스텝을 실행해서 소스코드를 러너에 다운받아야 한다.

name은 step을 식별할때 사용하는 이름이기 때문에 아무 이름이나 지정하면 된다.

uses에는 사용할 step을 지정하면 된다.

깃헙 액션에서는 이렇게 체크아웃처럼 활용할 수 있는 step을 여러 가지 제공해주고 있다.

이렇게 깃헙에서 제공해주는 하나의 step을 actions라고도 부른다.

그래서 actions의 checkout@v2를 지정해서 해당 워크플로우가 사용하는 깃허브의 소스 코드를 러너에 다운받을 수 있다.

docker setup step

러너에는 기본적으로 도커가 설치되어 있지만 buildx 기능은 활성화되어 있지 않다.

도커의 buildx 기능을 활성화 하면 멀티플랫폼 빌드나 캐싱 같은 기능을 사용할 수 있다.

그래서 도커 기능을 사용하기 전에 이렇게 setup-buildx-action 을 사용해서 도커의 기능을 확장할 수 있다.

 

docker/login-action@v1은 PC에서 도커 로그인을 실행하는 것과 같은 역할을 한다.

도커 로그인을 실행하면 사용자의 인증 정보를 파이 형태로 저장했다.

with를 사용해서 action이 사용할 수 있는 파라미터를 제공할 수 있다.

login-action에 도커 레지스트리 사용자명과 패스워드를 제공하면 러너의 도커 허브에 로그인 할 수 있는 계정 정보를 생성한다.

그래서 이후에 도커 허브의 이미지를 푸시할 때 이 정보를 사용할 수 있는 것이다.

 

계정 정보는 보안의 위험이 있기 때문에 소스 코드에 저장하면 안된다.

그래서 보안을 위해 깃헙 액션에서는 secret 이라는 기능을 제공한다. 

깃헙 secret에 키와 값 형태로 실제 값을 저장해 놓은 다음에 워크플로우 안에서 $와 {} 로 묶어서 secrets.key 값으로 지정하면 소스코드가 아닌 깃허브에서 실제 값을 불러올 수 있다.

docker build and push step

build-push-action은 소스코드를 사용해서 이미지를 빌드하고 이미지를 레지스트리에 푸시하는 액션이다.

with에 파라미터로는 소스코드의 위치인 context와 file 부분에는 도커 파일의 위치를 제공해야 한다.

그리고 push 부분은 분리형 값을 사용해서 이미지를 빌드만 할지 push까지 할지를 선택할 수 있다.

tags의 값을 사용해서 이미지를 빌드할 때 사용할 태그를 지정할 수 있다.

platforms는 이미지를 사용할 수 있는 CPU 아키텍처를 지정해야 한다.

컨테이너 가상화는 커널을 사용한 가상화이기 때문에 이 CPU 아키텍처에 맞추어서 이미지를 빌드해야 한다.

그래서 macOS에서 빌드한 이미지가 윈도우나 리눅스에서는 제대로 실행되지 않는다.

여기서 도커의 멀티플랫폼 빌드를 사용하면 여러 가지 종류의 CPU에서 사용할 수 있는 이미지들을 한 번에 빌드할 수 있다.

하나의 이미지가 사용할 수 있는 CPU를 여러 종류로 빌드하는 것이다.

러너를 우분투 라는 리눅스로 지정했는데 멀티플랫폼 빌드를 사용하지 않으면 이미지는 동일한 리눅스에서만 제대로 실행된다.

정리

이렇게 step들을 잘 활용하면 러너 안에서 소스 코드를 다운받고 이 소스 코드를 이미지로 빌드해서 push까지 할 수 있다.

트리거를 잘 설정하면 원하는 변경 사항이 발생 했을때 이미지를 자동으로 push 할 수 있는 CI 파이프라인을 만들 수 있다.