Minor updates to intro and vs. content; update use cases
This commit is contained in:
Rob Genova
Preetha Appan
parent
f10155f285
commit
0be66f4de1
|
|
@ -15,14 +15,17 @@ to use to improve your environment.
|
|||
We've covered the basics of all the core features of Nomad in this guide.
|
||||
We recommend exploring the following resources as next steps.
|
||||
|
||||
* [Documentation](/docs/index.html) - The documentation is an in-depth
|
||||
reference guide to all the features of Nomad.
|
||||
* [Guides](/guides/index.html) - The Guides provide best practices and
|
||||
guidance for using and operating Nomad in a real-world production setting.
|
||||
|
||||
* [Creating a Cluster](/guides/cluster/bootstrapping.html) - Additional details on
|
||||
creating a production worthy Nomad Cluster.
|
||||
* [Docs](/docs/index.html) - The Docs provide detailed reference information
|
||||
all available features and options of Nomad.
|
||||
|
||||
* [Operating a Job](/guides/operating-a-job/index.html) - Additional details on how to
|
||||
run a job in production.
|
||||
* [Job Lifecycle](/guides/operating-a-job/index.html) - Additional details
|
||||
specific to runnning a job in production.
|
||||
|
||||
* [Creating a Cluster](/guides/operations/cluster/bootstrapping.html) - Additional
|
||||
details on creating a production worthy Nomad Cluster.
|
||||
|
||||
* [Example Terraform configuration](https://github.com/hashicorp/nomad/tree/master/terraform) -
|
||||
Use Terraform to automatically provision a cluster in AWS.
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ Additional metadata can be viewed by providing the `-detailed` flag.
|
|||
|
||||
You can use `Ctrl-C` (the interrupt signal) to halt the agent.
|
||||
By default, all signals will cause the agent to forcefully shutdown.
|
||||
The agent [can be configured](/docs/agent/configuration/index.html#leave_on_terminate) to
|
||||
The agent [can be configured](/docs/configuration/index.html#leave_on_terminate) to
|
||||
gracefully leave on either the interrupt or terminate signals.
|
||||
|
||||
After interrupting the agent, you should see it leave the cluster
|
||||
|
|
@ -134,7 +134,7 @@ replication continues to be attempted until the node recovers. Nomad will
|
|||
automatically try to reconnect to _failed_ nodes, allowing it to recover from
|
||||
certain network conditions, while _left_ nodes are no longer contacted.
|
||||
|
||||
If an agent is operating as a server, [`leave_on_terminate`](/docs/agent/configuration/index.html#leave_on_terminate) should only
|
||||
If an agent is operating as a server, [`leave_on_terminate`](/docs/configuration/index.html#leave_on_terminate) should only
|
||||
be set if the server will never rejoin the cluster again. The default value of `false` for `leave_on_terminate` and `leave_on_interrupt`
|
||||
work well for most scenarios. If Nomad servers are part of an auto scaling group where new servers are brought up to replace
|
||||
failed servers, using graceful leave avoids causing a potential availability outage affecting the [consensus protocol](/docs/internals/consensus.html).
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
layout: "intro"
|
||||
page_title: "Nomad Web UI"
|
||||
page_title: "Web UI"
|
||||
sidebar_current: "getting-started-ui"
|
||||
description: |-
|
||||
Visit the Nomad Web UI to inspect jobs, allocations, and more.
|
||||
---
|
||||
|
||||
# Nomad Web UI
|
||||
# Web UI
|
||||
|
||||
At this point we have a fully functioning cluster with a job running in it. We have
|
||||
learned how to inspect a job using `nomad status`, next we'll learn how to inspect
|
||||
|
|
|
|||
|
|
@ -13,16 +13,37 @@ place to start with Nomad. We cover what Nomad is, what
|
|||
problems it can solve, how it compares to existing software,
|
||||
and contains a quick start for using Nomad.
|
||||
|
||||
If you are already familiar with the basics of Nomad, the
|
||||
[documentation](/docs/index.html) provides a better reference
|
||||
guide for all available features as well as internals.
|
||||
If you are already familiar with the basics of Nomad, the [Guides](/guides/index.html)
|
||||
and the [reference documentation](/docs/index.html) will provide a more comprehensive
|
||||
resource.
|
||||
|
||||
## What is Nomad?
|
||||
|
||||
Nomad is a tool for managing a cluster of machines and running applications
|
||||
Nomad is a flexible container orchestration tool that enables an organization to
|
||||
easily deploy and manage any containerized or legacy application using a single,
|
||||
unified workflow. Nomad can run a diverse workload of Docker, non-containerized,
|
||||
microservice, and batch applications, and generally offers the following benefits
|
||||
to developers and operators:
|
||||
|
||||
* **API-driven Automation**: Workload placement, scaling, and upgrades can be
|
||||
automated, simplifying operations and eliminating the need for homegrown tooling.
|
||||
* **Self-service Deployments**: Developers are empowered to service application
|
||||
lifecycles directly, allowing operators to focus on higher value tasks.
|
||||
* **Workload Reliability**: Application, node, and driver failures are handled
|
||||
automatically, reducing the need for manual operator intervention
|
||||
* **Increased Efficiency and Reduced Cost**: Higher application densities allow
|
||||
operators to reduce fleet sizes and save money.
|
||||
|
||||
Nomad is trusted by enterprises from a range of sectors including financial,
|
||||
retail, software, and others to run production workloads at scale across private
|
||||
infrastructure and the public cloud.
|
||||
|
||||
## How it Works
|
||||
|
||||
At its core, Nomad is a tool for managing a cluster of machines and running applications
|
||||
on them. Nomad abstracts away machines and the location of applications,
|
||||
and instead enables users to declare what they want to run and Nomad handles
|
||||
where they should run and how to run them.
|
||||
and instead enables users to declare what they want to run while Nomad handles
|
||||
where and how to run them.
|
||||
|
||||
The key features of Nomad are:
|
||||
|
||||
|
|
@ -57,6 +78,15 @@ The key features of Nomad are:
|
|||
to support demanding workloads. Nomad has been proven to scale to cluster sizes that
|
||||
exceed 10k nodes in real-world production environments.
|
||||
|
||||
## How Nomad Compares to Other Tools
|
||||
|
||||
Nomad differentiates from related tools by virtue of its **simplicity**, **flexibility**,
|
||||
**scalability**, and **high performance**. Nomad's synergy and integration points with
|
||||
HashiCorp Terrform, Consul, and Vault make it uniquely suited for easy integration into
|
||||
an organization's existing workflows, minimizing the time-to-market for critical initiatives.
|
||||
See the [Nomad vs. Other Software](/intro/vs/index.html) page for additional details and
|
||||
comparisons.
|
||||
|
||||
## Next Steps
|
||||
|
||||
See the page on [Nomad use cases](/intro/use-cases.html) to see the
|
||||
|
|
|
|||
|
|
@ -3,35 +3,70 @@ layout: "intro"
|
|||
page_title: "Use Cases"
|
||||
sidebar_current: "use-cases"
|
||||
description: |-
|
||||
This page lists some concrete use cases for Nomad, but the possible use cases are much broader than what we cover.
|
||||
This page lists some concrete use cases for Nomad, but the possible use cases
|
||||
are much broader than what we cover.
|
||||
---
|
||||
|
||||
# Use Cases
|
||||
|
||||
Before understanding use cases, it's useful to know [what Nomad is](/intro/index.html).
|
||||
This page lists some concrete use cases for Nomad, but the possible use cases are
|
||||
much broader than what we cover.
|
||||
This page lists Nomad's core use cases. Please note that the full range of potential
|
||||
use cases is much broader than what is currently covered here. Reading through the
|
||||
[Introduction to Nomad](/intro/index.html) is highly recommended before diving into
|
||||
the use cases.
|
||||
|
||||
## Microservices Platform
|
||||
## Docker Container Management
|
||||
|
||||
Microservices, or Service Oriented Architectures (SOA), are a design paradigm in which many
|
||||
services with narrow scope, tight state encapsulation, and API driven interfaces interact together
|
||||
to form a larger application. However, they add an operational challenge of managing hundreds
|
||||
or thousands of services instead of a few large applications. Nomad provides a platform for
|
||||
managing microservices, making it easier to adopt the paradigm.
|
||||
Organizations are increasingly moving towards a Docker centric workflow for
|
||||
application deployment and management. This transition requires new tooling
|
||||
to automate placement, perform job updates, enable self-service for developers,
|
||||
and to handle failures automatically. Nomad supports a [first-class Docker workflow](/docs/drivers/docker.html)
|
||||
and integrates seamlessly with [Consul](/guides/operations/consul-integration/index.html)
|
||||
and [Vault](/guides/operations/vault-integration/index.html) to enable a complete solution
|
||||
while maximizing operational flexibility. Nomad is easy to use, can scale to
|
||||
thousands of nodes in a single cluster, and can easily deploy across private data
|
||||
centers and multiple clouds.
|
||||
|
||||
## Hybrid Cloud Deployments
|
||||
## Legacy Application Deployment
|
||||
|
||||
Nomad is designed to handle multi-datacenter and multi-region deployments and is cloud agnostic.
|
||||
This allows Nomad to schedule in private datacenters running bare metal, OpenStack, or VMware
|
||||
alongside an AWS, Azure, or GCE cloud deployment. This makes it easier to migrate workloads
|
||||
incrementally, or to utilize the cloud for bursting.
|
||||
A virtual machine based application deployment strategy can lead to low hardware
|
||||
utlization rates and high infrastructure costs. While a Docker-based deployment
|
||||
strategy can be impractical for some organizations or use cases, the potential for
|
||||
greater automation, increased resilience, and reduced cost is very attractive.
|
||||
Nomad natively supports running legacy applications, static binaries, JARs, and
|
||||
simple OS commands directly. Workloads are natively isolated at runtime and bin
|
||||
packed to maximize efficiency and utilization (reducing cost). Developers and
|
||||
operators benefit from API-driven automation and enhanced reliability for
|
||||
applications through automatic failure handling.
|
||||
|
||||
## Microservices
|
||||
|
||||
Microservices and Service Oriented Architectures (SOA) are a design paradigm in
|
||||
which many services with narrow scope, tight state encapsulation, and API driven
|
||||
communication interact together to form a larger solution. However, managing hundreds
|
||||
or thousands of services instead of a few large applications creates an operational
|
||||
challenge. Nomad elegantly integrates with [Consul](/guides/operations/consul-integration/index.html)
|
||||
for automatic service registration and dynamic rendering of configuration files. Nomad
|
||||
and Consul together provide an ideal solution for managing microservices, making it
|
||||
easier to adopt the paradigm.
|
||||
|
||||
## Batch Processing Workloads
|
||||
|
||||
As data science and analytics teams grow is size and complexity, they increasingly
|
||||
benefit from highly performant and scalable tools that can run batch workloads with
|
||||
minimal operational overhead. Nomad can natively run batch jobs, [parameterized](https://www.hashicorp.com/blog/replacing-queues-with-nomad-dispatch) jobs, and [Spark](https://github.com/hashicorp/nomad-spark)
|
||||
workloads. Nomad's architecture enables easy scalability and an optimistically
|
||||
concurrent scheduling strategy that can yield [thousands of container deployments per
|
||||
second](https://www.hashicorp.com/c1m). Alternatives are overly complex and limited
|
||||
in terms of their scheduling throughput, scalability, and multi-cloud capabilities.
|
||||
|
||||
**Related video**: [End to End Production Nomad at Citadel](https://www.youtube.com/watch?reload=9&v=ZOBcGpGsboA)
|
||||
|
||||
## Multi-region and Multi-cloud Deployments
|
||||
|
||||
Nomad is designed to natively handle multi-datacenter and multi-region deployments
|
||||
and is cloud agnostic. This allows Nomad to schedule in private datacenters running
|
||||
bare metal, OpenStack, or VMware alongside an AWS, Azure, or GCE cloud deployment.
|
||||
This makes it easier to migrate workloads incrementally and to utilize the cloud
|
||||
for bursting.
|
||||
|
||||
## E-Commerce
|
||||
|
||||
A typical E-Commerce website has a few types of workloads. There are long-lived services
|
||||
used for web serving. These include the load balancer, web frontends, API servers, and OLTP databases.
|
||||
Batch processing using Hadoop or Spark may run periodically for business reporting, user targeting,
|
||||
or generating product recommendations. Nomad allows all these workloads to share an underlying cluster,
|
||||
increasing utilization, reducing cost, simplifying scaling and providing a clean abstraction
|
||||
for developers.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,29 @@ description: |-
|
|||
|
||||
# Nomad vs. Other Software
|
||||
|
||||
Nomad is a cluster manager and scheduler. There are many related categories
|
||||
including cluster managers, resource managers, workload managers, and schedulers.
|
||||
There are many existing tools in each category, and the comparisons are not exhaustive
|
||||
of the entire space.
|
||||
The following characteristics generally differentiate Nomad from related products:
|
||||
|
||||
Due to the bias of the comparisons being on the Nomad website, we attempt
|
||||
to only use facts. If you find something that is invalid or out of date
|
||||
in the comparisons, please
|
||||
[open an issue](https://github.com/hashicorp/nomad/issues) and we'll
|
||||
* **Simplicity**: Nomad runs as a single process with zero external dependencies.
|
||||
Operators can easily provision, manage, and scale Nomad. Developers can easily
|
||||
define and run applications.
|
||||
* **Flexibility**: Nomad can run a diverse workload of containerized, legacy,
|
||||
microservice, and batch applications. Nomad can schedule service, batch
|
||||
processing and system jobs, and can run on both Linux and Windows.
|
||||
* **Scalability and High Performance**: Nomad can schedule thousands of containers
|
||||
per second, scale to thousands of nodes in a single cluster, and easily federate
|
||||
across regions and cloud providers.
|
||||
* **HashiCorp Synergy**: Nomad elegantly integrates with Vault for secrets
|
||||
management and Consul for service discovery and dynamic configuration. Nomad's
|
||||
Consul-like architecture and Terraform-like job specification lower the barrier
|
||||
to entry for existing users of the HashiCorp stack.
|
||||
|
||||
There are many relevant categories for comparison including cluster managers,
|
||||
resource managers, workload managers, and schedulers. There are many existing
|
||||
tools in each category, and the comparisons are not exhaustive of the entire space.
|
||||
|
||||
Due to the bias of the comparisons being on the Nomad website, we attempt to only
|
||||
use facts. If you find something that is invalid or out of date in the comparisons,
|
||||
please [open an issue](https://github.com/hashicorp/nomad/issues) and we will
|
||||
address it as soon as possible.
|
||||
|
||||
Use the navigation on the left to read comparisons of Nomad versus other
|
||||
systems.
|
||||
Use the navigation on the left to read comparisons of Nomad versus other systems.
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@
|
|||
</li>
|
||||
|
||||
<li<%= sidebar_current("getting-started-ui") %>>
|
||||
<a href="/intro/getting-started/ui.html">Nomad UI</a>
|
||||
<a href="/intro/getting-started/ui.html">Web UI</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("getting-started-nextsteps") %>>
|
||||
|
|
|
|||
Loading…
Reference in a new issue