CI/CD는 Continuous Integration, Continuous Delivery, Continuous Deployment의 약어로
(코드의) 지속적인 통합, 지속적인 (서비스) 제공, 지속적인 배포를 의미한다.
코드를 통합하는 과정, 테스트하는 과정, 배포 과정 모두 자동화를(automated) 통해 이루어진다.
→ 코드의 지속적인 통합(CI)은 코드의 변경 사항을 소스코드를 공유하는 리포지토리(저장소)에
자동으로 자주 통합하는 과정을 나타내고, 지속적인 (서비스) 제공 및 배포(CD)는
코드 변경 사항의 통합, 코드 테스트, 테스트한 소스코드를(서비스) 제공하는 과정을 의미한다.
CI/CD 파이프라인은 개발자들의 코드 변경 사항을 빠르게 통합하고(CI)
자동화된 테스트를 통해 예상대로 동작하는지(기능이 정상적으로 동작하는지) 등을 검증하고,
배포를 자동화하여 사용자들이 업데이트된 기능을 빠르게 사용할 수 있도록 한다.
도커란 어플리케이션을 패키징할 수 있는 툴(도구)이다.
도커 이미지(docker image)는 자르(*jar) 파일과 같이 실행되지 않는 OS다.
도커 이미지는 도커 컨테이너 런타임(실행할 때?)에 필요한 바이너리, 라이브러리 및 설정 값 등을 포함하고,
→ 도커 컨테이너는 애플리케이션을 실행하기 위한 실행환경을 말하며 도커 컨테이너를 사용하면 OS 환경과 무관하게
애플리케이션을 동일한 방식으로 실행할 수 있다. 바이너리, 라이브러리가 애플리케이션(소스코드)을 의미하는 것 같고,
설정 값이 해당 애플리케이션을 OS와 무관하게 동일한 방식으로 실행시킬 수 있도록 설정하는 값을 의미하는 듯??
도커 이미지는 변경되는 상태 값을 보유하지 않고(stateless) 변하지 않는다(Immutable, Read-Only)
도커 이미지와 도커 컨테이너의 관계
도커 이미지는 컨테이너에 대한 OS, 어플리케이션(소스코드), 라이브러리 등등의 정보를 담고 있다.
도커 컨테이너는 도커 이미지를 실행한 상태, 1개의 이미지로부터 N개의 컨테이너를 만들 수 있는 1:N의 관계,
자바에서 클래스(class)와 인스턴스(Instance)의 관계라고 한다.
docker container 명렁어
# docker image 목록 보기
docker images
# docker container 목록 보기
# 아무런 옵션없이 docker ps 라고만 명령하면 현재 실행중인 컨테이너의 목록만 출력한다.
# docker ps -a 라고 명령하면 현재 실행중인 컨테이너 이외의 모든 컨테이너 목록을 출력하게 된다.
docker ps <옵션>
# docker image를 통해서 컨테이너를 생성하고(create) 실행하고(start)
# docker container 안에 들어가는(attach) 명령어를 한 번에 실행하는 명령어다 --> docker run
docker run <옵션> <이미지명(이미지 id)> <명령> <매개변수>
# -d 옵션
# 컨테이너를 백그라운드에서 실행시켜야 하는 경우가 많다? 그런 상황일 때 -d 옵션주기
# --> 컨테이너가 detached 모드에서 실행되서 백그라운드에서 실행되게 할 수 있다.
# docker container 삭제하기
docker rm <container id 또는 container name>
# docker image 삭제하기
docker rmi <image id>
Github Actions
Github Actions는 Github에 내장되어 있는 CI/CD 도구이다.
Github Actions에서 CI(가 갖는 의미)란 test를 통과한 코드만
develop 브랜치와 main 브랜치에 merge 되도록함
→ 오류 방지, 안정적 코드 배포, 버그를 빠르게 발견
Github Actions에서 CD(가 갖는 의미)란 배포를
자동화하는 작업을 기술해서 빠르고 간편하게 배포한다.
---- 스파르타코딩에서 제공하는 깃허브 액션 강의 듣는데 배경지식이 부족으로 솔직히
뭔말인지 모르겠다. 강의를 멈추고 개인적으로 하나하나 검색해서 공부해야할 듯 ------
------------ youtub_큰돌의 터전 - 제대로 이해하는 CI / CD | 개발자필수지식 ------------
continuous integration(CI): 코드를 빌드하고 테스트하고 합친다.
continuous delivery: 해당 레퍼지토리(저장소)에 릴리즈 한다.
continuous deployment: 프로덕션, 즉 실제 서비스에 배포한다
→ 어플리케이션을 사용하는 유저들이 사용할 수 있도록 시장에 내놓는다?
***delivery와 deployment의 차이
delivery는 main 브랜치에 최종 코드 결과물을 머지한 것(올려놓은 것),
delivery한 다음에 사용자(실제 유저)들이 볼 수 있게끔(사용할 수 있게끔)
서비스를 제공하는 것(배포)을 deployment 라고 한다.
코드 작성(구축), 소스코드 빌드, 테스트, 배포까지 일련의 과정을 체계적으로 설계하는 것을?
CI/CD 파이프라인이라고 하고, 파이프라인 과정 내에 테스트가 있기 때문에
작성한 기능에 대한 테스트 파일을 반드시 작성해야 한다.
테스트 파일이 없으면 코드 머지(병합) 자체가 안되게 만들 수 있다.
***테스트는 함수(하나의 기능, ex. 목록 조회) 등 작은 단위를 테스팅하는 단위 테스트,
모듈을 통합할 때 테스트하는 통합 테스트,
사용자가 서비스를 사용하는 상황을 가정해서 테스트하는 엔드투엔드 테스트가 있다.
→ 엔드투엔드 테스트라는 용어는 처음 알게됨.
하나의 어플리케이션을 개발하기 위해 여러 명의 개발자들이 협업을 하고,
코드를 작성하고, 합치는(머지) 과정에서 코드의 충돌은 불가피하다.
불가피한 코드 충돌은 더 작은 단위로 발생하게 하는 것이 중요하다.
코드 머지는 너무 아토믹하게 작은 단위로 하지 않고 작은 이슈단위를 기반으로 머지한다.
-----------------------------------------------------------------------------------------------------------
github actions 파일 만들기
1. .github 디렉토리를 만들고, workflows 라는 디렉토리를 만든다
.github 디렉토리는 프로젝트 최상위 디렉토리(루트 디렉토리)에 위치해야 한다.
(디렉토리명은 정해진 것, 경로 및 철자가 틀려선 안된다)
.github ------------- 디렉토리
└ workflows ----- 디렉토리
2. 확장자가 yml인 파일을(*.yml, 야믈파일) 만들어준다.
야믈파일명은 임의작성 가능하다.
deploy.yml -----------------------------------------------------------------
# github actions 에서 이 yml 파일에 정의된 프로세스?를 하나의 workflow 로 본다.
# name 이라는 속성은 workflow 에 이름을 붙이는 개념
name: Github Actions 실행시켜보기
# github actions 가 작동하는 방식을 정하기
# 어떤 시점에 github actions 가 작동할지를 정하는 것
# 원격 main 브랜치에 push 가 발생하면 github actions 를 실행시키겠다
# (job 이하에 정의한 것: github actions 가 작동하는 로직)
# Event: 실행되는 시점을 정의
on:
push:
branches:
- main
# work flow 의 이름을 정의하는 것
# 하나의 workflow 는 1개 이상의 Job 으로 구성된다.
# 여러 Job 은 기본적으로 병렬적으로 수행된다.
jobs:
# Job 을 식별하기 위한 고유 id
My-Deploy-Job:
# ubuntu 라는 운영체제를 가진 컴퓨터였으면 좋겠어, 그 중 최신 버전(latest)
runs-on: ubuntu-latest
# Job 은 여러 개의 step 들로 구성된다.
# step: 특정 작업을 수행하는 가장 작은 단위
steps:
# step 마다 이름을 붙이기
- name: Hello World 찍기
run: echo "Hello World"
# step 추가하기
- name: 여러 명령어 문장 작성하기
run:
echo "Good"
echo "Morning"
- name: Github Actions 자체에 저장되어 있는 변수 사용해보기
run:
# Github Repository 를 보면 commit 의 고유한 값이 존재한다.
echo $GITHUB_SHA # Github Repository 에 존재하는 commit 의 고유한 값
echo $GITHUB_REPOSITORY # 깃허브에 존재하는 레포지토리명
- name: 아무한테도 노출이 되면 안되는 값
# Github Repository --> Settings --> Secrets and variables --> actions --> new repository secret 클릭
run: echo ${{ secrets.MY_NAME }} # secrets.new repository secret 에 작성한 NAME
정리
하나의 yml 파일을 하나의 workflow 라고 한다.
workflow 가 실행될 시점을 설정하는 것이 EventEvent 에 설정한 action 이 실행될 때 workflow 를 실행한다.하나의 workflow 는 여러 개의 job 들로 구성되어 있는데하나의 job 은 여러 개의 step 으로 구성되어 있다.
git 에서 github 로 파일을 올리고(로컬 브랜치에 작성된 소스코드를 원격 브랜치로 push 하고)
github 에서 github actions 를 호출한다. github actions 에서는 클라우드타입 이라는 곳으로
서버를(어플리케이션?) 배포하게 된다.
Dockerfile은 Docker Image를 build 하기 위한 것,
도커 이미지를 run 하면 도커 컨테이너가 실행된다.
dockerfile 은 어떤 파일을 실행할지, 어떤 프로그램을 설치할지,
어떤 os에서 실행할지를 적어놓은 것이다. 정리하자면 다음과 같다.
Dockerfile -- build → docker image -- run → container
참고
1. 도커(Docker)에 막 입문했다면 무조건 알아야할 필수 명령어들을 살펴보자!
2. youtube_큰돌의 터전: 제대로 이해하는 CI / CD | 개발자필수지식
3. youtube_JSCOD 박재성: CI/CD 입문·실전 - 1.4. [실습] Github Actions 기본 문법 정리
'[부트캠프] kdt 심화 과정' 카테고리의 다른 글
MSA(Microservices Architecture) 서킷브레이커 (0) | 2025.03.12 |
---|---|
MSA(Microservices Architecture) 서비스 디스커버리, 로드 밸런싱 (0) | 2025.03.11 |
2025년 3월 7일(금) (0) | 2025.03.07 |
2025년 3월 5일(수) (1) | 2025.03.05 |
2025년 3월 4일(화) (0) | 2025.03.04 |