L'orchestration de conteneurs est actuellement associée principalement aux kubernetes. Mais ce n'est pas le seul choix possible. Il existe des outils d'orchestration alternatifs, tels que nomad, le développeur de HashiCorp (bien connu sous le nom de développeur de virtualisation Vagrant).
La maîtrise du travail avec l'orchestration est généralement difficile, car tout le monde n'a pas accès à l'infrastructure à partir de plusieurs serveurs avec un accès root, donc dans un article précédent
Nous déployons Kubernetes sur le bureau en quelques minutes avec MicroK8s, nous avons décrit le processus de déploiement de l'environnement Kubernetes sur le bureau en utilisant l'exemple d'application Django. Initialement, j'avais prévu de continuer à décrire l'exploitation de la base de données dans l'environnement MicroK8s. Mais j'ai pensé qu'il serait intéressant de continuer à travailler avec un outil d'orchestration nomade tout aussi pratique. Je ne donnerai même pas un allemand pour comparer différents systèmes d'orchestration. La seule chose que je remarque pour ceux qui doutent que le nomade soit encore plus facile à installer que les MicroK8, car Pour ce faire, copiez simplement les deux fichiers exécutables (nomade et consul) depuis le serveur du développeur.
Donc, comme je l'ai dit, vous devez d'abord télécharger
nomade et
consul , qui sont des binaires prêts à l'emploi pour tous les principaux systèmes d'exploitation. Vous n'avez pas besoin d'un accès root pour exécuter ces fichiers, donc tout peut être placé dans le répertoire personnel et exécuté au nom d'un utilisateur non privilégié.
Et, bien sûr, vous devriez déjà avoir docker installé, si seulement vous allez réorganiser les conteneurs docker. Soit dit en passant, nomad peut exécuter non seulement des conteneurs, mais aussi des exécutables réguliers, que nous utiliserons bientôt.
Donc, vous devez d'abord créer un fichier de configuration nomade. Nomad peut être lancé en mode serveur ou en mode client, ainsi que simultanément dans les deux modes (non recommandé en production). Pour ce faire, vous devez placer la section serveur, la section client ou les deux de ces sections dans le fichier de configuration:
bind_addr = "127.0.0.1" data_dir = "/tmp/nomad" advertise { http = "127.0.0.1" rpc = "127.0.0.1" serf = "127.0.0.1" } server { enabled = true bootstrap_expect = 1 } client { enabled = true options = { "driver.raw_exec.enable" = "1" } } consul { address = "127.0.0.1:8500" }
Nomad est lancé par une commande qui indique le chemin d'accès au fichier de configuration créé:
nomad agent --config nomad/nomad.conf
Dans la dernière section de la configuration, l'adresse à laquelle le consul travaillera est spécifiée. Consul peut également fonctionner en mode serveur, en mode client et en mode serveur et client:
consul agent -server -client 127.0.0.1 -advertise 127.0.0.1 -data-dir /tmp/consul -ui -bootstrap
Après avoir exécuté ces commandes, vous pouvez ouvrir dans le navigateur (http: // localhost: 4646) - c'est le nom de l'interface utilisateur et (http: // localhost: 8500) - c'est le consul de l'interface utilisateur.
Ensuite, créez un Dockerfile pour l'image Django. Du Dockerfile dans le
post précédent, il diffère de la ligne dans laquelle l'accès à Django est autorisé via n'importe quel hôte:
FROM python:3-slim LABEL maintainer="apapacy@gmail.com" WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt RUN django-admin startproject mysite /app \ && echo "\nALLOWED_HOSTS = ['*']\n" >> /app/mysite/settings.py EXPOSE 8000 STOPSIGNAL SIGINT ENTRYPOINT ["python", "manage.py"] CMD ["runserver", "0.0.0.0:8000"]
Après la construction de conteneurs:
docker build django/ -t apapacy/tut-django:1.0.1
Vous devez créer une tâche dans laquelle le nombre requis de répliques de conteneurs Django sera créé (nomad / django.conf):
job "django-job" { datacenters = ["dc1"] type = "service" group "django-group" { count = 3 restart { attempts = 2 interval = "30m" delay = "15s" mode = "fail" } ephemeral_disk { size = 300 } task "django-job" { driver = "docker" config { image = "apapacy/tut-django:1.0.1" port_map { lb = 8000 } } resources { network { mbits = 10 port "lb" {} } } service { name = "django" tags = ["urlprefix-/"] port = "lb" check { name = "alive" type = "http" path = "/" interval = "10s" timeout = "2s" } } } } }
Tous les paramètres de cette configuration sont assez compréhensibles en fonction de leurs noms. La seule chose que je voudrais décrypter est une ligne: le
port "lb" {} , ce qui signifie que les ports seront attribués dynamiquement par l'environnement (vous pouvez également les définir statiquement).
La tâche est lancée par la commande:
nomad job run nomad/django.conf
Maintenant, via le nomade de l'interface utilisateur (http: // localhost: 4646), vous pouvez voir l'état du travail django-job, et via le consul d'interface utilisateur (http: // localhost: 8500), vous pouvez voir l'état du service django, ainsi que les adresses IP et les ports sur lesquels il fonctionne. chaque réplique du service django. Désormais, les services sont disponibles via ces adresses IP, mais uniquement à l'intérieur du réseau nomade, et ne sont pas accessibles de l'extérieur. Afin de publier des services pour un accès externe, vous pouvez utiliser un certain nombre de fonctionnalités. Par exemple, via haproxy, mais la façon la plus simple de le faire est d'utiliser un autre module (troisième après nomade et consul) de HashiCorp - fabio.
Vous n'aurez pas non plus besoin de le télécharger - vous pouvez fournir ce cas nomade qui, comme je l'ai mentionné au début du message, peut fonctionner non seulement avec les conteneurs Docker, mais aussi avec tous les fichiers exécutables. Pour ce faire, créez une autre tâche (nomad / fabio.conf):
job "fabio-job" { datacenters = ["dc1"] type = "system" update { stagger = "60s" max_parallel = 1 } group "fabio-group" { count = 1 task "fabio-task" { driver = "raw_exec" artifact { source = "https://github.com/fabiolb/fabio/releases/download/v1.5.4/fabio-1.5.4-go1.9.2-linux_amd64" } config { command = "fabio-1.5.4-go1.9.2-linux_amd64" } resources { cpu = 100 # 500 MHz memory = 128 # 256MB network { mbits = 10 port "lb" { static = 9999 } port "admin" { static = 9998 } } } } } }
Le pilote
driver = "raw_exec" utilisé pour effectuer cette tâche. Tous les pilotes ne sont pas chargés par défaut, donc dans la configuration nomade, nous avons fourni cette fonctionnalité:
client { enabled = true options = { "driver.raw_exec.enable" = "1" } }
Soit dit en passant, dans les nouvelles versions de nomad, la syntaxe de chargement des plugins et des pilotes changera, donc cette partie de la configuration devra être finalisée bientôt.
La tâche est lancée par la commande:
nomad job run nomad/fabio.conf
Après cela, l'interface utilisateur fabio est disponible dans le navigateur à l'adresse (http: // localhost: 9998). Et à l'adresse (http: // localhost: 9999) le service django sera publié.
Le code des configurations présentées dans la publication se trouve dans le référentiel .
Liens utiles
1.dvps.blog/minimalnoie-sravnieniie-swarm-kubernetes-mesos-nomad-rancherpapacy@gmail.com
20 février 2019