Introduccion
Recientemente, la popularidad de Kubernetes está creciendo rápidamente: cada vez más proyectos lo implementan en casa. Quería tocar un orquestador como Nomad: es perfecto para proyectos que ya usan otras soluciones de HashiCorp, por ejemplo, Vault y Consul, y los proyectos en sí no son complicados en términos de infraestructura. Este artículo proporcionará instrucciones para instalar Nomad, combinar dos nodos en un clúster e integrar Nomad con Gitlab.
Banco de pruebas
Un poco sobre el banco de pruebas: se utilizan tres servidores virtuales con las características de 2 CPU, 4 RAM, SSD de 50 Gb, unidos en una red local común. Sus nombres y direcciones IP:
- nomad-livelinux-01 : 172.30.0.5
- nomad-livelinux-02 : 172.30.0.10
- cónsul-livelinux-01 : 172.30.0.15
Instalación de nómada, cónsul. Crear un grupo nómada
Pasemos a la instalación básica. A pesar de la facilidad de instalación, lo describiré por la integridad del artículo: de hecho, fue creado a partir de borradores y notas para un acceso rápido si es necesario.
Antes de comenzar la práctica, discutiremos la parte teórica, porque en esta etapa es importante comprender la estructura futura.
Tenemos dos nodos nómadas y queremos combinarlos en un clúster, y para el futuro necesitaremos un escalado automático del clúster; para esto necesitamos Cónsul. Con esta herramienta, agrupar y agregar nuevos nodos se convierte en una tarea muy simple: el nodo Nomad creado se conecta al agente Cónsul y luego se conecta al clúster Nomad existente. Por lo tanto, al principio instalaremos el servidor Consul, configuraremos la autorización http básica para el panel web (es por defecto sin autorización y se puede acceder por una dirección externa), así como los agentes Consul en los propios servidores Nomad, después de lo cual solo iniciaremos Nomad.
Instalar las herramientas HashiCorp es muy simple: de hecho, simplemente movemos el archivo binario al directorio bin, configuramos el archivo de configuración de la herramienta y creamos su archivo de servicio.
Descargue el archivo binario de Consul y descomprímalo en el directorio de inicio del usuario:
root@consul-livelinux-01:~
Ahora tenemos un archivo de cónsul binario listo para una configuración adicional.
Para trabajar con Consul, necesitamos crear una clave única usando el comando keygen:
root@consul-livelinux-01:~
Pasemos a configurar el Cónsul, cree el directorio /etc/consul.d/ con la siguiente estructura:
/etc/consul.d/ ├── bootstrap │ └── config.json
El directorio bootstrap contendrá el archivo de configuración config.json; en él estableceremos la configuración de Consul. Sus contenidos:
{ "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"] }
Examinemos por separado las principales directivas y sus significados:
- bootstrap : cierto. Activamos la adición automática de nuevos nodos si están conectados. Observo que no indicamos aquí el número exacto de nodos esperados.
- servidor : verdadero. Activa el modo servidor. Cónsul en esta máquina virtual será el único servidor y maestro en este momento, VM Nomad serán clientes.
- centro de datos : dc1. Especifique el nombre del centro de datos para crear un clúster. Debe ser idéntico tanto en clientes como en servidores.
- cifrar : su clave. Una clave que también debe ser única y coincidir en todos los clientes y servidores. Generado usando el comando consul keygen.
- inicio_unirse . En esta lista indicamos la lista de direcciones IP a las que se realizará la conexión. Por el momento, dejamos solo nuestra propia dirección.
En este punto, podemos comenzar a consultar usando la línea de comando:
root@consul-livelinux-01:~
Esta es una buena forma de depurar ahora, sin embargo, de forma continua, el uso de este método no funcionará por razones obvias. Cree un archivo de servicio para administrar Consul a través de systemd:
root@consul-livelinux-01:~
El contenido del archivo 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
Ejecute Consul a través de systemctl:
root@consul-livelinux-01:~
Verificamos: nuestro servicio debería iniciarse, y al ejecutar el comando de miembros del cónsul deberíamos ver nuestro servidor:
root@consul-livelinux:/etc/consul.d
El siguiente paso: instalar Nginx y configurar proxy, autorización http. Instale nginx a través del administrador de paquetes y cree el archivo de configuración consul.conf en el directorio / etc / nginx / sites-enabled con el siguiente contenido:
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"; } }
No olvide crear un archivo .htpasswd y generar un nombre de usuario y contraseña para él. Este elemento es necesario para que el panel web no sea accesible para todos los que conocen nuestro dominio. Sin embargo, al configurar Gitlab, tendremos que abandonar esto; de lo contrario, no podremos implementar nuestra aplicación en Nomad. En mi proyecto, tanto Gitlab como Nomad solo están en la red gris, por lo que no existe tal problema.
En los otros dos servidores, instale agentes Consul de acuerdo con las siguientes instrucciones. Repita los pasos con el archivo binario:
root@nomad-livelinux-01:~
Por analogía con el servidor anterior, creamos un directorio para los archivos de configuración /etc/consul.d con la siguiente estructura:
/etc/consul.d/ ├── client │ └── config.json
El contenido del archivo 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 } }
Guardamos los cambios y procedemos a la configuración del archivo de servicio, su contenido:
/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
Comenzamos cónsul en el servidor. Ahora, después de comenzar, deberíamos ver el servicio configurado en los miembros de nsul. Esto significará que se conectó con éxito al clúster como cliente. Repita lo mismo en el segundo servidor y después de eso podremos comenzar a instalar y configurar Nomad.
Una instalación más detallada de Nomad se describe en su documentación oficial. Hay dos métodos de instalación tradicionales: descargar un archivo binario y compilar desde la fuente. Elegiré el primer método.
Nota : el proyecto se está desarrollando muy rápido, a menudo salen nuevas actualizaciones. Quizás se lanzará una nueva versión para cuando se complete este artículo. Por lo tanto, recomiendo que antes de leer verifique la versión actual de Nomad en este momento y descárguela.
root@nomad-livelinux-01:~
Después de desempaquetar, obtendremos un archivo binario Nomad'a con un peso de 65 MB; debe moverse a / usr / local / bin.
Cree un directorio de datos para Nomad y edite su archivo de servicio (lo más probable es que no exista al principio):
root@nomad-livelinux-01:~
Inserte las siguientes líneas allí:
[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
Sin embargo, no tenemos prisa por ejecutar nómada, todavía no hemos creado su archivo de configuración:
root@nomad-livelinux-01:~
La estructura final del directorio será la siguiente:
/etc/nomad.d/ ├── nomad.hcl └── server.hcl
El archivo nomad.hcl debe contener la siguiente configuración:
datacenter = "dc1" data_dir = "/opt/nomad"
El contenido del archivo 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 }
No olvide cambiar el archivo de configuración en el segundo servidor; allí deberá cambiar el valor de la directiva http.
Lo último en esta etapa es la configuración de Nginx para la representación y la configuración de la autorización http. El contenido del archivo 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"; } }
Ahora podemos acceder al panel web a través de una red externa. Nos conectamos y vamos a la página de servidores:
Figura 1. Lista de servidores en un clúster Nomad
Ambos servidores se muestran con éxito en el panel, lo mismo que veremos en la salida del comando de estado del nodo nómada:
Imagen 2. La salida del comando de estado del nodo nómada
¿Qué hay del cónsul? A ver Vaya al panel de control de Consul, a la página de nodos:
Figura 3. Lista de nodos en el clúster Consul
Ahora hemos preparado a Nomad, trabajando en conjunto con el cónsul. En la etapa final, comenzaremos la parte más interesante: configuraremos la entrega de contenedores Docker de Gitlab a Nomad, y también hablaremos sobre algunas de sus otras características distintivas.
Crear corredor de Gitlab
Para implementar imágenes de Docker en Nomad, utilizaremos un corredor separado con el archivo binario Nomad dentro (aquí, por cierto, se puede observar una característica más de las aplicaciones Hashicorp: individualmente, son el único archivo binario). Descárguelo al directorio del corredor. Para él, cree el Dockerfile más simple con los siguientes contenidos:
FROM alpine:3.9 RUN apk add --update --no-cache libc6-compat gettext COPY nomad /usr/local/bin/nomad
En el mismo proyecto, cree .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}
Como resultado, tendremos una imagen accesible del corredor Nomad en el Registro de Gitlab, ahora podemos ir directamente al repositorio del proyecto, crear un Pipeline y configurar el trabajo Nomad.
Configuración del proyecto
Comencemos con el archivo del trabajo para Nomad. Mi proyecto en este artículo será bastante primitivo: consistirá en una tarea. El contenido de .gitlab-ci será el siguiente:
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
Aquí la implementación se realiza en modo manual, pero puede configurarla para cambiar el contenido del directorio del proyecto. La canalización consta de dos etapas: desde el ensamblaje de la imagen y su despliegue hasta el nómada. En la primera etapa, recopilamos la imagen del acoplador y la insertamos en nuestro Registro; en la segunda, lanzamos nuestro trabajo en 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" {} } } } } }
Tenga en cuenta que tengo un registro privado y para un grupo de imágenes de acoplador exitoso necesito iniciar sesión en él. La mejor solución en este caso es ingresar un nombre de usuario y contraseña en Vault con su posterior integración con Nomad. Nomad admite de forma nativa Vault. Pero primero, en Vault, instalaremos las políticas necesarias para Nomad, puede descargarlas:
Ahora, después de haber creado las políticas necesarias, agregaremos integración con Vault en el bloque de tareas en el archivo job.nomad:
vault { enabled = true address = "https://vault.domain.name:8200" token = "token" }
Uso la autorización por token y la escribo directamente aquí, también existe la opción de especificar el token como una variable cuando ejecuto el agente nómada:
$ VAULT_TOKEN=<token> nomad agent -config /path/to/config
Ahora podemos usar las teclas con Vault. El principio de funcionamiento es simple: creamos un archivo en el trabajo Nomad, que almacenará los valores de las variables, por ejemplo:
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 }
Con este enfoque simple, puede configurar la entrega de contenedores al clúster Nomad y trabajar con él en el futuro. Diré que hasta cierto punto simpatizo con Nomad: es más adecuado para proyectos pequeños donde Kubernetes puede causar dificultades adicionales y no se dará cuenta de su potencial hasta el final. Además, Nomad es perfecto para principiantes: es fácil de instalar y configurar. Sin embargo, cuando pruebo en algunos proyectos, encuentro el problema de sus versiones anteriores: muchas funciones básicas simplemente no existen o no funcionan correctamente. Sin embargo, creo que Nomad continuará desarrollándose y en el futuro adquirirá todas las funciones necesarias.
Publicado por Ilya Andreev, editado por Alexei Zhadan y Live Linux Team