integration: Add tests for port mappings#48545
Merged
thaJeztah merged 3 commits intomoby:masterfrom Oct 7, 2024
Merged
Conversation
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
robmry
reviewed
Sep 24, 2024
| serverID := container.Run(ctx, t, c, | ||
| container.WithName(sanitizeCtrName(t.Name()+"-server")), | ||
| container.WithExposedPorts("80/tcp"), | ||
| container.WithPortMap(nat.PortMap{"80/tcp": {{HostPort: serverPort}}}), |
Contributor
There was a problem hiding this comment.
As the mapping doesn't include a HostIP, the mapping should work via any host address (apart from --userland-proxy=false --ipv6=false, which will be IPv4 only).
If that's the intention, perhaps it'd be worth checking access via each of the host addresses in each test... dropping the last component of the test-config so that, for each combo of userland-proxy and IPv6-enabled, there's an http request to each of eth0 and lo's v4 and v6 addresses.
But it might also be worth testing that, with a host address in the port mapping, it's not possible to access the http server via other host addresses?
2bb254f to
dfafb97
Compare
d1b45d4 to
09df741
Compare
f885f18 to
d3e2a59
Compare
robmry
approved these changes
Sep 30, 2024
This was referenced Oct 2, 2024
thaJeztah
reviewed
Oct 3, 2024
neersighted
approved these changes
Oct 4, 2024
Member
neersighted
left a comment
There was a problem hiding this comment.
LGTM overall with the exception of @thaJeztah's concern about sysctls, which he beat me to.
d3e2a59 to
ef52cdd
Compare
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Along with this new test, a new struct `L3Segment` is introduced to simulate hosts connected on a same switched network. This struct will let us test various scenarios where published ports and containers should or should not be accessible from remote hosts. The new test introduced, `TestAccessPublishedPortFromRemoteHost`, skips link-local address as port publishing doesn't work on those addresses currently. This will be fixed in a future commit. Signed-off-by: Albin Kerouanton <albinker@gmail.com>
ef52cdd to
5875b6e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
- What I did
Introduce new integration tests that ensure port mappings are correctly accessible from the host, and from a remote host. This is another attempt at upstreaming some of the tests introduced in:
These tests should help ensure nothing breaks when we'll modify iptables rules, or when we'll add nftables support.
- How I did it
I added a new
L3Segmentstruct that simulates (using netns) a LAN segment where arbitraryHosts live. That's what makesTestAccessPublishedPortFromRemoteHostpossible.That specific test simulates two hosts: one is the 'current' netns where the daemon-under-test and the tests themselves are executed. The other is the 'remote host'. Each host gets a pair of veth. A third network namespace is used to isolate the bridge from any network programming the engine does.
To create all these objects (netns, veth, etc...), simple iproute2 invocations are made. The previous attempt was using netlink calls, which was an horrendously bad idea since there was no way to recreate the same env for manual debugging. All iproute2 invocations are logged, so now it's just a matter of copy / pasting logs into a shell script, tidying them up a bit, and then running the script.
The
L3Segmentstruct has one important method:AddHost.And
Hosthas two important methods:Run, which runs a command in the host's netns. That command is logged too.Do, which runs a callback in the host's netns.Both
Hosts andL3Segmentcan take any number of IP addrs, making it easy to test v4/v6-only, as well as, dual-stack scenarios in one go.This should be enough to cover all use-cases.
- How to verify it
CI is green.