Make port-forwarding work on Podman with apps listening on the loopback interface, via a new --forward-localhost flag
#6629
Conversation
This file contains 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
This avoids repeating the same methods in both interfaces, and makes the intent clearer.
This is recommended in the Coding Conventions guidelines [1]. Specifically, what's important here is checking that it meets the 'platform.Client' contract. [1] https://github.com/redhat-developer/odo/wiki/Dev:-Coding-Conventions#verify-interface-compliance
…ckage This paves the way to providing a different implementation for Podman
Current implementation relies on the Devfile object, so it makes more sense to be in the libdevfile package.
…mmand process This allows callers to get more meaningful events about the process.
As explained in [1], this makes use of a helper sidecar container (aptly named "odo-helper-port-forwarding") to be added to the Pod Spec created by odo. In this scope, port-forwarding will be equivalent of executing a socat command in this helper container, like so: socat -d tcp-listen:20002,reuseaddr,fork tcp:localhost:5858 In the command above, this will open up port 20001 on the helper container, and forwarding requests to localhost:5858 (which would be in the application container, part of the same Pod) [1] redhat-developer#6510
Specifically, the 'StartPortForwarding' method can now accept an explicit list of ports that needs to be forwarded, if the caller can compute provide such information. This is currently useful on Podman where the ports (even the random ones) are known in advance.
As explained in [1], this helper sidecar container (aptly named "odo-helper-port-forwarding")
will hold the actual container/host ports mapping in the spec
(to overcome the limitation of using hostPort against a container app listening on the loopback interface);
this running container will be used to execute the actual port-forwarding commands (based on socat), e.g:
```
apiVersion: v1
kind: Pod
metadata:
name: my-component-app
labels:
app: my-component-app
spec:
containers:
- name: runtime
command: [ 'tail', '-f', '/dev/null']
# Omitted for brevity, but imagine an application being executed by odo
# and listening on both 0.0.0.0:3000 and 127.0.0.1:5858
- name: odo-helper-port-forwarding
image: quay.io/devfile/base-developer-image:ubi8-latest
command: [ 'tail', '-f', '/dev/null']
ports:
- containerPort: 20001
# A command will be executed by odo, e.g.: 'socat -d -d tcp-listen:20001,reuseaddr,fork tcp:localhost:3000'
hostPort: 20001
- containerPort: 20002
# A command will be executed by odo, e.g.: 'socat -d -d tcp-listen:20002,reuseaddr,fork tcp:localhost:5858'
hostPort: 20002
# ... Omitted for brevity
```
In this scope, port-forwarding from 20002 to 5858 for example will be equivalent of executing
a socat command in this helper container, like so:
socat -d tcp-listen:20002,reuseaddr,fork tcp:localhost:5858
In the command above, this will open up port 20001 on the helper container,
and forwarding requests to localhost:5858
(which would be in the 'runtime' container, part of the same Pod)
[1] redhat-developer#6510
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
✅ Deploy Preview for odo-docusaurus-preview ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
3 tasks
rm3l
force-pushed
the
6510-ability-to-forward-localhost-on-podman-via-a-side-container
branch
from
144797b to
ef3238a
Compare
rm3l
changed the title
--forward-localhost on Podman--forward-localhost flag
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
rm3l
added
kind/feature
feloy
reviewed
Mar 3, 2023
|
|
||
| // GetAllResourcesFromSelector returns all resources of any kind (including CRs) matching the given label selector | ||
| GetAllResourcesFromSelector(selector string, ns string) ([]unstructured.Unstructured, error) | ||
| platform.Client |
|
Kudos, SonarCloud Quality Gate passed!
|
feloy
approved these changes
Mar 6, 2023
openshift-ci
bot
added
the
lgtm
rm3l
deleted the
6510-ability-to-forward-localhost-on-podman-via-a-side-container
branch
anandrkskd
pushed a commit
to anandrkskd/odo
that referenced
this pull request
Mar 7, 2023
…ck interface, via a new `--forward-localhost` flag (redhat-developer#6629) * Embed platform.Client interface in platform-specific interfaces This avoids repeating the same methods in both interfaces, and makes the intent clearer. * Verify interface compliance of PodmanCli at compile time This is recommended in the Coding Conventions guidelines [1]. Specifically, what's important here is checking that it meets the 'platform.Client' contract. [1] https://github.com/redhat-developer/odo/wiki/Dev:-Coding-Conventions#verify-interface-compliance * Move K8s-specific implementation of port-forwarding to a dedicated package This paves the way to providing a different implementation for Podman * Remove GetPortsToForward method from the portForward.Client interface Current implementation relies on the Devfile object, so it makes more sense to be in the libdevfile package. * Monitor and send appropriate status events after starting a remote command process This allows callers to get more meaningful events about the process. * Implement port-forwarding logic on Podman As explained in [1], this makes use of a helper sidecar container (aptly named "odo-helper-port-forwarding") to be added to the Pod Spec created by odo. In this scope, port-forwarding will be equivalent of executing a socat command in this helper container, like so: socat -d tcp-listen:20002,reuseaddr,fork tcp:localhost:5858 In the command above, this will open up port 20001 on the helper container, and forwarding requests to localhost:5858 (which would be in the application container, part of the same Pod) [1] redhat-developer#6510 * Update portForward.Client interface methods Specifically, the 'StartPortForwarding' method can now accept an explicit list of ports that needs to be forwarded, if the caller can compute provide such information. This is currently useful on Podman where the ports (even the random ones) are known in advance. * Add helper sidecar container to the Pod Spec generated on Podman As explained in [1], this helper sidecar container (aptly named "odo-helper-port-forwarding") will hold the actual container/host ports mapping in the spec (to overcome the limitation of using hostPort against a container app listening on the loopback interface); this running container will be used to execute the actual port-forwarding commands (based on socat), e.g: ``` apiVersion: v1 kind: Pod metadata: name: my-component-app labels: app: my-component-app spec: containers: - name: runtime command: [ 'tail', '-f', '/dev/null'] # Omitted for brevity, but imagine an application being executed by odo # and listening on both 0.0.0.0:3000 and 127.0.0.1:5858 - name: odo-helper-port-forwarding image: quay.io/devfile/base-developer-image:ubi8-latest command: [ 'tail', '-f', '/dev/null'] ports: - containerPort: 20001 # A command will be executed by odo, e.g.: 'socat -d -d tcp-listen:20001,reuseaddr,fork tcp:localhost:3000' hostPort: 20001 - containerPort: 20002 # A command will be executed by odo, e.g.: 'socat -d -d tcp-listen:20002,reuseaddr,fork tcp:localhost:5858' hostPort: 20002 # ... Omitted for brevity ``` In this scope, port-forwarding from 20002 to 5858 for example will be equivalent of executing a socat command in this helper container, like so: socat -d tcp-listen:20002,reuseaddr,fork tcp:localhost:5858 In the command above, this will open up port 20001 on the helper container, and forwarding requests to localhost:5858 (which would be in the 'runtime' container, part of the same Pod) [1] redhat-developer#6510 * Inject the right portForward client depending on the platform * Delegate port-forwarding on Podman to the appropriate client * Implement --forward-localhost on Podman * Add unit and integration test cases * Cover more debug-related test cases on Podman * Expose the endpoint protocol so as to instruct socat to listen and forward the right protocol * Fix sub-deps of EXEC and PORT_FORWARD, as suggested in review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 type of PR is this:
/kind feature
/area odo-on-podman
/area dev
What does this PR do / why we need it:
This is the second and last PR (building on #6620) to address #6510.
For some context, the way
odocurrently does port-forwarding on Podman is via aHostPortin the relevant container in the pod spec. But as reported in #6510 and containers/podman#17353, Podman won't forward traffic to the container if the container port is bound to the container loopback interface.As discussed in #6510 (comment) (and similar to how things work on DevSpaces), #6620 tried to detect if ports that need to be forwarded are bound to the container loopback interface. If this is the case:
odo devon Podman will error out with an error message indicating the issue, along with a recommendation to either change the application to listen on 0.0.0.0, or to runodo devwith--forward-localhost.odo devis run with--ignore-localhost, this message will be displayed as a warning, but this won't preventodo devfrom running. However, any request sent out to the local port forwarded to the container on its loopback interface might not work with Podman.This PR is about supporting a new
--forward-localhostflag, to make port-forwarding work on Podman with applications bound to the loopback interface. It does so by injecting a dedicated side container (running thequay.io/devfile/base-developer-imageimage). Port-forwarding is then done by running asocatcommand in this container. It will listen on one port on all interfaces, and on the other hand forward traffic to the second port (which might be bound to the loopback interface).The main interest of having this flag on Podman is to have on Podman the same behaviour as
kubectl port-forwardon Kubernetes, which is able to port-forward a container port bound on localhost. This is primarily useful for working with the debugger on localhost, without exposing it on all interfaces, for security reasons.Which issue(s) this PR fixes:
Fixes #6510
PR acceptance criteria:
Unit test
Integration test
Documentation
How to test changes / Special notes to the reviewer:
This behavior should not affect the default cluster mode.
To test the changes on Podman, either use a project with an application listening on some port on localhost, or leverage some existing stacks like Node.JS which have debuggers listening on localhost.
Without
--forward-localhost, the behavior depends on the value of--ignore-localhost. See On Podman, detect if application is listening on the loopback interface, and either error out or not depending on--ignore-localhost#6620 (comment).With
--forward-localhost,odo devon Podman should start and requests sent to the debug port should work as expected:NOTE: a sidecar is added as long as
--forward-localhostis passed, even if the application is not listening on the loopback interface. But this does not prevent port-forwarding from working correctly. In the example above, if I runODO_EXPERIMENTAL_MODE=t odo dev --platform=podman --forward-localhost(without--debug),odo devshould start and work normally.