웹 개발 파이프라인 구축(1)

✨강의를 통해 답을 찾아나가는 과정을 거치자

풀 싸이클(full cycle) 개발이 의미하는 것?

(웹 서비스 개발의 관점에서)  파이프라인(pipeline)이 의미하는 것?

CI / CD란 무엇이고 이것들은 왜 필요할까?

여기에 이용되는 도구들의 역할과 활용방법?

• Docker (도커)
• Kubernetes (쿠버네티스)
• Jenkins (젠킨스)
• 등등

CI / CD

배포/인도 자동화의 중요성

전통적 인도 프로세스

한계점

• 느린 인도 기간
  • 개발 요구사항이 정의된 때로부터 제품 전달이 완료되기까지 긴 시간 소요
• 느린 피드백 주기
  • 개발팀의 효율성 향상에 걸림돌로 작용
• 자동화 미비
  • 릴리스 회수가 적으므로 자동화 필요감소 -> 릴리즈 기간 예측 어려워짐
• 핫픽스 위험성
  • 긴급한 코드 변경에 대하여 충분한 테스트가 이루어질 수 없는 위험
• 개발 문화 건정성 제한
  • 팀 스트레스, 의사소통 부족. 책임의 분산, 낮은 업무 만족도

해결책: 지속적 인도(CD) / 배포방식

• 변경 내용이 단지 코드 한 줄 이라고 할 때,
  • 이를 배포하는데 어느정도 시간이 소요되는가?
  • 이 배포 작업을 반복해서 안정적으로 수행할 수 있는가?
• 해결안: 프로세스의 각 단계를 자동화
  • 빠른 제품 인도
  • 짧은 피드백 주기
  • 위험도가 낮은 릴리스: 반복과 롤백
  • 유연한 릴리스 정책 결정 가능

Git을 활용한 SCM에서 논리적 연관성이 있는 변경사항을 묶어 잘게 자주 커밋하는 것과 유사

자동배포 파이프라인

• 코드의 통합, 테스트, 배포는 (전통적 인도 방식에서와 마찬가지로) 매우 중요한 단계들이다.
  • 각 단계를 유지하면서 동시에 자동화하는 것이 필요, 또한 지속적 모니터링 필수

지속적 통합 (CI; Continuous Integration)

• 코드가 올바르게 빌드 및 통합되는지를 자동으로 확인
  • 리포지토리에서 코드를 체크아웃
  • 빌드(컴파일 및 링크 등)을 수행하고 단위테스트(UT; Unit Test)를 행함
    • 테스트 커버리지(test coverage) 리포트 생성
  • 코드 품질을 검증
    • 정적 분석(static analysis)를 통한 규칙 검사
    • 코딩 규약 등의 준수 여부 검사
• 개발팀에 1차적인 피드백 제공
• 인수테스트 (UAT; User Acceptance Test)
  • 제품이 릴리스할 준비가 되었는지를 '사용자(고객) 요구사항에 견주어' 확인
  • 전통적으로 QA(Quality Assurance) 팀의 역할
  • 통합 테스트, 인수 테스트, 비기능적 분석 (성능, 확장성, 보안, ...) 등을 포함
• CD 파이프라인에 통합
  • 품질 점검을 나중에 하는 것이 아니라 개발 중에 제품에 내재시키는 것
  • 개발자가 구현을 마치는 즉시 고객에 원하는 제품인지를 검증
  • 소프트웨어의 인도 결정을 자동화한다는 뜻
• 구성 관리 (Configuration Management)
  • 소프트웨어와 환경 변화를 추적하고 제어
  • 전통적으로 운영 (Operation) 팀의 역할
  • 필수 도구 준비와 설치
  • 응용의 배포와 관련한 다양한 서비스 인스턴스와 배포 버전 관리
• CD 파이프라인에 통합
  • 프로덕션 환경의 응용을 자동으로 구성하고 배포
  • 구성 관리 도구를 이용하여 구성 관리 파일을 버전 관리 시스템에 저장하고 변경 이력 추적

CD를 위한 기술적 전제조건

• 자동 빌드, 테스트, 패키징, 배포
  • 전체 프로세스 중 자동화되지 않는 부분이 있다면 지속적 인도가 불가능
• 신속한 파이프라인 실행
  • 리포지토리에 커밋 발생할 때마다 실행되어야 하므로 소요시간이 길면 안됨
• 신속한 장애 복구
  • 신속한 롤백이 가능해야 하며, 그렇지 못 할 경우 잦은 릴리스에 따른 위험도가 높아짐
• 무중단 배포
  • 잦은 (하루에도 수 회) 배포가 이루어지므로 배포 중 서비스 타운타임(downtime)이 발생하며 안됨
• 트렁크 기반 개발
  • 로컬 브랜치에만 코드 체크인하면 코드 통합 검증이 이루어지지 않고 릴리스 회수가 줄어듦

웹 개발 파이프라인 구성 도구

파이프라인 자동화 도구들

🔸컨테이너 가상화 및 클러스터 운용

• Docker + Kubernetes

🔸소프트웨어 개발 파이프라인 자동화 서버

• Jenkins

🔸구성 관리 자동화

• Ansible

🔸소프트웨어 버전 관리(SCM; Source Code Management)

• GitHub

🔸그 외

• 빌드 도구(자동화 지원), 단위 테스트 프레임워크, 정적 코드 분석기, 인수 테스트 프레임워크,...등

컨테이너화 (Containerization)

🔸응용 프로그램, 설정(configuration) 파일, 라이브러리,

그리고 이들 사이의 의존성 관계를 한군데에 묶어(컨테이너 안에 넣어) 관리

• 소프트웨어 개발 및 배포의 효율과 안정성을 향상시킴
• 하이퍼바이저 (hypervisor)에 의한 가상 기계 (VM; Virtual Machine)의 대체 및 보완 방식으로 각광받고 있음
• 시스템 의존성이 최소화되어 소프트웨어 시스템의 이식이 용이해짐
• 예측 가능하고 유연한 소프트웨어 실행 환경을 제공하여 클라우드 컴퓨팅 인프라에서 활용도가 높음

지속적 통합 파이프라인 (CI Pipeline)

🔸리포지토리에 코드 커밋이 발생할때마다 빌드, 단위테스트, 정적분석 등을 행함

자동 인수 테스트

🔸Docker와 Jeckins를 결합하여 인수 테스트 환경을 만들고 테스트 수행

쿠버네티스 클러스터링

🔸Docker Host 대신에 Kubernetes Cluster가 연결된 상태

구성관리 (Configuration Management)

🔸다중 환경을 생성, 미러링하여 테스트 환경과 프로덕션 환경을 미러링

컨테이너 가상화와 도커

가상화 (Virtualization)

🔸컴퓨팅 자원 (리소스; resource)의 추상화를 일컫는 광범위한 용어

🔸(딱딱한 정의) 물리적인 컴퓨팅 자원의 특징을 다른 시스템, 응용 프로그램

최종 사용자들이 자원과 상호 작용하는 방식으로 감추는 기술

🔸(부드러운 정의) 컴퓨터 안에 또 다른, 즉 가상의 컴퓨터가 존재하도록 하는 기술

가상화 컴퓨팅의 이점

🔸시스템 측면

• 시스템 이용률 (utilization)의 향상
• 설정 (configuration)의 구성과 복원이 용이

🔸비즈니스 측면

• 자본 및 운영 비용 절감
• 다운타임 최소화 (또는 제거)
• 비즈니스 연속성 및 재해 복구 향상
• 데이터 센터 관리 간소화

🔸우리의 관심

• 개발한 소프트웨어 배포, 테스트, 구성 관리 등에 통일된 환경을 제공
• (실제 물리적 하드웨어에 상관 없이)
• 따라서 소프트웨어 통합 / 인도 프로세스의 자동화에 적용하기 좋음

서버 가상화 기술의 진화

가상 기계 (VM; Virtual Machine) 기반

• 하이퍼바이저 (hypervisor)를 이용
• Type 1: 네이티브(native) 또는 베어메탈(bare-metal)형
  • 전가상화 (full virtualization)
  • 반가상화 (para virtualization)
• Type 2: 호스트형 (hosted)

컨테이너 (container) 기반

• 호스트 OS의 컨테이너 기술을 이용

호스트

: 다른 시스템을 가상화하여 실행하는 컴퓨터

게스트

: 호스트 시스템 위에 가상화 되어 제공되는 (가상) 시스템

하이퍼바이저의 두 가지 형태

https://ko.wikipedia.org/wiki/%ED%95%98%EC%9D%B4%ED%8D%BC%EB%B0%94%EC%9D%B4%EC%A0%80

하이퍼바이저 - 위키백과, 우리 모두의 백과사전

컨테이너 가상화 (Containerization)

https://www.atlassian.com/ko/microservices/cloud-computing/containers-vs-vms

컨테이너와 가상 컴퓨터 비교 | Atlassian

컨테이너 사용의 이점

🔸가상기계 (VM; Virtual Machine)의 대체 또는 보완 방식으로 각광받고 있음

🔸소프트웨어 개발 및 배포의 효율과 안정성을 향상시킴

• 응용 프로그램, 설정파일, 라이브러리, 그리고 이들 사이의 의존성 관계를 한데 묶어 관리
• 이 '묶음'을 컨테이너라고 부르고,
• 컨테이너 엔진의 도움으로 시스템 의존성이 최소화되어 소프트웨어 시스템의 이식이 용이해짐

도커(Docker)

널리 이용되고 있는 컨테이너 기반 가상화 플랫폼

🔸Linux, Windows, MacOS 상에서 실행되는 컨테이너 엔진을 제공

🔸AWS, GCP, Azure 등의 클라우드 컴퓨팅 인프라와 결합하면 더욱 유연한 운영이 가능

도커 허브(Docker Hub)

컨테이너 이미지들에 대해 원격저장, 유지관리, 공유, 권한관리 등을

효율적으로 행할 수 있는 온라인 서비스 제공

➡️➡️소프트웨어 개발 / 배포 프로세스의 효율성이 크게 증대

https://hub.docker.com/

Docker Hub Container Image Library | App Containerization

도커설치하고 맛보기

Docker Desktop과 Docker Engine

❄️Docker Desktop for Linux

🔸GUI 제공 - 보다 간단한 컨테이너 및 서비스 관리가 가능

🔸Docker Engine을 포함, 그러나 Windows 및 MacOS의 경우와 마찬가지로 VM 위에서 실행

❄️Docker Engine for Linux

🔸Docker는 Linux의 프로세스 컨트롤 그룹을 이용하여

호스트 커널의 서비스들을 이용하며 격리되어 실행

🔸여기에서는 이 방법을 활용하는 것으로 가정

도커의 구성요소

도커 이미지와 도커 컨테이너

도커 이미지 (Docker Images)

• 응용을 실행하는데 필요한 모든 파일들과 그것을 실행하는 방법을 한데 묶어 놓은 것
• 상태를 저장하지 않는 stateless 방식 - 네트워크로 전송, 레지스트리에 저장, 이름 및 버전 지정 가능
• 계층화되어있다는 특징을 갖고 있으며, 어떤 이미지로부터 다른 이미지를 만드는 것이 가능

도커 컨테이너 (Docker Containers)

• 이미지의 실행 인스턴스 (instance)
• 하나의 이미지로부터 여러 컨테이너(인스턴스)를 만들어 동일한 응용을 여러 개 실행할 수 있음(각각은 독립)
• 상태를 저장하는 stateful 방식 - 컨테이너를 사용하면서 상태를 변경할 수 있음
• 그러나 컨테이너가 소멸하면 이 상태도 잊어버림

이미지의 계층 (Layer) 구조

배운것

• 도커이미지를 이용해서 컨테이너를 만들어 실행할 수 있다.
• 도커 이미지는
  • 계층 구조를 가지고 있음
  • 컨테이너를 만드는데 이용되는 거푸집으로서 상태를 저장하고 있지 않음
  • 이미지 레지스트리를 통하여 네트워크를 통해 전송가능
• 도커 컨테이너는
  • 이미지를 이용하여 만들어진, 응용 소프트웨어를 실제로 실행하는 격리된 환경
  • 도커 엔진에 의해서 관리되며 마치 컴퓨터 하나가 새로 생겨서 정해진 일을 수행한느 것과 같은 모습을 보여줌

컨테이너와 이미지 관련 명령어 요약

✨docker run 이미지이름

이름이 주어진 이미지를 로컬에서 또는 레지스트리에서 가져다가 컨테이너 만들어 실행

✨docker ps

현재 실행중인 컨테이너들의 정보를 조회

✨docker ps-a

중단되어 있는 것까지 포함하여 모든 컨테이너들의 정보를 조회

✨docker images

로컬 컴퓨터에 가지고 있는 이미지들의 정보를 조회

✨docker stop 컨테이너이름 || ID / ctrl + c

현재 실행중인 컨테이너의 실행을 중단

컨테이너가 없어지지는 않음

✨docker rm 컨테이너이름 || ID

컨테이너를 삭제

✨docker rmi 이미지이름 || ID

이미지를 삭제

다시

도커 이미지

응용을 실행하는데 필요한 모든 파일들과 그것을 실행하는 방법을 한데 묶어 놓은 것

상태 정보를 가지고 있지 않음

도커 컨테이너

이미지의 실행 인스턴스 (instance)

실행 상태를 유지함

도커 이미지 만들기

---

💢도커 이미지 연결 이슈

docker httpd로 이미지를 생성해서 사용하는데

여기에 나온 url을 사용할 수가 없다.

그래서 포트번호 8080을 부여하고 겨우 확인할 수 있었는데,

이 방법을 통하면 포트번호나 이름을 부여하는 것이기 때문에

stateless를 경험하지 못 했다.

---

이미지 생성 자동화

Dockerfile

• 계층 구조를 이용하여 도커 이미지를 만드는 절차를 기술하는 파일 (텍스트)
• FROM [--platform=<patform>]<image>[AS<name>]
• RUN <command>
• ENTRYPOINT ['executable', 'param1', 'param2']

이미지 빌드 명령어

• docker build [OPTINS] PATH | URL | -

요약정리

도커의 편리함 (CI/CD 관점에서 생각)

• 응용을 실행하는데 이용되는 실제(물리적) 컴퓨터 환경과 독립적으로 통일된 실행 환경 제공 가능
• 이미지로부터 여러개의 동일한 컨테이너 인스턴스를 만들고 실행 가능
• 필요한 소프트웨어 도구 및 설정 파일 등을 사전에 지정해두고 알려진 상태에서 컨테이너 생성가능(자동화)

컨테이너 다루기

도커에서의 환경 변수의 이용

Dockerfile

hello.py

실행이 끝난 컨테이너의 자동삭제

🔸docker run 명령에 --rm 옵션을 붙이면 실행 완료와 함께 컨테이너 삭제

호스트의 포트와 컨테이너 포트를 연결

컨테이너 이름 지정하기

도커 컨테이너는 이름과 ID(고유 해시 값)에 의하여 식별

🔸이름을 지정하지 않으면 docker가 컨테이너를 만들 때 이름을 자동 부여

🔸그러나 관리 편의 및 자동화를 위해서 이름을 지정하는것이 필요해짐

명령어

docker run --name 컨테이너이름 이미지

도커 클린업

✨docker rm 컨테이너

컨테이너 삭제

✨docker rmi 이미지

이미지 삭제

✨docker container prune

컨테이너 전체 삭제

✨docker image prune -a

이미지 전체 삭제

컨테이너 안의 파일들과 도커 볼륨

컨테이너 안의 파일들에 접근하는 방법

❄️실행하고 있는 컨테이너와 호스트 사이의 파일 복사

명령어 ✨docker cp를 이용

❄️이미지 빌드할때 호스트로부터 파일을 컨테이너에 추가

Dockerfile안에 ADD 지시자를 활용

❄️바인드 마운트

✨docker -v 옵션으로 호스트의 특정 디렉토리를 컨테이너와 공유

❄️도커 볼륨

docker -v 옵션으로 호스트와 공유하는 것은 비슷하지만 컨테이너가 마운트하는 것은 추상화된 볼륨

파일 복사

🔥내 디렉토리에 만들어 놓은 index.html을  /usr/share/nginx/html에 복사(덮어쓰기)

🔥/usr/share/nginx/html에 있는 50x.html 파일을 지금 내 디렉토리에 복사(가져오기)

이미지 빌드에 파일 추가

Dockerfile 내에 ADD 지시자를 이용해서 호스트가 제공하는 파일을 특정 위치에 둠

🔸ADD <호스트 내 source 파일의 경로> <컨테이너 내에 배치할 파일의 경로>

바인드 마운트(bind mount)

명령어

docker run -v <호스트 경로> <이미지>

💢window의 cmd에서 '~'는 홈디렉토리를 나타내지 않으므로 💢C:/부터 경로를 절대적으로 작성하여야한다.

도커 불륨 

볼륨 생성 명령어

docker volume create <볼륨의 이름>

 

마치며

• 도커 이미지, 컨테이너가 무엇인지 설명할 수 있다.
• CI/CD에 도커의 큰 역할 이해한다.
• 레지스트리에서 이미지를 찾아 컨테이너를 만들어 실행할 수 있다.
• 기본적인 Dockerfile을 작성해서 필요한 이미지를 만들 수 있다.
  • Dockerfile에 대한 예제 찾아 참고
• 컨테이너에 이름을 부여할 수 있고, 이미지에 태그를 달 수 있다.
• 만든 이미지를 레지스트리 (도커허브)에 푸시하여 게시할 수 있다.

과제