github.com/iqoqo/nomad@v0.11.3-0.20200911112621-d7021c74d101/website/pages/docs/runtime/interpolation.mdx (about) 1 --- 2 layout: docs 3 page_title: Variable Interpolation 4 sidebar_title: Variable Interpolation 5 description: Learn about the Nomad's interpolation and interpreted variables. 6 --- 7 8 # Variable Interpolation 9 10 Nomad supports interpreting two classes of variables: node attributes and 11 runtime environment variables. Node attributes are interpretable in constraints, 12 task environment variables, and certain driver fields. Runtime environment 13 variables are not interpretable in constraints because they are only defined 14 once the scheduler has placed them on a particular node. 15 16 The syntax for interpreting variables is `${variable}`. An example and a 17 comprehensive list of interpretable fields can be seen below: 18 19 ```hcl 20 task "docs" { 21 driver = "docker" 22 23 # Drivers support interpreting node attributes and runtime environment 24 # variables 25 config { 26 image = "my-app" 27 28 # Interpret runtime variables to inject the address to bind to and the 29 # location to write logs to. 30 args = [ 31 "--bind", "${NOMAD_ADDR_RPC}", 32 "--logs", "${NOMAD_ALLOC_DIR}/logs", 33 ] 34 35 port_map { 36 RPC = 6379 37 } 38 } 39 40 # Constraints only support node attributes as runtime environment variables 41 # are only defined after the task is placed on a node. 42 constraint { 43 attribute = "${attr.kernel.name}" 44 value = "linux" 45 } 46 47 # Environment variables are interpreted and can contain both runtime and 48 # node attributes. These environment variables are passed into the task. 49 env { 50 "DC" = "Running on datacenter ${node.datacenter}" 51 "VERSION" = "Version ${NOMAD_META_VERSION}" 52 } 53 54 # Meta keys are also interpretable. 55 meta { 56 VERSION = "v0.3" 57 } 58 } 59 ``` 60 61 ## Node Variables ((#interpreted_node_vars, #node-variables-)) 62 63 Below is a full listing of node attributes that are interpretable. These 64 attributes are interpreted by **both** constraints and within the task and 65 driver. 66 67 <table> 68 <thead> 69 <tr> 70 <th>Variable</th> 71 <th>Description</th> 72 <th>Example Value</th> 73 </tr> 74 </thead> 75 <tbody> 76 <tr> 77 <td> 78 <code>{'${node.unique.id}'}</code> 79 </td> 80 <td>36 character unique client identifier</td> 81 <td> 82 <code>9afa5da1-8f39-25a2-48dc-ba31fd7c0023</code> 83 </td> 84 </tr> 85 <tr> 86 <td> 87 <code>{'${node.region}'}</code> 88 </td> 89 <td>Client's region</td> 90 <td> 91 <code>global</code> 92 </td> 93 </tr> 94 <tr> 95 <td> 96 <code>{'${node.datacenter}'}</code> 97 </td> 98 <td>Client's datacenter</td> 99 <td> 100 <code>dc1</code> 101 </td> 102 </tr> 103 <tr> 104 <td> 105 <code>{'${node.unique.name}'}</code> 106 </td> 107 <td>Client's name</td> 108 <td> 109 <code>nomad-client-10-1-2-4</code> 110 </td> 111 </tr> 112 <tr> 113 <td> 114 <code>{'${node.class}'}</code> 115 </td> 116 <td>Client's class</td> 117 <td> 118 <code>linux-64bit</code> 119 </td> 120 </tr> 121 <tr> 122 <td> 123 <code> 124 ${'{'}attr.<property>{'}'} 125 </code> 126 </td> 127 <td> 128 Property given by <code>property</code> on the client 129 </td> 130 <td> 131 <code>{'${attr.cpu.arch} => amd64'}</code> 132 </td> 133 </tr> 134 <tr> 135 <td> 136 <code> 137 ${'{'}meta.<key>{'}'} 138 </code> 139 </td> 140 <td> 141 Metadata value given by <code>key</code> on the client 142 </td> 143 <td> 144 <code>{'${meta.foo} => bar'}</code> 145 </td> 146 </tr> 147 </tbody> 148 </table> 149 150 Below is a table documenting common node properties: 151 152 <table> 153 <thead> 154 <tr> 155 <th>Property</th> 156 <th>Description</th> 157 </tr> 158 </thead> 159 <tbody> 160 <tr> 161 <td> 162 <code>{'${attr.cpu.arch}'}</code> 163 </td> 164 <td> 165 CPU architecture of the client (e.g. <code>amd64</code>,{' '} 166 <code>386</code>) 167 </td> 168 </tr> 169 <tr> 170 <td> 171 <code>{'${attr.cpu.numcores}'}</code> 172 </td> 173 <td>Number of CPU cores on the client</td> 174 </tr> 175 <tr> 176 <td> 177 <code>{'${attr.cpu.totalcompute}'}</code> 178 </td> 179 <td> 180 <code>cpu.frequency × cpu.numcores</code> but may be overridden by{' '} 181 <code>client.cpu_total_compute</code> 182 </td> 183 </tr> 184 <tr> 185 <td> 186 <code>{'${attr.consul.datacenter}'}</code> 187 </td> 188 <td>The Consul datacenter of the client (if Consul is found)</td> 189 </tr> 190 <tr> 191 <td> 192 <code> 193 ${'{'}attr.driver.<property>{'}'} 194 </code> 195 </td> 196 <td> 197 See the <a href="/docs/drivers">task drivers</a> for property 198 documentation 199 </td> 200 </tr> 201 <tr> 202 <td> 203 <code>{'${attr.unique.hostname}'}</code> 204 </td> 205 <td>Hostname of the client</td> 206 </tr> 207 <tr> 208 <td> 209 <code>{'${attr.unique.network.ip-address}'}</code> 210 </td> 211 <td> 212 The IP address fingerprinted by the client and from which task ports are 213 allocated 214 </td> 215 </tr> 216 <tr> 217 <td> 218 <code>{'${attr.kernel.name}'}</code> 219 </td> 220 <td> 221 Kernel of the client (e.g. <code>linux</code>, <code>darwin</code>) 222 </td> 223 </tr> 224 <tr> 225 <td> 226 <code>{'${attr.kernel.version}'}</code> 227 </td> 228 <td> 229 Version of the client kernel (e.g. <code>3.19.0-25-generic</code>,{' '} 230 <code>15.0.0</code>) 231 </td> 232 </tr> 233 <tr> 234 <td> 235 <code>{'${attr.platform.aws.ami-id}'}</code> 236 </td> 237 <td>AMI ID of the client (if on AWS EC2)</td> 238 </tr> 239 <tr> 240 <td> 241 <code>{'${attr.platform.aws.instance-type}'}</code> 242 </td> 243 <td>Instance type of the client (if on AWS EC2)</td> 244 </tr> 245 <tr> 246 <td> 247 <code>{'${attr.os.name}'}</code> 248 </td> 249 <td> 250 Operating system of the client (e.g. <code>ubuntu</code>,{' '} 251 <code>windows</code>, <code>darwin</code>) 252 </td> 253 </tr> 254 <tr> 255 <td> 256 <code>{'${attr.os.version}'}</code> 257 </td> 258 <td>Version of the client OS</td> 259 </tr> 260 </tbody> 261 </table> 262 263 Here are some examples of using node attributes and properties in a job file: 264 265 ```hcl 266 job "docs" { 267 # This will constrain this job to only run on 64-bit clients. 268 constraint { 269 attribute = "${attr.cpu.arch}" 270 value = "amd64" 271 } 272 273 # This will restrict the job to only run on clients with 4 or more cores. 274 # Note: you may also declare a resource requirement for CPU for a task. 275 constraint { 276 attribute = "${cpu.numcores}" 277 operator = ">=" 278 value = "4" 279 } 280 281 # Only run this job on a memory-optimized AWS EC2 instance. 282 constraint { 283 attribute = "${attr.platform.aws.instance-type}" 284 value = "m4.xlarge" 285 } 286 } 287 ``` 288 289 ## Environment Variables ((#interpreted_env_vars)) 290 291 The following are runtime environment variables that describe the environment 292 the task is running in. These are only defined once the task has been placed on 293 a particular node and as such can not be used in constraints. 294 295 Environment variables should be enclosed in brackets `${...}` for 296 interpolation. 297 298 ### Dots in Variables ((#dots_in_vars)) 299 300 Starting in Nomad 0.9, task configuration interpolation requires variables to 301 be valid identifiers. While this does not affect default variables or common 302 custom variables, it is possible to define a variable that is not a valid 303 identifier: 304 305 ```hcl 306 env { 307 "valid.name" = "ok" 308 "invalid...name" = "not a valid identifier" 309 } 310 ``` 311 312 The environment variable `invalid...name` cannot be interpolated using the 313 standard `"${invalid...name}"` syntax. The dots will be interpreted as object 314 notation so multiple consecutive dots are invalid. 315 316 To continue supporting all user environment variables Nomad 0.9 added a new 317 `env` variable which allows accessing any environment variable through index 318 syntax: 319 320 ```hcl 321 task "redis" { 322 driver = "docker" 323 config { 324 image = "redis:3.2" 325 labels { 326 label1 = "${env["invalid...name"]}" 327 label2 = "${env["valid.name"]}" 328 } 329 } 330 } 331 ``` 332 333 @include 'envvars.mdx'