ProHoster > Blog > Pentadbiran > Menyediakan kluster Nomad menggunakan Konsul dan menyepadukan dengan Gitlab

Menyediakan kluster Nomad menggunakan Konsul dan menyepadukan dengan Gitlab

Pengenalan

Baru-baru ini, populariti Kubernetes telah berkembang pesat - semakin banyak projek melaksanakannya. Saya ingin menyentuh tentang orkestra seperti Nomad: ia sesuai untuk projek yang sudah menggunakan penyelesaian lain daripada HashiCorp, contohnya, Vault dan Consul, dan projek itu sendiri tidak rumit dari segi infrastruktur. Bahan ini akan mengandungi arahan untuk memasang Nomad, menggabungkan dua nod ke dalam kelompok, serta menyepadukan Nomad dengan Gitlab.

Menyediakan kluster Nomad menggunakan Konsul dan menyepadukan dengan Gitlab

Tempat ujian

Sedikit tentang bangku ujian: tiga pelayan maya digunakan dengan ciri-ciri 2 CPU, 4 RAM, 50 Gb SSD, disatukan ke dalam rangkaian tempatan yang sama. Nama dan alamat IP mereka:

  1. nomad-livelinux-01: 172.30.0.5
  2. nomad-livelinux-02: 172.30.0.10
  3. konsul-livelinux-01: 172.30.0.15

Pemasangan Nomad, Konsul. Mencipta kluster Nomad

Mari kita mulakan dengan pemasangan asas. Walaupun persediaan adalah mudah, saya akan menerangkannya demi integriti artikel: ia pada asasnya dicipta daripada draf dan nota untuk akses pantas apabila diperlukan.

Sebelum kita memulakan latihan, kita akan membincangkan bahagian teori, kerana pada peringkat ini adalah penting untuk memahami struktur masa depan.

Kami mempunyai dua nod nomad dan kami ingin menggabungkannya menjadi satu kluster, dan pada masa hadapan kami juga memerlukan penskalaan kluster automatik - untuk ini kami memerlukan Konsul. Dengan alat ini, pengelompokan dan penambahan nod baharu menjadi tugas yang sangat mudah: nod Nomad yang dibuat bersambung kepada ejen Konsul, dan kemudian bersambung ke gugusan Nomad sedia ada. Oleh itu, pada mulanya kami akan memasang pelayan Konsul, mengkonfigurasi kebenaran http asas untuk panel web (ia adalah tanpa kebenaran secara lalai dan boleh diakses di alamat luar), serta ejen Konsul sendiri pada pelayan Nomad, selepas itu kami hanya akan meneruskan ke Nomad.

Memasang alatan HashiCorp adalah sangat mudah: pada asasnya, kami hanya memindahkan fail binari ke direktori bin, menyediakan fail konfigurasi alat dan mencipta fail perkhidmatannya.

Muat turun fail binari Konsul dan bongkarkannya ke dalam direktori rumah pengguna:

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/

Kini kami mempunyai binari konsul sedia untuk konfigurasi selanjutnya.

Untuk bekerja dengan Konsul, kita perlu mencipta kunci unik menggunakan arahan keygen:

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

Mari kita teruskan untuk menyediakan konfigurasi Konsul, mencipta direktori /etc/consul.d/ dengan struktur berikut:

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

Direktori bootstrap akan mengandungi fail konfigurasi config.json - di dalamnya kami akan menetapkan tetapan Konsul. Kandungannya:

{
"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"]
}

Mari kita lihat arahan utama dan maknanya secara berasingan:

  • bootstrap: benar. Kami mendayakan penambahan automatik nod baharu jika ia disambungkan. Saya perhatikan bahawa kami tidak menunjukkan di sini bilangan sebenar nod yang dijangkakan.
  • server: benar. Dayakan mod pelayan. Konsul pada mesin maya ini akan bertindak sebagai satu-satunya pelayan dan tuan pada masa ini, VM Nomad akan menjadi pelanggan.
  • Pusat data: dc1. Nyatakan nama pusat data untuk membuat kluster. Ia mestilah sama pada kedua-dua pelanggan dan pelayan.
  • menyulitkan: kunci anda. Kuncinya, yang juga mestilah unik dan sepadan pada semua pelanggan dan pelayan. Dijana menggunakan arahan keygen konsul.
  • start_join. Dalam senarai ini kami menunjukkan senarai alamat IP yang sambungannya akan dibuat. Pada masa ini kami hanya meninggalkan alamat kami sendiri.

Pada ketika ini kita boleh menjalankan konsul menggunakan baris arahan:

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

Ini ialah cara yang baik untuk nyahpepijat sekarang, namun, anda tidak akan dapat menggunakan kaedah ini secara berterusan atas sebab yang jelas. Mari buat fail perkhidmatan untuk mengurus Konsul melalui systemd:

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

Kandungan fail 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

Lancarkan Konsul melalui systemctl:

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

Mari kita semak: perkhidmatan kami mesti berjalan, dan dengan melaksanakan arahan ahli konsul, kami harus melihat pelayan kami:

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

Peringkat seterusnya: memasang Nginx dan menyediakan proksi dan kebenaran http. Kami memasang nginx melalui pengurus pakej dan dalam direktori /etc/nginx/sites-enabled kami mencipta fail konfigurasi consul.conf dengan kandungan berikut:

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";
    }
}

Jangan lupa untuk mencipta fail .htpasswd dan menjana nama pengguna dan kata laluan untuknya. Item ini diperlukan supaya panel web tidak tersedia kepada semua orang yang mengetahui domain kami. Walau bagaimanapun, apabila menyediakan Gitlab, kami perlu meninggalkan ini - jika tidak, kami tidak akan dapat menggunakan aplikasi kami ke Nomad. Dalam projek saya, kedua-dua Gitlab dan Nomad hanya berada di web kelabu, jadi tiada masalah sedemikian di sini.

Pada baki dua pelayan kami memasang ejen Konsul mengikut arahan berikut. Kami mengulangi langkah dengan fail binari:

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/

Dengan analogi dengan pelayan sebelumnya, kami mencipta direktori untuk fail konfigurasi /etc/consul.d dengan struktur berikut:

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

Kandungan fail 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
     }

Simpan perubahan dan teruskan untuk menyediakan fail perkhidmatan, kandungannya:

/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

Kami melancarkan konsul pada pelayan. Sekarang, selepas pelancaran, kita harus melihat perkhidmatan yang dikonfigurasikan dalam ahli nsul. Ini bermakna ia telah berjaya menyambung ke kluster sebagai pelanggan. Ulangi perkara yang sama pada pelayan kedua dan selepas itu kita boleh mula memasang dan mengkonfigurasi Nomad.

Pemasangan Nomad yang lebih terperinci diterangkan dalam dokumentasi rasminya. Terdapat dua kaedah pemasangan tradisional: memuat turun fail binari dan menyusun daripada sumber. Saya akan memilih kaedah pertama.

Nota: Projek ini berkembang sangat cepat, kemas kini baharu sering dikeluarkan. Mungkin versi baharu akan dikeluarkan pada masa artikel ini selesai. Oleh itu, sebelum membaca, saya mengesyorkan menyemak versi semasa Nomad pada masa ini dan memuat turunnya. 

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

Selepas membongkar, kami akan menerima fail binari Nomad seberat 65 MB - ia mesti dialihkan ke /usr/local/bin.

Mari buat direktori data untuk Nomad dan edit fail perkhidmatannya (kemungkinan besar ia tidak akan wujud pada mulanya):

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

Tampalkan baris berikut di sana:

[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

Walau bagaimanapun, kami tidak tergesa-gesa untuk melancarkan nomad - kami belum mencipta fail konfigurasinya:

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

Struktur direktori terakhir adalah seperti berikut:

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

Fail nomad.hcl hendaklah mengandungi konfigurasi berikut:

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

Kandungan fail 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
}

Jangan lupa untuk menukar fail konfigurasi pada pelayan kedua - di sana anda perlu menukar nilai arahan http.

Perkara terakhir pada peringkat ini ialah mengkonfigurasi Nginx untuk proksi dan menyediakan kebenaran http. Kandungan fail 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";
        }
        
}

Kini kita boleh mengakses panel web melalui rangkaian luaran. Sambung dan pergi ke halaman pelayan:

Menyediakan kluster Nomad menggunakan Konsul dan menyepadukan dengan Gitlab
Imej 1. Senarai pelayan dalam kelompok Nomad

Kedua-dua pelayan berjaya dipaparkan dalam panel, kita akan melihat perkara yang sama dalam output perintah status nomad nomad:

Menyediakan kluster Nomad menggunakan Konsul dan menyepadukan dengan Gitlab
Imej 2. Output perintah status nomad nod

Bagaimana dengan Konsul? Jom tengok. Pergi ke panel kawalan Konsul, ke halaman nod:
Menyediakan kluster Nomad menggunakan Konsul dan menyepadukan dengan Gitlab
Imej 3. Senarai nod dalam kluster Konsul

Kini kami mempunyai Nomad yang bersedia bekerja bersama-sama dengan Konsul. Pada peringkat akhir, kita akan sampai ke bahagian yang menyeronokkan: menyediakan penghantaran bekas Docker dari Gitlab ke Nomad, dan juga bercakap tentang beberapa ciri tersendirinya yang lain.

Mencipta Gitlab Runner

Untuk menggunakan imej docker ke Nomad, kami akan menggunakan pelari berasingan dengan fail binari Nomad di dalam (di sini, dengan cara ini, kami boleh perhatikan ciri lain aplikasi Hashicorp - secara individu ia adalah fail binari tunggal). Muat naiknya ke direktori pelari. Mari buat fail Docker mudah untuknya dengan kandungan berikut:


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

Dalam projek yang sama kami mencipta .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}

Akibatnya, kami akan mempunyai imej pelari Nomad yang tersedia dalam Pendaftaran Gitlab, kini kami boleh pergi terus ke repositori projek, mencipta Talian Paip dan mengkonfigurasi kerja nomad Nomad.

Persediaan projek

Mari kita mulakan dengan fail kerja untuk Nomad. Projek saya dalam artikel ini akan menjadi agak primitif: ia akan terdiri daripada satu tugas. Kandungan .gitlab-ci adalah seperti berikut:

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

Di sini penempatan berlaku secara manual, tetapi anda boleh mengkonfigurasinya untuk menukar kandungan direktori projek. Saluran paip terdiri daripada dua peringkat: pemasangan imej dan penggunaannya ke nomad. Pada peringkat pertama, kami memasang imej docker dan menolaknya ke dalam Registry kami, dan pada peringkat kedua kami melancarkan tugas kami di 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" {}
                }
            }
        }
    }
}

Sila ambil perhatian bahawa saya mempunyai Pendaftaran peribadi dan untuk berjaya menarik imej docker saya perlu log masuk kepadanya. Penyelesaian terbaik dalam kes ini ialah memasukkan log masuk dan kata laluan ke dalam Vault dan kemudian menyepadukannya dengan Nomad. Nomad menyokong Vault secara asli. Tetapi pertama sekali, mari pasang dasar yang diperlukan untuk Nomad dalam Bilik Kebal itu sendiri; ia boleh dimuat turun:

# 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

Kini, setelah mencipta dasar yang diperlukan, kami akan menambah penyepaduan dengan Vault dalam blok tugas dalam fail job.nomad:

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

Saya menggunakan kebenaran dengan token dan mendaftarkannya terus di sini, terdapat juga pilihan untuk menentukan token sebagai pembolehubah apabila memulakan ejen nomad:

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

Kini kita boleh menggunakan kekunci dengan Vault. Prinsip operasi adalah mudah: kami mencipta fail dalam kerja Nomad yang akan menyimpan nilai pembolehubah, contohnya:

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
}

Dengan pendekatan mudah ini, anda boleh mengkonfigurasi penghantaran kontena ke gugusan Nomad dan bekerja dengannya pada masa hadapan. Saya akan mengatakan bahawa sedikit sebanyak saya bersimpati dengan Nomad - ia lebih sesuai untuk projek kecil di mana Kubernetes boleh menyebabkan kerumitan tambahan dan tidak akan menyedari potensi penuhnya. Selain itu, Nomad sesuai untuk pemula—mudah dipasang dan dikonfigurasikan. Walau bagaimanapun, apabila menguji beberapa projek, saya menghadapi masalah dengan versi awalnya - banyak fungsi asas tidak ada atau ia tidak berfungsi dengan betul. Walau bagaimanapun, saya percaya bahawa Nomad akan terus berkembang dan pada masa hadapan ia akan memperoleh fungsi yang diperlukan oleh semua orang.

Pengarang: Ilya Andreev, disunting oleh Alexey Zhadan dan pasukan Live Linux


Sumber: www.habr.com

Tambah komen