Ρύθμιση ενός Nomad cluster χρησιμοποιώντας το Consul και ενσωμάτωση με το Gitlab

Εισαγωγή

Πρόσφατα, η δημοτικότητα του Kubernetes αυξάνεται ραγδαία - όλο και περισσότερα έργα το εφαρμόζουν. Ήθελα να αγγίξω έναν ενορχηστρωτή όπως το Nomad: είναι ιδανικό για έργα που χρησιμοποιούν ήδη άλλες λύσεις από τη HashiCorp, για παράδειγμα, Vault και Consul, και τα ίδια τα έργα δεν είναι πολύπλοκα όσον αφορά την υποδομή. Αυτό το υλικό θα περιέχει οδηγίες για την εγκατάσταση του Nomad, τον συνδυασμό δύο κόμβων σε ένα σύμπλεγμα, καθώς και την ενσωμάτωση του Nomad με το Gitlab.

Ρύθμιση ενός Nomad cluster χρησιμοποιώντας το Consul και ενσωμάτωση με το Gitlab

Περίπτερο δοκιμής

Λίγα λόγια για τον πάγκο δοκιμών: χρησιμοποιούνται τρεις εικονικοί διακομιστές με τα χαρακτηριστικά 2 CPU, 4 RAM, 50 Gb 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

Εγκατάσταση Nomad, Πρόξενος. Δημιουργία ενός Nomad cluster

Ας ξεκινήσουμε με τη βασική εγκατάσταση. Αν και η ρύθμιση ήταν απλή, θα την περιγράψω για χάρη της ακεραιότητας του άρθρου: ουσιαστικά δημιουργήθηκε από προσχέδια και σημειώσεις για γρήγορη πρόσβαση όταν χρειάζεται.

Πριν ξεκινήσουμε την πρακτική, θα συζητήσουμε το θεωρητικό μέρος, γιατί σε αυτό το στάδιο είναι σημαντικό να κατανοήσουμε τη μελλοντική δομή.

Έχουμε δύο νομαδικούς κόμβους και θέλουμε να τους συνδυάσουμε σε ένα σύμπλεγμα και στο μέλλον θα χρειαστούμε επίσης αυτόματη κλιμάκωση συστάδων - για αυτό θα χρειαστούμε Consul. Με αυτό το εργαλείο, η ομαδοποίηση και η προσθήκη νέων κόμβων γίνεται μια πολύ απλή εργασία: ο δημιουργημένος κόμβος Nomad συνδέεται με τον πράκτορα Consul και στη συνέχεια συνδέεται με το υπάρχον σύμπλεγμα Nomad. Επομένως, στην αρχή θα εγκαταστήσουμε τον διακομιστή Consul, θα διαμορφώσουμε τη βασική εξουσιοδότηση http για το web panel (είναι χωρίς εξουσιοδότηση από προεπιλογή και μπορεί να προσπελαστεί σε εξωτερική διεύθυνση), καθώς και οι ίδιοι οι πράκτορες Consul στους διακομιστές 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/

Τώρα έχουμε ένα έτοιμο δυαδικό consul για περαιτέρω διαμόρφωση.

Για να δουλέψουμε με το Consul, πρέπει να δημιουργήσουμε ένα μοναδικό κλειδί χρησιμοποιώντας την εντολή keygen:

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

Ας προχωρήσουμε στη ρύθμιση της διαμόρφωσης Consul, δημιουργώντας έναν κατάλογο /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"]
}

Ας δούμε τις κύριες οδηγίες και τις έννοιές τους ξεχωριστά:

  • bootstrap: αλήθεια. Ενεργοποιούμε την αυτόματη προσθήκη νέων κόμβων εάν είναι συνδεδεμένοι. Σημειώνω ότι δεν αναφέρουμε εδώ τον ακριβή αριθμό των αναμενόμενων κόμβων.
  • διακομιστής: αλήθεια. Ενεργοποίηση λειτουργίας διακομιστή. Ο Consul σε αυτήν την εικονική μηχανή θα λειτουργεί ως ο μόνος διακομιστής και κύριος αυτή τη στιγμή, το VM του Nomad θα είναι οι πελάτες.
  • κέντρο δεδομένων: dc1. Καθορίστε το όνομα του κέντρου δεδομένων για τη δημιουργία του συμπλέγματος. Πρέπει να είναι πανομοιότυπο τόσο στους πελάτες όσο και στους διακομιστές.
  • κρυπτογράφηση: το κλειδί σου. Το κλειδί, το οποίο πρέπει επίσης να είναι μοναδικό και να ταιριάζει σε όλους τους πελάτες και τους διακομιστές. Δημιουργήθηκε χρησιμοποιώντας την εντολή consul keygen.
  • start_join. Σε αυτή τη λίστα υποδεικνύουμε μια λίστα με διευθύνσεις IP στις οποίες θα γίνει η σύνδεση. Προς το παρόν αφήνουμε μόνο τη δική μας διεύθυνση.

Σε αυτό το σημείο μπορούμε να εκτελέσουμε το consul χρησιμοποιώντας τη γραμμή εντολών:

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

Ας ελέγξουμε: η υπηρεσία μας πρέπει να εκτελείται και εκτελώντας την εντολή consul Members θα πρέπει να δούμε τον διακομιστή μας:

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 βρίσκονται μόνο στον γκρίζο ιστό, επομένως δεν υπάρχει τέτοιο πρόβλημα εδώ.

Στους υπόλοιπους δύο διακομιστές εγκαθιστούμε πράκτορες 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

Ξεκινάμε το Consul στον διακομιστή. Τώρα, μετά την εκκίνηση, θα πρέπει να δούμε τη ρυθμισμένη υπηρεσία στα μέλη 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";
        }
        
}

Τώρα μπορούμε να έχουμε πρόσβαση στο web panel μέσω ενός εξωτερικού δικτύου. Συνδεθείτε και μεταβείτε στη σελίδα διακομιστών:

Ρύθμιση ενός Nomad cluster χρησιμοποιώντας το Consul και ενσωμάτωση με το Gitlab
Εικόνα 1. Λίστα διακομιστών στο σύμπλεγμα Nomad

Και οι δύο διακομιστές εμφανίζονται με επιτυχία στον πίνακα, θα δούμε το ίδιο πράγμα στην έξοδο της εντολής κατάστασης νομαδικού κόμβου:

Ρύθμιση ενός Nomad cluster χρησιμοποιώντας το Consul και ενσωμάτωση με το Gitlab
Εικόνα 2. Έξοδος της εντολής κατάστασης κόμβου nomad

Τι γίνεται με το Consul; Ας ρίξουμε μια ματιά. Μεταβείτε στον πίνακα ελέγχου Consul, στη σελίδα κόμβων:
Ρύθμιση ενός Nomad cluster χρησιμοποιώντας το Consul και ενσωμάτωση με το Gitlab
Εικόνα 3. Λίστα κόμβων στο σύμπλεγμα Consul

Τώρα έχουμε ένα έτοιμο Nomad που εργάζεται σε συνεργασία με τον Πρόξενο. Στο τελικό στάδιο, θα φτάσουμε στο διασκεδαστικό μέρος: τη ρύθμιση της παράδοσης κοντέινερ Docker από το Gitlab στο Nomad, και επίσης θα μιλήσουμε για μερικά από τα άλλα διακριτικά του χαρακτηριστικά.

Δημιουργία Gitlab Runner

Για να αναπτύξουμε εικόνες docker στο Nomad, θα χρησιμοποιήσουμε έναν ξεχωριστό runner με το δυαδικό αρχείο Nomad μέσα (εδώ, παρεμπιπτόντως, μπορούμε να σημειώσουμε ένα άλλο χαρακτηριστικό των εφαρμογών Hashicorp - μεμονωμένα είναι ένα ενιαίο δυαδικό αρχείο). Ανεβάστε το στον κατάλογο runner. Ας δημιουργήσουμε ένα απλό 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

Εδώ η ανάπτυξη πραγματοποιείται με μη αυτόματο τρόπο, αλλά μπορείτε να τη ρυθμίσετε ώστε να αλλάζει τα περιεχόμενα του καταλόγου του έργου. Το Pipeline αποτελείται από δύο στάδια: τη συναρμολόγηση εικόνας και την ανάπτυξή του στο nomad. Στο πρώτο στάδιο, συναρμολογούμε μια εικόνα 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 πρέπει να συνδεθώ σε αυτό. Η καλύτερη λύση σε αυτήν την περίπτωση είναι να εισαγάγετε ένα login και έναν κωδικό πρόσβασης στο Vault και στη συνέχεια να το ενσωματώσετε στο Nomad. Το 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"
}

Χρησιμοποιώ εξουσιοδότηση μέσω διακριτικού και την καταχωρίζω απευθείας εδώ, υπάρχει επίσης η επιλογή να προσδιορίσετε το διακριτικό ως μεταβλητή κατά την εκκίνηση του πράκτορα nomad:

$ 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 θα συνεχίσει να αναπτύσσεται και στο μέλλον θα αποκτήσει τις λειτουργίες που χρειάζεται ο καθένας.

Συγγραφέας: Ilya Andreev, που επιμελήθηκε ο Alexey Zhadan και η ομάδα του Live Linux


Πηγή: www.habr.com

Προσθέστε ένα σχόλιο