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

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

[Daniel Sangorrin]

This was required for example to communicate with a squad
server running on localhost

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@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

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

[Tim.Bird]

> -----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@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?  Is this a permanent feature of the created container, or
something that can change at runtime?

Does this affect access to Debian repositories during the container build?

I'd like to understand this a bit better before applying it.

Thanks,
 -- Tim

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

[daniel.sangorrin]

> -----Original Message-----
> From: Tim.Bird@sony.com <Tim.Bird@sony.com>
> Sent: Friday, January 11, 2019 9:39 AM
> To: sangorrin daniel(サンゴリン ダニエル ○ＳＷＣ□ＯＳＴ) <daniel.sangorrin@toshiba.co.jp>;
> fuego@lists.linuxfoundation.org
> Subject: RE: [Fuego] [PATCH 1/2] docker: add no_proxy variable
> 
> > -----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@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.

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

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

Thanks,
Daniel

> 
> Thanks,
>  -- Tim

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

[Tim.Bird]

> -----Original Message-----
> From: daniel.sangorrin@toshiba.co.jp
> 
> > -----Original Message-----
> > From: Tim.Bird@sony.com <Tim.Bird@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@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