[Docker/K8S] 웹 서비스를 GKE로 배포하기(1) - Dockerfile 구성, Docker compose로 확인하기

이번에 업무과정에서 썼던 툴들을 정리해보면서 k8s 웹 배포를 작년에 했던 기억을 되살려 다시 공부해보면서 포스팅하기로 했다. 이 포스팅에서는 먼저 필요한 dockerfile 들을 정의하고 로컬 환경에서 정상적으로 동작하는지 테스트해본다.

목표

• GKE(Google Kubernetes Engine)와 GCE(Google Compute Engine) 등을 활용한 풀스택 웹 서비스 배포하기
  1. docker file 구성하기
  2. kubectl 활용하기
  3. 쿠버네티스 구성에 관한 이해 및 적용
     • Deployment
     • StatefulSet
     • Persistent Volume
     • Service
     • Gateway 
     • Networking

해당 포스팅에서 사용된 docker image는 dockerhub에서 pull하실 수 있습니다.
- mysterias/web-service:latest

1. Docker File 구성하기

A. 프론트엔드 / 백엔드 Docker Image 만들기

• 프론트엔드를 별도 프레임워크(React 등) 으로 구성하는 경우에는 이 또한 다른 워크로드로 구성하는 경우가 있지만, 내 웹 서비스의 경우에는 jQuery와 javascript로 간단하게 만들었기 때문에 별도로 나누지 않았다.
• DB는 다른 워크로드로 띄울 것이기 때문에 DB와 백엔드 앱이 연결되는 부분을 환경변수 처리 해서 내부적으로 동작할 수 있도록 해준다. 나는 SQLAlchemy를 사용하여서 `create_engine` 의 url 부분을 나눠서 환경변수 처리를 했다.
• 그리고 처음 FastaAPI 앱 개발 및 테스트를 할 때는 uvicorn을 사용했으나, 서비스를 할 때는 동시 요청이 많아지므로 병렬 처리를 위해 gunicorn으로 동작시키는 것을 docker cmd로 정했다.

# Fastapi Dockerfile
FROM python:3.12

# 먼저 requirements만 복사해서 활용
COPY requirements.txt /app/requirements.txt

# 실행위치 이동
WORKDIR /app

# pip 라이브러리 설치
RUN pip install --upgrade pip && pip install --no-cache -r requirements.txt

# 앱 코드 복사
COPY . /app

# 환경 변수 설정
ENV db_user = user
...

# 포트 설정
EXPOSE 8080

# 실행어
CMD ["gunicorn", "-k", "uvicorn.workers.UvicornWorker", "main:app", "--bind", "0.0.0.0:8080", "--workers", "2", "--timeout", "60", "--sys-log"]

• 나중에 한 번 문제가 생겨서 수정한 부분이 있는데, CMD에서 bind 주소를 반드시 0.0.0.0 으로 해야한다. 처음에 별 생각 없이 localhost로 했었는데, 그러면 추후 kubernetes 위에 올렸을 때 서비스로 외부 노출을 시도해도 외부는 localhost에 포함되지 않으므로 접속이 되지 않는다. 0.0.0.0 은 들어오는 모든 주소를 허용하겠다는 의미이다.
  • 만일 kubenetes 환경에 올리지 않고 로컬에서만 테스트 하거나 서비스할 거라면 상관없다. 그런 경우에는 fastapi 컨테이너를 외부 노출하는 게 아니라 nginx 등 웹 서버를 위에 덮어서 서빙한다.
• 환경변수의 경우 추후 docker compose를 사용해서 테스트 할 것이라 굳이 dockerfile에 추가하지는 않았지만 필요하다면 여기서 넣어도 된다.
• 이렇게 한 후에 dockerfile을 빌드해둔다.

docker build -t web-service:251111 .

• 이러면 251111이라는 tag를 가진 도커 이미지 web-service가 로컬에 저장된다.

 

B. DB Docker Image 만들기

• 현재 내 서비스에서 DB가 필요로 하는 것은 미리 생성되어있는 특정 user(DB owner)와 user에게 할당될 특정한 database 이렇게 두 가지였다.
• kubernetes에 올릴 때는 postgres 공식 이미지를 사용했지만, 로컬 테스트를 위해서는 별도로 이미지를 만들어서 사용했다. 이유에 대해서는 추후에 쿠버네티스를 구성하면서 서술하겠다.
• 만드는 방법은 간단하게 공식이미지에 미리 user와 db를 만드는 sql 파일을 만들어서 entrypoint로 복사해두면 된다. 

// init.sql
DO
$$
BEGIN
    IF NOT EXISTS (SELECT 1 FROM pg_catalog.pg_roles WHERE rolname = 'dain') THEN
        CREATE ROLE dain WITH LOGIN PASSWORD 'password';
    END IF;
END
$$;

SELECT 'CREATE DATABASE monitor OWNER dain'
WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'monitor')\gexec

• 간단히 해설하자면 role name 중에 dain이 없으면 password를 비밀번호로 해서 만들고, database 중에 monitor가 없으면 dain을 owner로 해서 만들어라~ 라는 sql 파일이다.
• 이 init.sql을 복사해서 docker-entrypoint-initdb.d 로 만들어주면 도커가 entrypoint로 인식하고 실행해준다.

# postgreSQL Dockerfile

FROM postgres:15

COPY init.sql /docker-entrypoint-initdb.d
EXPOSE 5432

• 이제 docker build로 이미지를 구워둔다.

docker build -t db_postgres:251111 .

 

2. Docker Compose로 확인하기

A. DB 구성하기

• 만든 두 개의 이미지가 각각의 container로 띄웠을 때 잘 동작하는지를 확인하기 위해서 docker compose를 활용한다. 
• fastapi 앱의 경우 DB와 연결을 시도하는 것이 첫 스텝이므로 fastapi보다 postgreSQL 컨테이너를 먼저 띄워야한다. 
• 구성은 아래와 같다.

services:
  postgresql:
    image: db_postgres:251111
    container_name: postgresql
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres 
    ports: ["5433:5432"]
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U dain -d energy_monitor"]
      interval: 5s
      timeout: 3s
      retries: 10

• 하나씩 뜯어보자. 먼저 image는 아까 우리가 구워뒀던 db_postgres:251111 로 설정했다. tag는 일종의 버전이므로 꼭 알맞은 것을 써주어야한다.
  • 만일 dockerfile만 있고 image를 별도로 만들어두지 않았다면 build 옵션을 추가한다. docker file의 경로를 지정해주어서 docker compose up을 할 때 그 dockerfile을 기반으로 이미지를 빌드해준다.
• container_name은 같은 네트워크 아래에 묶여있는 이 컨테이너의 식별자 같은 것이다. 같은 머신 안에서 돌리는 컨테이너들 끼리는 ip 대신 이 이름으로 서로를 알아볼 수 있다. fastapi쪽을 정의할 때 자세히 다루겠다.
• environment 에는 POSTGRES_USER, POSTGRES_PASSWORD 가 있다. 이것은 마스터 권한을 갖는 user와 password를 정하는 것이므로 적당히 설정해준다.
• ports는 순서대로 [host:내부] 순서다. 외부에서 붙을 거라면 port를 지정해줘야하고, 지금처럼 내부에서만 붙을 거라면 굳이 안 해줘도 된다.
• volumes는 container가 삭제되면 사라지는 데이터를 보존하기 위하여 현재 실행 머신의 저장공간(디렉토리)와 컨테이너 내부 디렉토리를 매핑하는 것이다. /var/lib/postgresql/data 경로에 저장되는 모든 데이터는 실행머신의 pgdata 디렉토리에 저장되는 것과 같다고 생각하면 된다.
  • container에서 가용한 특정한 저장공간 영역과 실제 host machine의 어느 저장공간 영역을 매핑해서 container에서 해당 저장공간에 저장하면 나중에 container를 삭제해도 실제 host machine의 저장공간에 저장한 것이기 때문에 사라지지 않는다. 
  • volume은 container에 미리 할당된 용량을 잡아먹지 않는다. 이미 호스트 머신에 있는 저장공간을 컨테이너가 사용하는 것이다.
• healthcheck는 현재 컨테이너가 내가 설정한대로 잘 구동되었는지를 확인한다.

 

B. Web 서비스 구성하기

• FastAPI를 올리는 쪽도 크게 다르지 않다.

service: 
  postgresql:
    ...
    
  fastapi:
    image: web-service:latest
    container_name: fastapi
    depends_on:
      postgresql:
        condition: service_healthy
    env_file: "docker.env"
    ports: ["8080:8080"]
    restart: on-failure

• 눈에 띄게 다른 점은 depends_on 부분과 env_file 이다. 두 가지만 설명하고 넘어가자.
• depends_on 은 말 그대로 아래 정의한 것에 의존하여 이 컨테이너를 실행한다는 뜻이다. postgresql이라고 컨테이너 이름을 명시했고, 이 컨테이너의 상태(condition)이 service_healthy, 즉 정상 작동할 때만 fastapi 컨테이너를 실패 없이 올릴 수 있다.
  • 여기서 postgresql 이라는 이름으로 container를 확인할 수 있는 이유는 두 컨테이너가 같은 호스트 머신 안에 있고, 같은 네트워크에 묶이기 때문이다.
  • docker compose를 올린 뒤에 docker network ls 를 실행하면 
• env_file 은 환경변수를 선언하는 또다른 방법이다. 환경변수가 많아서 일일히 다 적기 뭐할때, 혹은 내용을 숨겨두고 싶을 때 별도의 파일로 저장해서 불러오도록 할 수 있다.

 

C. 실행하기

• 우선 로컬 환경에 docker desktop이 실행 중이어야한다.
• 실행 방법은 간단하다.

docker compose up

• 만약 이미지를 새로 빌드해야하는 경우에는 build를 하고 up 하면 되고, 백그라운드 실행을 원하면 -d 를 붙이면 된다.

• 실행 후에는 터미널에 이렇게 상태가 올라오고, 각 컨테이너의 이름을 앞에 붙이고 로그가 출력된다. docker desktop에서도 확인할 수 있다.

• 이제 localhost:8080 등으로 접속해서 확인해보면 웹 페이지를 볼 수 있다.

 

 

다음 포스트에서는 kubernetes gke 설정에 관해 이어서 가보도록 하겠다. 슬슬 시행착오^^가 담길 예정이다..