-
Notifications
You must be signed in to change notification settings - Fork 138
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
Example Nginx config grabs all services #80
Comments
I dropped that shell script in a gist: https://gist.github.com/tgross/2c98898ff5188d2986af so that people who are reading the thread don't have to download locally. This approach ties us to using links, which I feel like get a little confusing when it comes to having multiple nodes for a single backend application. But I definitely see your point here. There a couple of approaches we could use here:
As you say, it doesn't affect the example programs, but it would probably be a good idea for us to include one of these approaches in the example programs so that it's clear how a user might try it. I'll implement this. |
I have cleaned up my script. https://gist.github.com/donniev/4a006781af544fdda1a5 The original does not do the job completely as it failed to wrap some sections. |
My main goal is that this can be automated so you don't have to create a new template file manually as you add services. Checking for the port will not help if you have a service (like redis) which exposes a port but still should not be proxied by nginx. I like the idea of using tags so that everything is visible to consul. |
Doesn't that really only work if all your |
My generator grabs domain information for each service from an Manta object and so far I have been able to add new services by just updating the Manta object when I add a new service. I would rather have that info in a tag in service but whenever I query consul for tags I get an empty array. It seems like cb doesn’t register those tags with consul or else I am doing something wrong.
|
@donniev sorry I let this issue sit for a couple days. If the tags aren't being registered (or queried properly) then that's definitely a bug. Is it possible for you to share the Containerbuddy configuration you're using to write the tags? |
It was a while ago when I tried it. I will see if I can reproduce it.
|
Ok here is config
If I then open Consul the service is up and running and reports "No tags"
Which renders as
|
@donniev I tested this locally and was able to see tags being added. The example application actually uses a tag ("application" for the |
The cb executable I have been using I pulled from containerbuddy-0.0.1-alpha.tar.gz which is clearly out of date. What is process for building executeable for current version that I can include in my images. |
Yeah, that version didn't support tags yet (they were added in 0.1.0). For getting a new release you've got two options:
|
getting the following error:
which makes no sense to me because it is a file not a dir |
pulling latest directly from gihub solves the build issue but now I have a new problem. None of my services are registering with consul. (except nginx). I have made no changes to their config json files and the only change I have made to their docker images is to use the new cb executable. No clue at this point why they are no longer registering. Registered fine in previous version of cb. |
You may have build artifacts that are controlled by
Hard to debug that from here... can you provide logs from those containers, their configuration files, and/or the docker-compose file you're using to run them? |
Ok. I have tried to simplify by running the additional service by just adding to the examples docker-compose.yml
ninja.json
reload-ninja.sh
The app is up and running but does not register with consul |
make clean build did not help so am still using direct download of executable
|
Ok, so you have
I don't know what
I dug into this and you typically see this error from a Makefile syntax error. Is your make file modified in any way? (The reason I ask is because it Works On My Machine™) |
Doh. Obviously a complete misunderstanding on my part of purpose of onStart. Working now. Will try the make again on a clean pull. I did not intentionally change the makefile and git didn't say I had modified it but to make sure I will pull fresh but I need to get these other things working first. Thanks for your help. and yes tags do now show up in template. I am planning to use those to supply server names in the nginx config. When I didn't have tags I had a node plugin which returned them but I would like to get rid of that dependency |
Thanks for your help on the new version.
In the new approach I determine which services need an upstream by adding a comment line in docker-compose
and in maketemplate.sh I parse that
To generate the server block I now expect a service to have an array of tags containing the server names
Since the tags are available in the consul template I need no external calls. If .Tags is empty I don't create the server block
I think this is a lot cleaner. I am sure that is not what tags were designed for but it is an easy way to get the information into the consul template. I suppose you could also create key-value pairs. |
gist for new template https://gist.github.com/donniev/60cd7c97522c538f6d11 |
@donniev I think I get where you're going with this, but the example app isn't necessarily intended to be a universal applies-to-all-situations sort of thing. I wonder if it might make more sense to move this idea over to https://github.com/tgross/triton-nginx where we've built an Nginx configuration that is intended to be more universal? |
I've opened autopilotpattern/nginx#4 to continue work on this issue. Please join me over there! |
Observation. When creating default.conf file via the consul template an upstream is created for all services. If your cluster has containers which do not expose an external port and are not managed by nginx including an upstream for them will fail the nginx file because it will try to emit a port of 0.
This doesn't affect the example programs but would affect other situations.
I have modified my code to only create entries in the conf file for those services which are linked to nginx.
There are undoubtedly cleaner methods than the one am I using because I am certainly not a bash guru but I am including the file in case it is of interest (and in the hope that you say "Geez Don, it is a lot simpler to just do this ..."
start.sh.zip
The text was updated successfully, but these errors were encountered: