🥇 إنشاء مجموعة Nomad مع القنصل والاندماج مع Gitlab

مقدمة

في الآونة الأخيرة ، نمت شعبية Kubernetes بسرعة - المزيد والمزيد من المشاريع تنفذها في المنزل. أردت أن أتطرق إلى منسق مثل Nomad: إنه مثالي للمشاريع حيث يتم استخدام حلول أخرى من HashiCorp ، مثل Vault and Consul ، والمشاريع نفسها ليست معقدة من حيث البنية التحتية. ستوفر هذه المادة إرشادات لتثبيت Nomad ، ودمج عقدتين في مجموعة ، بالإضافة إلى دمج Nomad مع Gitlab.

اختبار موقف

قليلاً عن منصة الاختبار: يتم استخدام ثلاثة خوادم افتراضية بخصائص وحدتي CPU و 2 RAM و 4 Gb SSD ، متحدة في شبكة محلية مشتركة. أسمائهم وعناوين IP الخاصة بهم:

البدو- livelinux-01: 172.30.0.5
البدو- livelinux-02: 172.30.0.10
القنصل-ليفلينوكس -01: 172.30.0.15

تركيب نوماد ، القنصل. إنشاء مجموعة البدو

لنبدأ بالتثبيت الأساسي. على الرغم من سهولة التثبيت ، سأصفه حرصًا على سلامة المقال: في الواقع ، تم إنشاؤه من المسودات والملاحظات للوصول السريع في حالة الحاجة.

قبل الشروع في الممارسة ، سنناقش الجزء النظري ، لأنه من المهم في هذه المرحلة فهم الهيكل المستقبلي.

لدينا عقدتان بدويان ونريد دمجهما في مجموعة ، وسنحتاج أيضًا في المستقبل إلى توسيع نطاق المجموعة تلقائيًا - لهذا نحتاج إلى قنصل. باستخدام هذه الأداة ، يصبح التجميع وإضافة عقد جديدة مهمة بسيطة للغاية: تتصل عقدة Nomad التي تم إنشاؤها بوكيل Consul ، وبعد ذلك تتصل بمجموعة Nomad الحالية. لذلك ، في البداية سنقوم بتثبيت خادم Consul ، وتهيئة ترخيص http الأساسي للوحة الويب (افتراضيًا بدون إذن ويمكن الوصول إليه من عنوان خارجي) ، وكذلك وكلاء القنصل أنفسهم على خوادم Nomad ، بعد الذي سننتقل إليه للتو إلى Nomad.

يعد تثبيت أدوات HashiCorp أمرًا بسيطًا للغاية: في الأساس ، نقوم فقط بنقل الملف الثنائي إلى دليل bin ، وإعداد ملف تكوين الأداة ، وإنشاء ملف الخدمة الخاص به.

قم بتنزيل برنامج القنصل الثنائي واستخرجه إلى الدليل الرئيسي للمستخدم:

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 ، نحتاج إلى إنشاء مفتاح فريد باستخدام الأمر keygen:

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

دعنا ننتقل إلى تكوين Consul ، وإنشاء دليل /etc/consul.d/ بالهيكل التالي:

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

سيحتوي دليل bootstrap على ملف التكوين config.json - حيث سنقوم بتعيين إعدادات القنصل. المحتوى:

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

دعونا نلقي نظرة على التوجيهات الرئيسية ومعانيها بشكل منفصل:

ألبس الحذاء: حقيقي. قم بتمكين الإضافة التلقائية للعقد الجديدة إذا كانت متصلة. ألاحظ أننا لا نشير هنا إلى العدد الدقيق للعقد المتوقعة.
الخادم: حقيقي. قم بتشغيل وضع الخادم. سيكون القنصل على هذا الجهاز الظاهري بمثابة الخادم الوحيد والخادم الرئيسي في الوقت الحالي ، وسيكون جهاز Nomad's VM عملاء.
مركز البيانات: DC1. حدد اسم مركز البيانات لإنشاء الكتلة. يجب أن تكون متطابقة في كل من العملاء والخوادم.
تشفير:مفتاحك. المفتاح الذي يجب أن يكون فريدًا أيضًا ومطابقًا لجميع العملاء والخوادم. ولدت باستخدام الأمر consul keygen.
بدء_انضم. في هذه القائمة ، نحدد قائمة بعناوين IP التي سيتم الاتصال بها. في الوقت الحالي ، لا نترك سوى عنواننا الخاص.

في هذه المرحلة ، يمكننا أن نبدأ القنصل باستخدام سطر الأوامر:

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

هذه طريقة جيدة للتصحيح الآن ، لكنها لن تعمل على أساس دائم لأسباب واضحة. لنقم بإنشاء ملف خدمة لإدارة القنصل عبر 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

قم بتشغيل Consul عبر 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

نبدأ القنصل على الخادم. الآن ، بعد البدء ، يجب أن نرى الخدمة التي تم تكوينها في أعضاء نسول. هذا يعني أنه نجح في الاتصال بالعنقود كعميل. كرر الأمر نفسه على الخادم الثاني وبعد ذلك يمكننا البدء في تثبيت وتكوين 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

بعد التفريغ ، سنحصل على ملف ثنائي بحجم 65 ميغابايت - يجب نقله إلى / 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 هناك.

آخر شيء في هذه المرحلة هو إعداد 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";
        }
        
}

الآن يمكننا الوصول إلى لوحة الويب عبر الشبكة الخارجية. اتصل وانتقل إلى صفحة الخوادم:

صورة 1. قائمة الخوادم في مجموعة Nomad

يتم عرض كلا الخادمين بنجاح في اللوحة ، وسنرى نفس الشيء في إخراج أمر حالة العقدة البدائية:

صورة 2. Nomad node status إخراج الأمر

ماذا عن القنصل؟ دعنا نلقي نظرة. انتقل إلى لوحة تحكم القنصل ، إلى صفحة العقد:

صورة 3. قائمة العقد في الكتلة القنصلية

الآن لدينا Nomad جاهز للعمل مع القنصل. في المرحلة النهائية ، سننتقل إلى الجزء الأكثر إثارة للاهتمام: سنقوم بإعداد تسليم حاويات Docker من Gitlab إلى Nomad ، ونتحدث أيضًا عن بعض ميزاتها المميزة الأخرى.

إنشاء Gitlab Runner

لنشر صور عامل الإرساء في 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}

نتيجة لذلك ، سيكون لدينا صورة متوفرة عن Nomad runner في Gitlab Registry ، والآن يمكننا الانتقال مباشرة إلى مستودع المشروع ، وإنشاء خط أنابيب وإعداد وظيفة البدو البدوية.

إعداد مشروع

لنبدأ بملف الوظيفة لـ 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

الآن ، بعد إنشاء السياسات اللازمة ، سنضيف التكامل مع 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 يقوم بتخزين قيم المتغيرات ، على سبيل المثال:

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 ستستمر في التطور وستكتسب في المستقبل الوظائف التي يحتاجها الجميع.

المؤلف: إيليا أندريف ، تحرير أليكسي زهادان وفريق Live Linux

المصدر: www.habr.com

إنشاء مجموعة Nomad مع القنصل والاندماج مع Gitlab

مقدمة

اختبار موقف

تركيب نوماد ، القنصل. إنشاء مجموعة البدو

إنشاء Gitlab Runner

إعداد مشروع

إضافة تعليق إلغاء الرد