2017-11-15 19:40:34 +00:00
|
|
|
# Provision a Nomad cluster in the Cloud
|
2017-06-15 22:49:02 +00:00
|
|
|
|
2020-07-16 19:58:42 +00:00
|
|
|
Use this repo to easily provision a Nomad sandbox environment on AWS, Azure, or GCP with
|
2017-06-25 17:45:30 +00:00
|
|
|
[Packer](https://packer.io) and [Terraform](https://terraform.io).
|
|
|
|
[Consul](https://www.consul.io/intro/index.html) and
|
|
|
|
[Vault](https://www.vaultproject.io/intro/index.html) are also installed
|
|
|
|
(colocated for convenience). The intention is to allow easy exploration of
|
2017-06-26 17:51:59 +00:00
|
|
|
Nomad and its integrations with the HashiCorp stack. This is *not* meant to be
|
|
|
|
a production ready environment. A demonstration of [Nomad's Apache Spark
|
2017-06-25 17:45:30 +00:00
|
|
|
integration](examples/spark/README.md) is included.
|
2017-06-15 22:49:02 +00:00
|
|
|
|
|
|
|
## Setup
|
|
|
|
|
2017-11-15 19:40:34 +00:00
|
|
|
Clone the repo and optionally use [Vagrant](https://www.vagrantup.com/intro/index.html)
|
2017-06-25 17:45:30 +00:00
|
|
|
to bootstrap a local staging environment:
|
2017-06-15 22:49:02 +00:00
|
|
|
|
|
|
|
```bash
|
|
|
|
$ git clone git@github.com:hashicorp/nomad.git
|
2018-06-05 15:29:57 +00:00
|
|
|
$ cd nomad/terraform
|
2017-06-15 22:49:02 +00:00
|
|
|
$ vagrant up && vagrant ssh
|
|
|
|
```
|
|
|
|
|
2017-11-15 19:40:34 +00:00
|
|
|
The Vagrant staging environment pre-installs Packer, Terraform, Docker and the
|
|
|
|
Azure CLI.
|
2017-06-15 22:49:02 +00:00
|
|
|
|
2017-06-24 23:50:11 +00:00
|
|
|
## Provision a cluster
|
2017-06-15 22:49:02 +00:00
|
|
|
|
2017-11-15 22:18:49 +00:00
|
|
|
- Follow the steps [here](aws/README.md) to provision a cluster on AWS.
|
|
|
|
- Follow the steps [here](azure/README.md) to provision a cluster on Azure.
|
2020-07-16 19:58:42 +00:00
|
|
|
- Follow the steps [here](gcp/README.md) to provision a cluster on GCP.
|
2017-06-15 22:49:02 +00:00
|
|
|
|
2017-11-15 19:40:34 +00:00
|
|
|
Continue with the steps below after a cluster has been provisioned.
|
2017-06-15 22:49:02 +00:00
|
|
|
|
2017-11-15 19:40:34 +00:00
|
|
|
## Test
|
2017-06-15 22:49:02 +00:00
|
|
|
|
2017-11-15 19:40:34 +00:00
|
|
|
Run a few basic status commands to verify that Consul and Nomad are up and running
|
2017-06-25 17:45:30 +00:00
|
|
|
properly:
|
2017-06-15 22:49:02 +00:00
|
|
|
|
|
|
|
```bash
|
|
|
|
$ consul members
|
2018-06-05 16:35:03 +00:00
|
|
|
$ nomad server members
|
2018-11-14 04:21:01 +00:00
|
|
|
$ nomad node status
|
2017-06-15 22:49:02 +00:00
|
|
|
```
|
|
|
|
|
2017-11-15 19:40:34 +00:00
|
|
|
## Unseal the Vault cluster (optional)
|
|
|
|
|
|
|
|
To initialize and unseal Vault, run:
|
2017-06-15 22:49:02 +00:00
|
|
|
|
|
|
|
```bash
|
2018-06-05 16:37:06 +00:00
|
|
|
$ vault operator init -key-shares=1 -key-threshold=1
|
2018-11-14 04:21:01 +00:00
|
|
|
$ vault operator unseal
|
2017-06-15 22:49:02 +00:00
|
|
|
$ export VAULT_TOKEN=[INITIAL_ROOT_TOKEN]
|
|
|
|
```
|
|
|
|
|
2017-06-25 17:45:30 +00:00
|
|
|
The `vault init` command above creates a single
|
|
|
|
[Vault unseal key](https://www.vaultproject.io/docs/concepts/seal.html) for
|
|
|
|
convenience. For a production environment, it is recommended that you create at
|
|
|
|
least five unseal key shares and securely distribute them to independent
|
|
|
|
operators. The `vault init` command defaults to five key shares and a key
|
|
|
|
threshold of three. If you provisioned more than one server, the others will
|
2017-11-15 19:40:34 +00:00
|
|
|
become standby nodes but should still be unsealed. You can query the active
|
2017-06-25 17:45:30 +00:00
|
|
|
and standby nodes independently:
|
2017-06-25 17:09:28 +00:00
|
|
|
|
|
|
|
```bash
|
|
|
|
$ dig active.vault.service.consul
|
|
|
|
$ dig active.vault.service.consul SRV
|
|
|
|
$ dig standby.vault.service.consul
|
2017-11-15 19:40:34 +00:00
|
|
|
```
|
|
|
|
|
|
|
|
See the [Getting Started guide](https://www.vaultproject.io/intro/getting-started/first-secret.html)
|
|
|
|
for an introduction to Vault.
|
2017-06-15 22:49:02 +00:00
|
|
|
|
|
|
|
## Getting started with Nomad & the HashiCorp stack
|
|
|
|
|
2017-11-15 19:40:34 +00:00
|
|
|
Use the following links to get started with Nomad and its HashiCorp integrations:
|
2017-06-15 22:49:02 +00:00
|
|
|
|
2017-06-16 21:46:51 +00:00
|
|
|
* [Getting Started with Nomad](https://www.nomadproject.io/intro/getting-started/jobs.html)
|
|
|
|
* [Consul integration](https://www.nomadproject.io/docs/service-discovery/index.html)
|
|
|
|
* [Vault integration](https://www.nomadproject.io/docs/vault-integration/index.html)
|
2017-11-15 19:40:34 +00:00
|
|
|
* [consul-template integration](https://www.nomadproject.io/docs/job-specification/template.html)
|
2017-06-15 22:49:02 +00:00
|
|
|
|
|
|
|
## Apache Spark integration
|
|
|
|
|
2017-06-25 17:45:30 +00:00
|
|
|
Nomad is well-suited for analytical workloads, given its performance
|
|
|
|
characteristics and first-class support for batch scheduling. Apache Spark is a
|
|
|
|
popular data processing engine/framework that has been architected to use
|
2017-06-26 17:51:59 +00:00
|
|
|
third-party schedulers. The Nomad ecosystem includes a [fork that natively
|
|
|
|
integrates Nomad with Spark](https://github.com/hashicorp/nomad-spark). A
|
|
|
|
detailed walkthrough of the integration is included [here](examples/spark/README.md).
|