On Podman, unable to access local ports forwarded to container applications listening on the loopback interface (e.g. debug endpoints) #6510
Assignees
Labels
area/dev
Issues or PRs related to `odo dev`
area/odo-on-podman
Issues or PRs related to running odo against Podman
kind/bug
Categorizes issue or PR as related to a bug.
priority/High
Important issue; should be worked on before any other issues (except priority/Critical issue(s)).
Milestone
Comments
|
🤔 Same behavior with the |
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Jan 19, 2023
…ed debug port until [1] is fixed We can work on fixing the issue on Podman in a separate PR. [1] redhat-developer#6510
3 tasks
openshift-merge-robot
pushed a commit
that referenced
this issue
Jan 19, 2023
…g` (#6505) * Add integration tests meeting the expectations * Refactor 'libdevfile.GetContainerEndpointMapping' such that it returns debug endpoints only if told so * [Kubernetes] Port-forward Debug endpoints only if running in Debug mode * [Podman] Port-forward Debug endpoints only if running in Debug mode * Use '--inspect' instead of '--inspect-brk' to run the "debug" script in Node.JS sample projects '--inspect-brk' stops the execution at the start of the command (waiting for a debugger to attach to it) while '--inspect' does not. We need the application to be started regardless of whether a debugger is attached or not, as we are testing that we can communicate with the forwarded ports. * Temporarily skip the test step on Podman that connects to the forwarded debug port until [1] is fixed We can work on fixing the issue on Podman in a separate PR. [1] #6510
|
FWIW, I just discovered a |
|
As noticed by @feloy, it works if the application listens on all interfaces ( TODO (Scope of this issue after team discussion on 2023-01-23):
|
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 2, 2023
By default, Docusaurus would listen only on the loopback interface, which does not work with Podman at this time (see [1]). [1] redhat-developer#6510 (comment)
openshift-merge-robot
pushed a commit
that referenced
this issue
Feb 2, 2023
* Add 'devfile.yaml' for working on the website * Git-ignore the '.odo' folder * Make Docusaurus listen on all interfaces By default, Docusaurus would listen only on the loopback interface, which does not work with Podman at this time (see [1]). [1] #6510 (comment)
|
Summary of investigations Per containers/podman#17353 (comment), this behavior is intentional on Podman: applications that are bound to the loopback interface cannot be reached using I noticed we have the same issue when publishing ports with either Docker or Podman, e.g: # On the host, localhost:20001 is reachable
$ docker container run --rm -p 20001:9000 -t quay.io/redhatworkshops/simple-python-web \
/usr/bin/python3 -m http.server 9000 --bind 0.0.0.0
# On the host, localhost:20001 is not reachable
$ docker container run --rm -p 20001:9000 -t quay.io/redhatworkshops/simple-python-web \
/usr/bin/python3 -m http.server 9000 --bind 127.0.0.1Kubernetes port forwarding seems to work differently, according to the corresponding design doc: it is currently specified in the Container Runtime Interface (CRI). Now, most CRI implementations I have seen (like containerd or cri-o) forward a stream inside the network namespace to a specific port. For now, as agreed, I'm documenting this as a difference between K8s and Podman: users would need to explicitly bind their applications to 0.0.0.0 (or any public interfaces of the container) in such cases. Meanwhile, I have explored alternatives that would not require users to change how they bind their applications to network interfaces:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
labels:
app: my-pod
spec:
containers:
- name: nginx-container
image: nginx:latest
#ports:
#- containerPort: 80
# hostPort: 8888
- name: python-web-container
image: quay.io/redhatworkshops/simple-python-web:latest
command: [ '/usr/bin/python3', '-m', 'http.server', '9000', '--bind', '127.0.0.1']
ports:
- containerPort: 9000
# This won't work
hostPort: 19000
- name: python-web-container-socat
image: quay.io/devfile/base-developer-image:ubi8-latest
command: [ '/bin/sh', '-c', 'socat -d -d tcp-listen:20002,reuseaddr,fork tcp:localhost:9000']
ports:
- containerPort: 20002
# This works !
hostPort: 20002
|
25 tasks
|
Cabal call [7th Feb '23] Stage 1/Quick sol: Use socat inside the container; check if the images in the Devfile registry has the binary; should work for most of the user |
As we can see below, the
|
|
/retitle On Podman, unable to access local ports forwarded to container applications listening on the loopback interface Retitling, now that we understand what the actual issue is. |
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 10, 2023
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
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 10, 2023
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
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 10, 2023
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
3 tasks
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 10, 2023
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
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 10, 2023
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
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 10, 2023
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
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 10, 2023
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
What are the arguments in favor of making this issue a blocker? Arguments against are:
(1) As I understand, we want to introduce Podman backend for odo to lower the entry level to develop with odo. If we increase the complexity of the deployed containers in Podman (by adding sidecar containers, etc, with the associated security risks), this could be counter-productive. |
I understand that there are security concerns when doing this in the developer machine, for example explained here: https://nodejs.org/fr/docs/guides/debugging-getting-started/#security-implications I don't know much about networking inside Containers/Podman, and if their concerns are also applicable inside a Podman container? |
One of the arguments for me was, from the Adapters perspective, to make sure they could use the same current Devfiles to debug on either Podman or Kubernetes, with no changes in the Devfile.
The configuration of the Debugger could also be in the project code itself, as we saw with the Node.JS stack; well, the debug command to run is still in the Devfile, that said.
I see all this as an internal implementation detail of how But let's see @kadel's take on this. |
|
The biggest issue is that because localhost works with the cluster, we have a lot of Devfiles leveraging this "feature". debugger on localhost
debugger on 0.0.0.0
It will be confusing to have it working differently on one platform than the other. This makes me think about how this works on DevSpaces. If the application opening ports only for localhost doesn't work on DevSpaces, than we don't have to worry about not being able to reach ports on podman. But instead, we will have to restrict cluster port-forwarding to match how it works on DevSpaces and fix devfiles in the registry. |
8 tasks
|
We have checked that applications listening on localhost currently work on DevSpaces.
Summary of our discussions/brainstorming
Done in the following PRs:
Later, we can turn those new flags into preferences, so users don't need to set them for each call. |
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 23, 2023
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 23, 2023
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 27, 2023
…und to the loopback interface (on any ports supposed to be forwarded) Next step will be to provide an option for end-users to override this behavior, by either: - ignoring this error (--ignore-localhost); - or explicitly adding a redirect via a side container (--forward-localhost) More context in redhat-developer#6510 (comment)
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 28, 2023
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
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 28, 2023
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
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Feb 28, 2023
…und to the loopback interface (on any ports supposed to be forwarded) Next step will be to provide an option for end-users to override this behavior, by either: - ignoring this error (--ignore-localhost); - or explicitly adding a redirect via a side container (--forward-localhost) More context in redhat-developer#6510 (comment)
openshift-merge-robot
pushed a commit
that referenced
this issue
Mar 1, 2023
…ce, and either error out or not depending on `--ignore-localhost` (#6620) * Add functions allowing to detect ports opened in a given container Specifically, this will be useful in Podman to detect applications that are bound to the loopback interface * Make `odo dev` fail on Podman if we detect that the application is bound to the loopback interface (on any ports supposed to be forwarded) Next step will be to provide an option for end-users to override this behavior, by either: - ignoring this error (--ignore-localhost); - or explicitly adding a redirect via a side container (--forward-localhost) More context in #6510 (comment) * Add '--ignore-localhost' flag to 'odo dev' on Podman Currently, `odo dev` on Podman will error out if it detects that the application is listening on the container loopback interface. Instead of erroring out, this flag allows users to ignore such failure; a warning will be displayed anyway if the application is listening on the container loopback interface, but odo will not error out. Ports will be marked as forwarded, but Podman might fail to redirect traffic to the application if it is bound to this loopback interface. * Add test cases * Fix existing integration tests by passing --ignore-localhost on Podman - odo describe component - odo dev --debug Some projects used there are listening to the loopback interface, so they won't work on Podman unless --ignore-localhost is passed. Next, we'll pass --forward-localhost when it is implemented, so we can have a fully working project with port-forwarding. * Extract logic for handling loopback ports in a separate method Requested in review
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Mar 1, 2023
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
rm3l
added a commit
to rm3l/odo
that referenced
this issue
Mar 1, 2023
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
3 tasks
openshift-merge-robot
pushed a commit
that referenced
this issue
Mar 6, 2023
…ck interface, via a new `--forward-localhost` flag (#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] #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] #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
anandrkskd
pushed a commit
to anandrkskd/odo
that referenced
this issue
Mar 7, 2023
…ce, and either error out or not depending on `--ignore-localhost` (redhat-developer#6620) * Add functions allowing to detect ports opened in a given container Specifically, this will be useful in Podman to detect applications that are bound to the loopback interface * Make `odo dev` fail on Podman if we detect that the application is bound to the loopback interface (on any ports supposed to be forwarded) Next step will be to provide an option for end-users to override this behavior, by either: - ignoring this error (--ignore-localhost); - or explicitly adding a redirect via a side container (--forward-localhost) More context in redhat-developer#6510 (comment) * Add '--ignore-localhost' flag to 'odo dev' on Podman Currently, `odo dev` on Podman will error out if it detects that the application is listening on the container loopback interface. Instead of erroring out, this flag allows users to ignore such failure; a warning will be displayed anyway if the application is listening on the container loopback interface, but odo will not error out. Ports will be marked as forwarded, but Podman might fail to redirect traffic to the application if it is bound to this loopback interface. * Add test cases * Fix existing integration tests by passing --ignore-localhost on Podman - odo describe component - odo dev --debug Some projects used there are listening to the loopback interface, so they won't work on Podman unless --ignore-localhost is passed. Next, we'll pass --forward-localhost when it is implemented, so we can have a fully working project with port-forwarding. * Extract logic for handling loopback ports in a separate method Requested in review
anandrkskd
pushed a commit
to anandrkskd/odo
that referenced
this issue
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
/kind bug
/area dev
/area odo-on-podman
What versions of software are you using?
Operating System:
Fedora 37, kernel 6.1.6-200.fc37.x86_64
Output of
odo version:odo v3.5.0(8dbf42e)How did you run odo exactly?
As expected, trying to access the forwarded application port (40001 here) works correctly:
But trying to access the application on the forwarded debug port (40002 here) returns an error:
Actual behavior
Accessing the application on the forwarded debug port (40002 here) returns an error:
Expected behavior
When running
odo devagainst a cluster, we get the expected HTTP response from the forwarded application debug port:I was expecting the same behavior on Podman.
Any logs, error output, etc?
podman kube generate
The text was updated successfully, but these errors were encountered: