이 시리즈의 첫 번째 부분에서는 Ansible을 사용하여 GitLab CI 파이프라인 아티팩트를 배포하는 방법을 보여줍니다. GitLab CI는 GitLab에 직접 통합되어 프로젝트를 자동으로 구축하는 지속적 통합 솔루션입니다. 간단하지만 강력한 프로비저닝 및 배포 자동화 솔루션인 Ansible과 결합된 GitLab CI는 사용하기 쉬운 지속적인 전달 파이프라인을 제공합니다. 이 기사는 먼저 관련된 물리적 및 기술적 기계에 대한 개요를 제공합니다. 그런 다음 GitLab Community Edition의 모든 GitLab 프로젝트에 대한 Ansible 배포에 대한 적절한 지원을 구현하는 방법에 대한 계획이 개발됩니다. 계획 실행에 대한 자세한 설명으로 모든 것이 완료됩니다.
기사의 첫 번째 부분은 GitLab CI & Ansible의 작동 방식을 설명하고 Ansible 배포가 GitLab 소프트웨어 환경에 어떻게 적합한지 이해하려는 모든 GitLab 사용자와 관련이 있으며, 두 번째 부분에서는 자체 호스팅 GitLab 커뮤니티 에디션이 어떻게 작동하는지 자세히 설명합니다. 관리 사용자가 Ansible 지원으로 확장할 수 있습니다.
그런 다음 이 블로그 시리즈의 다음 기사에서는 Spring Boot 애플리케이션이 GitLab CI 파이프라인 내에서 Ansible에 의해 완전히 자동으로 배포되는 방법을 보여줍니다. GitLab 자체와 GitLab CI/Runner의 설치는 이 시리즈의 초점을 벗어납니다.
로부터 git push 실행된 코드에
모든 코드 변경 사항의 자동화된 배포는 경험한 후에는 없어서는 안 될 기능입니다. 새로운 기능을 요청자에게 직접 보여주거나 테스터가 커밋할 때마다 버그 수정 사항을 검토하도록 하면 피드백 루프가 크게 단축되어 더 짧은 시간에 더 나은 소프트웨어를 만들 수 있습니다. 이 일이 일어나려면 무엇이 필요합니까?
그림 1은 구현하려는 접근 방식을 보여줍니다. GitLab 서버로 푸시하면 파이프라인에서 실행되는 일련의 작업이 시작됩니다. 작업은 아티팩트를 생성하고 테스트한 다음 대상 리포지토리에 업로드합니다. 이러한 대상 리포지토리의 예로는 Nexus 또는 Artifactory, Docker 레지스트리 또는 GitLab 자체와 같은 Maven 리포지토리가 있습니다. 그런 다음 배포 작업은 스테이징 서버에 아티팩트를 업로드하고 애플리케이션의 새 버전을 시작하여 모든 사람에게 최신 변경 사항을 제공합니다. 팀의 개발자가 사용할 수 있습니다. 숙련된 독자가 궁금해하기 전에 이 시리즈의 다음 부분에서 프로덕션 환경을 포함하도록 파이프라인이 확장될 것입니다.
일반적인 GitLab CI 설치는 그림 2의 서버 환경에 표시된 것처럼 GitLab 서버와 하나(또는 그 이상)의 GitLab 실행기 서버 등 여러 서버로 구성됩니다.
하나 후에 git push GitLab 서버로의 CI 파이프라인은 GitLab Runner에서 시작됩니다. .gitlab-ci.yml 프로젝트에 정의된 CI 작업. 이 문서에 설명된 계획을 구현한 후 다음 행만 .gitlab-ci.yml 푸시할 때마다 자동으로 배포하는 데 필요합니다.
deploy_app:
stage: deploy
tags:
- ansible
script:
- 'ansible-playbook -i staging deploy.yml'
GitLab의 Ansible 배포
Ansible은 “이 파일” 및 “이 서비스 다시 시작”과 같은 작업 목록이 포함된 플레이북을 실행합니다. 플레이북은 하나 이상의 대상 시스템(이 경우 스테이징 서버)에 적용됩니다. 파이프라인 내에서 Ansible을 사용하려면 파이프라인의 작업이 GitLab 실행기에 의해 실행되는 방식을 이해해야 합니다.
특정 파이프라인 작업을 전문으로 하는 여러 러너를 GitLab에 추가할 수 있습니다. 이러한 특수 러너(GitLab Runner와 혼동하지 말 것) 주인러너를 실행하는 서버)에 데이터베이스, 가상 머신 또는 러너 호스트에 대한 직접 액세스와 같은 추가 기계를 장착할 수 있습니다. 이것은 다른 때문입니다 집행자 허용합니다. 또한 러너는 특정 GitLab 프로젝트에 할당하거나 모든 프로젝트 간에 공유할 수 있습니다(공유 러너). 모든 프로젝트에 대해 Ansible 배포를 활성화하려고 하므로 Docker 실행기를 사용하는 공유 실행기를 생성합니다.
러너의 실행자는 파이프라인 작업에 대한 실행 환경을 제공합니다. Docker 실행기를 사용하면 Ansible 배포를 실행할 Docker 이미지를 지정할 수 있습니다. 그림 3에서 볼 수 있듯이 이미 만들어진 여러 Ansible 이미지가 포함된 공식 Docker Hub 레지스트리에서 이미지를 직접 가져올 수 있습니다. 새 주자는 레이블(영어: 낮)에 태그를 지정하여 러너 사용을 해당 태그가 있는 작업으로 제한할 수 있습니다.
대상 시스템에 연결하기 위해 Ansible은 SSH를 사용합니다.
이는 GitLab Runner 호스트가 스테이징 서버에 인증하기 위해 SSH 키가 필요함을 의미합니다. 또한 이 키는 그림 4와 같이 이상적으로는 루트가 아닌 사용자에 대해 권한이 부여되어야 합니다. 또한 SSH 키의 개인 부분은 Docker를 통해 GitLab Runner 호스트에서 실행되는 Ansible 컨테이너 내에서 노출되어야 합니다.
컨테이너 내부의 SSH 개인 키와 같은 비밀을 노출하는 일반적인 방법은 그림 5와 같이 Docker 볼륨을 사용하는 것입니다. 런타임 시 볼륨이 컨테이너에 마운트되어 Ansible이 SSH 키에 액세스할 수 있습니다. 실행기의 볼륨은 GitLab Runner 구성 파일 내에서 지정할 수 있습니다.
비밀을 노출하는 또 다른 접근 방식은 GitLab의 보안 변수를 사용하는 것입니다. 개인 SSH 키는 이러한 변수에 저장할 수 있으며 GitLab Runner는 다음과 같이 구성할 수도 있습니다. pre_build_script, SSH 에이전트에 SSH 키를 추가합니다. 이 접근 방식을 사용하면 프로젝트별로 SSH 키를 구성할 수 있으므로 이론적으로 시스템을 더 안전하게 만들 수 있으며 사용자가 Gitlab Runner 호스트에 액세스하지 않고도 새 배포 대상을 정의할 수 있습니다. 이 접근 방식에 대한 열린 질문은 GitLab에서 안전한 변수 설정을 자동화하는 방법입니다. 이러한 이유로 우리는 첫 번째 접근 방식을 선택했습니다.
계획
GitLab 파이프라인 내에서 Ansible을 사용할 수 있도록 하는 계획은 다음 단계로 구성됩니다.
- GitLab Runner 호스트에서 SSH 키를 생성합니다.
- SSH 키가 승인될 배치 사용자를 작성하십시오.
- Ansible Docker 이미지를 기반으로 새 GitLab 러너를 생성하고 SSH 키로 디렉터리를 마운트하는 볼륨으로 러너를 구성합니다.
- 새로운 러너에 하나를 넣어
ansible-GitLab에서 태그를 지정하고 다음을 사용하는 작업만 실행하도록 러너를 구성합니다.ansible– 태그가 실행됩니다.
계획의 실행
1단계와 2단계는 Ansible이 훌륭하게 처리할 수 있는 일반적인 프로비저닝 작업입니다. 키와 사용자를 직접 생성하는 대신 SSH 키를 생성하고(아직 존재하지 않는 경우) 키의 공개 부분을 읽고 대상 시스템에서 권한을 부여하는 짧은 플레이북을 생성할 수 있습니다.
- hosts: gitlab_runner
…
- tasks:
- name: create ssh key if it does not exist
expect:
command: ssh-keygen -t rsa
# only creates the key if the file does not exist
creates: "{{ runner_user_home }}/.ssh/id_rsa"
...
responses:
"file": "{{ runner_user_home }}/.ssh/id_rsa"
"passphrase": ""
- name: read public key
command: "cat {{ runner_user_home }}/.ssh/id_rsa.pub"
register: runner_pub_key
- hosts: deploy_target
…
- tasks:
- name: add deploy key to authorized keys
authorized_key:
user: "{{ user }}"
key: "{{ hostvars[ deploy_source_host ].runner_pub_key.stdout}}"
플레이북의 세부 정보는 여기서 관련이 없습니다. 요점은 이러한 작업은 스크립팅하기 쉽고 bevuta github 계정에서 전체 플레이북을 편집할 수 있다는 것입니다. 이러한 단계를 자동화하면 나중에 새 대상을 쉽게 추가하고 플레이북을 다시 실행할 수 있습니다. Ansible은 모든 작업이 멱등적으로 실행되도록 보장합니다. 즉, 새 대상 컴퓨터에서만 조정이 이루어집니다. 몇 가지 확장을 통해 자동 키 갱신 및 오래된 키의 승인 취소를 구현할 수 있으며, 이는 주기적으로 수행될 수 있습니다.
계획의 3단계는 GitLab Runner Host에서 실행해야 합니다. 이것은 쉘 프로그램을 사용하여 수행됩니다. gitlab-ci-multi-runner 새로운 주자가 등록되었습니다. 등록을 위해 탭의 토큰 Admin Area -> Overview -> Runners GitLab에 필요한:
sudo ./gitlab-ci-multi-runner register
--non-interactive
--executor docker
--url <gitlab-url>
--name deploy-ansible-runner
--registration-token <Registrierungstoken>
--docker-image williamyeh/ansible:centos7
--docker-privileged false
--docker-volumes "/home/<deploy-user>/.ssh:/root/.ssh"
--tag-list Ansible
모든 값이 올바른지 확인하려면 /etc/gitlab-runner/config.toml 확인할 수 있습니다. 러너 등록 후 구성 파일을 쉽게 편집하고 저장할 수 있습니다. 그런 다음 GitLab은 파일의 변경 사항에 자동으로 반응합니다.
[[runners]]
name = "deploy-ansible-runner"
url = <gitlab-url>
token = <deploy-token>
executor = "docker"
environment = ["GIT_SSL_NO_VERIFY=1"] (1)
[runners.docker]
image = williamyeh/ansible:centos7
privileged = false
volumes = ["/cache",
"/home/<deploy-user>/.ssh:/root/.ssh" (2)
]
(1) 자체 서명된 SSL 인증서를 사용하는 경우 이 환경 변수를 설정하면 다음을 방지할 수 있습니다. git 체크아웃 거부.
(2) 이것을 장착 .ssh경로의 디렉토리 /root/.ssh이것은 Ansible이 SSH 키를 자동으로 사용하게 하는 기본 경로이기 때문입니다.
계획의 4단계는 클릭 몇 번으로 구현할 수 있습니다. 단순히 ansible-deploy-runner GitLab에서 탭 Admin Area -> Overview -> Runners 선택하고 그가 ansible-태그가 있고 Run untagged jobs 체크박스를 선택 취소합니다. 그렇지 않으면 러너는 다른 런타임 환경을 예상할 수 있는 다른 작업에도 사용될 수 있습니다.
지속적인 통합!
이것이 Ansible 배포로 GitLab CI 설치를 확장하는 데 필요한 전부입니다. 이제부터 모든 GitLab 프로젝트는 Ansible Runner를 사용할 수 있으며 ansible-일 .gitlab-ci.yml 지정되고 Ansible 플레이북이 제공됩니다. 이에 대해서는 이 시리즈의 다음 블로그 게시물에서 스테이징 및 프로덕션 환경이 포함된 전체 파이프라인의 예를 통해 설명합니다.