GitLab CI 및 Ansible을 사용한 지속적인 제공(2부)

안타깝게도 시리즈의 첫 번째 부분을 계속해서 제공하는 데 꽤 오랜 시간이 걸렸습니다. 고객을 위해 해야 할 일이 많았습니다. 그러나 마침내 그는 여기에 있습니다.

1부에서는 큰 그림을 살펴보고 Ansible을 Gitlab CI와 함께 사용하여 다양한 환경에 소프트웨어를 제공하는 방법을 설명했지만 이 기사에서는 Ansible을 사용하여 Gitlab 아티팩트를 설치하는 데 더 중점을 둘 것입니다. 특히 스테이징 환경에 결국 Spring Boot 애플리케이션을 설치할 전체 파이프라인을 살펴보고 있습니다.

여기서 다루고 있는 IT 환경에 대한 개요를 제공하기 시작했습니다. 이것은 또한 첫 번째 부분의 기억을 새로 고칠 것입니다.

이 스케치의 일부는 우리에게 친숙해 보일 것입니다. 우리는 개발자가 Git을 사용하여 코드를 Gitlab 서버(단계 0)에 푸시하고 파이프라인을 시작합니다(단계 1). 파이프라인은 다른 모든 작업을 설정하고 작업은 애플리케이션 빌드 및 테스트(2단계), 빌드된 아티팩트를 Maven 리포지토리에서 사용 가능하게 만들기(3단계), 스테이징 Nudge 서버에 Ansible을 통해 설치(4단계)를 담당합니다. 3단계의 리포지토리를 아티팩트로 사용합니다(5단계). 마지막으로 애플리케이션을 다시 시작합니다(6단계).

아래에서 파이프라인의 개별 작업을 자세히 살펴봅니다. 우리가 배운 것처럼 파이프라인은 Gitlab이 우리를 위해 실행할 일련의 작업에 지나지 않습니다. 파이프라인의 첫 번째 작업은 Spring Boot 애플리케이션을 빌드하고 테스트하는 것입니다.

코드 리포지토리에 대한 파이프라인은 다음 파일에 정의됩니다. .gitlab-ci.yml 호출됩니다. 다음은 파이프라인의 2단계와 3단계에 대한 정의입니다.

variables:
  # Dies unterdrückt ein erneutes Herunterladen von Abhängigkeiten und Plugins und verhindert das Anzeigen von Upload-Nachrichten im Log.
  # `showDateTime` wird die vergangene Zeit in Millisekunden anzeigen. Es muss `--batch-mode` mitgegeben werden, damit das funktioniert.
  MAVEN_OPTS: "-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN -Dorg.slf4j.simpleLogger.showDateTime=true -Djava.awt.headless=true"
  # Seit Maven 3.3.0 kann diesen Option alternativ auch in `.mvn/maven.config` definiert werden. Damit würde dieselbe Konfiguration genutzt werden,
  # wenn dies von der Kommandozeile aus ausgeführt würde.
  # `installAtEnd` und `deployAtEnd` funktionieren nur mit aktuellen Versionen der entsprechenden Erweiteurngen.
  MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true"
  POSTGRES_DB: our_test_project_database
  POSTGRES_USER: our_test_project_user
  POSTGRES_PASSWORD: our_test_project_password

cache:
  paths:
    - /root/.m2/repository

stages:
  - build
  - test
  - release

validate:jdk8:
  stage: build
  script:
    - 'mvn $MAVEN_CLI_OPTS test-compile' 
  image: maven:3.5.0-jdk-8

deploy:jdk8:
  stage: test
  services:
    - postgres:9.6
  script:
    - 'mvn --settings settings.xml $MAVEN_CLI_OPTS -Dspring.profiles.active=gitlab deploy'
  image: maven:3.5.0-jdk-8

release_staging:
  stage: release
  image: williamyeh/ansible:centos7
  only: 
    - master
  tags:
    - ansible
  script:
    - 'ansible-playbook -i staging deploy.yml'

이 단계를 단계별로 살펴보겠습니다. 처음에는 나중에 사용할 수 있는 몇 가지 변수를 선언합니다.

  # Dies unterdrückt ein erneutes Herunterladen von Abhängigkeiten und Plugins und verhindert das Anzeigen von Upload-Nachrichten im Log.
  # `showDateTime` wird die vergangene Zeit in Millisekunden anzeigen. Es muss `--batch-mode` mitgegeben werden, damit das funktioniert.
  MAVEN_OPTS: "-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN -Dorg.slf4j.simpleLogger.showDateTime=true -Djava.awt.headless=true"
  # Seit Maven 3.3.0 kann diesen Option alternativ auch in `.mvn/maven.config` definiert werden. Damit würde dieselbe Konfiguration genutzt werden,
  # wenn dies von der Kommandozeile aus ausgeführt würde.
  # `installAtEnd` und `deployAtEnd` funktionieren nur mit aktuellen Versionen der entsprechenden Erweiteurngen.
  MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true"
  POSTGRES_DB: our_test_project_database
  POSTGRES_USER: our_test_project_user
  POSTGRES_PASSWORD: our_test_project_password

다음으로 각 작업 사이에 보관할 경로 목록(이 경우에는 실제로 하나만)을 선언합니다. 우리는 Maven이 모든 종속성에 대해 계속해서 반복되는 것을 원하지 않습니다.

cache:
  paths:
    - /root/.m2/repository

그 후 소위 세 단계를 선언합니다. 단계(아마도 독일어로 단계로 가장 잘 번역됨)는 다른 작업을 그룹화하는 데 사용할 수 있습니다. 동일한 단계에 속하는 작업은 병렬로 실행됩니다. 우리의 세 단계는 build, test 그리고 release:

stages:
  - build
  - test
  - release

정의된 단계와 관련하여 또 다른 중요한 측면이 있습니다. 특정 단계에 속하는 작업은 이전 단계의 작업이 성공적으로 실행될 수 있는 경우에만 실행됩니다. 우리의 경우, 그것은 test– 단계는 다음의 작업이 있는 경우에만 트리거됩니다. build-phase 모두 ​​성공적으로 실행되었습니다. 이것은 매우 유용합니다.

이것이 Gitlab에서 이 파이프라인 단계의 순서입니다.

기초 작업이 완료되면 Gitlab이 우리를 위해 수행할 작업을 정의하는 단계로 넘어갈 수 있습니다. 첫 번째 직업은 validate:jdk8 라고 불리는:

validate:jdk8:
  stage: build
  script:
    - 'mvn $MAVEN_CLI_OPTS test-compile' 
  image: maven:3.5.0-jdk-8              

이 작업이 속한 build-스테이지이며 다음과 같은 두 가지 특징을 갖는다: (1) 수행한다. mvn test-compile 와 더불어 $MVN_CLI_OPTS
위에서 우리는 variables-섹션에서 정의했습니다. 그런 다음 Maven은 리소스를 처리하고 애플리케이션 및 관련 테스트를 컴파일합니다. (2) Docker 이미지 내에서 이 모든 작업을 수행합니다. 이 경우 maven:3.5.0-jdk-8-Docker Hub에서 찾을 수 있는 이미지.

다음 작업은 deploy:jdk8. 이 작업의 정의는 다음과 같습니다.

deploy:jdk8:
  stage: test
  services:
    - postgres:9.6
  script:
    - 'mvn --settings settings.xml $MAVEN_CLI_OPTS -Dspring.profiles.active=gitlab deploy'
  image: maven:3.5.0-jdk-8

이것은 ~의 일이다 test-단계. 동일한 Docker 이미지를 사용하여 Maven을 다시 실행하고 있습니다.
validate:djk8-직업. 또한 이 작업에는 실행 중인 PostgreSQL 데이터베이스가 필요합니다. 위에서 언급한 변수를 사용합니다. variables-섹션이 설정되었습니다. 예, 간단합니다. 그런 다음 Gitlab에서 사용할 수 있도록 하는 데이터베이스는 호스트 이름으로 연결할 수 있습니다.
postgres. 이를 위해 생성한 Spring 프로필을 사용하여 그에 따라 JDBC에 대한 연결 URL을 조정합니다.

마지막 작업은 이쪽 release-우리 모두가 기다려온 직업. 그를 자세히 살펴 보겠습니다.

release_staging:
  stage: release
  image: williamyeh/ansible:centos7
  only: 
    - master
  tags:
    - ansible
  script:
    - 'ansible-playbook -i staging deploy.yml'

이 경우 스테이징 환경에 Spring Boot 애플리케이션을 설치합니다. 이 작업은 release단계이며 다음 경우에만 실행됩니다. master– 브랜치가 업데이트 되었습니다. (이것은 이전에 살펴본 작업에는 적용되지 않으며 모든 푸시된 gitcommit에서 실행됩니다.)

참고: 앱이 업데이트될 때마다 애플리케이션을 자동으로 설치하거나 업데이트하지 않을 수 있습니다. master– 브랜치가 업데이트 되었습니다. 애플리케이션이 수동 트리거링에 의해서만 설치되거나 업데이트되도록 하기 위해 작업 정의는 다음으로 보완될 수 있습니다. when: manual. 그런 다음 Gitlab에서 해당 버튼을 클릭하여 배포를 트리거할 수 있습니다. (아래의 “재생 버튼”을 참조하십시오.) 조정된 작업 정의는 다음과 같습니다.

release_staging:
  stage: release
  image: williamyeh/ansible:centos7
  only: 
    - master
  when: manual
  tags:
    - ansible
  script:
    - 'ansible-playbook -i staging deploy.yml'

어느 쪽이든 이 작업은 정확히 한 가지 작업을 수행합니다. 즉, Ansible 플레이북을 실행합니다.

  script:
    - 'ansible-playbook -i staging deploy.yml'

우리가 명심해야 할 또 다른 세부 사항은 이것입니다
tags– 이 작업 설명의 요소. 이 작업에 대한 GitLab 실행기를 선택하는 데 태그가 사용됩니다. 각 러너는 하나 이상의 태그를 가질 수 있습니다. 이 직업은 그런ansible-낮. 이것은 그날의 Gitlab 러너가 여기에서 선택되었음을 의미합니다.

여기에서 사용하는 Docker 이미지는 비공식적이지만 Ansible이 제공하는 CentOS 7의 매우 우수한 Docker 이미지입니다. 위에서 논의한 바와 같이, Playbook
밖으로.

다음으로 자세히 살펴봐야 할 플레이북은 다음과 같습니다.

---
- hosts: web
  become: true
  tasks:
    - name: Install python setuptools
      apt: name=python-setuptools state=present
    - name: Install pip
      easy_install: name=pip state=present
    - name: Install lxml
      pip: name=lxml
    - name: Download latest snapshot
      maven_artifact:
       group_id: our.springboot.application
       artifact_id: our_springboot_artifact_id
       repository_url: http://our_springboot_server.bevuta.com:8080/artifactory/our_springboot_application/
       username: our_springboot_user
       password: our_springboot_password
       dest: /home/our/springboot_application.jar
    - name: Copy systemd unit file
      copy: src=our_springboot_application.service dest=/etc/systemd/system/our_springboot_application.service
    - name: Start web interface
      systemd:
        state: restarted
        name: our_springboot_application
        enabled: yes
        daemon_reload: yes

첫 번째 부분은 매우 간단합니다. 이 플레이북은 그룹에 속한 모든 호스트에 대한 작업을 정의합니다. web 제자리에 있다. 그리고 예, Ansible이 대상 시스템에서 루트로 작동하도록 허용되어야 합니다. 그것이 우리가 기대하는 것입니다. become:
true.

나머지는 Ansible이 우리를 위해 해야 할 일을 정의합니다. 시작하려면 Ansible을 실행하는 데 필요한 몇 가지 Python 도구를 설치합니다. maven_artifact– 할 일.

- name: Install python setuptools
  apt: name=python-setuptools state=present
- name: Install pip
  easy_install: name=pip state=present
- name: Install lxml
  pip: name=lxml

불행히도 이것은 그다지 우아하지 않습니다. 더 나은 방법을 알고 계십니까? 알려주세요.

대상 시스템을 준비한 후 Gitlab이 2단계에서 빌드하고 Maven 리포지토리에 업로드한 아티팩트를 살펴보겠습니다.

- name: Download latest snapshot
  maven_artifact:
    group_id: our.springboot.application
    artifact_id: our_springboot_artifact_id
    repository_url: http://our_springboot_server.bevuta.com:8080/artifactory/our_springboot_application/
    username: our_springboot_user
    password: our_springboot_password
    dest: /home/our/springboot_application.jar

마지막으로 (마지막으로) 다음을 추가하여 Spring Boot 애플리케이션을 자동으로 시작하겠습니다.
systemd대상 시스템에서 Ansible이 생성한 장치를 활성화합니다.

- name: Copy systemd unit file
  copy: src=our_springboot_application.service dest=/etc/systemd/system/our_springboot_application.service
- name: Start web interface
  systemd:
    state: restarted
    name: our_springboot_application
    enabled: yes
    daemon_reload: yes

단위 파일은 소위 “시스템 단위”를 설명합니다. 정확히 무엇입니까? “man page”를 살펴보자: “systemd” 단위는 “서비스, 소켓, 장치, 마운트 지점, 자동 마운트 지점, 스왑 파일 또는 파티션, 시작 대상, 감시 파일”입니다. 시스템 경로 …”(man/systemd.unit).

우리의 경우 Ansible은 Spring Boot 애플리케이션을 처리하는 방법, 즉 시스템이 부팅될 때 시작되는지 확인하는 방법을 systemd에 알려주는 단위 파일을 생성합니다.

그리고 그것으로 우리는 끝에 도달했을 것입니다. 우리의 Spring Boot 애플리케이션은 빌드, 테스트, Maven 리포지토리에 업로드되고 거기에서 대상 시스템으로 수정되고 시작되었습니다. 이 모든 것이 자동화되었습니다.