[테크월드=배유미 기자] ‘속도’는 소프트웨어의 중요한 요소다. 속도를 보장하기 위한 방안으로 지속적인 통합(CI: Continuous Integration)과 지속적인 배포(CD: Continuous Deployment)가 있지만, 단순히 이 CI/CD 파이프라인을 만드는 것만으로 속도를 보장할 수는 없다. CI/CD는 소프트웨어 개발주기를 최대한 활용할 수 있도록 지속적으로 개선해 줘야 한다. 4가지 요소를 통해 CI/CD 파이프라인을 신속하고 효율적으로 구동할 수 있도록 지원한다. 각 단계에 대해 하나씩 알아가 보고, 20분 만에 CI/CD 파이프라인을 설정해 보자.
기본을 이해하기
CI/CD 파이프라인을 최대한 활용하기 위해서는 계속해서 변경되는 부분들을 이해해야 한다. 간단한 것처럼 보이지만, 이와 관련된 모든 사람들이 용어와 기본을 명확하게 이해하는 것은 활용도를 높이는 데 중요하다.
CI/CD의 모든 것은 각 단계의 작업들이 모여 있는 파이프라인에서 시작된다. 일반적으로 커밋(Commit)으로 알려진 코드 변경 작업은 각 작업을 개별적으로 실행하는 에이전트 혹은 서버인 러너(Runner)가 실행해야 하는 명령에만 적용된다. 마이크로서비스와 쿠버네티스(Kubernetes) 클러스터의 아키텍처 덕분에 러너를 필요에 따라 만들 수도, 없앨 수도 있다. 또한, 빌드나 배포와 같은 작업의 각기 다른 프로세스와도 관련이 있는데, 동일한 단계의 작업들은 병렬로 수행이 가능하다.
CI/CD 파이프라인은 YAML 파일을 사용해 구성한다. 무엇을 실행할 것인지, 프로세스 성공 또는 실패 시 수행할 작업 등에 대해 파이프라인의 매개변수를 설정해야 하는데, 이를 위해서는 여러 영역에 걸쳐 있는 복잡한 프로젝트인 다중 프로젝트 파이프라인이 필요하다. 이에 대한 좋은 예시가 마이크로서비스다.
마지막으로 작업 중인 모든 CI/CD 파이프라인에 적용해야 할 몇 가지 상위 개념들이 있다. 버전 관리는 시간이 지남에 따라 변경사항을 추적하고, 필요한 경우 이전 버전으로 쉽게 전환할 수 있도록 한다. 또한, 감사 추적은 소스 코드 변경을 추적한다. 이와 같은 맥락에서 협업은 전반적인 팀이 전체 시스템을 개선·제안하고 있는지, 업데이트를 위한 코드에 얼마나 쉽게 접근할 수 있는지에 따라 달라진다. 린트(Lint) 도구는 YAML 파일이 유효한지 확인할 수 있도록 해 주며, 새로운 사용자에게 도움이 될 수 있도록 한다.
자동화 기능 내장
CI/CD라는 용어 자체는 단순하지만, 그 프로세스는 이름만큼 간단하지 않다. 대부분의 CI/CD 파이프라인은 최소 9단계를 가지고 있으며, 그보다 더 많기도 하다. 그러나 깃랩의 프로세스를 거치면, 20분 이내에 파이프라인을 구축하고 실행할 수 있다. 이처럼 시간과 과정을 대폭 줄일 수 있었던 이유는 ‘자동 데브옵스(Auto DevOps)’를 도입했기 때문이다. 자동화 기능이 내장된 CI/CD 소루션을 선택하면, 모든 과정이 간단해지며, 시간도 단축된다.
이 짧은 시간 안에, 우리는 애플리케이션을 컨테이너에 구축하고, 취약성과 의존성, 라이선스 등을 확인할 수 있다. 또한, 이를 쿠버네티스 클러스터에 배포해 호스트 이름과 DNS, TLS 인증까지 설정할 수 있다. 필요한 경우에는 자동 갱신도 가능하다.
마지막으로 코드에 대한 성능 테스트를 수행한다. 이는 집에서도 수행할 수 있는데, 쿠버네티스에 쉽게 연결하기 위해 필요한 코드는 ‘kubectl gitlab-bootstrap gitlab-project-id’다. 이는 깃랩 프로젝트에서 쿠버네티스 클러스터에 대한 자세한 내용을 확인할 수 있는 url로 생성된다.
하지만 이 모든 상황에서, 모든 것들을 자동화하는 것은 아니다. 여기에서도 앞서 언급한 ‘기본을 이해하는 과정’이 수반돼야 한다. 배포 프로세스의 각 구성요소에 대한 기본 소스 코드를 사용할 수 있어야 자동화 작업을 결정할 수 있다.
오토 스케일링 러너로 인프라 걱정 해소
파이프라인이 실행되는 것을 기다리는 시간이 낭비된다고 느껴질 수 있다. 이를 해결하기 위한 방안이 오토 스케일링 러너(Autoscaling Runner)다. 오토 스케일링은 CI/CD 파이프라인에 유연성과 실시간 서버 공급을 제공하는데, 이것이 제대로 수행되면 파이프라인의 다운타임을 거의 제거할 수 있다.
이를 시작하기 위해서는 인스턴스와 러너가 필요하다. 이는 깃랩이 무료로 제공하고 있는데, Go에 작성돼 있기에 리눅스(Linux), OSX, 윈도우(Windows), FreeBSD나 도커(Docker)를 비롯한 Go 바이너리를 구현할 수 있는 모든 플랫폼 상에서 실행이 가능하다. 또한, 몇몇 러너 설정을 통해 온디맨드 형으로 러너를 구동시킬 수도 있다.
작업이 완료되면, 러너는 다음 작업을 위해 대기하거나 자동으로 제거된다. 종료하기 전에는 유휴시간(Idle Time)을 얼마나 길게 유지할 것인지도 저장할 수 있다.
이처럼 오토 스케일링 러너를 사용하면 어떠한 것도 낭비하지 않고 최대의 효율을 뽑아낼 수 있다. 인프라를 너무 과하지도, 부족하지도 않게, 요구조건에 부합하는 최상의 골디락스(Goldilocks) 상태로 만들 수 있다. 이를 통해 개발자들은 코드 작성에만 주력할 수 있고, 운영 전문가들은 인프라에 대한 걱정을 해소할 수 있다. 이는 가장 쉽게 달성할 수 있는 상생 전략이다.
프로세스의 간소화
개발자는 새로운 모든 코드가 의존하고 있는 마이크로서비스를 손상시키지 않도록 유의해야 하며, 이를 위한 테스트도 더 많이 필요하다. 이 테스트를 수행하는 가장 효율적인 방법은 프로젝트 간 파이프라인을 설정하는 것이다.
이는 프로젝트 파이프라인을 생성할 때 간단하게 프로젝트 간 파이프라인을 트리거하는, 단순한 프로세스다. 깃랩에서는 CI구성 파일에서 트리거 작업을 수행할 수 있다. CI/CD 단계의 순서를 정리한 YAML CI 파일에 ‘트리거(Trigger)’ 키워드를 추가하면, 프로젝트 간 파이프라인을 생성하는 중개 작업이 이뤄진다. 이후 다운스트림 파이프라인에 매개변수를 설정하고, 사용할 브랜치를 정의할 수 있다. 파이프라인 그래프에서는 모든 순차와 병렬 작업은 물론, 다운스트림 파이프라인에서 발생하는 상황을 추적할 수 있도록 모든 이동하는 부분들에 대한 시각적 가이드를 제공한다.
그래도 삭제하시겠습니까?