saltstack-formulas / consul-formula

Formula to install and configure Hashicorp Consul

consul

Formula to install and configure Hashicorp Consul.

Table of Contents

• General notes
• Contributing to this repo
• Special notes
• Available states
  • consul
  • consul.install
  • consul.config
  • consul.service
  • consul-template
• Testing
  • Requirements
  • bin/kitchen converge
  • bin/kitchen verify
  • bin/kitchen destroy
  • bin/kitchen test
  • bin/kitchen login
• Testing with Vagrant
  • Requirements
  • Setup
  • Note
  • bin/kitchen converge
  • bin/kitchen verify
  • bin/kitchen destroy
  • bin/kitchen test
  • bin/kitchen login

General notes

See the full SaltStack Formulas installation and usage instructions.

If you are interested in writing or contributing to formulas, please pay attention to the Writing Formula Section.

If you want to use this formula, please pay attention to the FORMULA file and/or git tag, which contains the currently released version. This formula is versioned according to Semantic Versioning.

See Formula Versioning Section for more details.

If you need (non-default) configuration, please pay attention to the pillar.example file and/or Special notes section.

Contributing to this repo

Commit message formatting is significant!!

Please see How to contribute for more details.

Special notes

None.

Available states

• consul
• consul.install
• consul.config
• consul.service
• consul-template

consul

Installs and configures the Consul service.

consul.install

Downloads and installs the Consul binary file.

consul.config

Provision the Consul configuration files and sources.

consul.service

Adds the Consul service startup configuration or script to an operating system.

To start a service during Salt run and enable it at boot time, you need to set following Pillar:

consul:
  service: true

consul-template

Installs and configures Consul template.

Testing

Linux testing is done with kitchen-salt.

Requirements

• Ruby
• Docker

$ gem install bundler
$ bundle install
$ bin/kitchen test [platform]

Where [platform] is the platform name defined in kitchen.yml, e.g. debian-9-2019-2-py3.

bin/kitchen converge

Creates the docker instance and runs the consul main state, ready for testing.

bin/kitchen verify

Runs the inspec tests on the actual instance.

bin/kitchen destroy

Removes the docker instance.

bin/kitchen test

Runs all of the stages above in one go: i.e. destroy + converge + verify + destroy.

bin/kitchen login

Gives you SSH access to the instance for manual testing.

Testing with Vagrant

Windows/FreeBSD/OpenBSD testing is done with kitchen-salt.

Requirements

• Ruby
• Virtualbox
• Vagrant

Setup

$ gem install bundler
$ bundle install --with=vagrant
$ bin/kitchen test [platform]

Where [platform] is the platform name defined in kitchen.vagrant.yml, e.g. windows-81-latest-py3.

Note

When testing using Vagrant you must set the environment variable KITCHEN_LOCAL_YAML to kitchen.vagrant.yml. For example:

$ KITCHEN_LOCAL_YAML=kitchen.vagrant.yml bin/kitchen test      # Alternatively,
$ export KITCHEN_LOCAL_YAML=kitchen.vagrant.yml
$ bin/kitchen test

Then run the following commands as needed.

bin/kitchen converge

Creates the Vagrant instance and runs the salt main states, ready for testing.

bin/kitchen verify

Runs the inspec tests on the actual instance.

bin/kitchen destroy

Removes the Vagrant instance.

bin/kitchen test

Runs all of the stages above in one go: i.e. destroy + converge + verify + destroy.

bin/kitchen login

Gives you RDP/SSH access to the instance for manual testing.

consul-formula's Issues

SLS render fails without `template_engine`

I've got the following error when running consul-template with a pillar similar to the example:

    Data failed to compile:
----------
    Rendering SLS 'base:consul-template.config' failed: Jinja variable 'dict object' has no attribute 'template_engine'

Adding template_engine: null to the tmpl section results in errors about the resulting None value.

template_engine: jinja causes jinja syntax errors when trying to read the go template used by consul-template.

I was able to bypass the issue by removing line 15 in consul-template/config.sls: - template: {{ tmpl.template_engine }}

Windows support

Hey, it would be great if you added support for winows agents.

Thanks :)

Adding Certificate support

Hi,

Is it an option to add configuration features :

• "ca_file" -> https://www.consul.io/docs/agent/options.html#ca_file
• "cert_file" -> https://www.consul.io/docs/agent/options.html#cert_file
• "key_file" -> https://www.consul.io/docs/agent/options.html#key_file

Thanks,

Support cloud auto-join feature

Hi,

There is a cloud auto-join feature in conusul (https://www.consul.io/docs/agent/options.html#cloud-auto-joining). What do you think about adding support for this feature ?

I can probably do the Pull Request :)

Bye !

[BUG] service fails to start in Centos 8

Bug details

Describe the bug

Just noticed this when we changed from Centos 7 to Centos 8.
With selinux enforcing, the consul binary moved from /tmp retains the context tmp_t. selinux denies execution of the consul binary so startup fails.

Steps to reproduce the bug

In pillar, set:

consul:
  service: True

Install and try to run consul on a Centos 8 minion.
salt-call state.apply consul

state will fail.

Check the audit log:

grep consul /var/log/audit/audit.log

Expected behaviour

service should start

Attempts to fix the bug

We use the following in install.sls after file.rename fixes the context;

{% if grains['os_family'] == 'RedHat' %}
consul_bin_restorecon:
  module.run:
    - file.restorecon:
        - /usr/local/bin/consul-{{consul.version}}
    - watch:
      - file: consul_install
{% endif %}

Use the module function file.restorecon to change the context of the consul binary to match destination location of the file - which then permits execution by systemd.

Default to support Multiple IPs

Hi,

setting bind_addr to 0.0.0.0 fails on hosts with multiple IPs.

If you change consul/defaults.yaml:
bind_addr: 0.0.0.0
to
`bind_addr: "{{ grains['ip4_interfaces']['eth0'][0] }}"``
then it will always work.

Not a bug, and not foolproof either. After posting this, I realised just how hard it is to get the 'right' IP from the grains!

Geoff