github.com/maier/nomad@v0.4.1-0.20161110003312-a9e3d0b8549d/website/source/docs/agent/configuration/server.html.md (about)

     1  ---
     2  layout: "docs"
     3  page_title: "server Stanza - Agent Configuration"
     4  sidebar_current: "docs-agent-configuration-server"
     5  description: |-
     6    The "server" stanza configures the Nomad agent to operate in server mode to
     7    participate in scheduling decisions, register with service discovery, handle
     8    join failures, and more.
     9  ---
    10  
    11  # `server` Stanza
    12  
    13  <table class="table table-bordered table-striped">
    14    <tr>
    15      <th width="120">Placement</th>
    16      <td>
    17        <code>**server**</code>
    18      </td>
    19    </tr>
    20  </table>
    21  
    22  
    23  The `server` stanza configures the Nomad agent to operate in server mode to
    24  participate in scheduling decisions, register with service discovery, handle
    25  join failures, and more.
    26  
    27  ```hcl
    28  server {
    29    enabled          = true
    30    bootstrap_expect = 3
    31    retry_join       = ["1.2.3.4", "5.6.7.8"]
    32  }
    33  ```
    34  
    35  ## `server` Parameters
    36  
    37  - `bootstrap_expect` `(int: required)` - Specifies the number of server nodes to
    38    wait for before bootstrapping. It is most common to use the odd-numbered
    39    integers `3` or `5` for this value, depending on the cluster size. A value of
    40    `1` does not provide any fault tolerance and is not recommended for production
    41    use cases.
    42  
    43  - `data_dir` `(string: "[data_dir]/server")` - Specifies the directory to use -
    44    for server-specific data, including the replicated log. By default, this is -
    45    the top-level [data_dir](/docs/agent/configuration/index.html#data_dir)
    46    suffixed with "server", like `"/opt/nomad/server"`. This must be an absolute
    47    path.
    48  
    49  - `enabled` `(bool: false)` - Specifies if this agent should run in server mode.
    50    All other server options depend on this value being set.
    51  
    52  - `enabled_schedulers` `(array<string>: [all])` - Specifies which sub-schedulers
    53    this server will handle. This can be used to restrict the evaluations that
    54    worker threads will dequeue for processing.
    55  
    56  - `encrypt` `(string: "")` - Specifies the secret key to use for encryption of
    57    Nomad server's gossip network traffic. This key must be 16-bytes that are
    58    base64-encoded. The provided key is automatically persisted to the data
    59    directory and loaded automatically whenever the agent is restarted. This means
    60    that to encrypt Nomad server's gossip protocol, this option only needs to be
    61    provided once on each agent's initial startup sequence. If it is provided
    62    after Nomad has been initialized with an encryption key, then the provided key
    63    is ignored and a warning will be displayed. See the
    64    [Nomad encryption documentation][encryption] for more details on this option
    65    and its impact on the cluster.
    66  
    67  - `node_gc_threshold` `(string: "24h")` - Specifies how long a node must be in a
    68    terminal state before it is garbage collected and purged from the system. This
    69    is specified using a label suffix like "30s" or "1h".
    70  
    71  - `num_schedulers` `(int: [num-cores])` - Specifies the number of parallel
    72    scheduler threads to run. This can be as many as one per core, or `0` to
    73    disallow this server from making any scheduling decisions. This defaults to
    74    the number of CPU cores.
    75  
    76  - `protocol_version` `(int: 1)` - Specifies the Nomad protocol version to use
    77    when communicating with other Nomad servers. This value is typically not
    78    required as the agent internally knows the latest version, but may be useful
    79    in some upgrade scenarios.
    80  
    81  - `rejoin_after_leave` `(bool: false)` - Specifies if Nomad will ignore a
    82    previous leave and attempt to rejoin the cluster when starting. By default,
    83    Nomad treats leave as a permanent intent and does not attempt to join the
    84    cluster again when starting. This flag allows the previous state to be used to
    85    rejoin the cluster.
    86  
    87  - `retry_join` `(array<string>: [])` - Specifies a list of server addresses to
    88    retry joining if the first attempt fails. This is similar to
    89    [`start_join`](#start_join), but only invokes if the initial join attempt
    90    fails. The list of addresses will be tried in the order specified, until one
    91    succeeds. After one succeeds, no further addresses will be contacted. This is
    92    useful for cases where we know the address will become available eventually.
    93    Use `retry_join` with an array as a replacement for `start_join`, **do not use
    94    both options**. See the [server address format](#server-address-format)
    95    section for more information on the format of the string.
    96  
    97  - `retry_interval` `(string: "30s")` - Specifies the time to wait between retry
    98    join attempts.
    99  
   100  - `retry_max` `(int: 0)` - Specifies the maximum number of join attempts to be
   101    made before exiting with a return code of 1. By default, this is set to 0
   102    which is interpreted as infinite retries.
   103  
   104  - `start_join` `(array<string>: [])` - Specifies a list of server addresses to
   105    join on startup. If Nomad is unable to join with any of the specified
   106    addresses, agent startup will fail. See the
   107    [server address format](#server-address-format) section for more information
   108    on the format of the string.
   109  
   110  ### Server Address Format
   111  
   112  This section describes the acceptable syntax and format for describing the
   113  location of a Nomad server. There are many ways to reference a Nomad server,
   114  including directly by IP address and resolving through DNS.
   115  
   116  #### Directly via IP Address
   117  
   118  It is possible to address another Nomad server using its IP address. This is
   119  done in the `ip:port` format, such as:
   120  
   121  ```
   122  1.2.3.4:5678
   123  ```
   124  
   125  If the port option is omitted, it defaults to the Serf port, which is 4648
   126  unless configured otherwise:
   127  
   128  ```
   129  1.2.3.4 => 1.2.3.4:4648
   130  ```
   131  
   132  #### Via Domains or DNS
   133  
   134  It is possible to address another Nomad server using its DNS address. This is
   135  done in the `address:port` format, such as:
   136  
   137  ```
   138  nomad-01.company.local:5678
   139  ```
   140  
   141  If the port option is omitted, it defaults to the Serf port, which is 4648
   142  unless configured otherwise:
   143  
   144  ```
   145  nomad-01.company.local => nomad-01.company.local:4648
   146  ```
   147  
   148  ## `server` Examples
   149  
   150  ### Common Setup
   151  
   152  This example shows a common Nomad agent `server` configuration stanza. The two
   153  IP addresses could also be DNS, and should point to the other Nomad servers in
   154  the cluster
   155  
   156  ```hcl
   157  server {
   158    enabled          = true
   159    bootstrap_expect = 3
   160    retry_join       = ["1.2.3.4", "5.6.7.8"]
   161  }
   162  ```
   163  
   164  ### Configuring Data Directory
   165  
   166  This example shows configuring a custom data directory for the server data.
   167  
   168  ```hcl
   169  server {
   170    data_dir = "/opt/nomad/server"
   171  }
   172  ```
   173  
   174  ### Automatic Bootstrapping
   175  
   176  The Nomad servers can automatically bootstrap if Consul is configured. For a
   177  more detailed explanation, please see the
   178  [automatic Nomad bootstrapping documentation](/docs/cluster/automatic.html).
   179  
   180  ### Restricting Schedulers
   181  
   182  This example shows restricting the schedulers that are enabled as well as the
   183  maximum number of cores to utilize when participating in scheduling decisions:
   184  
   185  ```hcl
   186  server {
   187    enabled            = true
   188    enabled_schedulers = ["batch", "service"]
   189    num_schedulers     = 7
   190  }
   191  ```
   192  
   193  [encryption]: /docs/agent/encryption.html "Nomad Agent Encryption"