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

Default behavior for port mapping #6958

Closed
nickethier opened this issue Jan 17, 2020 · 3 comments · Fixed by #10828
Closed

Default behavior for port mapping #6958

nickethier opened this issue Jan 17, 2020 · 3 comments · Fixed by #10828

Comments

@nickethier
Copy link
Member

nickethier commented Jan 17, 2020

Currently the following network stanza will generate an error:

network {
  mode = "bridge"
  port "http" { }
}

This is because there is no to field in the port stanza. We should change this to map the to field to what ever the host port is assigned. This means for a dynamic port, if to is not specified Nomad will map the port to the same value that is allocated for the dynamic port. For static ports, this means the port will get mapped to the same port specified in static.

This change should be noted in the Version Specific Upgrade notes as its a significant change in behavior.

@tgross
Copy link
Member

tgross commented Jun 28, 2021

I'm doing some networking documentation cleanup and this issue seems to conflict with #9456 where they're claiming that we already have this. I've verified this with the following jobspec on Nomad 1.1.2:

jobspec
job "example" {
  datacenters = ["dc1"]

  group "web" {

    network {
      mode = "bridge"
      port "www" {
        // to = 8001
      }
    }

    task "httpd" {
      driver = "docker"

      config {
        image   = "busybox:1"
        command = "httpd"
        args    = ["-v", "-f", "-p", "${NOMAD_PORT_www}", "-h", "/local"]
        ports   = ["www"]
      }

      template {
        data        = "<html>hello, world</html>"
        destination = "local/index.html"
      }

      resources {
        cpu    = 128
        memory = 128
      }
    }
  }
}

Run the job and see that the unspecified port is being mapped to the dynamic port, just as this issue says:

$ nomad job run ./example.nomad
==> 2021-06-28T18:31:49Z: Monitoring evaluation "eb98212a"
    2021-06-28T18:31:49Z: Evaluation triggered by job "example"
    2021-06-28T18:31:49Z: Allocation "0853a728" created: node "1eba2e0c", group "web"
...

$ nomad alloc status 085
ID                  = 0853a728-297d-4e32-9f91-c8758297b38e
...
Allocation Addresses (mode = "bridge")
Label  Dynamic  Address
*www   yes      10.0.2.15:20158
...

$ curl 10.0.2.15:20158
<html>hello, world</html>

So it sounds like the way we could close out both #6958 and #9456 is to change the port map to documentation as follows:

diff --git a/website/content/docs/job-specification/network.mdx b/website/content/docs/job-specification/network.mdx
index 02f688830..7d1a1ceb0 100644
--- a/website/content/docs/job-specification/network.mdx
+++ b/website/content/docs/job-specification/network.mdx
@@ -72,9 +72,10 @@ job "docs" {
   dynamic port is chosen. We **do not recommend** using static ports, except
   for `system` or specialized jobs like load balancers.
 - `to` `(string:nil)` - Applicable when using "bridge" mode to configure port
-  to map to inside the task's network namespace. `-1` sets the mapped port equal to the
-  dynamic port allocated by the scheduler. The `NOMAD_PORT_<label>` environment variable
-  will contain the `to` value.
+  to map to inside the task's network namespace. Omitting this field or
+  setting it to `-1` sets the mapped port equal to the dynamic port allocated
+  by the scheduler. The `NOMAD_PORT_<label>` environment variable will contain
+  the `to` value.
 - `host_network` `(string:nil)` - Designates the host network name to use when allocating
   the port. When port mapping the host port will only forward traffic to the matched host
   network address.

@tgross
Copy link
Member

tgross commented Jun 28, 2021

I found the PR where this got done originally, which was a side-effect of #8208. I'll make a PRs and changelog PR to call it out to close both this and #9456

@github-actions
Copy link

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants