הקמת אשכול Nomad באמצעות Consul ושילוב עם Gitlab

מבוא

לאחרונה, הפופולריות של Kubernetes גדלה במהירות - יותר ויותר פרויקטים מיישמים אותה. רציתי לגעת במתזמר כמו Nomad: הוא מושלם לפרויקטים שכבר משתמשים בפתרונות אחרים של HashiCorp, למשל, Vault ו-Consul, והפרויקטים עצמם אינם מורכבים מבחינת תשתית. חומר זה יכיל הוראות להתקנת Nomad, שילוב שני צמתים לאשכול, וכן שילוב של Nomad עם Gitlab.

עמדת מבחן

קצת על ספסל הבדיקה: נעשה שימוש בשלושה שרתים וירטואליים עם מאפיינים של 2 מעבדים, 4 זיכרון RAM, 50 ג'יגה-בייט SSD, המאוחדים לרשת מקומית משותפת. השמות וכתובות ה-IP שלהם:

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

התקנה של נומד, קונסול. יצירת אשכול נוודים

נתחיל עם ההתקנה הבסיסית. למרות שההגדרה הייתה פשוטה, אתאר אותה למען שלמות המאמר: היא נוצרה בעצם מטיוטות והערות לגישה מהירה בעת הצורך.

לפני שנתחיל בתרגול, נדון בחלק התיאורטי, כי בשלב זה חשוב להבין את המבנה העתידי.

יש לנו שני צמתים נוודים ואנחנו רוצים לשלב אותם לאשכול, ובעתיד נצטרך גם קנה מידה אוטומטי של אשכולות - בשביל זה נזדקק לקונסול. בעזרת הכלי הזה, clustering והוספה של צמתים חדשים הופכים למשימה פשוטה מאוד: ה-Nomad שנוצר מתחבר לסוכן ה-Consul, ולאחר מכן מתחבר לאשכול Nomad הקיים. לכן, בהתחלה נתקין את שרת ה-Consul, נתקין הרשאת http בסיסי לפאנל האינטרנט (הוא ללא הרשאה כברירת מחדל וניתן לגשת אליו בכתובת חיצונית), וכן את סוכני הקונסול עצמם בשרתי 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/

כעת יש לנו קונסול בינארי מוכן להגדרה נוספת.

כדי לעבוד עם קונסול, עלינו ליצור מפתח ייחודי באמצעות פקודת keygen:

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

בואו נעבור להגדרת תצורת הקונסול, יצירת ספרייה /etc/consul.d/ עם המבנה הבא:

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

ספריית ה-bootstrap תכיל קובץ תצורה 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"]
}

הבה נסתכל על ההנחיות העיקריות ומשמעויותיהן בנפרד:

• אֹזֶן הַנַעַל: נכון. אנו מאפשרים הוספה אוטומטית של צמתים חדשים אם הם מחוברים. אציין שאיננו מציינים כאן את המספר המדויק של הצמתים הצפויים.
• שרת: נכון. אפשר מצב שרת. קונסול במכונה הוירטואלית הזו ישמש כשרת והמאסטר היחיד כרגע, ה-VM של Nomad יהיה הלקוחות.
• מרכז הנתונים: dc1. ציין את שם מרכז הנתונים ליצירת האשכול. זה חייב להיות זהה גם בלקוחות וגם בשרתים.
• להצפין: המפתח שלך. המפתח, שחייב להיות גם ייחודי ולהתאים בכל הלקוחות והשרתים. נוצר באמצעות הפקודה consul 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

הפעל את 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 והגדרת proxying והרשאת 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, נצטרך לנטוש זאת - אחרת לא נוכל לפרוס את האפליקציה שלנו לנומד. בפרויקט שלי, גם Gitlab וגם Nomad נמצאים רק ברשת האפורה, כך שאין כאן בעיה כזו.

בשני השרתים הנותרים אנו מתקינים סוכני 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

אנו משיקים קונסול בשרת. כעת, לאחר ההשקה, עלינו לראות את השירות המוגדר אצל חברי nsul. המשמעות היא שהוא התחבר בהצלחה לאשכול כלקוח. חזור על אותו הדבר בשרת השני ולאחר מכן נוכל להתחיל להתקין ולהגדיר את 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

לאחר פירוק, נקבל קובץ בינארי של Nomad במשקל 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

עם זאת, אנחנו לא ממהרים להשיק את נווד - עדיין לא יצרנו את קובץ התצורה שלו:

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 ל-Proxy והגדרת הרשאת 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. פלט של פקודת מצב הצומת הנווד

מה עם קונסול? בואו נסתכל. עבור ללוח הבקרה של קונסול, לדף הצמתים:

תמונה 3. רשימת צמתים באשכול הקונסול

עכשיו יש לנו נווד מוכן שעובד בשיתוף עם קונסול. בשלב האחרון, נגיע לחלק המהנה: הגדרת משלוח של מכולות Docker מ-Gitlab לנומד, וגם נדבר על כמה מהמאפיינים הייחודיים האחרים שלה.

יצירת Gitlab Runner

כדי לפרוס תמונות 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}

כתוצאה מכך, תהיה לנו תמונה זמינה של רץ Nomad ב-Gitlab Registry, כעת נוכל לעבור ישירות למאגר הפרויקטים, ליצור Pipeline ולהגדיר את עבודת הנוודים של 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

כאן הפריסה מתרחשת באופן ידני, אבל אתה יכול להגדיר אותה כדי לשנות את התוכן של ספריית הפרויקט. צינור מורכב משני שלבים: הרכבת תמונה ופריסה שלו לנווד. בשלב הראשון אנחנו מרכיבים תמונת docker ודוחפים אותה לרישום שלנו, ובשני אנחנו משיקים את העבודה שלנו ב-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 אני צריך להיכנס אליו. הפתרון הטוב ביותר במקרה זה הוא להזין שם משתמש וסיסמה לכספת ולאחר מכן לשלב אותה עם Nomad. Nomad תומך באופן מקורי בכספת. אבל ראשית, בואו נתקין את המדיניות הדרושה עבור 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 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 - הוא מתאים יותר לפרויקטים קטנים שבהם Kubernetes יכול לגרום למורכבות נוספת ולא יממש את מלוא הפוטנציאל שלו. בנוסף, Nomad מושלם למתחילים - קל להתקנה ולהגדרה. עם זאת, בעת בדיקה בפרויקטים מסוימים, אני נתקל בבעיה עם הגרסאות המוקדמות שלו - פונקציות בסיסיות רבות פשוט אינן שם או שהן אינן פועלות כהלכה. עם זאת, אני מאמין ש-Nomad תמשיך להתפתח ובעתיד היא תרכוש את הפונקציות שכולם צריכים.

מחבר: איליה אנדרייב, בעריכת אלכסיי ז'אדאן וצוות Live Linux


מקור: www.habr.com