automium.consul

Rôle Ansible pour déployer Consul

Consul

Fonctionnalités

Configurer Consul avec YAML

La configuration pour le service Consul se fait par conversion de YAML en JSON, ce qui permet d'exprimer vos configurations Consul de cette manière :

consul_master_token: monToken
consul_server: true
consul_configs:
  main:
    acl_datacenter: pantheon
    acl_master_token: "{{ consul_master_token | to_uuid }}"
    bootstrap: true
    bind_addr: 0.0.0.0
    client_addr: 0.0.0.0
    datacenter: pantheon
    data_dir: "{{ consul_data_dir }}"
    log_level: INFO
    node_name: master
    server: "{{ consul_server }}"
    ui: true

Ceci se fait à l'aide de filtres Jinja2. Ce rôle ne met pas en œuvre d'entrées préconfigurées pour la configuration, donc au lieu d'écrire la configuration de Consul en JSON, vous l'exprimez simplement dans une syntaxe équivalente YAML, ce qui signifie que cela peut se trouver n'importe où dans votre configuration Ansible.
Comme montré dans l'exemple ci-dessus, cela peut être très puissant, car cela vous permet d'utiliser d'autres filtres disponibles dans Ansible pour construire des données arbitraires et les utiliser dans la configuration. Tout ce que vous pouvez exprimer avec le système de modèles d’Ansible (y compris la récupération de données/informations sur les hôtes à partir de l'inventaire, etc.) peut être utilisé dans la configuration.

L'exemple de configuration ci-dessus montre de simples paires clé/valeur, mais vous pouvez bien sûr définir tout type valide en YAML, comme des dictionnaires et des listes.
Si vous ne savez pas comment exprimer la configuration JSON de Consul en YAML, consultez ici pour un convertisseur pratique.

Exigences

Ce rôle a seulement été testé sur Ubuntu 16.04, mais devrait fonctionner sur n'importe quelle distribution Linux. Il nécessite :

systemd
unzip

Variables par défaut du rôle

---
consul_packer_provision: false
consul_group_name: consul
consul_group_gid: 3000
consul_user_name: consul
consul_user_uid: 3000
consul_user_home: /opt/consul
consul_config_dir: "{{ consul_user_home }}/conf.d"
consul_data_dir: "{{ consul_user_home }}/data"
consul_version: 1.6.3
# si consul est configuré pour être un serveur, systemd définit cap_net_bind_service pour le port 53
consul_cap_net_bind_service: "{{ consul_configs.main.server | default('false') }}"
consul_server: false
consul_uri: "https://releases.hashicorp.com/consul/{{ consul_version }}/consul_{{ consul_version }}_linux_amd64.zip"
consul_config_src: main.json.j2
consul_config_validate: "{{ consul_user_home }}/bin/consul validate -config-format=json %s"
consul_extra_args: []
consul_service_file:
  src: consul.service.j2
  dest: /etc/systemd/system/consul.service
consul_service_status: started
# rechargé
# redémarré
# démarré
# arrêté

enable_on_boot: yes
# oui
# non

# configurez cette variable pour ne pas exécuter l'étape de configuration
# no_configure

# configurez cette variable pour ne pas exécuter l'étape de configuration
# no_install

consul_config:
  datacenter: dc-1
  data_dir: "{{ consul_data_dir }}"
  log_level: INFO
  node_name: node-1
  server: "{{ consul_server }}"

Exemple de Playbook

Configuration de base du rôle

- hosts: consul_servers
  vars:
    consul_master_token: monToken
    consul_server: true
    consul_config:
      acl_datacenter: pantheon
      acl_master_token: "{{ consul_master_token | to_uuid }}"
      bootstrap: true
      bind_addr: 0.0.0.0
      client_addr: 0.0.0.0
      datacenter: pantheon
      data_dir: "{{ consul_data_dir }}"
      log_level: INFO
      node_name: master
      server: "{{ consul_server }}"
      ui: true
  roles:
      - entercloudsuite.consul

Ne pas configurer, juste installer

---
- name: exécuter le rôle principal
  hosts: all
  roles:
    - role: entercloudsuite.consul
      configure: false
      install: true
      consul_service_status: "stopped"
      consul_master_token: monToken
      consul_server: true
      consul_configs:
        main:
          acl_datacenter: pantheon
          acl_master_token: "{{ consul_master_token | to_uuid }}"
          bootstrap: true
          bind_addr: 0.0.0.0
          client_addr: 0.0.0.0
          datacenter: pantheon
          data_dir: "{{ consul_data_dir }}"
          log_level: INFO
          node_name: master
          server: "{{ consul_server }}"
          ui: true

Ne pas installer, juste configurer

---
- name: exécuter le rôle principal
  hosts: all
  roles:
    - role: entercloudsuite.consul
      configure: true
      install: false
      consul_service_status: "started"
      consul_master_token: monToken
      consul_server: true
      consul_configs:
        main:
          acl_datacenter: pantheon
          acl_master_token: "{{ consul_master_token | to_uuid }}"
          bootstrap: true
          bind_addr: 0.0.0.0
          client_addr: 0.0.0.0
          datacenter: pantheon
          data_dir: "{{ consul_data_dir }}"
          log_level: INFO
          node_name: master
          server: "{{ consul_server }}"
          ui: true

Configurations de l'agent Consul

Exemples de configurations d'agent, il rejoint le serveur dans groups['server']

    - role: ansible-consul
      configure: true
      install: true
      consul_service_status: "started"
      consul_version: 1.6.3
      consul_configs:
        main:
          bind_addr: "{{ ansible_default_ipv4['address'] }}"
          client_addr: 0.0.0.0
          node_name: "{{ ansible_hostname }}"
          data_dir: "{{ consul_data_dir }}"
          datacenter: "pantheon"
          enable_syslog: true
          server: false
          ui: true
          enable_script_checks: true
          rejoin_after_leave: true
          retry_join: "{{ groups['server'] | map('extract', hostvars, ['ansible_default_ipv4', 'address']) | list }}"

Exemple de serveur Consul

Exemples de configurations de serveur, les hôtes dans groups['server'] créent un nouveau cluster Consul.

    - role: ansible-consul
      configure: true
      install: true
      consul_service_status: "started"
      consul_version: 1.6.3
      consul_configs:
        main:
          bind_addr: "{{ ansible_default_ipv4['address'] }}"
          client_addr: 0.0.0.0
          node_name: "{{ ansible_hostname }}"
          data_dir: "{{ consul_data_dir }}"
          datacenter: "pantheon"
          enable_syslog: true
          server: true
          ui: true
          enable_script_checks: true
          rejoin_after_leave: true
          retry_join: "{{ groups['server'] | map('extract', hostvars, ['ansible_default_ipv4', 'address']) | list }}"
          ports:
            dns: 53
          dns_config:
            udp_answer_limit: 64
          bootstrap_expect: "{{ groups['server'] | length | int }}"
          recursors:
            - 1.1.1.1
            - 8.8.8.8

Tests

Des tests sont effectués avec Molecule.

Installez Molecule ou utilisez docker-compose run --rm molecule pour exécuter un conteneur Docker local, basé sur le projet entercloudsuite/molecule, depuis lequel vous pouvez utiliser molecule.

Exécutez molecule create pour démarrer le conteneur Docker cible sur votre moteur local.
Utilisez molecule login pour vous connecter au conteneur en cours d'exécution.
Modifiez les fichiers du rôle.
Ajoutez d'autres rôles requis (externes) dans le fichier molecule/default/requirements.yml.
Modifiez le molecule/default/playbook.yml.
Définissez les tests infra sous le dossier molecule/default/tests en utilisant le vérificateur goos.
Quand tout est prêt, utilisez molecule converge pour exécuter le playbook Ansible et molecule verify pour exécuter la suite de tests. Notez que le processus de convergence commence par effectuer une vérification de syntaxe du rôle. Détruisez le conteneur Docker avec la commande molecule destroy.

Pour exécuter toutes les étapes en une seule commande, exécutez molecule test.

Pour exécuter le rôle ciblant une VM, utilisez le fichier playbook_deploy.yml par exemple avec la commande suivante : ansible-playbook ansible-docker/molecule/default/playbook_deploy.yml -i VM_IP_OR_FQDN, -u ubuntu --private-key private.pem