مقدمة
في الآونة الأخيرة ، تزداد شعبية Kubernetes بسرعة - المزيد والمزيد من المشاريع تنفذها في المنزل. أردت أن أتطرق إلى أوركسترا مثل Nomad: إنه مثالي للمشاريع التي تستخدم بالفعل حلولًا أخرى من HashiCorp ، على سبيل المثال ، Vault و Consul ، والمشاريع نفسها ليست معقدة من حيث البنية التحتية. توفر هذه المقالة إرشادات حول تثبيت Nomad ، والجمع بين عقدتين في كتلة ، ودمج Nomad مع Gitlab.
موقف اختبار
قليلاً عن طاولة الاختبار: يتم استخدام ثلاثة خوادم افتراضية مع خصائص وحدة المعالجة المركزية (CPU) و 4 RAM و 50 جيجا بايت SSD ، وهي متحدة في شبكة محلية مشتركة. أسمائهم وعناوين IP:
- nomad-livelinux-01 : 172.30.0.5
- nomad-livelinux-02 : 172.30.0.10
- القنصل-ليفيلينوكس 01 : 172.30.0.15
تركيب البدوي ، القنصل. خلق الكتلة البدوية
دعنا ننتقل إلى التثبيت الأساسي. على الرغم من سهولة التثبيت ، سأصفها من أجل سلامة المقالة: في الواقع ، تم إنشاؤها من المسودات والملاحظات للوصول السريع إذا لزم الأمر.
قبل البدء في الممارسة ، سنناقش الجزء النظري ، لأنه من المهم في هذه المرحلة فهم الهيكل المستقبلي.
لدينا عقدتان بدويتان ونريد ضمهما إلى مجموعة ، وفي المستقبل سنحتاج إلى تحجيم تلقائي للمجموعة - لهذا نحن بحاجة إلى القنصل. باستخدام هذه الأداة ، يصبح تجميع وإضافة عقد جديدة مهمة بسيطة للغاية: تتصل عقدة Nomad التي تم إنشاؤها بوحدة القنصل ، ثم تتصل بمجموعة Nomad الموجودة. لذلك ، في البداية ، سنقوم بتثبيت خادم القنصل ، وتكوين تفويض http الأساسي للوحة الويب (يكون افتراضيًا دون إذن ويمكن الوصول إليه عن طريق عنوان خارجي) ، بالإضافة إلى وكلاء القنصل أنفسهم على خوادم Nomad ، وبعد ذلك نبدأ تشغيل Nomad.
تثبيت أدوات HashiCorp بسيط للغاية: في الواقع ، فنحن ببساطة ننقل الملف الثنائي إلى دليل bin ، ونقوم بتكوين ملف تهيئة الأداة وإنشاء ملف الخدمة الخاص بها.
قم بتنزيل الملف الثنائي القنصل وقم بفك ضغطه في الدليل الرئيسي للمستخدم:
root@consul-livelinux-01:~
الآن لدينا ملف قنصل ثنائي جاهز لمزيد من التكوين.
للعمل مع القنصل ، نحتاج إلى إنشاء مفتاح فريد باستخدام أمر keygen:
root@consul-livelinux-01:~
دعنا ننتقل إلى تكوين القنصل ، إنشاء دليل /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"] }
دعونا نفحص بشكل منفصل التوجيهات الرئيسية ومعانيها:
- التمهيد : صحيح. يتم تشغيل الإضافة التلقائية للعقد الجديدة إذا كانت متصلة. ألاحظ أننا لا نشير هنا إلى العدد الدقيق للعقد المتوقعة.
- الخادم : صحيح. قم بتشغيل وضع الخادم. سيكون القنصل على هذا الجهاز الافتراضي هو الخادم الوحيد والرائد في الوقت الحالي ، وسيكون VM Nomad عملاء.
- مركز البيانات : DC1. حدد اسم مركز البيانات لإنشاء كتلة. يجب أن تكون متطابقة على كل من العملاء والخوادم.
- تشفير : مفتاحك. مفتاح يجب أن يكون فريدًا ومطابقًا على جميع العملاء والخوادم. ولدت باستخدام الأمر القنصل كجن.
- start_join . في هذه القائمة ، نشير إلى قائمة عناوين IP التي سيتم الاتصال بها. في الوقت الحالي ، نترك عنواننا فقط.
في هذه المرحلة ، يمكننا أن نبدأ القنصل باستخدام سطر الأوامر:
root@consul-livelinux-01:~
هذه طريقة جيدة لتصحيح الأخطاء الآن ، ولكن بشكل مستمر ، لن يعمل استخدام هذه الطريقة لأسباب واضحة. قم بإنشاء ملف خدمة لإدارة القنصل من خلال systemd:
root@consul-livelinux-01:~
محتويات ملف 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:~
نتحقق: يجب بدء تشغيل خدمتنا ، ومن خلال تنفيذ أمر أعضاء القنصل ، يجب أن نرى خادمنا:
root@consul-livelinux:/etc/consul.d
الخطوة التالية: تثبيت Nginx وإعداد الوكيل ، إذن HTTP. قم بتثبيت nginx من خلال مدير الحزم وفي الدليل / etc / nginx / sites-create إنشاء ملف التكوين 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:~
عن طريق القياس مع الخادم السابق ، نقوم بإنشاء دليل لملفات التكوين /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.
ويرد وصف أكثر تفصيلا ل Nomad في وثائقها الرسمية. هناك طريقتان للتثبيت التقليدي: تنزيل ملف ثنائي وتجميع من المصدر. سأختار الطريقة الأولى.
ملاحظة : يتطور المشروع بسرعة كبيرة ، وغالبًا ما يتم إصدار تحديثات جديدة. ربما ، بحلول وقت الانتهاء من المقال ، سيتم إصدار نسخة جديدة. لذلك ، أوصي قبل قراءة التحقق من الإصدار الحالي من Nomad في الوقت الحالي وتنزيله.
root@nomad-livelinux-01:~
بعد التفريغ ، سنحصل على ملف Nomad'a الثنائي الذي يبلغ حجمه 65 ميجا بايت - يجب نقله إلى / usr / local / bin.
قم بإنشاء دليل بيانات لـ Nomad وتعديل ملف الخدمة الخاص به (على الأرجح لن يكون موجودًا في البداية):
root@nomad-livelinux-01:~
أدخل الأسطر التالية هناك:
[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:~
ستكون بنية الدليل النهائي كما يلي:
/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. قائمة الخوادم في كتلة البدوي
يتم عرض الخادمين بنجاح في اللوحة ، وهو نفس الشيء الذي سنراه في إخراج أمر حالة عقدة البدو:
الصورة 2. إخراج أمر حالة عقدة البدو
ماذا عن القنصل؟ لنرى. انتقل إلى لوحة التحكم القنصل ، إلى صفحة العقد:
الشكل 3. قائمة العقد في المجموعة القنصل
الآن أعددنا نوماد ، بالتعاون مع القنصل. في المرحلة الأخيرة ، سنبدأ الجزء الأكثر إثارة للاهتمام: سنقوم بتكوين تسليم حاويات Docker من Gitlab إلى Nomad ، بالإضافة إلى الحديث عن بعض ميزاته المميزة الأخرى.
إنشاء 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}
نتيجة لذلك ، سيكون لدينا صورة يمكن الوصول إليها من عداء Nomad في سجل Gitlab ، والآن يمكننا الانتقال مباشرة إلى مستودع المشروع ، وإنشاء خط أنابيب وتكوين الوظيفة البدوية 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
يحدث النشر هنا في الوضع اليدوي ، ولكن يمكنك تكوينه لتغيير محتويات دليل المشروع. يتكون خط الأنابيب من مرحلتين: من تجميع الصورة ونشرها إلى البدو. في المرحلة الأولى ، نقوم بجمع صورة عامل ميناء ودفعها إلى قلمنا ؛ في الثانية ، نطلق عملنا في البدوي.
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. لكن أولاً ، في Vault نفسها ، سنقوم بتثبيت السياسات اللازمة لـ Nomad ، يمكنك تنزيلها:
الآن ، وبعد إنشاء السياسات اللازمة ، سنضيف التكامل مع 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 والعمل معها في المستقبل. سأقول إنني أتعاطف مع البدوي إلى حد ما - إنه أكثر ملاءمة للمشاريع الصغيرة حيث يمكن أن تسبب Kubernetes صعوبات إضافية ولن تدرك إمكاناتها حتى النهاية. بالإضافة إلى ذلك ، يعد Nomad مثاليًا للمبتدئين - إنه سهل التثبيت والتكوين. ومع ذلك ، عند الاختبار على بعض المشاريع ، واجهت مشكلة الإصدارات السابقة - العديد من الوظائف الأساسية ببساطة غير موجودة أو أنها لا تعمل بشكل صحيح. ومع ذلك ، أعتقد أن نوماد ستواصل تطويرها وستحصل في المستقبل على جميع الوظائف اللازمة.
تم النشر بواسطة Ilya Andreev ، تم تحريره بواسطة Alexei Zhadan و Live Linux Team