Présentation
RĂ©cemment, la popularitĂ© de Kubernetes augmente rapidement - de plus en plus de projets le mettent en Ćuvre Ă la maison. Je voulais toucher un orchestrateur comme Nomad: il est parfait pour les projets qui utilisent dĂ©jĂ d'autres solutions de HashiCorp, par exemple, Vault et Consul, et les projets eux-mĂȘmes ne sont pas compliquĂ©s en termes d'infrastructure. Cet article fournira des instructions sur l'installation de Nomad, la combinaison de deux nĆuds dans un cluster et l'intĂ©gration de Nomad avec Gitlab.
Banc d'essai
Un peu sur le banc de test: trois serveurs virtuels sont utilisés avec les caractéristiques de 2 CPU, 4 RAM, SSD 50 Go, réunis dans un réseau local commun. Leurs noms et adresses IP:
- nomad-livelinux-01 : 172.30.0.5
- nomad-livelinux-02 : 172.30.0.10
- consul-livelinux-01 : 172.30.0.15
Installation de Nomad, Consul. Création d'un cluster nomade
Passons à l'installation de base. Malgré la facilité d'installation, je vais le décrire pour l'intégrité de l'article: en fait, il a été créé à partir de brouillons et de notes pour un accÚs rapide si nécessaire.
Avant de commencer la pratique, nous discuterons de la partie théorique, car à ce stade, il est important de comprendre la structure future.
Nous avons deux nĆuds nomades et nous voulons les combiner en un cluster, et pour l'avenir, nous aurons besoin d'une mise Ă l'Ă©chelle automatique du cluster - pour cela, nous avons besoin de Consul. Ă l'aide de cet outil, le clustering et l'ajout de nouveaux nĆuds deviennent une tĂąche trĂšs simple: le nĆud Nomad crĂ©Ă© se connecte Ă l'agent Consul, puis se connecte au cluster Nomad existant. Par consĂ©quent, au dĂ©but, nous allons installer le serveur Consul, configurer l'autorisation http de base pour le panneau Web (elle est par dĂ©faut sans autorisation et peut ĂȘtre consultĂ©e Ă une adresse externe), ainsi que les agents Consul eux-mĂȘmes sur les serveurs Nomad, aprĂšs quoi nous dĂ©marrons simplement Nomad.
L'installation des outils HashiCorp est trÚs simple: en fait, nous déplaçons simplement le fichier binaire dans le répertoire bin, configurons le fichier de configuration de l'outil et créons son fichier de service.
Téléchargez le fichier binaire Consul et décompressez-le dans le répertoire personnel de l'utilisateur:
root@consul-livelinux-01:~
Nous avons maintenant un fichier consul binaire prĂȘt Ă l'emploi pour une configuration supplĂ©mentaire.
Pour travailler avec Consul, nous devons créer une clé unique à l'aide de la commande keygen:
root@consul-livelinux-01:~
Passons à la configuration du Consul, créons le répertoire /etc/consul.d/ avec la structure suivante:
/etc/consul.d/ âââ bootstrap â âââ config.json
Le répertoire bootstrap contiendra le fichier de configuration config.json - nous y définirons les paramÚtres Consul. Son contenu:
{ "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"] }
Examinons séparément les principales directives et leur signification:
- bootstrap : vrai. Nous activons l'ajout automatique de nouveaux nĆuds s'ils sont connectĂ©s. Je note que nous n'indiquons pas ici le nombre exact de nĆuds attendus.
- serveur : vrai. Activez le mode serveur. Le consul sur cette machine virtuelle sera le seul serveur et maĂźtre pour le moment, VM Nomad sera client.
- centre de donnĂ©es : dc1. SpĂ©cifiez le nom du centre de donnĂ©es pour crĂ©er un cluster. Il doit ĂȘtre identique sur les clients et les serveurs.
- crypter : votre-clĂ©. Une clĂ© qui doit Ă©galement ĂȘtre unique et correspondre Ă tous les clients et serveurs. GĂ©nĂ©rĂ© Ă l'aide de la commande consul keygen.
- start_join . Dans cette liste, nous indiquons la liste des adresses IP auxquelles la connexion sera Ă©tablie. Pour le moment, nous ne laissons que notre propre adresse.
à ce stade, nous pouvons démarrer consul en utilisant la ligne de commande:
root@consul-livelinux-01:~
C'est un bon moyen de déboguer maintenant, cependant, sur une base continue, l'utilisation de cette méthode ne fonctionnera pas pour des raisons évidentes. Créez un fichier de service pour gérer Consul via systemd:
root@consul-livelinux-01:~
Le contenu du fichier 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
Exécutez Consul via systemctl:
root@consul-livelinux-01:~
Nous vĂ©rifions: notre service doit ĂȘtre dĂ©marrĂ©, et en exĂ©cutant la commande consul members, nous devrions voir notre serveur:
root@consul-livelinux:/etc/consul.d
L'étape suivante: installer Nginx et configurer un proxy, autorisation http. Installez nginx via le gestionnaire de packages et dans le répertoire / etc / nginx / sites-enabled créez le fichier de configuration consul.conf avec le contenu suivant:
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"; } }
N'oubliez pas de créer un fichier .htpasswd et de générer un nom d'utilisateur et un mot de passe pour celui-ci. Cet élément est requis pour que le panneau Web ne soit pas accessible à tous ceux qui connaissent notre domaine. Cependant, lors de la configuration de Gitlab, nous devrons l'abandonner - sinon nous ne pourrons pas déployer notre application sur Nomad. Dans mon projet, Gitlab et Nomad sont uniquement sur le réseau gris, il n'y a donc pas de problÚme.
Sur les deux autres serveurs, installez les agents Consul conformément aux instructions suivantes. Répétez les étapes avec le fichier binaire:
root@nomad-livelinux-01:~
Par analogie avec le serveur précédent, nous créons un répertoire pour les fichiers de configuration /etc/consul.d avec la structure suivante:
/etc/consul.d/ âââ client â âââ config.json
Le contenu du fichier 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 } }
Nous enregistrons les modifications et procédons à la configuration du fichier de service, son contenu:
/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
Nous commençons consul sur le serveur. Maintenant, aprĂšs le dĂ©marrage, nous devrions voir le service configurĂ© dans les membres nsul. Cela signifie qu'il s'est connectĂ© avec succĂšs au cluster en tant que client. RĂ©pĂ©tez la mĂȘme chose sur le deuxiĂšme serveur et aprĂšs cela, nous pourrons commencer Ă installer et configurer Nomad.
Une installation plus détaillée de Nomad est décrite dans sa documentation officielle. Il existe deux méthodes d'installation traditionnelles: le téléchargement d'un fichier binaire et la compilation à partir des sources. Je choisirai la premiÚre méthode.
Remarque : le projet se dĂ©veloppe trĂšs rapidement, de nouvelles mises Ă jour sortent souvent. Peut-ĂȘtre qu'une nouvelle version sera publiĂ©e au moment oĂč cet article sera terminĂ©. Par consĂ©quent, je recommande qu'avant de lire, vĂ©rifiez la version actuelle de Nomad pour le moment et tĂ©lĂ©chargez-la.
root@nomad-livelinux-01:~
AprĂšs le dĂ©ballage, nous obtiendrons un fichier binaire Nomad'a pesant 65 Mo - il doit ĂȘtre dĂ©placĂ© vers / usr / local / bin.
Créez un répertoire de données pour Nomad et éditez son fichier de service (il n'existera probablement pas au début):
root@nomad-livelinux-01:~
Insérez-y les lignes suivantes:
[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
Cependant, nous ne sommes pas pressés d'exécuter nomade - nous n'avons pas encore créé son fichier de configuration:
root@nomad-livelinux-01:~
La structure finale du répertoire sera la suivante:
/etc/nomad.d/ âââ nomad.hcl âââ server.hcl
Le fichier nomad.hcl doit contenir la configuration suivante:
datacenter = "dc1" data_dir = "/opt/nomad"
Le contenu du fichier 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 }
N'oubliez pas de changer le fichier de configuration sur le deuxiĂšme serveur - lĂ , vous devrez changer la valeur de la directive http.
Le dernier à ce stade est la configuration de Nginx pour le proxy et la définition de l'autorisation http. Le contenu du fichier 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"; } }
Nous pouvons maintenant accéder au panneau Web via un réseau externe. Nous nous connectons et allons sur la page des serveurs:
Figure 1. Liste des serveurs dans un cluster Nomad
Les deux serveurs sont affichĂ©s avec succĂšs dans le panneau, la mĂȘme chose que nous verrons dans la sortie de la commande d'Ă©tat du nĆud nomade:
Image 2. La sortie de la commande nomad node status
Et le consul? Voyons voir. AccĂ©dez au panneau de configuration Consul, Ă la page des nĆuds:
Figure 3. Liste des nĆuds du cluster Consul
Nous avons maintenant préparé Nomad, en collaboration avec le consul. Dans la derniÚre étape, nous allons commencer la partie la plus intéressante: nous allons configurer la livraison des conteneurs Docker de Gitlab à Nomad, ainsi que parler de certaines de ses autres caractéristiques distinctives.
Créer Gitlab Runner
Pour dĂ©ployer des images de docker sur Nomad, nous utiliserons un exĂ©cuteur sĂ©parĂ© avec le fichier binaire Nomad Ă l'intĂ©rieur (ici, au fait, une autre fonctionnalitĂ© des applications Hashicorp peut ĂȘtre notĂ©e - individuellement, il s'agit du seul fichier binaire). TĂ©lĂ©chargez-le dans le rĂ©pertoire runner. Pour lui, crĂ©ez le Dockerfile le plus simple avec le contenu suivant:
FROM alpine:3.9 RUN apk add --update --no-cache libc6-compat gettext COPY nomad /usr/local/bin/nomad
Dans le mĂȘme projet, crĂ©ez .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}
En conséquence, nous aurons une image accessible du runner Nomad dans le registre Gitlab, maintenant nous pouvons aller directement au référentiel du projet, créer un Pipeline et configurer le job nomade Nomad.
Configuration du projet
Commençons par le dossier de travail pour Nomad. Mon projet dans cet article sera assez primitif: il consistera en une tùche. Le contenu de .gitlab-ci sera le suivant:
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
Ici, le déploiement se produit en mode manuel, mais vous pouvez le configurer pour modifier le contenu du répertoire du projet. Le pipeline comprend deux étapes: de l'assemblage de l'image et de son déploiement au nomade. Dans un premier temps, nous collectons l'image docker et la poussons dans notre Registre; dans un second temps, nous lançons notre travail dans 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" {} } } } } }
Veuillez noter que j'ai un registre privĂ© et que pour un pool d'images Docker rĂ©ussi, je dois me connecter. La meilleure solution dans ce cas est d'entrer un identifiant et un mot de passe dans Vault avec son intĂ©gration ultĂ©rieure avec Nomad. Nomad prend en charge nativement Vault. Mais d'abord, dans Vault lui-mĂȘme, nous installerons les politiques nĂ©cessaires pour Nomad, vous pouvez les tĂ©lĂ©charger:
Maintenant, aprÚs avoir créé les politiques nécessaires, nous allons ajouter l'intégration avec Vault dans le bloc de tùches du fichier job.nomad:
vault { enabled = true address = "https://vault.domain.name:8200" token = "token" }
J'utilise l'autorisation par token et l'écris directement ici, il y a aussi la possibilité de spécifier le token comme variable lors de l'exécution de l'agent nomade:
$ VAULT_TOKEN=<token> nomad agent -config /path/to/config
Maintenant, nous pouvons utiliser les clés avec Vault. Le principe de fonctionnement est simple: on crée un fichier dans le job Nomad, qui va stocker les valeurs des variables, par exemple:
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 }
Avec cette approche simple, vous pouvez configurer la livraison des conteneurs au cluster Nomad et travailler avec lui Ă l'avenir. Je dirai que dans une certaine mesure, je sympathise avec Nomad - il convient mieux aux petits projets oĂč Kubernetes peut causer des difficultĂ©s supplĂ©mentaires et ne rĂ©alisera pas son potentiel Ă la fin. De plus, Nomad est parfait pour les dĂ©butants - il est facile Ă installer et Ă configurer. Cependant, lors de tests sur certains projets, je rencontre le problĂšme de ses versions antĂ©rieures - de nombreuses fonctions de base n'existent tout simplement pas ou ne fonctionnent pas correctement. NĂ©anmoins, je pense que Nomad va continuer Ă se dĂ©velopper et Ă l'avenir acquĂ©rir toutes les fonctions nĂ©cessaires.
Publié par Ilya Andreev, édité par Alexei Zhadan et Live Linux Team