This includes most things except the containerd and runc builds
which I will do next time I update them.
Note that all golang:alpine images now for 1.8 are ALpine 3.5 based.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Now there is an Alpine 3.5 variant of the Go 1.7 images, use this.
fix#972
Note updated the containers/binfmt image as this will be converted
to go-compile shortly, at which point alpine-build-go can be removed.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Go code is really fast to compile so we do not really need to use the
cache features of `docker build`. So make a compile container instead.
This can also output a build context and Dockerfile if you want to do
a build.
For reference, an uncached `docker build` of our Go code takes about
7s, a cached one 1.2s, and this takes 1.7s, so the best case is a little
worse, but we save a lot of images, and the worst case is better.
This is mainly designed to make the nested builds for containerd
containers simpler too. Will add a variant for the C code as well.
Also add `-static` to the flags so we always make static executables,
which was omitted previously.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This means that multiple builds will not conflict, so we can
remove the lock from the CI. Also quieter when no errors.
Some still left to do, only done the ones used in build and CI
initially. Some of the others will be cleaned up anyway later.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Model for the others, make sure dependencies are correct and that
only the exactly correct things are passed to Docker. No longer copy
vendor directory.
Signed-off-by: Justin Cormack <justin@specialbusservice.com>
The purpose of the `slirp-proxy` is to expose ports on the Mac or
Windows host. In d5bd7d690a we added
an additional `Listen` inside the VM for backwards compatibility
with software that expected to be able to listen on `0.0.0.0` in
one container and then access this easily from other containers
using an IP bound to the VM (instead of using a first-class network
to connect the containers or discovering a real IP of the host).
Before this patch we could only expose ports on if the Listen
succeeds on both the host and the VM. In practice this meant that
we could only expose ports on `0.0.0.0` and `127.0.0.1`; attempts
to expose ports on specific interfaces on the host would fail.
This patch treats the EADDRNOTAVAIL error from the Listen inside
the VM as a soft failure, and still attempts to Listen on the host.
If the Listen on the host fails it is still a hard failure.
This allows ports to be exposed on specific IPs used on the host.
Fixes [docker/pinata#5080]
Signed-off-by: David Scott <dave.scott@docker.com>
docker itself seems to bind to the port globally inside Moby, so we
get an EADDRINUSE if we try to do it too.
Signed-off-by: David Scott <dave.scott@docker.com>
This allows the proxy to be run easily from a terminal or other script
without requiring fd 3 to be open and writable.
Signed-off-by: David Scott <dave.scott@docker.com>
Linux xargs calls the command with no arguments if it gets no inputs, which
`docker rmi` complains about. It provides -r / --no-run-if-empty to prevent
this but unfortunately this isn't supported on OSX.
Ignore errors from `docker rmi` so that `make clean` will keep going and clean
up later stuff.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
On both Mac and Windows we have one well-known port and a SOCKS-like
port to tunnel connections through it. This was necessary on Windows
where ports have well-known GUIDs, but we might as well do it the same
way on both platforms for consistency.
This patch removes the dynamic binding of vsock ports, which fails on
a Windows Moby anyway.
Signed-off-by: David Scott <dave.scott@docker.com>
We now tell the 9P server
proto1:ip1:port1:<address for forwarding>
which means please listen on proto1:ip1:port1, then connect to the port
proxy in Moby and tell it the connection is for <address for forwarding>.
Note this requires a corresponding change in hostnet/vpnkit.
Signed-off-by: David Scott <dave.scott@docker.com>
On a Hyper-V system we can only register one listening endpoint (with
a GUID), so we need to accept connections, read a header and then
start the proxy.
If the binary has argv[0] == "proxy-vsockd" then run this new frontend.
Signed-off-by: David Scott <dave.scott@docker.com>
Previously the proxy would listen only on the vsock port, which is
fine for accessing the port on the host, but if a container also wants
to access the port (e.g. via `--net=host` and using the Moby IP) then
we need to listen on the IP too.
Related to [docker/pinata#2854]
Signed-off-by: David Scott <dave.scott@docker.com>
