DevOps 실습 - Docker Container 방식

1. 도입

대상: 소프트웨어 개발 경험이 적거나 Docker, Git, CI/CD 개념에 익숙하지 않은 초보자

준비물:

Python (파이썬): 최신 버전 설치 (예: 3.9 이상)
VSCode (비주얼 스튜디오 코드): 텍스트 편집기
Git (깃): 버전 관리를 위한 도구
GitHub (깃허브) 계정: 코드 저장소 및 CI/CD 자동화를 위한 서비스
Docker Desktop (도커 데스크톱): 로컬에서 Docker (도커) 컨테이너를 실행하기 위한 필수 도구
Docker Hub (도커 허브) 계정: Docker 이미지를 저장하고 공유하기 위한 레지스트리

핵심 개념 이해:

개념	설명	고전적 방식 관점 (C++ 비유)	CI/CD 현대화 (본 실습 관점)	입력 (Input)	출력 (Output)
CI/CD	소프트웨어 개발 과정을 자동화하여, 지속적 통합을 통해 코드 변경 사항을 자주 병합하고, 지속적 배포를 통해 언제든 배포 가능한 상태를 유지하는 방법론.	수동적인 빌드, 테스트, 배포	자동화된 워크플로우 및 파이프라인 구축	소스 코드 변경 사항	배포 가능한 소프트웨어, 피드백
Build (빌드)	소스 코드를 실행 가능한 형태로 변환하고, 필요한 자원을 준비하는 과정.	`컴파일(Compile) + 링크(Link)`를 통한 실행 파일 생성	`Dockerfile`로 컨테이너 이미지 빌드	소스 코드 (`.py`, `Dockerfile` 등)	Docker Image, `.html` 문서 등
Test (테스트)	빌드된 소프트웨어 또는 시스템의 기능, 성능, 안정성 등을 검증하여 에러나 버그를 발견하는 과정.	수동 실행, 출력 확인	유닛/통합 테스트 자동화, 워크플로에서 자동 실행	실행 가능한 소프트웨어, 데이터	테스트 결과 (성공/실패, 보고서)
Deploy (배포)	테스트를 통과한 소프트웨어 또는 결과물을 실제 사용자가 접근할 수 있는 운영 환경에 설치하고 실행하는 과정.	수동으로 파일 업로드, 수동 설치	GitHub Actions로 빌드 → 이미지 Push → 서버 Pull/Run	빌드된 최종 결과물 (Docker Image)	운영 환경에 설치된 소프트웨어, 서비스
Publish (공개)	배포된 소프트웨어 또는 문서의 존재를 공식적으로 알리고, 대중 또는 특정 사용자 그룹이 접근하고 사용할 수 있도록 공개하는 과정.	실행 파일 공유	Docker Hub에 이미지 Push → 누구나 Pull/Run 가능	배포된 서비스/문서, 접근 URL	널리 알려진 서비스/문서, 접근 권한 확보

실습 흐름 요약 (단계별):

로컬 개발 & Docker 이미지 생성/테스트:
버전 관리 & GitHub (깃허브) Push (푸시):
CI/CD 자동화 - GitHub Actions (깃허브 액션즈):
Docker (도커) 이미지 배포 및 재현성 확인:

2. 실습 흐름 트리 구조

bash

[1] 로컬 개발 및 Docker 이미지 생성/테스트
 ├─ 목표: 애플리케이션 개발 및 Dockerfile 작성, 로컬 환경에서 Docker 이미지 빌드 및 실행 확인
 ├─ Python + venv + requests + dotenv + os 환경 설정
 ├─ .env 로 API_KEY 설정 및 main.py 에서 실제 API 요청 구현
 ├─ Dockerfile 작성: FROM, WORKDIR, COPY, RUN, ENV, CMD 이해
 ├─ 로컬에서 Docker 이미지 빌드 및 실행 테스트 (docker build, docker run 명령어 사용)

[2] GitHub 저장소에 코드 Push (Git을 통한 버전 관리)
 ├─ 목표: 소스 코드를 GitHub에 공유하고 버전 관리 시작
 ├─ 코드 (main.py, requirements.txt, Dockerfile) 업로드
 ├─ .env 및 venv 폴더 .gitignore에 추가 및 Git 원리 이해

[3] GitHub Actions를 통한 CI/CD 파이프라인 구축
 ├─ 목표: 코드 Push 시 Docker 이미지 자동 빌드 및 (선택적으로) Docker Hub 자동 Push
 ├─ .github/workflows/docker-build-and-push.yml 파일 작성 (워크플로 파일명 명확화)
 ├─ GitHub Actions의 'on', 'jobs', 'steps' 핵심 요소 이해
 ├─ GitHub Secrets (시크릿)을 이용한 Docker Hub 로그인 정보 보안 관리 (매우 중요!)
 ├─ (선택) Docker Hub 자동 Push 워크플로 구성

[4] Docker 이미지 배포 및 재현성 확인
 ├─ 목표: 빌드된 Docker 이미지를 Docker Hub에 공개하고 다른 환경에서 쉽게 실행
 ├─ Docker Hub 저장소에 이미지 Push (수동 또는 GitHub Actions 연동)
 ├─ 다른 환경 (예: 다른 PC, 클라우드 서버)에서 docker pull + docker run으로 실행하여 환경 독립적인 실행 확인

3. 실습 폴더 구조

bash

my_docker_project/
 ├── .github/
 │    └── workflows/
 │         └── docker-build-and-push.yml   # GitHub Actions 워크플로 파일 (파일명 변경 제안)
 ├── venv/                               # 로컬 가상환경 (Git 커밋 제외)
 ├── .env                                # 로컬 환경변수 (Git 커밋 제외)
 ├── .gitignore                          # Git 추적에서 제외할 파일/폴더 지정
 ├── requirements.txt                    # 파이썬 의존성 목록
 ├── main.py                             # 메인 실행 파일 (파이썬 애플리케이션)
 ├── README.md                           # 프로젝트 설명 파일
 ├── Dockerfile                          # Docker 이미지 빌드 지시 파일

4. 핵심 파일들

requirements.txt
.env (⚠️ 주의: 이 파일은 외부에 노출되면 안 됩니다. .gitignore에 반드시 포함!)
main.py
Dockerfile
.gitignore

5. 로컬 Docker (도커) 빌드 & 실행

Dockerfile (도커파일)이 있는 디렉토리로 이동:
Docker (도커) 이미지 빌드:
Docker (도커) 컨테이너 실행:

6. Docker Hub (도커 허브) Push (푸시)

로컬에서 빌드된 Docker (도커) 이미지를 Docker Hub (도커 허브)에 업로드하여 다른 사람들과 공유하거나 다른 환경에서 사용할 수 있도록 합니다.

Docker (도커) 이미지에 태그 지정:
Docker Hub (도커 허브) 로그인:
Docker Hub (도커 허브)로 이미지 푸시:

7. 다른 환경에서 Pull (풀) + Run (실행)

이제 Docker Hub (도커 허브)에 업로드된 이미지를 인터넷 연결만 되어 있다면 어떤 컴퓨터에서도 쉽게 가져와 실행할 수 있습니다. 이는 환경 독립적인 배포의 핵심입니다.

다른 환경 (다른 PC, 클라우드 서버 등)으로 이동하여 이미지 가져오기 (Pull):
가져온 이미지 실행:

8. (선택) GitHub Actions (깃허브 액션즈)를 통한 자동화

코드를 GitHub (깃허브)에 푸시할 때마다 자동으로 Docker (도커) 이미지를 빌드하고 Docker Hub (도커 허브)에 푸시하도록 GitHub Actions (깃허브 액션즈) 워크플로를 설정합니다.

사전 준비 (GitHub Secrets 설정):

GitHub (깃허브) 저장소로 이동합니다.
Settings (설정) 탭으로 이동합니다.
왼쪽 사이드바에서 Secrets and variables (시크릿 및 변수) > Actions (액션즈)를 클릭합니다.
New repository secret (새 저장소 시크릿) 버튼을 클릭하여 다음 두 가지 시크릿을 추가합니다:

GitHub Actions 워크플로 파일 (.github/workflows/docker-build-and-push.yml):

yaml

name: Build and Push Docker Image to Docker Hub # 워크플로의 명확한 이름 지정

on:
  push:
    branches: [ main ] # main 브랜치에 푸시될 때 워크플로 실행
  pull_request:
    branches: [ main ] # main 브랜치로 풀 리퀘스트가 생성/업데이트될 때 워크플로 실행

jobs:
  build_and_push: # 작업(Job) 이름
    runs-on: ubuntu-latest # 작업을 실행할 가상 머신 환경 (최신 Ubuntu Linux)

    steps:
    - name: Checkout code # GitHub 저장소의 코드를 워크플로 환경으로 가져옵니다.
      uses: actions/checkout@v4 # 최신 버전의 액션 사용 권장

    - name: Set up Docker Buildx # Docker Buildx를 설정하여 Docker 이미지 빌드 기능을 확장합니다.
      uses: docker/setup-buildx-action@v3

    - name: Login to Docker Hub # Docker Hub에 로그인합니다.
      uses: docker/login-action@v3
      with:
        username: ${{ secrets.DOCKER_USERNAME }} # GitHub Secrets에서 사용자 이름 가져오기
        password: ${{ secrets.DOCKER_PASSWORD }} # GitHub Secrets에서 비밀번호 가져오기

    - name: Build and push Docker image # Docker 이미지를 빌드하고 Docker Hub로 푸시합니다.
      uses: docker/build-push-action@v5 # 최신 버전의 액션 사용 권장
      with:
        context: . # Dockerfile이 있는 경로 (현재 디렉토리)
        push: true # 이미지를 Docker Hub로 푸시하도록 설정
        tags: ${{ secrets.DOCKER_USERNAME }}/my_docker_project:latest # 빌드된 이미지의 태그 지정 (본인 Docker Hub 사용자 이름 사용)
        # 선택 사항: 이미지 빌드 캐싱을 사용하여 빌드 속도 향상
        cache-from: type=gha # GitHub Actions 캐시 사용
        cache-to: type=gha,mode=max

참고: API Key

API Key (e.g. my_real_api_key)는 실제로 API (Application Programming Interface) 서비스를 제공하는 곳에서 발급해주는 고유한 키를 의미합니다. 즉, 개발하려는 애플리케이션이 특정 외부 서비스(예: 날씨 정보, 지도 데이터, 주식 시세, 인공지능 모델 등)의 기능을 사용하기 위해 필요한 인증 정보입니다.

main.py 예시에서는 https://httpbin.org/get이라는 더미 (dummy) API를 사용하고 있기 때문에, 이 경우에는 실제로 유효한 API 키가 필요하지 않습니다. httpbin.org는 테스트 목적으로 설계된 웹 서비스라, 어떤 값을 넣어도 응답이 옵니다. 하지만 실제 서비스에서는 my_real_api_key가 매우 중요합니다. 다음은 실제 API 키를 얻는 과정에 대한 일반적인 설명입니다.

`my_real_api_key`는 어디서 어떻게 얻나요?

API (Application Programming Interface) 서비스 선택:
서비스 제공자의 개발자 콘솔 (Developer Console) 또는 대시보드 (Dashboard) 접속:
새 프로젝트 (Project) 또는 애플리케이션 (Application) 생성:
API (Application Programming Interface) 활성화 및 키 발급:
키 복사 및 사용:

예시:

Google Maps (구글 맵스) API 키: Google Cloud Platform (구글 클라우드 플랫폼) 콘솔에 접속하여 프로젝트를 생성하고, Google Maps Platform (구글 맵스 플랫폼) API를 활성화하면 API 키를 발급받을 수 있습니다.
OpenAI (오픈AI) API 키: OpenAI 웹사이트에 로그인하여 'API (Application Programming Interface) keys (키)' 섹션에서 새 시크릿 키 (Secret Key)를 생성할 수 있습니다.
공공 데이터 포털 API 키: 대한민국 공공 데이터 포털 (data.go.kr)에서 원하는 공공 데이터를 찾아 활용 신청을 하면 API 키를 발급해줍니다.

`my_real_api_key` 관리의 중요성

API 키는 당신의 애플리케이션이 외부 서비스에 접근할 수 있는 인증서와 같습니다. 이 키가 외부에 노출되면 다음과 같은 문제가 발생할 수 있습니다.

무단 사용 및 과금: 다른 사람이 당신의 API 키를 사용하여 서비스를 무단으로 이용하고, 그 비용이 당신에게 청구될 수 있습니다.
서비스 남용 및 차단: API 사용 정책을 위반하는 대량 요청 등으로 인해 당신의 계정이 서비스 제공자로부터 차단될 수 있습니다.

따라서, my_real_api_key와 같은 민감 정보는 절대 Git (깃) 저장소에 직접 커밋 (commit)해서는 안 됩니다. .env 파일을 사용하여 로컬에서 관리하고, GitHub Actions (깃허브 액션즈)와 같은 CI/CD (지속적 통합/지속적 배포) 환경에서는 GitHub Secrets (깃허브 시크릿)와 같은 보안 기능을 통해 안전하게 주입해야 합니다. 이는 실습 기획서의 8. (선택) GitHub Actions (깃허브 액션즈)를 통한 자동화 섹션에서 강조된 부분입니다.