-
Notifications
You must be signed in to change notification settings - Fork 25
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
Update example ctmpl to select services #4
Comments
Currently it creates the base template(default.ctmpl) before it starts nginx. Nginx wll pick up when you start a service that was in the original docker-compose.yml when it is started but would not pick up any changes if you added to that file after nginx was deployed. It would use the tags of the service to generate the appropriate service blocks but if you had a new service that was not in the original list of services it would never get that far. There would have to be some mechanism that a) generated new base template default.ctmp b) copied it to consul k-v pair c) copied that to files system on nginx where it looks for that template. So basically execute the commands that the start.sh script does before it launches nginx |
https://gist.github.com/donniev/728d423bb754eff0012d I have added this script to my menu options. I deployed nginx without the "hexo" service in either that upstreams comment on in docker-compose. I then added the service in docker-compose and added it to the upstreams comment and then ran reloadbase.sh and started hexo. Shelled into nginx and looked at config file and it had picked hexo up. I did modify the reload-nginx.sh to always pull latest from consul instead of checking for $VIRTUALHOST so this seems to work. Of course it requires a manual step to run the reload but I don't think that is a big deal because you manually edited the docker-compose to add a new service so running that reload script after you are done can just be part of the workflow. |
I think you're getting at the crux of the problem here, which is that adding a new upstream to Nginx requires two things:
(Alternately, we could just redeploy a new Nginx container of course but I imagine that's what we're trying to avoid here.)
It's $NGINX_CONF in this repo but same thing. That was something we had added to give people an option for injecting the template as part of their
What it sounds like we want to do is to have both the Containerbuddy configuration and the Nginx configuration in Consul, and then try to get Nginx to poll the key somehow. Unless we do something like TritonDataCenter/containerpilot#87 maybe this is something we could add to the
The danger, as alluded to in TritonDataCenter/containerpilot#87, is that if the query on Consul runs long then the heartbeat TTL might expire and the node marked unhealthy. So we'll need to accommodate that. As an aside, I'm going to argue that automatically generating a virtualhost configuration from the list of services only works if the |
@tgross' concerns about the difficulty of building a generic Nginx image seem to have been born out as we've attempted to integrate this with other projects. I finally gave up hope for it recently and we overhauled this image and our usage example to reflect the following:
We're maintaining the image for those two usage scenarios. I believe the need expressed in this ticket is best addressed by using this Nginx as a base and building up from there. |
In TritonDataCenter/containerpilot#80 @donniev noted that our example configuration for Nginx grabs all the services. Because we want to mostly use the Containerbuddy examples as integration tests, I've recommended we move that discussion here.
@donniev has provided a proof-of-concept for generating the list of services we want into the template file: https://gist.github.com/donniev/60cd7c97522c538f6d11 We could use something like this to create the https://github.com/tgross/triton-nginx/blob/master/example/nginx.ctmpl template file prior to injecting it into the Nginx environment.
In adapting this script, we should be careful not to get ourselves into a situation where we can't add a new service to Nginx without a redeploy -- we should be able to add a service with the appropriate tag and have Nginx pick it up automatically with help from Containerbuddy.
The text was updated successfully, but these errors were encountered: