에어플로우를 클라우드 서비스에서 사용해보겠다고 시도했다 며칠간 상당히 많은 난관에 부딪혔다. 특히 devops에서 힘든 점은 사용하는 법만 알면, 에러가 났을 때 에러 찾기가 쉽지 않다는 점이다. 짬바로 당장은 어떻게 해결해도 전체적으로 구조를 이해 못 하면 돌아가도 왜 돌아가는지 모르고 안 돌아가면 왜 안 돌아가는지 알 수없는 상황이 벌어진다. 이게 내가 만든 앱이나 작은 단위의 알고리즘을 이용해 파이프라인을 만드는 것과의 차이 아닐까...
회사가 클 수록 devops/파이프라인 설계/분석 업무가 잘 나눠져 있겠지만 대부분은 저 세 단계중 최소 두 개 이상은 하기를 원해서 devops도 회사마다 정도는 다르겠지만 피해갈 수는 없는 것같다.
처음에는 도커와 비슷한 사용법이기 때문에 쿠버네티스를 사용해보기 위해 GKE 에 클러스터를 생성하고 airflow 이미지를 만들어서 설치를 해야하나 생각했다가 → Helm차트를 사용해서 설치 → Cloud composer 사용으로 이르렀다. 당장은 커스터마이징이 많을 수록 삽을 들고 있는 시간이 길어져서 이른 선택이었다. 이마저도 과금이 시작되면서 사용하기 쉽지 않아졌지만..ㅠㅠ
해야할 것과 내가 나아가고자 하는 방향, 금같은 시간에서 우선순위를 잘 정해야 한다...쿠버네티스는 인터넷에 떠도는 자투리를 보다가 그냥 책을 구입했다. 전체적인 구조와 사용법을 차근히 익히는 걸로 하자.
헬름은 쿠버네티스의 패키지 관리자로 오픈 소스 소프트웨어로 공개되어 있다.
사용해본 소감으로는 사람들이 많이 사용하는 툴들을 템플릿화해서 한번에 설치하고 관리할 수 있게 만든 툴로 보였다. 쿠버네티스를 사용하게 되면 helm도 자주 사용하고, 커스터마이징해서 사용할 수 있을 것 같아 살펴봤던 내용들을 간단하게나마 정리해보려 한다.
정리 내용
차트 다운로드
Artifact Hub에서 차트를 검색하고 다운받을 수 있다.
로컬에 저장소 등록 & 확인
# helm repo add [저장소이름] [저장소주소]
helm repo add apache-airflow https://airflow.apache.org
helm repo list
NAME URL
apache-airflow https://airflow.apache.org
airflow-helm https://airflow-helm.github.io/charts
Helm의 차트 구조
저장소에서 받아온 데이터는 계정의 .cache 에 저장된다. 이전에 GKE 클러스터에 airflow를 올리면서 받아온 airflow 차트들에서 airflow-1.4.0.tgz 의 압축을 풀고 구조를 살펴보았다.
~/.cache/helm/repository$ ll
total 340
drwxr-xr-x 3 lucca lucca 4096 2월 5 14:15 ./
drwxr-xr-x 3 lucca lucca 4096 2월 4 01:01 ../
drwxrwxr-x 6 lucca lucca 4096 2월 5 14:15 airflow/
-rw-r--r-- 1 lucca lucca 146472 2월 5 11:18 airflow-1.4.0.tgz
-rw-r--r-- 1 lucca lucca 128917 2월 5 02:30 airflow-8.5.3.tgz
-rw-r--r-- 1 lucca lucca 8 2월 5 01:09 airflow-helm-charts.txt
-rw-r--r-- 1 lucca lucca 31838 2월 5 01:09 airflow-helm-index.yaml
-rw-r--r-- 1 lucca lucca 8 2월 4 01:01 apache-airflow-charts.txt
-rw-r--r-- 1 lucca lucca 13228 2월 4 01:01 apache-airflow-index.yaml
Helm의 파일의 구성 template에 쿠버네티스에 설치할 airflow 설정들이 담겨있음을 확인할 수 있었다. airflow 각 역할(스케줄러, 웹서버, 트리거, 워커 등)에 대한 쿠버네티스 pod, deployment, service yaml파일을 저곳에서 확인할 수 있다.
~/.cache/helm/repository/airflow$ tree -L 2
.
├── CHANGELOG.txt
├── Chart.lock
├── charts
│ └── postgresql
├── Chart.yaml
├── dockerfiles
│ ├── pgbouncer
│ ├── pgbouncer-exporter
│ ├── README.md
│ └── statsd-exporter
├── files
│ └── pod-template-file.kubernetes-helm-yaml
├── INSTALL
├── LICENSE
├── NOTICE
├── README.md
├── templates
│ ├── check-values.yaml
│ ├── cleanup
│ ├── configmaps
│ ├── dags-persistent-volume-claim.yaml
│ ├── flower
│ ├── _helpers.yaml
│ ├── jobs
│ ├── limitrange.yaml
│ ├── logs-persistent-volume-claim.yaml
│ ├── NOTES.txt
│ ├── pgbouncer
│ ├── rbac
│ ├── redis
│ ├── resourcequota.yaml
│ ├── scheduler
│ ├── secrets
│ ├── statsd
│ ├── triggerer
│ ├── webserver
│ └── workers
├── UPDATING.rst
├── values.schema.json
├── values_schema.schema.json
└── values.yaml
Helm의 템플릿은 pod에 설치할 컨테이너와 마운트 설정 등이 모두 적어놓고, 사용자가 커스터마이징할 수 있는 값들은 values.yaml로 빼놓았다. 따라서 사용자는 대부분 values.yaml만 수정하면 된다.
예를 들어 airflow의 스케줄러 배포 템플릿에는 initContainer에 .Values.dags.gitsync.enabled 라는 부분이 보이는데 이 부분의 값을 values.yaml에서 설정해주면 된다.
values.yaml에서 dags 설정부분
dags:
## the airflow dags folder
path: /opt/airflow/dags
## configs for the dags PVC
persistence:
## if a persistent volume is mounted at `dags.path`
enabled: false
## the name of an existing PVC to use
existingClaim: ""
## sub-path under `dags.persistence.existingClaim` to use
subPath: ""
## the name of the StorageClass used by the PVC
storageClass: ""
## the access mode of the PVC
## - [WARNING] must be "ReadOnlyMany" or "ReadWriteMany" otherwise airflow pods will fail to start
accessMode: ReadOnlyMany
## the size of PVC to request
size: 1Gi
gitSync:
## if the git-sync sidecar container is enabled
enabled: false
## the git-sync container image
image:
repository: k8s.gcr.io/git-sync/git-sync
tag: v3.2.2
pullPolicy: IfNotPresent
uid: 65533
gid: 65533
## resource requests/limits for the git-sync container
resources: {}
repo: "https://github.com/ymmu/repo.git"
repoSubPath: "tests/dags"
## the git branch to check out
##
branch: master
내 dag보관용 깃에 git-sync를 맞춘 후에 업데이트가 안 되서 (근데 첫번째 업데이트는 됐다는 게 함정... 처음엔 깃에 새 파일 올리고 한 1분 뒤에 적용되었다. 그 이후로 이유 알아내려고 테스트 반복;;) apache에서 제공한 helm을 뜯어보았다. initcontainer에만 git-sync가 들어가 있고 continers에는 들어가 있지 않아서 helm 유저 커뮤니티가 만든 airflow 차트를 사용했다. 거기엔 initcontainer와 containers에 모두 깃싱크가 들어가 있음. 그러나 쿼터때문에 스케줄러가 실행이 안 됨..또르르
템플릿으로 매니페스트 생성
헬름 템플릿 파일은 IF 구문이나 Range 구문 등도 사용할 수 있어 복잡해지기 쉽고 실제로 적용되는 매니페스트를 예측하기 어려운 경우도 있다. helm install 명령어로 애플리케이션을 배포하면 실제로 적용되는 매니페스트가 예상치 못한 방향으로 적용되는 경우도 있다.
이때 template 명령어를 써서 템플릿에 values.yaml이 적용된 값을 확인할 수 있다.
helm template(install대신) airflow apache-airflow/airflow -f values.yaml --version 1.4.0
# or values.yaml 대신 바로 설정
# --set dags.gitSync.repo="https://github.com/ymmu/airflow_test.git"
# 템플릿에 values.yaml값 적용된 매니페스트 출력
# ...
Helm 아키텍처
helm 클라이언트는 헬름 저장소에서 다운로드한 차트와 values의 조합을 릴리스로 관리하고 쿠버네티스의 시크릿으로 데이터를 저장한다. 그래서 별도 데이터베이스가 필요없다.
#쿠버네티스에서 helm이 생성한 시크릿을 가져오자
kubectl get secret -l owner=helm
# 릴리즈 확인
helm list
# 릴리즈 삭제
helm uninstall airflow
커스텀 차트 생성
- helm에서는 차트라는 단위로 시스템을 패키징한다. 차트 내용은 쿠버네티스의 매니페스트 템플릿과 변수가 메인. 커스텀 시스템을 패키징하려면 신규로 차트를 생성한다. 프로그래밍에서 말하는 프레임워크 프로젝트를 생성하는 작업.
- 기본적으로 롤링 업데이트(파트 인스턴스를 하나씩 업데이트하여 티플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 하는 것)가 가능하도록 디플로이먼트를 사용하여 생성하는 것을 추천하지만 파드 및 레플리카셋에서도 패키지 생성은 가능.
- 차트는 직접 생성해도 좋지만 쿠버네티스 버전 업그레이드에 따라 문법이 바뀔 수 있으므로 helm create로 생성한 차트를 이용하는 것을 권장한다. 한번 생성한 차트는 수동으로 쿠버네티스 문법 변경에 맞춰 수정해야 한다.
- 차트에서 다른 차트를 사용할 수 있는 구조로 되어 있다. 예를 들어 워드프레스 차트는 MARIADB차트를 불러오도록 되어 있고, 그 부분은 requirements.yaml에 정의되어 있다.
helm create sample-charts
# sample-charts가 생성됨
/.cache/helm/repository$ cd sample-charts/ && tree -L 2
.
├── charts
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── hpa.yaml
│ ├── ingress.yaml
│ ├── NOTES.txt
│ ├── serviceaccount.yaml
│ ├── service.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yaml
3 directories, 10 files
패키지 구성
차트 패키지화와 helm 저장소 공개
helm 저장소에서 차트를 제공할 떄는 tgz 형식으로 패키지화해 두어야 한다.
# 생성한 차트 패키지화
# --dependency-update : requirements.yaml 을 사용하여 최신 차트를 포함하는 옵션
helm package --dependency-update ./sample-charts/
저장소를 생성하는 경우, 공개하는 웹 서버 디렉터리에 생성한 패키지 파일을 배치하고 다음 명령어를 실행하면 helm 저장소의 index를 생성할 수 있다. 저장소 생성 후 해당 저장소에 url을 helm repo add 로 등록하여 사용할 수 있다.
helm repo index .
참조
- 쿠버네티스 완벽 가이드, 길벗 p638~
