Consul을 사용하여 Nomad 클러스터 설정 및 Gitlab과 통합

소개

최근 Kubernetes의 인기가 급속히 높아지고 있으며 이를 구현하는 프로젝트가 점점 더 많아지고 있습니다. 저는 Nomad와 같은 오케스트레이터를 다루고 싶었습니다. 이는 HashiCorp의 다른 솔루션(예: Vault 및 Consul)을 이미 사용하고 있는 프로젝트에 적합하며 프로젝트 자체는 인프라 측면에서 복잡하지 않습니다. 이 자료에는 Nomad 설치, 두 노드를 클러스터로 결합, Nomad를 Gitlab과 통합하는 방법에 대한 지침이 포함되어 있습니다.

테스트 벤치

테스트 벤치에 대해 간략히 설명하면 2개의 CPU, 4개의 RAM, 50Gb SSD의 특성을 지닌 XNUMX개의 가상 서버가 공통 로컬 네트워크로 통합되어 사용됩니다. 이름 및 IP 주소:

1. 유목민-livelinux-01: 172.30.0.5
2. 유목민-livelinux-02: 172.30.0.10
3. consul-livelinux-01: 172.30.0.15

노마드 설치, 영사. 노마드 클러스터 생성

기본 설치부터 시작해 보겠습니다. 설정은 간단했지만 기사의 무결성을 위해 설명하겠습니다. 기본적으로 필요할 때 빠르게 액세스할 수 있도록 초안과 메모를 사용하여 작성되었습니다.

연습을 시작하기 전에 이론적 부분을 논의하겠습니다. 이 단계에서는 미래 구조를 이해하는 것이 중요하기 때문입니다.

우리는 두 개의 노마드 노드를 가지고 있으며 이를 클러스터로 결합하려고 하며, 앞으로는 자동 클러스터 확장도 필요할 것입니다. 이를 위해서는 Consul이 필요합니다. 이 도구를 사용하면 새 노드를 클러스터링하고 추가하는 작업이 매우 간단해집니다. 생성된 Nomad 노드는 Consul 에이전트에 연결한 다음 기존 Nomad 클러스터에 연결됩니다. 따라서 처음에는 Consul 서버를 설치하고, 웹 패널에 대한 기본 http 인증(기본적으로 인증이 없으며 외부 주소에서 액세스할 수 있음)과 Nomad 서버의 Consul 에이전트 자체를 구성합니다. Nomad로만 진행하겠습니다.

HashiCorp의 도구를 설치하는 것은 매우 간단합니다. 기본적으로 바이너리 파일을 bin 디렉터리로 이동하고 도구의 구성 파일을 설정하고 서비스 파일을 생성하기만 하면 됩니다.

Consul 바이너리 파일을 다운로드하고 사용자의 홈 디렉터리에 압축을 풉니다.

root@consul-livelinux-01:~# wget https://releases.hashicorp.com/consul/1.5.0/consul_1.5.0_linux_amd64.zip
root@consul-livelinux-01:~# unzip consul_1.5.0_linux_amd64.zip
root@consul-livelinux-01:~# mv consul /usr/local/bin/

이제 추가 구성을 위해 미리 만들어진 consul 바이너리가 있습니다.

Consul을 사용하려면 keygen 명령을 사용하여 고유 키를 생성해야 합니다.

root@consul-livelinux-01:~# consul keygen

Consul 구성 설정으로 넘어가서 다음 구조로 /etc/consul.d/ 디렉터리를 생성해 보겠습니다.

/etc/consul.d/
├── bootstrap
│   └── config.json

부트스트랩 디렉터리에는 구성 파일 config.json이 포함됩니다. 이 파일에서 Consul 설정을 지정합니다. 내용:

{
"bootstrap": true,
"server": true,
"datacenter": "dc1",
"data_dir": "/var/consul",
"encrypt": "your-key",
"log_level": "INFO",
"enable_syslog": true,
"start_join": ["172.30.0.15"]
}

주요 지시문과 그 의미를 별도로 살펴 보겠습니다.

• 부트 스트랩: 진실. 새 노드가 연결되면 자동 추가를 활성화합니다. 여기서는 예상되는 노드의 정확한 수를 표시하지 않습니다.
• 섬기는 사람: 진실. 서버 모드를 활성화합니다. 이 가상 머신의 Consul은 현재 유일한 서버 및 마스터 역할을 하며 Nomad의 VM은 클라이언트가 됩니다.
• 데이터 센터: dc1. 클러스터를 생성할 데이터 센터의 이름을 지정합니다. 클라이언트와 서버 모두에서 동일해야 합니다.
• 암호화: 당신의 열쇠. 모든 클라이언트와 서버에서 고유하고 일치해야 하는 키입니다. consul keygen 명령을 사용하여 생성됩니다.
• 시작_참여. 이 목록에는 연결될 IP 주소 목록이 표시됩니다. 지금은 우리 주소만 남깁니다.

이 시점에서 명령줄을 사용하여 consul을 실행할 수 있습니다.

root@consul-livelinux-01:~# /usr/local/bin/consul agent -config-dir /etc/consul.d/bootstrap -ui

이는 현재 디버깅하는 좋은 방법이지만, 분명한 이유로 인해 지속적으로 이 방법을 사용할 수는 없습니다. systemd를 통해 Consul을 관리하기 위한 서비스 파일을 만들어 보겠습니다.

root@consul-livelinux-01:~# nano /etc/systemd/system/consul.service

consul.service 파일의 내용:

[Unit]
Description=Consul Startup process
After=network.target
 
[Service]
Type=simple
ExecStart=/bin/bash -c '/usr/local/bin/consul agent -config-dir /etc/consul.d/bootstrap -ui' 
TimeoutStartSec=0
 
[Install]
WantedBy=default.target

systemctl을 통해 Consul을 시작합니다.

root@consul-livelinux-01:~# systemctl start consul

확인해 보겠습니다. 서비스가 실행 중이어야 하며 consulmembers 명령을 실행하면 서버가 표시됩니다.

root@consul-livelinux:/etc/consul.d# consul members
consul-livelinux    172.30.0.15:8301  alive   server  1.5.0  2         dc1  <all>

다음 단계: Nginx를 설치하고 프록시 및 http 인증을 설정합니다. 패키지 관리자를 통해 nginx를 설치하고 /etc/nginx/sites-enabled 디렉토리에 다음 내용으로 구성 파일 consul.conf를 만듭니다.

upstream consul-auth {
    server localhost:8500;
}

server {

    server_name consul.doman.name;
    
    location / {
      proxy_pass http://consul-auth;
      proxy_set_header Host $host;
      auth_basic_user_file /etc/nginx/.htpasswd;
      auth_basic "Password-protected Area";
    }
}

.htpasswd 파일을 생성하고 이에 대한 사용자 이름과 비밀번호를 생성하는 것을 잊지 마십시오. 이 항목은 우리 도메인을 아는 모든 사람이 웹 패널을 사용할 수 없도록 하기 위해 필요합니다. 그러나 Gitlab을 설정할 때 이를 포기해야 합니다. 그렇지 않으면 애플리케이션을 Nomad에 배포할 수 없습니다. 내 프로젝트에서는 Gitlab과 Nomad 모두 그레이 웹에만 있으므로 여기서는 그런 문제가 없습니다.

나머지 두 서버에는 다음 지침에 따라 Consul 에이전트를 설치합니다. 바이너리 파일을 사용하여 단계를 반복합니다.

root@nomad-livelinux-01:~# wget https://releases.hashicorp.com/consul/1.5.0/consul_1.5.0_linux_amd64.zip
root@nomad-livelinux-01:~# unzip consul_1.5.0_linux_amd64.zip
root@nomad-livelinux-01:~# mv consul /usr/local/bin/

이전 서버와 유사하게 다음 구조를 사용하여 구성 파일 /etc/consul.d에 대한 디렉터리를 만듭니다.

/etc/consul.d/
├── client
│   └── config.json

config.json 파일의 내용:

{
    "datacenter": "dc1",
    "data_dir": "/opt/consul",
    "log_level": "DEBUG",
    "node_name": "nomad-livelinux-01",
    "server": false,
    "encrypt": "your-private-key",
    "domain": "livelinux",
    "addresses": {
      "dns": "127.0.0.1",
      "https": "0.0.0.0",
      "grpc": "127.0.0.1",
      "http": "127.0.0.1"
    },
    "bind_addr": "172.30.0.5", # локальный адрес вм
    "start_join": ["172.30.0.15"], # удаленный адрес консул сервера
    "ports": {
      "dns": 53
     }

변경 사항을 저장하고 서비스 파일 및 해당 내용 설정으로 이동합니다.

/etc/systemd/system/consul.service:

[Unit]
Description="HashiCorp Consul - A service mesh solution"
Documentation=https://www.consul.io/
Requires=network-online.target
After=network-online.target

[Service]
User=root
Group=root
ExecStart=/usr/local/bin/consul agent -config-dir=/etc/consul.d/client
ExecReload=/usr/local/bin/consul reload
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target

서버에서 consol을 실행합니다. 이제 출시 후 nsul 멤버에 구성된 서비스가 표시됩니다. 이는 클라이언트로서 클러스터에 성공적으로 연결되었음을 의미합니다. 두 번째 서버에서도 동일한 작업을 반복한 후 Nomad 설치 및 구성을 시작할 수 있습니다.

Nomad 설치에 대한 자세한 내용은 공식 문서에 설명되어 있습니다. 전통적인 설치 방법에는 바이너리 파일을 다운로드하고 소스에서 컴파일하는 두 가지 방법이 있습니다. 저는 첫 번째 방법을 선택하겠습니다.

주의: 프로젝트는 매우 빠르게 발전하고 있으며 새로운 업데이트가 자주 출시됩니다. 아마도 이 기사가 완료될 때쯤에는 새 버전이 출시될 것입니다. 따라서 읽기 전에 현재 Nomad의 최신 버전을 확인하고 다운로드하는 것이 좋습니다.

root@nomad-livelinux-01:~# wget https://releases.hashicorp.com/nomad/0.9.1/nomad_0.9.1_linux_amd64.zip
root@nomad-livelinux-01:~# unzip nomad_0.9.1_linux_amd64.zip
root@nomad-livelinux-01:~# mv nomad /usr/local/bin/
root@nomad-livelinux-01:~# nomad -autocomplete-install
root@nomad-livelinux-01:~# complete -C /usr/local/bin/nomad nomad
root@nomad-livelinux-01:~# mkdir /etc/nomad.d

압축을 풀면 65MB의 Nomad 바이너리 파일을 받게 됩니다. 이 파일을 /usr/local/bin으로 이동해야 합니다.

Nomad용 데이터 디렉터리를 만들고 해당 서비스 파일을 편집해 보겠습니다(처음에는 존재하지 않을 가능성이 높음).

root@nomad-livelinux-01:~# mkdir --parents /opt/nomad
root@nomad-livelinux-01:~# nano /etc/systemd/system/nomad.service

거기에 다음 줄을 붙여넣으세요.

[Unit]
Description=Nomad
Documentation=https://nomadproject.io/docs/
Wants=network-online.target
After=network-online.target

[Service]
ExecReload=/bin/kill -HUP $MAINPID
ExecStart=/usr/local/bin/nomad agent -config /etc/nomad.d
KillMode=process
KillSignal=SIGINT
LimitNOFILE=infinity
LimitNPROC=infinity
Restart=on-failure
RestartSec=2
StartLimitBurst=3
StartLimitIntervalSec=10
TasksMax=infinity

[Install]
WantedBy=multi-user.target

그러나 우리는 nomad를 시작하기 위해 서두르지 않습니다. 아직 구성 파일을 생성하지 않았습니다.

root@nomad-livelinux-01:~# mkdir --parents /etc/nomad.d
root@nomad-livelinux-01:~# chmod 700 /etc/nomad.d
root@nomad-livelinux-01:~# nano /etc/nomad.d/nomad.hcl
root@nomad-livelinux-01:~# nano /etc/nomad.d/server.hcl

최종 디렉토리 구조는 다음과 같습니다.

/etc/nomad.d/
├── nomad.hcl
└── server.hcl

nomad.hcl 파일에는 다음 구성이 포함되어야 합니다.

datacenter = "dc1"
data_dir = "/opt/nomad"

server.hcl 파일의 내용:

server {
  enabled = true
  bootstrap_expect = 1
}

consul {
  address             = "127.0.0.1:8500"
  server_service_name = "nomad"
  client_service_name = "nomad-client"
  auto_advertise      = true
  server_auto_join    = true
  client_auto_join    = true
}

bind_addr = "127.0.0.1" 

advertise {
  http = "172.30.0.5"
}

client {
  enabled = true
}

두 번째 서버에서 구성 파일을 변경하는 것을 잊지 마십시오. 여기서 http 지시문의 값을 변경해야 합니다.

이 단계의 마지막 작업은 HTTP 인증을 프록시하고 설정하기 위해 Nginx를 구성하는 것입니다. nomad.conf 파일의 내용:

upstream nomad-auth {
        server 172.30.0.5:4646;
}

server {

        server_name nomad.domain.name;
        
        location / {
	        proxy_pass http://nomad-auth;
	        proxy_set_header Host $host;
	        auth_basic_user_file /etc/nginx/.htpasswd;
		   auth_basic "Password-protected Area";
        }
        
}

이제 외부 네트워크를 통해 웹 패널에 액세스할 수 있습니다. 연결하고 서버 페이지로 이동합니다.

이미지 1. Nomad 클러스터의 서버 목록

두 서버 모두 패널에 성공적으로 표시되며 nomad node status 명령의 출력에 동일한 내용이 표시됩니다.

이미지 2. nomad node status 명령의 출력

영사는 어떻습니까? 한번 살펴보자. Consul 제어판의 노드 페이지로 이동합니다.

이미지 3. Consul 클러스터의 노드 목록

이제 우리는 Consul과 함께 일하는 준비된 Nomad를 갖게 되었습니다. 마지막 단계에서는 Gitlab에서 Nomad로 Docker 컨테이너 전달을 설정하고 다른 독특한 기능에 대해 이야기하는 재미있는 부분을 살펴보겠습니다.

Gitlab 실행기 만들기

도커 이미지를 Nomad에 배포하기 위해 Nomad 바이너리 파일이 내부에 있는 별도의 실행기를 사용합니다(여기서 Hashicorp 애플리케이션의 또 다른 기능을 확인할 수 있습니다. 개별적으로는 단일 바이너리 파일입니다). 실행기 디렉터리에 업로드합니다. 다음 내용으로 간단한 Dockerfile을 만들어 보겠습니다.

FROM alpine:3.9
RUN apk add --update --no-cache libc6-compat gettext
COPY nomad /usr/local/bin/nomad

동일한 프로젝트에서 .gitlab-ci.yml을 만듭니다.

variables:
  DOCKER_IMAGE: nomad/nomad-deploy
  DOCKER_REGISTRY: registry.domain.name
 

stages:
  - build

build:
  stage: build
  image: ${DOCKER_REGISTRY}/nomad/alpine:3
  script:
    - tag=${DOCKER_REGISTRY}/${DOCKER_IMAGE}:latest
    - docker build --pull -t ${tag} -f Dockerfile .
    - docker push ${tag}

결과적으로 Gitlab 레지스트리에 Nomad 실행기의 사용 가능한 이미지가 있게 되며 이제 프로젝트 저장소로 직접 이동하여 파이프라인을 생성하고 Nomad의 nomad 작업을 구성할 수 있습니다.

프로젝트 설정

Nomad에 대한 작업 파일부터 시작하겠습니다. 이 기사에서 내 프로젝트는 매우 원시적입니다. 하나의 작업으로 구성됩니다. .gitlab-ci의 내용은 다음과 같습니다.

variables:
  NOMAD_ADDR: http://nomad.address.service:4646
  DOCKER_REGISTRY: registry.domain.name
  DOCKER_IMAGE: example/project

stages:
  - build
  - deploy

build:
  stage: build
  image: ${DOCKER_REGISTRY}/nomad-runner/alpine:3
  script:
    - tag=${DOCKER_REGISTRY}/${DOCKER_IMAGE}:${CI_COMMIT_SHORT_SHA}
    - docker build --pull -t ${tag} -f Dockerfile .
    - docker push ${tag}


deploy:
  stage: deploy
  image: registry.example.com/nomad/nomad-runner:latest
  script:
    - envsubst '${CI_COMMIT_SHORT_SHA}' < project.nomad > job.nomad
    - cat job.nomad
    - nomad validate job.nomad
    - nomad plan job.nomad || if [ $? -eq 255 ]; then exit 255; else echo "success"; fi
    - nomad run job.nomad
  environment:
    name: production
  allow_failure: false
  when: manual

여기서 배포는 수동으로 수행되지만 프로젝트 디렉터리의 내용을 변경하도록 구성할 수 있습니다. 파이프라인은 이미지 조립과 노마드로의 배포라는 두 단계로 구성됩니다. 첫 번째 단계에서는 도커 이미지를 조립하여 레지스트리에 푸시하고, 두 번째 단계에서는 Nomad에서 작업을 시작합니다.

job "monitoring-status" {
    datacenters = ["dc1"]
    migrate {
        max_parallel = 3
        health_check = "checks"
        min_healthy_time = "15s"
        healthy_deadline = "5m"
    }

    group "zhadan.ltd" {
        count = 1
        update {
            max_parallel      = 1
            min_healthy_time  = "30s"
            healthy_deadline  = "5m"
            progress_deadline = "10m"
            auto_revert       = true
        }
        task "service-monitoring" {
            driver = "docker"

            config {
                image = "registry.domain.name/example/project:${CI_COMMIT_SHORT_SHA}"
                force_pull = true
                auth {
                    username = "gitlab_user"
                    password = "gitlab_password"
                }
                port_map {
                    http = 8000
                }
            }
            resources {
                network {
                    port "http" {}
                }
            }
        }
    }
}

개인 레지스트리가 있고 도커 이미지를 성공적으로 가져오려면 해당 레지스트리에 로그인해야 합니다. 이 경우 가장 좋은 해결책은 Vault에 로그인과 비밀번호를 입력한 다음 Nomad와 통합하는 것입니다. Nomad는 기본적으로 Vault를 지원합니다. 하지만 먼저 Vault 자체에 Nomad에 필요한 정책을 설치해 보겠습니다. 다운로드할 수 있습니다.

# Download the policy and token role
$ curl https://nomadproject.io/data/vault/nomad-server-policy.hcl -O -s -L
$ curl https://nomadproject.io/data/vault/nomad-cluster-role.json -O -s -L

# Write the policy to Vault
$ vault policy write nomad-server nomad-server-policy.hcl

# Create the token role with Vault
$ vault write /auth/token/roles/nomad-cluster @nomad-cluster-role.json

이제 필요한 정책을 생성한 후 job.nomad 파일의 작업 블록에 Vault와의 통합을 추가하겠습니다.

vault {
  enabled = true
  address = "https://vault.domain.name:8200"
  token = "token"
}

저는 토큰에 의한 승인을 사용하여 여기에 직접 등록합니다. Nomad 에이전트를 시작할 때 토큰을 변수로 지정하는 옵션도 있습니다.

$ VAULT_TOKEN=<token> nomad agent -config /path/to/config

이제 Vault에서 키를 사용할 수 있습니다. 작동 원리는 간단합니다. Nomad 작업에서 변수 값을 저장할 파일을 만듭니다. 예를 들면 다음과 같습니다.

template {
                data = <<EOH
{{with secret "secrets/pipeline-keys"}}
REGISTRY_LOGIN="{{ .Data.REGISTRY_LOGIN }}"
REGISTRY_PASSWORD="{{ .Data.REGISTRY_LOGIN }}{{ end }}"

EOH
    destination = "secrets/service-name.env"
    env = true
}

이 간단한 접근 방식을 사용하면 Nomad 클러스터에 대한 컨테이너 제공을 구성하고 향후에 이를 사용할 수 있습니다. 나는 Nomad에 어느 정도 공감한다고 말할 것입니다. Kubernetes는 추가적인 복잡성을 야기할 수 있고 그 잠재력을 최대한 실현하지 못하는 소규모 프로젝트에 더 적합합니다. 게다가 Nomad는 초보자에게 적합합니다. 설치와 구성이 쉽습니다. 그러나 일부 프로젝트를 테스트할 때 초기 버전에서 문제가 발생했습니다. 많은 기본 기능이 없거나 제대로 작동하지 않습니다. 하지만 저는 Nomad가 계속해서 발전할 것이며, 앞으로도 모두가 필요로 하는 기능을 갖추게 될 것이라고 믿습니다.

저자: Ilya Andreev, 편집자: Alexey Zhadan 및 Live Linux 팀


출처 : habr.com