Consul を使用した Nomad クラスターのセットアップと Gitlab との統合

導入

最近、Kubernetes の人気が急速に高まっており、Kubernetes を実装するプロジェクトが増えています。 Nomad のようなオーケストレーターについて触れたいと思いました。Nomad は、Vault や Consul など、HashiCorp の他のソリューションをすでに使用しているプロジェクトに最適であり、プロジェクト自体はインフラストラクチャの点で複雑ではありません。 この資料には、Nomad のインストール、XNUMX つのノードをクラスターに結合する手順、および Nomad を Gitlab と統合する手順が含まれています。

テストスタンド

テストベンチについて少し説明します。2 つの CPU、4 つの RAM、50 Gb SSD の特性を持つ XNUMX つの仮想サーバーが共通のローカル ネットワークに統合されて使用されます。 彼らの名前とIPアドレス:

1. ノマド-livelinux-01：００７
2. ノマド-livelinux-02：００７
3. 領事-livelinux-01：００７

Nomad、Consulのインストール。 Nomad クラスターの作成

基本的なインストールから始めましょう。 セットアップは簡単でしたが、記事の整合性を保つために説明します。基本的に、必要なときにすぐにアクセスできるように、下書きとメモから作成されました。

この段階では将来の構造を理解することが重要であるため、実践を始める前に理論的な部分について説明します。

XNUMX つのノマド ノードがあり、それらを XNUMX つのクラスターに結合したいと考えています。将来的にはクラスターの自動スケーリングも必要になります。そのためには Consul が必要になります。 このツールを使用すると、クラスタリングと新しいノードの追加が非常に簡単なタスクになります。作成された Nomad ノードは Consul エージェントに接続し、次に既存の Nomad クラスタに接続します。 したがって、最初に Consul サーバーをインストールし、Web パネルの基本的な 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

確認してみましょう: サービスが実行されている必要があり、consul members コマンドを実行するとサーバーが表示されるはずです。

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 ファイルを作成し、そのファイルのユーザー名とパスワードを生成することを忘れないでください。 この項目は、ドメインを知っている人全員が Web パネルを利用できないようにするために必要です。 ただし、Gitlab をセットアップするときは、これを放棄する必要があります。そうしないと、アプリケーションを Nomad にデプロイできなくなります。 私のプロジェクトでは、Gitlab と Nomad は両方とも灰色の Web 上にのみ存在するため、ここではそのような問題は発生しません。

残りの XNUMX つのサーバーには、次の手順に従って 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

サーバー上で consul を起動します。 起動後、nsul メンバーに設定されたサービスが表示されるはずです。 これは、クライアントとしてクラスターに正常に接続されたことを意味します。 XNUMX 番目のサーバーでも同じことを繰り返します。その後、Nomad のインストールと構成を開始できます。

Nomad のインストールの詳細については、公式ドキュメントに記載されています。 従来のインストール方法には、バイナリ ファイルをダウンロードする方法とソースからコンパイルする方法の XNUMX つがあります。 最初の方法を選択します。

注意: プロジェクトは非常に急速に開発されており、新しいアップデートが頻繁にリリースされます。 おそらく、この記事が完成するまでに新しいバージョンがリリースされるでしょう。 したがって、読む前に、現時点での 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

解凍後、65 MB の 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
}

XNUMX 番目のサーバー上の構成ファイルを変更することを忘れないでください。そこで http ディレクティブの値を変更する必要があります。

この段階での最後の作業は、プロキシ用に Nginx を構成し、http 認証を設定することです。 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";
        }
        
}

これで、外部ネットワーク経由で Web パネルにアクセスできるようになりました。 接続してサーバー ページに移動します。

画像1。 Nomad クラスター内のサーバーのリスト

両方のサーバーがパネルに正常に表示され、nomad ノード ステータス コマンドの出力にも同じことが表示されます。

画像2。 nomad ノード ステータス コマンドの出力

領事はどうですか？ 見てみましょう。 Consul コントロール パネルのノード ページに移動します。

画像3。 Consul クラスター内のノードのリスト

これで、Consul と連携して動作する準備の整った Nomad ができました。 最終段階では、Gitlab から Nomad への Docker コンテナの配信を設定し、その他の特徴的な機能についても説明する楽しい部分に進みます。

Gitlab ランナーの作成

Docker イメージを 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 のジョブ ファイルから始めましょう。 この記事での私のプロジェクトは非常に原始的なものになります。それは XNUMX つのタスクで構成されます。 .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 へのデプロイの XNUMX つの段階で構成されます。 最初の段階では、Docker イメージをアセンブルしてレジストリにプッシュし、第 XNUMX 段階で 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" {}
                }
            }
        }
    }
}

私はプライベート レジストリを持っており、Docker イメージを正常にプルするにはそれにログインする必要があることに注意してください。 この場合の最善の解決策は、Vault にログインとパスワードを入力し、Nomad と統合することです。 Nomad は Vault をネイティブにサポートします。 ただし、その前に、Nomad に必要なポリシーを Vault 自体にインストールしましょう。ポリシーはダウンロードできます。

# 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