Files
nomad/website/content/docs/faq.mdx
Aimee Ukasick 53b083b8c5 Docs: Nomad IA (#26063)
* Move commands from docs to its own root-level directory

* temporarily use modified dev-portal branch with nomad ia changes

* explicitly clone nomad ia exp branch

* retrigger build, fixed dev-portal broken build

* architecture, concepts and get started individual pages

* fix get started section destinations

* reference section

* update repo comment in website-build.sh to show branch

* docs nav file update capitalization

* update capitalization to force deploy

* remove nomad-vs-kubernetes dir; move content to what is nomad pg

* job section

* Nomad operations category, deploy section

* operations category, govern section

* operations - manage

* operations/scale; concepts scheduling fix

* networking

* monitor

* secure section

* remote auth-methods folder and move up pages to sso; linkcheck

* Fix install2deploy redirects

* fix architecture redirects

* Job section: Add missing section index pages

* Add section index pages so breadcrumbs build correctly

* concepts/index fix front matter indentation

* move task driver plugin config to new deploy section

* Finish adding full URL to tutorials links in nav

* change SSO to Authentication in nav and file system

* Docs NomadIA: Move tutorials into NomadIA branch (#26132)

* Move governance and policy from tutorials to docs

* Move tutorials content to job-declare section

* run jobs section

* stateful workloads

* advanced job scheduling

* deploy section

* manage section

* monitor section

* secure/acl and secure/authorization

* fix example that contains an unseal key in real format

* remove images from sso-vault

* secure/traffic

* secure/workload-identities

* vault-acl change unseal key and root token in command output sample

* remove lines from sample output

* fix front matter

* move nomad pack tutorials to tools

* search/replace /nomad/tutorials links

* update acl overview with content from deleted architecture/acl

* fix spelling mistake

* linkcheck - fix broken links

* fix link to Nomad variables tutorial

* fix link to Prometheus tutorial

* move who uses Nomad to use cases page; move spec/config shortcuts

add dividers

* Move Consul out of Integrations; move namespaces to govern

* move integrations/vault to secure/vault; delete integrations

* move ref arch to docs; rename Deploy Nomad back to Install Nomad

* address feedback

* linkcheck fixes

* Fixed raw_exec redirect

* add info from /nomad/tutorials/manage-jobs/jobs

* update page content with newer tutorial

* link updates for architecture sub-folders

* Add redirects for removed section index pages. Fix links.

* fix broken links from linkcheck

* Revert to use dev-portal main branch instead of nomadIA branch

* build workaround: add intro-nav-data.json with single entry

* fix content-check error

* add intro directory to get around Vercel build error

* workound for emtpry directory

* remove mdx from /intro/ to fix content-check and git snafu

* Add intro index.mdx so Vercel build should work

---------

Co-authored-by: Tu Nguyen <im2nguyen@gmail.com>
2025-07-08 19:24:52 -05:00

105 lines
5.0 KiB
Plaintext

---
layout: docs
page_title: Frequently Asked Questions
description: Nomad frequently asked question topics include checkpoint, gossip and consensus protocols, Nomad datacenter versus Consul datacenter, bootstrapping a cluster, and connecting to a host network with Docker Desktop.
---
# Frequently Asked Questions
## Q: What is Checkpoint? / Does Nomad call home?
Nomad makes use of a HashiCorp service called [Checkpoint](https://checkpoint.hashicorp.com)
which is used to check for updates and critical security bulletins.
Only anonymous information, which cannot be used to identify the user or host, is
sent to Checkpoint. An anonymous ID is sent which helps de-duplicate warning messages.
This anonymous ID can be disabled. Using the Checkpoint service is optional and can be disabled.
See [`disable_anonymous_signature`](/nomad/docs/configuration#disable_anonymous_signature)
and [`disable_update_check`](/nomad/docs/configuration#disable_update_check).
## Q: Is Nomad eventually or strongly consistent?
Nomad makes use of both a [consensus protocol](/nomad/docs/architecture/cluster/consensus) and
a [gossip protocol](/nomad/docs/architecture/security/gossip). The consensus protocol is strongly
consistent, and is used for all state replication and scheduling. The gossip protocol
is used to manage the addresses of servers for automatic clustering and multi-region
federation. This means all data that is managed by Nomad is strongly consistent.
## Q: Is Nomad's `datacenter` parameter the same as Consul's?
No. For those familiar with Consul, [Consul's notion of a
datacenter][consul_dc] is more equivalent to a [Nomad region][nomad_region].
Nomad supports grouping nodes into multiple datacenters, which should reflect
nodes being colocated, while being managed by a single set of Nomad servers.
Consul on the other hand does not have this two-tier approach to servers and
agents and instead [relies on federation to create larger logical
clusters][consul_fed].
## Q: What is "bootstrapping" a Nomad cluster? ((#bootstrapping))
Bootstrapping is the process when a Nomad cluster elects its first leader
and writes the initial cluster state to that leader's state store. Bootstrapping
will not occur until at least a given number of servers, defined by
[`bootstrap_expect`], have connected to each other. Once this process has
completed, the cluster is said to be bootstrapped and is ready to use.
Certain configuration options are only used to influence the creation of the
initial cluster state during bootstrapping and are not consulted again so long
as the state data remains intact. These typically are values that must be
consistent across server members. For example, the [`default_scheduler_config`]
option allows an operator to set the SchedulerConfig to non-default values
during this bootstrap process rather than requiring an immediate call to the API
once the cluster is up and running.
If the state is completely destroyed, whether intentionally or accidentally, on
all of the Nomad servers in the same outage, the cluster will re-bootstrap based
on the Nomad defaults and any configuration present that impacts the bootstrap
process.
## Q: How to connect to my host network when using Docker Desktop (Windows and MacOS)?
Since Docker is based on Linux-native technologies, Docker Desktop for Windows
and MacOS uses a small Linux virtual machine to run containers. This extra step
adds a layer of indirection between the network of your host (the computer you
are currently using) and the network of the VM running your containers.
This means that, by default, your Docker tasks will not be able to access
endpoints that are available in your host network, such as a local Consul agent.
In order to properly setup this connection you will need to explicitly bind
the Nomad client to a non-loopback network interface, and anything else you
would like to access must also be in the same interface.
On Windows, we recommend you to start with the [WSL2 backend for Docker
Desktop][wsl2-docker]. Once you are more familiarized with Nomad you can start
running it natively.
To use the network named `en0` that has the IP address `192.168.0.10`, you can
start Nomad with this command.
```shell-session
$ sudo nomad agent -dev -bind=0.0.0.0 -network-interface=en0
```
To start Consul in the same network, you can run this command.
```shell-session
$ consul agent -dev -client=0.0.0.0 -bind=192.168.0.10
```
Now your services will be registered in Consul using the right IP and your
tasks will be able to reach each other. To access your tasks from your host
machine you will need to use the network interface IP address.
```shell-session
$ curl http://192.168.0.10:8080
```
[consul_dc]: /consul/docs/agent/config/config-files#datacenter
[consul_fed]: /consul/tutorials/networking/federation-gossip-wan
[nomad_region]: /nomad/docs/configuration#datacenter
[`bootstrap_expect`]: /nomad/docs/configuration/server#bootstrap_expect
[`default_scheduler_config`]: /nomad/docs/configuration/server#default_scheduler_config
[wsl2-docker]: https://docs.docker.com/docker-for-windows/wsl/