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

 

 

 

이 내용은 인프런 - 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와 Infrastructure as Code (IaC) 연동

    🔽  개요

        📦 소개

Infrastructure as Code (IaC)는 코드형 인프라라고 불리며, 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고, 프로비저닝하는 것을 말해요.

IaC를 이용하면 인프라 사양을 담은 구성 파일이 생성되기 때문에 구성을 편집하고, 배포하기가 더 쉬워지게 됩니다.
또한, 매번 동일한 환경을 프로비저닝하도록 보장할 수 있어요.

IaC는 구성 사양을 코드화 하고, 문서화 함으로 구성 관리를 지원하기 때문에 구성 변경 사항을 문서화하지 않고, 임시로 변경하는 일을 막을 수 있는 장점이 있어요.

버전 제어는 IaC의 중요한 부분이에요. 다른 소프트웨어 소스 코드 파일과 마찬가지로 구성 파일도 소스 제어가 필요하답니다. 코드로 인프라를 배포한다는 것은 인프라를 모듈식 구성 요소로 분활하고, 자동화를 통해 다양한 방식으로 결합할 수 있다는 뜻이에요.

IaC로 인프라 프로비저닝을 자동화하게 되면 애플리케이션을 개발하거나, 배포할 때마다 개발자가 직접 서버, 운영체제, 스토리지, 기타 인프라 구성 요소를 수동으로 프로비저닝하고, 관리할 필요가 없어져요.

이러한 작업은 수동으로 진행할 수도 있고, Ansible과 같은 자동화 툴을 이용할 수도 있어요.





1. 시스템, 하드웨어 또는 인터페이스의 구성정보를 파일(스크립트)을 통해 관리 및 프로비저닝.

2. IT Infrastructure, Bare Metal Server 등 물리 장비 및 가상 머신과 관련된 구성 자원 관리.

3. 버전 관리를 통한 자원 관리.

 

1. Infrastructure as Code(IaC)를 사용하기 전

IaC가 도입되기 이전에는 단말기(Laptop, Desktop 등)을 통해 Server를 관리해줘야 해요.
만약 특정 Server를 사용 못할 정도에 문제가 발생하게 되면 해당 Server를 떼어내고, 새로운 Server를 도입해야 해요.
이 모든 작업을 터미널 등을 이용해서 직접 수동으로 해줘야 합니다.





2. Infrastructure as Code(IaC)를 사용하기 후

먼저 Ansible과 같은 소프트웨어를 도입하게 되면 Ansible과 Server를 연동 시켜주고, Server의 목록(Inventory)와 Server들을 관리함에 있어 필요한 작업들의 절차를 담아 놓는 File (Play Books)를 지정해 주게 됩니다.

만약 Server 한 대가 사용 못할 정도에 문제가 발생하게 되면 해당 Server를 떼어내고, 다른 Server를 구축했을 때, 자동으로 필요한 설정이나, 환경들을 구성할 수 있게 할 수 있어요.

주니하랑이 공부해 볼 Ansible은 Agnet가 필요 없다는 특징이 있어요.
각각의 Server에 Python이 설치되어 있다면 Python이 가지고 있는 Network Module을 통해 관리 Server와 통신을 할 수 있게 할 수 있어요.

 

 

 

    🔽  Ansible

        📦 Ansible이란?

1. 여러 개의 Server를 효율적으로 관리할 수 있게 해주는 환경 구성 자동화 도구
   ∙ Configuration Management, Deployment & Orchestration Tool.
   ∙ IT Infrastructure Automatically.

2. Push 기반 Service

3. Simple, Agentless 방식

4. Ansible을 통해 할 수 있는 일
   ∙ 설치 : apt-get, yum, homebrew 등.
   ∙ File & Script 배포 : copy.
   ∙ Download : get_url, git 등.
   ∙ 실행 : shell, task

 

 

 

 

        📦 Ansible 설치

1. Ansible Server 설치 (RedHat 기반 Linux)

yum install ansible

728x90

정상 설치 및 Version 확인

ansible --version

2. 환경 설정 파일 : /etc/ansible/ansible.cfg

3. Ansible에서 접속하는 Host List(대상 서버 목록) : /etc/ansible/hosts

강의에서는 강사님이 구축해 놓은 docker Container가 있어요.

 

주니하랑은 Linux 기반에서 돌아하는 Synology NAS에 Docker를 이용할 것이기 때문에 위의 Image를 Pull 받도록 할 것이에요.

위의 Image를 받으셨다면 Container 기동은 아래와 같이 해 주시면 되요.

sudo docker run --privileged -itd -p 20022:22 -p 8081:8080 -e container=docker -v /sys/fs/cgroup:/sys/fs/cgroup edowon0623/ansible:latest /usr/sbin/init

반응형

그런 뒤 ansible Container로 연결하려면 아래와 같이 해 주시면 되요.

ssh root@localhost -p 20022 (or docker exec -it ansible-server bash)

root Password : P@ssw0rd

또한 해당 Container 안에는 Docker가 설치 되어 있는데, 기동중이지 않기 때문에 아래와 같은 작업이 필요해요.

vim /etc/sysconfig/docker

위에 4번째 줄 OPTIONS가 있는 곳에 --selinux-enabled=false로 수정 해 주세요.

 

sed -i -e 's/overlay2/vfs/g' /etc/sysconfig/docker-storage

위 명령어는 /etc/sysconfig/docker-storage에서 앞에 값을 변경할 수 있도록 해주는 작업이에요.

위와 같이 Docker를 기동해 주면 되요.

💡 참고 사항

최초 주니하랑은 Sysnology NAS에 Docker를 이용하여 Ubuntu 22.04 LTS Container를 하나 만들어 주었어요.

이 곳에 ssh, net-tools, systemctl를 먼저 설치해 줄게요.

Synology NAS에 SSH로 붙은 뒤 Docker Container를 먼저 확인 해 주었어요.

그런 뒤 해당 Container ID를 통해 접속해 줍니다.


Docker를 이용해서 Ubuntu를 이용할 때, 몇 가지 설치해줘야 하는 것들이 있어요.
그 내용에 대해서는 이 곳에 준비해 둘게요.

또한, Ubuntu 22.04 LTS에 ansible을 설치하는 것은 이 곳에 준비해 둘게요.

 

        📦 Ansible 설정과 작동 과정

최초 Docker Host Server에서 현재 구동중인 Container에 정보를 확인해 볼게요.

sudo docker network inspect bridge

위와 같이 IP 정보도 확인할 수 있어요.



Ansible Container에서 아래와 같이 대상 Container 들을 등록해 주었어요.

vim /etc/ansible/hosts

 

 

        📦 Ansible 기본 명령어

Ansible에서 각각의 대상 Server에 SSH를 통해서 연결이 되도록 해야해요.
이 때, 매번 계정을 입력하기에는 매우 번거롭기 때문에 SSH Key를 생성한 뒤 Ansible Container에서 각각의 대상 Server에 배포를 해주도록 할 것이에요.

ssh-keygen

 

위와 같이 Ansible Container에서 ssh Key를 만들어 주었어요.

ssh-copy-id {접속할 계정명}@{접속 Server IP주소} -p {port 번호}

 

위와 같이 Ansible Container에서 대상 Server로 keygen을 통해 만들었던 공개키를 대상 서버에게 전달해 주었어요.

이런 뒤 ssh를 접속한다고 하면 아래와 같이 진행되요.

root 계정에 암호를 묻지 않고, 바로 접속되는 것을 확인할 수 있어요.

이번에는 Ansible Container 자기 자신에게도 위와 같이 작업을 해 두었어요.

 

Ansible Module - 실행 Option

1. -i (--inventory-file) : 적용 될 대상 Server들에 대한 File 정보.
   ∙ 이 Options을 이용하게 되면 /etc/ansible/hosts가 아닌 지정한 위치에 File을 읽어 적용 대상 Server 관리.

2. -m (--mocule-name) : Module 선택.

3. -k (--ask-pass) : 관리자 암호 요청.

4. -K (--ask-become-pass) : 관리자 권한 상승.

5. --list-hosts : 적용되는 대상 Server 목록 정보.

6. 멱등성 특징
   ∙ 같은 설정을 여러 번 적용하더라도 결과가 달라지지 않고, 한번만 적용되는 성질.
      - 예시:) echo -e "[junyharanggroup]\n172.20.10.22" >> /etc/ansible/hosts

 

 

cat /etc/ansible/hosts

멱등성 Test를 위해 위와 같이 echo 명령어를 이용해서 앞에 내용을 /etc/ansible/hosts로 삽입해 주었어요.

위 echo 명령어를 한번 더 실행 한 뒤 결과를 보면

동일한 값이 두 개 들어간 것을 확인할 수 있어요.

        📦 Ansible Module

Ansible Module 문서

최초 Ansible Module을 한번 Test 해볼게요.

ansible all -m ping

 

Ansible Container에 등록된 대상 Server들에게 모두 ping Test를 할 수 있는 모습이에요.

위에 172.17.0.5는 ssh port가 달라서 발생하는 문제에요.

위에 명령어에서 all은 group을 지정하는 부분이에요. all이라고 쓰면 모든 group(/etc/ansible/hosts)을 지칭하는 것이에요.

위와 같이 특정 group 이름을 넣어서 Test 해볼 수 있어요.



이번에는 각 대상 Server에게 명령어를 전달해 보도록 할게요.

ansible all -m shell -a "free -h"

free -h 명령어는 Memory 정보를 확인할 수 있는 명령어에요.

위와 같이 대상 Server들에 Memory를 확인할 수 있어요.



이번에는 File을 한번 전송해 볼게요.

최초 test.txt를 touch 명령어로 만들어주고, 위와 같이 글자를 입력해 주었어요.

대상 Server에 /tmp에 어떤 내용들이 있는지 먼저 확인해 줄게요.
현재는 아무것도 없음을 확인할 수 있어요.

ansible all -m copy -a "src=./text dest=/tmp"

 

위 명령어는 모든 대상 Server들의 group에 File을 복사할 건데, "현재 Directory의 text라는 File을 각각의 대상 Server의 /tmp Directory에 복사해라" 라는 의미에요.

대상 Server에 File이 들어온 걸 확인할 수 있어요.




이번에는 Program을 설치해 보도록 할게요.

먼저 Ubuntu 대상 Server에 httpd가 설치 되었는지 확인을 해 주었어요.

 

그리고, RedHat Linux 기반인 Ansible Container도 마찬가지로 확인해 주었어요.

ansible devops -m yum -a "name=httpd state=present"

 

위의 명령어는 yum을 통해서 httpd를 설치하라는 명령어에요.

Ubuntu에서는 yum 명령어가 먹지 않기 때문에 문제가 발생했고, Ansible Container를 CentOS이기 때문에 정상 설치가 되었다고 나와요.

 

Ansible Container에 httd 가 정상적으로 설치 되었어요!

 

        📦 Ansible Playbook

1. 사용자가 원하는 내용을 미리 작성해 놓은 파일
   ∙ 예시 :) 설치, 파일 전송, 서비스 재시작 등.
   ∙ 예시 :) 다수 대상 Server들에 반복 작업 처리  시.

2. Playbook
   ∙ vim {playbook 이름}.yml 작성.
   ∙ ansible-playbook {playbook 이름}.yml
   ∙ cat /etc/ansible/hosts

vim ~/first-playbook.yml

yaml 형식으로 위와 같이 Playbook을 만들어 주었어요.

먼저 해당 playbook의 이름을 name으로 지정을 해 주었고, Host 부분에는 대상 Server의 IP를 넣을수도 있고, /etc/ansible/hosts에 등록되어 있는 group 이름을 넣을 수도 있는데, 주니하랑은 group 이름을 넣어주었어요.

tasks에 어떤 작업을 할 것인지 명시를 할 것인데, 작업 이름을 name에다가 입력해 주고, 해당 작업의 대상 위치를 path에 지정해주고, block은 반드시 |로 시작을 해주어야 해요. 그리고, 작업 내용을 작성해 주었습니다.

 

ansible-playbook first-playbook.yml

 

playbook을 실행하려고 했더니 위와 같이 문제가 있다고 나와요.

yaml 형식은 들여쓰기가 굉장히 중요해요. 들여쓰기 문제로 문제가 있었던 것이에요.

위와 같이 수정을 해주고, 다시 명령어를 실행해 줄게요.

ansible-playbook first-playbook.yml

cat /etc/ansible/hosts

위와 같이 playbook에서 입력한 내용이 입력된 것을 확인할 수 있어요.

이번에는 멱등성에 대해 Test 해볼게요.

ansible-playbook first-playbook.yml

다시 한번 playbook을 동작시켜 보았어요.

cat /etc/ansible/hosts

대상 Server에서 다시 확인해 보면 해당 내용이 추가되어 있는 것이 아니고, 하나만 입력되어 있는 것을 확인할 수 있어요.



또 다른 Test를 진행해 볼게요.

vim ~/playbook-sample1.yml

 

위와 같이 yaml을 하나 더 만드는데, 이번에는 copy를 통해 ansible에 ~/(home Directory) 안에 sample.txt File을 각각의 대상 Server들의 /tmp 안에 복사하고, 해당 File의 소유주를 root로 하고, 권한을 644(rw-r-r)로 주겠다는 의미에요.

이 전에 만들었던 test.txt File 이름을 sample.txt로 바꾸어 주었어요.

ls -al

 

대상 Server에는 현재 sample.txt가 없는 것을 확인할 수 있어요.

ansible-playbook playbook-sample1.yml

 

실행을 했는데, 위와 같이 실패를 하였어요.

아무래도 playbook-sample1에 오타가 있는 거 같아요

이 부분에 modE에 E 부분을 소문자로 바꿔서 다시 진행해 볼게요.

 

ansible-playbook playbook-sample1.yml

정상 진행된 것을 확인할 수 있어요.

대상 Server를 확인해 보니 sample.txt가 생긴걸 확인할 수 있어요.
소유주도 root이고, 644(rw-r-r)로 권한이 적용 되었어요!




이번에는 Program을 내려받기 하는 예제를 진행해 볼게요.

vim ~/playbook-sample2.yml

 

이번에는 tasks의 name이 두 개가 있는 것을 볼 수 있어요.
이 의미는 작업을 두 가지를 하겠다는 의미에요.

먼저 첫번째 작업은 /opt/tomcat9 이라는 Directory를 만드는 부분이고, 권한을 755(rwxr-xr-x)를 주겠다는 의미에요.

그리고, 두번째에서는 url에서 tar File을 내려 받을건데, 받을 위치는 /opt/tomcat9 이라는 의미이고, 이 역시 권한은 755(rwxr-xr-x)로 할 것이라는 뜻이고, 해당 File이 정상(위, 변조 여부)인지 여부를 확인하기 위해 checksum을 이용해서 확인하겠다는 의미에요.

 

 

먼저 대상 Server에 해당 Directory가 있는지 확인해 보았어요.

ansible-playbook playbook-sample2.yml

대상 하나는 성공하고 하나는 실패하였어요.

정상적으로 처리가 된 대상 Server에는 위와 같이 tomcat 설치 압축 File이 있는 것을 확인하실 수 있어요.

 

    🔽  Ansible과 Jenkins

        📦 연동하기

이번에는 Jenkins에서 Ansible을 연동해 볼게요.

최초 Jenkins 관리에서 시스템 설정으로 들어가 줄게요.

기존에 실습했던 내용은 지우고, 새롭게 이 부분에 입력을 해 줄게요.

hostname -i

그 전에 Ansible Container의 IP를 확인해 주었어요.

위와 같이 입력을 해주고, Test Configuration을 눌러주니 Success가 뜬 것을 확인할 수 있어요.

 

 

        📦 Jenkins + Ansible Playbook 사용하기

최초 위와 같이 새로운 Item을 하나 생성할게요.

이전에 Docker Project에서 몇가지만 수정할 것이기 때문에 Copy Item에서 Docker Project Item 내용을 가져오도록 할게요.

빌드 후 조치에서 기존에 있었던 내용은 모두 지워줄게요.

그런 뒤 Send Build ... 를 선택해 줍니다.

Name 부분은 Jenkins 관리 시스템 설정에서 SSH 대상 Container를 위와 같이 ansible-host라고 하나 만들어 주었어요. 그걸 선택해 주고,

Source files에는 /taget에 모든 war File을 지정하고, Remove prefix에는 target Directory는 필요가 없기 때문에 지정해서 복사되지 않도록 해주었어요.

Remote Directory는 Ansible Container에 war File을 어디에 저장할건지를 정하는 곳인데, ssh를 root로 접속하게 되면 바로 /root Directory로 접속하게 되요. 그래서 그냥 그 곳을 지정해 준 것이에요.

이렇게만 하고, 일단 Apply -> Save 해줄게요.

Build를 해보니 정상적으로 Build가 되었어요.

 
Ansible Container에 war File이 생긴걸 확인할 수 있어요.

vim ~/first-devops-playbook1.yml

 

Ansible Container에 새롭게 playbook을 만들어 주었어요.
이 playbook은 war File이 Jenkins를 통해 오면 그걸 가지고, docker Image를 build하는 명령어가 들어가 있는 것을 알 수 있어요.

마지막으로 Target Directory는 root Directory로 설정을 해주는 것이에요.

hosts는 모든 group를 대상으로 했어요.

vim ~/Dockerfile

 

/root Directory에 Dockerfile을 만들어 주는데 위와 같이 만들어 주었어요. tomcat 9.0 Version을 가지고, 현재 Directory에 있는 hello-world.war File을 docker를 만들어 그 안에 /usr/local/tomcat/webapps에 복사해라 라는 내용이에요.

vim ~/hosts

 

이번에는 /etc/ansible/hosts가 아닌 위와 같이 hosts를 만들어 Ansible Container 자기 자신을 등록해 주었어요.

ansible-playbook -i hosts first-devops-playbook.yml

위에서 만든 playbook을 실행 시켜 보았어요.

-i hosts라는 부분은 /etd/ansible/hosts를 쓸 것이 아니라 주니하랑이 위에서 만든 hosts를 쓰겠다는 의미에요.

docker images

위와 같이 docker image만 정상적으로 만들어진 것을 확인할 수 있어요.




이번에는 Docker Container까지 생성해 볼게요.

vim ~/first-devops-playbook.yml

위에서 만든 cicd-project-ansible 이라는 이름의 image를 가지고, Container를 만드는 명령어를 추가해 줬어요.

-d 는 Background에서 작업을 하라는 의미이고, --name Options 뒤에 해당 Container 이름을 넣어주고, Port Fowarding할 내용이 있다면 -p Options 뒤에 입력을 해주고, Image 이름을 넣어주었어요.

현재 존재하는 Docker Image 들을 확인해 주었고, 기동중인 Container가 있는지 확인해 주었어요.

ansible-playbook -i hosts first-devops-playbook.yml

위와 같이 작업이 성공하였어요!

Docker Container 까지 정상적으로 만들어 진 것을 확인할 수 있어요.




이제 위 내용이 자동화 처리가 되도록 하기 위해 Jenkins에 힘을 빌리려고 해요.
그 전에 만들어진 Image와 Container는 모두 지워주도록 할게요.

먼저 Docker Container를 중지시키고, 삭제 해주었어요.

그런 뒤 Image까지 삭제해 준 모습이에요.

잘 처리가 되었는지 확인해 주었어요.

해당 Item의 구성에 들어와서 Exec command에 아래 내용을 추가해 주었어요.

ansible-playbook -i hosts first-devops-playbook.yml

이제 저장을 한 뒤 다시 Build를 해 볼게요.

작업이 성공적으로 끝났다고 해요!

Docker Image랑 Container도 정상적으로 생성된 걸 확인할 수 있어요!

이렇게 Web Service도 정상적으로 구동되는 걸 확인할 수 있어요.





이번에는 Github에서 push even가 발생해서 변경 사항이 있다면 자동으로 Build가 되게 설정해 줄게요.

해당 Project 구성에 Poll SCM에 위와 같이 설정을 해 주었어요.

위에 5번째, 11 ~ 12번째 Code를 약간 수정해 보았어요.

Github에 push를 해 볼게요!

지금 빌드를 누르지 않았지만, 위와 같이 자동으로 Build 작업이 걸리는 것을 확인할 수 있어요.

 

하지만 Build는 실패하고 말았어요.

실패한 이유는 기존에 기동중인 Docker Container가 있었는데, 동일한 이름으로 Container를 만들려고 했기 때문에 발생한 문제에요.

vim ~/first-devops-playbook.yml

위와 같이 Docker Container를 중지하고, 삭제하고, Image 또한 삭제하는 명령어를 추가해 주었어요.

ignore_errors: yes는 만약 중지 명령어를 내렸는데, 중지할 대상 Container가 없으면 Error가 발생하게 되요. 이 때 이 Error를 무시하게 해서 작업을 계속 이어 나갈 수 있게 하기 위해 추가한 부분이에요.

Code를 살짝 수정해서 다시 push를 해주었어요.

작업이 성공하였어요!

Docker Image와 Container도 만들어진지 얼마 안된 것을 확인할 수 있어요.

Web Service도 글자가 비록 깨졌지만, 정상 구동 되는 것을 확인할 수 있어요!

 

        📦 Use Ansible Docker Image Management

이번에는 주니하랑이 작업한 Docker Image를 Docker Hub에 Upload 하는 작업을 해 볼게요.

현재 주니하랑에 Docker Hub Repository에는 아무것도 없어요.

docker tag {Docker Image 이름} {Docker Hub 계정}/{Docker Image 이름}

최초 위와 같이 Docker Hub 계정명을 이용한 Image를 하나 만들어 주었어요.

docker images

 

docker login

그런 뒤 docker hub에 Login하기 위해 위와 같이 작업을 해 주었어요.

docker push {Docker Hub 계정}/{Docker Image 이름}

위의 방법으로 Image를 Docker Hub에 올려줄 수 있어요.

다시 Docker Hub를 확인해 보니 위와 같이 Image가 올라간 것을 확인할 수 있어요.


위 작업을 자동화 하기 위해 새로운 playbook을 Ansible Container에 만들어 주었어요.

vim ~/create-cicd-project-image-playbook.yml

그런 뒤 playbook을 실행 시켜 주니 위와 같이 정상적으로 처리가 되었어요!

Docker Hub에도 Image가 정상적으로 올라갔어요!



이번에는 Container를 생성하는 Playbook 작업을 해볼게요.

최초 위와 같이 기존에 만들었던 playbook File 이름을 변경해 주었어요.

vim ~/create-cicd-devops-container.yml

수정한 내용은 Docker Hub에서 Image를 Pull 받아 올 수 있게 처리를 해 주었고, Docker를 기동할 때, Image 이름에 주니하랑의 계정명을 붙혀준 것이에요.

기존에 받았던 Image는 일단 제거를 해 주었어요.

Docker가 설치된 CentOS 기반 Container를 대상 Server로 Test하기 위해 준비해 두었고, Docker를 기동시켜 주었어요.

해당 Container에는 기동중인 Container나, Image는 없어요.

준비된 대상 Container는 위와 같은 IP를 쓰고 있고, Ansible에 Custom하게 만든 hosts 파일에 등록시켜 줄게요.

vim ~/hosts

위와 같이 등록을 해 주었어요.

 

먼저 진행하려고 하는 작업은 Docker Image를 만들고, Push하는 명령어가 들어간 playbook을 실행시킬건데, hosts에 등록된 모든 Server에 해당 작업이 먹지 않고, Ansible Container만 해당 명령어가 먹게 하기 위해 --limit Option과 함께 Container IP를 넣어주었어요.

위와 같이 Ansible Container에서만 작업이 진행되었고, Image를 만들고, Docker Hub에 Push해 주고, 지워주는 작업을 해 주었어요.

Image가 방금 올라온 것을 확인할 수 있어요.

이번에는 새로 만들었던 Docker Container에 기존에 구동중이던 Docker Container 중지, 삭제 Image 삭제를 하고 난 뒤 Docker Hub에서 Image를 받고, 구동 시키는 작업이 들어간 Playbook을 실행 시켜 보았어요.

위의 Error가 발생한 것은 중지, 삭제할 대상이 없기 때문에 Error가 발생했는데, Ignore_Error를 yes로 주었기 때문에 정상인 것이에요.

위와 같이 Docker Container에 정상적으로 Image와 Container가 생성된 것을 확인할 수 있어요.

해당 작업을 다시 실시하게 되면 Docker Container와 Image가 존재하고 있는 상태이기 때문에 Error 없이 처리되는 것을 확인할 수 있어요.

        📦 Use Ansible Playbook Create Docker Container

Jenkins를 이용해서 위에 작업들을 자동화 해 보도록 할게요.

먼저 새로운 Item을 만들어 주도록 할게요.

Exec command 부분에 위에서 Test한 명령어들을 넣어줄게요.

그 외에 내용들은 바뀌지 않을 것이에요.

Code를 살짝 또 수정하고, Push를 해 주었어요.

작업이 성공적으로 수행 되었어요!

Docker Container에도 정상적으로 작업이 완료 된 걸 확인할 수 있어요.