URI란 통합 자원 식별자(Uniform Resource Identifier)는 인터넷에 있는 자원을 어디에 있는지 자원 자체를 식별하는 방법입니다. URI의 하위개념으로는 URL, URN이 있습니다.
URL은 Locator를 의미하며 리소스가 있는 위치를 지정합니다. 반면에 URN은 Name을 의미하며 리소스에 이름을 부여하비다. 위치는 변할 수 있지만, 이름은 변하지 않습니다. 따라서 URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화되지 않았습니다.
☁️ URL은?
URL은 네트워크 상에서 자원이 어디 있는지 위치를 알려주기 위한 규약입니다. 즉, 컴퓨터 네트워크와 검색 메커니즘에서의 위치를 지정하는, 웹 리소스에 대한 참조라고 할 수 있습니다.
흔히 우리는 URL을 웹 사이트 주소로만 알고 있지만, URL은 웹 사이트 주소뿐만 아니라 컴퓨터 네트워크상의 자원을 모두 나타내는 표기법이며 해당 주소에 접속하려면 URL에 맞는 프로토콜(http, sftp, smp ..등)을 알아야 하고, 그와 동일한 프로토콜로 접속해야 합니다
** 해당 포스팅은 '[인프런] 김영한의 HTTP 웹 기본 지식' 강의 내용을 기록용으로 정리한 글입니다. HTTP의 매우 얕고 넓은 개념을 기록한 점 참고 부탁드리며, 구체적인 내용은 추후 다른 포스팅에서 작성할 예정입니다.
IP란?
IP(Internet Protocol) 란 인터넷에 연결되어 있는 모든 장치들(컴퓨터, 서버 장비, 스마트폰 등)을 식별할 수 있도록 각각의 장비에게 부여되는 고유 주소입니다.
IP의 주요 역할은?
지정한 IP 주소 (IP Address)에 데이터 전달
패킷 (Packet)이라는 통신 단위로 데이터 전달
IP 프로토콜의 한계는?
비연결성
패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
비신뢰성
중간에 패킷이 사라지면?
패킷이 순서대로 안오면?
프로그램 구분
같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?
TCP/IP란?
TCP/IP를 알아보기 이전, 인터넷 프로토콜에 관련하여 간단하게 알아보겠습니다.
인터넷 프로토콜 인터넷에서 컴퓨터들이 서로 정보를 주고 받는데 쓰이는 통신규약. 여러가지 종류의 인터넷 프로토콜이 있으나 그 중 TCP/IP가 가장 많이 쓰이기 때문에 TCP/IP 프로토콜이라고 함께 부르는 경우가 많다.
인터넷 프로토콜은 다음과 같이 4계층으로 이루어져 있습니다. 각 계층은 인터넷 통신에서 특정 역할을 담당하며, 데이터를 전송하고 수신하는 데 필요한 기능을 분리하여 정의합니다.
프로토콜 계층에서 데이터는 어떻게 전달될까요?
데이터가 애플리케이션에서 생성되어 인터넷을 통해 전송되고, 서버에 도달하기까지의 과정을 간단하게 시각적으로 보여드리겠습니다.
TCP/IP 정의
TCP/IP는 하나의 프로토콜이 아니라 TCP와 IP를 합쳐 부르는 말입니다. TCP/IP를 사용한다는 것은 IP 주소 체계를 따라 목적지에 데이터를 전달하고, IP 라우팅을 통해 데이터가 올바른 경로로 도달하도록 한다는 의미입니다. 또한, TCP의 특징을 활용해 송신자와 수신자 간의 논리적 연결을 생성하고 데이터 전송의 신뢰성을 유지할 수 있도록 보장합니다. 즉, TCP/IP를 말한다는 것은 송신자가 수신자에게 IP 주소를 사용해 데이터를 전달하고, 데이터가 제대로 전달되었는지, 너무 빠르거나 느리지 않은지, 정상적으로 수신되었는지에 대해 이야기하는 것을 의미합니다.
☁️ TCP 특징
TCP는 전송 제어 프로토콜 (Transmission Control Protocol)이며 현재는 대부분 TCP를 사용합니다.
연결지향 - TCP 3 way handshake (가상 연결)
의미 : TCP/IP 프로토콜을 이용해서 통신을 하는 응용 프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴와 사전에 세션을 수립하는 과정
SYN(접속 요청), ACK(요청 수락)을 사용
데이터 전달 보증
전송한 데이터를 잘 받았는지 확인
순서 보장
전송한 순서대로 도착
신뢰할 수 있는 프로토콜
☁️ UDP 특징
UDP는 사용자 데이터그램 프로토콜(User Datagram Protocol)입니다.
연결지향 X - TCP 3 way handshake X
데이터 전달 보증 X
순서 보장 X
데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
추상적으로 정리하자면, IP와 거의 유사하지만, port와 체크섬 정도가 추가된 것입니다. 따라서 애플리케이션에서 추가 작업이 필요합니다.
Port 란?
포트(port)는 '논리적인 접속장소'이며, 특히 인터넷 프로토콜인 TCP/IP를 사용할 때에는 클라이언트 프로그램이 네트워크 상의 특정 서버 프로그램을 지정하는 방법으로 사용됩니다.
네트워크 상에서 통신을 할 때 IP를 토대로 해당 서버가 있는 컴퓨터에 접근하게 됩니다. 하지만 대부분의 경우 하나의 컴퓨터에는 여러 개의 서버가 실행될 수 있습니다. 이렇게 컴퓨터에 여러 개의 서버가 실행되고 있다면, 어느 서버에 접속해야 하는지 컴퓨터에게 알려주어야 합니다. 이때 사용되는 것이 바로 포트 번호입니다 !
포트 번호의 범위는 ?
포트 번호는 0~65535번까지의 범위를 가집니다. 이 중 일부는 특정 용도로 예약되어 있습니다.
1024~49151 (Registered Ports): 특정 응용 프로그램에 등록된 포트. 예: 3306번 (MySQL), 5432번 (PostgreSQL).
49152~65535 (Dynamic/Private Ports): 임시 포트로, 클라이언트가 서버와 연결할 때 동적으로 사용됩니다.
DNS란?
DNS(Domain Name System)는 도메인 이름과 IP 주소를 매핑하는 시스템입니다. 인터넷 상의 모든 장치는 고유한 IP 주소를 통해 통신합니다. 그러나 IP 주소는 숫자로 이루어져 있어 사용자가 기억하기 어렵기 때문에, 사람이 이해하기 쉬운 도메인 이름(예: www.google.com)을 사용할 수 있도록 DNS가 만들어졌습니다.
✔️ DNS의 주요 역할
IP는 기억하기 어려우며, 변경될 수 있습니다. DNS는 변경된 IP 주소를 도메인 이름에 자동으로 매핑하여, 사용자는 IP 주소 변경을 신경 쓰지 않고 도메인 이름만으로 서비스를 이용할 수 있습니다. 즉, 사용자에게는 도메인 이름만 제공되므로, IP 주소가 변경되어도 동일한 도메인 이름으로 서비스를 이용할 수 있습니다.
도메인 이름 → IP 주소 변환
사용자가 www.google.com과 같은 도메인 이름을 입력하면, DNS 서버가 이를 IP 주소(예: 142.250.190.78)로 변환하여 해당 웹사이트에 접근할 수 있도록 합니다.
사용자 친화적인 인터넷 환경 제공
IP 주소 대신 도메인 이름을 사용하므로 기억하기 쉽고, 직관적인 인터넷 사용이 가능합니다.
인터넷의 전화번호부 역할
DNS는 도메인 이름과 IP 주소를 저장하고 관리하며, 인터넷 사용자가 원하는 웹사이트에 쉽게 연결될 수 있도록 돕습니다.
GitHub Actions은 GitHub 플랫폼에서 제공하는 자동화 및 지속적 통합/지속적 배포(CI/CD) 서비스입니다. 소프트웨어 개발 라이프사이클 안에서 Pull Request, Push 등의 이벤트 발생에 따라 자동화된 작업을 진행할 수 있게 해주며 코드의 통합과 배포 프로세스를 자동화하여 개발 생산성을 향상시킬 수 있습니다.
** 하단의 글들을 모두 타블로그의 글을 참고한 추후 수정 목적의 개인 공부용 글입니다. **
시작하기
✔️ 템플릿 이용하기
공식문서의Quick Start에도 설명이 잘 되어 있듯이, 이미 기본적인 프로젝트에 대한 CI/CD 템플릿을 어느정도 지원하고 있습니다. 간단한 프로젝트라면 이미 구축되어 있는 템플릿을 활용하는 것도 빠른 CI/CD를 구축하는데 도움이 될 것 같습니다.
CI/CD를 구축하고 싶은 Repository로 이동하여 Actions 탭을 누르면 다음과 같은 화면이 보입니다. 여기서 원하는 템플릿을 가져다 쓰면 됩니다!
하지만 이번 포스팅에서는 워크플로우를 직접 구성하여 클라우드 서비스와 연동하는 과정까지 직접 작성한 내용에 대해 다루어보도록 하겠습니다.
✔️ .github/workflows/cicd.yml
처음 접하는 yaml 문법이라면, 속도가 당연히 더딜 수는 있어도 프로젝트 환경에 맞는 배포 워크플로우를 커스터마이징 할 수 있다는 장점이 있습니다.
다만, 워크플로우를 작성할 때는 yaml 파일이 프로젝트 폴더의.github/workflows/디렉토리에 위치해있는지 확인하면 됩니다.
yaml이란? yaml이란 데이터 표현 양식의 한 종류이며 기본적으로 들여쓰기(indent)를 원칙으로 하며 데이터는 Map(key-value)형식으로 작성되어야 합니다.
구성요소
Workflow
Workflow란 레포지토리에 추가할 수 있는 일련의 자동화된 커맨드 집합입니다.
하나 이상의 Job으로 구성되어 있으며, Push나 PR과 같은 이벤트에 의해 실행될 수도 있고 특정 시간대에 실행될 수도 있습니다. 빌드, 테스트, 배포 등 각각의 역할에 맞는 Workflow를 추가할 수 있고,.github/workflows디렉토리에 YAML 형태로 저장합니다.
Event
Event란 Workflow를 실행시키는 Push, Pull Request, Commit 등의 특정 행동을 의미합니다.
Job이란 동일한 Runner에서 실행되는 여러 Step의 집합을 의미합니다. 워크플로우에서 특정 이벤트에 따라 처리하는 프로세스를 구분하고 정의할 수 있습니다.프로세스는 각각의 step으로 나뉘고 이 step은 shell에서 동작하는 CLI와 동일하게 실행이 됩니다.각각의 step들 정의한 순서대로 실행되며, step 별로 동일한 환경변수를 지정할 수 있어 데이터를 공유할 수 있습니다. 기본적으로 하나의 Workflow 내의 여러 Job은 독립적으로 실행되지만, 필요에 따라 의존 관계를 설정하여 순서를 지정해줄 수 있습니다.
Actions
Action이란 Job을 만들기 위해 Step을 결합한 독립적인 커맨드로, 재사용이 가능한 Workflow의 가장 작은 단위의 블럭입니다. 반복되는 코드를 모듈이나 함수로 관리하는 것처럼 복잡하고 자주 사용되는 작업을 정의할 수 있습니다.워크플로우 내에서 자주 반복되는 스크립트를 미리 정의하여 좀 더 효율적으로 관리할 수 있습니다.이미 많은 사용자들이 불편함을 느껴 GitHub 마켓플레이스에 퍼블릭하게 배포해 놓은 action들이 많이 있으니, 참고하여 각자 개발 프로세스에 맞는 CI/CD를 구축할 수 있겠네요!
env
환경변수가 반드시 필요한 구성요소는 아니지만, 노출되어서는 안되는 민감한 정보를 환경변수로 설정하여 사용할 수 있습니다. Repository별로 환경변수를 독립적으로 설정할 수 있고, Organization을 사용한다면, 모든 Repository에 적용되는 환경변수를 관리할 수 있습니다.
Step
Step이란 커맨드를 실행할 수 있는 각각의 Task를 의미하는데, Shell 커맨드가 될 수도 있고, 하나의 Action이 될 수도 있습니다. 하나의 Job 내에서 각각의 Step은 다양한 Task로 인해 생성된 데이터를 공유할 수 있습니다.
Runner
Runner란 Github Actions Workflow 내에 있는 Job을 실행시키기 위한 애플리케이션입니다. Runner Application은 Github에서 호스팅하는 가상 환경 또는 직접 호스팅하는 가상 환경에서 실행 가능하며, Github에서 호스팅하는 가상 인스턴스의 경우에는 메모리 및 용량 제한이 존재합니다.
아래 화면과 같이Settings -> Secrets and variables (Actions) -> New Repository secret순으로 이동합니다.
Github Action이 실행되는 repository에 환경변수를 직접 추가해주었기 때문에, 이제 환경변수에 손쉽게 접근할 수 있습니다. 노출에 민감한 값을 적용할 때 권장되는 방법입니다. 환경변수를 워크플로우 내부에서 지정하여 사용하는 방법에 대해서는 Slack API 단락을 확인해주세요.
환경변수 사용 예시 아래 예시 코드는 AWS credential 인증을 위한 action 코드입니다. 이 때 필요한 값은access-key-id와secret-access-key값입니다. 하지만 외부 제 3자가 이 두가지 값을 안다면, 내부 리소스에 접근할 수 있기 때문에 환경변수로 관리해야합니다. repository에 등록한 환경변수에는{{ secrets.Name }}과 같은 방식으로 접근할 수 있습니다. Name에는 직접 입력한 환경변수의 Key 값을 입력하여 사용할 수 있습니다.
S3 버킷에 build 파일을 업로드 하여 Frontend 코드를 배포하고 해당 S3 스토리지에 저장된 파일을 CloudFront에서 전달하는 배포 프로세스를 따르고 있습니다. 우리는 build 파일을 S3에 업로드만 하면 되기 때문에 해당 워크플로우를 들여다보겠습니다.
마찬가지로 name은 원하는 워크플로우 이름을 지정해줍시다.
어떤 폴더를 빌드 폴더로 지정할 지 정해줍니다. 여기서는 build 폴더로 지정하겠습니다.
S3에 접근할 때 사용되는Action인 lbertenasco/s3-deploy@v1을 사용해줍니다.
bucket의 실제 이름과cloudfront의 dist-id 값을 repository 환경변수에 등록을 해주고, 필요한 필드에 값을 치환해주면 됩니다.
배포가 될 때마다 새로운 컨텐츠를 제공할 수 있도록 invalidation 설정을 해줍니다. 캐시 무효화 작업을 통해 배포가 되면 캐싱 데이터를 전달하지 않고 새로운 데이터를 전달합니다.
Github Action IP 주소 받기haythem/public-ip@v1.2액션을 통해 ip 값을 id에 지정해줍니다. 이 값은 이후 스텝에서 사용됩니다.
- name: Get GitHub Actions IP
id: ip
uses: haythem/public-ip@v1.2
인바운드 규칙에 IP주소 화이트리스트 등록하기SSH에 직접 접근하는 방식으로 배포를 하고 있습니다. 만약 외부에서 SSH 접속을 통해 API 내부에 침투한다면 굉장히 위험하기 때문에 인바운드 규칙에서 접속 가능한 IP 리스트를 제한하고 있습니다. 로컬 뿐만이 아니라, Github Action에서 SSH 접속을 허용해야 하기 때문에 아래와 같은 스크립트를 작성할 수 있습니다.
보안그룹 ID 값이 필요합니다.--group-id플래그에 대한 값에 지정해줍니다.
tcp port는 SSH접속 목적이기 때문에 22port로 지정해줍니다.
cidr은 Github Action의 IPv4 대역을 받아옵니다. 1번에서 id에 ip 값을 할당하고 있는데 그 값을 사용할 수 있습니다.steps.ip.output.ipv4라는 값을 사용할 수 있습니다.
name: Add Github Actions IP to Security group run: | aws ec2 authorize-security-group-ingress \ --group-id ${{ secrets.PROD_AWS_SG_ID }} \ --protocol tcp --port 22 \ --cidr ${{ steps.ip.outputs.ipv4 }}/32
Deploy to EC2
Github Action의 CIDR이 인바운드 규칙에 등록이 되었다면, CI/CD가 실행되는 네트워크에서 우리 서버 EC2로 접속할 수 있게 됩니다.
EC2에 접속하기 위해appleboy/ssh-action@master액션을 사용하며, 필요한 값은 다음과 같습니다:
AW_SSH_KEY:*.pem값을 환경변수로 지정해줍니다.
AWS_HOST: 호스트는 EC2의 인스턴스의 퍼블릭 CIDR을 가리킵니다.
실제로 Github Action이 실행되는 터미널을 확인해보면, 로컬에서 접속하는 것과 동일하게 EC2 인스턴스에 접속해있는 것을 확인할 수 있습니다. 이제 EC2 인스턴스 내부에서 리눅스 명령어를 사용하여 Backend 소스 코드를 받아오고 pm2 매니저를 활용하여 서비스를 중단하지 않고 배포를 해보겠습니다.
git pull origin “branch”
Install Dependencies (mecab-ko 설치 필요!)
pm2 reload
- name: EC2 Production Server Deploy
uses: appleboy/ssh-action@master
with:
key: ${{ secrets.PROD_AWS_SSH_KEY }}
host: ${{ secrets.PROD_AWS_HOST }}
username: ubuntu
script: |
export NVM_DIR=~/.nvm
source ~/.nvm/nvm.sh
pm2 stop 0
pm2 stop 1
pm2 save
cd 2minutes
git checkout main
git pull origin main
npm ci && node_modules/mecab-ya/bin/install-mecab ko
pm2 start 0
pm2 start 1
pm2 save
with Cache node_modules
✔️ GitHub Action은 cache를 제공한다
mecab-ko-dic을 OS에 설치하는 방법이 반드시 필요하다!
GitHub Actiond에서는 특정 파일을 해시값으로 바꾸어 해당 파일을 캐싱할 수 있습니다. 아래 소스 코드를 살펴보겠습니다.
- name: Cache Dependencies
id: dependency-cache
uses: actions/cache@v3
with:
# 캐시 대상이 되는 파일입니다.
# node_module 디렉토리의 하위 내용을 모두 캐시하겠다는 의미입니다.
path: "**/node_modules"
# 캐시를 식별할 때 사용하느 옵션입니다.
# npm-package 대신 저장하고 싶은 캐시 키 값을 사용할 수 있습니다.
# ${{ hashFiles('**/package-lock.json') }}은 package-lock.json 파일 내용을 해시값으로 저장합니다.
# 여기서 해싱이 되어 저장된 package-lock.json 파일과 새로운 commit 코드의 package-lock.json 파일이 일치하는지 확인합니다.
key: npm-package-${{ hashFiles('**/package-lock.json') }}
# 캐싱이 되어있는 해시 파일을 찾습니다.
# 해시 파일을 찾는 기준은 restore-keys에 등록된 순으로 찾습니다.
# 예를 들어, Caches에 npm-package-1, npm-package-2, npm-package-3 이라는 파일이 있다고 가정해봅시다.
# 이 때 package-lock.json의 해싱 파일이 npm-package-1로 되어 있다면, npm-package-1을 기준 캐시 데이터로 지정합니다.
# 지정된 캐시 파일은 commit의 package-lock.json 파일을 비교하는 작업을 하게됩니다.
# *** PR이 달라도 기존 캐시 파일을 찾기 때문에 local-build & test 속도를 향상시킬 수 있습니다. ***
retore-keys: |
npm-package-${{ hashFiles('**/package-lock.json') }}
npm-package-
만약 새로 개발한 작업에서 써드파티 라이브러리를 사용하는 경우 새로운 디펜던시가 추가가 될 것입니다. 그럼 새로운 작업 소스 코드의package-lock.json파일과 캐싱된 파일을 비교하여, 변동 사항이 없다면 굳이 디펜던시를 다시 설치하여 사용할 필요가 없다고 판단하게 됩니다.
with Slack Message
✔️ Slack 수신웹후크 (Incoming Webhook)
Github Action에서 Slack 메시지를 보내는 방법은 이 포스팅에서 소개하는 방식 외에도 다양한 방법이 이습니다. 그 중 Slack API의 수신웹후크를 사용하여 CI/CD의 결과를 Slack 메시지로 보내는 방법에 대해 소개해보겠습니다.
앱 생성 방식이 아닌앱 추가 방식을 우선 소개합니다. 만약 회사 공용 slack 계정으로 추가할 경우 앱 추가 방식이 문제가 되진 않지만, 팀을 떠날 가능성이 있다면 개인 계정을 사용할 경우 앱 생성 방식을 권장합니다.
앱 추가 절차
앱 관리 > Incoming Webhook 검색 > 원하는 채널에 추가
구성 편집의웹훅 URL정보 확인.(Github Repository의 환경변수로 지정해줍니다.)
✔️ Github Action에서 슬랙 메시지 전송하기
슬랙메시지 전송 job 구성하기local 테스트 및 staging & production에 코드를 배포하는 job이 종료가 되면, CI/CD의 결과를 슬랙 메시지로 전송하기 위한 job을 추가해보겠습니다. 슬랙 메시지는 결과가 어떻든 항상 보내져야 하는 작업이기 때문에 조건을 추가해줍니다.always()함수를 통해 위에서 실행된 CI/CD의 결과가 어떻든 해당 job은 항상 실행이 되도록 지정할 수 있습니다. 선행 결과를 고려하지는 않아도 반드시 필요한 선행 결과를 지정해주어야 그 결과를 슬랙 채널에 전달할 수 있기 때문에needs옵션을 사용하여 반드시 선행되어야 하는 job의 이름을 지정해줍니다.
슬랙메시지 커스터마이즈로컬테스트, staging & production 서버 배포의 결과에 따라 상태메시지 (STATUS)와 슬랙에서 사용될 이모지 (IMOJI)를 커스터마이즈 할 수 있습니다. run 옵션에 아래와 같은 리눅스 명령어를 작성해줍니다.if … then … elif … then fi구문은 조건절을 나타냅니다. 조건절은 항상fi를 작성하여 구문을 종료합니다. 우선, github.ref라는 변수에 접근하여 Github Action이 실행될 때 저장되는 branch의 이름을 받아올 수 있습니다. 해당 값에 따라 슬랙 메시지에 보여질BUILD_NAME변수에 값을 동적으로 지정해줄 수 있습니다.
... slack_notification jobs ...
steps:
- name: CUSTOM_STATUS SET UP
run: |
if [ "${{ github.ref }}" = "refs/heads/develop" ];
then
BUILD_NAME="Staging Deploy"
elif [ "${{ github.ref }}" = "refs/heads/main" ];
then
BUILD_NAME="Production Deploy"
else
BUILD_NAME="Local Build & Test"
fi
다음으로 needs 옵션에 추가했던 선행 job들의 결과에 따라 슬랙메시지에 보여질 상태메시지와 이모지를 지정해주는 스크립트입니다.needs.지정한_job_이름.result을 통해 해당 job의 실행결과를 받아올 수 있습니다. 실행 결과 값은 아래와 같습니다:
success: 성공
failure: 테스트 또는 빌드 실패, 내부 네트워크 에러 등
cancelled: 의도적 중단 혹은 내부 네트워크 에러 등해당 job에서 사용될 환경변수를 GITHUB_ENV에 추가하여 실제로 그 값을 호출하고 사용할 수 있도록 지정해줍니다.
... slack_notification jobs ...
steps:
- name: CUSTOM_STATUS SET UP
run: |
... BUILD_NAME Set up...
... STATUS & IMOJI Set up...
echo "CUSTOM_STATUS=${CUSTOM_STATUS}" >> $GITHUB_ENV
echo "BUILD_NAME=${BUILD_NAME}" >> $GITHUB_ENV
echo "SLACK_EMOJI=${SLACK_EMOJI}" >> $GITHUB_ENV
echo "key: value" >> 환경변수_등록_파일을 통해 환경변수를 지정해줄 수 있습니다:
... slack_notification jobs ...steps:-name: CUSTOM_STATUS SET UP run:| ... BUILD_NAME Set up... if [ "${{ needs.local_build_test.result }}" = "failure" ] || \ [ "${{ needs.deploy_staging.result }}" = "failure" ] || \ [ "${{ needs.deploy_production.result }}" = "failure" ]; then CUSTOM_STATUS="Failure" SLACK_EMOJI=":boom:" elif [ "${{ needs.local_build_test.result }}" = "cancelled" ] || \ [ "${{ needs.deploy_staging.result }}" = "cancelled" ] || \ [ "${{ needs.deploy_production.result }}" = "cancelled" ]; then CUSTOM_STATUS="Aborted" SLACK_EMOJI=":exclamation:" else CUSTOM_STATUS="Success" SLACK_EMOJI=":rocket:" fi
✔️ Webhook을 이용하여 슬랙메시지 보내기
슬랙 메시지 전송 옵션은 아래와 같습니다.
사용 Actionuses
rtCamp/action-slack-notify@v2
슬랙 메시지에 전달 되는 변수env
SLACK_WEBHOOK 첫번째 단계에서 Github Repository에 지정한 환경변수를 불러옵니다.
MSG_MINIMAL 웹훅에서 기본값으로 보내주는 값들입니다. 불필요한 값은 해당 필드에 추가하여 제거해주고 더욱 깔끔한 슬랙 메시지로 커스터마이즈 할 수 있습니다.
SLACK_CHNNEL 슬랙 메시지가 전송 될 채널을 지정해줍니다.
SLACK_COLOR job의 실행 결과의 색을 따르도록 지정합니다. 커스터마이즈 가능합니다.
SLACK_ICON 슬랙메시지가 보내질 때 프로필 사진을 지정할 수 있습니다. 커스터마이즈 가능합니다.
SLACK_USERNAME 슬랙메시지가 보내질 때 이름을 지정할 수 있습니다. 커스터마이즈 가능합니다.
SLACK_TITLE ${{ env.GITHUBENV에등록한_환경변수_key }} 구문을 활용하여 슬랙메시지가 보내질 때 타이틀을 지정할 수 있습니다.
CI/CD(Continuous Integration/Continuous Deployment or Delivery)는 코드 통합, 테스트, 빌드, 배포 과정을 자동화하여 개발 효율성을 높이고 품질을 유지하기 위한 소프트웨어 개발 방법론
1. CICD의 주요 개념
일반적인 앱의 개발 및 유지보수 단계는 아래와 같습니다. 여기서 지속적 통합 및 지속적 전달을 단계별로 자동화할 수 있습니다.
CI (Continuous Integration) ' 지속적인 통합 '
개발자를 위한 자동화 프로세스라고 볼 수 있으며, Code - Build - Test 단계를 자동화할 수 있습니다.
Code : 개발자가 코드를 원격 코드 저장소 (Ex. github repository)에 push하는 단계 Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계 Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정
애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있습니다.
이전에는 각자 개발자가 작성한 코드를 합치고 난 후, 모두 모여서 빌드를 시작하고 나서야 문제점을 파악할 수 있었습니다. 지속적 통합이 적용된 개발팀은 코드를 머지하기 전, 이미 빌드 오류나 테스트 오류를 확인하여 훨씬 더 효율적인 개발을 할 수 있게 됩니다.
개발자가 작성한 코드를 자주(하루에도 여러 번) 저장소에 통합하는 프로세스.
코드가 통합될 때마다 자동으로 테스트와 빌드를 실행
CD (Continuous Delivery & Deployment) ' 지속적인 제공 & 배포 '
Release - Deploy - Operate 단계를 자동화할 수 있습니다. 지속적으로 통합된 코드를 자동으로 프로덕션 환경에 배포하는 프로세스이며 즉, 개발자가 원클릭으로 수작업 없이 빌드, 테스트, 배포까지의 자동화를 할 수 있습니다.
코드 변경 사항이 테스트 및 승인을 거쳐 자동으로 프로덕션 환경에 배포 (merge to main) 되고, 새로운 기능과 버그 수정 사항이 실제 사용자에게 빠르게 제공됩니다.
Release : 배포 가능한 소프트웨어 패키지를 작성 Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출 > 실질적인 배포 Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지
Continuous Delivery: CI에서 생성된 빌드 결과물을 수동 승인 후 프로덕션 환경에 배포.
Continuous Deployment: CI에서 생성된 결과물을 자동으로 프로덕션 환경에 배포.
2. CI/CD 파이프라인의 주요 구성
개발자가 배포할 때마다 일일히 빌드하고 배포하는 과정을 진행하는 것은 한두 번이면 충분하겠지만, 이러한 과정이 수없이 진행된다면 일일히 이 과정을 수행하는 것이 번잡스럽고 지루할 것이다. 그래서 이 수없이 진행되는 배포 과정을 자동화시키는 방법을 구축하게 되는데, 그것을 CI/CD 파이프라인이라고 한다.
2.1 소스 코드 관리 (Source)
GitHub, GitLab, Bitbucket과 같은 플랫폼에서 소스 코드를 관리
브랜치 전략(예: Git Flow, Trunk-Based)을 활용하여 작업 분리
2.2 빌드 (Build)
코드를 컴파일하고 의존성을 설치하여 실행 가능한 상태로 만드는 단계
ex )
FE : npm run build
BE (Java): mvn clean package
2.3 테스트 (Test)
단위 테스트: 기능별 코드가 올바르게 동작하는지 확인
통합 테스트: 여러 컴포넌트 간 상호작용 테스트
E2E 테스트: 실제 사용자 환경에서의 테스트
2.4 배포 (Deploy)
스테이징 환경: 실제 배포 전에 테스트를 위한 환경
프로덕션 환경: 사용자에게 제공되는 환경
배포 도구: Kubernetes, AWS ECS, Docker Swarm 등
3. CI/CD의 주요 도구
3.1 CI/CD 플랫폼
GitHub Actions: GitHub 기반 CI/CD 워크플로우 GitLab CI/CD: GitLab 내장 CI/CD 기능 Jenkins: 오픈소스 CI/CD 서버 CircleCI: 클라우드 기반 CI/CD 서비스 TravisCI: 간단한 설정으로 CI/CD 제공
3.2 빌드 및 테스트 도구
FE : Jest, Mocha, Cypress (테스트), Webpack (빌드) BE (Java) : JUnit (테스트), Maven/Gradle (빌드)
3.3 배포 도구
Docker: 컨테이너 기반 애플리케이션 배포 Kubernetes : 컨테이너 오케스트레이션 도구 AWSECS/EKS : AWS의 컨테이너 관리 서비스 GoogleCloudBuild : Google Cloud의 CI/CD 서비스
