본문 바로가기

[부트캠프] kdt 심화 과정

2025년 3월 10일(월)

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 기본 문법 정리