kemko/nomad
1
0
Fork 0
mirror of https://github.com/kemko/nomad.git synced 2026-01-06 10:25:42 +03:00
Code Issues Packages Projects Releases Wiki Activity

Copy changes from review

Browse Source
This commit is contained in:
Michael Lange
2019-10-02 16:54:38 -07:00
parent f26f959bb3
commit d7861cf83e
3 changed files with 17 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
website/source/guides/web-ui/inspecting-the-cluster.html.md
View File

@@ -8,7 +8,7 @@ description: |-
# Inspecting the Cluster
The Web UI can be a powerful tool for keeping tabs on the state of the Nomad cluster from an
The Web UI can be a powerful tool for monitoring the state of the Nomad cluster from an
operator's perspective. This includes showing all client nodes, showing driver health for client nodes,
driver status, resource utilization, allocations by client node, and more.
@@ -110,11 +110,10 @@ details of how the drain is performed.
## Reviewing All Servers
Where client nodes are used to run your jobs, server nodes are used to run Nomad and maintain
Whereas client nodes are used to run your jobs, server nodes are used to run Nomad and maintain
availability. From any page, the Servers List page can be accessed from the left-hand navbar.
Here you can see every server node. This will be a small list—typically three, but maybe five or
seven.
Here you can see every server node. This will be a small list—[typically three or five](/docs/internals/consensus.html#deployment-table).
[![Servers List][img-servers-list]][img-servers-list]
@@ -128,9 +127,8 @@ Clicking a server node on the Servers List will expand the tags table for the se
Depending on the size of your team and the details of you Nomad deployment, you may wish to control
which features different internal users have access to. This includes limiting who has access to see
and manage client nodes and see and manage server nodes.
Nomad has an access contro list system for doing just that.
and manage client nodes and see and manage server nodes. You can enforce this with Nomad's access
control list system.
By default, all features—read and write—are available to all users of the Web UI. Check out the
[Securing the Web UI with ACLs](/guides/web-ui/securing.html) guide to learn how to prevent

20
website/source/guides/web-ui/operating-a-job.html.md
View File

@@ -10,7 +10,7 @@ description: |-
The Web UI can be a powerful companion when monitoring and debugging jobs running in Nomad. The Web
UI will list all jobs, link jobs to allocations, allocations to client nodes, client nodes to driver
health, and much more. This creates a fluid exploratory experience.
health, and much more.
## Reviewing All Jobs
@@ -65,8 +65,7 @@ Task events are listed on the Task Detail page and live-update as Nomad handles
### Rescheduled Allocations
Allocations will be placed on any client node that satisfies the constraints of the job definition.
However, just because a node sounds like a good fit doesn't mean there isn't the possibility of
unforeseen hostility, (e.g., corrupted `/bin`, no access to a container registry).
There are events, however, that will cause Nomad to reschedule allocations, (e.g., node failures).
Allocations can be configured [in the job definition to reschedule](/docs/job-specification/reschedule.html)
to a different client node if the allocation ends in a failed status. This will happen after the
@@ -74,7 +73,7 @@ task has exhausted its [local restart attempts](/docs/job-specification/restart.
The end result of this automatic procedure is a failed allocation and that failed allocation's
rescheduled successor. Since Nomad handles all of this automatically, the Web UI makes sure to
explain the state of allocations through iconography and linking previous and next allocations in a
explain the state of allocations through icons and linking previous and next allocations in a
reschedule chain.
[![Allocation Reschedule Icon][img-alloc-reschedule-icon]][img-alloc-reschedule-icon]
@@ -113,7 +112,7 @@ A task will typically emit log information to `stdout` and `stderr`. Nomad captu
exposes them through an API. The Web UI uses these APIs to offer `head`, `tail`, and streaming logs
from the browser.
The Web UI will first attempt to directly connecto to the client node the task is running on.
The Web UI will first attempt to directly connect to the client node the task is running on.
Typically, client nodes are not accessible from the public internet. If this is the case, the Web UI
will fall back and proxy to the client node from the server node with no loss of functionality.
@@ -124,11 +123,7 @@ logs will still be followed using interval polling.
## Restarting or Stopping an Allocation or Task
Ideally software always runs smoothly and as intended, but this isn't something we can count on.
Sometimes tasks will have a memory leak, sometimes a node will have noisy neighbors, and sometimes
we have no clue what's going so it's time to try turning it off and on again.
For these times, Nomad allows for restarting and stopping individual allocations and tasks. When a
Nomad allows for restarting and stopping individual allocations and tasks. When a
task is restarted, Nomad will perform a local restart of the task. When an allocation is stopped,
Nomad will mark the allocation as complete and perform a reschedule onto a different client node.
@@ -182,9 +177,8 @@ marking them as complete, and freeing up resources in the cluster.
Depending on the size of your team and the details of your Nomad deployment, you may wish to control
which features different internal users have access to. This includes differentiation between
submitting jobs, restarting allocations, and viewing potentially sensitive logs.
Nomad has an access control list system for doing just that.
submitting jobs, restarting allocations, and viewing potentially sensitive logs. You can enforce
this with Nomad's access control list system.
By default, all features—read and write—are available to all users of the Web UI. Check out the
[Securing the Web UI with ACLs](/guides/web-ui/securing.html) guide to learn how to prevent

11
website/source/guides/web-ui/submitting-a-job.html.md
View File

@@ -76,7 +76,7 @@ Upon submitting a job, you will be redirected to the Job Overview page for the j
If this is a new job, the job will start in a queued state. If there are no placement failures,
allocations for the job will naturally transition from a starting to a running or failed state.
Nomad is quick to schedule allocations (i.e., find a client node to start the allocation on), but an
allocation may sit in the starting state for awhile if it has to download
allocation may sit in the starting state for a while if it has to download
[source images](/docs/job-specification/task.html#task-examples) or
[other artifacts](/docs/job-specification/artifact.html). It may also sit in a starting state if the
task fails to start and requires retry attempts.
@@ -95,7 +95,7 @@ job and its allocations change.
From the subnav on any job detail page, you can access the Job Definition page.
The Job Definition page will show the job's underlying JSON representation. This can be useful for
quickly verifying how the job was configuring. Many properties from the job configuration will also
quickly verifying how the job was configured. Many properties from the job configuration will also
be on the Job Overview page, but some deeper properties may only be available in the definition
itself. It can also be convenient to see everything at once rather than traversing through task
groups, allocations, and tasks.
@@ -108,7 +108,7 @@ From the subnav on any job detail page, you can access the Job Versions page.
The Job Versions page will show a timeline view of every version of the job. Each version in the
timeline includes the version number, the time the version was submitted, whether the version is/was
stable, the number of changes, and the job diff itself.
stable, the number of changes, and the job diff.
Reviewing the job diffs version by version can be used to debug issues in a similar manner to `git log`.
@@ -154,9 +154,8 @@ monitor, but an experienced Nomad user can use evaluations to diagnose potential
## Access Control
Depending on the size of your team and the details of your Nomad deployment, you may wish to control
which features different internal users have access to.
Nomad has an access control list system for doing just that.
which features different internal users have access to. You can enforce this with Nomad's access
control list system.
By default, all features—read and write—are available to all users of the Web UI. Check out the
[Securing the Web UI with ACLs](/guides/web-ui/securing.html) guide to learn how to prevent