Docker (5) - CI/CD with Docker Workflow

이전의 4개의 글에서 docker에 대해 자세히 알아보았다.

그러면 이제는 docker를 어떻게 사용하고, 이를 어떻게 본래의 목적에 맞게 활용하는지를 알아보겠다.

 

1. CI / CD

소프트웨어 개발을 하는 사람이라면 많이 들어봤을 단어 두 개이다. 개발을 한다고 하더라도

매번 새로운 기능을 구현하거나 버그를 발견할 때 마다 이를 fix해야 할 때 발생하는 문제가 바로 

1. 개발한 것을 저장소에 통합하고

2. 개발한 것을 프로덕션 환경에 배포해야하는 과정을 매번 반복해줘야 한다는 것이다.

개발자는 귀찮음과 반복적인 작업을 자동화시켜 처리하는 과정을 즐기는편인데,

이러한 과정 또한 마찬가지로 자동적으로 처리하게 해주는 작업을 진행한다. 이 과정이 CI/CD이다.

이것에 대해 간단히 설명하겠다.

• CI (Continuous Integration) : 지속적 통합
  • 소스코드를 통한 웹 개발을 진행하고 이후 테스트를 통해서 현재 기능이 정상적으로 동작함을 확인
  • 그리고 이 소스코드를 빌드하고, 실행을 위한 사전 작업 및 환경을 설정한다.
  • 이렇게 배포할 준비가 완료된 모든 것, 모든 파일들을 중앙 저장소에 통합하는 작업을 진행한다.
  • 이러한 모든 과정을 자동으로 진행하는 것이 지속적 통합이다.
• CD (Continuous Deployment) : 지속적 배포
  • CI에서 중앙저장소에 저장한 내용을 실행하려는 서버에서 pull 받는다
  • pull 받은 것을 프로덕션 서버에서 실행한다.
  • 위 작업들을 자동으로 진행하는 것을 지속적 배포라고 한다.

2. Docker의 사용 절차와 함께 보는 CI / CD

1. Develop :  소프트웨어 개발을 위한 소스 코드를 작성. 로컬 환경에서 수행된다.
2. Test : 로컬 환경이나 추가 툴을 이용, 작성한 코드를 테스트한다.
3. Build : 테스트 완료된 소스코드를 통해 binary code를 build한다
4. Build Docker Image : 어플리케이션의 빌드된 binary code와 환경설정과 함께 docker image를 build한다.
5. Push Docker Image to Registry : 중앙 저장소(Registry)에 docker image를 저장한다.
6. Pull Docker Image from Registry : 중앙 저장소에 Push될 경우, 자동으로 Production server로 Pull 받는다.
7. Run Docker Image : Production server에서 image를 Container를 실행시켜 배포 프로세스가 완료.

1 ~ 5 까지가 CI의 절차이고,

6 ~ 7 까지가 CD의 절차이다.

 

 

그렇지만 docker는 CI, CD, 즉 자동적으로 우리가 개발한 코드를 push했을 때,

build, push, pull, run 해주는 기능이 없다. 이러한 과정에서 핵심이 되기는 하지만 말이다.

 

이를 자동적으로 실행시켜서 자동화를 시켜주는 데 필요한 게 바로 CI / CD 툴이다.

 

3. CI / CD 툴

• Jenkins : 유명한 CI / CD 툴이다. 이를 사용하려면 Jenkins를 위한 서버를 따로 구축해야 한다.
• Github Action :
  • Github이 공짜이고, Github Action 또한 공짜
  • 또한, Github Repository가 제공되고, 이를 사용하므로 호환성도 좋다.
  • 어떤 이벤트가 발생했을 때 (예를 들어, github repository의 main branch로 push된다거나 하는 식의 구체적인 액션이 주어지는 경우) 자동화 작업이 일어날 수 있도록 하는 것이 가능하다.

 

https://www.daleseo.com/github-actions-basics/

GitHub Actions의 소개와 핵심 개념

https://www.daleseo.com/github-actions-first-workflow/

GitHub Actions 첫 워크플로우 생성해보기