-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
Feature/env #76
Feature/env #76
Conversation
Thanks! Will take a look over this properly in a bit. You might also be interested in #64. /cc @sherzberg |
It's an extremly quick/simple feature to implement. Yes, i read about #64, and i have some comments to elaborate before i post. |
+1 for this. I want to be able to inject file paths in the volumes section of web:
build: .
ports:
- 5000:5000
volumes:
- .:/app
links:
- redis
- db becomes: web:
build: $DOCKER_ROOT
ports:
- 5000:5000
volumes:
- $APP_ROOT:/app
links:
- redis
- db |
+1 for implementing os.path.expandvars . Although we understand in theory why it might not be advisable to have envvars in the fig.yml, in practice we don't want to have credentials in our repositories, and the fig file gives very important structural and actionable information to be left out of the repos. |
I agree that this would solve a pressing problem (secrets in version control), but I'm also a fan of #64, and I'm not yet sure how we'd get both features to coexist nicely. One option would be to use
I haven't fully thought through the implications and complexity of implementation, though. |
Would it be possible to extend this feature to having fig read a settings file (e.g. .env) Then you could have something like production.env staging.env fig.yml
then do something like |
One of the things that was added to maestro-ng (signalfx/maestro-ng#8) is simply preprocessing the yaml with Jinja so the yaml looks like: environment:
- DB_PASSWORD: {{ env.DB_PASSWORD }} I can't say I thought of the idea, SaltStack and Rails both preprocess their yaml files with Jinja and erb respectively. To achieve something like @thestonefox wants, you could just use envdir and do |
+1 for this. |
+1 as well |
@Jud : Jinja could be great, but i think it's a huge dependency to add. I see basic cases, like default values, where logic in the yaml file could be seen as useful: example:
But this kind of cases should be handle at the application configuration level instead. example:
Right now I don't see any case where Jinja could be really useful. Do you? |
@SkinyMonkey could you explain a little about how you've got skydock working with fig? There are a lot of things in the skydock install that I wasn't sure how to use with fig, like udp ports and providing the docker0 interface IP. |
(slight tangent alert) I just found out about Skydock last night, and although it doesn't solve the ENV VAR expansion issue (this issue), it does seem to offer a solution to a lot of the issues to the resolution of dynamic IPs. I'd recommend anyone who hasn't played around with it to take a look. |
@hunterloftis : http://pastebin.com/89PeJ1sC Sorry for polluting this thread, but might be useful to other people. |
+1 for Jinja. Check out envtpl too. https://github.com/andreasjansson/envtpl |
looking so forward to this |
+1 |
2 similar comments
+1 |
+1 |
+1 |
Maybe Jinja2 could be a some kind of an optional dependency? So when fig is starting up it looks for a file like |
Because fig uses yaml.load, you can already pass environment variables from the machine where you're running 'fig' to the containers. If you're on a Mac and you wanted your containers to know the IP address of the boot2docker VM, for instance: environment:
SOME_VALUE: 123
DOCKER_HOST: !!python/object/apply:os.getenv ["DOCKER_HOST"] This feels like a hack, and it feels a bit wrong that fig doesn't use |
@mozz100 that's interesting, though yeah, I don't think it's a good idea to have end-users doing that. In particular, fig may not always be written in Python (there's a current effort underway by a few devs to do it in Go). |
Any news on such a feature? #297 isn't sufficient for me, because I want to supply from host things like volumes, not just environment variables. Any templating of volumes:
- ${something}:/app and being able to supply |
If we don't want loading jinja2, what about just using string.Template with a whitelist of keys – not ultimately substitute it from env vars, but provide a list of substitutions on run: volumes:
- ${something}:/app $ fig run --template something:/var/www/cache |
Volumes already support environment variables in this form, at least for the host portion: https://github.com/docker/fig/blob/master/fig/service.py#L490 I'm not a big fan of "just pass everything to a substitution (I think it's error prone). A lot of fields support environment variables now, it shouldn't be difficult to add more support. |
For your example:
|
Wow. They do. Thank you. |
I also ran into a situation where I would like to use this. I would like to tag each container built on our CI server with a build number. having a function like this would allow for us to deploy not only the latest, but also roll back to a previous successful build just buy putting the build number in. |
@funkymonkeymonk I think you can already do this using
#457 is also related to this idea |
@dnephin Thanks for the response. If I'm not mistaken wouldn't that name the container with the build number not tag it? That would create a large number of repos quickly when I push. Also when I go to deploy the stack I'd like to deploy the stack passing in the build number as an argument. Something to the effect of
This would give us the ability to roll back to a previous build easier. |
Yes, it would be part of the name. What you're looking for sounds a lot like #457 |
I would like to use environment vars in the |
+1 Trying to solve service lookups via dns and would love to beeing able to use the very same fig.yml for development and production. To solve this I would need something like |
I would like to use variables in ports: I have a usecase where several services share the same public default port on the docker host. |
+1 |
+1 |
Any news here ? |
+1 |
2 similar comments
+1 |
+1 |
+1 Would like to use this to pass in AWS credentials into containers |
#1488 will be in the next release, which will let you do something like this if you wanted to: cat docker-compose.yml | python -c "import os, sys; os.path.expandvars(sys.stdin.read())" | docker-compose up -f - Which can be aliased as I think it's still work calling out that this can easily break the yaml syntax, so should be used with caution. |
This is a non-solution, @dnephin. Heck, it might even be an unsolution. When invoking Wrapping an invocation of a tool with something like the above basically means the tool in question sucks majorly. |
I agree that the need to interpolate IP addresses in a Compose file is a legal request that is insufficiently addressed by this solution. The suggested solution is only a minor improvement to command substitution which was possible before:
|
I totally agree with @griwes, this looks like an unsolution. |
This is done in #1765 |
This feature allow you to use environment variables in the fig.yml file.
It simply expand any found environment variable (ex: $HOST) to the value defined in the environment running fig.
useful example :
I'm using Skydock (https://github.com/crosbymichael/skydock) along with skydns.
When i launch a skydns container by hand I need to specify the ip of the docker0 interface so that docker inject a new nameserver into /etc/resolv.conf:
ex:
Here the ip is "172.17.42.1"
docker run -d -dns 172.17.42.1 -p 172.17.42.1:53:53/udp -name skydns crosbymichael/skydns -nameserver 8.8.8.8:53 -domain docker
A nice way to be more flexible, compute what is the address automatically for example, is to add an environment variable in the equation :
env DNS_IP=172.17.42.1 docker run -d -dns $DNS_IP -p $DNS_IP:53:53/udp -name skydns crosbymichael/skydns -nameserver 8.8.8.8:53 -domain docker
Wouldn't it be nice to be able to do the same thing in a fig.yml file?
ex:
env DNS_IP=172.17.42.1 fig up
with this fig.yml:
I wanted to add a flag to make this expansion optional, just in case. What do you think?