02. Docker에서 웹 서비스 실행

학습 주제: Dockerization, CI/CD, Github Actions

Hangman 서비스

프로그램 소개

• flask를 사용하여 웹으로 노출
• requirements.txt로 flask 관련 모듈 설치 필요
  • pip3 install -r requirements.txt
• 실행 방법: python3 -m flask run --host=0.0.0.0 --port=4000
  • 이 경우 app.py를 기본으로 사용

Docker Image 구성하기

Docker 컨테이너 내부 프로세스와 호스트 프로세스간의 통신: 포트매핑

• Docker 컨테이너로 포트 4000에 실행된 Flask app이 있다

  • jiwon hangman % docker run jiwon4420/hangman 이렇게 실행하면 localhost:4000들어가도 오류 발생
  • Docker 컨테이너 내부 프로세스가 오픈한 포트번호는 바깥 프로세스에는 안 보이기 때문
    • 예를 들어 앞서 4000번 포트는 호스트 프로세스 브라우저에게는 안 보임

• 이 app을 호스트 운영체제에서 접근하기 위해서는 Docker 컨테이너 내부 프로세스가 오픈한 포트번호를 외부로 노출해줘야 함. 이것이 포트맵핑

  • docker run 수행시 -p 옵션 사용: docker run -p 4000:4000 이미지이름
  • jiwon hangman % docker run -p 4000:4000 jiwon4420/hangman 이렇게 실행해야 함

Dockerfile 추가하기: Dockerization

• Dockerfile 작성
  • app.py 있는 폴더내에 작성

FROM python:3.8-slim-buster
LABEL Maintainer="chu44200@gmail.com" # 메타데이터 docker inspect 명령으로 찾아볼 수 있음

WORKDIR /app
COPY app.py ./
COPY requirements.txt ./

RUN pip3 install -r requirements.txt
EXPOSE 4000 # 이 포트 번호를 사용하니 포트 매핑 시 참고해라
CMD ["python3", "-m", "flask", "run", "--host=0.0.0.0", "--port=4000"]

명령어 순서

• docker build --platform=linux/amd64 -t keeyong/hangman .
• docker image ls
• docker inspect jiwon4420/hangman
• docker run -p 4000:4000 jiwon4420/hangman
• docker run -p 4000:4000 -d jiwon4420/hangman
  • -d: 백그라운드 실행 옵션
• docker push jiwon4420/hangman
  • docker Hub repo에 push: 이때 웹페이지에서 따로 Create Repository안 해줘도 됨

---

CI/CD와 Github Actions

소프트웨어 빌드

• 자신(혹은 팀)이 개발한 소프트웨어를 최종적으로 출시하기 위한 형태로 만드는 것
  • 테스트가 빌드의 중요한 일부로 포함
• 참여 개발자들이 많을수록 이 중요성은 더 커짐
• 개발이 끝나기 전부터 빌드를 하면 소프트웨어의 안정성 증대
  • Continuous Integration

Continuous Integration이란?

• Software Engineering Practice 중 하나
• 기본 원칙
  • 코드 Repo는 하나만 유지(Master)
  • 코드 변경을 최대한 자주 반영
  • 테스트를 최대한 추가
    • Test Coverage
  • 빌드를 계속적으로 수행(자동화)
    • Commit Build vs. Nightly Build
  • 성공한 빌드의 프로덕션 릴리즈(자동화)
    • CD: Continuous Delivery

빌드 실패

• 새 코드의 커밋으로 인해 테스트가 실패하는 경우
• 많은 회사들이 빌드 실패시 빌드가 다시 성공할 때까지 코드 변경을 금지함
  • 즉, 빌드 실패는 모든 사람들을 잡아두는 족쇄
  • 그래서 어느 정도 조직이 커지면 빌드 전담 엔지니어가 생김
    • 이 사람의 업무 중 하나는 빌드 실패시 누가 주범인지 알아내는 것
  • 빌드 실패시 가벼운 형태로 패널티 부여

CI/CD

소프트웨어 개발 및 배포를 더 효율적이고 안정적으로 만들기 위한 일련의 프로세스와 방법론

• CI(Continuous Integration)
  • 개발자들이 변경한 코드(코드 커밋)를 정기적으로, 보통 하루에 여러 번 중앙 리포지토리에 병합하는 프로세스
• CD(Continuous Delivery)
  • CI의 결과물인 애플리케이션을 사용자가 쉽게 배포할 수 있도록 준비하는 프로세스
  • 코드가 빌드되고 테스트된 후, 자동화된 방식으로 스테이징 환경까지 배포되며, 필요에 따라 프로덕션 환경으로의 배포는 수동으로 수행
• CD(Continuous Deployment)
  • Continuous Delivery의 확장된 개념으로, 코드 변경 사항이 자동으로 프로덕션 환경까지 배포되는 프로세스
  • 즉, 모든 코드 변경이 자동으로 프로덕션 환경에 릴리즈됩니다.

GitHub와 CI/CD

Push나 Merge 시점이 CI/CD를 실행하기 위한 순간

• 코드가 Main/Master 브랜치에 추가되는 순간 CI/CD 트리거
  • 이를 특정 Main/Master나 특정 브랜치만 대상으로 하도록 설정 가능
  • 이때 테스트 수행하고 최종적으로 Docker Image등을 만들도록 하는 것이 가능
  • 그래서 CI/CD는 Github에서 구현하는 것이 가장 자연스러움
• Github에서는 이를 Actions라는 기능을 통해 Workflow라는 이름으로 구현 가능

Github Actions

• CI/CD를 Github에서 구현하기 위한 서비스
  • 코드 테스트, 빌드, 배포 자동화 기능 제공
• Workflow라 부르며 아래 컴포넌트로 구성
  • Event
  • Jobs
  • Actions
  • Runner
    • Github hosted runners
    • Self hosted runners

Github Actions - Workflow

Workflow는 트리거 이벤트가 발생하면 시작되는 일련의 동작들을 지칭

• 트리거 이벤트의 예
  • 코드 커밋(main과 같은 특정 브랜치를 대상으로만 제한 가능)
  • PR 생성
  • 다른 Workflow의 성공적인 실행
• Workflow를 위한 명령어들은 YAML 파일로 저장
  • 명령어들로는 환경설정과 script 실행들이 대표적
• Workflow는 Job들로 나눠지며 각 Job은 일련의 스텝을 수행
  • 각 스텝은 하나 혹은 그 이상의 명령어를 실행
    • 이 명령어는 actions라고 부르는 명령어들의 집합이 될 수도 있음
  • 각 스텝은 윈도우나 리눅스 서버 위에서 runner에 의해 실행
    • 이걸 Docker Image에서 수행하는 것이 서비스 배포 과정에 따라 더 일반적이기도 함

Github에서 Github Actions 선택

• 적용하려는 repo에서 Actions 메뉴 서택
• 다음으로 Workflow 하나 생성
• yml 파일을 직접 생성 혹은 템플릿(CI Templates)선택 후 수정
  • Python Application 혹은 Docker Image

Dockerization 추가: Github Action을 통해 Docker Image 빌드/푸시 구현

• 먼저 learndataeng/hangman_web repo를 본인의 Github 어카운트로 fork
  • 여기에 앞서 만든 Dockerfile 존재해야 함
• Github Actions를 통해 main 브랜치에 push나 PR이 있는 경우 Docker Image를 만들고 Docker Hub으로 푸시
  • 하나의 repo에 대해 다수의 workflow들이 존재 가능
  • 모두 .github/workflows/ 밑에 yml 파일 형태로 존재

순서

• Acitions 탭에서 사용할 Template: Docker Image
• docker login 정보 Repo/settings/secrets/actions에서 저장
  • DOCKER_USER
  • DOCKER_PASSWORD
• 위의 내용들을 .github/workflows/docker-image.yml에 기술

name: Docker Image CI 
on:
 push:
  branches: [ "main" ]
 pull_request: 
  branches: [ "main" ]
jobs: 
 build:
  runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3 
- name: docker login
 env:
  DOCKER_USER: ${{secrets.DOCKER_USER}} 
  DOCKER_PASSWORD: ${{secrets.DOCKER_PASSWORD}}
 run: |
  docker login -u $DOCKER_USER -p $DOCKER_PASSWORD
- name: Build the Docker image
  run: docker build --tag ${{secrets.DOCKER_USER}}/hangman:latest . 
- name: docker push
  run: docker push ${{secrets.DOCKER_USER}}/hangman:latest

---

기타

flake8: 파이썬 코드 스타일 체크

파이썬 코드에서 에러나 코딩 스타일 등에서 이슈를 체크해주는 툴
* 이런 툴을 Linting tool이라고 함(언어별로 존재)
* flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics