mirror of
https://github.com/kemko/nomad.git
synced 2026-01-03 08:55:43 +03:00
* 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>
105 lines
5.0 KiB
Plaintext
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/
|