[Fuego] [PATCH 1/2] docker: add no_proxy variable

Tim.Bird at sony.com Tim.Bird at sony.com
Fri Jan 11 01:09:27 UTC 2019



> -----Original Message-----
> From: daniel.sangorrin at toshiba.co.jp
> 
> > -----Original Message-----
> > From: Tim.Bird at sony.com <Tim.Bird at sony.com>
> >
> > > -----Original Message-----
> > > From: Daniel Sangorrin
> > >
> > > This was required for example to communicate with a squad
> > > server running on localhost
> > >
> > > Signed-off-by: Daniel Sangorrin <daniel.sangorrin at toshiba.co.jp>
> > > ---
> > >  fuego-host-scripts/docker-create-container.sh | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/fuego-host-scripts/docker-create-container.sh b/fuego-host-
> > > scripts/docker-create-container.sh
> > > index 59cce3d..c9e4444 100755
> > > --- a/fuego-host-scripts/docker-create-container.sh
> > > +++ b/fuego-host-scripts/docker-create-container.sh
> > > @@ -23,5 +23,6 @@ sudo docker create -it --name
> ${DOCKERCONTAINER} \
> > >      -v $DIR/../fuego-rw:/fuego-rw \
> > >      -v $DIR/../fuego-ro:/fuego-ro:ro \
> > >      -v $DIR/../../fuego-core:/fuego-core:ro \
> > > +    --env no_proxy="$no_proxy" \
> > >      --net="host" ${DOCKERIMAGE} || \
> > >      echo "Could not create fuego-container. See error messages."
> > > --
> > > 2.7.4
> >
> > I'm not as conversant with docker as I should be.  I'm not sure what
> > effect this will have.
> >
> > Does this mean that  the container will never be able to communicate
> > via a proxy?
> 
> No. The no_proxy environment variable is just a list of IP addresses and URL
> patterns that tell the system not to go through the proxy when accessing
> them. For example, you don't need to go through the proxy to connect to
> local machines or a service running on your host PC. If you are not using it
> already, it shouldn't have any effect on you. It's only for users that work
> behind web proxies.

OK - sounds safe to use.  I'll apply it.

> 
> >Is this a permanent feature of the created container, or
> > something that can change at runtime?
> 
> They are permanent to the container because we are using "docker create"
> instead of "docker run". In other words, currently we build an image, then
> we create a container and finally we start the container. A more flexible way
> consists of building the image, and then using "docker run" to create a
> temporary container with whatever environment variables or volumen
> mounts we need.

Hmmm.  One issue is that we have all our jobs and jenkins build data are
defined inside the jenkins directories inside the container.  That means
they are not persistent when moving from one container to another.
When ProFusion was working on the release test,
they restructured the directories to also put /home/jenkins from the container
(and maybe /var/lib/jenkins - I don't remember) into volume mounts as well,
so that they were visible in the host filesystem (along with fuego-ro and fuego-rw).

When you re-initialize Jenkins it can read this data, put up all the same information
it had from the last container.  I've been thinking of re-adding that system,
but it means moving some directories around, which is dicey for backwards compability.
It also makes it so that you can do file operations on the Jenkins jobs from the
host, even if the container is not running.  (this could be useful for cleanup, or
repair, or diagnostics of Jenkins/Fuego problems)

Do you have an opinion on this?

> 
> > Does this affect access to Debian repositories during the container build?
> No, these are runtime variables only.
> 
> > I'd like to understand this a bit better before applying it.
> 
> Sorry for the lack of explanation.
No problem.

Thanks for the patch.
 -- Tim



More information about the Fuego mailing list