2024 공개SW 개발자대회 복기2 - 플러그인 개발기

플러그인 개발

---

플러그인 개발을 위해 메가존 클라우드 현직자분들이 개발해 놓으신 소스를 참고했다. 정해진 디렉터리 구조가 존재했다.

도움이 많이 되었지만, 개발 기간이 짧은 탓도 있었고, 모두가 이 대회 하나에만 올인할 수 없었던 환경이었기에

Cloudforet의 완전한 구조를 흡수하지 못했던 것에 아쉬움이 남는다.

 

개발한 플러그인 소스

https://github.com/ChainsoMen/plugin-github-inven-collector

GitHub - ChainsoMen/plugin-github-inven-collector: OSS project Cloudforet plugin-github-inven-collector

 

https://github.com/ChainsoMen/plugin-jenkins-inven-collector

GitHub - ChainsoMen/plugin-jenkins-inven-collector: OSS project Cloudforet plugin-jenkins-inven-collector

 

https://github.com/ChainsoMen/plugin-argo-inven-collector

GitHub - ChainsoMen/plugin-argo-inven-collector: OSS project Cloudforet plugin-argo-inven-collector

 

 

참고 소스

https://github.com/cloudforet-io

Cloudforet

 

https://github.com/cloudforet-io/plugin-azure-inven-collector/tree/master/src/plugin

plugin-azure-inven-collector/src/plugin at master · cloudforet-io/plugin-azure-inven-collector

 

 

Github, Jenkins, ArgoCD 세 가지 플러그인을 개발했다.

세 플러그인 모두 다음과 같은 플로우로 진행한다.

1. Cloudforet 에서 확인할 메타데이터를 먼저 정의하고,
2. Connector 에서, 라이브러리를 통해 API 호출하여 데이터를 수집했으며,
3. Manager 에서, 수집한 정보들과 메타데이터를 매핑하여 서비스를 생성하고 데이터를 보여준다.

• Github collector 플러그인은 PyGithub 라이브러리를 사용하여 유저의 Repository 정보들과 Github Actions의 Workflows 내부의 모든 데이터들을 가져오도록 개발했다.
• Jenkins collector 플러그인은 Python Jenkins 라이브러리를 사용하여 빌드 정보, 파이프라인 스크립트의 모든 데이터들을 가져오도록 개발했다.
• ArgoCD collector 플러그인은 Argo Client 라이브러를 사용하여 애플리케이션 데이터들을 가져오도록 개발했다.

Github collector 플러그인은 유저의 깃허브 token만 있으면 되는 반면,

jenkins와 argo 플러그인은 각각 젠킨스 서버, 아르고 서버를 띄워야 했다.

 

깃허브는 몇년 전부터 꾸준히 사용해오고 있었고, 익숙해서 따로 학습하거나 정리하지 않았다.

이번에 대회를 진행하면서 반드시 건드려야 했던 jenkins와 argoCD에 대해서 학습했다.

 

 

 

DevOps Toolchain 학습 및 서버 구축

---

Jenkins 개념

Jenkins는 오픈소스 자동화 서버로, 소프트웨어 개발 과정에서 CI/CD를 지원한다.

Jenkins는 다양한 플러그인과 확장 기능을 통해 빌드, 테스트, 배포 등의 작업을 자동화하여 개발자들이 지속적으로 코드를 통합하고, 품질을 유지할 수 있도록 돕는다.

대부분의 CI/CD 도구가 그렇듯, 코드가 변경되면 Jenkins가 자동으로 빌드를 수행하고, 테스트를 통과한 변경 사항을 배포까지 자동으로 처리할 수 있다.

다양한 소스 코드 저장소(Git, SVN 등)와의 연동이 가능하며, 여러 플러그인을 통해 빌드 툴(Maven, Gradle), 배포 환경(Docker, Kubernetes)과도 쉽게 통합할 수 있다.

Jenkins는 파이프라인 기능을 통해 CI/CD 과정을 코드로 정의하고 관리할 수 있으며, 이를 통해 배포 프로세스의 일관성과 재현성을 보장한다.

오픈소스로 무료이며, 강력한 커뮤니티와 수많은 플러그인 덕분에 다양한 상황에 맞춰 커스터마이징이 가능하다는 장점이 있다.

 

Jenkins 서버 올리기

먼저 시스템 패키지를 최신 상태로 업데이트한다.

sudo apt update && sudo apt upgrade -y

 

자바 설치

Jenkins는 Java가 필요하다. Jenkins의 최신 버전을 설치하기 위해 Java 11 이상을 설치한다.

sudo apt install openjdk-11-jdk -y

 

Jenkins 설치

 

Jenkins는 공식 Repository를 통해 설치한다. 먼저 Jenkins의 GPG 키를 추가한다.

curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo tee /usr/share/keyrings/jenkins-keyring.asc > /dev/null

 

Jenkins 패키지를 위한 repository를 추가한다.

echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null

 

패키지 정보를 갱신하고 Jenkins를 설치한다.

sudo apt update
sudo apt install jenkins -y

 

Jenkins 서비스 시작

 

Jenkins 설치 후 서비스를 시작하고, 부팅 시 자동으로 시작되도록 설정한다.

sudo systemctl start jenkins
sudo systemctl enable jenkins

 

Jenkins 서비스의 상태를 확인한다.

sudo systemctl status jenkins

 

기본적으로 Jenkins는 8080 포트를 사용한다.

 

Jenkins 웹 인터페이스 설정

 

Jenkins는 웹 브라우저를 통해 설정할 수 있다. 기본적으로 http://<서버_IP>:8080에서 접근 가능하다.

 

jenkins 로그인 화면

 

초기 관리자 비밀번호 확인

• Jenkins 설치 후 초기 설정을 위해 관리자 비밀번호를 입력해야 한다.
• 초기 비밀번호는 /var/lib/jenkins/secrets/initialAdminPassword 파일에 저장되어 있다.

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

 

출력된 비밀번호를 복사하여 Jenkins 웹 설정 페이지에 입력한다.

 

 

플러그인 설치 및 사용자 생성

• 초기 설정 화면에서 권장 플러그인을 설치하거나, 필요한 플러그인만 선택하여 설치할 수 있다.
• 이후 관리자 계정을 생성한다.

 

Jenkins 사용하기

 

Jenkins 대시보드에 접근할 수 있고, 새로운 프로젝트를 생성하거나 빌드 파이프라인을 설정할 수 있다.

 

 

 

ArgoCD 개념

기존의 소프트웨어 배포 및 관리 방식은 인프라와 소프트웨어의 불일치를 초래하고, 배포 과정에서 많은 문제가 발생할 수 있었다.

이러한 문제를 해결하기 위해 GitOps가 등장했으며, 이는 Git 저장소를 중심으로 인프라와 소프트웨어를 함께 관리하여 일관성을 유지하고, 변경 내역을 쉽게 추적하고 롤백할 수 있게 한다.

ArgoCD는 Kubernetes 애플리케이션의 자동 배포를 위한 오픈소스 도구로, GitOps를 구현하는 주요 도구다.

Argo는 CI/CD 파이프라인에서 CD(Continuous Deployment) 부분을 담당하며,

Git 저장소의 변경 사항을 감지하여 Kubernetes 클러스터에 자동으로 애플리케이션을 배포한다.

ArgoCD는 선언적 애플리케이션 관리(Declarative Application Management)를 통해 애플리케이션의 원하는 상태를 명시적으로 정의하고, 클러스터의 실제 상태와 비교하여 이를 일치시킨다.

이를 통해 배포 및 관리 과정에서 발생할 수 있는 실수나 오류를 방지하는 것이 목적이다.

 

ArgoCD 동작 과정

Git 리포지토리 설정

• 애플리케이션의 소스 코드, Helm Chart, Kubernetes 매니페스트 파일(예: YAML 파일) 등이 Git 리포지토리에 저장되어 있다.
• Git 리포지토리는 애플리케이션의 Desired State(원하는 상태)를 정의하는 중심 저장소 역할을 한다.

Argo CD 애플리케이션 설정

• Argo CD에서 애플리케이션(App)을 정의하고 Git 리포지토리의 위치를 지정한다.
• 사용자는 Argo CD를 통해 Git 리포지토리에 있는 Helm Chart나 YAML 파일로부터 애플리케이션의 배포 정보를 읽어오도록 설정한다.

Argo CD와 Kubernetes 연결

• Argo CD는 Kubernetes API와 상호작용하여 Kubernetes 클러스터에 접근하고, 현재 상태(Current State)를 모니터링한다.
• 사용자가 Argo CD 웹 UI 또는 CLI를 통해 애플리케이션 배포나 상태 관리를 요청할 수 있다.

GitOps 방식으로 애플리케이션 배포

• Git 리포지토리에 변경사항이 푸시되면, Argo CD는 이러한 변경사항을 감지하고 자동으로 Kubernetes 클러스터에 배포를 수행한다.
• 이때 Helm을 사용하여 배포하는 경우, Helm Chart를 Git에서 가져와 Kubernetes 클러스터에 설치한다.
• Argo CD는 Git에 정의된 Desired State(원하는 상태)와 Kubernetes 클러스터의 Current State(현재 상태)를 지속적으로 비교하여 두 상태를 일치시킨다.

상태 동기화(Synchronization)

• Desired State와 Current State가 다를 경우, Argo CD는 Kubernetes 클러스터의 상태를 자동으로 Desired State와 일치시키기 위해 동기화(Sync)를 수행한다.
• 사용자가 수동으로 배포하거나 설정을 변경할 수도 있지만, Argo CD는 이와 같은 수동 변경 사항이 Git의 정의된 상태와 다를 경우 자동으로 원래 상태로 복구하여 일관성을 유지한다.

ArgoCD의 동작 과정을 학습했을 땐 위와 같았다.

 

 

실제로 구성한 ArgoCD 동작 과정은 다음과 같다.

draw.io로 그린 argoCD 동작

 

먼저 Git에 변경사항을 커밋한다.

Argo CD는 Git 리포지토리를 주기적으로 감시하고,

변경사항이 감지되면 이를 자동으로 동기화(Sync)하여 Kubernetes 클러스터에 배포한다.

Argo CD는 Helm Chart를 사용하여 새로운 애플리케이션 배포 또는 업데이트를 진행하고,

배포 상태와 애플리케이션의 현재 상태를 클러스터와 Git 간에 동기화한다.

 

 

ArgoCD 서버 올리기

먼저 namespace를 생성하고, 공식 홈페이지에서 제공하는 argocd yaml 파일로 설치한다.

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

 

설치를 확인한다

kubectl get po -n argocd

 

초기 비밀번호를 확인하고 변경한다.

kubectl get secret -n argocd argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
여기에 Password가 나올 것이다.

 

argocd-server 파드로 접근하여 로그인

kubectl exec -it -n argocd deployment/argocd-server -- /bin/bash
argocd login localhost:8080

Username: admin
Password: password 입력

 

로그인 했으면 비밀번호를 변경하고,

argocd account update-password

기존 비밀번호 입력: 
새로운 비밀번호 입력: 

 

port forwarding을 걸어준다.

kubectl port-forward --address=0.0.0.0 svc/argocd-server -n argocd 8088:443 &

 

로그인 후 애플리케이션을 등록한다.

ArgoCD Application을 생성하는 법은 구글에 검색하면 많이 나와 있다.

 

 

플러그인 등록

---

개발한 플러그인 등록 과정

각 Repo의 static 파일에서 확인할 수 있다.

 

플러그인을 등록을 위해 필요한 yaml 파일들을 각 플러그인마다 작성했다.

앞서 개발한 github, jenkins, argo collector 플러그인을 등록하기 위해서는 Identity, Inventory, Repository 서비스의 gRPC 엔드포인트가 필요하다.

spacectl config endpoint add identity grpc://localhost:8083
spacectl config endpoint add inventory grpc://localhost:8084
spacectl config endpoint add repository grpc://localhost:8085

 

 

추가된 서비스들의 엔드포인트들 위와 같고, 토큰은 뒤에 훨씬 길게 있으니 보안 위협과는 크게 상관없다.

포트포워딩을 설정하면 로컬 환경에서 각 마이크로서비스로 gRPC 통신을 할 수 있다.

kubectl port-forward svc/identity -n cloudforet 8083:50051 --address=0.0.0.0 &
kubectl port-forward svc/inventory -n cloudforet 8084:50051 --address=0.0.0.0 &
kubectl port-forward svc/repository -n cloudforet 8085:50051 --address=0.0.0.0 &

 

구성된 백그라운드 포트포워딩은 다음과 같다.

ps aux ❘ grep kubectl

 

spacectl api-resources 명령어를 통해 사용할 수 있는 마이크로서비스의 API 목록을 확인할 수 있다.

더 자세한 건 다음 링크에서…

https://cloudforet.io/api-doc/

Cloudforet API Documentation Site

 

포트포워딩 중에 svc/mongoDB가 있다.

MongoDB Compass를 연동했다.

여기서 모든 플러그인 관련 데이터를 확인할 수 있다.

MongoDB Compass

Repository 등록

로컬에서 플러그인을 등록하기 위해 새로운 Repository를 생성한다.

spacectl exec register repository.Repository -f register_repository.yaml

 

Schema 생성

각 플러그인마다 create_schema.yaml 파일을 작성했다.

Schema는 SpaceONE 콘솔에서 Secret Data를 입력할 때 필요한 템플릿을 제공한다.

spacectl exec create repository.Schema -f create_schema.yaml

Schema

Provider 생성

또한 각 플러그인마다 create_provider.yaml 파일을 작성했는데, 이는 Cloudforet에서 서비스 어카운트를 생성할 때 사용되는 메타 데이터를 정의해논 것으로 다음과 같은 명령어를 통해 생성한다.

spacectl exec create identity.Provider -f create_provider.yaml

Provider

 

플러그인 등록

spacectl exec register repository.Plugin -f register_plugin.yaml

 

Dockerfile을 작성하고 빌드하고, 이미지를 DockerHub에 Push

하게 되면, Cloudforet 에서 컬렉터를 생성하고, 수집까지 할 수 있다.

docker build --no-cache -t [dockerhub 사용자명]/plugin-github-inven-collector:1.1.6 .
docker run [dockerhub 사용자명]/plugin-github-inven-collector:1.1.6
docker push [dockerhub 사용자명]/plugin-github-inven-collector:1.1.6

 

docker run은 로컬에서 테스트 하기 위한 용도이므로, 서버에서 직접 테스트할 땐 생략했다.

 

플러그인 테스트

---

개발을 완료한 후, 로컬 테스트 진행

먼저 로컬에서 플러그인 서버 실행시킨 뒤,

spaceone run plugin-server -s src plugin

플러그인 서버 실행

init 으로 초기화를 해주고,

spacectl exec init plugin.Collector -f init.yaml

 

컬렉터 수집 명령어를 통해

spacectl exec collect plugin.Collector -f collect.yaml

데이터를 의도대로 잘 가져오나 확인했다.

 

서버 테스트 진행

로컬에서 먼저 정상적으로 데이터가 수집되는 것을 확인하고, Cloudforet에 접속해서 컬렉터로 수집하고, 대시보드에서 데이터가 수집된 것까지 확인했다.

Github Repository와 관련된 정보들을 전부 가져온다

 

 

Demo 영상 링크

[2024 공개SW 개발자대회 지정과제(기업형)] ChainsoMen 팀 시연 영상