griggheo / ansible-consul-template Goto Github PK

Is this playbook on Ansible galaxy? I'm struggling to find it there.

It would be more secure to allow the option of creating a specific "consul-template" user and group and use these for file permissions and for running the system service.

Hello @griggheo !
Is it possible to release the latest version of your module ?
I actually like the latest PR and was going to do it and found somebody already did it ( Thanks @wilfriedroset )

j\x00

Hi,

I am seeing the following error when installing on CentOS7/RHEL 7.

TASK [griggheo.consul-template : copy consul-template upstart service configuration] ***
fatal: [127.0.0.1]: FAILED! => {"changed": false, "checksum": "a77a962bc6c943ac70e8895d96a76d4c2d551a38", "msg": "Destination directory /etc/init does not exist"}
ignoring

TASK [griggheo.consul-template : copy consul-template init.d script] ***********
skipping: [127.0.0.1]

apt is not available in RedHat systems. What do you think about conditionally using yum (when: ansible_os_family == "RedHat") in these systems?

Is it possible to release this new version ?
I would like to use the new dest parameter.

Regards.
J\x00

Hi all,

according to http://docs.ansible.com/ansible/latest/playbooks_loops.html#standard-loops
the line

Since such an item only contains one attribute 'src' one could think about turning it into a list.

Hey Grig !
I tested the new version and it seems to be working they we want it to .
Is it possible that you push this version to ansible-galaxy ?

Regards

J\x00

consul-template releases have been moved to https://releases.hashicorp.com/ (apparently in .zip format instead of .tar.gz)

Sorry to bother you again. I think there is a bug in the latest version (1.1.1) because you use the variable consul_template_config_dir (see commit) instead of consul_template_use_config_dir.

The consul-template service fails to start because of the attempt to redirect stdout to a log file. Systemd does not execute the ExecStart command as a shell, so these are passed as additional arguments to the consul-template command, which causes it to fail. See the output below:

# journalctl -u consul-template
-- Logs begin at Sat 2016-01-09 17:34:28 UTC, end at Sat 2016-01-09 18:39:27 UTC. --
Jan 09 18:32:29 mesos-slave-02 systemd[1]: Started consul-template.
Jan 09 18:32:29 mesos-slave-02 systemd[1]: Starting consul-template...
Jan 09 18:32:29 mesos-slave-02 consul-template[24970]: Consul Template returned errors:
Jan 09 18:32:29 mesos-slave-02 consul-template[24970]: cli: extra argument(s): [">>" "/var/log/consul-te
Jan 09 18:32:29 mesos-slave-02 systemd[1]: consul-template.service: main process exited, code=exited, st
Jan 09 18:32:29 mesos-slave-02 systemd[1]: Unit consul-template.service entered failed state.
Jan 09 18:32:29 mesos-slave-02 systemd[1]: consul-template.service failed.

I would suggest relying on journalctl for logging and ditching the log file when systemd is being used. I'd be happy to submit a PR for this, just thought I'd open an issue first to get your blessing.

Everything is in the title :)

Looks like the actual version is not the current one

https://galaxy.ansible.com/griggheo/consul-template

regards

I assume this role isn't being updated anymore, but wanted to put this here in case anyone uses it for newer versions (v0.18+) of consul-template. There needs to be some changes to ./templates/consul-template.service.systemd.j2 so that reload and stop/start works correctly. I am posting the full config I have that works:

[Unit]
Description=consul-template
Requires=network-online.target
After=network-online.target consul.service

[Service]
{% if consul_template_use_config_dir %}
ExecStart={{ consul_template_home }}/bin/{{ consul_template_binary }}  -config={{ consul_template_home }}/config
{% else %}
ExecStart={{ consul_template_home }}/bin/{{ consul_template_binary }}  -config={{ consul_template_home }}/config/{{ consul_template_config_file }}
{% endif %}
KillSignal=SIGINT
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Would you mind tagging a release so that I can use this role in a Galaxy requirements file without having to use master?

Any chance you could tag the latest version as 1.1.0?