배포 자동화는 CI/CD를 모두 품고 있는것.
지속적 배포
- 애플리케이션 개발 및 배포 과정에서 사용되는 방식 중 하나.
- 코드 변경사항이 발생하면 자동으로 애플리케이션을 빌드하고 테스트한 후, 운영 환경에 배포하는 것을 의미한다.
- 개발 및 운영팀 간 소통 및 협업을 더욱 향상, 요구사항에 더욱 빠르게 대응
- 지속적 배포 방식은 애플리케이션의 배포 주기를 단축하고, 버그를 빠르게 발견하고 수정할 수 있도록 도와주지만 일부 조직에서는 보안과 안정성에 대한 우려가 있을 수 있다.
- 이를 위해 보안과 안정성을 고려한 개발 및 배포 프로세스를 구성하고, 지속적인 모니터링과 피드백을 통해 개선할 수 있다.
배포 자동화
✅ 배포 자동화
- 배포 자동화는 애플리케이션 배포할 때 일어나는 반복적이고 수동적인 작업을 자동화하는 방식
- 배포과정에서 발생하는 실수를 줄이고, 배포 시간을 단출해 개발자들이 더 빠르게 배포할 수 있게 도와준다.
- 안정성과 일관성을 높이는 데 도움이 되고 일일이 작업을 수행하는 것보다 일관된 결과를 얻을 수 있다.
✅ 배포 파이프라인
- 배포 파이프라인이란 소스 코드의 관리부터 실제 배포 과정을 연결하는 구조이다.
- Source 단계: Source 단계에서는 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행합니다.
- Build 단계: Build 단계에서는 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공합니다. 또한 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행합니다.
- Deploy 단계: Deploy 단계에서는 Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행합니다.
지속적 배포와 배포 자동화의 차이
지속적 배포와 배포 자동화는 모두 애플리케이션 개발 및 배포를 자동화하는 방식이지만 목적과 범위에서 차이가 있다.
✅ 지속적 배포 : 코드 변경사항이 발생하면 자동으로 애플리케이션 빌드, 테스트, 배포를 실행한다. 이는 개발팀이 애플리케이션 개발과 배포를 더 효율적이고 빠르게 수행할 수 있게 해준다.
✅ 배포 자동화 : 일반적으로 애플리케이션 배포 과정에서 수동으로 수행되는 작업을 자동으로 수행한다. 예시로 애플리케이션 빌드, 패키징, 배포를 자동으로 수행하는 스크립트를 작성하여 배포 과정에서 반복적으로 수행되는 작업을 자동화할 수 있다.
▶️ 지속적 배포는 애플리케이션 개발 및 운영의 전반적인 프로세스를 자동화하는 것이며, 배포 자동화는 특정한 작업에 대해 자동화를 수행하는 것이다.
GitHub Actions를 통한 컨테이너 지속적 배포
- 백엔드 개발자의 IDE(e.g. 로컬 환경의 IntelliJ)에서 코드 작업 후 연결된 Github 저장소로 Commit & Push.
- Github Repository에 변화가 감지되면 Github Actions가 작동.
- 작성한 Github Actions Workflow의 순서대로 명령이 실행된다. 3-1. Github Repository에 갱신된 코드에 테스트 및 빌드를 진행. (./gradlew build를 명령한 것과 같습니다.) 3-2. Repository에 있는 Dockerfile을 통해 웹 애플리케이션을 도커 이미지로 만든다.
- Github Actions Workflow에 의해 (3-2)에서 생성된 이미지가 DockerHub에 업로드.
- Github Actions Workflow에 의해 AWS EC2에 연결.
- EC2 인스턴스에 연결하기 위해선 SSH 연결, 세션매니저 연결 등 다양한 연결 방법이 있습니다. EC2를 연결하는 방식에 따라 Github Actions를 이용한 연결도 다양한 방법으로 진행될 수 있다.
- 콘텐츠에서는 세션 매니저를 이용한 방식으로 EC2 인스턴스에 연결하여 AWS CLI를 통한 세션 연결을 소개
- ~ 7. DockerHub에 올라간 도커 이미지를 EC2에 Pull을 받아와 도커를 통해 컨테이너를 8080번 포트를 통해 접근할 수 있도록 실행