Difficulty: Beginner
Estimated Time: 20 minutes

In this scenario, you're configuring Docker and XtestingCI to pass enterprise proxies. It fully covers the 3 main container operations: build, pull and run.

Squid, the well-known opensource caching proxy, is selected for the needs of this scenario.

XtestingCI well supports proxies for all its features. Be free to apply the guidelines for any Docker environment or any ansible playbook.

Stay tune!

All about proxies

Step 1 of 7

Docker behind enterprise proxy

The enterprise proxies usually fail many users and Docker is particulary misleading in this case due to its design and due to the different container operations.

At first, the Docker client sends all operations to the Docker daemon generally via the Docker Unix socket. Then you cannot leverage the classical and simple environment variable configuration (e.g. http_proxy, https_proxy, etc.) where you call the Docker client to pull a new Docker image. The proxy configuration must be rather applied to the Docker daemon as described in Control Docker with systemd.

Then you must set the proxy configuration when building your containers to download all the packages required. As this operations are done from a new container, you must also set the proxy configuration as build-time variables whatever it's applied or not in your environment (e.g. ~/.bashrc, /etc/profile, etc.). It should be noted that configuring proxies in systemd only helps when downloading the parent image (i.e. FROM).

Finally, you may have to set the proxy configuration when running the container if your software reaches internet. Here you may care not to hardcode the proxy configuration in your container image as it would forbid everybody to execute it from everywhere (Editor's Note: I saw this strong mistake in a big opensource project). You can simply set the environment variables manually when booting your container.

This scenario describes all this cases in the view of XtestingCI.

Terminal Host 2