Point users to security doc instead. Right now it takes a lot of explaining to describe to users exactly how to validate the binary and what the output of the tools used means. For example, this is the output when validating according to the instructions in this guide and the linked doc: ``` vagrant@linux:/tmp$ gpg --verify nomad_0.8.7_SHA256SUMS.sig nomad_0.8.7_SHA256SUMS gpg: Signature made Fri 11 Jan 2019 09:47:56 PM UTC using RSA key ID 348FFC4C gpg: Good signature from "HashiCorp Security <security@hashicorp.com>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 91A6 E7F8 5D05 C656 30BE F189 5185 2D87 348F FC4C vagrant@linux:/tmp$ shasum -a 256 -c nomad_0.8.7_SHA256SUMS shasum: ./nomad_0.8.7_darwin_amd64.zip: ./nomad_0.8.7_darwin_amd64.zip: FAILED open or read shasum: ./nomad_0.8.7_linux_386.zip: No such file or directory ./nomad_0.8.7_linux_386.zip: FAILED open or read shasum: ./nomad_0.8.7_linux_amd64-lxc.zip: No such file or directory ./nomad_0.8.7_linux_amd64-lxc.zip: FAILED open or read ./nomad_0.8.7_linux_amd64.zip: OK shasum: ./nomad_0.8.7_linux_arm64.zip: No such file or directory ./nomad_0.8.7_linux_arm64.zip: FAILED open or read shasum: ./nomad_0.8.7_linux_arm.zip: No such file or directory ./nomad_0.8.7_linux_arm.zip: FAILED open or read shasum: ./nomad_0.8.7_windows_386.zip: No such file or directory ./nomad_0.8.7_windows_386.zip: FAILED open or read shasum: ./nomad_0.8.7_windows_amd64.zip: No such file or directory ./nomad_0.8.7_windows_amd64.zip: FAILED open or read shasum: WARNING: 7 listed files could not be read ``` There are only two lines that matter in all of that output: ``` ... gpg: Good signature from "HashiCorp Security <security@hashicorp.com>" ... ./nomad_0.8.7_linux_amd64.zip: OK ... ``` I feel like trying to teach users how to use and interpret these tools in our deployment guide may be as likely to reduce confidence as increase it.
10 KiB
layout | page_title | sidebar_current | description | product_version |
---|---|---|---|---|
guides | Nomad Deployment Guide | guides-operations-deployment-guide | This deployment guide covers the steps required to install and configure a single HashiCorp Nomad cluster as defined in the Nomad Reference Architecture | 0.8 |
Nomad Deployment Guide
This deployment guide covers the steps required to install and configure a single HashiCorp Nomad cluster as defined in the Nomad Reference Architecture.
These instructions are for installing and configuring Nomad on Linux hosts running the systemd system and service manager.
Reference Material
This deployment guide is designed to work in combination with the Nomad Reference Architecture and Consul Deployment Guide. Although it is not a strict requirement to follow the Nomad Reference Architecture, please ensure you are familiar with the overall architecture design. For example, installing Nomad server agents on multiple physical or virtual (with correct anti-affinity) hosts for high-availability.
Overview
To provide a highly-available single cluster architecture, we recommend Nomad server agents be deployed to more than one host, as shown in the Nomad Reference Architecture.
These setup steps should be completed on all Nomad hosts:
Download Nomad
Precompiled Nomad binaries are available for download at https://releases.hashicorp.com/nomad/ and Nomad Enterprise binaries are available for download by following the instructions made available to HashiCorp Enterprise customers.
export NOMAD_VERSION="0.8.7"
curl --silent --remote-name https://releases.hashicorp.com/nomad/${NOMAD_VERSION}/nomad_${NOMAD_VERSION}_linux_amd64.zip
You may perform checksum verification of the zip packages using the SHA256SUMS and SHA256SUMS.sig files available for the specific release version. HashiCorp provides a guide on checksum verification for precompiled binaries.
Install Nomad
Unzip the downloaded package and move the nomad
binary to /usr/local/bin/
. Check nomad
is available on the system path.
unzip nomad_${NOMAD_VERSION}_linux_amd64.zip
sudo chown root:root nomad
sudo mv nomad /usr/local/bin/
nomad version
The nomad
command features opt-in autocompletion for flags, subcommands, and arguments (where supported). Enable autocompletion.
nomad -autocomplete-install
complete -C /usr/local/bin/nomad nomad
Create a data directory for Nomad.
sudo mkdir --parents /opt/nomad
Configure systemd
Systemd uses documented sane defaults so only non-default values must be set in the configuration file.
Create a Nomad service file at /etc/systemd/system/nomad.service
.
sudo touch /etc/systemd/system/nomad.service
Add this configuration to the Nomad service file:
[Unit]
Description=Nomad
Documentation=https://nomadproject.io/docs/
Wants=network-online.target
After=network-online.target
[Service]
ExecReload=/bin/kill -HUP $MAINPID
ExecStart=/usr/local/bin/nomad agent -config /etc/nomad.d
KillMode=process
KillSignal=SIGINT
LimitNOFILE=infinity
LimitNPROC=infinity
Restart=on-failure
RestartSec=2
StartLimitBurst=3
StartLimitIntervalSec=10
TasksMax=infinity
[Install]
WantedBy=multi-user.target
The following parameters are set for the [Unit]
stanza:
Description
- Free-form string describing the nomad serviceDocumentation
- Link to the nomad documentationWants
- Configure a dependency on the network serviceAfter
- Configure an ordering dependency on the network service being started before the nomad service
The following parameters are set for the [Service]
stanza:
ExecReload
- Send Nomad aSIGHUP
signal to trigger a configuration reloadExecStart
- Start Nomad with theagent
argument and path to a directory of configuration filesKillMode
- Treat nomad as a single processLimitNOFILE
,LimitNPROC
- Disable limits for file descriptors and processesRestartSec
- Restart nomad after 2 seconds of it being considered 'failed'Restart
- Restart nomad unless it returned a clean exit codeStartLimitBurst
,StartLimitIntervalSec
- Configure unit start rate limitingTasksMax
- Disable task limits (only available in systemd >= 226)
The following parameters are set for the [Install]
stanza:
WantedBy
- Creates a weak dependency on nomad being started by the multi-user run level
Configure Nomad
Nomad uses documented sane defaults so only non-default values must be set in the configuration file. Configuration can be read from multiple files and is loaded in lexical order. See the full description for more information about configuration loading and merge semantics.
Some configuration settings are common to both server and client Nomad agents, while some configuration settings must only exist on one or the other. Follow the common configuration guidance on all hosts and then the specific guidance depending on whether you are configuring a Nomad server or client.
Common configuration
Create a configuration file at /etc/nomad.d/nomad.hcl
:
sudo mkdir --parents /etc/nomad.d
sudo chmod 700 /etc/nomad.d
sudo touch /etc/nomad.d/nomad.hcl
Add this configuration to the nomad.hcl
configuration file:
~> Note: Replace the datacenter
parameter value with the identifier you will use for the datacenter this Nomad cluster is deployed in.
datacenter = "dc1"
data_dir = "/opt/nomad"
datacenter
- The datacenter in which the agent is running.data_dir
- The data directory for the agent to store state.
Server configuration
Create a configuration file at /etc/nomad.d/server.hcl
:
sudo touch /etc/nomad.d/server.hcl
Add this configuration to the server.hcl
configuration file:
~> NOTE Replace the bootstrap_expect
value with the number of Nomad servers you will use; three or five is recommended.
server {
enabled = true
bootstrap_expect = 3
}
server
- Specifies if this agent should run in server mode. All other server options depend on this value being set.bootstrap_expect
- The number of expected servers in the cluster. Either this value should not be provided or the value must agree with other servers in the cluster.
Client configuration
Create a configuration file at /etc/nomad.d/client.hcl
:
sudo touch /etc/nomad.d/client.hcl
Add this configuration to the client.hcl
configuration file:
client {
enabled = true
}
client
- Specifies if this agent should run in client mode. All other client options depend on this value being set.
~> NOTE The options
parameter can be used to enable or disable specific configurations on Nomad clients, unique to your use case requirements.
ACL configuration
The Access Control guide provides instructions on configuring and enabling ACLs.
TLS configuration
Securing Nomad's cluster communication with mutual TLS (mTLS) is recommended for production deployments and can even ease operations by preventing mistakes and misconfigurations. Nomad clients and servers should not be publicly accessible without mTLS enabled.
The Securing Nomad with TLS guide provides instructions on configuring and enabling TLS.
Start Nomad
Enable and start Nomad using the systemctl command responsible for controlling systemd managed services. Check the status of the nomad service using systemctl.
sudo systemctl enable nomad
sudo systemctl start nomad
sudo systemctl status nomad
Next Steps
- Read Outage Recovery to learn the steps required to recover from a Nomad cluster outage.
- Read Autopilot to learn about features in Nomad 0.8 to allow for automatic operator-friendly management of Nomad servers.