CI/CD 구축하기-젠킨스,도커,슬랙,깃

MSA기반의 시스템 환경구성하기 목표계획

• 도커 설치 -> 하단의 각 시스템 별 컨테이너 구성 및 관리해보기
• 젠킨스 설치 -> 자동배포 파이프라인 구성
• 배포과정 및 이슈 트래킹용 (슬랙 or 카프카 or 레빗엠큐 중 택1)
• 젠킨스 자동배포 구성 중 깃, 깃허브 자동배포 환경 연동
• k8s 구성 -> 모니터링 등

완료 내역

1. 우분투 내 도커설치 및 환경 구성완료
2. 젠킨스 이미지 생성완료
3. 젠킨스 플러그인 다운로드 완료
4. 깃, 톰캣 등 자동배포에 필요한 구성 설치완료

개념정리

CI/CD

자동화 도구 및 개선된 Work flow 수작업에서 자동화

• 다수의 개바라자가 개발한 소스를 지속적으로 통합하는것 지속 통합
• 자동화된 빌드 & 테스트는 원천 소스코드의 충돌 방지

개발자의 변경사항이 Repository를 넘어 고객의 프로덕션 환경까지 자동으로 지속적 배포

• 형상관리 소스코드 병합, 변경사항이력관리, 버전관리 등
• 소스코드 빌드 자동화
• 정합성 검증 커버리지 정적 분석, 표준형식 및 스타일 준수여부
• 변경사항이 다른 라이브러리 및 배포 환경 호환 여부 체크
• 수동테스트를 거쳐 클라이언트 요구사항 체크
• CI 파이프라인에서 생성된 패키지를 프로덕션으로 배포할 수 있도록 절차
• 자동화 또는 절차과정을 통해 프로덕션 배포

CI/CD 파이프라인 구성에 필수요소들

1. 버전관리 저장소 -> SVN, GIT
2. 빌드서버 -> 젠킨스
3. 빌드스크립트 -> 스크립트, 배치파일
4. 프로젝트 관리도구 -> 모니터링용 슬랙, 텔레그램 봇 등
5. 품질관리도구 -> 인수테스트 자동수행 승인 -> sonarQube

기존 프로젝트 소스를 자동배포 할 수 있도록 구성

1. 로컬 PC 내 우분투 구성, wsl2, 젠킨스, 서비스 배포환경 구성, openjdk 설치, 도커 설치 깃허브 또는 SVN 구성
2. 매번 배포때마다 수작업으로 진행보다 젠킨스 통해 자동배포 및 테스트로 인한 코드품질 및 안전성 확보

젠킨스

젠킨스에서 CI/CD를 수행할 파이프라인을 설정 후 개발자가 소스를 repository 저장하면
젠킨스는 소스를 체크 아웃 후 -> 아카이브와 디플로이를 자동으로 수행

장점

• 오픈소스 -효율적인 커뮤니티 지원 제공
• 플랫폼 간 통합 도구 - 운영 체계에 따라 실행
• 확장가능 - 지원하는 플러그인 기능이 풍부하고 다양
• 설치 및 사용이 간단

단점

• 프로젝트별 보안 및 권한 설정 등이 불편함.
• 지라나 레드마인 등 이슈트래커와 연동이 어려움
• AWS에 독립적 전용 EC2가 있어야함.
• 호스팅을 직접해야됨
• 플러그인 관리 복잡하고 파이프라인 작성 어려움

구성시 주의사항 CI/CD 파이프라인은 여러 단계가 있고 개발주기 전반에 걸쳐 지속적으로 실행되므로 고객 관점에서 서비스 목표와 수준을 평가하고 개발 및 운용조직의 기존 프로세스 변화에 따른 저항으로 부터 극복 가능한 수준으로 구상해야됨.

• 개발/운영 환경 및 서비스 목적 확인

  형상관리, 통합빌드 단위 테스트 수행 및 테스트 커버리지 측정 테스트를 포함한 빌드 결과의 손쉬운 확인이 가능한 통합 개발 환경 필요

• 자동화 대상 기능 선정

  기존의 형상관리 시스템에서 관리 중인 소스코드들을 자동으로 빌드하는 환경 빌드시 단위 테스트 수행 및 테스트 커버리지 측정, 빌드 및 테스트 결과 챗봇, 메신저 등 구성

• 개발도구 선정

  개발 언어에 맞는 도구 선정 오픈소스 도구, 상용 도구에 상관없이 현재 개발 환경에 적합한 도구 선정

• 도구 간 연계성 파악

  레거시 시스템(형상관리, 개발 도구 등)과 연계가 가능한 도구 위주로 선정 폐쇄적인 개발/운영 환경에서는 솔루션간 최신 버전 업그레이드 운용의 부담

젠킨스 구축

프로젝트 자동빌드 및 테스트실행 배포 등의 기능을 보유함.

젠킨스 시나리오

1. 회사에서 중앙관리용 깃허브 코드를 공유함.
2. 젠킨스는 깃헙의 코드를 가져와 오류를 체크함.
3. 의존관계의 라이브러리 다운
4. 테스트 코드 존재시 테스트를 실행함.
5. 테스트에 이상없을 경우 빌드하여 실서버에 배포함.

– 자동빌드 테스트 결과

진행내역

1. 깃허브 연동
2. 자동빌드 테스트
3. 파이프라인 구성

• Jenkins 주요기능 및 플러그인
  1. Build Pipeline Plugin 쉽게 말하면 Job들 간에 관계를 제공합니다. Job 간의 순서와 트리거 기능 제공

1. Parameterized Trigger Plugin Build Pipeline Plugin에 종속성을 가지고 있는 플러그인으로, 트리거에 Parameter를 보낼 수 있는 기능을 제공

2. dashboard-view Build Pipeline Plugin에 종속성을 가지고 있는 플러그인으로 연관 관계가 있는 Job들 간의 Dashboard를 제공

3. Parameterized Build Parameter를 사용하여 빌드할 수 있는 환경을 제공

도커

도커는 컨테이너형 가상화 기술을 구현하기 위한 상주 어플리케이션과 이 어플리케이션을 조작하기 위한 명령행 도구로 구성되는 프로덕트.

• 어플리케이션 배포에 특화 애플리케이션 개발 및 운영을 컨테이너 중심으로 할수있음.

1. 변화하지 않는 실행환경으로 동일한 요청을 한번 보내는 것과 여러번 연속으로 보내는것이 같은 효과를 지니고, 서버의 상태도 동일하게 남는것으로 확보
2. 코드를 통한 실행환경 구축 및 어플리케이션 구성
3. 실행환경과 어플리케이션 일체화로 이식성 향상
4. 시스템을 구성하는 어플리케이션 및 미들웨어 관리 용이해짐.

컨테이너 개념

리눅스 기술을 사용해 선박의 컨테이너 처럼 프로세스가 사용하는 자원을 격리

• 컨테이너는 가상머신과 마찬가지로 어플리케이션을 관련 라이브러리 및 종속 항목과 함께 패키지로 묶어 SW서비스 구동을 위한 격리환경 마련
• 도커는 다양한 종류의 컨테이너 중 하나의 기술임.

도커플로우

1. 코드개발 2. 도커파일생성 3. 도커파일이미지생성 4. 컨테이너 오케스트레이터를 통한배포
2. 1. 컨테이너 런 6. 컨테이너이미지 푸시(코드를 이미지화해서배포하는것이중요함.)

장점

1. 빠른 시작과 종료 속도
2. 높은 직접도
3. 낮은 오버헤드(빠르다.)
4. 어플리케이션컨테이너지원

단점

1. 호스트 OS에 종속적
2. 컨테이너별 커널구성 불가

도커컨테이너와 vm 차이

vm 정의 가상머신은 게스트OS에 바이오스,가상CPU, 가상메모리, 가상디스크 등 제공하여 물리서버와 동일하게 궁성됨. 가상화기술은 가상머신 이미지마다 OS가 필요함.

컨테이너 정의 컨테이너는 OS를 가상화해서 여러개의 컨테이너를 OS커널에서 직접실행 컨테이너는 기존 가상화 기술보다 훨씬가볍다 OS커널을 공유하고 시작시간, 종료시간이 빠르고 메모리를 적게소모한다.

빠른시작시간 - 컨테이너는 분리된 프로세스 형식으로 OS부팅이 필요없다. 부팅시간 최소화 가능 높은 이동성 - 애플리케이션에 필요한 라이브러리나 의존 파일들을 이미지에 포함하기 때문에 환경에 의한 발행되는 문제가 거의 없음

오케스트레이션 기능

컨테이너 역시 그 수가 많아지게 되면 관리와 운영에 있어 어려워짐, 컨테이너 오케스트레이션은 이러한 다수 컨테이너 실행을 관리 및 조율하는 시스템을뜻함.

• 엔터프라이즈급 오케스트레이션으로 여러 서드파티 프로젝트가 있는데 쿠버네티스는 구글에서 공개한 대표적 컨테이너 관리 시스템임.

오케스트레이션기능

서비스디스커버리 - 서비스 탐색 기능으로 기본적으로 클라우드 환경에서 컨테이너의 생성과 배치 이동 여부를 알 수 없기에 IP, 포트, 업데이트 등 종합적인 관리 를 통해 서비스 지원 스케일링(로드밸런싱) - 생성된 컨테이너의 컴퓨팅 자원 사용량의 설정 및 자동 배분 스케일링(스케줄링) - 늘어난 컨테이너를 적합한 서버에 나누어 배포하고 서버가 다운 될 경우 실행 중이던 컨테이너를 다른 서버에서 구동시킴 클러스터링 - 여러개의 서버를 묶어 하나의 서버처럼 사용할 수 있도록 지원하거나, 가상 네트워크를 이용하여 산재된 서버를 연결시켜줌 로깅,모니터링 - 여러서버를 한곳에서 상태를 모니터링하고 로그관리 할수있도록 함

쿠버네티스

컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고 확장 가능한 오픈소스 플랫폼, 선언적 구성과 자동화를 모두 용이하게 해줌. 클라우드 환경에 적합한 컴퓨팅 기술지원

장점

확장성 - 일주일에 수십억 개의 컨테이너들을 운영하게 해준 경험에 따라 쿠버네티스가 디자인 되었기 때문에 손쉽게 확장가능 유연성 - 로컬 테스트, 프로덕트 운영이든 환경에 상관없이 사용자의 복잡한 요구를 모두 수용할 수 있는 유연성을 가져 애플리케이션들을 끊임없고 쉽게 전달 할수있음. 이식성 - 오픈소스로 온프레임, 하이브리드 퍼블릭클라우드, 인프라스트럭처 등 여러 환경에서 사용가능 모니터링중 관리자 설정 값과 다르면 설정한 값으로 바꿔주는 규칙설정가능

도커 기초 명령어

//도커 실행 명령어 메커니즘
docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]

다음은 자주 사용하는 옵션들입니다.
옵션	설명
-d	detached mode 흔히 말하는 백그라운드 모드
-p	호스트와 컨테이너의 포트를 연결 (포워딩)
-v	호스트와 컨테이너의 디렉토리를 연결 (마운트)
-e	컨테이너 내에서 사용할 환경변수 설정
–name	컨테이너 이름 설정
–rm	프로세스 종료시 컨테이너 자동 제거
-it	-i와 -t를 동시에 사용한 것으로 터미널 입력을 위한 옵션
–link	컨테이너 연결 [컨테이너명:별칭]


docker ps -a #모든 컨테이너 출력(정지 컨테이너 포함)
docker ps #실행 중인 컨테이너만 출력
docker start hello #hello 이름의 컨테이너 시작
docker restart hello #hello 이름의 컨테이너 재시작(재부팅)
docker attach hello #컨테이너에 접속(bash 쉘 접속)
docker stop hello #hello 이름의 컨테이너 종료
docker rm hello #hello 이름의 컨테이너 삭제
docker rm -f hello #hello 이름의 컨테이너 강제삭제


젠킨스 런
docker run -d -p 8181:8080 -v /jenkins:/var/jenkins_home --name jm_jenkins -u root jenkins/jenkins:lts

도커 프로세스
docker ps -a

도커 시작
docker start 컨테이너ID

도커 삭제
docker rm 컨테이너 ID

도커 정지
docker stop 컨테이너 ID
젠킨스 암호 찾는법 도커로 젠킨스띄웠을경우
docker exec <컨테이너네임> cat /var/jenkins_home/secrets/initialAdminPassword

톰캣 이미지 구성

톰캣 실행 및 프로세스 확인

톰캣 도커 실행명령어 docker run -d -i -t -p 7070:7070 tomcat:8

웹페이지 연결한 것을 이미지로 떠놓기 실행시 바로 해당 웹페이지 연결되도록 구성된 이미지

1. 젠킨스webhook 설정 웹훅은 ( web callback 혹은 HTTP push API 라고도 불림) 앱이 다른 앱에 실시간 정보를 제공하는 방법입니다. 웹훅은 실시간으로 데이터를 가져오기 위해 꽤 자주 polling 해야 하는 전형적인 API와 달리 다른 앱에 데이터를 즉시 전달하므로 데이터를 즉시 얻을 수 있습니다. … 웹훅의 유일한 단점은 처음에 웹훅을 설정하는 어려움입니다. 웹훅은 API 스펙에 해당하므로 “역방향 API” 라고도 하며 따라서 웹훅을 사용하기 위해선 API를 설계해야 합니다. 웹훅은 HTTP 요청을 당신의 어플리케이션에 보낼 것입니다. (일반적으로 POST 방식)

젠킨스 + 깃허브 연동 - 매우 중요!!!!

젠킨스에 깃허브 웹후크 연동을 위해서는 만약 개인 PC일 경우 기본적으로 막혀있기 때문에 ngrok이라는 프로그램을 통해 - (포트 포워딩과 같은 원리지원 프로그램)

웹후크 url선언시 ngrok에서 발급된 url + 80포트 + github-webhook

예시 : http://8f7g8e7wewf.ngrok.io:80/github-webhook/

위와 같이 선언 후 꼭 깃허브에서 딜리버 테스트통해서 200 코드 확인후 진행하면된다.

젠킨스에서 깃허브 연동 에러 128번 에러코드 발생시 대응방법

젠킨스에서 깃 연동 시 발생하는 하단과 같은 에러코드 일 때
stderr: fatal: unable to access Could not resolve host: github.com

1. sudo vim /etc/resolv.conf DNS 설정해줘야함. 접근이안되는 에러이며

   nameserver 168.126.63.1 #kt DNS 서비스
   nameserver 8.8.8.8 #구글 퍼블릭 DNS서비스(IPv4)
   nameserver 8.8.4.4 #구글 퍼블릭 DNS 서비스(IPv4)
   options edns0
   

해주면 된다.