feat: support container network mode #1429
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #1429 +/- ##
==========================================
+ Coverage 67.47% 67.69% +0.21%
==========================================
Files 26 26
Lines 2346 2377 +31
==========================================
+ Hits 1583 1609 +26
- Misses 666 670 +4
- Partials 97 98 +1
☔ View full report in Codecov by Sentry. |
|
I think I have found a better way to solve this. Will update PR later on. |
schizo99
force-pushed
the
networkmode-service
branch
from
0236f91
to
85f84f3
Compare
|
Maybe did a mistake by force pushing? In any case I think this new approach is nicer and does not require any additional labels. |
There was a problem hiding this comment.
This seems like it should work. The only thing I am not thrilled about is that the API for getting the container info also alters the returned info. The way it's used right now, this shouldn't be an issue, but it's hidden/unexpected, which could lead to bugs further on.
Of course, the "right" way would be to do this when preparing the new configuration before starting the container. Except that at that time, the old container should already have been removed.
|
You're right. I'm not 100% sold on this but it's the most efficient way. The other option would be my first approach which would require an additional label to be added besides the depends_on label. |
|
Was intending to add tests. However, as soon as I update the Go test thrown errorsAnd I don't have the slightest as to why this is not working even if the container is pointing to itself. |
|
Any updates on this PR? Updating containers with service network mode is painful right now. Looking forward to seeing this get merged. |
|
@s-wasser it still needs tests, and I don't have enough knowledge of how docker network configuration changes the container info to fix it easily. I can take a look next time I get some free time though... |
|
Any updates on this getting merged? |
|
@shivindera still needs tests. I have no idea if this actually works or not. The tests need to be there for us to be able to maintain this project. They tell us what some code is expected to do and how we can incorporate other changes without breaking this one's. I don't personally use this functionality myself, so it both requires extra time on reading up on and understanding the use cases, but it also means it would be guesses from my part in the end. |
|
@schizo99 any chance of getting this PR tested and merged? it seems you guys were really close last year, what is missing here to fix the issue? |
|
@heisenberg2980 What's missing are tests for the new code. But I'm getting errors when implementing the tests. |
|
@schizo99 if you can push the tests with the errors, I can probably fix them! Also, I got a VPN subscription and created some integration test cases that use gluetun as the container network. It still needs credentials of course, but if you have a service provider you should be able to test watchtower with it. I can add it to the tools in this PR. |
|
@piksel I never got so far as to create any test cases for these changes since it started failing as soon as I modified the So all you need to do for the tests to start failing is to update the file and set NetworkMode as this Might very well be me not understanding the mock framework. |
…rvice:container is set
Co-authored-by: nils måsén <nils@piksel.se>
Co-authored-by: nils måsén <nils@piksel.se>
piksel
force-pushed
the
networkmode-service
branch
from
440bb04
to
abbdaa8
Compare
|
To make the tests easier to write, I did some refactoring on the docker API server mock. |
|
Thank you very much @piksel, we are really close to have this PR merged and the issue fixed |
|
@piksel will you be able to add the additional test to get this PR merged? |
|
@piksel do you know when a new version of watchtower containing this change will be released so we can test it? |
Use |
This PR solves the issue when using
network_mode: service:xxxxxin a service.It closes #1286
For this to work not only does the labelcom.centurylinklabs.watchtower.depends-onbe set to the parent container. It also require a new labelcom.centurylinklabs.watchtower.network-serviceto be set.It solves the issue by updating the HostConfig with the ID of the new parent container.
Update: Since
NetworkMode: "container:*"would mean that the container would not work without being re-created if the network supplying container was updated, this should no longer be necessary. Instead it is now treated as an implicit link.