안녕하세요. 오픈소스컨설팅 Playce Cloud팀 임기환입니다. AA/DevOps 관련 업무를 담당하고 있으며 Application Architect를 넘어서 ‘All’ Architect를 꿈꾸고 있습니다.
오픈소스컨설팅에서는 자사 서비스로 Kubernetes 환경을 손쉽게 설치할 수 있는 순수 오픈소스로만 구성된 Playce Kube 2.0을 공개하였습니다. 이를 통해, 많은 분들이 Kubernetes 환경을 구성하는데 도움이 되고 있습니다만, 실제 애플리케이션 서비스를 구동하는데에는 아직 전통적인 배포 방식을 사용하고 있고, 자동화에 어려움이 많이 발생하고 있습니다.
이번 포스트에서는 Playce Kube를 이용하여 애플리케이션 빌드 배포 환경인 CI/CD 환경을 구성하고 샘플 예제를 통해 애플리케이션 배포를 다뤄보도록 하겠습니다.
본 글을 다 이해하게 되면 DevOps의 가장 중요한 기술인 CI/CD에 대해 이해할 수 있으며, 오픈소스 솔루션을 활용하여 에코 시스템을 구축하고 지속적인 빌드/배포가 가능한 파이프라인 사이클을 만들어 개발 생산성을 높일 수 있을 것입니다.
들어가기에 전에…
먼저 Playce Kube가 무엇인지, 설치는 어떻게 하고 사용은 어떻게 해야하는지를 먼저 알아볼 필요가 있는데요. 이는, 저희 팀내의 실력있는 분이 작성한 포스트를 먼저 살펴보고 오도록 하겠습니다.
Playce Kube 2.0 설치 (Ubuntu jammy 22.04)
Playce Kube 2.0 설치 (CentOS 7.8)
Playce Kube 2.0 설치 (Rocky 8.5)
실제 CI/CD Pipeline을 구성하기 전에 계속 말하고 있는 CI/CD는 무엇인지, 파이프라인은 무엇인지, 몇가지 용어에 대해 알아보도록 할게요
CI/CD 란
CI(Continuous Integration)란?
지속적인 통합을 의미합니다.
훌륭한 개발A팀 기능 100개와 개발B팀 기능 100개가 통합 된단다고 상상해보세요.
좋은 기능 200개가 될까요?
S/W 통합은 눈에 보이지 않는 복잡한 일입니다.
자동화된 도구로 자주 Build, Test로 S/W의 높은 품질을 유지해야 합니다.
CD(Continuous Delivery or Continuous Deploy)란?
높은 품질의 S/W를 개발서버, 운영서버에 배포하는 과정을 사람 손으로 한다면 시간, 비용, 실수가 발생합니다. Java Legacy System을 운영하는 조직 중에는 빌드 결과 class파일만 교체하는 경우도 있습니다. (신규 개발인데 이렇게 하고 계신가요? 저희한테 빨리 연락주세요)
엑셀 파일에 class파일 리스트 받고..
자동화된 배포 시스템은 시간, 비용, 실수를 방지하고 팀이 더 빠르게 개발, 빌드, 배포를 할 수 있게 해줍니다.
비즈니스팀, 기획, 디자인, 개발, 운영팀은 자동화된 빌드, 배포 시스템으로 민첩함을 유지하고 서비스를 시장에 높은 품질의 소프트웨어를 출시할 수 있습니다.
지속적 통합/배포가 필요한 이유
자동화된 CI/CD 파이프라인의 이점은 코드 품질 및 신속한 버그 수정과 같은 실질적인 고려 사항부터 사용자에게 적합한 내용을 구축하고 전체 소프트웨어 개발 프로세스를 개선하는 것까지 다양합니다.
DevOps라는 이름 때문에 개발자와 운영 팀에 초점을 맞추고 있는 것으로 느껴질 수도 있지만 CI/CD 파이프라인을 구축하면 전체 직무 팀에 걸쳐 협업 기회가 제공됩니다. 제품 릴리스 단계를 간소화하면 제품이 어떻게 사용될 것인지에 대한 개념을 팀에게 보다 정확하게 알려주고 개별 팀원이 보다 자유롭게 혁신 창출에 집중할 수 있습니다.
Pipeline이란
Pipeline의 사전적 의미는 ‘석유, 천연가스 등 유체의 수송을 위해 만든 관로’입니다. 컴퓨팅 기술에서 Pipeline은 프로세서에서 성능을 높이기 위해서 명령어 처리 과정으로 명령어 처리를 여러 단계로 나누어 단계별로 동시에 수행하여 병렬화를 시키는 것을 말합니다.
CI/CD에서 말하는 Pipeline은 애플리케이션을 만들고 배포함에 있어 일련의 과정들의 관로처럼 나열하여 순차적으로 실행하는 것을 의미합니다.
CI/CD 프로세스
그러면 지속적인 통합/배포를 하기 위해서는 어떠한 프로세스를 가지는지 알아볼텐데요. 일반적으로 다음과 같은 프로세스로 진행됩니다.
- 개발자가 소스를 개발하여 리포지토리에 통합
- 소스코드를 빌드
- 컨테이너에서 구동가능한 이미지 생성
- 단위 테스트 및 코드 정적 분석 등의 테스트
- Kubernetes, VM 등의 플랫폼 환경에 배포
위의 내용을 각각의 Task로 정의하며, 이를 조합하여 Pipeline을 생성하여 CI/CD 프로세스를 완성합니다.
Tekton이란
그러면 우리가 사용할 Tekton은 무엇인지 간략하게 알아보도록 할게요
Tekton은 CI/CD Pipeline을 작성할 수 있는 오픈소스 프로젝트입니다.
Tekton은 기본적으로 yaml 형태로 구성 하므로 다른 Kubernetes CI/CD Tool과도 연동 및 변환이 가능합니다.
Tekton 특징
- 자동화: 자동화된 프로세스는 일관성을 보장하고 오류를 줄여줌
- 재사용: Tekton의 Task는 독립적이어서 여러 Pipeline에서 필요한 Task를 선택적으로 사용이 가능
- 표준화: Kubernetes의 custom resource를 통해 정의
- 확장성: Tekton hub를 통해 Tekton 커뮤니티에서 작성한 여러 task를 사용할 수 있음
Tekton Pipeline
Tekton Pipeline은 task들의 모음입니다.
Pipeline 속 Task들은 순차적으로 실행되게 되며, Task의 RunAfter구문을 통해 이전 Task가 끝난 뒤 다음 Task가 실행되게 할 수 있습니다.
- Task : 실제 수행을 정의하는 리소스 타입으로 여러 step을 정의할 수 있음
- Pipeline: Task의 실행 순서를 정의하는 리소스 타입
- TaskRun: Task를 실행하는 리소스 타입
- PipelineRun: Pipeline을 실행하는 리소스 타입
- Pipeline Resource: TaskRun, PipelineRun에서 참조하는 리소스 타입입니다. Pipeline Resource의 예에는 git이나 docker image등이 있습니다.
Jenkins vs Tekton
CI/CD 를 사용하는 Tool 중에서 가장 많이 사용되고 있는 Jenkins와는 어떤 차이가 있는지 알아 보도록 하겠습니다.
- 현재 가장 많이 사용 되는 Jenkins는 러닝 커브가 낮고 범용성이 높지만 플러그인 관리, 장애 대처, 자격 증명 등의 단점도 존재합니다.
- Tekton은 Kubernetes 환경에서 동작해서 Auto Scaling, Self-Healing, Serverless 등 서버 관리에 이점이 있지만 관련 정보가 적다는 단점이 있습니다.
- Kubernetes를 사용하고 있는 환경을 잘 이해하고 있으며 자신이 직접 Pipeline을 구축할 수 있는 사용자는 Tekton을, 오픈소스로 빠르게 CI/CD를 구축하고 싶은 사용자는 Jenkins를 사용하는 것이 적절합니다.
본격적으로…
개념적인 이야기는 여기서 마무리하고 본격적으로 CI/CD Pipeline을 구성하여 애플리케이션을 배포해 보도록 하겠습니다.
Pipeline을 구성함에 있어 정답은 없습니다. 프로젝트 상황에 맞는 모델을 적용하고 지속적으로 발전해 나가면 그게 바로 정답입니다.
1. 환경 구성
이번 포스트에서는 다음과 같은 환경에서 Pipeline을 작성할 것입니다.
- 외부 네트워크가 가능한 환경
외부 도커 레지스트리(docker.io) 및 JAVA Library 참조(https://registry-1.docker.io)를 위해 외부로 접근가능한 환경이어야 합니다. - Playce Kube 패키지를 통한 Kubernetes 환경 구성
앞서 말씀드린 Playce Kube 포스트를 참고하여 Kubernetes 환경을 구성합니다. - maven으로 package되는 spring boot 프로젝트
프로젝트 생성이 어려우신 분은 VS Code 공식 사이트를 참고하여 작성이 가능합니다.
https://code.visualstudio.com/docs/java/java-spring-boot - 필요 Add-ons 설치하기
본 포스트에서는 다음 Add-ons를 연동하여 Pipeline을 작성합니다.
아래 코드를 참조하여 Add-ons를 설치하며, 앞 서 말씀드린 ‘Playce Kube 2.0 설치’ 관련 포스트를 참고하면 좀 더 자세하게 Add-ons 설치 방법을 확인하실 수 있습니다.
# gitea 설치(소스코드 리포지토리)
[root@deploy-rocky ~]# /playcecloud/playcekube/kube-packages/gitea/install-helm-charts.sh
# harbor 설치(이미지 레지스트리)
[root@deploy-rocky ~]# /playcecloud/playcekube/kube-packages/harbor/install-helm-charts.sh
# tekton 설치(Pipeline 구동)
[root@deploy-rocky ~]# /playcecloud/playcekube/kube-packages/tekton/install-helm-charts.sh 2. 리소스 설정하기
Tekton Pipeline 구성 시 소스 리포지토리, pipelineResource, pvc, secret, ServiceAccount 등이 필요하며 Pipeline 구성 전에 미리 정보를 설정합니다.
2.1. Add-ons 도메인 정보 확인하기
kubectl get ingress -A 명령으로 ingress node에 설치된 Add-ons을 확인합니다.
[root@deploy-rocky ~]# kubectl get ingress -A | grep -v "ADDRESS"
| awk '{ print "curl -o /dev/null -sL -w \"%{http_code} https://"$4"\n\"
--resolve "$4":443:"$5" https://"$4 }' | bash
2.2. Host 설정하기
브라우저 접속을 위해 Worker 노드의 로드 밸런서 주소와 Add-ons의 도메인 주소를 등록합니다.
Linux 계열의 경우 /etc/hosts 파일, Windows 계열의 경우 C:\Windows\System32\drivers\etc\hosts 파일의 내용을 수정합니다.
# Add-ons에 대한 접속 정보 등록
XXX.XXX.XXX.XXX oauth2-proxy.k8s.playce.cloud argo.k8s.playce.cloud gitea.k8s.playce.cloud harbor.k8s.playce.cloud tekton.k8s.playce.cloud keycloak.k8s.playce.cloud2.3. Gitea 소스 리포지토리 생성
준비한 샘플 소스를 리포지토리에 등록합니다. 이미 리포지토리가 있는 경우 접속 정보만 기억하며 2.3. 은 건너갑니다.
gitea web으로 접속하여 로그인을 합니다. (ex. URL: https://gitea.k8s.playce.cloud )
메인화면에서 맨위 + 기호를 눌러 새 저장소를 클릭하여 리포지토리를 생성합니다.
저장소 이름을 입력하고 저장소 만들기를 클릭합니다.
생성한 리포지토리에 git 명령을 통해 샘플 소스를 업로드합니다.
이미지 빌드를 위한 Dockerfile을 생성하여 소스 리포지토리 내에 root 경로에 push 하여 포함합니다.
아래 내용은 기본적인 Java 샘플에 대한 예시이며, 빌드 언어에 따라 baseimage, 실행방법은 변경이 필요합니다.
# Baseimage
FROM openjdk:18-ea-34-jdk
# image label
LABEL version=0.1
# jar copy
COPY target/sample-0.0.1-SNAPSHOT.jar /app/sample-0.0.1-SNAPSHOT.jar
# java run
ENTRYPOINT ["java", "-jar", "/app/sample-0.0.1-SNAPSHOT.jar" ]
docker와 dockerfile에 대한 좀 더 자세한 내용은 아래 포스트를 참고해주세요.
[Container 시리즈] 03. Docker File, Docker Image – 도커파일 및 이미지에 대하여
2.4. PersistentVolumeClaims 추가
Pipeline에서 사용할 volume을 생성합니다. yaml 파일 작성 후 kubectl 명령을 통해 리소스를 추가합니다.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: workspace
namespace: playcekube-dev
spec:
resources:
requests:
storage: 5Gi
accessModes:
- ReadWriteMany
storageClassName: nfs-csi2.5. pipelineResource 추가
위에서 생성한 git 리포지토리 정보 및 실제 컨테이너로 사용할 이미지 정보를 생성합니다.
yaml 파일 작성 후 kubectl 명령을 통해 리소스를 추가합니다.
---
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: maven-sample-demo-source-git
namespace: playcekube-dev
spec:
type: git
params:
- name: url
value: https://gitea.k8s.playce.cloud/gitea-admin/maven-sample.git
- name: revision
value: master
- name: sslVerify
value: "false"
---
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: maven-sample-demo-image
namespace: playcekube-dev
spec:
type: image
params:
- name: url value: harbor.k8s.playce.cloud/library/maven-sample/maven-sample-demo2.6. 계정 정보 추가
git 리포지토리의 접속 정보와 이미지를 저장할 레지스트리(harbor) 정보를 secret으로 추가하며, 이를 ServiceAccount로 등록합니다.(password는 변경해 주세요!)
yaml 파일 작성 후 kubectl 명령을 통해 리소스를 추가합니다.
---
apiVersion: v1
kind: Secret
type: kubernetes.io/basic-auth
metadata:
annotations:
tekton.dev/git-0: https://gitea.k8s.playce.cloud/gitea-admin/maven-sample-demo
name: maven-sample-demo-git-user
namespace: playcekube-dev
stringData:
username: gitea-admin
password: xxxxxxxx
---
apiVersion: v1
kind: Secret
type: kubernetes.io/basic-auth
metadata:
annotations:
tekton.dev/docker-0: https://harbor.k8s.playce.cloud
name: harbor-secret
namespace: playcekube-dev
stringData:
username: admin
password: xxxxxxxx
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: maven-sample-demo-pipe-bot
namespace: playcekube-dev
secrets:
- name: maven-sample-demo-git-user- name: harbor-secret3. Pipeline 생성하기
그러면, 본격적으로 Pipeline을 생성해 보도록 하겠습니다.
CI/CD Pipeline은 ‘소스 다운로드’-‘소스 빌드’-‘이미지 생성’-‘이미지 Push’-‘배포’ 순으로 진행하며 각각을 ClusterTask로 등록합니다.
ClusterTask는 Task와 다르게 namespace의 영향을 받지 않고 글로벌하게 사용할 수 있습니다.
Task는 yaml로 작성하며, kubectl 명령을 통해 리소스를 추가합니다.
- 소스 다운로드 Task
apiVersion: tekton.dev/v1beta1
kind: ClusterTask
metadata:
name: download-git
spec:
workspaces:
- name: workspace
resources:
inputs:
- name: source-git
type: git
params:
- name: appname
type: string
description: application name
default: default
steps:
- image: registry.local.cloud:5000/library/busybox:1.35.0
name: copysrc
script: |
#!/bin/sh
mkdir -p $(workspaces.workspace.path)/$(params.appname)/src
cp -rp $(resources.inputs.source-git.path)/* $(workspaces.workspace.path)/$(params.appname)/src/
workspaces:
- name: workspace - 소스 빌드 Task
apiVersion: tekton.dev/v1beta1
kind: ClusterTask
metadata:
name: build-maven
spec:
workspaces:
- name: workspace
params:
- name: appname
type: string
description: application name
default: default
- name: base-image
type: string
description: java build base image
default: maven:3.8.5-openjdk-18
steps:
- image: $(params.base-image)
name: build-java
script: |
#!/bin/sh
cd $(workspaces.workspace.path)/$(params.appname)/src
mvn clean package -Duser.home=$(workspaces.workspace.path) -DskipTests- 이미지 빌드 빛 push Task
apiVersion: tekton.dev/v1beta1
kind: ClusterTask
metadata:
name: image-build-push
spec:
workspaces:
- name: workspace
resources:
outputs:
- name: result-image
type: image
params:
- name: appname
type: string
description: application name
default: default
- name: base-image
type: string
description: base image
default: ubuntu:latest
- name: private-registry
type: string
description: private registry url
default: registry.local.cloud:5000
- name: dockerfilename
type: string
default: Dockerfile
sidecars:
- image: $(params.private-registry)/library/docker:dind
name: server
securityContext:
privileged: true
env:
- name: DOCKER_TLS_CERTDIR
value: /certs
volumeMounts:
- mountPath: /certs/client
name: dind-certs
- mountPath: /etc/ssl/certs
name: ca-certs
readinessProbe:
periodSeconds: 1
exec:
command: ['ls', '/certs/client/ca.pem']
steps:
- image: $(params.private-registry)/library/docker:latest
name: build
env:
- name: DOCKER_HOST
value: tcp://localhost:2376
- name: DOCKER_TLS_VERIFY
value: '1'
- name: DOCKER_CERT_PATH
value: /certs/client
script: |
#!/usr/bin/env sh
echo "##### image build start"
cd $(workspaces.workspace.path)/$(params.appname)/src
IMAGE_TAG=$(grep "LABEL version" $(params.dockerfilename) | sed "s/.*LABEL version=\(.*\)/\1/g")
docker build -f $(params.dockerfilename) -t $(resources.outputs.result-image.url):${IMAGE_TAG} .
volumeMounts:
- mountPath: /certs/client
name: dind-certs
- image: $(params.private-registry)/library/docker:latest
name: push
env:
- name: DOCKER_HOST
value: tcp://localhost:2376
- name: DOCKER_TLS_VERIFY
value: '1'
- name: DOCKER_CERT_PATH
value: /certs/client
script: |
#!/usr/bin/env sh
echo "##### image push start"
cd $(workspaces.workspace.path)/$(params.appname)/src
IMAGE_TAG=$(grep "LABEL version" $(params.dockerfilename) | sed "s/.*LABEL version=\(.*\)/\1/g")
docker push $(resources.outputs.result-image.url):${IMAGE_TAG}
volumeMounts:
- mountPath: /certs/client
name: dind-certs
volumes:
- name: dind-certs
emptyDir: {}
- name: ca-certs
secret:
secretName: playcekube-rootca- 배포 Task
apiVersion: tekton.dev/v1beta1
kind: ClusterTask
metadata:
name: deploy
spec:
workspaces:
- name: workspace
resources:
inputs:
- name: app-image
type: image
params:
- name: appname
type: string
description: application name
default: default
steps:
- image: bitnami/kubectl
name: deploy
script: |
#!/bin/sh
cd $(workspaces.workspace.path)/$(params.appname)/src
IMAGE_TAG=$(grep "LABEL version" Dockerfile | sed "s/.*LABEL version=\(.*\)/\1/g")
# deployment.yaml create
cat << EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: $(params.appname)
namespace: playcekube-dev
labels:
app.kubernetes.io/name: $(params.appname)
spec:
replicas: 1
selector:
matchLabels:
app.kubernetes.io/name: $(params.appname)
template:
metadata:
labels:
app.kubernetes.io/name: $(params.appname)
spec:
containers:
- name: simple-http
image: $(resources.inputs.app-image.url):${IMAGE_TAG}
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
protocol: TCP
securityContext:
runAsNonRoot: false
runAsUser: 0
EOF
# ingress.yaml create
cat << EOF > ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
labels:
app.kubernetes.io/name: $(params.appname)
name: $(params.appname)
namespace: playcekube-dev
spec:
rules:
- host: $(params.appname).k8s.test.playce.cloud
http:
paths:
- backend:
service:
name: simple
port:
number: 80
path: /
pathType: Prefix
EOF
# service.yaml create
cat << EOF > service.yaml
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/name: $(params.appname)
name: $(params.appname)
namespace: playcekube-dev
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app.kubernetes.io/name: $(params.appname)
type: ClusterIP
EOF
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f ingress.yaml
workspaces:
- name: workspace 4. Pipeline 배포하기
등록된 Task를 조합하여 Pipeline을 생성합니다. Pipeline도 Task와 마찬가지로 yaml로 작성하며, kubectl 명령을 통해 리소스를 추가합니다.
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: sample-pipeline-tekton
namespace: playcekube-dev
spec:
workspaces:
- name: workspace
resources:
- name: source-git
type: git
- name: app-image
type: image
params:
- name: appname
type: string
description: application name
default: sample
- name: private-registry
type: string
description: private registry
default: registry.local.cloud:5000
tasks:
- name: download-git
taskRef:
name: download-git
kind: ClusterTask
workspaces:
- name: workspace
workspace: workspace
resources:
inputs:
- name: source-git
resource: source-git
params:
- name: appname
value: $(params.appname)
- name: source-build
taskRef:
name: build-maven
kind: ClusterTask
runAfter:
- download-git
workspaces:
- name: workspace
workspace: workspace
params:
- name: appname
value: $(params.appname)
- name: image-build-push
taskRef:
name: image-build-push
kind: ClusterTask
runAfter:
- source-build
workspaces:
- name: workspace
workspace: workspace
resources:
outputs:
- name: result-image
resource: app-image
params:
- name: appname
value: $(params.appname)
- name: private-registry
value: $(params.private-registry)
- name: deploy
taskRef:
name: deploy
kind: ClusterTask
runAfter:
- image-build-push
params:
- name: appname
value: $(params.appname)
workspaces:
- name: workspace
workspace: workspace Pipeline을 등록한 후, tkn 모듈을 이용하여 Pipeline을 실행하여 애플리케이션을 배포합니다.
Tekton 대시보드에서도 배포가 가능하지만, 기능이 제한적이며 workspace 설정이 안되서 tkn을 이용하여 배포합니다.
tkn pipeline start sample-pipeline-tekton -n playcekube-dev \
--workspace name=workspace,claimName=workspace \
--param appname=maven-sample \
--param private-registry=registry.local.cloud:5000 \
--resource source-git=maven-sample-demo-source-git \
--resource app-image=maven-sample-demo-image
-s maven-sample-demo-pipe-bot명령을 수행하면 tekton 대시보드를 통해 배포 결과를 확인할 수 있습니다.
Tekton 대시보드에서 [Main]-[PipelineRuns]를 클릭하면 배포 결과과 리스트로 표시됩니다.
배포가 정상적으로 수행 되었다면, 배포 Task에서 설정한 Ingress 도메인을 통해 접속하여 애플리케이션이 정상 동작하는지 확인해 볼 수 있습니다.
마치며…
지금까지 간략하게 Playce Kube CI/CD 환경을 구성하여 Kubernetes 환경에 애플리케이션을 배포해 보았습니다.
Playce Kube CI/CD 를 이용할 경우 몇가지 특장점이 있는데요.
- SW 자유도 부여
- Playce Kube에서 선정한 OSS 외에 타 OSS 대체 가능
- Restful API를 통해 기존 레거시 시스템과 연동 가능
- Pipeline 자동 생성
- 템플릿 제공으로 Pipeline 자동 생성 및 재 사용에 용이
- 다양한 개발 언어에 대한 샘플 제공
- 운영 효율화
- 자동화를 통한 서비스 관리에 용이
- 형상관리 획일화(Naming 및 branch 정책 통일화)를 통한 운영 효율화 증대
- Git-ops를 통한 애플리케이션 설정 파일에 대한 효율적인 이력 관리 제공
오픈소스 환경에서는 기본 아키텍처는 대동소이하나, 실제 운영환경에서 얼마나 잘 사용할 수 있는 환경으로 제공 되느냐가 중요한데 Playce Kube 환경을 이용하면 이러한 문제를 해소할 수 있습니다.
그래서 Playce Kube CI/CD 에서는 몇가지 기술셋을 더 제공하고 있는데요…
- argoCD와 git-ops를 통한 운영관리
- Tekton Trigger를 활용한 Pipeline 자동 배포
- Sonarqube를 이용한 소스 코드 정적분석 수행
- Argo-rollout을 통한 blue/green으로 애플리케이션 배포
해당 기술셋을 Pipeline에 반영하면 지속적 통합/배포에 다가갈 수 있습니다.
해당 기술셋을 적용하는 방법은 다음 포스트에서 만나보실 수 있습니다.
참고자료
Playce Kube 공식 매뉴얼: https://osci.atlassian.net/wiki/spaces/PKV/overview
Kubernetes 공식 매뉴얼: https://kubernetes.io/ko/docs/home/
Tekton 공식 매뉴얼: https://tekton.dev/docs/
오픈소스컨설팅 Playce Cloud 팀에서 근무하고 있는 임기환입니다. All Architect를 목표로 달려갑니다.
