[DevOps] Jenkins를 이용한 CI/CD Pipeline 구축 - Jenkins + Ansible + Kubernetes 와의 연동

 

 

이 내용은 인프런 - Jenkins를 이용한 CI/CD Pipeline 구축 강의를 보고 정리한 내용 입니다.


해당 내용의 Code 내용은 이 곳에서 확인하실 수 있습니다.

 

쿠버네티스 완벽 가이드:입문부터 실제 운용까지 필요한 기술 총망라!

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

 

 

 

🗂 목차

● [DevOps] Jenkins를 이용한 CI/CD Pipeline 구축 - 자동화 도구의 사용
● [DevOps] Jenkins를 이용한 CI/CD Pipeline 구축 - Jenkins + Infrastructure as Code 와의 연동
● [DevOps] Jenkins를 이용한 CI/CD Pipeline 구축 - Jenkins + Ansible + Kubernetes 와의 연동
● [DevOps] Jenkins를 이용한 CI/CD Pipeline 구축 - Advenced Jenkins 사용 ① - Pipeline
● [DevOps] Jenkins를 이용한 CI/CD Pipeline 구축 - Advenced Jenkins 사용 ② - SonarQube
● [DevOps] Jenkins를 이용한 CI/CD Pipeline 구축 - Advenced Jenkins 사용 ③ - Multi Nodes
● [DevOps] Jenkins를 이용한 CI/CD Pipeline 구축 - 상용 클라우드 환경에 배포하기
● [DevOps] Jenkins를 이용한 CI/CD Pipeline 구축 - 부록

 

 

🚀 Jenkins, Ansible, Kubernetes 연동

    🔽  개요

        📦 소개

쿠버네티스 공식 자료

전통적인 방법 즉, 온프레미스 기반에서 배포를 한다는 것은 물리적 Hardware에 OS(운영체제)를 올리고, 그 위에 Application을 올려 사용하는 방식이였어요.

하나의 Application이 자원을 많이 차지하게 되면 다른 Application은 자원을 쓰지 못해 성능이 떨어지는 문제가 있었어요.

이 문제를 해결하기 위해 여러대의 물리 머신을 두고, Application을 각각 배포하는 방식을 쓰기도 했었는데, 비용의 문제와 자원의 확장 문제가 있었어요.


두번째는 가상화 솔루션을 이용하는 방법이 있어요.
대표적으로 VM Ware사의 exsi나, Windows의 Hyper-V 등이 있어요.

가상화의 경우 물리 머신위에 가상화 OS를 올리고, 그 위에 Hypervisor가 올라가게 되는데, 이 기술을 통해 각각의 VM(가상 머신)에 개별 OS를 올리고, Application을 운용할 수 있어요.

그렇기 때문에 한 물리 머신내에 여러 가상 머신은 각각의 독립 자원을 갖을 수 있게 됨으로 각각의 Application들이 사용하는 자원을 통제할 수 있고, 상호 보안도 유지할 수 있게 되었어요.

하지만, 가상화의 경우 물리 서버내에 여러 가상 머신이 올라가게 되면 자원은 줄게 되고, 부하가 커지는 문제가 있어요.


세번째로 Container 가상화 방법이 있어요.
이 방법은 VM과 유사한 방법인데, 각 가상 머신에 대해 격리하는 부분을 좀 더 완화해서 Application 간 운영체제를 서로 공유할 수 있도록 하는 방법이에요.

또한 Container 가상화는 VM방식과 다르게 각 가상머신에 OS가 추가로 설치되는 방식이 아니기 때문에 좀 더 가볍게 운영이 가능하다는 장점이 있어요.

또한 Host Server의 자원을 사용할 수 있기도 해요.


CNCF(Cloud Native Interactive Landscape)

Kubernetes(K8s)는 오픈 소스 기반의 Container화 된 Application(Work load & Service)의 자동 배포, 스케일링 등을 제공하는 관리 Platform이에요.

K8s와 Docker는 엄연히 다른 솔루션이에요.
K8s와 Docker는 상호 대체할 수 없어요.

K8s는 Container 가상화 기술을 이용한 Service, Packaging된 Serivce의 자동 배포, Scaling 작업을 도와주는 도구에요.





K8s의 장/ 단점

장       점	단       점
Container화 된 Application 구동	Source Code 배포 불가, Build 불가
Service Discovery & Load balancing	Application Level Service 지원 없음
Storage orchestration	Logging, Monitoring Solution 지원 없음
자동화된 Roll Out, Roll Back	포괄적 Machine Setting, 유지보수, 관리, 자동 복구 시스템 제공 없음
자동화된 Bin Packing
자동화된 Self-Healing (복구)
Secret & composition Management (구성 관리)

K8s Cluster란?

K8s는 Master Node(각각의 Work Node 관리)와 실제 Container 자체 운영, 스케쥴링을 담당하는 것이 Work Node이고, 이 두가지를 합쳐서 부르는 것이 K8s Cluster에요.

Master Node 안에는 설정 정보(etcd), 사용자 스케쥴 관리(sched), api 등을 처리할 수 있도록 구성이 되어 있어요.

Work Node 안에는 실제로 운영하고자 하는 Container들을 관리하기 위한 pod라는 개념, 이 pod를 운영하기 위한 kubelet이라는 개념이 포함되어 있어요.

 
개발자나, 관리자가 각각의 접근 Tool(UI를 가진 Web Service Tool 혹은 CLI Tool)로 K8s Master Node API에 명령어를 전달하면 API는 자기가 가용할 수 있는 Work Node들에게 개발자나, 관리자가 보낸 명령어를 전달하게 되요.

API가 전달한 명령어는 Cube(K8s) Proxy가 받는 역할을 하는데,  Cube(K8s) Proxy는 Cluster의 각 Work Node에서 실행되고 있는 Network Proxy에요.
즉, K8s에서 Service의 개념으로 보면 좋을 거 같아요.
이 친구는 Network에 유지, 관리를 담당하고 있어요.

Master Node에서 각각 가용할 수 있는 Work Node에 어떤 명령어를 전달하면 사용 가능한 Container를 Pod 형태로 묶어서 사용 가능하는 것이 일반적인 형태에요.

K8s는 사용할 수 있는 최소한의 단위인 Pod라는 형태로 묶어 배포를 하게 되고, 이 Pod안에는 여러 Container가 존재할 수 있어요.

각각의 Work Node는 Container를 운영하기 위한 Container Engine을 가지고 있어야 해요.

Work Node를 단일 Node로 구성할 수도 있지만, 안정적인 Service를 위해 Multi Node를 가지고, K8s Cluster를 구성하는게 좋아요.

Pod안에 포함되어 있는 즉, Work Node안에 포함되어 있는 Service를 확대해서 살펴볼게요.

일단, Service와 Pod 개념이 존재하는데, 이 두 친구는 K8s가 사용할 수 있는 Object 또는 자원(Resource)라고 불리는 개념이고, Service는 각각의 Pod 간에 Data를 주고 받을 수 있도록 Network 관련 작업을 처리하는 친구에요.

Pod는 Container들이 Packaging 되어 있는 최소한의 단위이고, Application들이 묶여 있는 것이라고 보면 될 거 같아요.

 

 

    🔽  설치하기

        📦 Kubernetes 설치

Kubernetes 설치 방법에 대해서는 이 곳에 정리를 해 두었어요.

주니하랑은 CentOS7에 가상화 솔루션을 올리고, 그 곳에 3개의 Guest OS (CentOS 7)을 올려 Study 환경을 만들어 주었습니다.

        📦 Minikube 설치

Minikube는 Test 혹은 개발용으로 사용할 수 있는 가벼운 목적에 Kubernetes에요.

Minikube를 통해 Kubernetes Cluster를 복잡하게 구성하는 것이 아니라, Docker Desktop 등을 이용해서 Sigle Cluster로 구축된 상태에 Kubernetes를 사용할 수 있는 친구에요.

Docker Desktop 설정에서 위와 같이 Enable Kubernetes를 활성화 해 준 뒤 Apply & Restart를 눌러주면 설치가 진행됩니다.

위에 방법은 Mac, Windows에서 이용할 수 있는 방법이고, 혹시나 CentOS와 같은 Linux 환경에서 설치를 하고 싶다면 이 곳을 참고해 주세요.

kubectl get nodes

728x90

Docker Desktop에서 Kubernetes 설정이 완료된 뒤 위의 명령어를 통해 주니하랑 Mac Book에 어떤 Node가 있는지 확인을 해 보았어요.

위와 같이 Minikube를 이용하면 Single Cluster 방식이라고 하였었는데, 이는 Master와 Worcker Node를 한 곳에서 이용한다는 의미에요.

실제 운영 환경에서는 위와 같이 하진 않을거에요.

 

kubectl get pods

kubectl get deployments

kubectl get services

최초 pods에 대한 명령어는 현재 기동중인 pod 목록을 확인하는 명령어에요.
주니하랑은 현재 기동중인 Pod나, deployment Object가 없는 것으로 확인이 되었어요.

    🔽  Kubernetes

        📦 기본 명령어

위와 같이 sample-nginx라는 이름을 가진 사용할 Image를 nginx Image를 사용하겠다고 한 뒤 port를 설정해 주었어요.

이렇게 하면 pod(Kubernetes 최소 단위)가 만들어지는 것을 알 수 있어요.

kubectl get pods

Kubernetes의 pod가 하나 기동중인 것을 확인할 수 있어요.

위에 READY에 숫자가 의미하는 것은 해당 Pod안에 Container 개수 즉, 정상 기동중인 Container가 몇 개인지를 나타내는 것이에요.

일반적으로 한 개의 Pod안에는 하나의 Container를 넣어요.

kubectl describe pods {pod 이름}

위의 명령어를 통해 pod에 대한 상세 정보를 확인할 수 있어요.
해당 pod는 현재 docker-desktop이라는 Wocker Node에 설치가 된 것을 확인할 수 있어요.

또한, Evnets에는 정상 여부를 확인할 수 있어요.


만약 만든 pod를 삭제하고 싶을 때는 아래 명령어를 이용해 주시면 됩니다.

kubectl delete pod/{pod 이름}

 

위와 같이 pod가 제거된 것을 확인할 수 있어요.


Deployment는 우리가 가지고 있는 Pod를 리플리카 세트라고 하여 여러 개의 형태로 스케일 해서 만들거나, 스케쥴링, 히스토리 작업을 할 때 사용할 수 있는 설치 개념이에요.

kubectl create deployment {원하는 deployment 이름} --image={image 이름}

반응형

위와 같이 deployment를 만들어 보았어요.

Deployment도 pod를 배포하는 개념이라고 보면 되는 것이에요.
Pod의 상위 개념으로 배포 단위를 Deployment 감싸서 배포하게 되면 스케일링 작업, 스케쥴 작업 등을 할 때, 훨씬 편하게 작업 할 수 있다는 이점이 있답니다.

kubectl get deployments

위와 같이 Deployment가 제대로 생성이 된 걸 확인할 수 있어요.

kubectl get pods

pod 목록을 조회해 보면 위와 같이 주니하랑이 설정한 이름 뒤에 Random 값이 추가가 된 것을 확인할 수 있어요.
이 말인 즉, 주니하랑이 만든 Deployment는 pod가 하나 묶여 정상적으로 실행되고 있음을 확인할 수 있는 것이에요.

이번에는 해당 Pod를 다시 삭제해 볼게요.

분명히 pod를 삭제했지만, 다시 Pod 목록을 조회했을 때, Pod가 기동 중 인것을 확인할 수 있어요.
현재 기동중인 Pod는 위에서 주니하랑이 삭제한 Pod가 아닌 것은 확실해요.

이것은 Deploymnet로 pod를 묶어 실행할 경우 Deploymnet는 최소 유지 Pod 개수를 계속 유지하려고 하는 성질을 가지고 있기 때문이에요. 

따라서 Pod에 문제가 생기면 Deployment를 만들 때, 제시했던 개수만큼은 무조건 Pod를 유지해준답니다.

kubectl scale deployment {deployment 이름} --replicas={희망 Deployment 개수}

이번에는 Deployment에 대한 Scale 작업을 해 볼게요.
위의 명령어는 Deployment에서 유지하고자 하는 Pod 개수를 하나 더 늘려주는 것이에요.

kubectl get pods

다시 Pod 목록을 확인해보니 Pod가 하나 더 생긴것을 확인할 수 있어요.

 

💡 참고 사항
Pod는 Container라고 말할순 없어요.
왜냐하면 Pod에는 Container가 하나가 들어갈 수도 있고, 여러 개가 들어갈 수도 있기 때문이에요.

 

kubectl get deployments

이번엔 Deployment 목록을 확인해 보았어요.
READY에 1/1이 아닌 2/2라고 표시된 것을 확인할 수 있어요.

이는 2개의 Pod를 유지할 것이고, 2개의 Pod가 정상 작동중이라는 의미에요.

Scaling 작업은 숫자를 늘릴 수도 있지만, 줄일수도 있어요.

위와 같이 Pod 개수가 하나 줄어든 것을 확인할 수 있어요.

kubectl delete deployment.apps/{deployment 이름}

위와 같이 Deployment를 삭제해 줄 수도 있어요.

        📦 Script 만들어 가지고 놀기

이번에는 위에서 공부했던 내용을 Script로 한 방에 만들어서 가지고 노는 방법을 알아볼게요.

GUI 형태인 Text Editor를 통해 작성해도 되지만 주니하랑은 vim을 통해 CLI 형태로 작성을 해보려해요.

sample1.yml

위의 yaml Script는 크게 4가지 Part로 구분이 되어 있는 것이에요.

1. apiVersion
   ∙ 어떤 Object 즉, Pod나, Deployment를 만들 것인지에 따라 달라지겠으나, 일반적으로 Pod, Deployment,
        Service의 경우 apps/v1이라는 이름으로 많이 사용.

2. kind
   ∙ 만들고자 하는 Kubernetes Object 이름 명시.

3. metadata
   ∙ 작성하는 Script의 이름, Labeling 작업
      - Labeling을 해 준다면 자유롭게 Key와 Value 형태로 지정을 하고, 다른 자원에서 현재 만들고 있는 자원을 선택하여
         사용하거나, 어떤 값을 반영할 때 등 사용하기 위해 지정.

4. spec
   ∙ kind 즉, Kubernetes Object 마다 작성법이 달라짐.
      - Pod의 경우 어떤 Container를 쓸 것인지에 대해 정의.
      - Deployment의 경우 Deployment에 필요한 Option 정의.

   ∙ replicas:2 라고 하면 생성하고자 하는 Deployment는 유지하고자 하는 Pod의 개수를 2개로 설정.
   ∙ selector(대상 정의) : 현재 작업하고자 하는 대상에 대해 어떤 Lable에 명시할 것인지 정의.
   ∙ template: 실제 Deployment를 통해 만들고자 하는 Pod 내용 정의.
      - spec: containers: -name: 설치하고자 하는 Container이름 정의 및 사용하고자 하는 Imate 정의.
      - spec: containers: ports: Container가 사용할 Port 지정.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

kubectl apply -f {Script File Name}

위의 명령어를 통해 Script를 기동 시켜 보았어요.

참고로 -f Options은 File이라는 Option이고, Script File 명을 뒤에 적겠다는 의미에요.

현재 주니하랑의 Mac Book에서 기동중인 Kubernetes의 Object 목록들을 출력해 보았어요.

 

 

💡 참고 사항

kubectl get pods -o wide

Pod 정보를 좀 더 자세하게 확인하고 싶다면 위의 명령어를 이용.

Pod에 접속하고자 할 때는 Docker에서 exec -it 명령어를 통해 접근했듯이 비슷한 명령어로 Pod에 접속할 수 있어요.

kubectl exec -it {Pod 이름} -- {사용하고자 하는 Shell}

 

💡 참고 사항
exec -it Option

i : Interactive
t : tty

Keyboard 상에 입력한 값을 Terminal에 전달하기 위해 사용하는 Option

 

 

접속된 Pod의 OS는 Debian 계열의 Linux 인 것을 확인할 수 있어요.

apt-get update

apt를 통해 몇가지 Tool을 내려받기 위해 최신화를 해주었어요.

apt-get install -y curl wget

apt를 통해 curl과 wget을 내려받기 해 주었어요.

해당 Pod에 IP를 확인하고, Nginx가 정상 작동중인지를 curl Tool을 통해 확인해 보았어요.

현재 주니하랑의 Mac Book으로 위의 Pod에 http로 접속을 하게 되면 연결이 되지 않을거에요.
접속을 해보기 위해 위와 같이 Port Forwarding 작업 해주고, Port를 80으로 열어주었어요.

service 목록을 확인해 보니 nginx-deployment가 외부에서는 30127로 내부에서는 80으로 Port Forwarding된 것을 확인 할 수 있어요.

위와 같이 Mac Book 브라우저로 접속할 수 있는 것을 확인할 수 있어요.

Deploymenet를 일단, 삭제해 주었어요.

또한 해당 Service도 삭제해 주었어요.

cicd-devops-deployment.yml

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cicd-deployment
spec:
  selector:
    matchLabels:
      app: cicd-devops-project
  replicas: 2

  template:
    metadata:
      labels:
        app: cicd-devops-project
    spec:
      containers:
      - name: cicd-devops-project
        image: edowon0623/cicd-project-ansible
        imagePullPolicy: Always
        ports:
        - containerPort: 8080

일단! 위와 같이 또 다른 yml File을 만들어 주었어요.

cdcd-devops-service.yml

 

apiVersion: v1
kind: Service
metadata:
  name: cicd-service
  labels:
    app: cicd-devops-project
spec:
  selector:
    app: cicd-devops-project
  type: NodePort
  ports:
    - port: 8080
      targetPort: 8080
      nodePort: 32000

그런 뒤 위와 같이 service Object를 만들어 주었는데, Deployment로 만든 Ansible을 외부에서 이용하게 하기 위함이에요.

위에 Script 중 중요한 부분은 내부 8080 Port를 외부 8080으로 Port Forwarding 하는 부분이에요.

실제 Node에 접속할 때는 32000 Port를 이용하겠다고 추가 해 주었습니다.

ls -al

위 두가지 Script를 작동시켜 보도록 할게요.

kubectl apply -f cicd-devops-deplyment.yml

위와 같이 deployment를 먼저 생성해 주었어요.

만약 READY가 0/2 등과 같이 비정상적 표시가 된다면 Image를 내려받고, Pod를 만드느라 시간이 걸리기 때문이에요.

kubectl get pods

Pod 들이 잘 생겨난 걸 확인할 수 있어요.

kubectl apply -f cicd-devops-service.yml

만약 위와 같이 Error가 발생한다면 yml 들여쓰기나, 오타가 있는지 확인할 필요가 있는 것이에요.

위와 같이 Service Object가 만들어지는 Script를 기동해 주었어요.

kubectl get services

Service Object 목록을 확인해 보았더니 위와 같이 cicd-service가 NodePort Type으로 Port Forwarding까지 완벽하게 된 것을 확인 할 수 있어요.

위와 같이 브라우저를 통해 이 전에 Docker와 Jenkins 연동을 공부하면서 만들어두었던 Docker Image가 정상적으로 잘 받아와 졌고, Container로 잘 동작하는 것을 확인할 수 있어요.

    🔽  Kubernetes와 Ansible

        📦 연동

 

이번 작업은 이 전에 CentOS7에 가상화 CentOS7에 Kubernetes Master를 올린 곳에서 작업을 해보려고 해요.
CentOS7에 Kubernetes를 설치하는 방법은 이 곳에 정성스럽게 준비해 두었어요.

 

이번에는 이 전 시간에 공부 했던 Ansible을 이용해서 Kubernetes에 접속한 뒤 Playbook을 이용하는 방법에 대해 공부해 보려고 해요.

 

Jenkins를 통해 Ansible에 ssh를 이용하여 Ansible의 Playbook이 동작하는 명령어를 전달하고, 해당 Playbook을 이용하여 Kubernetes Cluster에 명령어를 전달해 보려고 해요.

혹은 Jenkins에서 바로 Kubernetes 명령어를 이용해서 Cluster에 명령어를 전달할 수도 있어요.

 
먼저 주니하랑은 Ansible Server에서 k8s-master Server로 ssh 접속 Test를 진행해 보았어요.

참고로 현재 Ansible은 주니하랑의 Synology NAS Docker로 구성되어 있고, Kubernetes Master Server는 Laptop에 CentOS7을 올리고, 그 안에 가상 머신으로 CentOS7을 다시 올려서 구성을 해 놨기 때문에 VPN을 통해 통신이 가능하도록 구성을 하고 진행하고 있어요.

Ansible Server에 Root Directory에서 K8s라는 Directory를 만들어 주었어요.

vim ~/k8s/hosts

k8s Directory에 hosts라는 File을 만들어주고, 위와 같이 K8s-master 정보를 정의해 주었어요.

ssh-keygen

 

ssh-copy-id {계정이름}@{Server IP}

 

이번에는 Ansible Server에서 k8s로 편리하게 접속하기 위해 SSH 공개키를 만들어서 전달해 주었어요.-

 

ansible -i ~/k8s/hosts kubernetes -m ping

 

Ansible hosts로 등록한 Kubernetes Group에 Kuberntest Master Node에 Ping Test를 진행해 보았어요.

vim ~/k8s-cicd-deployment-playbook.yml

 

- name: Create pods using deployment 
  hosts: kubernetes 
  # become: true
  # user: ubuntu
 
  tasks: 
  - name: create a deployment
    command: kubectl apply -f cicd-devops-deployment.yml

먼저 Ansible Server에서 Kubernetes 동작을 정의할 Playbook Script를 위와 같이 만들어주었어요.

 

위에서 만든 hosts File에 정의된 kubernetes Group에 등록된 Server에게 cicd-devops-deployment 라는 yaml Script를 기동하도록 만든 Script에요.

vim ~/cicd-devops-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cicd-deployment

spec:
  selector:
    matchLabels:
      app: cicd-devops-project

  replicas: 2

  template:
    metadata:
      labels:
        app: cicd-devops-project

    spec:
      containers:
      - name: cicd-devops-project
        image: junyharang/cicd-project-ansible
        imagePullPolicy: Always
        ports:
        - containerPort: 8080

이번에는 Kubernetes Master Server에 Deployment를 생성하는 yml Script를 만들어 주었어요.

ansible-playbook -i ~/k8s/hosts k8s-cicd-deployment-playbook.yml

위와 같이 playbook Script를 기동시켜 주니 정상적으로 작업이 되었다고 나왔어요.

 

kubectl get all

Kubernetes Master Server에서 Pod와 Deployment 목록을 조회해 보니 위와 같이 pod 2개가 만들어진 걸 확인할 수 있어요.

vim ~/k8s-cicd-service-playbook.yml

 

이번에는 Kubernetes Service Object를 만들 playbook Script를 위와 같이 만들어 주었어요.

vim ~/cicd-devops-service.yml

Kubernetes Server에서 위와 같이 Service Object에 대한 Script를 만들어 주었어요.

kubectl get service

 

위의 Script를 기동하기 전 Kubernetes Master Server에서 Service 목록을 조회해 보았어요.

ansible-playbook -i ~/k8s/hosts k8s-cicd-service-playbook.yml

Ansible Server에서 Service Object 관련 Script를 기동시켜 주었어요.

kubectl get service

 

Kubernetes Master Server에서 Service 목록을 다시 조회해 보니 위와 같이 cicd-service라는 것이 생긴 것을 확인할 수 있어요.

위와 같이 브라우저를 통해서도 접속되는 것을 확인할 수 있어요.

 

    🔽  Kubernetes와 Jenkins

        📦 연동

주니하랑은 Kubernetes와 Ansible 연동에서 이 전에 CentOS 7에 가상화로 CentOS7을 올리고, 그 곳에 만들었던 Kubernetes Master를 이용했었는데, 이번에는 주니하랑의 Mac Book에서 Docker Desktop을 통해 MiniKube를 이용한 방식으로 작업을 해보도록 할게요.

이번에는 Ansible을 이용하지 않고, Jenkins에서 바로 Kubernetes 제어가 가능한지 공부해보려고 해요.

 

작업을 시작하기 전 위에서 진행해서 만들어진 내용은 모두 삭제를 해 주었어요.

Jenkins 관리 -> 시스템 설정

 

SSH Server -> 추가

위와 같이 Jenkins 시스템 설정에서 SSH Server를 하나 더 추가해 줄게요.
이 곳에서 Kubernetes Master에 대한 정보를 기입해 줄 것이에요.

주니하랑은 Mac Book에 Minikube를 구성하였고, 이것을 통해 Test를 할 것이에요.
그래서 username은 주니하랑이 Mac Book Login 시에 사용하는 계정을 입력해 주었고, Mac Book의 IP를 Hostname에 입력해 주었어요.

Remote Directory는 현재 주니하랑이 Mac Book에서 관련 작업을 처리하는 Directory로 지정해주었어요.

여기까지 완성 되었으면 '고급'을 눌러줍니다.

user password ...

위의 use password ... Check Box를 활성화 한 뒤 Password에 주니하랑 Mac Book 계정인 junyss의 비밀번호를 입력해 주었어요.

Port는 Minikube가 설치된 PC의 ssh Port 번호 혹은 Kubernetes Master ssh Port 번호를 입력해 주고, Test Configuration Button을 눌러 Success가 뜨는지 확인해 줍니다.


Apply를 누르고, Save를 눌러 해당 창을 빠져나왔어요.


이번엔 Item을 하나 만들어 볼게요.

Item 이름을 설정하고, 이 전에 작업했었던 Ansible 설정을 그대로 가져오기 위해 위와 같이 한 뒤 'OK'를 눌러주었어요.

빌드 후 조치

 

빌드 후 조치에서 SSH Publishers에 SSH Server를 위에서 설정했던 mac-minikube로 선택을 해 주었어요.

 

아직 Github에 있는 코드를 쓸 것은 아니라서 Source files에 설정은 크게 중요하지 않은 것이에요.

Minikube가 설치된 Mac Book에 작업 Directory Path를 절대 경로로 Remote directory에 적어주고,

Exec command에 kubectl을 이용해서 Script가 작동되게 해 주었어요.

명령어에서 Kubectl 명령어가 위치한 절대 경로를 입력해 주었는데, Mac Book, Windows 를 통한 Minikube 사용시에는 저렇게 하지 않으면 Error가 발생할 수 있기 때문에 절대 경로로 적어주는 것이 좋아요.

💡 참고 사항

Mac OS kubectl 위치 

Build가 성공적으로 처리 되었어요.

 

kubectl get all

Minikube가 설치된 Mac Book에서 확인해보니 위와 같이 Pod와 Deployment가 만들어진 것을 확인할 수 있어요.

이번에는 Jenkins와 Ansible 그리고, Kubernetes 모두를 이용하는 작업을 해 볼게요.
최초 Item 하나를 만들어줄게요.

 

이번에는 빌드 후 조치에서 위와 같이 이 전에 만들었던 ansible-host를 선택해 주었어요.

Exec command 부분에는 play book을 기동하는 명령어를 작성해 주었는데, -u Option은 대상 Server 여기서는 주니하랑의 Mac Book이고, 해당 Server에 계정을 입력해 주면 되요.

만약 root라면 생략 가능합니다.

Apply를 누른 뒤 저장을 해서 해당 창을 나와줄게요.
그런 뒤 Build 작업을 해 주었어요.

 

작업이 실패 하였어요.

 

이 문제는 Ansible Server의 IP가 바뀌어서 발생된 문제에요. 위의 터미널에서 ifconfig를 하였을 때, eth0의 IP가 172.17.0.5이지만, Jenkins에 설정된 IP 주소는 172.17.0.6인 것을 확인 할 수 있어요.

Jenkins에 설정 IP를 5로 바꾸어 줄게요.

변경 뒤 Test까지 정상적으로 처리가 되었어요.

추가적으로 service Object 작업에 대한 Script 명령어를 위와 같이 생성해 주었어요.

        📦 전체 CI/CD 자동화 Process 구성

CI(Continuous Integration)는 지속적인 통합이라는 뜻으로 형상 관리 솔루션에 우리가 만든 Code를 Push 즉, 올리게 되면 환경에 맞추어 Build를 하면서 필요에 따라 Unit Test(단위 테스트)를 하게 될 것이고, 이상이 없다면 Packaging File을 만들게 될 것이에요.

그런 뒤 배포하고자 하는 Server에 배포를 하게 될 것이에요.

여기까지 작업을 CI라고 부르는 것이에요.

CD(Continuous Delivery & Continouos Deployment)은 지속적 배포

    🔽  Jenkins를 이용한 CI/CD 자동화 파이프라인 구축

        📦 첫번째 이야기

 

- hosts: all
#   become: true

  tasks:
  - name: create a docker image with deployed war file
    command: docker build -t junyharang/cicd-project-ansible .
    args:
        chdir: /root

  - name: push the image on Docker Hub
    command: docker push junyharang/cicd-project-ansible
    ignore_erros: yes

  - name: remove the docker image from the ansible server
    command: docker rmi junyharang/cicd-project-ansible
    ignore_errors: yes

최초 이 전에 Ansible에서 만들어 두었던 Docker image를 생성하는 Script를 이용할 것이에요.

수정 전

 

수정 후

또한 이 전에 만들어 두었던 Dockerfile을 이용할 것인데, 여기에서 주니하랑은 tomcat이 아닌 Nginx를 이용하도록 수정을 해 주었어요.

 

현재 주니하랑 Mac Book에서 기동중인 pod와 deployment를 확인해 주었고, 모두 삭제를 해 주었어요.

Jenkins에서 위와 같이 Item을 하나 생성해 주었어요.

수정한 부분은 Exec command 부분인데, image를 만드는 Script를 실행되게 하고, 오직 Ansible Server에서만 작동되게 명령어를 입력해 주었어요.


저장하고 해당 창을 나가준 뒤 Build를 진행해 보았어요.

 

이번에도 작업이 실패하였어요. 역시 한번에 완료되면 재미가 없는 것이에요.

이 문제를 알아보기 위해 Ansible Server에서 직접 Jenkins에 입력했던 명령어를 실행해 보기로 하였어요.

만약 위와 같이 Error가 나온다면 yml에 문법이 틀린 것이에요.

위와 같이 문제가 발생하면 아래처럼 해결할 수 있어요.

ssh-copy-id {계정}@{대상 Server IP}

Ansible 자기 자신에게 ssh 접속 시 계정등을 묻지 않게 하기 위해 SSH 공개키를 저장해 두고, 진행했더니 성공하였어요.

Docker Hub에도 정상적으로 Update 된 것을 확인할 수 있어요.


CI 작업은 정상적으로 끝이 났다고 판단하고, 이제 CD 작업을 진행하도록 할게요.

 

Build other projects

Jenkins에 Item 설정에서 '빌드 후 조치 추가' Button을 눌러주세요.
그런 뒤 Build other projects를 눌러주세요.

이것은 Build가 완료된 뒤에 어떤 Project를 추가로 연계할 것인지 선택하는 곳이에요.

Projects to build에 이 전에 만들었던 Ansible을 이용한 kubernetes 연동 Project를 선택해 주었어요.

이 이야기는 현재 Project가 정상적으로 끝나면 'Junyharang-k8s-Porject-Using-Ansible' 이라는 Project를 추가로 실행해 달라는 것이에요.


위와 같이 설정하고, 저장을 한 뒤 해당 창을 나왔어요.
그런 뒤 Build를 실행해 주었어요.

위와 같이 정상 작동 하였어요.

Docker Image도 Docker Hub에 잘 올라와 주었어요.

Code 15번에 Version을 1.5로 변경하고, Git에 Push해서 자동으로 CI / CD가 이뤄지는지 확인해 볼게요.

 

쿠버네티스 완벽 가이드:입문부터 실제 운용까지 필요한 기술 총망라!

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."