코드로서의 인프라스트럭처(IaC, Infrastructure as code)에서 실행되는 Ansible 플레이 북 데모를 통해 GitLab CI의 강력한 기능을 살펴보세요.
GitLab CI는 코드로서의 인프라스트럭처와 GitOps를 포함하여 여러 가지 용도로 사용할 수 있는 강력한 도구입니다. GitLab 은 특정 툴에 구애받지 않지만 본 데모에서는 Ansible 을 사용합니다. 왜냐하면, 개발자가 코드로서의 인프라스트럭처에 일반적으로 사용되는 언어이기 때문입니다. 여기에서는 Ansible 네트워크 강좌의 two-router 데모를 사용합니다.
GitLab CI의 특별한 점은, 어떠한 의존성도 로컬에 설치하지 않고 Ansible 플레이 북 코드를 편집하고 배포할 수 있다는 것입니다. 보안 정책에 따라 매월 모든 장치의 SNMP 문자열 업데이트를 호출하는 데모 프로젝트는, GitLab이 제공하는 호스팅 서비스인 GitLab.com에서 모두 수행이 가능합니다.
먼저 Ansible 플레이 북을 열어 봅니다. 아래와 같이 4단계로 이루어져 있습니다:
- 라우터 정보 수집
- 버전 표시하기
- 시리얼 번호 표시하기
- SNMP 문자열 설정하기
SNMP 문자열을 설정하는 것이 본 데모의 핵심이며, 몇 단계를 거쳐 간단하게 수행할 수 있습니다.
이슈 보드에서 시작하기
GitLab에서 모든 작업의 시작은 항상 이슈를 확인하는 것으로부터 시작됩니다. 따라서 GitLab 워크플로우의 첫 번째 단계는 ansible-demo 프로젝트 내에서 이슈 보드를 확인하는 것입니다. ansible-demo 이슈 보드를 확인하면, “모든 라우터의 SNMP 문자열 변경하기 (Change SNMP Strings on all Router)” 라는 이슈가 있습니다. 이슈에는 다음과 같이 GitLab 보안 정책을 설명하는 witki 페이지 링크가 있습니다.
GitLab 보안 정책에 따르면, 매달 SNMP 문자열을 업데이트해야 합니다.
다음은 two-router 데모에서 SNMP 문자열을 설정하는 명령어들이, 이슈에 기술된 바와 같이 GitLab 의 보안 정책을 따르고 있는지 확인합니다.
SNMP 문자열을 설정하는 명령어는 Ansible 플레이 북에서 사용할 수 있습니다.
그런 다음, 이슈로 돌아와서 자신에게 할당합니다. 그리고, 이슈 오른쪽 사이드바에서 to-do를 doing으로 바꾸거나, 이슈 보드 상에서 이슈를 드래그하여 라벨 상태를 바꿉니다.
머지 리퀘스트 생성하기
다음 단계는 이슈에서 머지 리퀘스트(MR)를 생성하는 것입니다. 미완성된 상태로 마스터 브랜치와 병합되지 않도록, 작업중(WIP, Work in Progress) 플래그가 MR에 붙어있는지 잘 확인해야 합니다. 변경해야 할 SNMP 문자열이 적기 때문에, 로컬로 연결하는 대신에 GitLab 웹 IDE를 사용합니다.
- CI/CD 데모를 엽니다.
- Ansible 플레이 북을 엽니다.
- 다음의 커맨드가 수행되도록 SNMP 섹션을 수정합니다.
-snmp-server community New-SNMP-DEMO1 RO
-snmp-server community Fun-SNMP-RW-STR RW - RO 및 RW는 이슈에 기술된 GitLab 보안 정책에 따라, 다른 문자열로 설정됩니다.
변경사항 커밋하기
정책에 따라 SNMP 문자열이 업데이트되었으므로 변경사항을 커밋해 보겠습니다. side-by-side 비교 창을 열어 방금 수정한 마지막 커밋 내용이 MR에 정상적으로 업데이트되었는지 확인합니다.
side-by-side 비교 툴은 변경사항을 쉽게 시각화해주는 유용한 도구입니다.
결과 확인
변경사항이 커밋되면 GitLab CI 파이프라인이 자동으로 시작됩니다. 다음과 같은 작업이 수행됩니다.
- 구문검사
- 드라이런(Dry-runs) 테스트
- 랩(Lab)/시뮬레이션 환경에서 변경사항 테스트
GitLab CI 파이프라인에서 각 작업의 진행 상황과 출력내용을 보면서 SNMP 업데이트를 실행할 수 있습니다.
시뮬레이션 환경에서 SNMP 업데이트가 정상적으로 완료되었는지 작업 결과를 확인합니다.
모든 작업이 실행되고 MR에 그 내용이 문서화됩니다.
체크 표시는 GitLab CI 파이프라인의 각 작업이 통과되었음을 나타냅니다.
다음으로, 랩 내의 라우터에 로그인하여 변경사항을 확인할 수 있습니다.
RO와 RW SNMP 문자열에 대한 변경사항이 라우터에 반영됩니다.
MR 검토
선택에 따라 MR 승인을 구현할 수 있습니다. MR 승인을 구현하면, 변경사항을 운영에 반영하기 전에 더 많은 사용자가 이를 검토하는 것이 가능해집니다.
변경 작업을 다른 사용자들의 검토 후 마스터로 병합되도록 MR을 설정할 수 있습니다.
마스터로 병합하기
테스트가 완료되면 변경사항을 마스터에 병합할 수 있습니다. 프로덕션 환경 코드가 저장된 브랜치 입니다.
준비됐으면 작업 중 상태 해결하기(Resolve Work In Progress) 버튼을 누릅니다. 그다음 병합(Merge)을 누릅니다.
WIP 상태를 해결하면, MR이 병합되고 해당 이슈가 종료되게 됩니다.
이제, 플레이 북 실행을 위한 추가 설정을 거친 모든 테스트가 파이프라인에 의해 운영환경에서 실행될 것입니다.
파이프라인 화면에서 진행 상황과 로그를 볼 수 있습니다. 이 과정이 완료되면, 운영 라우터에 로그인하여 SNMP 보안 문자열이 업데이트되었음을 확인할 수 있습니다.
GitLab CI의 마법
GitLab CI는 이 모든 것을 마법과 같이 가능하게 해 줍니다. GitLab CI 파이프라인은 Ansible 코드를 테스트하고 구현하는 데 필요한 모든 것을 실행하는 일련의 순차적인 작업입니다.
GitLab CI는 .gitlab-ci.yml 이라는 저장소에 있는 간단한 YAML 파일로 하나로 구성됩니다.
이 데모에서는 .gitlab-ci.yml 파일에 세 단계가 포함되어 있음을 알 수 있습니다.
- 배포(Deploy): Ansible을 사용하여 AWS에서 two-router 시뮬레이션 네트워크를 생성합니다.
- 데모(Demo): SNMP 문자열을 변경하는 플레이 북을 실행합니다.
- 제거(Destroy): two-router 시뮬레이션 네트워크를 제거합니다.
GitLab CI는 기본 이미지를 사용하여 시작합니다. 이 경우, 필요한 Ansible 바이너리 및 종속성이 모두 포함된 도커(Docker) 이미지를 사용합니다. 각 단계에서 실행할 명령과 필요에 따라 종속성을 지정합니다.
GitLab CI의 3단계가 포함된 간단한 YAML 파일
Ansible 플레이 북을 실행하는 GitLab CI demo 단계의 상세한 내용
지금까지 소개한 내용은 GitLab CI를 사용하여 코드로서의 인프라스트럭처를 실행하는 방법의 한 예시일 뿐입니다.파이프라인의 내부를 살펴보면, 컴퓨터에 Ansible 종속성을 설치하지 않고도 GitLab CI를 사용하여 코드로서의 인프라스트럭처를 구축하는 방법을 확인할 수 있습니다.
이 포스트는 GitLab의 동의를 받아 공식 블로그의 영문 포스트를 우리말로 번역한 글입니다.