mirror of https://github.com/docker/docs.git
Add new section to TOC, update file titles
This commit is contained in:
parent
af110f6003
commit
71129f8084
|
|
@ -2343,6 +2343,18 @@ manuals:
|
|||
title: Create and manage organizations
|
||||
- path: /ee/dtr/admin/manage-users/permission-levels/
|
||||
title: Permission levels
|
||||
- sectiontitle: Manage jobs
|
||||
section:
|
||||
- path: /ee/dtr/admin/manage-jobs/
|
||||
title: Job Queue
|
||||
- path: /ee/dtr/admin/manage-jobs/job-queue/
|
||||
title: Audit Jobs with the Web Interface
|
||||
- path: /ee/dtr/admin/manage-jobs/audit-jobs-via-ui/
|
||||
title: Audit Jobs with the API
|
||||
- path: /ee/dtr/admin/manage-jobs/audit-jobs-via-api/
|
||||
title: Enable Auto-Deletion of Job Logs
|
||||
- path: /ee/dtr/admin/manage-jobs/auto-delete-job-logs/
|
||||
title: Permission levels
|
||||
- sectiontitle: Monitor and troubleshoot
|
||||
section:
|
||||
- path: /ee/dtr/admin/monitor-and-troubleshoot/
|
||||
|
|
@ -2351,8 +2363,6 @@ manuals:
|
|||
title: Check Notary audit logs
|
||||
- path: /ee/dtr/admin/monitor-and-troubleshoot/troubleshoot-with-logs/
|
||||
title: Troubleshoot with logs
|
||||
- path: /ee/dtr/admin/monitor-and-troubleshoot/troubleshoot-batch-jobs/
|
||||
title: Troubleshoot batch jobs
|
||||
- sectiontitle: Disaster recovery
|
||||
section:
|
||||
- title: Overview
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Troubleshoot Jobs via the API
|
||||
title: Audit Jobs via the API
|
||||
description: Learn how Docker Trusted Registry runs batch jobs for job-related troubleshooting.
|
||||
keywords: dtr, troubleshoot
|
||||
redirect_from: /ee/dtr/admin/monitor-and-troubleshoot/troubleshoot-batch-jobs/
|
||||
|
|
@ -7,7 +7,10 @@ redirect_from: /ee/dtr/admin/monitor-and-troubleshoot/troubleshoot-batch-jobs/
|
|||
|
||||
## Overview
|
||||
|
||||
This covers troubleshooting batch jobs via the API and was introduced in DTR 2.2. Starting in DTR 2.6, admins have the ability to [manage job logs](view-job-logs-on-interface.md) using the web interface. This requires familiarity with the [DTR Job Queue](job-queue.md).
|
||||
This covers troubleshooting batch jobs via the API and was introduced in DTR 2.2. Starting in DTR 2.6, admins have the ability to [audit jobs](audit-jobs-via-ui.md) using the web interface.
|
||||
|
||||
## Prerequisite
|
||||
* [Job Queue](job-queue.md)
|
||||
|
||||
### Job capacity
|
||||
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: View Job Logs
|
||||
title: Audit Jobs via the Web Interface
|
||||
description: View a list of jobs happening within DTR and review the detailed logs for each job.
|
||||
keywords: registry, jobs, log, system management, job queue
|
||||
---
|
||||
|
|
@ -8,7 +8,7 @@ keywords: registry, jobs, log, system management, job queue
|
|||
>
|
||||
> This is beta content. It is not yet complete and should be considered a work in progress. This content is subject to change without notice.
|
||||
|
||||
As of DTR 2.2, admins were able to [view and troubleshoot jobs within DTR](./troubleshoot-jobs-via-api) using the API. DTR 2.6 enhances those capabilities by adding a **Job Logs** tab under **System** settings on the user interface. The tab displays a sortable and paginated list of jobs along with links to associated job logs.
|
||||
As of DTR 2.2, admins were able to [view and troubleshoot jobs within DTR](audit-jobs-via-api.md) using the API. DTR 2.6 enhances those capabilities by adding a **Job Logs** tab under **System** settings on the user interface. The tab displays a sortable and paginated list of jobs along with links to associated job logs.
|
||||
|
||||
## View Jobs List
|
||||
|
||||
|
|
@ -22,7 +22,7 @@ To view the list of jobs within DTR, do the following:
|
|||
|
||||
3. Specify a filtering option. **Job Logs** lets you filter by:
|
||||
|
||||
* Action: See [Troubleshoot Jobs via the API: Job Types](./troubleshoot-jobs-via-api/#job-types) for an explanation on the different actions or job types.
|
||||
* Action: See [Troubleshoot Jobs via the API: Job Types](./audit-jobs-via-api/#job-types) for an explanation on the different actions or job types.
|
||||
|
||||
* Worker ID: The ID of the worker in a DTR replica that is responsible for running the job.
|
||||
|
||||
|
|
@ -34,10 +34,10 @@ The following is an explanation of the job-related fields displayed in **Job Log
|
|||
|
||||
| Job Detail | Description | Example |
|
||||
|:----------------|:-------------------------------------------------|:--------|
|
||||
| Action | The type of action or job being performed. See [Job Types](./troubleshoot-jobs-via-api/#job-types) for a full list of job types. | `onlinegc`
|
||||
| Action | The type of action or job being performed. See [Job Types](./audit-jobs-via-api/#job-types) for a full list of job types. | `onlinegc`
|
||||
| ID | The ID of the job. | `ccc05646-569a-4ac4-b8e1-113111f63fb9` |
|
||||
| Worker | The ID of the worker node responsible for running the job. | `8f553c8b697c`|
|
||||
| Status | Current status of the action or job. See [Troubleshoot Jobs via the API: Job Status](./troubleshoot-jobs-via-api/#job-status) for more details. | `done` |
|
||||
| Status | Current status of the action or job. See [Troubleshoot Jobs via the API: Job Status](./audit-jobs-via-api/#job-status) for more details. | `done` |
|
||||
| Start Time | Time when the job started. | `9/23/2018 7:04 PM` |
|
||||
| Last Updated | Time when the job was last updated. | `9/23/2018 7:04 PM` |
|
||||
| View Logs | Links to the full logs for the job. | `[View Logs]` |
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
---
|
||||
title: Tag Pruning
|
||||
description: Skip the management headache of deciding which tags to delete or preserve by configuring a tag pruning policy or enforcing a tag limit per repository in the Docker Trusted Registry
|
||||
keywords: registry, tag pruning, tag limit, repo management
|
||||
---
|
||||
|
||||
> BETA DISCLAIMER
|
||||
>
|
||||
> This is beta content. It is not yet complete and should be considered a work in progress. This content is subject to change without notice.
|
||||
|
||||
## Overview
|
||||
|
||||
Tag pruning is the process of cleaning up unnecessary or unwanted repository tags. As of v2.6, you can configure the Docker Trusted Registry (DTR) to automatically perform tag pruning on repositories that you manage by:
|
||||
|
||||
* specifying a tag pruning policy or alternatively,
|
||||
* setting a tag limit
|
||||
|
||||
|
||||
> Tag Pruning
|
||||
>
|
||||
> When run, tag pruning only deletes a tag and does not carry out any actual blob deletion. For actual blob deletions, see [Garbage Collection](../../admin/configure/garbage-collection.md).
|
||||
|
||||
In the following section, we will cover how to specify a tag pruning policy and set a tag limit on repositories that you manage. It will not include modifying or deleting a tag pruning policy.
|
||||
|
||||
## Specify a tag pruning policy
|
||||
|
||||
As a repository administrator, you can now add tag pruning policies on each repository that you manage. To get started, navigate to `https://<dtr-url>` and log in with your credentials.
|
||||
|
||||
Select **Repositories** on the left navigation pane, and then click on the name of the repository
|
||||
that you want to update. Note that you will have to click on the repository name following
|
||||
the `/` after the specific namespace for your repository.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
Select the **Pruning** tab, and click **New pruning policy** to specify your tag pruning criteria:
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
DTR allows you to set your pruning triggers based on the following image attributes:
|
||||
|
||||
| Name | Description | Example |
|
||||
|:----------------|:---------------------------------------------------| :----------------|
|
||||
| Tag name | Whether the tag name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Tag name = `test`|
|
||||
| Component name | Whether the image has a given component and the component name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Component name starts with `b` |
|
||||
| Vulnerabilities | Whether the image has vulnerabilities – critical, major, minor, or all – and your selected vulnerability filter is greater than or equals, greater than, equals, not equals, less than or equals, or less than your specified number | Critical vulnerabilities = `3` |
|
||||
| License | Whether the image uses an intellectual property license and is one of or not one of your specified words | License name = `docker` |
|
||||
| Last updated at | Whether the last image update was before your specified number of hours, days, weeks, or months. For details on valid time units, see [Go's ParseDuration function](https://golang.org/pkg/time/#ParseDuration). | Last updated at: Hours = `12` |
|
||||
|
||||
Specify one or more image attributes to add to your pruning criteria, then choose:
|
||||
|
||||
- **Prune future tags** to save the policy and apply your selection to future tags. Only matching tags after the policy addition will be pruned during garbage collection.
|
||||
- **Prune all tags** to save the policy, and evaluate both existing and future tags on your repository.
|
||||
|
||||
Upon selection, you will see a confirmation message and will be redirected to your newly updated **Pruning** tab.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
If you have specified multiple pruning policies on the repository, the **Pruning** tab will display a list of your prune triggers and details on when the last tag pruning was performed based on the trigger, a toggle for deactivating or reactivating the trigger, and a **View** link for modifying or deleting your selected trigger.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
All tag pruning policies on your account are evaluated every 15 minutes. Any qualifying tags are then deleted from the metadata store. If a tag pruning policy is modified or created, then the tag pruning policy for the *affected* repository will be evaluated.
|
||||
|
||||
## Set a tag limit
|
||||
|
||||
In addition to pruning policies, you can also set tag limits on repositories that you manage to restrict the number of tags on a given repository. Repository tag limits are processed in a first in first out (FIFO) manner. For example, if you set a tag limit of 2, adding a third tag would push out the first.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
To set a tag limit, select the repository that you want to update and click the **Settings** tab. Specify a number in the **Pruning** section and click **Save**. The **Pruning** tab will now display your tag limit above the prune triggers list along with a link to modify this setting.
|
||||
|
||||
|
||||
{: .with-border}
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Garbage collection](../../admin/configure/garbage-collection.md)
|
||||
Loading…
Reference in New Issue