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

I need to pass extra env variables when building. #8

Open
eviln1 opened this issue Apr 29, 2015 · 9 comments
Open

I need to pass extra env variables when building. #8

eviln1 opened this issue Apr 29, 2015 · 9 comments

Comments

@eviln1
Copy link
Contributor

eviln1 commented Apr 29, 2015

Hi,
It turns out that when I run builder.py in production environment, I need to pass some extra env variables to the compiler container in the compile_packages phase, including (but not limited to) http_proxy , https_proxy, no_proxy.
It would be helpful to be able to do so easily.

Update : actually, those extra env vars are also needed in 'docker build' calls.

@eviln1 eviln1 changed the title In need to pass extra env variables when building. I need to pass extra env variables when building. Apr 29, 2015
@vperron
Copy link
Contributor

vperron commented Apr 30, 2015

no_proxy is deduced from the case when you don't have either one of the others, right ? :)

a not-so-bad approach (cc @fbochu ?) would be using an environment file and pass it to builder.py somehow:

./builder.py --env-file=environment

and the builder copies it to the machine if needed in the builder calls, or passes it to running compiler machine with the "docker run --env-file" native param.

cf https://docs.docker.com/reference/commandline/cli/

@fbochu
Copy link
Contributor

fbochu commented Apr 30, 2015

An other answer to this problem can be that the devs build the image and provide its hash. Then when you pull the image from your registry, you check the hash (this will serve as guarantee for non-alteration of the image).

@vperron
Copy link
Contributor

vperron commented Apr 30, 2015

such synchro, much wow

@eviln1
Copy link
Contributor Author

eviln1 commented Apr 30, 2015

Amen.
This would be the ideal solution; the building process is not that straightforward (yet) on our end and it kind of defeats the purpose of using Docker.
However, this idea was declined during our last meeting because of some security concerns; I believe that we should take a better look at this.

@rbarrois
Copy link

@vperron no_proxy lists the domains for which we mustn't use the proxy.
@fbochu Since the nginx/uwsgi configuration is embedded in the docker, the ops team needs to be able to deploy a hotfix without the dev team.

@fbochu
Copy link
Contributor

fbochu commented Apr 30, 2015

@rbarrois : They can do a hotfix by adding a new commit to the existing image.

@rbarrois
Copy link

@fbochu yes, but then they need to build and deploy the image - without dev being around.

@barryib
Copy link
Contributor

barryib commented Apr 30, 2015

@fbochu Agreed. I think that the build process should be done once.

Registry v2 now create a SHA256 digest for images it stores. And since docker 1.6 we can pull images with a particular digest. https://docs.docker.com/reference/commandline/cli/#listing-image-digests
This wouldn't solve our principal problem "this idea was declined during our last meeting because of some security concerns" ?

@fbochu
Copy link
Contributor

fbochu commented Jan 27, 2016

Can be done by now:

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

No branches or pull requests

5 participants