Closed hwestman closed 5 years ago
@hwestman, thanks for reporting this case. The MTU setting hardly depends on host machine network settings, so it looks not so good to hard code any values in docker images for all users.
Related blog: http://atodorov.org/blog/2017/12/08/how-to-configure-mtu-for-the-docker-network/
Thank you for responding. Not sure I understood what you mean when you say "The MTU setting hardly depends on host machine network settings", are you saying that it in fact does depend on the host machine network setting?
If so I would absolutely agree that it does not make sense to configure this in the agent image.
What made this issue hard to figure out, was that the teamcity-docker-agent would perform an http request just fine, but launching a container within the teamcity-docker-agent and running an http request would fail. This led me to think that there would be a problem with the image, and not an issue with the host or its network.
Guess the configuration I have is the proper way to handle this then :)
Would it be an idea to code the original image as such as you could specify the mtu (and other DOCKER_OPTS?) through an environment variable?
Im having an issue building within containers on the agent. First symptoms was that restoring nuget packages in a
dotnet restore
would time out for each individual package.I tested this ok directly on the docker agent, but it would consistently fail restoring in the container running on the agent.
Playing around with curl in the container running on the agent i got inconsistent results, it returned the header and partial html, eventually timing out.
After a suggestion from a co-worker we attempted to reduce MTU to 1380 (magic number he suggested) for the
docker_ops
on the teamcity agent, and it seems to have solved the problem.Now i mount a /etc/docker/daemon.json in order to set mtu. Looks like this:
{ "mtu":1380 }
Is this something that could be adjusted in the official image? (I do wonder why i'm the only one that seems to have this issue)