github.com/anth0d/nomad@v0.0.0-20221214183521-ae3a0a2cad06/website/content/docs/job-specification/network.mdx (about)

     1  ---
     2  layout: docs
     3  page_title: network Stanza - Job Specification
     4  description: |-
     5    The "network" stanza specifies the networking requirements for the task group,
     6    including networking mode and port allocations.
     7  ---
     8  
     9  # `network` Stanza
    10  
    11  <Placement groups={[['job', 'group', 'network']]} />
    12  
    13  The `network` stanza specifies the networking requirements for the task group,
    14  including the network mode and port allocations. When scheduling jobs in
    15  Nomad they are provisioned across your fleet of machines along with other jobs
    16  and services. Because you don't know in advance what host your job will be
    17  provisioned on, Nomad will provide your tasks with network configuration when
    18  they start up.
    19  
    20  Note that this document only applies to services that want to _listen_ on a
    21  port. Batch jobs or services that only make outbound connections do not need to
    22  allocate ports, since they will use any available interface to make an outbound
    23  connection.
    24  
    25  ```hcl
    26  job "docs" {
    27    group "example" {
    28      network {
    29        port "http" {}
    30        port "https" {}
    31        port "lb" {
    32          static = 8889
    33        }
    34      }
    35    }
    36  }
    37  ```
    38  
    39  ### Network modes
    40  
    41  When the `network` stanza is defined with `bridge` as the networking mode,
    42  all tasks in the task group share the same network namespace. This is a prerequisite for
    43  [Consul Connect](/docs/integrations/consul-connect). Tasks running within a
    44  network namespace are not visible to applications outside the namespace on the same host.
    45  This allows [Connect][]-enabled applications to bind only to localhost within the shared network stack,
    46  and use the proxy for ingress and egress traffic.
    47  
    48  To use `bridge` mode, you must have the [reference CNI
    49  plugins](https://github.com/containernetworking/plugins/releases/tag/v1.0.0)
    50  installed at the location specified by the client's [`cni_path`]
    51  configuration. These plugins are used to create the bridge network and
    52  configure the appropriate iptables rules.
    53  
    54  Network modes are only supported in allocations running on Linux clients.
    55  All other operating systems use the `host` networking mode.
    56  
    57  ## `network` Parameters
    58  
    59  - `mbits` <code>([_deprecated_](/docs/upgrade/upgrade-specific#nomad-0-12-0) int: 10)</code> - Specifies the bandwidth required in MBits.
    60  
    61  - `port` <code>([Port](#port-parameters): nil)</code> - Specifies a TCP/UDP port
    62    allocation and can be used to specify both dynamic ports and reserved ports.
    63  
    64  - `mode` `(string: "host")` - Mode of the network. This option is only supported
    65    on Linux clients. The following modes are available:
    66  
    67    - `none` - Task group will have an isolated network without any network interfaces.
    68    - `bridge` - Task group will have an isolated network namespace with an interface
    69      that is bridged with the host. Note that bridge networking is only
    70      currently supported for the `docker`, `exec`, `raw_exec`, and `java` task
    71      drivers.
    72    - `host` - Each task will join the host network namespace and a shared network
    73      namespace is not created. This matches the current behavior in Nomad 0.9.
    74    - `cni/<cni network name>` - Task group will have an isolated network namespace
    75      with the network configured by CNI.
    76  
    77  - `hostname` `(string: "")` - The hostname assigned to the network namespace. This
    78    is currently only supported using the [Docker driver][docker-driver] and when the
    79    [mode](#mode) is set to [`bridge`](#bridge). This parameter supports
    80    [interpolation](/docs/runtime/interpolation).
    81  
    82  - `dns` <code>([DNSConfig](#dns-parameters): nil)</code> - Sets the DNS configuration
    83    for the allocations. By default all DNS configuration is inherited from the client host.
    84    DNS configuration is only supported on Linux clients at this time.
    85  
    86  ### `port` Parameters
    87  
    88  - `static` `(int: nil)` - Specifies the static TCP/UDP port to allocate. If omitted, a
    89    dynamic port is chosen. We **do not recommend** using static ports, except
    90    for `system` or specialized jobs like load balancers.
    91  - `to` `(string:nil)` - Applicable when using "bridge" mode to configure port
    92    to map to inside the task's network namespace. Omitting this field or
    93    setting it to `-1` sets the mapped port equal to the dynamic port allocated
    94    by the scheduler. The `NOMAD_PORT_<label>` environment variable will contain
    95    the `to` value.
    96  - `host_network` `(string:nil)` - Designates the host network name to use when allocating
    97    the port. When port mapping the host port will only forward traffic to the matched host
    98    network address.
    99  
   100  The label assigned to the port is used to identify the port in service
   101  discovery, and used in the name of the environment variable that indicates
   102  which port your application should bind to. For example:
   103  
   104  ```hcl
   105  port "foo" {}
   106  ```
   107  
   108  When the task starts, it will be passed the following environment variables:
   109  
   110  - <tt>NOMAD_IP_foo</tt> - The IP to bind on for the given port label.
   111  - <tt>NOMAD_PORT_foo</tt> - The port value for the given port label.
   112  - <tt>NOMAD_ADDR_foo</tt> - A combined <tt>ip:port</tt> that can be used for convenience.
   113  
   114  The label of the port is just text - it has no special meaning to Nomad.
   115  
   116  ## `dns` Parameters
   117  
   118  - `servers` `(array<string>: nil)` - Sets the DNS nameservers the allocation uses for name resolution.
   119  - `searches` `(array<string>: nil)` - Sets the search list for hostname lookup
   120  - `options` `(array<string>: nil)` - Sets internal resolver variables.
   121  
   122  These parameters support [interpolation](/docs/runtime/interpolation).
   123  
   124  ## `network` Examples
   125  
   126  The following examples only show the `network` stanzas. Remember that the
   127  `network` stanza is only valid in the placements listed above.
   128  
   129  ### Dynamic Ports
   130  
   131  This example specifies a dynamic port allocation for the port labeled "http".
   132  Dynamic ports are allocated in a range from `20000` to `32000`.
   133  
   134  Most services run in your cluster should use dynamic ports. This means that the
   135  port will be allocated dynamically by the scheduler, and your service will have
   136  to read an environment variable to know which port to bind to at startup.
   137  
   138  ```hcl
   139  group "example" {
   140    network {
   141      port "http" {}
   142      port "https" {}
   143    }
   144  }
   145  ```
   146  
   147  ```hcl
   148  network {
   149    port "http" {}
   150  }
   151  ```
   152  
   153  ### Static Ports
   154  
   155  This example specifies a static port allocation for the port labeled "lb". Static
   156  ports bind your job to a specific port on the host they' are placed on. Since
   157  multiple services cannot share a port, the port must be open in order to place
   158  your task.
   159  
   160  ```hcl
   161  network {
   162    port "lb" {
   163      static = 6539
   164    }
   165  }
   166  ```
   167  
   168  ### Mapped Ports
   169  
   170  Some drivers (such as [Docker][docker-driver] and [QEMU][qemu-driver]) allow you
   171  to map ports. A mapped port means that your application can listen on a fixed
   172  port (it does not need to read the environment variable) and the dynamic port
   173  will be mapped to the port in your container or virtual machine.
   174  
   175  ```hcl
   176  group "app" {
   177    network {
   178      port "http" {
   179        to = 8080
   180      }
   181    }
   182  
   183    task "example" {
   184      driver = "docker"
   185  
   186      config {
   187        ports = ["http"]
   188      }
   189    }
   190  }
   191  ```
   192  
   193  The above example is for the Docker driver. The service is listening on port
   194  `8080` inside the container. The driver will automatically map the dynamic port
   195  to this service.
   196  
   197  When the task is started, it is passed an additional environment variable named
   198  `NOMAD_HOST_PORT_http` which indicates the host port that the HTTP service is
   199  bound to.
   200  
   201  ### Bridge Mode
   202  
   203  Bridge mode allows compatible tasks to share a networking stack and interfaces. Nomad
   204  can then do port mapping without relying on individual task drivers to implement port
   205  mapping configuration.
   206  
   207  The following example is a group level network stanza that uses bridge mode
   208  and port mapping.
   209  
   210  ```hcl
   211  network {
   212    mode = "bridge"
   213    port "http" {
   214      static = 9002
   215      to     = 9002
   216    }
   217  }
   218  ```
   219  
   220  Using bridge mode can result in failing outbound network requests on hosts that have
   221  [firewalld](https://firewalld.org) enabled. This includes most RHEL-based Linux distributions
   222  like CentOS, Rocky Linux or Oracle Linux. One solution for firewalld to allow network
   223  requsts coming from Nomad jobs is to mark the `nomad` bridge interface as trusted.
   224  
   225  ```shell-session
   226  $ sudo firewall-cmd --zone=trusted --add-interface=nomad
   227  $ sudo firewall-cmd --zone=trusted --add-interface=nomad --permanent
   228  ```
   229  
   230  It is neccessary to restart the affected jobs afterwards for them to be able to access
   231  the network. Further details can be found in Docker's documentation under [Docker and iptables](https://docs.docker.com/network/iptables/#integration-with-firewalld).
   232  
   233  ### DNS
   234  
   235  The following example configures the allocation to use Google's DNS resolvers 8.8.8.8 and 8.8.4.4.
   236  
   237  ```hcl
   238  network {
   239    dns {
   240      servers = ["8.8.8.8", "8.8.4.4"]
   241    }
   242  }
   243  ```
   244  
   245  ### Container Network Interface (CNI)
   246  
   247  Nomad supports CNI by fingerprinting each node for [CNI network configurations](https://github.com/containernetworking/cni/blob/v0.8.0/SPEC.md#network-configuration).
   248  These are associated to the node by the `name` field of the CNI configuration.
   249  The `name` can then be used when setting the network `mode` field in the form of `cni/<name>`.
   250  
   251  As an example if the following CNI configuration was on a node the proceeding network stanza could be used.
   252  
   253  ```json
   254  {
   255    "cniVersion": "0.3.1",
   256    "name": "mynet",
   257    "plugins": [
   258      {
   259        "type": "ptp",
   260        "ipMasq": true,
   261        "ipam": {
   262          "type": "host-local",
   263          "subnet": "172.16.30.0/24",
   264          "routes": [
   265            {
   266              "dst": "0.0.0.0/0"
   267            }
   268          ]
   269        }
   270      },
   271      {
   272        "type": "portmap",
   273        "capabilities": { "portMappings": true }
   274      }
   275    ]
   276  }
   277  ```
   278  
   279  ```hcl
   280  network {
   281    mode = "cni/mynet"
   282    port "http" {
   283      to = 8080
   284    }
   285  }
   286  ```
   287  
   288  The Nomad client will build the correct [capabilities arguments](https://github.com/containernetworking/cni/blob/v0.8.0/CONVENTIONS.md#well-known-capabilities) for the portmap plugin based on the defined port stanzas.
   289  
   290  ### Host Networks
   291  
   292  In some cases a port should only be allocated to a specific interface or address on the host.
   293  The `host_network` field of a port will constrain port allocation to a single named host network.
   294  If `host_network` is set for a port, Nomad will schedule the allocations on a node which has defined a `host_network` with the given name.
   295  If not set the "default" host network is used which is commonly the address with a default route associated with it.
   296  
   297  When Nomad does port mapping for ports with a defined `host_network`, the port mapping rule will use the host address as the destination address.
   298  
   299  ```hcl
   300  network {
   301    mode = "bridge"
   302  
   303    # define a port to use for public https traffic
   304    port "https" {
   305      static       = 443
   306      to           = 8080
   307      host_network = "public"
   308    }
   309    # define a port that is only exposed to private traffic
   310    port "admin" {
   311      to           = 9000
   312      host_network = "private"
   313    }
   314  }
   315  ```
   316  
   317  ### Limitations
   318  
   319  - Only one `network` stanza can be specified, when it is defined at the task group level.
   320  - Only the `NOMAD_PORT_<label>` and `NOMAD_HOST_PORT_<label>` environment
   321    variables are set for group network ports.
   322  
   323  [docker-driver]: /docs/drivers/docker 'Nomad Docker Driver'
   324  [qemu-driver]: /docs/drivers/qemu 'Nomad QEMU Driver'
   325  [connect]: /docs/job-specification/connect 'Nomad Consul Connect Integration'
   326  [`cni_path`]: /docs/configuration/client#cni_path