ProHoster > блог > Администрација > Поставување кластер Номад со помош на Consul и интегрирање со Gitlab

Поставување кластер Номад со помош на Consul и интегрирање со Gitlab

Вовед

Неодамна, популарноста на Kubernetes рапидно расте - се повеќе и повеќе проекти го спроведуваат. Сакав да допрам оркестратор како Номад: тој е совршен за проекти кои веќе користат други решенија од HashiCorp, на пример, Vault и Consul, а самите проекти не се сложени во однос на инфраструктурата. Овој материјал ќе содржи инструкции за инсталирање на Nomad, комбинирање на два јазли во кластер, како и интегрирање на Nomad со Gitlab.

Поставување кластер Номад со помош на Consul и интегрирање со Gitlab

Тест штанд

Малку за тест-клупата: се користат три виртуелни сервери со карактеристики на 2 процесор, 4 RAM, 50 Gb SSD, обединети во заедничка локална мрежа. Нивните имиња и IP адреси:

  1. nomad-livelinux-01: 172.30.0.5
  2. nomad-livelinux-02: 172.30.0.10
  3. конзул-livelinux-01: 172.30.0.15

Инсталација на Номад, конзул. Создавање номадски кластер

Да почнеме со основната инсталација. Иако поставувањето беше едноставно, ќе го опишам заради интегритетот на статијата: во суштина беше создаден од нацрти и белешки за брз пристап кога е потребно.

Пред да започнеме со пракса, ќе разговараме за теоретскиот дел, бидејќи во оваа фаза е важно да се разбере идната структура.

Имаме два номадски јазли и сакаме да ги комбинираме во кластер, а во иднина ќе ни треба и автоматско скалирање на кластерот - за ова ќе ни треба Конзул. Со оваа алатка, кластерирањето и додавањето нови јазли станува многу едноставна задача: креираниот Nomad јазол се поврзува со агентот Consul, а потоа се поврзува со постоечкиот Nomad кластер. Затоа, на почетокот ќе го инсталираме серверот Consul, ќе ја конфигурираме основната http овластување за веб-панелот (по дифолт е без овластување и може да се пристапи на надворешна адреса), како и самите агенти на Конзулот на серверите на Номад, по што ќе продолжиме само кон Номад.

Инсталирањето на алатките на HashiCorp е многу едноставно: во суштина, ние само ја преместуваме бинарната датотека во директориумот за отпадоци, ја поставуваме конфигурациската датотека на алатката и ја создаваме нејзината услужна датотека.

Преземете ја бинарната датотека 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/

Сега имаме готов конзулски бинарен за понатамошна конфигурација.

За да работиме со Конзул, треба да создадеме единствен клуч користејќи ја командата 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"]
}

Ајде да ги разгледаме главните директиви и нивните значења одделно:

  • bootstrap: точно. Овозможуваме автоматско додавање на нови јазли доколку се поврзани. Забележувам дека овде не го наведуваме точниот број на очекувани јазли.
  • сервер: точно. Овозможи режим на сервер. Конзулот на оваа виртуелна машина ќе делува како единствен сервер и господар во моментот, а клиентите ќе бидат VM на Nomad.
  • на Центарот за податоци: dc1. Наведете го името на центарот за податоци за да се создаде кластерот. Мора да биде идентичен и на клиентите и на серверите.
  • шифрирај: вашиот клуч. Клучот, кој исто така мора да биде единствен и да одговара на сите клиенти и сервери. Генерирана со помош на командата конзул keygen.
  • почеток_приклучи се. Во оваа листа укажуваме листа на IP адреси на кои ќе се направи врската. Во моментов оставаме само своја адреса.

Во овој момент можеме да работиме конзул користејќи ја командната линија:

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

Ова е добар начин за отстранување грешки сега, меѓутоа, нема да можете да го користите овој метод на тековна основа од очигледни причини. Ајде да создадеме услужна датотека за управување со Consul преку systemd:

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:

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

Ајде да провериме: нашата услуга мора да работи и со извршување на командата членови на конзул треба да го видиме нашиот сервер:

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 се само на сивата мрежа, така што тука нема таков проблем.

На преостанатите два сервери инсталираме агенти на Конзул според следните инструкции. Ги повторуваме чекорите со бинарната датотека:

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

Го лансираме конзулот на серверот. Сега, по стартувањето, треба да ја видиме конфигурираната услуга во членовите на nsul. Ова ќе значи дека тој успешно се поврзал со кластерот како клиент. Повторете го истото на вториот сервер и после тоа можеме да започнеме со инсталирање и конфигурирање на 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

По распакувањето, ќе добиеме бинарна датотека Nomad со тежина од 65 MB - мора да се премести во /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

Сепак, не брзаме да го лансираме номад - сè уште не сме ја создале неговата конфигурациска датотека:

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.

Последното нешто во оваа фаза е да го конфигурирате 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";
        }
        
}

Сега можеме да пристапиме до веб-панелот преку надворешна мрежа. Поврзете се и одете на страницата со сервери:

Поставување кластер Номад со помош на Consul и интегрирање со Gitlab
Слика 1. Список на сервери во кластерот Номад

И двата сервери се успешно прикажани во панелот, ќе го видиме истото на излезот од командата за статус на номадскиот јазол:

Поставување кластер Номад со помош на Consul и интегрирање со Gitlab
Слика 2. Излез од командата за статус на номадски јазол

Што е со конзулот? Ајде да погледнеме. Одете во контролната табла на Конзул, на страницата со јазли:
Поставување кластер Номад со помош на Consul и интегрирање со Gitlab
Слика 3. Список на јазли во кластерот Конзул

Сега имаме подготвен Номад кој работи заедно со конзулот. Во последната фаза, ќе дојдеме до забавниот дел: поставување на испорака на Docker контејнери од Gitlab до Nomad, а исто така зборуваме за некои други негови карактеристични карактеристики.

Креирање на Gitlab Runner

За да распоредиме докерски слики на Номад, ќе користиме посебен тркач со бинарната датотека Номад внатре (тука, патем, можеме да забележиме уште една карактеристика на апликациите 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}

Како резултат на тоа, ќе имаме достапна слика на Nomad runner во Gitlab Registry, сега можеме да одиме директно во складиштето на проектот, да создадеме Pipeline и да ја конфигурираме Nomad's nomad job.

Поставување на проектот

Да почнеме со досието на работното место за Номад. Мојот проект во оваа статија ќе биде прилично примитивен: ќе се состои од една задача. Содржината на .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

Овде распоредувањето се случува рачно, но можете да го конфигурирате да ја менува содржината на директориумот на проектот. Гасоводот се состои од две фази: склопување на слики и негово распоредување во номад. Во првата фаза, составуваме докер слика и ја туркаме во нашиот регистар, а во втората ја започнуваме нашата работа во Номад. 

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. Номад природно го поддржува 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

Сега, откако ги создадовме потребните политики, ќе додадеме интеграција со Vault во блокот со задачи во датотеката job.nomad:

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

Јас користам овластување по токен и го регистрирам директно овде, исто така постои и опција за одредување на токенот како променлива при стартување на номадскиот агент:

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

Сега можеме да ги користиме клучевите со Vault. Принципот на работа е едноставен: создаваме датотека во Nomad job која ќе ги складира вредностите на променливите, на пример:

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 е совршен за почетници - лесно се инсталира и конфигурира. Меѓутоа, при тестирање на некои проекти, наидувам на проблем со неговите рани верзии - многу основни функции едноставно ги нема или не работат правилно. Сепак, верувам дека Номад ќе продолжи да се развива и во иднина ќе ги стекне функциите што им се потребни на сите.

Автор: Илја Андреев, уреден од Алексеј Жадан и тимот на Live Linux


Извор: www.habr.com

Додадете коментар