CI - 지속적인 통합, 개발자간의 코드 충돌 방지를 위해 특정 주기에 저장소를 자동으로 빌드하는 것
CD - 지속적인 배포, 코드의 변경이 감지되면 서버에서 자동으로 배포하는 작업(서비스의 일시적인 중단없이 새로운 기능을 적용)
CI/CD 장점
- 자동화 시스템(테스트와 배포)
- Incremental Change(기능을 단계적으로 개발)
AWS - Code Commit
- github repository와 같은 파일 저장소
- 동시에 여러 명이 접근, 수정이 가능
- 버전 컨트롤 가능(변경된 정보 확인 - 언제, 어떻게, 누가 / 이전 버전으로 되돌리기)
code merge option ( feat -> master branch 병합 )
- git merge --ff-only : 마스터의 마지막 커밋 feat의 커밋이 되는 것
- git merge --squash : 병합할 브랜치의 모든 커밋을 하나의 커밋으로 합쳐 commit을 새로 생성하고 마스터에 코드 병합
- git merge --no-ff : fast-forward 관계(--ff--only)여도 강제로 merge commit을 생성하고 마스터에 코드 병합
AWS - Code Build
- Code Commit으로 변경된 코드를 토대로 컴파일, 테스트, 패키지 등을 생성하는 도구(변경 내역과 같은 여러 정보들을 확인 가능)
AWS - Code Deploy
- 새로운 기능의 빠른 배포(서버 다운 X)
- 기존 매뉴얼에 따른 에러 방지(ex. 새로운 개발자가 왔을 때 생길 실수 방지)
- Code Deploy Agent : 배포 과정에서 사용할 수 있게 해주는 소프트웨어 패키지(배포 과정에서 이벤트를 수신하는 등의 기능을 가능하게 한다)
- Agent로 배포를 하기 위해 EC2, S3 접근 및 배포할 수 있는 IAM 역할을 생성한다.
- PID - 프로세스 고유 ID(인스턴스에 따라 다름)
- 배포 그룹(호스트를 생성하여 codeDeploy를 담당하는 매개체) 생성
- 배포 방식(w. ELB)
- Rolling : 하나의 인스턴스에 먼저 새로운 기능을 적용시킨 뒤 새로운 버전의 서버로 대체하는 방식(점층적)
사용 이유 ) 첫 배포에서는 또 다른 배포 환경을 구축할 필요도 없고, 하나의 인스턴스만 적용시키면 되기 때문에 사용된다.
단점 ) 이전 방식으로 돌아가기 어려움. 배포했던 방식과 동일하게 하나씩 이전 배포된 버전으로 돌려야한다.
- Blue/Green : Blue 서버의 traffic양을 점차 줄여 새로운 기능이 적용된 Green 서버로 유저를 옮기는 방식(목적 - Blue 서버 셧다운)
특징 ) Blue 서버가 셧다운되지 않은 상태에서 또 다른 하나의 배포 환경(Green) 구축
AWS - Code Pipeline
- 빌드, 테스트 배포 과정을 관리
- workflow를 정의해 코드 변경을 감지(trigger), 관리할 수 있다.
- 어플리케이션 출시 자동화
- Code Commit -> Build -> Deploy 과정을 자동화
- 출시 : 모든 테스트, 배포가 이루어져 사용자에게 전달되는 마지막 단계
EC2 nginx HTTPS 설정 오류
AWS EC2 환경이 바뀌게 되면서 linux기반으로 EC2를 구동할 경우
도메인 HTTPS 인증서 설정(certbot)과 nginX 설정이 이전과 달라 적용하는 데 문제가 있었다.
공식 문서에서는 repository 구성(EC2 하드디스크 개념)이 달라졌기 때문에 설치할 필요가 없는 부분들이나 버전에 따라 변경된 부분을 적용시켜주어야하는 것 같다.
FE 개발자 성장 기록 👩🏻💻