원티드 프리온보딩 백엔드-Docker-3일차

전체 과정 설명

과정 설계 - 이론 + 실습시연 + 실제 면접 질문 + QnA(매 교시 시작시간 10분 + 수업 마지막 시간 30분 전 - QnA시간양은 유동적으로 조정)
- 4회동안 compact 하게 큰 그림을 그려봅시다 - 세부 사항 학습 자습 병행 (mac os / windows)
- 20% 핵심
포트폴리오에 어떻게 적용되는지 - 서비스 운영환경에 대한 경험 - 운영환경 구축 - CI/CD, 컨테이너

오늘의 면접질문 원픽

모던 웹 개발에서 CI/CD가 왜 필요하게 되었을까? (CI/CD 구축 왜 하셨어요?)

CI / CD 기초 개념과 아키텍쳐

CI/CD

ci/cd 란
from. “CI/CD(CI CD, 지속적 통합/지속적 배포): 개념, 툴, 구축, 차이.” Redhat.com, 2024, www.redhat.com/ko/topics/devops/what-is-ci-cd. (좋은 아티클이니 한번 꼭 읽어보세요!)

‌

CI/CD는 소프트웨어 개발 과정에서의 효율성과 신속성을 극대화하는 자동화된 프레임워크를 제공한다. 이 접근 방식은 개발부터 운영까지의 소프트웨어 개발 라이프사이클의 모든 단계를 아우르며, 지속적 통합, 지속적 전달, 지속적 배포의 세 주요 구성 요소로 구분된다.

지속적 통합 (CI)

개발자들이 작업한 코드를 주기적으로 공유 레포지토리에 병합함으로써, 코드의 통합을 자동화하는 과정이다.
모든 변경사항은 자동 빌드 및 테스트를 거쳐 메인 브랜치에 통합된다.
코드 충돌을 최소화하며, 소프트웨어의 품질을 유지하고, 배포 준비 상태를 지속적으로 유지할 수 있다.

지속적 전달 (CD - Continuous Delivery)

CI 과정을 한 단계 더 발전시켜, 코드 변경사항이 자동으로 빌드 및 테스트를 거쳐 실제 운영 환경에 배포될 준비가 된다.
이 단계에서는 배포 과정을 완전히 자동화하지 않고, 실제 배포는 수동으로 트리거할 수 있는 옵션을 둔다.
개발팀은 언제든지 안정적인 버전의 소프트웨어를 신속하게 배포할 준비가 되어 있으며, 비즈니스 요구에 따라 배포 시점을 선택할 수 있다.

지속적 배포 (CD - Continuous Deployment)

모든 코드 변경사항이 자동 테스트를 통과하면 즉시 프로덕션 환경에 배포된다.
이 과정은 개발팀이 소프트웨어를 빠르게 혁신하고, 사용자에게 지속적으로 가치를 전달할 수 있도록 한다.
지속적 배포를 통해, 소프트웨어의 릴리스 과정이 자동화되어, 인간의 개입 없이도 신속하게 배포된다.
CI/CD 파이프라인의 도입은 개발 프로세스의 자동화뿐만 아니라, 코드 통합, 테스트, 배포 과정의 효율성을 극대화하여, 개발팀이 더 나은 소프트웨어를 더 빠르게 출시할 수 있도록 지원한다. 각 단계에서의 자동화와 통합은 코드 품질의 지속적인 개선, 개발 주기의 단축, 그리고 최종적으로는 사용자 만족도의 증대로 이어진다. CI/CD는 현대적인 소프트웨어 개발의 필수 요소로, 지속적인 혁신과 경쟁력 유지를 위한 핵심 전략이다.
예시
CI/ CD 파이프라인 도구들
- 여러 CI/CD 파이프라인 도구들이 있으며, 각각의 도구는 고유의 특성과 장단점을 가지고 있습니다. 여기 몇 가지 주요 도구들을 소개하고, 각각에 대한 공식 문서 링크를 제공합니다:
- Jenkins
  - 장점: 매우 유연하며, 수많은 플러그인으로 확장 가능
  - 단점: 초기 설정이 복잡할 수 있음
  - Jenkins 공식 문서
- GitHub Actions
  - 장점: GitHub과의 긴밀한 통합
  - 단점: 다른 도구들에 비해 상대적으로 새로움
  - GitHub Actions 공식 문서
- GitLab CI/CD
  - 장점: 소스 코드 관리와 CI/CD가 하나의 플랫폼에 통합
  - 단점: 대규모 프로젝트에서는 자원 관리가 필요할 수 있음
  - GitLab CI/CD 공식 문서
- CircleCI
  - 장점: 빠른 실행 속도와 좋은 확장성
  - 단점: 무료 플랜의 제한적인 리소스
  - CircleCI 공식 문서
Github action 을 Github Repository 사용할 때 편합니다. 무엇보다 깔끔한 공식문서. 사용자 생태계로 만들어진 수많은 자료.
https://docs.github.com/ko/actions
- https://docs.github.com/ko/actions/guides
- 장점
  - 깃허브 통합: GitHub 리포지토리와 긴밀하게 통합되어 있어, 추가적인 서비스나 툴 없이도 바로 CI/CD 파이프라인을 설정할 수 있다.
  - 간편한 설정: 워크플로우 파일을 리포지토리에 추가하는 것만으로 파이프라인을 구성할 수 있어, 사용하기 쉽다.
  - 유연성: 다양한 운영 체제에서 작업을 실행할 수 있으며, 컨테이너 내에서 작업을 실행할 수도 있다.
  - 마켓플레이스: 수많은 액션을 마켓플레이스에서 찾아서 사용할 수 있어, 파이프라인을 쉽게 확장할 수 있다.
- 단점
  - 리소스 제한: 무료 플랜에서는 사용할 수 있는 리소스에 제한이 있어, 큰 프로젝트에서는 유료 플랜으로의 업그레이드가 필요할 수 있다.
  - 학습 곡선: GitHub Actions의 모든 기능을 활용하기 위해서는 YAML 문법과 GitHub Actions의 특정 개념을 익혀야 한다.
- GitHub 리포지토리를 사용할 때 GitHub Actions가 유리한 이유는 리포지토리와의 긴밀한 통합 때문이다. 소스 코드 관리와 CI/CD 파이프라인을 같은 플랫폼에서 관리할 수 있어, 복잡성이 줄어들고 프로젝트의 효율성이 증가한다.
github action 자체에 대해 더 알고 싶다면 아래 공식 문서 예시를 참조
- https://docs.github.com/en/actions/examples

Github Action 의 동작원리

GitHub Actions는 GitHub 리포지토리의 이벤트(예: 푸시, 풀 리퀘스트)에 반응하여 자동화된 워크플로우를 실행하는 시스템.
워크플로우는 .github/workflows 디렉토리 내 YAML 파일로 정의되며, 이 파일 내에서 작업(jobs), 단계(steps), 액션(actions) 등을 설정할 수 있음.
워크플로우는 이벤트 발생 시 지정된 환경(예: Ubuntu, Windows)에서 컨테이너 또는 가상 머신 위에서 실행. 작업은 서로 독립적으로 또는 병렬로 실행될 수 있으며, 각 단계에서는 소프트웨어 빌드, 테스트, 배포 등의 작업을 수행이 가능해짐.
https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
Workflow(작업) 은 GitHub Actions에서 실행되는 자동화 프로세스를 정의하는 단위. 각 작업은 독립적으로 실행되며, 여러 개의 단계로 구성될 수 있음.
Step(단계)는 각 작업 내에서 수행되는 단일 명령어 또는 액션의 연속. 작업 내에서 단계는 순차적으로 실행되며, 성공적으로 완료되어야 작업이 성공적으로 완료됨.
Action(액션)은 GitHub Marketplace에서 가져온 또는 직접 작성한 재사용 가능한 코드 조각. 이러한 액션은 다양한 용도로 사용될 수 있으며, CI/CD, 테스트, 배포 등과 같은 다양한 작업을 자동화하는 데 사용됨.
secretes:
- https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions
- GitHub Actions에서 secrets는 리포지토리의 중요한 데이터를 안전하게 저장하고 관리하는 데 사용. 이러한 데이터는 API 토큰, 암호, SSH 키 등과 같이 민감한 정보를 포함할 수 있음. Secrets는 보안을 유지하기 위해 암호화되어 저장되며, 워크플로우 실행 중에만 필요할 때만 복호화되어 사용됨.
- 워크플로우에서 Secrets를 사용하려면 리포지토리 설정에서 Secrets를 설정해야 함. Secrets는 보통 환경 변수로 사용되며, 워크플로우 실행 중에 워크플로우 스크립트나 액션에서 참조됨. Secrets는 워크플로우 로그에서 안전하게 숨겨지며, 민감한 정보가 외부로 노출되지 않도록 함.
- 보안성을 유지하기 위해, 일반적으로 Secrets는 코드와 함께 리포지토리에 직접 포함되지 않음. 대신, 안전한 방식으로 관리되고 워크플로우에서 필요한 경우에만 사용됩니다. 이를 통해 보안을 강화하고 민감한 정보가 외부로 유출되는 것을 방지할 수 있음.

  
steps:
  - name: Hello world action
    with: # Set the secret as an input
      super_secret: $
    env: # Or as an environment variable
      super_secret: $

이러한 구성 요소들을 조합하여 GitHub Actions를 사용하면 소프트웨어 개발 및 배포 프로세스를 자동화할 수 있음.

Github Action 사용하기 실습

[실습1] repository 만들기 - action 들어가기 - 클릭 후 만들기(commit & push)
READMD.md 를 만들고 commit 을 해봅시다.

  
# 이것은 Actions를 시작하는 데 도움이 되는 기본 워크플로우입니다

name: CI

# 워크플로우가 실행될 시점을 제어합니다
on:
  # "main" 브랜치에 대한 push 또는 pull request 이벤트가 발생했을 때 워크플로우를 트리거합니다
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

  # Actions 탭에서 이 워크플로우를 수동으로 실행할 수 있습니다
  workflow_dispatch:

# 워크플로우 실행은 하나 이상의 작업으로 구성되며, 이러한 작업은 순차적으로 또는 병렬로 실행될 수 있습니다
jobs:
  # 이 워크플로우는 "build"라고 불리는 단일 작업을 포함합니다
  build:
    # 작업이 실행될 러너의 유형
    runs-on: ubuntu-latest

    # 단계는 작업의 일부로 실행될 일련의 작업을 나타냅니다
    steps:
      # $GITHUB_WORKSPACE 아래에서 리포지토리를 체크아웃하여 작업이 이에 접근할 수 있도록 합니다
      - uses: actions/checkout@v3
      # https://github.com/actions/checkout 을 사용함.
      

      # 러너의 셸을 사용하여 단일 명령을 실행합니다
      - name: Run a one-line script
        run: echo Hello, world!

      # 러너의 셸을 사용하여 일련의 명령을 실행합니다
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

포인트 :
- actions/checkout 액션은 워크플로우가 실행되는 가상 환경에 당신의 저장소의 코드를 체크아웃(checkout)해서 사용할 수 있게 해줌. 즉, 이 액션을 사용하면 GitHub Actions가 실행 중인 워크플로우가 저장소의 코드에 접근하여 다양한 작업을 수행할 수 있게 됨.
[실습2] 공식문서 보고 직접해보기
- https://docs.github.com/ko/actions/learn-github-actions/understanding-github-actions

  
name: learn-github-actions
run-name: $ is learning GitHub Actions
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g bats
      - run: bats -v

[직접 풀기] 아래 그림에서 적힌 내용을 learn-github-actions.yml 에서 어떤 라인이 실행시키는지 매핑시켜보세요.
포인트1 : $
포인트2 : on: [push]
포인트3 : jobs:check-bats-version: 이 github action 섹션 모니터링에서 어떻게 보이는지?

Docker와 Github Action 함께 사용하기

시나리오1. GitHub Actions과 Docker를 함께 사용하여 간단한 flask 애플리케이션을 빌드하고 테스트
- https://github.com/siyoungoh/flask-app
시나리오2. GitHub Actions과 Docker를 함께 사용하여 간단한 Node.js 애플리케이션을 빌드하고 테스트
- https://github.com/siyoungoh/node-github-action-docker
- docker login 시도해보기 -> secrets 설정
  - DOCKER_PASSWORD, DOCKER_USERNAME
시나리오3. Github Action 을 사용해 push 가 되면 docker hub 에 새 이미지가 업데이트 되기
https://github.com/siyoungoh/nodejs-dockerhub
Github Action으로 내 서버까지 배포하기
- https://gist.github.com/siyoungoh/aeb2979f187ab9afe2a07679205ae51a

추가 실습

내 기술 스택에 맞는 배포 ci/cd 찾아서 튜닝해보기
- https://github.com/explore
- 예를 들면 spring :

Advanced

[실습3] - Docker 이미지 만들기
- https://github.com/actions/hello-world-docker-action
- https://docs.github.com/ko/actions/creating-actions/creating-a-docker-container-action
-

DockerFile 부터 해석해보기 https://github.com/actions/hello-world-docker-action/blob/main/Dockerfile

  
# 이후의 명령어에서 사용할 기본 이미지를 설정합니다.
FROM alpine:3.19

# 컨테이너 내에서 작업 디렉토리를 설정합니다.
WORKDIR /usr/src

# 액션에 필요한 소스 파일을 복사합니다.
COPY entrypoint.sh .

# 컨테이너를 실행 파일로 구성합니다.
ENTRYPOINT ["/usr/src/entrypoint.sh"]

참고 :
- ENTRYPOINT 지시자는 컨테이너가 시작될 때 실행되어야 하는 명령을 정의. 이를 통해 컨테이너가 특정 실행 파일을 기본으로 실행하도록 설정할 수 있으며, 컨테이너의 실행 환경을 구성하는 데 사용됨.
- ENTRYPOINT ["/usr/src/entrypoint.sh"] 구문은 컨테이너가 시작될 때 실행되어야 하는 기본 명령을 설정함. 여기서는 /usr/src/entrypoint.sh 스크립트를 컨테이너의 기본 실행 파일로 지정. 이 말은, 컨테이너가 시작될 때 이 스크립트가 자동으로 실행되어야 함을 의미.
[중요]
- https://docs.github.com/ko/actions/creating-actions/dockerfile-support-for-github-actions?learn=create_actions&learnProduct=actions
- “GitHub Actions에 대한 Dockerfile 지원: Docker 컨테이너 작업에 대한 Dockerfile을 만들 때 일부 Docker 명령이 GitHub Actions 및 작업의 메타데이터 파일과 상호 작용하는 방법을 알고 있어야 합니다.”
1-2. DockerFile 부터 해석해보기(관련된 파일인 entrypoint.sh)
1 #!/bin/sh -l

# 입력값을 얻기 위해 INPUT_<입력_이름>을 사용합니다

GREETING="Hello, $INPUT_WHO_TO_GREET!"

# 워크플로우 명령어를 사용하여 디버그 메시지 설정 같은 작업을 수행합니다

echo "::notice file=entrypoint.sh,line=7::$GREETING"

# 출력값을 $GITHUB_OUTPUT 파일에 작성합니다

echo "time=GITHUB_OUTPUT"

exit 0

참고
- echo "::notice file=entrypoint.sh,line=7::$GREETING"
  - GitHub Actions 워크플로우 내에서 사용되며, 실행 중인 스크립트의 특정 부분에서 사용자에게 알림을 보내기 위해 사용됨. 이 구문은 GitHub Actions에 의해 해석되어, entrypoint.sh 파일의 7번째 라인에서 생성된 GREETING 변수의 값을 포함하는 알림 메시지를 출력. 이는 디버깅과 로깅을 용이하게 하기 위한 방법 중 하나.
  - 여기서 ::notice는 알림 유형을 지정하고, file=entrypoint.sh,line=7은 알림이 관련된 파일과 줄 번호를 명시. $GREETING은 출력할 메시지를 담고 있는 변수. 이 구문을 사용하면 워크플로우 실행 중에 특정 파일의 지정된 줄에 대한 알림과 함께 사용자 정의 메시지를 로그에 표시할 수 있음.
- $GITHUB_OUTPUT
  - GitHub Actions가 제공하는 환경 변수 중 하나로, 작업의 실행 결과를 저장하는 데 사용. 스크립트나 액션에서 출력 값을 이 파일에 기록하면, 다른 스텝이나 작업에서 이 값을 읽어 사용할 수 있음. 이를 통해 작업 간에 데이터를 전달하고, 동적으로 워크플로우의 행동을 조정할 수 있음.
  - 우리가 설정하는 변수는 아닙니다! $GITHUB_OUTPUT 환경 변수는 GitHub Actions에 의해 자동으로 설정. 작업 내에서 출력 값을 공유하려고 할 때, 이 변수를 사용하여 출력 파일의 경로를 참조할 수 있음. 사용자가 직접 이 환경 변수를 설정할 필요는 없으며, GitHub Actions 워크플로우 내에서 자동으로 관리되고 사용됨.
두번째. action.yml
- 이 action.yml 파일은 “Hello World”라는 GitHub 액션을 설정한다. 이 액션은 특정 인물에게 인사를 하고 그 시각을 기록하는 역할을 한다. 사용자는 ‘who-to-greet’ 입력을 통해 인사할 대상을 지정할 수 있으며, 이는 필수 입력 사항으로 ‘World’가 기본값으로 설정되어 있다. 출력으로는 인사를 한 시간이 반환된다. 액션은 ‘docker’를 사용해 실행되며, ‘Dockerfile’을 기반으로 한 이미지를 빌드하고, 사용자 입력을 인수로 받아 처리한다.

name: Hello, World!  
description: Greet someone and record the time  
author: GitHub Actions

# Define your inputs here.

inputs:  
who-to-greet:  
description: Who to greet  
required: true  
default: World

# Define your outputs here.

outputs:  
time:  
description: The time we greeted you

runs:  
using: docker  
image: Dockerfile  
env:  
INPUT_WHO_TO_GREET: $

runs: using: docker
- GitHub Actions에서 해당 액션이 도커 컨테이너 안에서 실행되어야 함을 의미한다. 이 설정을 통해 액션은 도커 이미지를 기반으로 실행되며, 지정된 Dockerfile이나 도커 이미지를 사용하여 컨테이너 환경을 구성한다. 그리고 이 환경 안에서 작업을 진행한다.
env: INPUT_WHO_TO_GREET: $
- GitHub Actions 워크플로우에서 환경 변수 INPUT_WHO_TO_GREET를 설정하는 데 사용된다. 이때, inputs.who-to-greet에 정의된 입력값으로 환경 변수의 값을 지정한다. 즉, 사용자가 액션에 입력한 ‘who-to-greet’ 값이 INPUT_WHO_TO_GREET 환경 변수로 전달되어, 액션의 실행 도중 해당 값을 사용할 수 있게 한다.
.github/workflows/main.yml

on: [push]

jobs:  
hello_world_job:  
runs-on: ubuntu-latest  
name: A job to say hello  
steps:  
# To use this repository's private action,  
# you must check out the repository  
- name: Checkout  
uses: actions/checkout@v4  
- name: Hello world action step  
uses: ./ # Uses an action in the root directory  
id: hello  
with:  
who-to-greet: 'Mona the Octocat'  
# Use the output from the `hello` step  
- name: Get the output time  
run: echo "The time was $"

참고

Github Action starter Workflow: 일종의 공식 템플릿 모음집 https://github.com/actions/starter-workflows

원티드 프리온보딩 백엔드-Docker-3일차

전체 과정 설명

CI / CD 기초 개념과 아키텍쳐

CI/CD

지속적 통합 (CI)

지속적 전달 (CD - Continuous Delivery)

지속적 배포 (CD - Continuous Deployment)

Github Action 의 동작원리

Github Action 사용하기 실습

Docker와 Github Action 함께 사용하기

추가 실습

Advanced

참고

Further Reading

Docker Compose에서 Flask와 MySQL 연결 문제

원티드 프리온보딩 백엔드-Docker-2일차

원디트 프리온보딩 백엔드-Docker-1일차