Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consul Template does not render templates before exec in Alpine Docker Image #1207

Closed
ingshtrom opened this issue Apr 19, 2019 · 4 comments
Closed
Labels

Comments

@ingshtrom
Copy link

ingshtrom commented Apr 19, 2019

Consul Template version

v0.20.0

Configuration

Here is a repo with all of the files necessary to reproduce. The README shows how to run it locally and in docker.

Expected behavior

They should both behave the way the local version of consul-template is working, which is each template is rendered and after all templates are rendered, then exec is run.

Actual behavior

The docker version of consul-template (1) is not tested from what I can tell and (2) in Docker alpine, exec is run before the templates are actually rendered, which breaks because my exec expects the templates to be there.

Steps to reproduce

See the linked repo README for instructions on running the reproduction

@ingshtrom ingshtrom changed the title Consul Template does not render templates before exec in alpine Consul Template does not render templates before exec in Alpine Docker Image Apr 22, 2019
@ingshtrom
Copy link
Author

The template I was using was

log_level = "info"
reload_signal = "SIGHUP"
kill_signal = "SIGTERM"
max_stale = "30s"

wait {
  min = "1m"
  max = "5m"
}

consul {
  retry {
    enabled     = true
    attempts    = 15
    backoff     = "250ms"
    max_backoff = "10s"
  }
}

template {
	source      = "/local/in.tpl"
	destination = "/local/out.txt"
}

template {
	source      = "/local/in2.tpl"
	destination = "/local/out2.txt"
}

exec {
	command = "/local/test.sh"
}

When I remove the global wait everything works as expected for both local and in-container versions of consul-template. I believe it might be similar to #1196.

@eikenb
Copy link
Contributor

eikenb commented Jun 25, 2019

I'm trying to figure out why you'd want both wait and once. From what I've gathered so far wait/quiescence was designed to prevent templates from re-rendering in quick succession when a watched value is flapping. When using once this doesn't seem to make sense as you are only rendering once and would get the state at that time (ie. flapping wouldn't matter).

Basically I'm curious if you have a use case where both wait and once make sense together. Thanks.

@ingshtrom
Copy link
Author

Right, so my thought was that wait would be essentially ignored for once runs.

The use case I have is related to rendering a HAProxy template. (bear with me)

So I have the application, HAProxy, which consumes multiple configurations which are rendered from Consul Template. When the application starts up, it needs the configurations to all be there, otherwise we get in a restart loop. So what I do is run Consul Template in once mode prior to starting HAProxy. After that, Consul Template runs normally to keep getting continual updates as Consul values change.

If you are familiar with Kubernetes, this looks like using the same container image for an initContainer, with the additional -once flag.

My workaround for this was to have two configurations, which can be specified via the CLI when starting Consul Template.

I'm fine if you want to call this user error, but it threw me for a loop and several hours of debugging before I figured out exactly what I was doing. As you describe it, which makes complete sense, maybe we should be disabling or raising an exception if both wait and once are set at the same time?

@eikenb
Copy link
Contributor

eikenb commented Jun 25, 2019

Your idea/use-case makes total sense to me and having to have duplicate config files shouldn't be necessary. It should just do the right thing... which IMO is that if you specify -once the wait/quiescence timers should be disabled.

Thanks for the feedback, it is greatly appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants