Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When specifying one only container published port, the host port is not random but equal to containers one #7947

Closed
sshnaidm opened this issue Oct 7, 2020 · 3 comments · Fixed by #7951
Assignees
Labels
In Progress This issue is actively being worked by the assignee, please do not work on this at this time. kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@sshnaidm
Copy link
Member

sshnaidm commented Oct 7, 2020

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description
When specifying one only container published port - --publish 9000, the host port is not random but equal to containers one. In docs it's mentioned that host port will be a random port.

Steps to reproduce the issue:

  1. podman run -dit --name zzz -p 9000 alpine sleep 2m

  2. podman inspect zzz
    Describe the results you received:

"PortBindings": {
                "9000/tcp": [
                    {
                        "HostIp": "",
                        "HostPort": "9000"
                    }
                ]
            },

Describe the results you expected:
I'd expect host port to be random as it's mentioned in documentation, like:

"PortBindings": {
                "9000/tcp": [
                    {
                        "HostIp": "",
                        "HostPort": "43276"
                    }
                ]
            },

Additional information you deem important (e.g. issue happens only occasionally):
It happens in podman version 2, in podman versions 1 it's a real random port.
Output of podman version:

Version:      2.1.1
API Version:  2.0.0
Go Version:   go1.15.2
Built:        Thu Jan  1 00:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.16.1
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.20, commit: '
  cpus: 4
  distribution:
    distribution: ubuntu
    version: "20.04"
  eventLogger: journald
  hostname: ubuntu20-vmtest
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.4.0-48-generic
  linkmode: dynamic
  memFree: 1591517184
  memTotal: 2083717120
  ociRuntime:
    name: runc
    package: 'runc: /usr/sbin/runc'
    path: /usr/sbin/runc
    version: 'runc version spec: 1.0.1-dev'
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.1.4
      commit: unknown
      libslirp: 4.3.1-git
      SLIRP_CONFIG_VERSION_MAX: 3
  swapFree: 0
  swapTotal: 0
  uptime: 1m 29.64s
registries:
  search:
  - docker.io
  - quay.io
store:
  configFile: /home/ubuntu/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: vfs
  graphOptions: {}
  graphRoot: /home/ubuntu/.local/share/containers/storage
  graphStatus: {}
  imageStore:
    number: 22
  runRoot: /run/user/1000/containers
  volumePath: /home/ubuntu/.local/share/containers/storage/volumes
version:
  APIVersion: 2.0.0
  Built: 0
  BuiltTime: Thu Jan  1 00:00:00 1970
  GitCommit: ""
  GoVersion: go1.15.2
  OsArch: linux/amd64
  Version: 2.1.1

Package info (e.g. output of rpm -q podman or apt list podman):

podman/unknown,now 2.1.1~2 amd64 [installed]
podman/unknown 2.1.1~2 arm64
podman/unknown 2.1.1~2 armhf
podman/unknown 2.1.1~2 s390x

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):
OS: Ubuntu 20.04

Related to issue of idempotency in ansible podman modules: containers/ansible-podman-collections#116

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Oct 7, 2020
@mheon
Copy link
Member

mheon commented Oct 7, 2020

I'll take this one.

@mheon mheon self-assigned this Oct 7, 2020
@mheon mheon added the In Progress This issue is actively being worked by the assignee, please do not work on this at this time. label Oct 7, 2020
@sshnaidm
Copy link
Member Author

sshnaidm commented Oct 8, 2020

@mheon is there a reason behind a "randomness" of host port? What is it useful for? Wouldn't be more logical to set the same port if only one port was configured (as it's behavior now in 2.x)?
Probably this is not a bug, but feature. (Just need to update docs about it)

mheon added a commit to mheon/libpod that referenced this issue Oct 8, 2020
In Podman 1.9.3, `podman run -p 80` would assign port 80 in the
container to a random port on the host. In Podman 2.0 and up, it
assigned Port 80 in the container to Port 80 on the host. This is
an easy fix, fortunately - just need to remove the bit that
assumed host port, if not given, should be set to container port.

We also had a test for the bad behavior, so fix it to test for
the correct way of doing things.

Fixes containers#7947

Signed-off-by: Matthew Heon <matthew.heon@pm.me>
@mheon
Copy link
Member

mheon commented Oct 8, 2020

The logic, from what I can tell, is that this makes it trivial to launch a large batch of containers that all want to use the same port, and safely expose all of them to the internet. I could run a dozen HTTP servers with podman run -p 80 -d alpine and all of them would safely assign a host port.

mheon added a commit to mheon/libpod that referenced this issue Oct 14, 2020
In Podman 1.9.3, `podman run -p 80` would assign port 80 in the
container to a random port on the host. In Podman 2.0 and up, it
assigned Port 80 in the container to Port 80 on the host. This is
an easy fix, fortunately - just need to remove the bit that
assumed host port, if not given, should be set to container port.

We also had a test for the bad behavior, so fix it to test for
the correct way of doing things.

Fixes containers#7947

Signed-off-by: Matthew Heon <matthew.heon@pm.me>
kahowell added a commit to RedHatInsights/rhsm-subscriptions that referenced this issue Jan 13, 2021
I only noticed b/c `podman-compose down` followed by `podman-compose up`
broke my dev setup.

So, the difference between `5432` and `5432:5432`:

 - `5432` instructs podman to pick an arbitrary port to map to a
   container's port `5432`
 - `5432:5432` instructs podman to map the host's port `5432` to a
   container's port `5432`

podman v2.2.0+ ensures that the arbitrary port is random.

See containers/podman#7947
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 22, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
In Progress This issue is actively being worked by the assignee, please do not work on this at this time. kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants