entercloudsuite.consul

Rôle Ansible pour déployer Consul

Consul

Fonctionnalités

Configurer Consul avec YAML

La configuration pour le service Consul est faite à l'aide d'une conversion YAML en JSON, vous pouvez donc exprimer votre(s) configuration(s) Consul comme ceci :

consul_master_token: monToken
consul_server: vrai
consul_configs:
  main:
    acl_datacenter: pantheon
    acl_master_token: "{{ consul_master_token | to_uuid }}"
    bootstrap: vrai
    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: vrai

Cela se fait en utilisant des filtres Jinja2. Ce rôle n'implémente aucune entrée préconfigurée pour la configuration, donc plutôt que d'écrire la configuration de votre Consul en JSON ; vous l'exprimez simplement dans une syntaxe équivalente en YAML, ce qui signifie qu'elle peut se trouver n'importe où dans votre configuration Ansible.
Comme vu dans l'exemple ci-dessus, cela peut être très puissant, car cela vous permet de tirer parti 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 templating d'Ansible (y compris la récupération de données/informations d'hôte à partir de l'inventaire, etc.) peut être utilisé dans la configuration.

L'exemple de configuration ci-dessus montre des paires clé/valeur simples, mais vous pouvez bien sûr définir n'importe quel 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 n'a été testé que sur Ubuntu 16.04, mais il devrait fonctionner sur n'importe quelle distribution Linux. Il nécessite :

systemd
unzip

Variables par défaut du rôle

---
consul_packer_provision: faux
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éfinira cap_net_bind_service pour le port 53
consul_cap_net_bind_service: "{{ consul_configs.main.server | default('faux') }}"
consul_server: faux
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: démarré
# rechargé
# redémarré
# démarré
# arrêté

enable_on_boot: oui
# 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 rôle basique

- hosts: consul_servers
  vars:
    consul_master_token: monToken
    consul_server: vrai
    consul_config:
      acl_datacenter: pantheon
      acl_master_token: "{{ consul_master_token | to_uuid }}"
      bootstrap: vrai
      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: vrai
  roles:
      - entercloudsuite.consul

Ne pas configurer, juste installer

---
- nom: exécuter le rôle principal
  hosts: tous
  roles:
    - role: entercloudsuite.consul
      configure: faux
      install: vrai
      consul_service_status: "arrêté"
      consul_master_token: monToken
      consul_server: vrai
      consul_configs:
        main:
          acl_datacenter: pantheon
          acl_master_token: "{{ consul_master_token | to_uuid }}"
          bootstrap: vrai
          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: vrai

Ne pas installer, juste configurer

---
- nom: exécuter le rôle principal
  hosts: tous
  roles:
    - role: entercloudsuite.consul
      configure: vrai
      install: faux
      consul_service_status: "démarré"
      consul_master_token: monToken
      consul_server: vrai
      consul_configs:
        main:
          acl_datacenter: pantheon
          acl_master_token: "{{ consul_master_token | to_uuid }}"
          bootstrap: vrai
          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: vrai

Configurations de l'agent Consul

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

    - role: ansible-consul
      configure: vrai
      install: vrai
      consul_service_status: "démarré"
      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: vrai
          server: faux
          ui: vrai
          enable_script_checks: vrai
          rejoin_after_leave: vrai
          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: vrai
      install: vrai
      consul_service_status: "démarré"
      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: vrai
          server: vrai
          ui: vrai
          enable_script_checks: vrai
          rejoin_after_leave: vrai
          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 en utilisant Molecule.

Installez Molecule ou utilisez docker-compose run --rm molecule pour exécuter un conteneur Docker local, basé sur le projet entercloudsuite/molecule, à partir duquel 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 de rôle.
Ajoutez d'autres rôles nécessaires (externes) dans le fichier molecule/default/requirements.yml.
Modifiez le molecule/default/playbook.yml.
Définissez les tests infra dans le dossier molecule/default/tests en utilisant le vérificateur goos.
Lorsque vous êtes 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 avec 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