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