
들어가며
이번 글에서는 지난주 kOps기반 gitOps 기술에 대한 스터디에서 배운 내용을 정리하도록 한다.
GitOps는 평소에도 관심 가지고 부서에 도입하고자 했던 기술이었고, 이 내용을 스터디에서 다루게 되어 좋았다. 사용한 OSS(Open Source Software)인 Harbor, Gitlab, ArgoCD는 목적에 따라 개별적으로 프로젝트에 적용해 본 경험이 있었다.
스터디에서 한번에 연계해서 사용해보고 나니 생각보다 난이도가 높지 않고 적용해 볼 만하다 싶었다.
스터디 진행전 간단하게 각 OSS의 소개 및 용도에 대해 간략히히 정리하고 넘어가도록 한다.
Harbor

오픈소스 기반 이미지 레지스트리로써, 다른 SaaS형 이미지 레지스트리와 다르게 Onpremeis와 같은 격리된 환경에서 직접 레지스트리 구축이 가능하다.
CNCF Graduated 프로젝트로써 많은 레퍼런스가 있고 신뢰도가 높은 이미지 레지드스트리 도구라고 할 수 있으며, RBAC(Role Based Access) 기반의 접근 제어, 컨테이너 취약성 검사, 웹 UI, 레지스트리 애플리케이션 등의 다양한 기능을 제공한다.
이미지 업로드시 취약점을 자동으로 확인할 수 있는 기능 또한 제공한다. 스터디에서는 image registry 용도로 사용한다.
최소 하드웨어 스펙: 2CPU, 4 Mem, Disk 40GB
Gitlab

Git 저장소 및 CI/CD, 이슈 추적, 보안성 테스트 등의 기능을 갖춘 웹 기반의 DevOps 플랫폼으로, 관리- 계획 - 생성 - 검증 - 패키지 - 보안 - 배포 - 구성 -모니터링 - 방어 등의 10단계 프로세스를 모두 지원한다. 스터디에서는 private Git 저장소 용도로 사용한다.
최소 하드웨어 스펙: 4CPU, 4 Mem, Disk 40GB
ArgoCD

Argo CD는 kubernetes를 위한 선언적 GitOps CD 툴이다. 특정 git 저장소를 감시하며 Declarative CD 를 수행한다. 스터디에서는 CD 툴 용도로 사용한다.
최소 하드웨어 스펙: 1CPU, 512M, 1GB
이 세가지 툴을 이용하면 다음과 같은 실무를 수행할 수 있다.
Harbor에 저장된 Docker 이미지와, GitLab repository를 Argo CD와 연결한 다음, container 이미지 또는 Git repository 소스코드 변경 시 애플리케이션을 자동으로 배포할 수 있도록 환경을 구성한다. Argo CD는 GUI 환경을 제공하기 때문에 배포의 성공 유무를 확인할 수 있고 로그나 오류 메시지 역시 확인할 수 있다.
스터디에서는 kOps 클러스터에서 Harbor와 Gitlab, Argo CD를 이용하여 GitOps 환경을 실습했다.
클러스터 생성
kops-onclick.yaml을 이용하여 클러스터를 생성했다. 이번 실습에서는 위에 명시된 대로 OSS들이 리소스를 많이 소모하기 때문에 상대적으로 높은 spec의 c5.2xlarge 를 이용하여 Leader, Follow Node를 구축했다.
Kubernetes에서 Harbor와 GitLab 배포 시 SSL 인증서, LoadBalancer와 ExtenrnalDns를 사용할 수 있도록 kOps클러스터 환경 설정에 spec들을 추가해 줬다.
kops edit cluster
-----
spec:
certManager:
enabled: true
awsLoadBalancerController:
enabled: true
externalDns:
provider: external-dns
-----
kops update cluster --yes && echo && sleep 3 && kops rolling-update cluster
(실습 할 때 이 과정을 놓치고 배포를 하니 LB 생성이 되지 않아 살짝 멍했다..)
Harbor 실습
Helm을 이용하여 harbor 설치를 진행했다.
helm repo add harbor https://helm.goharbor.io
helm fetch harbor/harbor --untar
vim ~/harbor/values.yaml
values 파일에서 Ingress 설정은 Route 53에서 구매한 Domain과 alb를 사용하도록 했다. ingress scheme은 internet-facing으로, target-type은 ip로 지정했다. externalDns를 이용하여 externalURL 역시 커스텀하게 설정했다.

Harbor 로그인 후 busybox 이미지를 이용하여 harbor repository에 image를 등록하는 실습도 진행했다. 이때 harbor repository에 프로젝트를 등록하기 위해서는 다음과 같이 Bastion Server에서 harbor login 과정이 필요하다.
docker login harbor.$KOPS_CLUSTER_NAME -u admin -p Harbor12345 #초기 비밀번호
다음으로 이미지를 tagging하고 Push 한다.
docker tag busybox harbor.$KOPS_CLUSTER_NAME/pkos/busybox:0.1
docker tag busybox harbor.$KOPS_CLUSTER_NAME/pkos/busybox:0.1

등록된 이미지가 잘 받아지는지도 확인했다. 정훈님의 책 13장의 deploy.yaml을 이용하여 커스텀하게 등록된 이미지를 받아 파드를 배포하는 과정 역시 실습해 보았다.
curl -s -O https://raw.githubusercontent.com/junghoon2/kube-books/main/ch13/busybox-deploy.yml
sed -i "s|harbor.myweb.io/erp|harbor.$KOPS_CLUSTER_NAME/pkos|g" busybox-deploy.yml
kubectl apply -f busybox-deploy.yml


GitLab 실습
Gitlab 역시 Helm을 이용하여 구축했다. 내부적인 환경설정들은 다르지만 alb, SSL 인증서 등록등 큰 틀에서는 Harbor설치 때와 같았다.
GitLab을 이용하여 개인 계정을 만들고, 프로젝트 생성 및 commit, push를 간단하게 진행해 보았다. Github를 사용할 때와 마찬가지로 private repository clone 및 push를 위해서는 Local에 계정을 등록하고 발급받은 토큰을 통한 인증 형태로 사용해야 한다.
git config --global user.name "devlos"
git config --global user.email "devlos0322@gmail.com"
git clone https://gitlab.$KOPS_CLUSTER_NAME/devlos/test-stg.git
git push
Username for 'https://gitlab.devlos.click': devlos
Password for 'https://devlos@gitlab.devlos.link': <토큰 입력>


Argo CD 실습
Argo CD 설치는 Helm을 통해 했지만, CLB(Classic Load Balancer)를 NodePort에 연결해 주는 형태로 배포했다.
정상적으로 설치가 완료되면 다음과 같이 Argo CD 홈 화면에 접근가능하다.

Argo CD는 다소 직관적이고 깔끔한 GUI 환경을 제공하기 때문에 현재 필자가 사용하는 것과 같이 GUI를 통한 repository, Apllication 등을 쉽게 등록할 수 있다.

실습에서는 CIL 환경을 이용해 처리하기 위해서 Argo CD CLI 툴을 설치하여 사용했다.
curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd
설치가 완료되면 다음과 같이 argocd 커맨드를 이용하여 여러가지 기능을 사용할 수 있다.
# 로그인
argocd login <CLB 주소> --username admin --password <PW>
# repository 등록
argocd repo add https://gitlab.$KOPS_CLUSTER_NAME/devlos/test-stg.git --username devlos --password P@ssw0rd
ArgoCD에 rabbitMQ deploy에 관한 repository를 연결시켜놓은 상태에서 repository의 버전과 다른 형태로 서비스를 배포한 다음, repository의 정보와 실제 배포내용의 sync를 맞춰주는 데모를 실습해 보았다.



과제
과제 1 - Harbor 에 자신만의 아무 이미지나 태그 해서 업로드하고 다운로드해보고, 관련 스샷 올려주세요
docker pull pengbai/docker-supermario
docker images
docker tag pengbai/docker-supermario harbor.$KOPS_CLUSTER_NAME/pkos/super-devlos:0.1



super-devlos.yaml
------
cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
name: mario
labels:
app: mario
spec:
replicas: 1
selector:
matchLabels:
app: mario
template:
metadata:
labels:
app: mario
spec:
containers:
- name: mario
image: harbor.devlos.click/pkos/super-devlos:0.1
---
apiVersion: v1
kind: Service
metadata:
name: mario
spec:
selector:
app: mario
ports:
- port: 80
protocol: TCP
targetPort: 8080
type: NodePort
externalTrafficPolicy: Local
EOF
# 이미지 Pulling 확인
k describe po mario-85b84c9d5d-9x6dw


과제 2 - 자신만의 텍스트 파일을 kops-ec2 로컬에서 Gitlab 에 올려보고, 관련 스샷 올려주세요


git clone https://gitlab.devlos.click/devlos/my-homework.git
echo "2번째 과제를 진행중인 devlos" >> devlos.txt
git add . && git commit -m "initial commit - add devlos.txt"
git push

과제 3 - ArgoCD 챕터인, 책 273페이지의 ‘Gitops 실습: 클러스터 설정 내역 변경과 깃 저장소 자동 반영’을 직접 스스로 실습해보고, 관련 스샷 올려주세요

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: httpd
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
destination:
namespace: httpd
server: https://kubernetes.default.svc
project: default
source:
repoURL: https://gitlab.myweb.io/jerry/test-stg.git
path: 03.httpd
targetRevision: HEAD
directory:
recurse: true
syncPolicy:
syncOptions:
- CreateNamespace=true
automated:
prune: true
---
k apply -f httpd-directory-argo-application.yaml
k get applications
웹 서버 설치 yaml 파일 (automated.prune: true = 깃 저장소 자동 반영)
argocd repo add https:/ /gitlab.devlos.click/devlos/gitops-test.git--username devlos --insecure-skip-server-verification




좋았던 점
GitOps를 개념을 넘어 실무적으로 연계하여 사용해 볼 수 있어서 좋았다. 또한 Argo CD에서 항상 수동으로 선언내용을 업데이트 하지 않고 자동으로 처리가 가능하다는 사실 도 알 수 있게 되었다.
스터디 자료에도 언급되어 있는 것처럼 SSOT(Single Source Of Truth) 관련 문제를 해결할 수 있는 ArgoCD를 좀 더 깊게 이해할 수 있게 되어 좋았다. 필자 혼자서 개발할 때도 서버 배포 시 서비스 이미지 버전과, 로컬에서 테스트하는 이미지 버전기반 yaml 파일을 수동으로 동기화해주는 일이 매우 귀찮았다.
서버와 로컬 중 어느쪽이 최신인지 구분하기 힘든 적도 있었기 때문에 흔적을 뒤적거리며 해결했었다. 이제부터는 ArgoCD와 GitLab을 통한 연계로 이러한 불필요한 시간낭비를 줄이고 좀 더 배포된 Pod들에 대한 신뢰가 생길 것 같다.
힘들었던 점
이번 실습때는 이전에 사용하던 S3 Bucket을 가지고 계속 Cloud Formation을 수행하다가 Leader, Follow Node들이 생성되지 않는 불상사가 발생했었다.
이 부분이 문제가 있다는 사실을 인지하기까지 많은 시간이 흘렀다. 다음번엔 이런 실수 절대 안 할 것 같다!
마치며
이번 글에서는 쿠버네티스 실무 실습 스터디 4주 차에 진행한 내용을 정리해 보았다.
반복된 작업을 계속 수행하는 것은 개발자로써 피해야 할 상황이지만, 도메인 개발도 병행하며 사업을 진행해 가는 중이라 적용하기 쉽지 않았다. 혼자서 공부해서 적용하기 쉽지 않았지만(선구자 분들은 대단하십니다..) 스터디를 통해 이해도가 더욱 높아지며 자신감이 생겼다.
'클라우드 컴퓨팅 & NoSQL > [PKOS] 쿠버네티스 실무 실습 스터디' 카테고리의 다른 글
[6주차] PKOS 쿠버네티스 실무 실습 스터디 (23.02.19) (1) | 2023.02.26 |
---|---|
[5주차] PKOS 쿠버네티스 실무 실습 스터디 (23.02.12) (0) | 2023.02.18 |
[3주차] PKOS 쿠버네티스 실무 실습 스터디 (23.01.29) (0) | 2023.02.04 |
[2주차] PKOS 쿠버네티스 실무 실습 스터디 (23.01.15) (0) | 2023.01.29 |
[1주차] PKOS 쿠버네티스 실무 실습 스터디 (23.01.08) (2) | 2023.01.13 |