SKplanet Tacademy 유튜브 채널에서 토크온 세미나로 Jenkins에 대한 내용을 설명해서 쭉 정주행을 해보았다.
평소 CI/CD에 대해서 많이 들어봤지만 무엇인지 제대로 알지 못하고, 개념이 잡혀있지 않아서 많은 도움이 된 세미나 였던 것 같다.
추후 Jenkins에 대한 파이프라인을 직접 회사에서 구축해보고 공부할 수 있는 기회가 생기면 좋을 것 같다는 생각을 하였다.
아래는 SKPlanet 토크온 세미나 영상 주소이다.
www.youtube.com/watch?v=JPDKLgX5bRg
JenKens와 CICD / Jenkins를 활용한 실무 CICD (1강)
1. 강의 목표
-
CI/CD 파이프라인의 기본 개념의 이해
-
기본적인 운영환경(DEV, QA, PROD)이 어떻게 구성되고 운영되는지 이해
-
Jenkins의 기본 개념에 대한 이해
-
Jenkins를 통해 기본적인 배포 파이프라인을 직접 구축
-
실제 운영기에서 특히 AWS 기반의 클라우드 환경에서 Jenkins가 어떻게 활용되는지 이해
2. 강의 목표 추가 설명
-
사용자가 사용하는 Production이 아니라 개발자의 로컬 환경, DEV환경, QA환경 등 구축 환경에 대해 이해한다.
-
즉 내부 사용자들에 대해서도 지속적으로 전달하는 것 자체가 CI/CD라고 할 수 있고 각 환경에 대해 어떻게 구축해야 하는지 이해하여야 한다.
-
이를 도와주는 툴이 jenkins이고 이를 이용하여 이런 환경을 어떻게 매끄럽게 구축해나갈지에 대해 알아본다.
3. CI / CD란 무엇인가???
CI란
-
Continuous Integration을 말한다 => 무엇을 통합한다는 것일까?
-
기본적으로 코드이다.
-
여러 명의 많은 개발자들이 코드 베이스를 계속해서 통합하는 것이다.
-
여러 개발자들의 코드를 각각 가능한 빠르게 배포를 하는 것을 의미한다.
-
즉 코드를 통합한다는 것이다.
CD란
-
Continuous Delivery => 무엇을 배달
-
내부 사용자(내부 QA, 마케터, 기획자)든, 사용자든 서비스를 지속적으로 배달한다.
-
즉 코드 베이스가 항상 배포 가능한 상태를 유지하는 것을 의미한다.
Continuous Deployment
-
코드 베이스를 사용자가 사용 가능한 환경에 배포하는 것을 자동화하는 것이다.
-
버전 1 쓰다가 끊키지 않고 배포하는 것을 말하는데 ECS를 사용하면 이를 편리하게 구축할 수 있다.
즉 CI/CD란 각각의 개발자들이 개발을 하는 개발환경을 사용자가 사용 가능한 서비스로 전달하는 모든 과정을 지속 가능한 형태로 또 가능하다면 자동으로 해서 개발자와 사용자 사이의 격차를 없애는 것이다. 이러한 과정에는 코드를 빌드하고, 테스트하고 배포하는 활동이 있다.
-
코드 작성
-
배포 테스트
-
자바나 컴파일해야 하는 언어는 컴파일 및 빌드
-
도커로 배포 시 도커 이미지 만들기
-
쿠버네티스의 롤링 업데이트
-
이러한 과정들을 모두 자동화
CI/CD 파이프라인
-
파이프라인이라고 하는 이유는 이러한 배포 자동화 과정들이 물 흐르듯 흘러가는 것을 묘사해서 그렇게 부르게 된다.
CI 가 왜 필요한지 (CI가 없을 때)
10명의 개발자가 열심히 개발한다. 1주가 흐른다. Merge Hell이 발생한다. => 마지막 커밋 누구야.. 내꺼 안되잖아..
-
즉 뭔가 시스템 자체가 하나로 합쳐져있지 않고 여기저기 개발하던 것을 하나로 합치는 과정에서 문제가 발생한다.
-
따라서 코드를 작성할 때마다 바로바로 합치자는 것이 CI(Continuous Integration)이다.
-
철칙은 다음과 같다.
-
"가능한 최대한 빨리빨리 내 코드를 코드 베이스에 안착시키자"
-
"테스트 코드 없는 무서운 코드 버그 더미 코드를 애초에 코드 베이스에서 쫓아내자"
CD는 왜 필요한가?
백엔드 코드 개발 프론트와 협업해야 하니 배포를 해볼까? 저기 배포 좀 해주세요... 앗 버그...! 다시 배포 좀 해주세요... 데브 서버에 누가 배포했나요? 제꺼 안 되는데요? 앗 죄송.. QA 배포...
-
CTO가 보통 배포를 한다.
-
이때 계속 배포를 하게 되면 피곤해지는데 자동으로 배포되면 CTO의 부담을 덜 수 있다.
-
프로덕션 배포 시 초긴장 유지...
-
열심히 배포 스크립트 작성, AWS콘솔 만지작.. 혹은 베어메탈?!
-
이런 과정을 사람 손으로 하게 되면 실수도 많고 문제도 많이 발생하게 된다.
-
=> 개발자가 코드만 짜면 되지 뭐 이리 할게 많아 ㅠㅠ
CD와 함께라면?
10명의 개발자가 열심히 개발 => 끝 (머지됬으니까 내 역할은 여기까지 peace..)
-
QA 엔지니어와 같은 내부 사용자 혹은 실제 production 환경의 사용자에게 지속적이고 안정적으로 서비스를 제공한다.
4. 젠킨스란 무엇인가?
젠킨스 넌 누구냐
-
귀찮은 일을 다 해주는 '종', '하인'같은 존재
-
너 나가기 전에 젠킨스한테 너 하던 거 다 시키고 나가
-
Java Runtime 위에서 동작하는 자동화 서버
-
빌드, 테스트, 배포 등 모든 것을 자동화해주는 자동화 서버이다.
-
Docker위에서도 잘 동작하기 때문에 도커 다운받아서 설치해도 된다.
-
비서! 난 개발만 할 테니까 귀찮은 건 니가 다 해라!
젠킨스 기본 개념
-
Java Runtime Environment에서 동작
-
다양한 플러그인들을 활용해서 각종 자동화 작업을 처리할 수 있다.
-
AWS 배포, 테스트, 도커 빌드 등 할게 너무 많으니 각각의 컴포넌트들을 하나의 플러그인으로 모듈화를 해놓았는데 이를 활용하여 사용하면 된다.
-
가장 핵심적인 파이프라인, 시크릿 키마저도 플러그인으로 동작시킬 수 있다.
-
즉 일련의 자동화 작업의 순서들의 집합인 Pipeline을 통해 CI/CD 파이프라인을 구축한다.
-
플러그인들을 잘 조합해서 돌아가게 하는 게 Pipeline이라고 할 수 있다.
젠킨스의 Plugin
-
젠킨스에는 다양하고 많은 플러그인이 존재한다.
-
대표적인 플러그인들
-
Credentials Plugin
-
Git Plugin => jenkins에서 git에 대한 소스코드를 긁어와서 빌드할 수 있도록 도와줌
-
Pipeline => 핵심 기능인 파이프라인마저도 플러그인이다.
-
처음에는 그냥 Recommend 해주는 역할만 했는데 이제는 웬만한 기능은 다 깔려있다.
5. 젠킨스의 Plugin 깊게 살펴보기
Credentials Plugin
-
Jenkins는 그냥 단지 서버이기 때문에 배포에 필요한 각종 리소스에 접근하기 위해서는 여러 가지 중요 정보들을 저장하고 있어야 한다.
-
리소스에는 클라우드 리소스 혹은 베어메탈에 대한 ssh 접근 등을 의미한다.
-
베어메탈이란 어떠한 소프트웨어도 담겨 있지 않은 하드웨어를 가리킨다.
-
AWS token, Git access token, secret key, ssh(username, password)등의 정보들을 저장할 때 사용한다.
-
위와 같이 중요한 정보들을 저장해주는 플러그인
-
젠킨스는 실제 Production 환경에서는 Public 환경에 떠있는 게 아니라 Private Network에 떠있기 때문에 보안상 너무 걱정하지 않아도 된다.
Pipeline Plugin
-
젠킨스의 핵심 기능인 Pipeline을 관리할 수 있게 해주는 플러그인
Docker plugin and Docker Pipeline
-
Docker agent를 사용하고 jenkins에서 도커를 사용하기 위한 플러그인
6. 젠킨스의 PinpeLine 깊게 살펴보기
Pipeline
-
파이프라인이란 CI/CD 파이프라인을 젠킨스에 구현하기 위한 일련의 플러그인들의 집합이자 구성
-
즉 여러 플러그인들을 이 파이프라인에서 용도에 맞게 사용하고 정의함으로써 파이프라인을 통한 서비스가 배포된다.
-
Pipeline DSL(Domain Specific Langage)로 작성됨.
-
자기 멋대로 만든 Language를 쓰겠다.
-
젠킨스가 동작되기 위해서는 여러 플러그인들이 파이프라인을 통해 흘러가는 과정이라고 할 수 있음
Pipeline을 구성하는 요소
-
파이프라인이란 CI/CD 파이프라인을 젠킨스에 구현하기 위한 일련의 플러그인들의 집합이자 구성.
-
즉 여러 플러그인들을 이 파이프라인에서 용도에 맞게 사용하고 정의함으로써 파이프라인을 통해 서비스가 배포됨.
-
두 가지 형태의 Pipeline Syntax가 존재
-
Declarative
-
Scripted Pipeline
-
위 두 가지 형태중 최신이자 더 가독성 좋을 문법을 가진 Declarative Pipeline Syntax를 사용할 계획임.
Pipeline의 Section의 구성
-
Sections
-
Agent section
-
Post section
-
State section
-
Steps section
-
위와 같이 4개의 Section으로 구성됨
-
Section은 가장 큰 개념이라고 생각하면 편함.
7. Pipeline의 Section 깊게 알아보기
Agent section
-
젠킨스는 많을 일을 해야 하기 때문에 혼자 하기 버겁다.
-
여러 slave node를 두고 일을 시킬 수 있는데, 이처럼 어떤 젠킨스가 일을 하게 할 것인지를 지정한다.
-
젠킨스 노드 관리에서 새로 노드를 띄우거나 혹은 docker이미지를 통해 처리할 수 있다.
-
쉽게 말하면 젠킨스를 이용하여 시종을 여러 명 둘 수 있는데 어떤 시종에게 일을 시킬 것이냐 하는 것을 결정하는 것이다.
-
예를 들어 젠킨스 인스턴스가 서버 2대에 각각 떠있는 경우, 마스터에서 시킬 것인지 slave에서 시킬 것인지를 결정할 수 있다.
-
젠킨스 노드만 넣을 수 있는 것이 아니라 젠킨스 안에 있는 docker container에 들어가서 일을 시킬 수도 있다.
-
"nodejs안에서 뭔가를 해"라고도 명령을 시킬 수 있다.
Post section
-
스테이지가 끝난 이후의 결과에 따라서 후속 조치를 취할 수 있다.
-
각각의 단계별로 구별하면 다음과 같다.
-
success
-
failure
-
always
-
cleanup
-
성공 시에 성공 이메일, 실패하면 중단 혹은 건너뛰기 등등, 작업 결과에 따른 행동을 취할 수 있다.
-
ex) 프론트엔드 빌드를 했는데 성공했으면 콘솔을 찍어라.
-
ex) 배포후에 slack에 배포됬다는 메세지를 보내라
Stage Section
-
어떤 일들을 처리할 것인지 일련의 stage를 정의한다.
-
일종의 카테고리라고 보면 됨.
-
ex) 프론트엔드 배포를 위한 스테이지, 등
Steps Section
-
한 스테이지 안에서의 단계로 일련의 스텝을 보여줌.
-
Steps 내부는 여러 가지 스텝들로 구성되며 여러 작업들을 실행 가능
-
플러그인을 깔면 사용할 수 있는 스텝들이 생겨남
-
빌드를 할 때 디렉터리를 옮겨서 빌드를 한다던가, 다른 플러그인을 깔아서 해당 플러그인의 메서드를 활용해서 일을 처리한다던지 하는 작업들을 할 수 있다.
-
플러그인을 설치하면 쓸 수 있는 Steps들이 많아진다.
-
ex) git을 깔면 git을 끌어다 쓰는 steps
-
ex) docker를 깔면 도커를 가져와서 빌드할 수 있는 메서드를 쓸 수 있게 됨.
8. Declaratives 문법 알아보기
Declaratives
-
Environment, stage, options, parameters, triggers, when 등의 Declarative가 있음
-
각 stage안에서 어떠한 일들을 할 것인지 정의하는 게 Declarative이다.
Declaratives의 단계
Enviroment
- 어떤 pipeline이나 stage scope의 환경 변수를 설정함
Parameter
-
파이프라인 실행 시 파라미터 받음
Triggers
-
어떤 형태로 트리거 되는가?
-
이 파이프라인이 어떤 주기로 실행이 되는가?
When
-
언제 실행되는가?
-
내가 땡겨온 환경이 production이고 environment가 prod일 때만 수행
-
각각의 조건에 맞게 배포 환경 설정 가능
9. Jenkins 마지막 실습해보기
기본 실습 코드
-
pipeline => agent => stage=> step 순으로 작업이 세분화된다.
-
위에서는 git에서 branch를 받아와서 디렉터리를 바꾸고 s3파일 업로드를 한 뒤 로그를 찍는 젠킨스 파이프라인의 예제이다.
젠킨스 설치하기
-
Jenkins를 설치하기 위해 yum으로 설치한다.
-
이후 Jenkins가 돌아가도록 하기 위해 필요한 목록들을 설치한다.
