The environment I use is openstack vm, The network card mtu is 1454 ,not 1500
When I build with drone, I find that it creates a new container and the mtu of the network card
is 1500 . so the container was not able to access the Internet
by the way ,during the use, I discovered that the drone created a bridge network using docker and the mtu is 1500, I need to set the mtu of this network for 1400 to get online
Actually it’s not exactly Drone issues, but Docker (not possible to set default MTU for all new networks). Even if you will change MTU settings in daemon.json it will be applied only to default bridge. Settings inside docker-compose.yml will be applied only to networks that was created for drone-server/agent. But Drone will create additional network and that network will have default MTU 1500. So in result I end up with modifying Drone source code to be able to pass network options to this Drone-created network.
And I want to ask you @bradrydzewski do you interested in such Pull Request to 2 repos: drone/drone and cncd/pipeline to add ability to pass options for Drone created networks?
I am having the same issue. I am running Drone 0.8.2 inside the OpenStack VM which runs the Kubernetes with Weave Net CNI (Container Network Interface) which is running with the MTU of 1360 bytes.
At first, I thought that having the --mtu set to 1360 bytes for the drone-dind (docker:17.12.0-ce-dind) would have solved the issue, only if it was keeping that --mtu=1360 as the default for the newly created docker network bridges. Unfortunately, this is not the case .
I believe this should not be very hard to extend the Drone and let the users set their options such as the MTU value for the Docker network .
At the moment, my quick and dirty workaround is to leverage the “clamp the MSS” (Linux kernel feature in the network stack that calculates the proper MSS for the link) .
This is the piece of my configuration for the Kubernetes deployment:
I am using the DOCKER-USER iptables chain as the Docker is trying to place it as the first rule under the FORWARD chain.
Please also note that I am using --host=tcp://127.0.0.1:2375 instead of --host=tcp://0.0.0.0:2375 dockerd argument as the latter one allows an unprivileged container (ran in Drone) to escape to the drone-dind.
The network_mode property works only when you set the Trusted repo option which can only be done by Drone admin. Since the trusted repo also allows running containers in a privileged mode, this might not be a solution to many people, including me.
This patch should work based on the docker documentation, but I do not have an environment that I can use to test this. If you experience any issues we would kindly ask that you send a pull request that improves this code.