이제 OCI 레지스트리에서 도커 이미지를 가져와서 OCI 쿠버네티스 클러스터에 Wercker 파이프라인으로 배포할 차례이다.
이를 위해 사전에 해야 할 일이 있다.
참고 사이트: Adding a Service Account Authentication Token to a Kubeconfig File
앞서 OCI 쿠버네티스 클러스터에 kubectl 명령으로 접근하기 위해서 kubeconfig 파일을 설정했었고, 여기에는 OCI CLI가 자동으로 생성한 해당 유저만 사용할 수 있는 인증 토큰이 포함되어 있다. 이 인증 토큰은 개별 유저가 클러스터에 kubectl이나 쿠버네티스 대쉬보드에 접근할 때 인증하는데 사용이 된다.
그런데 이렇게 자동으로 생성된 인증 토큰은 Wercker, Jenkins같은 CI/CD 툴이나 프로세스를 인증하는데 적절하지 않다. 자동 생성된 인증 토큰으로 CI/CD 툴에 접근을 시도할 때 권한 오류가 나게 된다. 따라서 특정 유저에 국한되지 않은 인증 토큰이 필요하다. 이를 해결하기 위한 방법은 쿠버네티스 서비스 계정을 만들고 클러스터 관리자 권한을 가진 clusterrolebinding에 바인드시키는 것이다. 생성된 서비스 계정은 자신의 인증 토큰을 가지게 되고 CI/CD 툴은 이를 이용해서 클러스터에 접근하게 된다.
참고로 clusterrolebinding에 대해 간략히 설명하자면, 쿠버네티스는 RBAC(Role Based Access Control)로 시스템의 권한을 관리한다. 사용자와 role을 조합하여 사용자에게 권한을 부여하는 방식이다. 이때 Role binding은 role과 사용자를 묶어주는 역할을 수행하고, 지정한 사용자들에 대해 role에 명시된 규칙을 기준으로 권한을 사용할 수 있도록 관리한다.
아래와 같이 서비스 계정과 클러스터 role binding을 생성하고 인증 토큰 값을 얻어와서 kubeconfig 파일에 새로운 유저 정의로 추가하고, 해당 유저가 서비스 계정임을 설정한다.
| [opc@inst-public ~]$ kubectl -n kube-system create serviceaccount kubeconfig-sa serviceaccount/kubeconfig-sa created [opc@inst-public ~]$ kubectl create clusterrolebinding add-on-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:kubeconfig-sa clusterrolebinding.rbac.authorization.k8s.io/add-on-cluster-admin created [opc@inst-public ~]$ TOKENNAME=`kubectl -n kube-system get serviceaccount/kubeconfig-sa -o jsonpath='{.secrets[0].name}'` [opc@inst-public ~]$ TOKEN=`kubectl -n kube-system get secret $TOKENNAME -o jsonpath='{.data.token}'| base64 --decode` [opc@inst-public ~]$ kubectl config set-credentials kubeconfig-sa --token=$TOKEN User "kubeconfig-sa" set. [opc@inst-public ~]$ kubectl config set-context --current --user=kubeconfig-sa Context "context-csgcoleg5rd" modified. |
다음은 OCI 레지스트리에서 도커 이미지를 가져오기 위한 시크릿 파일을 생성해야 한다. 여기서는 “ocirsecret”이라는 이름으로 시크릿 파일을 생성했다. 시크릿 파일에는 앞서 살펴본 대로 OCI 레지스트리에 로그인하기 위한 인증 정보를 담고 있다.
| [opc@inst-public ~]$ kubectl create secret docker-registry ocirsecret --docker-server=iad.ocir.io --docker-username='apackrsct01/oracleidentitycloudservice/young.kyun.jung@sampletest.com' --docker-password='xxxxxxxxxxxxxxxxxxxx' --docker-email='young.kyun.jung@sampletest.com' secret/ocirsecret created [opc@inst-public ~]$ kubectl get secrets NAME TYPE DATA AGE default-token-ngvzw kubernetes.io/service-account-token 3 43h ocirsecret kubernetes.io/dockerconfigjson 1 70s |
OCI 레지스트리에서 이미지를 가져와서 클러스터에 배포를 할 때는 쿠버네티스 매니페스트 파일에 설정된 내용으로 배포를 하게된다. 지금 테스트하고 있는 GitHub 소스에는 “kubernetes_deployment.yml.template”라는 이름의 매니페스트 파일이 있다. 여기에 시크릿 이름, OCI 리포지토리 등의 변수가 있고, 이후 설정된 값이 Wercker로 전달될 것이다.
GitHub로 이동하여 리포지토리로 Fork해 온 소스의 매니페스트 파일을 확인해 본다.
“kubernetes_deployment.yml.template” 파일을 열어보면 맨 아래 부분에 “OKE_IMAGESECRET”라는 환경 변수로 시크릿을 지정하고 있다. 이에 대한 값을 앞서 만든 시크릿명으로 Wercker 어플리케이션에 지정해서 전달해야 한다.
Wercker로 이동하여 앞서 생성한 Wercker 어플리케이션에서 Enviornment 탭을 클릭한다.
Environemt 화면에서 앞서 이미 생성한 환경 변수를 볼 수 있다. 앞서 확인한 시크릿 환경 변수 이름과 생성한 시크릿 이름을 입력하고 “Add”를 클릭하여 저장한다.
- OKE_IMAGESECRET: ocirsecret
Wercker가 배포된 OCI 쿠버네티스 클러스터에 접근하기 위해서는 해당 쿠버네티스 클러스터의 서버 정보와 토큰값과 같은 인증 정보가 필요하다. wercker.yml에 파일에 이에 대한 정의가 기술되게 된다. GitHub 어플리케이션 소스에서 wercker.yml 파일을 열어서 변수를 확인한다.
참고로 wercker.yml 파일 내용에서 deploy-to-kubernetes 부분을 살펴보면, 먼저 디렉토리를 만들어서 쿠버네티스 설정 파일들을 옮긴다. 이 설정 파일들로 kubectl 명령을 실행하여 배포를 수행할 것이다.
그리고 배포에 60초 타임아웃을 설정하여 컨테이너가 성공적으로 시작할 때 까지 60초를 기다린다. 모든 파드가 기동될 때까지 배포 상태를 확인한다. 만일 파드가 배포되지 않고 타임아웃에 도달하면 종료 코드가 리턴되며, 파이프라인은 실패한다. 어플리케이션이 성공적으로 배포된 경우에만 파이프라인이 성공하고, 그렇지 않은 경우는 실패 처리를 한다.
위 wercker.yml 파일에 기술된 변수 OKE_MASTER, OKE_TOKEN은 kubeconfig 파일에서 해당 정보를 가져올 수 있다.
앞에서 살펴본 kubeconfig 파일의 내용을 확인할 수 있는 “kubectl config view” 명령으로는 클러스터의 서버 정보는 얻을 수 있지만 토큰 정보는 나오지 않는다. OCI 쿠버네티스 클러스터를 맨 처음 구성했을 때 생성한 kubeconfig 파일을 직접 열어 확인한다.
| [opc@inst-public ~]$ echo $KUBECONFIG /home/opc/.kube/config [opc@inst-public ~]$ cat /home/opc/.kube/config apiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURqRENDQW5TZ0F3SUJBZ0lVTE5OS0crVFlvNDFPV2krNnpsMFRRai80Njg0d0RRWUpLb1pJaHZjTkFRRUwKQlFBd1hqRUxNQWtHQTFVRUJoTUNWVk14RGpBTUJnTlZCQWdUQlZSbGVHRnpNUTh3RFFZRFZRUUhFd1pCZFhOMAphVzR4RHpBTkJnTlZCQW9UQms5eVlXTnNaVEVNTUFvR0ExVUVDeE1EVDBSWU1ROHdEUVlEVlFRREV3WkxPRk1nClEwRXdIaGNOTWpFd016QXlNRFUwT1RBd1doY05Nall3TXpBeE1EVTBPVEF3V2pCZU1Rc3dDUVlEVlFRR0V3SlYKVXpFT01Bd0dBMVVFQ0JNRlZHVjRZWE14RHpBTkJnTlZCQWNUQmtGMWMzUnBiakVQTUEwR0ExVUVDaE1HVDNKaApZMnhsTVF3d0NnWURWUVFMRXdOUFJGZ3hEekFOQmdOVkJBTVRCa3M0VXlCRFFUQ0NBU0l3RFFZSktvWklodmNOCkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFMWnh1M1lQUElXK1UzdzFFQkVKZURNN3U1ZFV2clVNTFR6NjVEaUkKQTdiVjFXR1djb3ZSTXZYVzVLVjJJZXZBaXFMeHAzMUdmMEdQRnNTQlJSdzF2VGcvVnpjZjJIVlNaMmF6SkZ2QQpEN1FIeEtkcWN1TG1ENTJhUE9tbmxpcGU0di9CMzEzMllPMnVZSndsMzk1Ny8yZ2hQeGZaRjBjVEVCMXpKZU1yCktMRjRQVFVaSW9lUEszbEo4TGFVL3Z2RVYycTdLaTkyUjM4eWlHclRaWEdzVUM4TUd1RjNsMkplTzB2d21sN1EKeDdRNDkxelZnWkpUQ0l5c0dXaWM4UzB3akl0dXRzcHVKelEwcWExSG8zL0xFR28wNTJoNWFxZUlsclQ4QUJPRgpsenM1b2hPakhxYnhaRG1lZVlJalRRVE56SDZkRTRSdThFRitKLzMxN0V3WUpRVUNBd0VBQWFOQ01FQXdEZ1lEClZSMFBBUUgvQkFRREFnRUdNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdIUVlEVlIwT0JCWUVGQnhMRGpGVjhHNU8KQWdhMmg0WGRTemlpRHV1MU1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQ21GYWJPeE5HNjdId3o1Zlo1MG03UAozMDIvcy9vV2VMb2E3UFZzWmh2NVozcFA2SThTdDFoZmlhUXovRGcvdWhlcitmZVNrUWtBdkkvdWY2SzdwM3ZlClpCaTZiT3ZnWUsyMmxkOUdTcXUyLzhkOCt6c0RBRjhRcU5xWXh4WTUrNU02Q2diMTRBb3A2ZnVhcWk2OFFLVFQKR1JnQ0VLMzJSZ3huU05uU1B2Vm4xbmVLZmt2OW5pN1ZhOUh0T0N4Skc4OFRhY2RQdmY3RERSdElQK3ZiM2lDagphVWs1THMxMFk2Y3M0eHdwaDlhWXROUHd4SUxyZ1M0VkErK3lQVnV2bzNIZlFQaEorTzBuUzR5UVBtU2RyVlA3CjFzenI1SDRuTUFCY3RlUzZTODlRYkhhYjJaRzkzQ0ZubE5WMkZQb1ZXUjdSeVdGV1pIc2ZSTEtwazNHSmc2VGwKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo= server: https://147.154.27.43:6443 name: cluster-csgcoleg5rd contexts: - context: cluster: cluster-csgcoleg5rd user: kubeconfig-sa name: context-csgcoleg5rd current-context: context-csgcoleg5rd kind: Config preferences: {} users: - name: kubeconfig-sa user: token: eyJhbGciOiJSUzI1NiIsImtpZCI6IlEzaVdSOHAzOGlwTFdTaEk0bmhVZkxuQmhnOXNEMFVrWXdFV0N0Qk5xVXMifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJrdWJlY29uZmlnLXNhLXRva2VuLXZoY3pnIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Imt1YmVjb25maWctc2EiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJjMzg1OGY0Yi1jOWIzLTRlYjgtYTI2Ni03OTFlMzAxMjQyMTYiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06a3ViZWNvbmZpZy1zYSJ9.Wm9dgKvkwu3CrJiKnUFdCY_6dShAm0iPuj_A4hKBeZVndr8wFkbpUMKnbUPwK2pHp4CX6WRQklKFOR7rZoH-9LrjOWqCwU3goKhPQeXhzZzWdS49y7FLTfTSgF-bdWcxtUYM3oZRQ_vNMF_OpuCLAop35Ilqq7ViICtUprVVdfhUfO9E5xXHIOUTGsFfcHdB4nW8DdvlPgHG64iGIUuYMMudOjUsX54owtntE6LY6uX5NvYz_n2zZy0ECwzrvqOX4e59DMyz0BLmcuG62NRVeWPQTFghH2kYFZO8chwiq891zGalor7C27BEXCfgHjMz0vuLbDAuKtrC5Rdcw1TZCg - name: user-csgcoleg5rd user: exec: apiVersion: client.authentication.k8s.io/v1beta1 |
kubeconfig 파일에서 OKE_MASTER 변수에 지정될 클러스터 서버 정보는 파일 내 “server:”에 해당하는 부분이고, OKE_TOKEN 변수에 지정될 토큰 정보는 파일 내 새로 생성한 토큰값 “token:”에 해당하는 부분이다.
각 변수의 값을 Wercker의 환경 변수로 전달해야 한다. Wercker로 이동하여 앞서 생성한 Wercker 어플리케이션에서 Enviornment 화면에서 아래와 같이 환경 변수를 입력하고 “Add”를 클릭하여 저장한다. OKE_TOKEN 의 경우 Value 입력 후, “Protected”를 클릭하여 값을 마스킹 처리한다.
- OKE_MASTER: kubeconfig 파일의 server 값
- OKE_TOKEN: kubeconfig 파일의 토큰 값
이번 순서는 OCI 쿠버네티스 클러스터에 컨테이너를 배포하기 위해 Wercker 어플리케이션에 “deploy-to-kubernetes”라는 이름으로 워크플로우를 생성할 것이다. “deploy-to-kubernetes”는 지금까지 살펴본 wercker.yml 파일에서 정의된 배포에 대한 정의로서 Wercker 워크플로우의 파이프라인에서 이 이름을 사용할 것이다.
Wercker 어플리케이션에서 Workflows 탭을 클릭하여 해당 화면으로 이동한다.
하단의 “Add new pipeline”을 클릭하여 파이프라인을 생성한다.
파이프라인 이름과 YML 파이프라인 이름에 “deploy-to-kubernetes”를 입력하고 “Create”을 클릭한다.
파이프라인 생성 후, Workflows 탭을 한번 더 클릭한다. Workflow Editor 창이 나타나고, 앞서 수행한 build 오른쪽에 “+”를 클릭하여 새로운 파이프라인 체인을 생성한다.
팝업 창 하단의 Execute pipeline에서 앞서 생성한 파이프라인 “deploy-to-kubernetes”를 선택하고 “Add”를 클릭한다.
이제 워크플로우에 파이프라인을 추가하는 것까지 완료되었다.
이제 OCI 레지스트리에서 가져온 이미지를 OCI 클러스터에 배포할 차례이다. Wercker의 파이프라인은 GitHub의 어플리케이션 소스 파일이 변경이 되면 자동으로 수행이 된다. 여기에서는 GitHub 소스를 변경했을 때 자동으로 배포가 되는 것을 테스트해 볼 것이다.
여기서는 “wercker.yml” 과 “kubernetes_deployment.yml.template” 파일, 두개를 변경할 것이다.
우선 GitHub 어플리케이션에서 wercker.yml 파일을 변경한다. GitHub에서 해당 파일을 클릭한다.
파일 내용 오른쪽 상단의 연필 모양의 아이콘 “Edit this file”을 클릭해서 파일을 편집한다.
배포를 완료하는데 보다 충분한 시간을 보장하기 위해 타임 아웃을 기존 60초에서 300초로 변경하고, 하단의 코멘트 부분에 “change timeout value”라고 입력한다. 그리고 “commit changes”를 클릭하여 소스 변경을 완료한다.
command: patch deployment/get-ip -p '{"spec":{"progressDeadlineSeconds":60}}' ---> command: patch deployment/get-ip -p '{"spec":{"progressDeadlineSeconds":300}}'
두번째로 kubernetes_deployment.yml.template 파일을 열어 위와 같은 방법으로 apiVersion의 값을 “v1beta1”에서 “apps/v1”로 변경한다.
참고 사이트: Significant Changes to the Kubernetes API
apiVersion: extensions/v1beta1 ---> apiVersion: apiVersion: apps/v1
이는 매니페스트 파일에서 디플로이먼트 자원에 대해 선언한 API 버전 “extensions/v1beta1”이 현재 배포한 쿠버네티스 1.8에서는 실행되지 않기 때문에 정식 버전임을 의미하는 “apps/v1”로 변경했다. 하단의 코멘트 부분에 “change value of apiVersion from "extensions/v1beta1 to "apps/v1"라고 입력하고 “commit changes”를 클릭하여 소스 변경을 완료한다.
GitHub 소스 변경에 대한 커밋 후, Wercker로 돌와와서 Runs 탭 화면으로 이동하면 빌드가 자동으로 시작되고 있음을 알 수 있다.
빌드가 정상 완료되면, 뒤이어 배포도 자동으로 진행이 된다.
Runs 탭 화면 아래로 스크롤 해 보면 배포의 각 단계가 성공적으로 완료된 것을 확인할 수 있다. 각 단계를 클릭하면 상세 실행 내역을 볼 수 있다.
배포 완료 후 kubectl 명령으로 확인해 보면 각 하나의 레플리카로 된 파드가 실행 중임을 알 수 있다. 또한 로드밸런서 타입으로 서비스가 만들어져 있다. 로드밸런서는 OCI 로드밸런서를 배포해야 하기 때문에 EXTERNAL-IP가 “<pending> “에서 로드밸런서 IP가 출력되기까지 다소 시간이 소요될 수 있다.
| [opc@inst-public ~]$ kubectl get deploy,po NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/get-ip 1/1 1 1 11m NAME READY STATUS RESTARTS AGE pod/get-ip-8944f86b-s6t67 1/1 Running 0 11m [opc@inst-public ~]$ kubectl get services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE get-ip LoadBalancer 10.96.137.160 129.159.91.48 80:32012/TCP 33m kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2d23h |
OCI 웹 콘솔에서도 로드밸런서가 생성되어 있는 것을 확인할 수 있다.
웹 브라우저로 생성된 서비스의 EXTERNAL-IP로 접속을 해 보면 클라이언트 IP 주소를 출력하고 있다.
글 순서
5. OCI 레지스트리에 이미지 업로드 & 다운로드 설정
여기에 정리한 내용은 오라클 제품을 다루고 있지만, 이는 개인적인 정리 및 테스트 결과일 뿐입니다. 오라클의 공식 문서는 오라클이 제공하는 매뉴얼과 기타 기술문서를 참조하셔야 합니다.
'Cloud > Oracle Cloud Infrastructure' 카테고리의 다른 글
| OCI를 이용한 쿠버네티스, Wercker 쉬운 샘플 - 8. OKE 모니터링 (0) | 2021.03.22 |
|---|---|
| OCI를 이용한 쿠버네티스, Wercker 쉬운 샘플 - 6. Wercker를 이용한 어플리케이션 빌드 (0) | 2021.03.22 |
| OCI를 이용한 쿠버네티스, Wercker 쉬운 샘플 - 5. OCI 레지스트리에 이미지 업로드 & 다운로드 설정 (0) | 2021.03.22 |
| OCI를 이용한 쿠버네티스, Wercker 쉬운 샘플 - 4. OKE 클러스터에 샘플 웹서버 배포 (0) | 2021.03.17 |
| OCI를 이용한 쿠버네티스, Wercker 쉬운 샘플 - 3. OCI 쿠버네티스 배포, 사용 환경 설정 (0) | 2021.03.17 |
