การตั้งค่าคลัสเตอร์ Nomad โดยใช้ Consul และบูรณาการกับ Gitlab

การแนะนำ

เมื่อเร็ว ๆ นี้ความนิยมของ Kubernetes เติบโตอย่างรวดเร็ว - มีการดำเนินโครงการมากขึ้นเรื่อย ๆ ฉันอยากจะพูดถึงผู้เรียบเรียงอย่าง Nomad: มันเหมาะสำหรับโปรเจ็กต์ที่ใช้โซลูชันอื่นจาก HashiCorp อยู่แล้ว เช่น Vault และ Consul และตัวโปรเจ็กต์เองก็ไม่ได้ซับซ้อนในแง่ของโครงสร้างพื้นฐาน เนื้อหานี้จะมีคำแนะนำในการติดตั้ง Nomad โดยการรวมสองโหนดไว้ในคลัสเตอร์ รวมถึงการผสานรวม Nomad เข้ากับ Gitlab

การตั้งค่าคลัสเตอร์ Nomad โดยใช้ Consul และบูรณาการกับ Gitlab

แท่นทดสอบ

เล็กน้อยเกี่ยวกับม้านั่งทดสอบ: ใช้เซิร์ฟเวอร์เสมือนสามเครื่องที่มีคุณสมบัติ 2 CPU, 4 RAM, 50 Gb SSD ซึ่งรวมกันเป็นเครือข่ายท้องถิ่นทั่วไป ชื่อและที่อยู่ IP ของพวกเขา:

  1. เร่ร่อน-livelinux-01: 172.30.0.5
  2. เร่ร่อน-livelinux-02: 172.30.0.10
  3. กงสุล-livelinux-01: 172.30.0.15

งานติดตั้งโนแมดกงสุล การสร้างคลัสเตอร์ Nomad

เริ่มจากการติดตั้งพื้นฐานกันก่อน แม้ว่าการตั้งค่าจะง่ายดาย แต่ฉันจะอธิบายเพื่อความสมบูรณ์ของบทความ: โดยพื้นฐานแล้วสร้างขึ้นจากฉบับร่างและบันทึกย่อเพื่อให้เข้าถึงได้รวดเร็วเมื่อจำเป็น

ก่อนที่เราจะเริ่มฝึก เราจะพูดถึงส่วนทางทฤษฎีก่อน เพราะในขั้นตอนนี้ สิ่งสำคัญคือต้องเข้าใจโครงสร้างในอนาคต

เรามีโหนดเร่ร่อนสองโหนดและเราต้องการรวมเข้าด้วยกันเป็นคลัสเตอร์ และในอนาคตเราจะต้องมีการปรับขนาดคลัสเตอร์อัตโนมัติด้วย สำหรับสิ่งนี้ เราจะต้องมีกงสุล ด้วยเครื่องมือนี้ การทำคลัสเตอร์และการเพิ่มโหนดใหม่จะกลายเป็นงานที่ง่ายมาก โดยโหนด Nomad ที่สร้างขึ้นจะเชื่อมต่อกับตัวแทนกงสุล จากนั้นเชื่อมต่อกับคลัสเตอร์ Nomad ที่มีอยู่ ดังนั้นในตอนเริ่มต้นเราจะติดตั้งเซิร์ฟเวอร์กงสุลกำหนดค่าการอนุญาต http พื้นฐานสำหรับแผงเว็บ (โดยค่าเริ่มต้นจะไม่มีการอนุญาตและสามารถเข้าถึงได้จากที่อยู่ภายนอก) รวมถึงตัวแทนกงสุลเองบนเซิร์ฟเวอร์ Nomad หลังจากนั้น เราจะเดินทางต่อไปยัง Nomad เท่านั้น

การติดตั้งเครื่องมือของ HashiCorp นั้นง่ายมาก โดยพื้นฐานแล้ว เราเพียงแค่ย้ายไฟล์ไบนารีไปยังไดเร็กทอรี bin ตั้งค่าไฟล์การกำหนดค่าของเครื่องมือ และสร้างไฟล์บริการของมัน

ดาวน์โหลดไฟล์ไบนารี 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

มาดูการตั้งค่ากงสุลกันต่อโดยสร้างไดเร็กทอรี /etc/consul.d/ ด้วยโครงสร้างต่อไปนี้:

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

ไดเร็กทอรีบูตสแตรปจะมีไฟล์กำหนดค่า 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. ระบุชื่อของศูนย์ข้อมูลเพื่อสร้างคลัสเตอร์ จะต้องเหมือนกันทั้งบนไคลเอนต์และเซิร์ฟเวอร์
  • การเข้ารหัสลับ: คีย์ของคุณ คีย์ซึ่งจะต้องไม่ซ้ำกันและตรงกันบนไคลเอนต์และเซิร์ฟเวอร์ทั้งหมด สร้างโดยใช้คำสั่งกงสุล keygen
  • start_join. ในรายการนี้ เราจะระบุรายการที่อยู่ 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

เปิดตัวกงสุลผ่าน 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 ได้

การติดตั้ง 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 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

อย่างไรก็ตาม เราไม่รีบร้อนที่จะเปิดตัว 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";
        }
        
}

ตอนนี้เราสามารถเข้าถึงแผงเว็บผ่านเครือข่ายภายนอกได้แล้ว เชื่อมต่อและไปที่หน้าเซิร์ฟเวอร์:

การตั้งค่าคลัสเตอร์ Nomad โดยใช้ Consul และบูรณาการกับ Gitlab
ภาพที่ 1 รายชื่อเซิร์ฟเวอร์ในคลัสเตอร์ Nomad

เซิร์ฟเวอร์ทั้งสองแสดงในแผงควบคุมได้สำเร็จ เราจะเห็นสิ่งเดียวกันในเอาต์พุตของคำสั่งสถานะโหนดเร่ร่อน:

การตั้งค่าคลัสเตอร์ Nomad โดยใช้ Consul และบูรณาการกับ Gitlab
ภาพที่ 2 เอาต์พุตของคำสั่งสถานะโหนด nomad

แล้วกงสุลล่ะ? มาดูกันดีกว่า ไปที่แผงควบคุมกงสุลไปที่หน้าโหนด:
การตั้งค่าคลัสเตอร์ Nomad โดยใช้ Consul และบูรณาการกับ Gitlab
ภาพที่ 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 ตอนนี้เราสามารถไปที่ที่เก็บโปรเจ็กต์ได้โดยตรง สร้าง Pipeline และกำหนดค่างาน Nomad ของ 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

ที่นี่การปรับใช้เกิดขึ้นด้วยตนเอง แต่คุณสามารถกำหนดค่าให้เปลี่ยนเนื้อหาของไดเร็กทอรีโปรเจ็กต์ได้ ไปป์ไลน์ประกอบด้วยสองขั้นตอน: การประกอบอิมเมจและการปรับใช้กับเร่ร่อน ในขั้นตอนแรก เรารวบรวมอิมเมจนักเทียบท่าและพุชมันเข้าไปใน Registry ของเรา และในขั้นตอนที่สอง เราก็เริ่มงานใน 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" {}
                }
            }
        }
    }
}

โปรดทราบว่าฉันมีรีจิสทรีส่วนตัว และเพื่อที่จะดึงอิมเมจนักเทียบท่าได้สำเร็จ ฉันจำเป็นต้องเข้าสู่ระบบ ทางออกที่ดีที่สุดในกรณีนี้คือการป้อนข้อมูลเข้าสู่ระบบและรหัสผ่านเข้าไปในห้องนิรภัย จากนั้นรวมเข้ากับ 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

ตอนนี้ หลังจากที่สร้างนโยบายที่จำเป็นแล้ว เราจะเพิ่มการผสานรวมกับห้องนิรภัยในบล็อกงานในไฟล์ job.nomad:

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

ฉันใช้การอนุญาตด้วยโทเค็นและลงทะเบียนโดยตรงที่นี่ นอกจากนี้ยังมีตัวเลือกในการระบุโทเค็นเป็นตัวแปรเมื่อเริ่มต้นตัวแทนเร่ร่อน:

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

ตอนนี้เราสามารถใช้กุญแจกับห้องนิรภัยได้แล้ว หลักการทำงานนั้นง่าย: เราสร้างไฟล์ในงาน 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 จะพัฒนาต่อไปและในอนาคตจะได้รับฟังก์ชันที่ทุกคนต้องการ

ผู้แต่ง: Ilya Andreev เรียบเรียงโดย Alexey Zhadan และทีม Live Linux


ที่มา: will.com

เพิ่มความคิดเห็น