# 배포와 CI/CD
# 배포(Deployment)
한 프론트엔드 개발자가 있습니다. 열심히 코드를 작성한 뒤, 나름대로 테스트까지 마쳤습니다. 그리고 이제 인터넷으로 사용자들 해당 웹 사이트에 접속하게 만들고 싶습니다. 어떻게 하면 사람들에게 웹 사이트에 접속하게 할 수 있을까요?
가장 간단한 방법은 인터넷이 연결되어있는 컴퓨터를 하나 산 뒤, 이 컴퓨터(서버)에 개발한 웹 소스 코드를 다운받은 후, 실행시키는 것이죠.
TIP
실제로 카페24 (opens new window)와 같이 컴퓨터를 빌려주는 웹 호스팅 서비스를 이용하면 웹 소스 코드를 올려 손쉽게 외부에 공개할 수 있습니다.
이렇게 프로그램(소스 코드)을 외부 환경에 설치하고 실행하는 일련의 과정을 배포
라고 합니다.
더 예를 들면, 새로운 모바일 앱을 앱스토어에 등록하는 것도 배포입니다. 기존에 있던 웹 서비스를 업데이트하는 작업도 배포라고 할 수 있습니다.
# 배포 방법의 변화
그렇다면 배포는 보통 어떻게 할까요? 세월이 지나면서 배포 방법도 많은 변화가 있었는데, 이에 대해 간략히 살펴봅시다. (절대적인 순서는 아닙니다)
# 직접 소스 코드 설치 & 실행하기
초기에는 서버에 직접 코드를 설치했습니다. 예를 들면 디스크나 CD, 지금으로 치면 USB 같은 디스크에 소스 코드를 담아, 서버가 있는 곳으로 가서 소스 코드를 직접 다운받아 실행시키는 것이죠. 배포는 할 수 있으나, "서버가 있는 곳까지 소스 코드를 들고 매번 가야 하는 불편함"이 존재했습니다.
# FTP나 원격저장소로 설치 & 실행하기
인터넷의 발달로 이제 인터넷을 통해 서버에 접속할 수 있게 되었습니다. 이제 직접 코드를 들고 컴퓨터가 있는 곳까지 가지 않고, FTP를 통해 서버에 소스 코드를 업로드합니다. 또는 GitHub와 같은 코드 원격 저장소를 통해 작업한 코드를 업로드하고, 서버에서 다운받아 설치합니다. 이후 서버에 접속하여 소스 코드를 실행시켜 배포합니다. 이전보다 훨씬 편해졌습니다.
하지만 서버가 여러 대인 경우, 이런 작업을 서버 개수만큼 해야하는 불편함은 여전히 존재했습니다. 또한 서버의 운영체제나 환경설정에 따라 내가 작성한 소스 코드가 실행되지 않는 일도 발생했습니다. 예를 들어 윈도우 환경에서 코드를 개발하고 테스트할 땐 문제가 없었는데, 서버의 운영체제인 리눅스에서 실행하면 문제가 발생하는 것입니다.
한 서버에 여러 개의 서비스를 실행할 때도 문제가 되었습니다. 예를 들어 서버에 A라는 서비스가 실행되고 있었다고 합시다. B라는 서비스를 이 서버 위에 또 배포하고 싶어 B 코드를 설치합니다. 이때 B를 설치하는 과정에서 A라는 서비스가 사용하고 있던 운영체제의 설정이 바뀌거나, 라이브러리가 바뀌는 부작용이 발생할 수 있습니다. 두 서비스는 독립적인 서비스인데, 같은 실행 환경을 공유하고 있기 때문에 이런 현상이 발생하게 된 것입니다.
이 때문에 "코드를 실행하는 환경"과 "배포의 독립성" 이 중요한 이슈로 떠오르게 됩니다.
# VM 위에서 배포하기
VM 등장 이후 이제 배포에 VM을 적극적으로 활용합니다. VM을 사용하면 윈도우 환경에서 개발해도, 실제 서버에 배포 하기 전에 VM으로 리눅스 환경을 구축하여 이 위에서 실행을 테스트할 수 있게 됩니다. 그리고 서버에도 마찬가지로 VM을 사용하여 테스트했던 환경과 똑같은 운영체제 환경을 구축할 수 있습니다. 이를 통해 "코드를 실행하는 환경"을 일관되게 가져갈 수 있었습니다.
# 컨테이너 기반(Docker)으로 배포하기
컨테이너는 VM 이후에 등장합니다. VM보다 가벼운 컨테이너 기술을 활용해 배포에 더 적극적으로 활용하게 됩니다. 현재 IT 회사에서 이뤄지는 대부분의 배포는 Docker를 통해 이루어집니다. 구체적으로는 다음의 과정을 거칩니다.
- 먼저 코드 개발을 완료합니다.
- 이제 배포를 할 단계입니다. 위처럼
Dockerfile
을 작성합니다. docker build
명령어를 입력하면 위Dockerfile
을 읽어 이미지를 만들게 됩니다. (보통 이를 "빌드"라고 표현합니다.)- Dockerhub와 같은 이미지 저장소에 만든 이미지를 업로드 합니다.
- 배포할 서버에 접속하여, 업로드한 컨테이너 이미지를 다운받은 뒤
docker run {컨테이너 이미지 이름}
으로 실행합니다.
Docker를 사용하면 VM보다 가벼우면서도 독립적인 실행환경을 갖출 수 있습니다. 또한 Dockerfile
내에 실행하기 위한 모든 설정이 기록되어 있기 때문에, Docker 문법을 아는 사람이라면 쉽게 실행환경을 이해할 수 있고 재현할 수 있습니다.
Docker의 이런 혁신적인 장점 때문에 현재 소스 코드를 배포하는데 Docker가 폭발적으로 쓰이고 있습니다.
# CI/CD
(출처: https://www.edureka.co/blog/content/ver.1531719070/uploads/2018/07/Asset-33-1.png)
Docker로 인해 이전보다 배포하는 속도가 빨라지고 더욱 자주 하게 되었습니다. 하지만 더 자주, 더 빨리 배포하기 위해선 배포 과정을 최대한 자동화하는 게 중요합니다.
- Docker 컨테이너 이미지를 빌드하는 과정
- 빌드된 이미지를 저장소에 업로드하는 과정
- 업로드한 컨테이너 이미지를 서버에서 다운받아 실행하는 과정
만약 위 과정이 자동화되면 팀원들이 더 빠르고 쉽게 배포를 진행할 수 있게 됩니다. 예를 들면 작업한 코드를 원격 저장소(GitHub)에 올리게 되면, 즉시 위 세 과정이 순차적으로 동작하도록 할 수 있습니다.
GitHub에 개발한 코드만 올리면 바로 배포가 되는 것이죠. 이를 지속적 통합/지속적 배포(Continous Integration / Continous Deployment), 일명 CI/CD
라고 부릅니다.
*CI (Continous Integration)
CI/CD에서 CD는 주로 "배포"를 의미하는 한편, CI는 주로 "테스트와 빌드"를 의미합니다. 위 내용에서 "테스트"에 대한 내용은 포함하지 않았는데 실제 현업에서는 테스트에 대한 내용까지 포함합니다. 즉 코드를 개발하면 자동으로 "테스트"하고, 테스트를 통과한 후에는 "빌드"함으로써 코드를 개발해나갈 때 지속해서 문제없이 코드를 "통합"해나가는 것입니다.
(출처: https://apifortress.com/wp-content/uploads/2020/12/CICDlogos.png)
CI/CD 도구로는 Jenkins, CircleCI, Travis, GitHub Action, BuddyWorks와 같은 것들이 있습니다. CI와 CD를 하나의 도구로 사용하기도 하며, 경우에 따라서 분리하여 사용하기도 합니다.
이러한 CI/CD 개념과 도구 덕분에 개발자들은 더욱 빠르게 배포할 수 있었습니다. 빠르게 배포 후 피드백을 받으니 개발 진척 속도도 더 빨라졌습니다.
회사에서 이런 CI/CD 업무는 보통 데브옵스 엔지니어가 담당합니다. 아직 데브옵스 엔지니어 팀이 없거나, 업무가 분담되지 않은 경우 개발자들이 직접 하기도 합니다.
# 정리
- 배포는 내가 만든 작업물을 외부 환경에 공개하는 일입니다.
- 배포 방법은 직접 설치, FTP나 원격저장소, VM을 거쳐 현재는 Docker를 사용하기까지 발전 과정이 있었습니다.
- 좀 더 자주, 빠른 배포를 위해 CI/CD 개념과 도구들이 생겨났습니다.
- CI/CD로 개발과 배포를 막힘없이 진행할 수 있습니다.
# 더 읽어보면 좋을 내용
- Docker와 관련된 내용들
- 서비큐라님 블로그 - 쿠버네티스 시작하기 - Kubernetes란 무엇인가? (opens new window)
- 쿠버네티스는 분산 환경에서의 컨테이너 오케스트레이션 툴입니다. 회사에서는 컨테이너 배포와 관리를 빠르게 하기 위해 쿠버네티스를 많이 사용합니다.
- CI/CD와 관련된 내용들
← 가상화 기술과 도커 쿠키와 세션 →