파일 내용은 다음과 같다.
- version
- x-airflow-common (여러 서비스에서 공유하는 공통 구성을 정의하며 보통 anchor라 하며 YML 파일 블록을 나중에 계승이란 형태로 재사용 가능하게 함.)
- services (postgres, redis, airflow-webserver, scheduler, etc.)
- volumes (postgres-db-volume)
x-aiflow-common은 처음보는데, 좀 더 자세히 살펴보고자 한다.
예시 코드는 다음과 같다.
x-airflow-common:
# 이후 아래 별칭으로 지칭
&airflow-common 별칭
# 이미지이름:-account_name/airflow란 이미지의 버전
image: ${AIRFLOW_IMAGE_NAME:-apache/airflow:2.5.1}
# 환경변수 설정
environment:
# 별칭 지정
&airflow-common-env
AIRFLOW_CORE_EXECUTOR: CeleryExecutor
...
_PIP_ADDITIONAL_REQUIREMENTS: ${_PIP_ADDITIONAL_REQUIREMENTS:-}
# 데이터 저장 - 3개 volume 모두 공유하는 상황 (host volumes)
volumes:
-${AIRFLOW_PROJ_DIR:-}/dags:/opt/airflow/dags
-${AIRFLOW_PROJ_DIR:-}/logs:/opt/airflow/logs
-${AIRFLOW_PROJ_DIR:-}/plugins:/opt/airflow/plugins
user: "${AIRFLOW_UID:-50000}:0"
depends_on:
&airflow-common-depends-on
# redis, postgres 정상 동작하는 경우 대기
redis:
condition: service_healthy
postgres:
condition: service_healthy
# airflow-scheduler 서비스 -> airflow-common사용해 중복되는 환경 어떻게 적용?
airflow-scheduler:
# 앞서 생성한 x-airflow-common 별칭 불러오기
<<: *airflow-common
command: scheduler
healthcheck:
test: ["CMD-SHELL", 'airflow jobs check --job type SchedulerJob --hostname "$${HOSTNAME}"]
interval: 10s
timeout: 10s
retries: 5
restart: always
depends_on:
<<: *airflow-common-depends-on
airflow-init:
condition: service_completed_successfully
🎈 Dag 구현하며 특정 파이썬 모듈 설치 어떻게?
-PIP_ADDITIONAL_REQUIREMENTS: ${_PIP_ADDITIONAL_REQUIREMENTS:- yfinance pandas numpy}
와 같은 방식으로 진행하기!
쿠버네티스란 다수의 클라우드 환경(docker)을 운영 및 관리하는 프로그램이기에 개인 학습이나 실습 환경을 구축하는 것이 상당히 어렵다.
그렇기에 이론적인 개념에 대해 학습을 진행하고자 한다.
그전에 학습했던 docker에 대해 정리하자.✨ docker
docker를 사용하는 이유 : 경량화되어 있고 속도가 빠른 장점이 있다. 또한 SW실행에 있어 타 환경과 분리된 환경에서 실행되므로 충돌이 없고 관리, 유지 보수가 쉬운 장점이 존재한다.
SW를 docker container에서 실행하기 위해선 format을 image로 지정해야 하고 image는 dockerfile(해당 SW)을 빌드함으로써
- Docker image: docker container실행을 위한 format
- Dockerfile: 해당 SW 어떻게 패키징할지 결정하여 IMAGE로 빌드
- Docker container: 복잡한 lifecycle을 가지며 앞선 image 실행
- Docker hub(registry): 여러 docker image를 공유하여 협업, 배포를 위한 저장소
- Docker Compose: 서비스 실행에 있어 다수의 container가 필요한 경우, container간 일관성, 의존성 관리하는 역할 담당 (Top-level key: Services, Networks, Volumes)
❗ docker -> 실제 production 환경 실행 시 유의점
- Docker volumes : host volumes은 보통 개발 시 소스코드를 container내로 바로 마운트, production에서는 named volume 사용 필요(특정 path persistent하도록 유지)
- Docker container : read-only 사용, 문제 발생 시 롤백 용이 (내용 변경 필요하면 실행 중인 컨테이너 수정이 아닌 새로 컨테이너 생성, 자동화 중요(CI/CD))
- 다수의 Container를 서버 1대에서 실행할 경우 문제 발생.
-> 다수의 Host들에서 실행할 필요 존재. (용량문제, Fail-over) : k8s💯 k8s 소개
컨테이너 기반 서비스 배포/스케일링/관리 자동화 기능을 보유한 오픈소스 프레임워크로 클라우드, 물리서버, 가상 서버 위에서 모두 동작하며 주로 docker container를 대상으로 자동화 작업이 진행된다.
또한 다음과 같은 장점도 존재한다.
- 다양한 환경에서 확장성이 좋다. (ML: Kubeflow, CI/CD: Tekton, Serverless: Kubeless)
- 다수 서버에 컨테이너 기반 프로그램(docker container) 실행하고 관리
< k8s 기본 구조 : 마스터 - 노드 >
- k8s는 다수의 클러스터로 구성되고 환경 설정 정보가 저장되는 key/value 스토어로 백업됌.
- master : High Availability(항상 백업이 존재해 서비스 운영에 차질 없도록 함), 클러스터 관리 역할 담당.
- 마스터 내부에서 여러 프로세스들이 동작 (API Server, Scheduler, Controller Manager)
-> API Server (컨테이너로 동작), Scheduler (Pod 생성, 할당), Controller Manager(전체 상황 모니터링, fault tolerance 보장), Master (HA 중요)- Controller runtime 제공
- k8s user가 사용하는 가장 작은 빌딩블록(Pod)로 container 사용 (k8s 사용 시 컨테이너 바로 사용 X, 1 Pod 당 보통 하나의 container로 구성)
- Pod는 호스트 이름을 가지고 있어 네트워크 주소를 가지는 self-contained server
서버 관리 과정에서 겪는 다양한 어려움이 존재하는데 이를 살펴보고자 한다.
1. 관리해야 하는 서버 수가 늘어나는 경우
-> 어느 서버에서 문제가 발생했고 해당 서버 내 어느 서비스가 문제를 일으키는 지 확인하는 과정이 존재한다.
이를 위한 해결방안은 다음과 같다.
문서화 (현 서버 상황에서 문제 발생 시 해결방안 문서화 작업 必)
코드로 처리 (자동화된 스크립트, chef, puppet, ansible, terraform 등) 단, learning curve가 매우 높고 sw 충돌 문제는 해결 X
VM 도입하여 SW 충돌 해결 (단, 전반적으로 리소스가 크고, 특정 VM 벤더나 클라우드에 Lock-in 됌.)
docker 도입해 모든 SW를 docker image로 만들어 container 실행 (단점도 거의 없지만, container수가 늘어나면 k8s로 관리 必)
🎈 추가사항
microservice ?
: 웹 서비스를 다수의 작은 서비스(microservice)들로 구현하는 방식으로 각 microservice는 팀 단위로 원하는 언어/기술로 개발하는 자율성을 가짐.
다수의 container가 존재하는 경우, 다양한 문제 해결을 위한 관리 도구.
기능은 다음과 같다.
1. 한 클러스터 내 다양한 서비스들이 공존 (DB, Web service, Backend)
2. 다양한 기능 제공:
2-1) 배포(이상 감지 시 롤백 처리 기능 가진 container로 배포)
2-2) 스케일링(server utilization 고려해 container 수 유동성 있게 처리)
2-3) 네트워크(서비스가 다수의 컨테이너로 나뉘면서 Load Balancer 필요, 서비스 디스커버리로 서비스 간 서로 쉽게 찾도록 처리)
2-4) 인사이트 (노드/컨테이너 문제 시 해결, logging, analytics 등 기능 제공 및 시각화, 문제 분석 등 서비스 분석 진행)
2-5) etc.
container orchestration의 툴로는 Mesos, Marathon, DEIS 등등이 있지만 대표적인 툴로 k8s가 주로 쓰인다.