17-1
full cycle, CI/CD, pipeline,
Docker(도커), Kubernetes(쿠버네티스), Jenkins(젠킨스)
배포/인도 자동화의 중요성
전통적 인도 프로세스
전통적 인도 프로세스의 한계점
- 느린 인도 기간
- 개발 요 구사항이 정의된 때로부터 제품 전달이 완료되기까지 긴 시간 소요
- 느린 피드백 주기
- 개발팀의 효율성 향상에 걸림돌로 작용
- 자동화 미비
- 릴리스 회수가 적으므로 자동화 필요 감소 → 릴리스 기간 예측 어려워짐
- 핫픽스 위험성
- 긴급한 코드 변경에 대하여 충반한 테스트가 이루어질 수 없는 위험
- 개발문화 건전성 제한
- 팀 스트레스, 의사소통 부족, 책임의 분산, 낮은 업무 만족도 등
그럼 어떻게?
해결방법 : 지속적 인도/배포 방식
-
변경 내용이 단지 코드 한 줄이라고 할 때
- 이를 배포하는 데 어느 정도 시간이 소요되는가?
- 이 배포 작업을 반복해서 안정적으로 수행할 수 있는가?
-
해결안 : 프로세스의 각 단계를 자동화
- 빠른 제품 인도
- 짧은 피드백 주기
- 위험도가 낮은 릴리스 : 반복과 롤백
- 유연한 릴리스 정책 결정 가능
Git을 활용한 SCM에서 논리적 연관성이 있는 변경사항을 묶어 잘게 자주 커밋하는 것과 유사함
자동 배포 파이프라인
코드의 통합, 테스트, 배포는 (전통적 인도 방식에서와 마찬가지로)매우 중요한 단계들임
- 각 단계를 유지하면서 동시에 자동화하는 것이 필요, 또한 지속적 모니터링도 필수
코드 변경 → 지속적 통합 → 자동 인수 테스트 → 구성 관리
지속적 통합 : (서로 다른 개발자에 의한)코드가 문제 없이 통합되는지 확인
자동 인수 테스트 : 구현한 기능이 고객 요구사항과 맞는지 확인
구성 관리 : 환경 구성, 소프트웨어 배포 (수동 운영 단계를 대체)
지속적 통합 (CI; Continuous Integration)
코드가 올바르게 빌드 및 통합되는지를 자동으로 확인
개발팀에 1차적인 피드백 제공
- 레포지토리에서 코드를 체크아웃
- 빌드 (컴파일 및 링크 등)를 수행하고 단위테스트(UT; Unit Test)를 행함
- 테스트 커버리지 (test coverage) 리포트 생성
- 코드 품질을 검증
- 정적 분석 (static analysis)을 통한 규칙 검사
- 코딩 규약 등의 준수 여부 검사
자동 인수 테스트
인수테스트(UAT; User Acceptance Test)- 제품이 릴리스할 준비가 되었는지를 "사용자 (고객)요구사항에 견주어"확인
- 전통적으로 QA(Quality Assurance)팀의 역할
- 통합 테스트, 인수 테스트, 비기능적 분석(성능, 확장성, 보안 ..)등을 포함
CD 파이프라인에 통합- 품질 점검을 나중에 하는 것이 아니라 개발 중에 제품에 내재시키자는 것
- 개발자가 구현을 마치는 즉시 고객이 원하는 제품인지를 검증
- 소프트웨어의 인도 결정을 자동화한다는 뜻
구성 관리
구성 관리(Configuration Management)- 소프트웨어와 환경 변화를 추적하고 제어
- 전통적으로 운영(Operation)팀의 역할
- 필수 도구 준비와 설치
- 응용의 배포와 관련한 다양한 서비스 인스턴스와 배포 버전 관리
CD 파이프라인에 통합- 프로덕션 환경의 응용을 자동으로 구성하고 배포
- 구성 관리 도구를 이용하여 구성 관리 파일을 버전 관리 시스템에 저장하고 변경 이력 추적
CD를 위한 기술적 전제조건
- 자동 빌드/ 테스트/ 패키징/ 배포
- 전체 프로세스 중 자동화되지 않는 부분이 있다면 지속적 인도가 불가능
- 신속한 파이프라인 실행
- 레포지토리에 커밋 발생할 때마다 실행되어야 하므로 소요시간이 길면 안됨
- 신속한 장애 복구
- 신속한 롤백이 가능해야 하며, 그렇지 못할 경우 잦은 릴리스에 따른 위험도가 높아짐
- 무중단 배포
- 잦은 (하루에도 수 회) 배포가 이루어지므로 배포 중 서비스 다운타임 (downtime)이 발생하면 안 됨
- 트렁크 기반 개발
- 로컬 브랜치에만 코드 체크인하면 코드 통합 검증이 이루어지지 않고 릴리스 회수가 줄어듬
---
Q. 이렇게 많은 도구들의 사용을 익혀야 하나?
A. Y - 도구와 환경을 올바르게 설정하는 것이 파이프라인 구축에 있어서 중요함
Q. 그렇다면, 파이프라인 구축에서 가장 중요한 것은 도구 사용법을 익히는 것?
A. N - 더욱 중요한 것은 각 도구가 세스에서 담당하는 역할과 요구되는 조건을 이해하는 것
Q. 아래의 도구들이 필수인 것인가?
A. N - 같은 역할을 하는 다른 도구들이 많이 존재, 환경에 맞는 도구를 유연하게 선택해야
Q. 새 도구를 선택할 때마다 다 새로 익혀야 하는 것인가?
A. N - 역할과 요구조건이 같은 도구들은 세부 사항에 차이가 있다고 하더라도 대부분 유사
---
웹 개발 파이프라인 구성 도구
- 컨테이너 가상화 및 클러스터 운용
- Docker + Kubernetes
- 소프트웨어 개발 파이프라인 자동화 서버
- Jenkins
- 구성 관리 자동화
- Ansible
- 소프트웨어 버전 관리(SCM; Source Code Management)
- GitHub
- 그 외
- 빌드도구(자동화 지원), 단위 테스트 프레임워크, 정적 코드 분석기, 인수 테스트 프레임워크, ...
컨테이너화 (Containerization)
응용 프로그램, 설정(configureation)파일, 라이브러리, 그리고 이들 사이의 의존성 관계를 한군데에 묶어 (컨테이너 안에 넣어서) 관리
- 소프트웨어 개발 및 배포의 효율과 안정성을 향상시킴
- 하이퍼바이저(Hypervisor)에 의한 가상 기계(VM; virtual machine)의 대체 및 보완 방식으로 강곽받고 있음
- 시스템 의존성이 최소화 되어 소프트웨어 시스템의 이식이 용이해짐
- 예측 가능하고 유연한 소프트웨어 실행 관경을 제공하여 클라우드 컴퓨팅 인프라에서 활용도가 높음
지속적 통합 파이프라인 (CI Pipeline)
리포지토리에 코드 커밋이 발생할 때마다 빌드, 단위 테스트, 정적 분석 등을 행함
자동 인수 테스트
Docker와 Jenkins를 결합하여 인수 테스트 환경을 만들고 테스트 수행
쿠버네티스 클러스터링
Docker Host 대신에 Kubernetes Cluster가 연결된 형태
구성 관리 (Configuration Management)
다중 환경을 생성, 미ㅓ링하여 테스트 환경과 프로덕션 환경을 미러링
도커
도커 이미지
- 응용을 실행하는 데 필요한 모든 파일들과 그것을 실행하는 방법을 한데 묶어 놓은 것
- 상태를 저장하지 않는 stateless 방식 - 네트워크 전송, 레즈스트리에 저장, 이름 및 버전 지정 가능
- 계층화되어 있다는 특징을 갖고 있으며, 어떤 이미지로부터 다른 이미지를 만드는 것이 가능
계층 구조를 가지고 있다
컨테이너를 만드는데 이용되는 거푸집으로서 상태를 저장하고 있지 않다
이미지 레지스트리를 통하여 네트워크를 통해 전송이 가능하다도커 컨테이너
- 이미지의 실행 인스턴스 (instance)
- 하나의 이미지로부터 여러 컨테이너(인스턴스)를 만들어 동일한 응용을 여러 개 실행 할 수 있음 (각각은 독립)
- 상태를 저장하는 statefull 방식 - 컨테이너를 사용하면서 상태를 변경할 수 있음
- 그러나 컨테이너가 소멸하면 이 상태도 잊어버림
이미지를 이용하여 만들어진 응용 소프트웨어를 실제로 실행하는 격리된 환경
도커 엔진에 의해서 관리되며 마치 컴퓨터 하나가 새로 생겨서 정해진 일을 수행하는 것과 같은 모습을 보여줌\
실행 상태를 유지함이미지의 계층 구조 (Layer)
컨테이너와 이미지 관련 명령어 일부
docker run <이미지 이름>
이름이 주어진 이미지를 로컬에서 또는 레지스트리에서 가져다가 컨테이너를 만들어 실행
docker ps, docker ps -a
현재 실행 중인 (또는 중단되어 있는 것까지 포함하여) 컨테이너들의 정보를 조회)
docker images
로컬 컴퓨터에 가지고 있는 이미지들의 정보를 조회
docker stop <컨테이너 이름/ID>
현재 실행중인 컨테이너의 실행을 중단
컨테이너가 없어지지는 않음
docker rm <컨테이너 이름/ID>
컨테이너를 삭제
docker rmi <이미지 이름/ID>
이미지를 삭제
