diff --git a/_data/toc.yaml b/_data/toc.yaml index d1ea654674..e8d0271b47 100644 --- a/_data/toc.yaml +++ b/_data/toc.yaml @@ -1340,7 +1340,7 @@ manuals: title: Troubleshoot DDE issues on Mac - path: /ee/desktop/troubleshoot/windows-issues/ title: Troubleshoot DDE issues on Windows - - sectiontitle: Universal Control Plane + - sectiontitle: Universal Control Plane section: - path: /ee/ucp/ title: Universal Control Plane overview @@ -1557,7 +1557,7 @@ manuals: path: /ee/ucp/kubernetes/layer-7-routing/ - title: Create a service account for a Kubernetes app path: /ee/ucp/kubernetes/create-service-account/ - - title: Install a CNI plugin + - title: Install an unmanaged CNI plugin path: /ee/ucp/kubernetes/install-cni-plugin/ - title: Kubernetes network encryption path: /ee/ucp/kubernetes/kubernetes-network-encryption/ @@ -1565,8 +1565,12 @@ manuals: path: /ee/ucp/kubernetes/use-csi/ - sectiontitle: Persistent Storage section: - - title: Use NFS storage + - title: Use NFS Storage path: /ee/ucp/kubernetes/storage/use-nfs-volumes/ + - title: Use Azure Disk Storage + path: /ee/ucp/kubernetes/storage/use-azure-disk/ + - title: Use Azure Files Storage + path: /ee/ucp/kubernetes/storage/use-azure-files/ - title: Use AWS EBS Storage path: /ee/ucp/kubernetes/storage/configure-aws-storage/ - title: Configure iSCSI @@ -2402,6 +2406,14 @@ manuals: title: Create and manage organizations - path: /ee/dtr/admin/manage-users/permission-levels/ title: Permission levels + - sectiontitle: Manage webhooks + section: + - title: Create and manage webhooks + path: /ee/dtr/admin/manage-webhooks/ + - title: Use the web interface + path: /ee/dtr/admin/manage-webhooks/use-the-web-ui/ + - title: Use the API + path: /ee/dtr/admin/manage-webhooks/use-the-api/ - sectiontitle: Manage jobs section: - path: /ee/dtr/admin/manage-jobs/job-queue/ @@ -2485,8 +2497,6 @@ manuals: path: /ee/dtr/user/audit-repository-events/ - title: Auto-delete repository events path: /ee/dtr/admin/configure/auto-delete-repo-events/ - - path: /ee/dtr/user/create-and-manage-webhooks/ - title: Create and manage webhooks - title: Manage access tokens path: /ee/dtr/user/access-tokens/ - title: Tag pruning diff --git a/app-template/working-with-template.md b/app-template/working-with-template.md index 62d7dd7669..3d812fef96 100644 --- a/app-template/working-with-template.md +++ b/app-template/working-with-template.md @@ -1,7 +1,7 @@ --- title: Working with Docker Template description: Working with Docker Application Template -keywords: Docker, application template, Application Designer, +keywords: Docker, application template, Application Designer --- ## Overview diff --git a/compose/gettingstarted.md b/compose/gettingstarted.md index 35189c3ce4..55198f2f3c 100644 --- a/compose/gettingstarted.md +++ b/compose/gettingstarted.md @@ -31,7 +31,6 @@ Define the application dependencies. import redis from flask import Flask - app = Flask(__name__) cache = redis.Redis(host='redis', port=6379) @@ -53,9 +52,6 @@ Define the application dependencies. count = get_hit_count() return 'Hello World! I have been seen {} times.\n'.format(count) - if __name__ == "__main__": - app.run(host="0.0.0.0", debug=True) - In this example, `redis` is the hostname of the redis container on the application's network. We use the default port for Redis, `6379`. @@ -86,19 +82,25 @@ itself. In your project directory, create a file named `Dockerfile` and paste the following: - FROM python:3.4-alpine - ADD . /code + FROM python:3.7-alpine WORKDIR /code + ENV FLASK_APP app.py + ENV FLASK_RUN_HOST 0.0.0.0 + RUN apk add --no-cache gcc musl-dev linux-headers + COPY requirements.txt requirements.txt RUN pip install -r requirements.txt - CMD ["python", "app.py"] + COPY . . + CMD ["flask", "run"] This tells Docker to: -* Build an image starting with the Python 3.4 image. -* Add the current directory `.` into the path `/code` in the image. +* Build an image starting with the Python 3.7 image. * Set the working directory to `/code`. -* Install the Python dependencies. -* Set the default command for the container to `python app.py`. +* Set environment variables used by the `flask` command. +* Install gcc so Python packages such as MarkupSafe and SQLAlchemy can compile speedups. +* Copy `requirements.txt` and install the Python dependencies. +* Copy the current directory `.` in the project to the workdir `.` in the image. +* Set the default command for the container to `flask run`. For more information on how to write Dockerfiles, see the [Docker user guide](/engine/tutorials/dockerimages.md#building-an-image-from-a-dockerfile) @@ -115,7 +117,7 @@ the following: web: build: . ports: - - "5000:5000" + - "5000:5000" redis: image: "redis:alpine" @@ -161,13 +163,13 @@ image pulled from the Docker Hub registry. Compose pulls a Redis image, builds an image for your code, and starts the services you defined. In this case, the code is statically copied into the image at build time. -2. Enter `http://0.0.0.0:5000/` in a browser to see the application running. +2. Enter http://localhost:5000/ in a browser to see the application running. If you're using Docker natively on Linux, Docker Desktop for Mac, or Docker Desktop for Windows, then the web app should now be listening on port 5000 on your - Docker daemon host. Point your web browser to `http://localhost:5000` to + Docker daemon host. Point your web browser to http://localhost:5000 to find the `Hello World` message. If this doesn't resolve, you can also try - `http://0.0.0.0:5000`. + http://127.0.0.1:5000. If you're using Docker Machine on a Mac or Windows, use `docker-machine ip MACHINE_VM` to get the IP address of your Docker host. Then, open @@ -219,15 +221,19 @@ Edit `docker-compose.yml` in your project directory to add a [bind mount](/engin web: build: . ports: - - "5000:5000" + - "5000:5000" volumes: - - .:/code + - .:/code + environment: + FLASK_ENV: development redis: image: "redis:alpine" The new `volumes` key mounts the project directory (current directory) on the host to `/code` inside the container, allowing you to modify the code on the -fly, without having to rebuild the image. +fly, without having to rebuild the image. The `environment` key sets the +`FLASK_ENV` environment variable, which tells `flask run` to run in development +mode and reload the code on change. This mode should only be used in development. ## Step 6: Re-build and run the app with Compose diff --git a/config/containers/logging/dual-logging.md b/config/containers/logging/dual-logging.md index 2f3d395582..10840af854 100644 --- a/config/containers/logging/dual-logging.md +++ b/config/containers/logging/dual-logging.md @@ -1,7 +1,7 @@ --- description: Learn how to read container logs locally when using a third party logging solution. keywords: docker, logging, driver -title: Using docker logs to read container logs for remote logging drivers +title: Use docker logs to read container logs for remote logging drivers --- ## Overview @@ -27,7 +27,8 @@ Starting with Docker Engine Enterprise 18.03.1-ee-1, you can use `docker logs` t logs regardless of the configured logging driver or plugin. This capability, sometimes referred to as dual logging, allows you to use `docker logs` to read container logs locally in a consistent format, regardless of the remote log driver used, because the engine is configured to log information to the “local” -logging driver. Refer to [Configure the default logging driver](/configure) for additional information. +logging driver. Refer to [Configure the default logging driver](/config/containers/logging/configure) for additional information. + ## Prerequisites diff --git a/develop/dev-best-practices.md b/develop/dev-best-practices.md index 0835eb6d71..103ad7f210 100644 --- a/develop/dev-best-practices.md +++ b/develop/dev-best-practices.md @@ -102,7 +102,7 @@ keep image size small: There are limitations around sharing data amongst nodes of a swarm service. If you use [Docker for AWS](/docker-for-aws/persistent-data-volumes.md) or -[Docker for Azure](docker-for-azure/persistent-data-volumes.md), you can use the +[Docker for Azure](/docker-for-azure/persistent-data-volumes.md), you can use the Cloudstor plugin to share data amongst your swarm service nodes. You can also write your application data into a separate database which supports simultaneous updates. diff --git a/docker-for-mac/faqs.md b/docker-for-mac/faqs.md index da08cdee6c..31b4cfc1e8 100644 --- a/docker-for-mac/faqs.md +++ b/docker-for-mac/faqs.md @@ -106,7 +106,7 @@ is about older releases of Docker for Mac. If, after installing Docker for Mac, you [change the name of your macOS user account and home folder](https://support.apple.com/en-us/HT201548), Docker for -Mac fails to start. [Reset to Factory Defaults](index.md#reset) is the simplest +Mac fails to start. [Reset to Factory Defaults](/docker-for-mac/index/#reset) is the simplest fix, but you'll lose all your settings, containers, images, etc. To preserve them, open the `~/Library/Group @@ -246,7 +246,7 @@ Starting with Docker for Mac Beta 27 and Stable 1.12.3, all trusted certificate authorities (CAs) (root or intermediate) are supported. For full information on adding server and client side certs, see -[Add TLS certificates](index.md#add-tls-certificates) in the Getting Started topic. +[Add TLS certificates](/docker-for-mac/index/#add-tls-certificates) in the Getting Started topic. ### How do I add client certificates? @@ -256,7 +256,7 @@ in `~/.docker/certs.d/:/client.cert` and `~/.docker/certs.d/:/client.key`. For full information on adding server and client side certs, see -[Add TLS certificates](index.md#add-tls-certificates) in the Getting Started topic. +[Add TLS certificates](/docker-for-mac/index/#add-tls-certificates) in the Getting Started topic. ### Can I pass through a USB device to a container? diff --git a/ee/desktop/user/mac-user.md b/ee/desktop/user/mac-user.md index 8068fde9f7..4ee9578598 100644 --- a/ee/desktop/user/mac-user.md +++ b/ee/desktop/user/mac-user.md @@ -1,6 +1,5 @@ --- title: Use Docker Desktop Enterprise on Mac -description: Exploring the Mac user interface keywords: Docker EE, Windows, Mac, Docker Desktop, Enterprise --- diff --git a/ee/dtr/admin/configure/auto-delete-repo-events.md b/ee/dtr/admin/configure/auto-delete-repo-events.md index 8e7c2d6366..bff0a4b6a7 100644 --- a/ee/dtr/admin/configure/auto-delete-repo-events.md +++ b/ee/dtr/admin/configure/auto-delete-repo-events.md @@ -10,24 +10,24 @@ Docker Trusted Registry has a global setting for repository event auto-deletion. ## Steps -1. In your browser, navigate to `https://` and log in with your UCP credentials. +1. In your browser, navigate to `https://` and log in with your admin credentials. -2. Select **System** on the left navigation pane which will display the **Settings** page by default. +2. Select **System** from the left navigation pane which displays the **Settings** page by default. 3. Scroll down to **Repository Events** and turn on ***Auto-Deletion***. -![](../../images/auto-delete-repo-events-0.png){: .img-fluid .with-border} + ![](../../images/auto-delete-repo-events-0.png){: .img-fluid .with-border} 4. Specify the conditions with which an event auto-deletion will be triggered. -![](../../images/auto-delete-repo-events-1.png){: .img-fluid .with-border} + ![](../../images/auto-delete-repo-events-1.png){: .img-fluid .with-border} -DTR allows you to set your auto-deletion conditions based on the following optional repository event attributes: + DTR allows you to set your auto-deletion conditions based on the following optional repository event attributes: -| Name | Description | Example | -|:----------------|:---------------------------------------------------| :----------------| -| Age | Lets you remove events older than your specified number of hours, days, weeks or months| `2 months` | -| Max number of events | Lets you specify the maximum number of events allowed in the repositories. | `6000` | + | Name | Description | Example | + |:----------------|:---------------------------------------------------| :----------------| + | Age | Lets you remove events older than your specified number of hours, days, weeks or months| `2 months` | + | Max number of events | Lets you specify the maximum number of events allowed in the repositories. | `6000` | If you check and specify both, events in your repositories will be removed during garbage collection if either condition is met. You should see a confirmation message right away. @@ -35,7 +35,7 @@ If you check and specify both, events in your repositories will be removed durin 6. Navigate to **System > Job Logs** to confirm that `onlinegc` has happened. -![](../../images/auto-delete-repo-events-2.png){: .img-fluid .with-border} + ![](../../images/auto-delete-repo-events-2.png){: .img-fluid .with-border} ## Where to go next diff --git a/ee/dtr/admin/manage-webhooks/index.md b/ee/dtr/admin/manage-webhooks/index.md new file mode 100644 index 0000000000..a9eaa8d778 --- /dev/null +++ b/ee/dtr/admin/manage-webhooks/index.md @@ -0,0 +1,36 @@ +--- +title: Manage webhooks +description: Learn how to create, configure, and test webhooks in Docker Trusted Registry. +keywords: registry, webhooks +redirect_from: + - /datacenter/dtr/2.5/guides/user/create-and-manage-webhooks/ + - /ee/dtr/user/create-and-manage-webhooks/ +--- + +You can configure DTR to automatically post event notifications to a webhook URL of your choosing. This lets you build complex CI and CD pipelines with your Docker images. The following is a complete list of event types you can trigger webhook notifications for via the [web interface](use-the-web-ui) or the [API](use-the-API). + +## Webhook types + +| Event Type | Scope | Access Level | Availability | +| --------------------------------------- | ----------------------- | ---------------- | ------------ | +| Tag pushed to repository (`TAG_PUSH`) | Individual repositories | Repository admin | Web UI & API | +| Tag pulled from repository (`TAG_PULL`) | Individual repositories | Repository admin | Web UI & API | +| Tag deleted from repository (`TAG_DELETE`) | Individual repositories | Repository admin | Web UI & API | +| Manifest pushed to repository (`MANIFEST_PUSH`) | Individual repositories | Repository admin | Web UI & API | +| Manifest pulled from repository (`MANIFEST_PULL`) | Individual repositories | Repository admin | Web UI & API | +| Manifest deleted from repository (`MANIFEST_DELETE`) | Individual repositories | Repository admin | Web UI & API | +| Security scan completed (`SCAN_COMPLETED`) | Individual repositories | Repository admin | Web UI & API | +| Security scan failed (`SCAN_FAILED`) | Individual repositories | Repository admin | Web UI & API | +| Image promoted from repository (`PROMOTION`) | Individual repositories | Repository admin | Web UI & API | +| Image mirrored from repository (`PUSH_MIRRORING`) | Individual repositories | Repository admin | Web UI & API | +| Image mirrored from remote repository (`POLL_MIRRORING`) | Individual repositories | Repository admin | Web UI & API | +| Repository created, updated, or deleted (`REPO_CREATED`, `REPO_UPDATED`, and `REPO_DELETED`) | Namespaces / Organizations | Namespace / Org owners | API Only | +| Security scanner update completed (`SCANNER_UPDATE_COMPLETED`) | Global | DTR admin | API only | + +You must have admin privileges to a repository or namespace in order to +subscribe to its webhook events. For example, a user must be an admin of repository "foo/bar" to subscribe to its tag push events. A DTR admin can subscribe to any event. + +## Where to go next + +- [Manage webhooks via the web interface](use-the-web-ui) +- [Manage webhooks via the the API](use-the-api) diff --git a/ee/dtr/admin/manage-webhooks/use-the-api.md b/ee/dtr/admin/manage-webhooks/use-the-api.md new file mode 100644 index 0000000000..f710fc1c07 --- /dev/null +++ b/ee/dtr/admin/manage-webhooks/use-the-api.md @@ -0,0 +1,311 @@ +--- +title: Manage webhooks via the API +description: Learn how to create, configure, and test webhooks for DTR using the API. +keywords: dtr, webhooks, api, registry +--- + +## Prerequisite + +See [Webhook types](/ee/dtr/admin/manage-webhooks/index.md/#webhook-types) for a list of events you can trigger notifications for via the API. + +## API Base URL + +Your DTR hostname serves as the base URL for your API requests. + +## Swagger API explorer + +From the DTR web interface, click **API** on the bottom left navigation pane to explore the API resources and endpoints. Click **Execute** to send your API request. + +## API requests via curl + +You can use [curl](https://curl.haxx.se/docs/manpage.html) to send HTTP or HTTPS API requests. Note that you will have to specify `skipTLSVerification: true` on your request in order to test the webhook endpoint over HTTP. + +### Example curl request + +```bash +curl -u test-user:$TOKEN -X POST "https://dtr-example.com/api/v0/webhooks" -H "accept: application/json" -H "content-type: application/json" -d "{ \"endpoint\": \"https://webhook.site/441b1584-949d-4608-a7f3-f240bdd31019\", \"key\": \"maria-testorg/lab-words\", \"skipTLSVerification\": true, \"type\": \"TAG_PULL\"}" +``` + +### Example JSON response + +```json +{ + "id": "b7bf702c31601efb4796da59900ddc1b7c72eb8ca80fdfb1b9fecdbad5418155", + "type": "TAG_PULL", + "key": "maria-testorg/lab-words", + "endpoint": "https://webhook.site/441b1584-949d-4608-a7f3-f240bdd31019", + "authorID": "194efd8e-9ee6-4d43-a34b-eefd9ce39087", + "createdAt": "2019-05-22T01:55:20.471286995Z", + "lastSuccessfulAt": "0001-01-01T00:00:00Z", + "inactive": false, + "tlsCert": "", + "skipTLSVerification": true +} +``` + +## Subscribe to events + +To subscribe to events, send a `POST` request to +`/api/v0/webhooks` with the following JSON payload: + +### Example usage + +``` +{ + "type": "TAG_PUSH", + "key": "foo/bar", + "endpoint": "https://example.com" +} +``` + +The keys in the payload are: + +- `type`: The event type to subcribe to. +- `key`: The namespace/organization or repo to subscribe to. For example, "foo/bar" to subscribe to +pushes to the "bar" repository within the namespace/organization "foo". +- `endpoint`: The URL to send the JSON payload to. + +Normal users **must** supply a "key" to scope a particular webhook event to +a repository or a namespace/organization. DTR admins can choose to omit this, +meaning a POST event notification of your specified type will be sent for all DTR repositories and namespaces. + +### Receive a payload + +Whenever your specified event type occurs, DTR will send a POST request to the given +endpoint with a JSON-encoded payload. The payload will always have the +following wrapper: + +``` +{ + "type": "...", + "createdAt": "2012-04-23T18:25:43.511Z", + "contents": {...} +} +``` + +- `type` refers to the event type received at the specified subscription endpoint. +- `contents` refers to the payload of the event itself. Each event is different, therefore the +structure of the JSON object in `contents` will change depending on the event +type. See [Content structure](#content-structure) for more details. + +### Test payload subscriptions + +Before subscribing to an event, you can view and test your endpoints using +fake data. To send a test payload, send `POST` request to +`/api/v0/webhooks/test` with the following payload: + +``` +{ + "type": "...", + "endpoint": "https://www.example.com/" +} +``` + +Change `type` to the event type that you want to receive. DTR will then send +an example payload to your specified endpoint. The example +payload sent is always the same. + +## Content structure + +Comments after (`//`) are for informational purposes only, and the example payloads have been clipped for brevity. + +### Repository event content structure + +**Tag push** + +``` +{ + "namespace": "", // (string) namespace/organization for the repository + "repository": "", // (string) repository name + "tag": "", // (string) the name of the tag just pushed + "digest": "", // (string) sha256 digest of the manifest the tag points to (eg. "sha256:0afb...") + "imageName": "", // (string) the fully-qualified image name including DTR host used to pull the image (eg. 10.10.10.1/foo/bar:tag) + "os": "", // (string) the OS for the tag's manifest + "architecture": "", // (string) the architecture for the tag's manifest + "author": "", // (string) the username of the person who pushed the tag + "pushedAt": "", // (string) JSON-encoded timestamp of when the push occurred + ... +} +``` + +**Tag delete** + +``` +{ + "namespace": "", // (string) namespace/organization for the repository + "repository": "", // (string) repository name + "tag": "", // (string) the name of the tag just deleted + "digest": "", // (string) sha256 digest of the manifest the tag points to (eg. "sha256:0afb...") + "imageName": "", // (string) the fully-qualified image name including DTR host used to pull the image (eg. 10.10.10.1/foo/bar:tag) + "os": "", // (string) the OS for the tag's manifest + "architecture": "", // (string) the architecture for the tag's manifest + "author": "", // (string) the username of the person who deleted the tag + "deletedAt": "", // (string) JSON-encoded timestamp of when the delete occurred + ... +} +``` +**Manifest push** + +``` +{ + "namespace": "", // (string) namespace/organization for the repository + "repository": "", // (string) repository name + "digest": "", // (string) sha256 digest of the manifest (eg. "sha256:0afb...") + "imageName": "", // (string) the fully-qualified image name including DTR host used to pull the image (eg. 10.10.10.1/foo/bar@sha256:0afb...) + "os": "", // (string) the OS for the manifest + "architecture": "", // (string) the architecture for the manifest + "author": "", // (string) the username of the person who pushed the manifest + ... +} +``` + +**Manifest delete** + +``` +{ + "namespace": "", // (string) namespace/organization for the repository + "repository": "", // (string) repository name + "digest": "", // (string) sha256 digest of the manifest (eg. "sha256:0afb...") + "imageName": "", // (string) the fully-qualified image name including DTR host used to pull the image (eg. 10.10.10.1/foo/bar@sha256:0afb...) + "os": "", // (string) the OS for the manifest + "architecture": "", // (string) the architecture for the manifest + "author": "", // (string) the username of the person who deleted the manifest + "deletedAt": "", // (string) JSON-encoded timestamp of when the delete occurred + ... +} +``` + +**Security scan completed** + +``` +{ + "namespace": "", // (string) namespace/organization for the repository + "repository": "", // (string) repository name + "tag": "", // (string) the name of the tag scanned + "imageName": "", // (string) the fully-qualified image name including DTR host used to pull the image (eg. 10.10.10.1/foo/bar:tag) + "scanSummary": { + "namespace": "", // (string) repository's namespace/organization name + "repository": "", // (string) repository name + "tag": "", // (string) the name of the tag just pushed + "critical": 0, // (int) number of critical issues, where CVSS >= 7.0 + "major": 0, // (int) number of major issues, where CVSS >= 4.0 && CVSS < 7 + "minor": 0, // (int) number of minor issues, where CVSS > 0 && CVSS < 4.0 + "last_scan_status": 0, // (int) enum; see scan status section + "check_completed_at": "", // (string) JSON-encoded timestamp of when the scan completed + ... + } +} +``` + +**Security scan failed** + +``` +{ + "namespace": "", // (string) namespace/organization for the repository + "repository": "", // (string) repository name + "tag": "", // (string) the name of the tag scanned + "imageName": "", // (string) the fully-qualified image name including DTR host used to pull the image (eg. 10.10.10.1/foo/bar@sha256:0afb...) + "error": "", // (string) the error that occurred while scanning + ... +} +``` + +### Namespace-specific event structure + +**Repository event (created/updated/deleted)** + +``` +{ + "namespace": "", // (string) repository's namespace/organization name + "repository": "", // (string) repository name + "event": "", // (string) enum: "REPO_CREATED", "REPO_DELETED" or "REPO_UPDATED" + "author": "", // (string) the name of the user responsible for the event + "data": {} // (object) when updating or creating a repo this follows the same format as an API response from /api/v0/repositories/{namespace}/{repository} +} +``` + +### Global event structure + +**Security scanner update complete** + +``` +{ + "scanner_version": "", + "scanner_updated_at": "", // (string) JSON-encoded timestamp of when the scanner updated + "db_version": 0, // (int) newly updated database version + "db_updated_at": "", // (string) JSON-encoded timestamp of when the database updated + "success": // (bool) whether the update was successful + "replicas": { // (object) a map keyed by replica ID containing update information for each replica + "replica_id": { + "db_updated_at": "", // (string) JSON-encoded time of when the replica updated + "version": "", // (string) version updated to + "replica_id": "" // (string) replica ID + }, + ... + } +} +``` + +### Security scan status codes + + +- 0: **Failed**. An error occurred checking an image's layer +- 1: **Unscanned**. The image has not yet been scanned +- 2: **Scanning**. Scanning in progress +- 3: **Pending**: The image will be scanned when a worker is available +- 4: **Scanned**: The image has been scanned but vulnerabilities have not yet been checked +- 5: **Checking**: The image is being checked for vulnerabilities +- 6: **Completed**: The image has been fully security scanned + + +## View and manage existing subscriptions + +### View all subscriptions + +To view existing subscriptions, send a `GET` request to `/api/v0/webhooks`. As +a normal user (i.e. not a DTR admin), this will show all of your +current subscriptions across every namespace/organization and repository. As a DTR +admin, this will show **every** webhook configured for your DTR. + +The API response will be in the following format: + +``` +[ + { + "id": "", // (string): UUID of the webhook subscription + "type": "", // (string): webhook event type + "key": "", // (string): the individual resource this subscription is scoped to + "endpoint": "", // (string): the endpoint to send POST event notifications to + "authorID": "", // (string): the user ID resposible for creating the subscription + "createdAt": "", // (string): JSON-encoded datetime when the subscription was created + }, + ... +] +``` + +For more information, [view the API documentation](/reference/dtr/{{site.dtr_version}}/api/). + +### View subscriptions for a particular resource + +You can also view subscriptions for a given resource that you are an +admin of. For example, if you have admin rights to the repository +"foo/bar", you can view all subscriptions (even other people's) from a +particular API endpoint. These endpoints are: + +- `GET /api/v0/repositories/{namespace}/{repository}/webhooks`: View all +webhook subscriptions for a repository +- `GET /api/v0/repositories/{namespace}/webhooks`: View all webhook subscriptions for a +namespace/organization + +### Delete a subscription + +To delete a webhook subscription, send a `DELETE` request to +`/api/v0/webhooks/{id}`, replacing `{id}` with the webhook subscription ID +which you would like to delete. + +Only a DTR admin or an admin for the resource with the event subscription can delete a subscription. As a normal user, you can only +delete subscriptions for repositories which you manage. + +## Where to go next + +- [Manage jobs](/ee/dtr/admin/manage-jobs/job-queue/) diff --git a/ee/dtr/admin/manage-webhooks/use-the-web-ui.md b/ee/dtr/admin/manage-webhooks/use-the-web-ui.md new file mode 100644 index 0000000000..b3c8dfe26f --- /dev/null +++ b/ee/dtr/admin/manage-webhooks/use-the-web-ui.md @@ -0,0 +1,54 @@ +--- +title: Manage repository webhooks via the web interface +description: Learn how to create, configure, and test repository webhooks for DTR using the web interface. +keywords: dtr, webhooks, ui, web interface, registry +--- + +## Prerequisites + +- You must have admin privileges to the repository in order to create a webhook. +- See [Webhook types](/ee/dtr/admin/manage-webhooks/index.md/#webhook-types) for a list of events you can trigger notifications for using the web interface. + +## Create a webhook for your repository + +1. In your browser, navigate to `https://` and log in with your credentials. + +2. Select **Repositories** from the left navigation pane, and then click on the name of the repository that you want to view. Note that you will have to click on the repository name following the `/` after the specific namespace for your repository. + +3. Select the **Webhooks** tab, and click **New Webhook**. + + ![](/ee/dtr/images/manage-webhooks-1.png){: .with-border} + +4. From the drop-down list, select the event that will trigger the webhook. +5. Set the URL which will receive the JSON payload. Click **Test** next to the **Webhook URL** field, so that you can validate that the integration is working. At your specified URL, you should receive a JSON payload for your chosen event type notification. + + ```json + { + "type": "TAG_PUSH", + "createdAt": "2019-05-15T19:39:40.607337713Z", + "contents": { + "namespace": "foo", + "repository": "bar", + "tag": "latest", + "digest": "sha256:b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c", + "imageName": "foo/bar:latest", + "os": "linux", + "architecture": "amd64", + "author": "", + "pushedAt": "2015-01-02T15:04:05Z" + }, + "location": "/repositories/foo/bar/tags/latest" + } + ``` + +6. Expand "Show advanced settings" to paste the TLS certificate associated with your webhook URL. For testing purposes, you can test over HTTP instead of HTTPS. + +7. Click **Create** to save. Once saved, your webhook is active and starts sending POST notifications whenever your chosen event type is triggered. + + ![](/ee/dtr/images/manage-webhooks-2.png){: .with-border} + +As a repository admin, you can add or delete a webhook at any point. Additionally, you can create, view, and delete webhooks for your organization or trusted registry [using the API](use-the-api). + +## Where to go next + +- [Manage webhooks via the API](use-the-api) diff --git a/ee/dtr/images/manage-webhooks-1.png b/ee/dtr/images/manage-webhooks-1.png index 632a5315b7..86e6ee80f0 100644 Binary files a/ee/dtr/images/manage-webhooks-1.png and b/ee/dtr/images/manage-webhooks-1.png differ diff --git a/ee/dtr/images/manage-webhooks-2.png b/ee/dtr/images/manage-webhooks-2.png index 15d2157e21..e7526bace4 100644 Binary files a/ee/dtr/images/manage-webhooks-2.png and b/ee/dtr/images/manage-webhooks-2.png differ diff --git a/ee/dtr/user/audit-repository-events.md b/ee/dtr/user/audit-repository-events.md index 7d10d1bc9b..b664b48eff 100644 --- a/ee/dtr/user/audit-repository-events.md +++ b/ee/dtr/user/audit-repository-events.md @@ -13,9 +13,9 @@ In the following section, we will show you how to view and audit the list of eve ## View List of Events As of DTR 2.3, admins were able to view a list of DTR events [using the API](/datacenter/dtr/2.3/reference/api/#!/events/GetEvents). DTR 2.6 enhances that feature by showing a permission-based events list for each repository page on the web interface. To view the list of events within a repository, do the following: -1. Navigate to `https://` and log in with your UCP credentials. +1. Navigate to `https://` and log in with your DTR credentials. -2. Select **Repositories** on the left navigation pane, and then click on the name of the repository that you want to view. Note that you will have to click on the repository name following the `/` after the specific namespace for your repository. +2. Select **Repositories** from the left navigation pane, and then click on the name of the repository that you want to view. Note that you will have to click on the repository name following the `/` after the specific namespace for your repository. 3. Select the **Activity** tab. You should see a paginated list of the latest events based on your repository permission level. By default, **Activity** shows the latest `10` events and excludes pull events, which are only visible to repository and DTR admins. * If you're a repository or a DTR admin, uncheck "Exclude pull" to view pull events. This should give you a better understanding of who is consuming your images. diff --git a/ee/dtr/user/create-and-manage-webhooks.md b/ee/dtr/user/create-and-manage-webhooks.md deleted file mode 100644 index 71ff486509..0000000000 --- a/ee/dtr/user/create-and-manage-webhooks.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: Manage webhooks -description: Learn how to create, configure, and test webhooks in Docker Trusted Registry. -keywords: registry, webhooks -redirect_from: - - /datacenter/dtr/2.5/guides/user/create-and-manage-webhooks/ ---- - -DTR has webhooks so that you can run custom logic when an event happens. This -lets you build complex CI and CD pipelines with your Docker images. - -## Create a webhook - -To create a webhook, navigate to the **repository details** page, choose -the **Webhooks** tab, and click **New Webhook**. - -![](../images/manage-webhooks-1.png){: .with-border} - -Select the event that will trigger the webhook, and set the URL to send -information about the event. Once everything is set up, click **Test** for -DTR to send a JSON payload to the URL you set up, so that you can validate -that the integration is working. You'll get an event that looks like this: - -```json -{ - "contents": { - "architecture": "amd64", - "author": "", - "digest": "sha256:b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c", - "imageName": "example.com/foo/bar:latest", - "namespace": "foo", - "os": "linux", - "pushedAt": "2015-01-02T15:04:05Z", - "repository": "bar", - "tag": "latest" - }, - "createdAt": "2017-06-20T01:29:53.046620425Z", - "location": "/repositories/foo/bar/tags/latest", - "type": "TAG_PUSH" -} -``` - -Once you save, your webhook is active and starts sending notifications when -the event is triggered. - -![](../images/manage-webhooks-2.png){: .with-border} - -## Where to go next - -* [Create promotion policies](promotion-policies/index.md) diff --git a/ee/dtr/user/manage-images/scan-images-for-vulnerabilities.md b/ee/dtr/user/manage-images/scan-images-for-vulnerabilities.md index 70fa9253f8..ce01f5ee39 100644 --- a/ee/dtr/user/manage-images/scan-images-for-vulnerabilities.md +++ b/ee/dtr/user/manage-images/scan-images-for-vulnerabilities.md @@ -37,7 +37,7 @@ Vulnerability Database that is installed on your DTR instance. When this database is updated, DTR reviews the indexed components for newly discovered vulnerabilities. -DTR scans both Linux and Windows images, but but by default Docker doesn't push +DTR scans both Linux and Windows images, but by default Docker doesn't push foreign image layers for Windows images so DTR won't be able to scan them. If you want DTR to scan your Windows images, [configure Docker to always push image layers](pull-and-push-images.md), and it will scan the non-foreign layers. diff --git a/ee/dtr/user/manage-images/sign-images/index.md b/ee/dtr/user/manage-images/sign-images/index.md index 9fa9511695..9bac5a1991 100644 --- a/ee/dtr/user/manage-images/sign-images/index.md +++ b/ee/dtr/user/manage-images/sign-images/index.md @@ -7,7 +7,7 @@ redirect_from: - /ee/dtr/user/manage-images/sign-images/manage-trusted-repositories/ --- -2 Key components of the Docker Trusted Registry is the Notary Server and Notary +2 Key components of the Docker Trusted Registry are the Notary Server and Notary Signer. These 2 containers give us the required components to use Docker Content Trust right out of the box. [Docker Content Trust](/engine/security/trust/content_trust/) allows us to sign image tags, diff --git a/ee/ucp/admin/configure/enable-saml-authentication.md b/ee/ucp/admin/configure/enable-saml-authentication.md index 905e03d551..314fd5acbc 100644 --- a/ee/ucp/admin/configure/enable-saml-authentication.md +++ b/ee/ucp/admin/configure/enable-saml-authentication.md @@ -36,17 +36,41 @@ Name: `is-admin`, Filter: (user defined) for identifying if the user is an admin ### ADFS integration values -ADFS integration requires these values: +ADFS integration requires the following steps: -- Service provider metadata URI. This value is the URL for UCP, qualified with `/enzi/v0/saml/metadata`. For example, `https://111.111.111.111/enzi/v0/saml/metadata`. -- Attribute Store: Active Directory. - - Add LDAP Attribute = Email Address; Outgoing Claim Type: Email Address - - Add LDAP Attribute = Display-Name; Outgoing Claim Type: Common Name -- Claim using Custom Rule. For example, `c:[Type == "http://schemas.xmlsoap.org/claims/CommonName"] - => issue(Type = "fullname", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);` -- Outgoing claim type: Name ID -- Outgoing name ID format: Transient Identifier -- Pass through all claim values +1. Add a relying party trust. For example: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-relying-party-trust) + +2. Obtain the service provider metadata URI. This value is the URL for UCP, qualified with `/enzi/v0/saml/metadata`. For example, `https://111.111.111.111/enzi/v0/saml/metadata`. + +3. Add claim rules: + + * Convert values from AD to SAML + - Display-name : Common Name + - E-Mail-Addresses : E-Mail Address + - SAM-Account-Name : Name ID + * Create full name for UCP (custom rule): + ``` + c:[Type == "http://schemas.xmlsoap.org/claims/CommonName"] + => issue(Type = "fullname", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, + ValueType = c.ValueType); + ``` + * Transform account name to Name ID: + - Incoming type: Name ID + - Incoming format: Unspecified + - Outgoing claim type: Name ID + - Outgoing format: Transient ID + * Pass admin value to allow admin access based on AD group (send group membership as claim): + - Users group : Your admin group + - Outgoing claim type: is-admin + - Outgoing claim value: 1 + * Configure group membership (for more complex organizations with multiple groups to manage access) + - Send LDAP attributes as claims + - Attribute store: Active Directory + - Add two rows with the following information: + - LDAP attribute = email address; outgoing claim type: email address + - LDAP attribute = Display-Name; outgoing claim type: common name + - Mapping: + - Token-Groups - Unqualified Names : member-of ## Configure the SAML integration diff --git a/ee/ucp/admin/configure/join-nodes/index.md b/ee/ucp/admin/configure/join-nodes/index.md index 3f305d7c6f..2379a20928 100644 --- a/ee/ucp/admin/configure/join-nodes/index.md +++ b/ee/ucp/admin/configure/join-nodes/index.md @@ -28,14 +28,15 @@ your cluster. For production-grade deployments, follow these rules of thumb: +* For high availability with minimal + network overhead, the recommended number of manager nodes is 3. The recommended maximum number of manager + nodes is 5. Adding too many manager nodes to the cluster can lead to performance degradation, + because changes to configurations must be replicated across all manager nodes. * When a manager node fails, the number of failures tolerated by your cluster decreases. Don't leave that node offline for too long. * You should distribute your manager nodes across different availability zones. This way your cluster can continue working even if an entire availability zone goes down. -* Adding many manager nodes to the cluster might lead to performance - degradation, as changes to configurations need to be replicated across all - manager nodes. The maximum advisable is seven manager nodes. ## Where to go next diff --git a/ee/ucp/admin/install/index.md b/ee/ucp/admin/install/index.md index 2f9340829b..5fece24ed2 100644 --- a/ee/ucp/admin/install/index.md +++ b/ee/ucp/admin/install/index.md @@ -52,17 +52,6 @@ Make sure you follow the [UCP System requirements](system-requirements.md) for opening networking ports. Ensure that your hardware or software firewalls are open appropriately or disabled. -> Ubuntu 14.04 mounts -> -> For UCP to install correctly on Ubuntu 14.04, `/mnt` and other mounts -> must be shared: -> ``` -> sudo mount --make-shared /mnt -> sudo mount --make-shared / -> sudo mount --make-shared /run -> sudo mount --make-shared /dev -> ``` - To install UCP: 1. Use ssh to log in to the host where you want to install UCP. @@ -86,12 +75,12 @@ To install UCP: To find what other options are available in the install command, check the [reference documentation](/reference/ucp/3.1/cli/install.md). -> Custom CNI plugins +> Custom Container Networking Interface (CNI) plugins > -> If you want to use a third-party Container Networking Interface (CNI) plugin, -> like Flannel or Weave, modify the previous command line to include the -> `--cni-installer-url` option. Learn how to -> [install a CNI plugin](../../kubernetes/install-cni-plugin.md). +> UCP will install [Project Calico](https://docs.projectcalico.org/v3.7/introduction/) +> for container-to-container communication for Kubernetes. A platform operator may +> choose to install an alternative CNI plugin, such as Weave or Flannel. Please see +>[Install an unmanaged CNI plugin](/ee/ucp/kubernetes/install-cni-plugin/). {: important} ## Step 5: License your installation diff --git a/ee/ucp/authorization/index.md b/ee/ucp/authorization/index.md index eb239040dc..35e193ade2 100644 --- a/ee/ucp/authorization/index.md +++ b/ee/ucp/authorization/index.md @@ -23,7 +23,7 @@ For an example, see [Deploy stateless app with RBAC](deploy-stateless-app.md). ## Subjects -A subject represents a user, team, organization, or service account. A subject +A subject represents a user, team, organization, or a service account. A subject can be granted a role that defines permitted operations against one or more resource sets. @@ -34,19 +34,19 @@ resource sets. - **Organization**: A group of teams that share a specific set of permissions, defined by the roles of the organization. - **Service account**: A Kubernetes object that enables a workload to access - cluster resources that are assigned to a namespace. + cluster resources which are assigned to a namespace. Learn to [create and configure users and teams](create-users-and-teams-manually.md). ## Roles Roles define what operations can be done by whom. A role is a set of permitted -operations against a type of resource, like a container or volume, that's -assigned to a user or team with a grant. +operations against a type of resource, like a container or volume, which is +assigned to a user or a team with a grant. -For example, the built-in role, **Restricted Control**, includes permission to +For example, the built-in role, **Restricted Control**, includes permissions to view and schedule nodes but not to update nodes. A custom **DBA** role might -include permissions to `r-w-x` volumes and secrets. +include permissions to `r-w-x` (read, write, and execute) volumes and secrets. Most organizations use multiple roles to fine-tune the appropriate access. A given team or user may have different roles provided to them depending on what @@ -71,7 +71,7 @@ To control user access, cluster resources are grouped into Docker Swarm is a logical area for a Kubernetes cluster. Kubernetes comes with a `default` namespace for your cluster objects, plus two more namespaces for system and public resources. You can create custom namespaces, but unlike Swarm - collections, namespaces _can't be nested_. Resource types that users can + collections, namespaces _cannot be nested_. Resource types that users can access in a Kubernetes namespace include pods, deployments, network policies, nodes, services, secrets, and many more. @@ -80,11 +80,12 @@ Together, collections and namespaces are named *resource sets*. Learn to ## Grants -A grant is made up of *subject*, *role*, and *resource set*. +A grant is made up of a *subject*, a *role*, and a *resource set*. Grants define which users can access what resources in what way. Grants are -effectively Access Control Lists (ACLs), and when grouped together, they -provide comprehensive access policies for an entire organization. +effectively **Access Control Lists** (ACLs) which +provide comprehensive access policies for an entire organization when grouped +together. Only an administrator can manage grants, subjects, roles, and access to resources. @@ -96,6 +97,37 @@ resources. > and applies grants to users and teams. {: .important} +## Secure Kubernetes defaults + +For cluster security, only users and service accounts granted the `cluster-admin` ClusterRole for +all Kubernetes namespaces via a ClusterRoleBinding can deploy pods with privileged options. This prevents a +platform user from being able to bypass the Universal Control Plane Security Model. + +These privileged options include: + + - `PodSpec.hostIPC` - Prevents a user from deploying a pod in the host's IPC + Namespace. + - `PodSpec.hostNetwork` - Prevents a user from deploying a pod in the host's + Network Namespace. + - `PodSpec.hostPID` - Prevents a user from deploying a pod in the host's PID + Namespace. + - `SecurityContext.allowPrivilegeEscalation` - Prevents a child process + of a container from gaining more privileges than its parent. + - `SecurityContext.capabilities` - Prevents additional [Linux + Capabilities](https://docs.docker.com/engine/security/security/#linux-kernel-capabilities) + from being added to a pod. + - `SecurityContext.privileged` - Prevents a user from deploying a [Privileged + Container](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities). + - `Volume.hostPath` - Prevents a user from mounting a path from the host into + the container. This could be a file, a directory, or even the Docker Socket. + +If a user without a cluster admin role tries to deploy a pod with any of these +privileged options, an error similar to the following example is displayed: + +```bash +Error from server (Forbidden): error when creating "pod.yaml": pods "mypod" is forbidden: user "" is not an admin and does not have permissions to use privileged mode for resource +``` + ## Where to go next - [Create and configure users and teams](create-users-and-teams-manually.md) diff --git a/ee/ucp/images/interlock-install-4.png b/ee/ucp/images/interlock-install-4.png new file mode 100644 index 0000000000..0097bce3da Binary files /dev/null and b/ee/ucp/images/interlock-install-4.png differ diff --git a/ee/ucp/images/interlock_service_clusters.png~Raw content addition b/ee/ucp/images/interlock_service_clusters.png~Raw content addition new file mode 100644 index 0000000000..84ad5f1898 Binary files /dev/null and b/ee/ucp/images/interlock_service_clusters.png~Raw content addition differ diff --git a/ee/ucp/interlock/deploy/index.md b/ee/ucp/interlock/deploy/index.md index 0843ad7719..33acd7aec3 100644 --- a/ee/ucp/interlock/deploy/index.md +++ b/ee/ucp/interlock/deploy/index.md @@ -8,19 +8,14 @@ redirect_from: This topic covers deploying a layer 7 routing solution into a Docker Swarm to route traffic to Swarm services. Layer 7 routing is also referred to as an HTTP routing mesh. -1. [Prerequisites](#prerequisites) -2. [Enable layer 7 routing](#enable-layer-7-routing) -3. [Work with the core service configuration file](#work-with-the-core-service-configuration-file) -4. [Create a dedicated network for Interlock and extensions](#create-a-dedicated-network-for-Interlock-and-extensions) -5. [Create the Interlock service](#create-the-interlock-service) - ## Prerequisites - [Docker](https://www.docker.com) version 17.06 or later - Docker must be running in [Swarm mode](/engine/swarm/) - Internet access (see [Offline installation](./offline-install.md) for installing without internet access) -## Enable layer 7 routing +## Enable layer 7 routing via UCP + By default, layer 7 routing is disabled, so you must first enable this service from the UCP web UI. @@ -28,7 +23,7 @@ enable this service from the UCP web UI. 2. Navigate to **Admin Settings** 3. Select **Layer 7 Routing** and then select **Enable Layer 7 Routing** -![http routing mesh](../../images/interlock-install-3.png){: .with-border} +![http routing mesh](../../images/interlock-install-4.png){: .with-border} By default, the routing mesh service listens on port 8080 for HTTP and port 8443 for HTTPS. Change the ports if you already have services that are using @@ -46,8 +41,7 @@ and attaches it to the `ucp-interlock` network. This allows both services to communicate. 4. The `ucp-interlock-extension` generates a configuration to be used by the proxy service. By default the proxy service is NGINX, so this service -generates a standard NGINX configuration. -( Is this valid here????) UCP creates the `com.docker.ucp.interlock.conf-1` configuration file and uses it to configure all +generates a standard NGINX configuration. UCP creates the `com.docker.ucp.interlock.conf-1` configuration file and uses it to configure all the internal components of this service. 5. The `ucp-interlock` service takes the proxy configuration and uses it to start the `ucp-interlock-proxy` service. @@ -55,8 +49,7 @@ start the `ucp-interlock-proxy` service. At this point everything is ready for you to start using the layer 7 routing service with your swarm workloads. - -The following code sample provides a default UCP configuration: +The following code sample provides a default UCP configuration (this will be created automatically when enabling Interlock as per section [Enable layer 7 routing](#enable-layer-7-routing)): ```toml ListenAddr = ":8080" @@ -78,7 +71,7 @@ PollInterval = "3s" ProxyStopGracePeriod = "5s" ProxyConstraints = ["node.labels.com.docker.ucp.orchestrator.swarm==true", "node.platform.os==linux"] PublishMode = "ingress" - PublishedPort = 80 + PublishedPort = 8080 TargetPort = 80 PublishedSSLPort = 8443 TargetSSLPort = 443 @@ -123,7 +116,12 @@ PollInterval = "3s" HideInfoHeaders = false ``` +## Enable layer 7 routing manually + +Interlock can also be enabled from the command line by following the below sections. + ### Work with the core service configuration file + Interlock uses the TOML file for the core service configuration. The following example utilizes Swarm deployment and recovery features by creating a Docker Config object: ```bash @@ -143,9 +141,9 @@ PollInterval = "3s" ProxyStopGracePeriod = "3s" ServiceCluster = "" PublishMode = "ingress" - PublishedPort = 80 + PublishedPort = 8080 TargetPort = 80 - PublishedSSLPort = 443 + PublishedSSLPort = 8443 TargetSSLPort = 443 [Extensions.default.Config] User = "nginx" @@ -166,6 +164,7 @@ $> docker network create -d overlay interlock ``` ### Create the Interlock service + Now you can create the Interlock service. Note the requirement to constrain to a manager. The Interlock core service must have access to a Swarm manager, however the extension and proxy services are recommended to run on workers. See the [Production](./production.md) section for more information diff --git a/ee/ucp/kubernetes/install-cni-plugin.md b/ee/ucp/kubernetes/install-cni-plugin.md index b3b7e024ac..66bd5ee4e4 100644 --- a/ee/ucp/kubernetes/install-cni-plugin.md +++ b/ee/ucp/kubernetes/install-cni-plugin.md @@ -1,98 +1,119 @@ --- -title: Install a CNI plugin -description: Learn how to install a Container Networking Interface plugin on Docker Universal Control Plane. -keywords: ucp, cli, administration, kubectl, Kubernetes, cni, Container Networking Interface, flannel, weave, ipip, calico +title: Install an unmanaged CNI plugin +description: Learn how to install a Container Networking Interface (CNI) plugin on Docker Universal Control Plane. +keywords: ucp, kubernetes, cni, container networking interface, flannel, weave, calico --- -For Docker Universal Control Plane, [Project Calico](https://docs.projectcalico.org/v3.0/introduction/) -provides the secure networking functionality for the container communication with Kubernetes. +For Docker Universal Control Plane (UCP), [Calico](https://docs.projectcalico.org/v3.7/introduction/) +provides the secure networking functionality for container-to-container communication within +Kubernetes. UCP handles the lifecycle of Calico and packages it with UCP +installation and upgrade. Additionally, the Calico deployment included with +UCP is fully supported with Docker providing guidance on the +[CNI components](https://github.com/projectcalico/cni-plugin). -Docker EE supports Calico and installs the -built-in [Calico](https://github.com/projectcalico/cni-plugin) plugin, but you can override that and -install a Docker certified plugin. +At install time, UCP can be configured to install an alternative CNI plugin +to support alternative use cases. The alternative CNI plugin is certified by +Docker and its partners, and published on Docker Hub. UCP components are still +fully supported by Docker and respective partners. Docker will provide +pointers to basic configuration, however for additional guidance on managing third party +CNI components, the platform operator will need to refer to the partner documentation +or contact that third party. -> **Note**: The `--cni-installer-url` option is deprecated as of UCP 3.1. It is replaced by the `--unmanaged-cni` option. +## Install an unmanaged CNI plugin on Docker UCP -# Install UCP with a custom CNI plugin +Once a platform operator has complied with [UCP system +requirements](/ee/ucp/admin/install/system-requirements/) and +taken into consideration any requirements for the custom CNI plugin, you can +[run the UCP install command](/reference/ucp/3.1/cli/install/) with the `--unmanaged-cni` flag +to bring up the platform. -Modify the [UCP install command-line](../admin/install/index.md#step-4-install-ucp) -to add the `--cni-installer-url` [option](/reference/ucp/3.0/cli/install.md), -providing a URL for the location of the CNI plugin's YAML file: +This command will install UCP, and bring up components +like the user interface and the RBAC engine. UCP components that +require Kubernetes Networking, such as Metrics, will not start and will stay in +a `Container Creating` state in Kubernetes, until a CNI is installed. + +### Install UCP without a CNI plugin + +Once connected to a manager node with the Docker Enterprise Engine installed, +you are ready to install UCP with the `--unmanaged-cni` flag. ```bash docker container run --rm -it --name ucp \ -v /var/run/docker.sock:/var/run/docker.sock \ {{ page.ucp_org }}/{{ page.ucp_repo }}:{{ page.ucp_version }} install \ --host-address \ - --unmanaged-cni \ + --unmanaged-cni \ --interactive ``` -> **Note**: Setting `--unmanaged-cni` to `true` value installs UCP without a managed CNI plugin. UCP and the -> Kubernetes components will be running but pod-to-pod networking will not function until a CNI plugin is manually -> installed. This will impact some functionality of UCP until a CNI plugin is running. +Once the installation is complete, you will be able to access UCP in the browser. +Note that the manager node will be unhealthy as the kubelet will +report `NetworkPluginNotReady`. Additionally, the metrics in the UCP dashboard +will also be unavailable, as this runs in a Kubernetes pod. -You must provide a correct YAML installation file for the CNI plugin, but most -of the default files work on Docker EE with no modification. +### Configure CLI access to UCP -## YAML files for CNI plugins - -Use the following commands to get the YAML files for popular CNI plugins. - -- [Flannel](https://github.com/coreos/flannel) - ```bash - # Get the URL for the Flannel CNI plugin. - CNI_URL="https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml" - ``` -- [Weave](https://www.weave.works/) - ```bash - # Get the URL for the Weave CNI plugin. - CNI_URL="https://cloud.weave.works/k8s/net?k8s-version=Q2xpZW50IFZlcnNpb246IHZlcnNpb24uSW5mb3tNYWpvcjoiMSIsIE1pbm9yOiI5IiwgR2l0VmVyc2lvbjoidjEuOS4zIiwgR2l0Q29tbWl0OiJkMjgzNTQxNjU0NGYyOThjOTE5ZTJlYWQzYmUzZDA4NjRiNTIzMjNiIiwgR2l0VHJlZVN0YXRlOiJjbGVhbiIsIEJ1aWxkRGF0ZToiMjAxOC0wMi0wN1QxMjoyMjoyMVoiLCBHb1ZlcnNpb246ImdvMS45LjIiLCBDb21waWxlcjoiZ2MiLCBQbGF0Zm9ybToibGludXgvYW1kNjQifQpTZXJ2ZXIgVmVyc2lvbjogdmVyc2lvbi5JbmZve01ham9yOiIxIiwgTWlub3I6IjgrIiwgR2l0VmVyc2lvbjoidjEuOC4yLWRvY2tlci4xNDMrYWYwODAwNzk1OWUyY2UiLCBHaXRDb21taXQ6ImFmMDgwMDc5NTllMmNlYWUxMTZiMDk4ZWNhYTYyNGI0YjI0MjBkODgiLCBHaXRUcmVlU3RhdGU6ImNsZWFuIiwgQnVpbGREYXRlOiIyMDE4LTAyLTAxVDIzOjI2OjE3WiIsIEdvVmVyc2lvbjoiZ28xLjguMyIsIENvbXBpbGVyOiJnYyIsIFBsYXRmb3JtOiJsaW51eC9hbWQ2NCJ9Cg==" - ``` - If you have kubectl available, for example by using - [Docker Desktop for Mac](/docker-for-mac/kubernetes.md), you can use the following - command to get the URL for the [Weave](https://www.weave.works/) CNI plugin: - ```bash - # Get the URL for the Weave CNI plugin. - CNI_URL="https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" - ``` -- [Romana](http://docs.romana.io/) - ```bash - # Get the URL for the Romana CNI plugin. - CNI_URL="https://raw.githubusercontent.com/romana/romana/master/docs/kubernetes/romana-kubeadm.yml" - ``` - -## Disable IP in IP overlay tunneling - -The Calico CNI plugin supports both overlay (IPIP) and underlay forwarding -technologies. By default, Docker UCP uses IPIP overlay tunneling. - -If you're used to managing applications at the network level through the -underlay visibility, or you want to reuse existing networking tools in the -underlay, you may want to disable the IPIP functionality. Run the following -commands on the Kubernetes master node to disable IPIP overlay tunneling. +Next, a platform operator should log into UCP, download a UCP client bundle, and +configure the Kubernetes CLI tool, `kubectl`. See [CLI Based +Access](ee/ucp/user-access/cli/#download-client-certificates) for more details. + +With `kubectl`, you can see that the UCP components running on +Kubernetes are still pending, waiting for a CNI driver before becoming +available. ```bash -# Exec into the Calico Kubernetes controller container. -docker exec -it $(docker ps --filter name=k8s_calico-kube-controllers_calico-kube-controllers -q) sh - -# Download calicoctl -wget https://github.com/projectcalico/calicoctl/releases/download/v3.1.1/calicoctl && chmod +x calicoctl - -# Get the IP pool configuration. -./calicoctl get ippool -o yaml > ippool.yaml - -# Edit the file: Disable IPIP in ippool.yaml by setting "ipipMode: Never". - -# Apply the edited file to the Calico plugin. -./calicoctl apply -f ippool.yaml - +$ kubectl get nodes +NAME STATUS ROLES AGE VERSION +manager-01 NotReady master 10m v1.11.9-docker-1 + +$ kubectl get pods -n kube-system -o wide +NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE +compose-565f7cf9ff-gq2gv 0/1 Pending 0 10m +compose-api-574d64f46f-r4c5g 0/1 Pending 0 10m +kube-dns-6d96c4d9c6-8jzv7 0/3 Pending 0 10m +ucp-metrics-nwt2z 0/3 ContainerCreating 0 10m manager-01 ``` -These steps disable overlay tunneling, and Calico uses the underlay networking, -in environments where it's supported. +### Install an unmanaged CNI plugin + +You can use`kubectl` to install a custom CNI plugin on UCP. +Alternative CNI plugins are Weave, Flannel, Canal, Romana and many more. +Platform operators have complete flexibility on what to install, but Docker +will not support the CNI plugin. + +The steps for installing a CNI plugin typically include: +- Downloading the relevant upstream CNI binaries from +https://github.com/containernetworking/cni/releases/tag/ +- Placing them in `/opt/cni/bin` +- Downloading the relevant CNI plugin's Kubernetes Manifest YAML, and +- Running `$ kubectl apply -f .yaml` + +Follow the CNI plugin documentation for specific installation +instructions. + +> While troubleshooting a custom CNI plugin, you may wish to access logs +> within the kubelet. Connect to a UCP manager node and run +> `$ docker logs ucp-kubelet`. + +### Verify the UCP installation + +Upon successful installation of the CNI plugin, the related UCP components should have +a `Running` status as pods start to become available. + +``` +$ kubectl get pods -n kube-system -o wide +NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE +compose-565f7cf9ff-gq2gv 1/1 Running 0 21m 10.32.0.2 manager-01 +compose-api-574d64f46f-r4c5g 1/1 Running 0 21m 10.32.0.3 manager-01 +kube-dns-6d96c4d9c6-8jzv7 3/3 Running 0 22m 10.32.0.5 manager-01 +ucp-metrics-nwt2z 3/3 Running 0 22m 10.32.0.4 manager-01 +weave-net-wgvcd 2/2 Running 0 8m 172.31.6.95 manager-01 +``` + +> **Note**: The above example deployment uses Weave. If you are using an alternative +> CNI plugin, look for the relevant name and review its status. ## Where to go next -- [Install UCP for production](../admin/install.md) -- [Deploy a workload to a Kubernetes cluster](../kubernetes.md) +- [Make your Cluster Highly Available](https://docs.docker.com/ee/ucp/admin/install/#step-6-join-manager-nodes) +- [Install an Ingress Controller on Kubernetes](ee/ucp/kubernetes/layer-7-routing/) diff --git a/ee/ucp/kubernetes/storage/use-azure-disk.md b/ee/ucp/kubernetes/storage/use-azure-disk.md new file mode 100644 index 0000000000..a2471925a9 --- /dev/null +++ b/ee/ucp/kubernetes/storage/use-azure-disk.md @@ -0,0 +1,239 @@ +--- +title: Configuring Azure Disk Storage for Kubernetes +description: Learn how to add persistent storage to your Docker Enterprise clusters running on Azure with Azure Disk. +keywords: Universal Control Plane, UCP, Docker EE, Kubernetes, storage, volume +redirect_from: +--- + +Platform operators can provide persistent storage for workloads running on +Docker Enterprise and Microsoft Azure by using Azure Disk. Platform +operators can either pre-provision Azure Disks to be consumed by Kubernetes +Pods, or can use the Azure Kubernetes integration to dynamically provision Azure +Disks on demand. + + +## Prerequisites + +This guide assumes you have already provisioned a UCP environment on +Microsoft Azure. The Cluster must be provisioned after meeting all of the +prerequisites listed in [Install UCP on +Azure](/ee/ucp/admin/install/install-on-azure.md). + +Additionally, this guide uses the Kubernetes Command Line tool `$ +kubectl` to provision Kubernetes objects within a UCP cluster. Therefore, this +tool must be downloaded, along with a UCP client bundle. For more +information on configuring CLI access for UCP, see [CLI Based +Access](/ee/ucp/user-access/cli/). + +## Manually provision Azure Disks + +An operator can use existing Azure Disks or manually provision new ones to +provide persistent storage for Kubernetes Pods. Azure Disks can be manually +provisioned in the Azure Portal, using ARM Templates or the Azure CLI. The +following example uses the Azure CLI to manually provision an Azure +Disk. + +```bash +$ RG=myresourcegroup + +$ az disk create \ + --resource-group $RG \ + --name k8s_volume_1 \ + --size-gb 20 \ + --query id \ + --output tsv +``` + +Using the Azure CLI command in the previous example should return the Azure ID of the Azure Disk +Object. If you are provisioning Azure resources using an alternative method, +make sure you retrieve the Azure ID of the Azure Disk, because it is needed for another step. + +``` +/subscriptions//resourceGroups//providers/Microsoft.Compute/disks/ +``` + +You can now create Kubernetes Objects that refer to this Azure Disk. The following +example uses a Kubernetes Pod. However, the same Azure Disk syntax can be +used for DaemonSets, Deployments, and StatefulSets. In the following example, the +Azure Disk Name and ID reflect the manually created Azure Disk. + +```bash +$ cat </resourceGroups//providers/Microsoft.Compute/disks/ +EOF +``` + +## Dynamically provision Azure Disks + +### Define the Azure Disk Storage Class + +Kubernetes can dynamically provision Azure Disks using the Azure Kubernetes +integration, which was configured when UCP was installed. For Kubernetes +to determine which APIs to use when provisioning storage, you must +create Kubernetes Storage Classes specific to each storage backend. For more +information on Kubernetes Storage Classes, see [Storage +Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/). + +In Azure there are 2 different Azure Disk types that can be consumed by +Kubernetes: Azure Disk Standard Volumes and Azure Disk Premium Volumes. For more +information on their differences, see [Azure +Disks](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/disks-types). + +Depending on your use case, you can deploy one or both of the Azure Disk storage Classes (Standard and Advanced). + +To create a Standard Storage Class: + +```bash +$ cat < + Warning FailedAttachVolume 7s (x11 over 6m) attachdetach-controller AttachVolume.Attach failed for volume "pvc-6b09dae3-6ad6-11e9-9509-0242ac11000b" : Attach volume "kubernetes-dynamic-pvc-6b09dae3-6ad6-11e9-9509-0242ac11000b" to instance "/subscriptions//resourceGroups//providers/Microsoft.Compute/virtualMachines/worker-03" failed with compute.VirtualMachinesClient#CreateOrUpdate: Failure sending request: StatusCode=409 -- Original Error: failed request: autorest/azure: Service returned an error. Status= Code="OperationNotAllowed" Message="The maximum number of data disks allowed to be attached to a VM of this size is 4." Target="dataDisks" +``` + +## Where to go next + +- [Deploy an Ingress Controller on + Kubernetes](/ee/ucp/kubernetes/layer-7-routing/) +- [Discover Network Encryption on + Kubernetes](/ee/ucp/kubernetes/kubernetes-network-encryption/) diff --git a/ee/ucp/kubernetes/storage/use-azure-files.md b/ee/ucp/kubernetes/storage/use-azure-files.md new file mode 100644 index 0000000000..6ba7ead84d --- /dev/null +++ b/ee/ucp/kubernetes/storage/use-azure-files.md @@ -0,0 +1,246 @@ +--- +title: Configuring Azure Files Storage for Kubernetes +description: Learn how to add persistent storage to your Docker Enterprise clusters running on Azure with Azure Files. +keywords: Universal Control Plane, UCP, Docker EE, Kubernetes, storage, volume +redirect_from: +--- + +Platform operators can provide persistent storage for workloads running on +Docker Enterprise and Microsoft Azure by using Azure Files. You can either +pre-provision Azure Files Shares to be consumed by +Kubernetes Pods or can you use the Azure Kubernetes integration to dynamically +provision Azure Files Shares on demand. + +## Prerequisites + +This guide assumes you have already provisioned a UCP environment on +Microsoft Azure. The cluster must be provisioned after meeting all +prerequisites listed in [Install UCP on +Azure](/ee/ucp/admin/install/install-on-azure.md). + +Additionally, this guide uses the Kubernetes Command Line tool `$ +kubectl` to provision Kubernetes objects within a UCP cluster. Therefore, you must download +this tool along with a UCP client bundle. For more +information on configuring CLI access to UCP, see [CLI Based +Access](/ee/ucp/user-access/cli/). + +## Manually Provisioning Azure Files + +You can use existing Azure Files Shares or manually provision new ones to +provide persistent storage for Kubernetes Pods. Azure Files Shares can be +manually provisioned in the Azure Portal using ARM Templates or using the Azure +CLI. The following example uses the Azure CLI to manually provision +Azure Files Shares. + +### Creating an Azure Storage Account + +When manually creating an Azure Files Share, first create an Azure +Storage Account for the file shares. If you have already provisioned +a Storage Account, you can skip to [Creating an Azure Files +Share](#creating-an-azure-file-share). + +> **Note**: the Azure Kubernetes Driver does not support Azure Storage Accounts +> created using Azure Premium Storage. + +```bash +$ REGION=ukwest +$ SA=mystorageaccount +$ RG=myresourcegroup + +$ az storage account create \ + --name $SA \ + --resource-group $RG \ + --location $REGION \ + --sku Standard_LRS +``` + +### Creating an Azure Files Share + +Next, provision an Azure Files Share. The size of this share can be +adjusted to fit the end user's requirements. If you have already created an +Azure Files Share, you can skip to [Configuring a Kubernetes +Secret](#configuring-a-kubernetes-secret). + +```bash +$ SA=mystorageaccount +$ RG=myresourcegroup +$ FS=myfileshare +$ SIZE=5 + +# This Azure Collection String can also be found in the Azure Portal +$ export AZURE_STORAGE_CONNECTION_STRING=`az storage account show-connection-string --name $SA --resource-group $RG -o tsv` + +$ az storage share create \ + --name $FS \ + --quota $SIZE \ + --connection-string $AZURE_STORAGE_CONNECTION_STRING +``` + +### Configuring a Kubernetes Secret + +After a File Share has been created, you must load the Azure Storage +Account Access key as a Kubernetes Secret into UCP. This provides access to +the file share when Kubernetes attempts to mount the share into a pod. This key +can be found in the Azure Portal or retrieved as shown in the following example by the Azure CLI: + +```bash +$ SA=mystorageaccount +$ RG=myresourcegroup +$ FS=myfileshare + +# The Azure Storage Account Access Key can also be found in the Azure Portal +$ STORAGE_KEY=$(az storage account keys list --resource-group $RG --account-name $SA --query "[0].value" -o tsv) + +$ kubectl create secret generic azure-secret \ + --from-literal=azurestorageaccountname=$SA \ + --from-literal=azurestorageaccountkey=$STORAGE_KEY +``` + +### Mount the Azure Files Share into a Kubernetes Pod + +The final step is to mount the Azure Files Share, using the Kubernetes Secret, into +a Kubernetes Pod. The following code creates a standalone Kubernetes pod, but you +can also use alternative Kubernetes Objects such as Deployments, DaemonSets, or +StatefulSets, with the existing Azure Files Share. + +```bash +$ FS=myfileshare + +$ cat < Today, only the Standard Storage Class is supported when using the Azure +> Kubernetes Plugin. File shares using the Premium Storage Class will fail to +> mount. + +```bash +$ cat < - [Kubernetes on Docker Desktop for Windows](/docker-for-windows/kubernetes/){: target="_blank" class="_"} is available in -[18.02 Edge (win50)](/docker-for-windows/edge-release-notes/#docker-community-edition-18020-ce-rc1-win50-2018-01-26){: target="_blank" class="_"} and higher edge channels only. +[18.06.0 CE (win70)](/docker-for-windows/release-notes/){: target="_blank" class="_"} and higher as well as edge channels. [Install Docker](/engine/installation/index.md){: class="button outline-btn"}
diff --git a/install/linux/docker-ee/ubuntu.md b/install/linux/docker-ee/ubuntu.md index 979220fc50..dae6557ba2 100644 --- a/install/linux/docker-ee/ubuntu.md +++ b/install/linux/docker-ee/ubuntu.md @@ -47,7 +47,7 @@ Older versions of Docker were called `docker` or `docker-engine`. In addition, if you are upgrading from Docker CE to Docker EE, remove the Docker CE package. ```bash -$ sudo apt-get remove docker docker-engine docker-ce docker.io +$ sudo apt-get remove docker docker-engine docker-ce docker-ce-cli docker.io ``` It's OK if `apt-get` reports that none of these packages are installed. diff --git a/network/macvlan.md b/network/macvlan.md index e0f6c4013d..42b441d7e7 100644 --- a/network/macvlan.md +++ b/network/macvlan.md @@ -1,5 +1,5 @@ --- -title: Use Macvlan networks +title: Use macvlan networks description: All about using macvlan to make your containers appear like physical machines on the network keywords: network, macvlan, standalone redirect_from: @@ -13,25 +13,27 @@ this type of situation, you can use the `macvlan` network driver to assign a MAC address to each container's virtual network interface, making it appear to be a physical network interface directly connected to the physical network. In this case, you need to designate a physical interface on your Docker host to use for -the Macvlan, as well as the subnet and gateway of the Macvlan. You can even -isolate your Macvlan networks using different physical network interfaces. +the `macvlan`, as well as the subnet and gateway of the `macvlan`. You can even +isolate your `macvlan` networks using different physical network interfaces. Keep the following things in mind: - It is very easy to unintentionally damage your network due to IP address exhaustion or to "VLAN spread", which is a situation in which you have an inappropriately large number of unique MAC addresses in your network. + - Your networking equipment needs to be able to handle "promiscuous mode", where one physical interface can be assigned multiple MAC addresses. + - If your application can work using a bridge (on a single Docker host) or overlay (to communicate across multiple Docker hosts), these solutions may be better in the long term. ## Create a macvlan network -When you create a Macvlan network, it can either be in bridge mode or 802.1q +When you create a `macvlan` network, it can either be in bridge mode or 802.1q trunk bridge mode. -- In bridge mode,Macvlan traffic goes through a physical device on the host. +- In bridge mode, `macvlan` traffic goes through a physical device on the host. - In 802.1q trunk bridge mode, traffic goes through an 802.1q sub-interface which Docker creates on the fly. This allows you to control routing and @@ -39,7 +41,7 @@ trunk bridge mode. ### Bridge mode -To create a Macvlan network which bridges with a given physical network +To create a `macvlan` network which bridges with a given physical network interface, use `--driver macvlan` with the `docker network create` command. You also need to specify the `parent`, which is the interface the traffic will physically go through on the Docker host. @@ -47,18 +49,18 @@ physically go through on the Docker host. ```bash $ docker network create -d macvlan \ --subnet=172.16.86.0/24 \ - --gateway=172.16.86.1 \ + --gateway=172.16.86.1 \ -o parent=eth0 pub_net ``` -If you need to exclude IP addresses from being used in the Macvlan network, such +If you need to exclude IP addresses from being used in the `macvlan` network, such as when a given IP address is already in use, use `--aux-addresses`: ```bash -$ docker network create -d macvlan \ - --subnet=192.168.32.0/24 \ +$ docker network create -d macvlan \ + --subnet=192.168.32.0/24 \ --ip-range=192.168.32.128/25 \ - --gateway=192.168.32.254 \ + --gateway=192.168.32.254 \ --aux-address="my-router=192.168.32.129" \ -o parent=eth0 macnet32 ``` @@ -70,7 +72,7 @@ Docker interprets that as a sub-interface of `eth0` and creates the sub-interfac automatically. ```bash -$ docker network create -d macvlan \ +$ docker network create -d macvlan \ --subnet=192.168.50.0/24 \ --gateway=192.168.50.1 \ -o parent=eth0.50 macvlan50 @@ -85,26 +87,25 @@ instead, and get an L2 bridge. Specify `-o ipvlan_mode=l2`. $ docker network create -d ipvlan \ --subnet=192.168.210.0/24 \ --subnet=192.168.212.0/24 \ - --gateway=192.168.210.254 \ - --gateway=192.168.212.254 \ + --gateway=192.168.210.254 \ + --gateway=192.168.212.254 \ -o ipvlan_mode=l2 ipvlan210 ``` ## Use IPv6 If you have [configured the Docker daemon to allow IPv6](/config/daemon/ipv6.md), -you can use dual-stack IPv4/IPv6 Macvlan networks. +you can use dual-stack IPv4/IPv6 `macvlan` networks. ```bash -$ docker network create -d macvlan \ +$ docker network create -d macvlan \ --subnet=192.168.216.0/24 --subnet=192.168.218.0/24 \ - --gateway=192.168.216.1 --gateway=192.168.218.1 \ + --gateway=192.168.216.1 --gateway=192.168.218.1 \ --subnet=2001:db8:abc8::/64 --gateway=2001:db8:abc8::10 \ -o parent=eth0.218 \ -o macvlan_mode=bridge macvlan216 ``` - ## Next steps - Go through the [macvlan networking tutorial](/network/network-tutorial-macvlan.md) diff --git a/reference/ucp/3.1/cli/backup.md b/reference/ucp/3.1/cli/backup.md index 97250d35a8..b67365047a 100644 --- a/reference/ucp/3.1/cli/backup.md +++ b/reference/ucp/3.1/cli/backup.md @@ -37,10 +37,11 @@ Note: ## Options -| Option | Description | -|:--------------------------|:---------------------------| -|`--debug, D`|Enable debug mode| -|`--jsonlog`|Produce json formatted output for easier parsing| -|`--interactive, i`|Run in interactive mode and prompt for configuration values| -|`--id`|The ID of the UCP instance to back up| -|`--passphrase`|Encrypt the tar file with a passphrase| +| Option | Description | +|:-----------------------|:--------------------------------------------------------------------| +| `--debug, -D` | Enable debug mode | +| `--jsonlog` | Produce json formatted output for easier parsing | +| `--interactive, -i` | Run in interactive mode and prompt for configuration values | +| `--id` *value* | The ID of the UCP instance to back up | +| `--no-passphrase` | Opt out to encrypt the tar file with a passphrase (not recommended) | +| `--passphrase` *value* | Encrypt the tar file with a passphrase | diff --git a/reference/ucp/3.1/cli/dump-certs.md b/reference/ucp/3.1/cli/dump-certs.md index 928bbbba1c..008e6cb912 100644 --- a/reference/ucp/3.1/cli/dump-certs.md +++ b/reference/ucp/3.1/cli/dump-certs.md @@ -27,9 +27,9 @@ to configure DTR. ## Options -| Option | Description | -|:--------------------------|:---------------------------| -|`--debug, D`|Enable debug mode| -|`--jsonlog`|Produce json formatted output for easier parsing| -|`--ca`|Only print the contents of the ca.pem file| -|`--cluster`|Print the internal UCP swarm root CA and cert instead of the public server cert| +| Option | Description | +|:-------------|:--------------------------------------------------------------------------------| +| `--debug, D` | Enable debug mode | +| `--jsonlog` | Produce json formatted output for easier parsing | +| `--ca` | Only print the contents of the ca.pem file | +| `--cluster` | Print the internal UCP swarm root CA and cert instead of the public server cert | diff --git a/reference/ucp/3.1/cli/id.md b/reference/ucp/3.1/cli/id.md index 0721e0e1c6..14387cd983 100644 --- a/reference/ucp/3.1/cli/id.md +++ b/reference/ucp/3.1/cli/id.md @@ -23,3 +23,9 @@ a client bundle. This ID is used by other commands as confirmation. +## Options + +| Option | Description | +|:-------------|:-------------------------------------------------| +| `--debug, D` | Enable debug mode | +| `--jsonlog` | Produce json formatted output for easier parsing | diff --git a/reference/ucp/3.1/cli/images.md b/reference/ucp/3.1/cli/images.md index 2980128ae0..9a0fb8145e 100644 --- a/reference/ucp/3.1/cli/images.md +++ b/reference/ucp/3.1/cli/images.md @@ -24,11 +24,11 @@ the ones that are missing. ## Options -| Option | Description | -|:--------------------------|:---------------------------| -|`--debug, D`|Enable debug mode| -|`--jsonlog`|Produce json formatted output for easier parsing| -|`--pull`|Pull UCP images: `always`, when `missing`, or `never`| -|`--registry-username`|Username to use when pulling images| -|`--registry-password`|Password to use when pulling images| -|`--list`|List all images used by UCP but don't pull them| +| Option | Description | +|:------------------------------|:-----------------------------------------------------| +| `--debug, D` | Enable debug mode | +| `--jsonlog` | Produce json formatted output for easier parsing | +| `--list` | List all images used by UCP but don't pull them | +| `--pull` *value* | Pull UCP images: `always`, when `missing`, or `never`| +| `--registry-password` *value* | Password to use when pulling images | +| `--registry-username` *value* | Username to use when pulling images | diff --git a/reference/ucp/3.1/cli/index.md b/reference/ucp/3.1/cli/index.md index 12e71bdcc2..f41b7283c9 100644 --- a/reference/ucp/3.1/cli/index.md +++ b/reference/ucp/3.1/cli/index.md @@ -31,15 +31,16 @@ docker container run -it --rm \ | Option | Description | |:-----------------|:----------------------------------------------------------| +| `backup` | Create a backup of a UCP manager node | +| `dump-certs` | Print the public certificates used by this UCP web server | +| `example-config` | Display an example configuration file for UCP | +| `help` | Shows a list of commands or help for one command | +| `id` | Print the ID of UCP running on this node | +| `images` | Verify the UCP images on this node | | `install` | Install UCP on this node | | `restart` | Start or restart UCP components running on this node | -| `stop` | Stop UCP components running on this node | -| `upgrade` | Upgrade the UCP cluster | -| `images` | Verify the UCP images on this node | -| `uninstall-ucp` | Uninstall UCP from this swarm | -| `dump-certs` | Print the public certificates used by this UCP web server | -| `support` | Create a support dump for this UCP node | -| `id` | Print the ID of UCP running on this node | -| `backup` | Create a backup of a UCP manager node | | `restore` | Restore a UCP cluster from a backup | -| `example-config` | Display an example configuration file for UCP | +| `stop` | Stop UCP components running on this node | +| `support` | Create a support dump for this UCP node | +| `uninstall-ucp` | Uninstall UCP from this swarm | +| `upgrade` | Upgrade the UCP cluster | diff --git a/reference/ucp/3.1/cli/install.md b/reference/ucp/3.1/cli/install.md index 96979016cc..63437e26ce 100644 --- a/reference/ucp/3.1/cli/install.md +++ b/reference/ucp/3.1/cli/install.md @@ -42,45 +42,46 @@ If you are installing on Azure, see [Install UCP on Azure](/ee/ucp/admin/install ## Options -| Option | Description | -|:-------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `--admin-password` | The UCP administrator password. Must be at least 8 characters. | -| `--admin-username` | The UCP administrator username | -| `--binpack` | Set the Docker Swarm scheduler to binpack mode. Used for backwards compatibility | -| `--cloud-provider` | The cloud provider for the cluster -| `--cni-installer-url` | Deprecated feature. A URL pointing to a Kubernetes YAML file to be used as an installer for the CNI plugin of the cluster. If specified, the default CNI plugin is not installed. If the URL uses the HTTPS scheme, no certificate verification is performed. | -| `--controller-port` | Port for the web UI and API -| `--data-path-addr` | Address or interface to use for data path traffic. Format: IP address or network interface name -| `--debug, D` | Enable debug mode | -| `--disable-tracking` | Disable anonymous tracking and analytics | -| `--disable-usage` | Disable anonymous usage reporting | -| `--dns` | Set custom DNS servers for the UCP containers | -| `--dns-opt` | Set DNS options for the UCP containers | -| `--dns-search` | Set custom DNS search domains for the UCP containers | -| `--enable-profiling` | Enable performance profiling | -| `--existing-config` | Use the latest existing UCP config during this installation. The install fails if a config is not found. | -| `--external-server-cert` | Use the certificates in the `ucp-controller-server-certs` volume instead of generating self-signed certs during installation | -| `--external-service-lb` | Set the external service load balancer reported in the UI | -| `--force-insecure-tcp` | Force install to continue even with unauthenticated Docker Engine ports | -| `--force-minimums` | Force the install/upgrade even if the system doesn't meet the minimum requirements. | -| `--host-address` | The network address to advertise to other nodes. Format: IP address or network interface name | -| `--interactive, i` | Run in interactive mode and prompt for configuration values | -| `--jsonlog` | Produce json formatted output for easier parsing | -| `--kube-apiserver-port` | Port for the Kubernetes API server (default: 6443) | -| `--kv-snapshot-count` | Number of changes between key-value store snapshots | -| `--kv-timeout` | Timeout in milliseconds for the key-value store | -| `--license` | Add a license: e.g.` --license "$(cat license.lic)" ` | -| `--pod-cidr` | Kubernetes cluster IP pool for the pods to allocated IPs from (Default: `192.168.0.0/16`) | -|`--service-cluster-ip-range`| Sets the subnet pool from which the IP for Services should be allocated (Default is `10.96.0.0/16`). | -| `--preserve-certs` | Don't generate certificates if they already exist | -| `--pull` | Pull UCP images: `always`, when `missing`, or `never` | -| `--random` | Set the Docker Swarm scheduler to random mode. Used for backwards compatibility | -| `--registry-username` | Username to use when pulling images | -| `--registry-password` | Password to use when pulling images | -| `--san` | Add subject alternative names to certificates (e.g. --san www1.acme.com --san www2.acme.com) | -| `--skip-cloud-provider` | Disables checks that rely on detecting the cloud provider (if any) on which the cluster is currently running. | -| `--swarm-experimental` | Enable Docker Swarm experimental features. Used for backwards compatibility | -| `--swarm-port` | Port for the Docker Swarm manager. Used for backwards compatibility | -| `--swarm-grpc-port` | Port for communication between nodes | -| `--unlock-key` | The unlock key for this swarm-mode cluster, if one exists. | -| `--unmanaged-cni` |The default value of `false` indicates that Kubernetes networking is managed by UCP with its default managed CNI plugin, Calico. When set to `true`, UCP does not deploy or manage the lifecycle of the default CNI plugin - the CNI plugin is deployed and managed independently of UCP. Note that when `unmanaged-cni=true`, networking in the cluster will not function for Kubernetes until a CNI plugin is deployed. | +| Option | Description | +|:--------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `--debug, -D` | Enable debug mode | +| `--jsonlog` | Produce json formatted output for easier parsing | +| `--interactive, -i` | Run in interactive mode and prompt for configuration values | +| `--admin-password` *value* | The UCP administrator password [$UCP_ADMIN_PASSWORD] | +| `--admin-username` *value* | The UCP administrator username [$UCP_ADMIN_USER] | +| `--binpack` | Set the Docker Swarm scheduler to binpack mode. Used for backwards compatibility | +| `--cloud-provider` *value* | The cloud provider for the cluster | +| `--cni-installer-url` *value* | A URL pointing to a kubernetes YAML file to be used as an installer for the CNI plugin of the cluster. If specified, the default CNI plugin will not be installed. If the URL is using the HTTPS scheme, no certificate verification will be performed | +| `--controller-port` *value* | Port for the web UI and API (default: 443) | +| `--data-path-addr` *value* | Address or interface to use for data path traffic. Format: IP address or network interface name [$UCP_DATA_PATH_ADDR] | +| `--disable-tracking` | Disable anonymous tracking and analytics | +| `--disable-usage` | Disable anonymous usage reporting | +| `--dns-opt` *value* | Set DNS options for the UCP containers [$DNS_OPT] | +| `--dns-search` *value* | Set custom DNS search domains for the UCP containers [$DNS_SEARCH] | +| `--dns` *value* | Set custom DNS servers for the UCP containers [$DNS] | +| `--enable-profiling` | Enable performance profiling | +| `--existing-config` | Use the latest existing UCP config during this installation. The install will fail if a config is not found | +| `--external-server-cert` | Customize the certificates used by the UCP web server | +| `--external-service-lb` *value* | Set the IP address of the load balancer that published services are expected to be reachable on | +| `--force-insecure-tcp` | Force install to continue even with unauthenticated Docker Engine ports. | +| `--force-minimums` | Force the install/upgrade even if the system does not meet the minimum requirements | +| `--host-address` *value* | The network address to advertise to other nodes. Format: IP address or network interface name [$UCP_HOST_ADDRESS] | +| `--kube-apiserver-port` *value* | Port for the Kubernetes API server (default: 6443) | +| `--kv-snapshot-count` *value* | Number of changes between key-value store snapshots (default: 20000) [$KV_SNAPSHOT_COUNT] | +| `--kv-timeout` *value* | Timeout in milliseconds for the key-value store (default: 5000) [$KV_TIMEOUT] | +| `--license` *value* | Add a license: e.g. --license "$(cat license.lic)" [$UCP_LICENSE] | +| `--nodeport-range` *value* | Allowed port range for Kubernetes services of type NodePort (Default: 32768-35535) (default: "32768-35535") | +| `--pod-cidr` *value* | Kubernetes cluster IP pool for the pods to allocated IP from (Default: 192.168.0.0/16) (default: "192.168.0.0/16") | +| `--preserve-certs` | Don't generate certificates if they already exist | +| `--pull` *value* | Pull UCP images: 'always', when 'missing', or 'never' (default: "missing") | +| `--random` | Set the Docker Swarm scheduler to random mode. Used for backwards compatibility | +| `--registry-password` *value* | Password to use when pulling images [$REGISTRY_PASSWORD] | +| `--registry-username` *value* | Username to use when pulling images [$REGISTRY_USERNAME] | +| `--san` *value* | Add subject alternative names to certificates (e.g. --san www1.acme.com --san www2.acme.com) [$UCP_HOSTNAMES] | +| `--skip-cloud-provider-check` | Disables checks which rely on detecting which (if any) cloud provider the cluster is currently running on | +| `--swarm-experimental` | Enable Docker Swarm experimental features. Used for backwards compatibility | +| `--swarm-grpc-port` *value* | Port for communication between nodes (default: 2377) | +| `--swarm-port` *value* | Port for the Docker Swarm manager. Used for backwards compatibility (default: 2376) | +| `--unlock-key` *value* | The unlock key for this swarm-mode cluster, if one exists. [$UNLOCK_KEY] | +| `--unmanaged-cni` | Flag to indicate if cni provider is calico and managed by UCP (calico is the default CNI provider) | | + diff --git a/reference/ucp/3.1/cli/restart.md b/reference/ucp/3.1/cli/restart.md index f1824f28ed..d8e50fc9cf 100644 --- a/reference/ucp/3.1/cli/restart.md +++ b/reference/ucp/3.1/cli/restart.md @@ -18,7 +18,7 @@ docker container run --rm -it \ ## Options -| Option | Description | -|:--------------------------|:---------------------------| -|`--debug, D`|Enable debug mode| -|`--jsonlog`|Produce json formatted output for easier parsing| +| Option | Description | +|:-------------|:-------------------------------------------------| +| `--debug, D` | Enable debug mode | +| `--jsonlog` | Produce json formatted output for easier parsing | diff --git a/reference/ucp/3.1/cli/restore.md b/reference/ucp/3.1/cli/restore.md index 6552c6b4f9..dc528345e3 100644 --- a/reference/ucp/3.1/cli/restore.md +++ b/reference/ucp/3.1/cli/restore.md @@ -58,13 +58,13 @@ Notes: ## Options -| Option | Description | -|:-------------------|:----------------------------------------------------------------------------------------------| -| `--debug, D` | Enable debug mode | -| `--jsonlog` | Produce json formatted output for easier parsing | -| `--interactive, i` | Run in interactive mode and prompt for configuration values | -| `--passphrase` | Decrypt the backup tar file with the provided passphrase | -| `--san` | Add subject alternative names to certificates (e.g. --san www1.acme.com --san www2.acme.com) | -| `--host-address` | The network address to advertise to other nodes. Format: IP address or network interface name | -| `--data-path-addr` | Address or interface to use for data path traffic | -| `--unlock-key` | The unlock key for this swarm-mode cluster, if one exists. | +| Option | Description | +|:---------------------------|:----------------------------------------------------------------------------------------------| +| `--debug, D` | Enable debug mode | +| `--jsonlog` | Produce json formatted output for easier parsing | +| `--interactive, i` | Run in interactive mode and prompt for configuration values | +| `--data-path-addr` *value* | Address or interface to use for data path traffic | +| `--host-address` *value* | The network address to advertise to other nodes. Format: IP address or network interface name | +| `--passphrase` *value* | Decrypt the backup tar file with the provided passphrase | +| `--san` *value* | Add subject alternative names to certificates (e.g. --san www1.acme.com --san www2.acme.com) | +| `--unlock-key` *value* | The unlock key for this swarm-mode cluster, if one exists. | diff --git a/reference/ucp/3.1/cli/stop.md b/reference/ucp/3.1/cli/stop.md index a246cb9fdf..3e9fbe58ba 100644 --- a/reference/ucp/3.1/cli/stop.md +++ b/reference/ucp/3.1/cli/stop.md @@ -18,7 +18,7 @@ docker container run --rm -it \ ## Options -| Option | Description | -|:--------------------------|:---------------------------| -|`--debug, D`|Enable debug mode| -|`--jsonlog`|Produce json formatted output for easier parsing| +| Option | Description | +|:-------------|:-------------------------------------------------| +| `--debug, D` | Enable debug mode | +| `--jsonlog` | Produce json formatted output for easier parsing | diff --git a/reference/ucp/3.1/cli/support.md b/reference/ucp/3.1/cli/support.md index 7649e26824..32ef42d55d 100644 --- a/reference/ucp/3.1/cli/support.md +++ b/reference/ucp/3.1/cli/support.md @@ -22,8 +22,7 @@ This command creates a support dump file for the specified node(s), and prints i ## Options -| Option | Description | -|:--------------------------|:---------------------------| -|`--loglines`|Specify number of lines to grab from `journalctl`. The default is 10,000 lines.| -|`--servicedriller`|Run the swarm service driller (ssd) tool. For more information on this tool, see [Docker Swarm Service Driller (ssd)](https://github.com/docker/libnetwork/tree/master/cmd/ssd) Not run by default.| -|`--nodes`|Select specific nodes on which to produce a support dump. Comma-separated node IDs are allowed. The default selects all nodes.| +| Option | Description | +|:-------------|:-------------------------------------------------| +| `--debug, D` | Enable debug mode | +| `--jsonlog` | Produce json formatted output for easier parsing | diff --git a/reference/ucp/3.1/cli/uninstall-ucp.md b/reference/ucp/3.1/cli/uninstall-ucp.md index a1277e692c..6e6e6d10f7 100644 --- a/reference/ucp/3.1/cli/uninstall-ucp.md +++ b/reference/ucp/3.1/cli/uninstall-ucp.md @@ -30,13 +30,13 @@ UCP is installed again. ## Options -| Option | Description | -| :-------------------- | :---------------------------------------------------------- | -| `--debug, D` | Enable debug mode | -| `--jsonlog` | Produce json formatted output for easier parsing | -| `--interactive, i` | Run in interactive mode and prompt for configuration values | -| `--pull` | Pull UCP images: `always`, when `missing`, or `never` | -| `--registry-username` | Username to use when pulling images | -| `--registry-password` | Password to use when pulling images | -| `--id` | The ID of the UCP instance to uninstall | -| `--purge-config` | Remove UCP configs during uninstallation | +| Option | Description | +|:------------------------------|:----------------------------------------------------------- | +| `--debug, D` | Enable debug mode | +| `--jsonlog` | Produce json formatted output for easier parsing | +| `--interactive, i` | Run in interactive mode and prompt for configuration values | +| `--id` *value* | The ID of the UCP instance to uninstall | +| `--pull` *value* | Pull UCP images: `always`, when `missing`, or `never` | +| `--purge-config` | Remove UCP configs during uninstallation | +| `--registry-password` *value* | Password to use when pulling images | +| `--registry-username` *value* | Username to use when pulling images | diff --git a/reference/ucp/3.1/cli/upgrade.md b/reference/ucp/3.1/cli/upgrade.md index de7d72ae24..23206666c5 100644 --- a/reference/ucp/3.1/cli/upgrade.md +++ b/reference/ucp/3.1/cli/upgrade.md @@ -29,19 +29,16 @@ healthy and that all nodes have been upgraded successfully. ## Options -| Option | Description | -|:----------------------|:------------------------------------------------------------------------------------------------------| -| `--debug, D` | Enable debug mode | -| `--jsonlog` | Produce json formatted output for easier parsing | -| `--interactive, i` | Run in interactive mode and prompt for configuration values | -| `--admin-username` | The UCP administrator username | -| `--admin-password` | The UCP administrator password | -| `--pull` | Pull UCP images: `always`, when `missing`, or `never` | -| `--registry-username` | Username to use when pulling images | -| `--registry-password` | Password to use when pulling images | -| `--id` | The ID of the UCP instance to upgrade | -| `--host-address` | Override the previously configured host address with this IP or network interface | -| `--force-minimums` | Force the install/upgrade even if the system does not meet the minimum requirements | -| `--pod-cidr` | Kubernetes cluster IP pool for the pods to allocated IP. The default IP pool is `192.168.0.0/16`. | -| `--nodeport-range` | Allowed port range for Kubernetes services of type `NodePort`. The default port range is `32768-35535`. | -| `--cloud-provider` | The cloud provider for the cluster | +| Option | Description | +|:------------------------------|:------------------------------------------------------------------------------------| +| `--debug, D` | Enable debug mode | +| `--jsonlog` | Produce json formatted output for easier parsing | +| `--interactive, i` | Run in interactive mode and prompt for configuration values | +| `--admin-password` *value* | The UCP administrator password | +| `--admin-username` *value* | The UCP administrator username | +| `--force-minimums` | Force the install/upgrade even if the system does not meet the minimum requirements | +| `--host-address` *value* | Override the previously configured host address with this IP or network interface | +| `--id` | The ID of the UCP instance to upgrade | +| `--pull` | Pull UCP images: `always`, when `missing`, or `never` | +| `--registry-password` *value* | Password to use when pulling images | +| `--registry-username` *value* | Username to use when pulling images | diff --git a/storage/storagedriver/index.md b/storage/storagedriver/index.md index 9b3cbd51ea..e55ecfacc2 100644 --- a/storage/storagedriver/index.md +++ b/storage/storagedriver/index.md @@ -27,14 +27,14 @@ instruction in the image's Dockerfile. Each layer except the very last one is read-only. Consider the following Dockerfile: ```conf -FROM ubuntu:15.04 +FROM ubuntu:18.04 COPY . /app RUN make /app CMD python /app/app.py ``` This Dockerfile contains four commands, each of which creates a layer. The -`FROM` statement starts out by creating a layer from the `ubuntu:15.04` image. +`FROM` statement starts out by creating a layer from the `ubuntu:18.04` image. The `COPY` command adds some files from your Docker client's current directory. The `RUN` command builds your application using the `make` command. Finally, the last layer specifies what command to run within the container. @@ -45,7 +45,7 @@ writable layer on top of the underlying layers. This layer is often called the "container layer". All changes made to the running container, such as writing new files, modifying existing files, and deleting files, are written to this thin writable container layer. The diagram below shows a container based on the Ubuntu -15.04 image. +18.04 image. ![Layers of a container based on the Ubuntu image](images/container-layers.jpg) @@ -63,7 +63,7 @@ deleted. The underlying image remains unchanged. Because each container has its own writable container layer, and all changes are stored in this container layer, multiple containers can share access to the same underlying image and yet have their own data state. The diagram below shows -multiple containers sharing the same Ubuntu 15.04 image. +multiple containers sharing the same Ubuntu 18.04 image. ![Containers sharing same image](images/sharing-layers.jpg) @@ -130,28 +130,28 @@ usually `/var/lib/docker/` on Linux hosts. You can see these layers being pulled in this example: ```bash -$ docker pull ubuntu:15.04 - -15.04: Pulling from library/ubuntu -1ba8ac955b97: Pull complete -f157c4e5ede7: Pull complete -0b7e98f84c4c: Pull complete -a3ed95caeb02: Pull complete -Digest: sha256:5e279a9df07990286cce22e1b0f5b0490629ca6d187698746ae5e28e604a640e -Status: Downloaded newer image for ubuntu:15.04 +$ docker pull ubuntu:18.04 +18.04: Pulling from library/ubuntu +f476d66f5408: Pull complete +8882c27f669e: Pull complete +d9af21273955: Pull complete +f5029279ec12: Pull complete +Digest: sha256:ab6cb8de3ad7bb33e2534677f865008535427390b117d7939193f8d1a6613e34 +Status: Downloaded newer image for ubuntu:18.04 ``` Each of these layers is stored in its own directory inside the Docker host's local storage area. To examine the layers on the filesystem, list the contents -of `/var/lib/docker//layers/`. This example uses the `aufs` +of `/var/lib/docker/`. This example uses the `overlay2` storage driver: ```bash -$ ls /var/lib/docker/aufs/layers -1d6674ff835b10f76e354806e16b950f91a191d3b471236609ab13a930275e24 -5dbb0cbe0148cf447b9464a358c1587be586058d9a4c9ce079320265e2bb94e7 -bef7199f2ed8e86fa4ada1309cfad3089e0542fec8894690529e4c04a7ca2d73 -ebf814eccfe98f2704660ca1d844e4348db3b5ccc637eb905d4818fbfb00a06a +$ ls /var/lib/docker/overlay2 +16802227a96c24dcbeab5b37821e2b67a9f921749cd9a2e386d5a6d5bc6fc6d3 +377d73dbb466e0bc7c9ee23166771b35ebdbe02ef17753d79fd3571d4ce659d7 +3f02d96212b03e3383160d31d7c6aeca750d2d8a1879965b89fe8146594c453d +ec1ec45792908e90484f7e629330666e7eee599f08729c93890a7205a6ba35f5 +l ``` The directory names do not correspond to the layer IDs (this has been true since @@ -161,7 +161,7 @@ Now imagine that you have two different Dockerfiles. You use the first one to create an image called `acme/my-base-image:1.0`. ```conf -FROM ubuntu:16.10 +FROM ubuntu:18.04 COPY . /app ``` @@ -209,10 +209,9 @@ layers are the same. ```bash $ docker build -t acme/my-base-image:1.0 -f Dockerfile.base . - - Sending build context to Docker daemon 4.096kB - Step 1/2 : FROM ubuntu:16.10 - ---> 31005225a745 + Sending build context to Docker daemon 812.4MB + Step 1/2 : FROM ubuntu:18.04 + ---> d131e0fa2585 Step 2/2 : COPY . /app ---> Using cache ---> bd09118bcef6 @@ -252,7 +251,7 @@ layers are the same. $ docker history bd09118bcef6 IMAGE CREATED CREATED BY SIZE COMMENT bd09118bcef6 4 minutes ago /bin/sh -c #(nop) COPY dir:35a7eb158c1504e... 100B - 31005225a745 3 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B + d131e0fa2585 3 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B 3 months ago /bin/sh -c mkdir -p /run/systemd && echo '... 7B 3 months ago /bin/sh -c sed -i 's/^#\s*\(deb.*universe\... 2.78kB 3 months ago /bin/sh -c rm -rf /var/lib/apt/lists/* 0B @@ -266,7 +265,7 @@ layers are the same. IMAGE CREATED CREATED BY SIZE COMMENT dbf995fc07ff 3 minutes ago /bin/sh -c #(nop) CMD ["/bin/sh" "-c" "/a... 0B bd09118bcef6 5 minutes ago /bin/sh -c #(nop) COPY dir:35a7eb158c1504e... 100B - 31005225a745 3 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B + d131e0fa2585 3 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B 3 months ago /bin/sh -c mkdir -p /run/systemd && echo '... 7B 3 months ago /bin/sh -c sed -i 's/^#\s*\(deb.*universe\... 2.78kB 3 months ago /bin/sh -c rm -rf /var/lib/apt/lists/* 0B diff --git a/storage/storagedriver/zfs-driver.md b/storage/storagedriver/zfs-driver.md index 2f3faa159a..e4fb127ded 100644 --- a/storage/storagedriver/zfs-driver.md +++ b/storage/storagedriver/zfs-driver.md @@ -263,7 +263,7 @@ There are several factors that influence the performance of Docker using the filesystems like ZFS. ZFS mitigates this by using a small block size of 128k. The ZFS intent log (ZIL) and the coalescing of writes (delayed writes) also help to reduce fragmentation. You can monitor fragmentation using - `zfs status`. However, there is no way to defragment ZFS without reformatting + `zpool status`. However, there is no way to defragment ZFS without reformatting and restoring the filesystem. - **Use the native ZFS driver for Linux**: The ZFS FUSE implementation is not diff --git a/storage/volumes.md b/storage/volumes.md index 1c5b42c570..afe2ade368 100644 --- a/storage/volumes.md +++ b/storage/volumes.md @@ -464,7 +464,7 @@ $ docker service create -d \ docker service create -d \ --name nfs-service \ --mount 'type=volume,source=nfsvolume,target=/app,volume-driver=local,volume-opt=type=nfs,volume-opt=device=:/,"volume-opt=o=10.0.0.10,rw,nfsvers=4,async"' \ - nginx:latest` + nginx:latest ``` ## Backup, restore, or migrate data volumes diff --git a/swarm/discovery.md b/swarm/discovery.md index 54a03de80d..20e125c983 100644 --- a/swarm/discovery.md +++ b/swarm/discovery.md @@ -168,6 +168,11 @@ Or with node discovery: ## Docker Hub as a hosted discovery service +> ### Deprecation Notice +> +> The Docker Hub Hosted Discovery Service will be removed on June 19th, 2019. Please switch to one of the other discovery mechanisms. Several brownouts of the service will take place in the weeks leading up to the removal in order for users to find places where this is still used and give them time to prepare. +{:.info} + > **Warning**: > The Docker Hub Hosted Discovery Service **is not recommended** for production use. It's intended to be used for testing/development. See the discovery backends for production use. {:.warning}