Polyconseil/grocker

I need to pass extra env variables when building.

Opened this issue · 9 comments

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.

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/

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).

such synchro, much wow

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.

@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.

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

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

@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" ?

Can be done by now: