개요
배포 자동화를 구현하면 자동화된 프로세스에 따라 테스트 환경과 프로덕션 환경 간에 소프트웨어를 이동할 수 있게 됩니다. 따라서 소프트웨어 제공 주기 전반에 걸쳐 안정적으로 배포를 반복할 수 있습니다.
배포 자동화를 통해 애플리케이션 배포에 작업자가 직접 관여하지 않고도 새로운 기능과 애플리케이션을 더 빨리, 더 자주 출시할 수 있습니다.
지속적인 통합/지속적인 제공(CI/CD)과 배포 자동화
배포 자동화는 DevOps 사례를 지원하고 CI/CD 파이프라인을 관리하는 데 중요한 요소입니다.
지속적인 통합/지속적인 제공(CI/CD)은 통합 및 테스트에서 제공 및 배포에 이르는 라이프사이클 전체를 지속적으로 자동화하고 끊임없이 모니터링하면서 고객에게 애플리케이션을 보다 짧은 주기로 제공하는 방법입니다.
지속적인 통합은 일반적으로 개발자의 애플리케이션 변경 사항을 자동으로 버그 테스트하여 리포지토리(예: GitHub 또는 컨테이너 레지스트리)에 업로드하는 것을 의미합니다. 그런 다음 운영팀에서 직접 또는 배포 자동화를 통해 리포지토리의 변경 사항을 라이브 프로덕션 환경에 배포할 수 있습니다.
개발자의 애플리케이션 변경 사항이 병합된 뒤 자동으로 애플리케이션을 빌드하고 다양한 수준의 테스트(대개 단위 테스트 및 통합 테스트)를 자동으로 실행하여, 변경 사항으로 인해 애플리케이션에 문제가 생기지 않는지 검증합니다.
지속적인 서비스 제공이란 무엇인가요? CI/CD 파이프라인을 이용해 애플리케이션 개발 자동화에 기여하는 방법을 알아보세요.
"CD"는 지속적인 배포(Continuous Deployment)를 의미하기도 하는데, 이 경우에는 리포지토리에 있는 개발자 변경 사항을 고객이 사용할 수 있도록 자동화된 배포를 통해 프로덕션 환경에 릴리스하는 것을 말합니다.
배포 파이프라인에서 프로덕션 이전인 이 단계에는 수동 배포 게이트가 없기 때문에 지속적인 배포를 위해서는 잘 설계된 테스트 자동화가 반드시 필요합니다.
자동화를 통한 지속적인 배포는 애플리케이션 제공 속도를 저하시키는 수동 프로세스로 인해 운영팀의 업무가 가중되는 문제를 해결합니다.
배포 파이프라인의 다음 단계를 자동화하는 지속적인 배포를 통해 지속적인 통합의 이점이 실현됩니다.
DevOps에도 자동화 활용
CI/CD를 성공적으로 구현하려면 개발팀과 운영팀이 DevOps 또는 사이트 신뢰성 엔지니어링(SRE) 접근 방식에 따라 민첩하게 상호 협력하면서 지원해야 합니다.
소프트웨어 개발에 애자일 방법론을 채택하면 출시 주기가 단축되고, 다운타임이 줄어들며, 새로운 버전이 나올 때까지 기다리지 않고도 오류를 즉시 수정할 수 있습니다.
개발팀과 운영팀의 애플리케이션 배포 방식 또는 환경 설정 방식이 서로 다른 경우 배포 자동화는 불가능합니다.
일관성이 있는 환경이어야 자동화할 수 있습니다. 다시 말해 프로덕션 환경을 비롯한 모든 환경에서 동일한 배포 프로세스를 사용해야 합니다.
각 팀의 프로세스가 일치하지 않으면 운영팀에서 배포를 수동으로 처리하다가 오류와 불일치가 발생하고 결과적으로 출시 주기가 더 길어질 위험도 있습니다.
그렇기 때문에 개발팀과 운영팀은 반드시 DevOps 사례에 따라 서로 협력해야 합니다. 즉, 개발팀과 운영팀이 협업을 통해 일관되고 반복 가능한 배포 자동화 프로세스를 만들어야 합니다.
소프트웨어 배포 프로세스 자동화
배포 파이프라인은 일반적으로 빌드, 테스트, 배포의 3가지 주요 단계로 이루어집니다(더 많을 수도 있음). 이 파이프라인을 통해 배포 프로세스를 자동화하고 코드를 커밋 단계에서 배포 단계로 빠르게 이동할 수 있습니다.
- 빌드: 개발자가 소프트웨어 리포지토리에 코드를 커밋합니다. 코드 변경 사항은 프로덕션 환경과 일치하는 환경에 통합합니다.
- 테스트: Jenkins나 Ansible과 같은 배포 자동화 툴에서 새로운 코드를 인식하고 일련의 테스트를 트리거합니다. 모든 테스트를 통과한 빌드는 프로덕션 환경으로 릴리스할 수 있습니다. 배포 자동화 프로세스가 없으면 이 단계를 수동으로 처리해야 합니다.
- 배포: 이 단계에서는 애플리케이션이 프로덕션 환경에 배포되어 사용자에게 제공됩니다.
애자일팀이나 DevOps팀에서는 개발과 동시에 테스트를 진행해야 합니다. 그리고 개발팀에 지속적으로 피드백을 전달해야 합니다.
지속적인 통합은 개발 프로세스의 중요한 부분으로서 이처럼 빈번한 업데이트가 서로 충돌하지 않게 해줍니다. 지속적인 통합이 제대로 구현되면 애플리케이션 코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합됩니다.
물론 환경에 온디맨드로 배포할 수도 있어야 합니다. 원하는 환경을 만들기 위해 요청을 해야 한다면 프로세스가 자동화되지 않은 것입니다.
Red Hat Ansible Automation Platform을 이용한 배포 자동화
Red Hat® Ansible® Automation Platform에는 플레이북, 시각적 대시보드, 분석 등 전사적 자동화를 구현하는 데 필요한 툴이 모두 포함되어 있습니다.
Red Hat Ansible Automation Platform을 이용하면 하나의 공통 프레임워크에서 멀티 티어 애플리케이션을 안정적이고 일관성 있게 배포할 수 있습니다. 필요한 서비스를 설정하고 애플리케이션 아티팩트를 푸시하는 것도 공통 시스템에서 처리할 수 있습니다.
YAML로 작성된 Ansible Playbook에는 원하는 시스템 상태가 기술되어 있으며 일반적으로 소스 제어를 통해 이러한 상태를 유지합니다. 그리고 Red Hat Ansible Automation Platform은 시스템의 현재 상태와 관계없이 바람직한 상태로 만들어 줍니다.
Ansible Playbook을 이용하면 설치와 업그레이드는 물론 일상적인 관리도 반복적이고 안정적으로 수행할 수 있습니다.
뿐만 아니라 Red Hat Ansible Automation Platform은 2020년 3분기 Forrester Wave™: 인프라 자동화 플랫폼 부문에서 Forrester Research가 선정한 리더 제품입니다.
기업이 원하는 것은 손쉽게 자동화를 구현하고 여러 프로젝트 및 팀에 걸쳐 자동화를 공유하고 재사용하는 것은 물론 적절한 수준의 거버넌스와 제어를 적용할 수 있는 솔루션입니다.
효과적인 자동화 솔루션으로 새로운 애플리케이션과 서비스를 더 신속하게 배포하고, IT 인프라를 더 효율적으로 관리하고, 애플리케이션 개발의 생산성을 높여 보세요.