mirror of https://github.com/docker/docs.git
Revert "Merge branch 'amberjack' into master"
This reverts commit87e1870d92, reversing changes made to4d3d196bb6.
This commit is contained in:
Maria Bermudez
parent
82cd7ac178
commit
5612fcbff8
|
|
@ -168,4 +168,4 @@ pipeline {
|
|||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,30 +0,0 @@
|
|||
command: docker registry
|
||||
short: Manage Docker registries
|
||||
long: Manage Docker registries
|
||||
usage: docker registry
|
||||
pname: docker
|
||||
plink: docker.yaml
|
||||
cname:
|
||||
- docker registry events
|
||||
- docker registry history
|
||||
- docker registry info
|
||||
- docker registry inspect
|
||||
- docker registry joblogs
|
||||
- docker registry jobs
|
||||
- docker registry ls
|
||||
- docker registry rmi
|
||||
clink:
|
||||
- docker_registry_events.yaml
|
||||
- docker_registry_history.yaml
|
||||
- docker_registry_info.yaml
|
||||
- docker_registry_inspect.yaml
|
||||
- docker_registry_joblogs.yaml
|
||||
- docker_registry_jobs.yaml
|
||||
- docker_registry_ls.yaml
|
||||
- docker_registry_rmi.yaml
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
command: docker registry events
|
||||
short: List registry events (DTR Only)
|
||||
long: List registry events (Only supported by Docker Trusted Registry)
|
||||
usage: docker registry events HOST | REPOSITORY [OPTIONS]
|
||||
pname: docker registry
|
||||
plink: docker_registry.yaml
|
||||
options:
|
||||
- option: format
|
||||
value_type: string
|
||||
description: Pretty-print output using a Go template
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: limit
|
||||
value_type: int64
|
||||
default_value: "50"
|
||||
description: Specify the number of event results
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: no-trunc
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Don't truncate output
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: object-type
|
||||
value_type: string
|
||||
description: |
|
||||
Specify the type of Event target object [REPOSITORY | TAG | BLOB | MANIFEST | WEBHOOK | URI | PROMOTION | PUSH_MIRRORING | POLL_MIRRORING]
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: type
|
||||
value_type: string
|
||||
description: |
|
||||
Specify the type of Event [CREATE | GET | DELETE | UPDATE | SEND | FAIL]
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
command: docker registry history
|
||||
short: Inspect registry image history (DTR Only)
|
||||
long: Inspect registry image history (DTR Only)
|
||||
usage: docker registry history IMAGE [OPTIONS]
|
||||
pname: docker registry
|
||||
plink: docker_registry.yaml
|
||||
options:
|
||||
- option: format
|
||||
value_type: string
|
||||
description: Pretty-print history using a Go template
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: human
|
||||
shorthand: H
|
||||
value_type: bool
|
||||
default_value: "true"
|
||||
description: Print sizes and dates in human readable format
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: no-trunc
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Don't truncate output
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
command: docker registry info
|
||||
short: Display information about a registry (DTR Only)
|
||||
long: Display information about a registry (Only supported by Docker Trusted Registry
|
||||
and must be authenticated as an admin user)
|
||||
usage: docker registry info HOST [OPTIONS]
|
||||
pname: docker registry
|
||||
plink: docker_registry.yaml
|
||||
options:
|
||||
- option: format
|
||||
value_type: string
|
||||
description: Pretty-print output using a Go template
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
command: docker registry inspect
|
||||
short: Inspect registry image
|
||||
long: Inspect registry image
|
||||
usage: docker registry inspect IMAGE [OPTIONS]
|
||||
pname: docker registry
|
||||
plink: docker_registry.yaml
|
||||
options:
|
||||
- option: format
|
||||
value_type: string
|
||||
description: Pretty-print output using a Go template
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
command: docker registry joblogs
|
||||
short: List registry job logs (DTR Only)
|
||||
long: List registry job logs (DTR Only)
|
||||
usage: docker registry joblogs HOST JOB_ID [OPTIONS]
|
||||
pname: docker registry
|
||||
plink: docker_registry.yaml
|
||||
options:
|
||||
- option: format
|
||||
value_type: string
|
||||
description: Pretty-print output using a Go template
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
command: docker registry jobs
|
||||
short: List registry jobs (DTR Only)
|
||||
long: List registry jobs (Only supported by Docker Trusted Registry and must be authenticated
|
||||
as an admin user)
|
||||
usage: docker registry jobs HOST [OPTIONS]
|
||||
pname: docker registry
|
||||
plink: docker_registry.yaml
|
||||
options:
|
||||
- option: action
|
||||
value_type: string
|
||||
description: |
|
||||
Specify the type of Job action [onlinegc | onlinegc_metadata | onlinegc_joblogs | onlinegc_events | license_update | scan_check | scan_check_single | scan_check_all | update_vuln_db | nautilus_update_db | push_mirror_tag | poll_mirror | tag_prune]
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: format
|
||||
value_type: string
|
||||
description: Pretty-print output using a Go template
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: limit
|
||||
value_type: int64
|
||||
default_value: "50"
|
||||
description: Specify the number of job results
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: no-trunc
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Don't truncate output
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
command: docker registry ls
|
||||
short: List registry images
|
||||
long: List registry images
|
||||
usage: docker registry ls REPOSITORY[:TAG] [OPTIONS]
|
||||
pname: docker registry
|
||||
plink: docker_registry.yaml
|
||||
options:
|
||||
- option: digests
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Show digests
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: format
|
||||
value_type: string
|
||||
description: Pretty-print output using a Go template
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: quiet
|
||||
shorthand: q
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Only display image names
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: verbose
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Display verbose image information
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
command: docker registry rmi
|
||||
short: Remove a registry image (DTR Only)
|
||||
long: Remove a registry image (DTR Only)
|
||||
usage: docker registry rmi REPOSITORY:TAG [OPTIONS]
|
||||
pname: docker registry
|
||||
plink: docker_registry.yaml
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
|
||||
|
|
@ -776,24 +776,6 @@ reference:
|
|||
title: docker pull
|
||||
- path: /engine/reference/commandline/push/
|
||||
title: docker push
|
||||
- sectiontitle: docker registry *
|
||||
section:
|
||||
- path: /engine/reference/commandline/registry/
|
||||
title: docker registry
|
||||
- path: /engine/reference/commandline/registry_events/
|
||||
title: docker registry events
|
||||
- path: /engine/reference/commandline/registry_history/
|
||||
title: docker registry history
|
||||
- path: /engine/reference/commandline/registry_info/
|
||||
title: docker registry info
|
||||
- path: /engine/reference/commandline/registry_inspect/
|
||||
title: docker registry inspect
|
||||
- path: /engine/reference/commandline/registry_joblogs/
|
||||
title: docker registry joblogs
|
||||
- path: /engine/reference/commandline/registry_ls/
|
||||
title: docker registry ls
|
||||
- path: /engine/reference/commandline/registry_rmi/
|
||||
title: docker registry rmi
|
||||
- path: /engine/reference/commandline/rename/
|
||||
title: docker rename
|
||||
- path: /engine/reference/commandline/restart/
|
||||
|
|
@ -1174,40 +1156,6 @@ manuals:
|
|||
nosync: true
|
||||
- title: Release notes
|
||||
path: /engine/release-notes/
|
||||
- sectiontitle: Docker Desktop Enterprise
|
||||
section:
|
||||
- path: /ee/desktop/
|
||||
title: Overview
|
||||
- path: /ee/desktop/release-notes/
|
||||
title: Release notes
|
||||
- sectiontitle: Admin
|
||||
section:
|
||||
- sectiontitle: Install
|
||||
section:
|
||||
- path: /ee/desktop/admin/install/mac/
|
||||
title: Install DDE on Mac
|
||||
- path: /ee/desktop/admin/install/windows/
|
||||
title: Install DDE on Windows
|
||||
- sectiontitle: Configure
|
||||
section:
|
||||
- path: /ee/desktop/admin/configure/mac-admin/
|
||||
title: Configure DDE on Mac
|
||||
- path: /ee/desktop/admin/configure/windows-admin/
|
||||
title: Configure DDE on Windows
|
||||
- sectiontitle: User
|
||||
section:
|
||||
- path: /ee/desktop/user/mac-user/
|
||||
title: Use DDE on Mac
|
||||
- path: /ee/desktop/user/windows-user/
|
||||
title: Use DDE on Windows
|
||||
- path: /ee/desktop/app-designer/
|
||||
title: Application designer
|
||||
- sectiontitle: Troubleshoot
|
||||
section:
|
||||
- path: /ee/desktop/troubleshoot/mac-issues/
|
||||
title: Troubleshoot DDE issues on Mac
|
||||
- path: /ee/desktop/troubleshoot/windows-issues/
|
||||
title: Troubleshoot DDE issues on Windows
|
||||
- sectiontitle: Universal Control Plane
|
||||
section:
|
||||
- path: /ee/ucp/
|
||||
|
|
@ -1406,7 +1354,7 @@ manuals:
|
|||
- title: Securing services with TLS
|
||||
path: /ee/ucp/interlock/usage/tls/
|
||||
- title: Configuring websockets
|
||||
path: /ee/ucp/interlock/usage/websockets/
|
||||
path: /ee/ucp/interlock/usage/websockets/
|
||||
- sectiontitle: Deploy apps with Kubernetes
|
||||
section:
|
||||
- title: Access Kubernetes Resources
|
||||
|
|
@ -3122,26 +3070,6 @@ manuals:
|
|||
title: Get support
|
||||
- title: Get support
|
||||
path: /ee/get-support/
|
||||
- sectiontitle: Docker Assemble
|
||||
section:
|
||||
- path: /assemble/install/
|
||||
title: Install
|
||||
- path: /assemble/spring-boot/
|
||||
title: Build a Spring Boot project
|
||||
- path: /assemble/dot-net/
|
||||
title: Build a C# ASP.NET Core project
|
||||
- path: /assemble/configure/
|
||||
title: Configure
|
||||
- path: /assemble/images/
|
||||
title: Images
|
||||
- path: /assemble/adv-backend-manage/
|
||||
title: Advanced Backend Management
|
||||
- path: /assemble/cli-reference/
|
||||
title: CLI reference
|
||||
- sectiontitle: Docker App
|
||||
section:
|
||||
- path: /app/working-with-app/
|
||||
title: Working with Docker App
|
||||
- sectiontitle: Docker Compose
|
||||
section:
|
||||
- path: /compose/overview/
|
||||
|
|
@ -3636,4 +3564,4 @@ manuals:
|
|||
- path: /swarm/swarm-api/
|
||||
title: Docker Swarm API
|
||||
- path: /release-notes/docker-swarm/
|
||||
title: Docker Swarm release notes
|
||||
title: Docker Swarm release notes
|
||||
|
|
|
|||
|
|
@ -1,346 +0,0 @@
|
|||
---
|
||||
title: Working with Docker App
|
||||
description: Learn about Docker App
|
||||
keywords: Docker App, applications, compose, orchestration
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Docker App is a CLI plug-in that introduces a top-level `docker app` command that brings the _container experience_ to applications. The following table compares Docker containers with Docker applications.
|
||||
|
||||
|
||||
| Object | Config file | Build with | Execute with |
|
||||
| ------------- |---------------| -------------------|-----------------------|
|
||||
| Container | Dockerfile | docker image build | docker container run |
|
||||
| App | bundle.json | docker app bundle | docker app install |
|
||||
|
||||
|
||||
With Docker App, entire applications can now be managed as easily as images and containers. For example, Docker App lets you _build_, _validate_ and _deploy_ applications with the `docker app` command. You can even leverage secure supply-chain features such as signed `push` and `pull` operations.
|
||||
|
||||
This guide will walk you through two scenarios:
|
||||
|
||||
1. Initialize and deploy a new Docker App project from scratch
|
||||
2. Convert an existing Compose app into a Docker App project (Added later in the beta process)
|
||||
|
||||
The first scenario will familiarize you with the basic components of a Docker App and get you comfortable with the tools and workflow.
|
||||
|
||||
## Initialize and deploy a new Docker App project from scratch
|
||||
|
||||
In this section, we'll walk through the process of creating a new Docker App project. By then end, you'll be familiar with the workflow and most important commands.
|
||||
|
||||
We'll complete the following steps:
|
||||
|
||||
1. Pre-requisites
|
||||
2. Initialize an empty new project
|
||||
3. Populate the project
|
||||
4. Validate the app
|
||||
5. Deploy the app
|
||||
6. Push the app to Docker Hub
|
||||
7. Install the app directly from Docker Hub
|
||||
|
||||
### Pre-requisites
|
||||
|
||||
In order to follow along, you'll need at least one Docker node operating in Swarm mode. You will also need the latest build of the Docker CLI with the APP CLI plugin included.
|
||||
|
||||
Depending on your Linux distribution and your security context, you may need to prepend commands with `sudo`.
|
||||
|
||||
|
||||
### Initialize a new empty project
|
||||
|
||||
The `docker app init` command is used to initialize a new Docker application project. If you run it on its own, it initializes a new empty project. If you point it to an existing `docker-compose.yml` file, it initializes a new project based on the Compose file.
|
||||
|
||||
Use the following command to initialize a new empty project called "hello-world".
|
||||
|
||||
```
|
||||
$ docker app init --single-file hello-world
|
||||
Created "hello-world.dockerapp"
|
||||
```
|
||||
|
||||
The command will produce a single file in your current directory called `hello-world.dockerapp`. The format of the file name is <project-name> appended with `.dockerapp`.
|
||||
|
||||
```
|
||||
$ ls
|
||||
hello-world.dockerapp
|
||||
```
|
||||
|
||||
If you run `docker app init` without the `--single-file` flag you will get a new directory containing three YAML files. The name of the directory will the name of the project with `.dockerapp` appended, and the three YAML files will be:
|
||||
|
||||
- `docker-compose.yml`
|
||||
- `metadata.yml`
|
||||
- `parameters.yml`
|
||||
|
||||
However, the `--single-file` option merges the three YAML files into a single YAML file with three sections. Each of these sections relates to one of the three YAML files mentioned above --- `docker-compose.yml`, `metadata.yml`, and `parameters.yml`. Using the `--single-file` option is great for enabling you to share your application via a single configuration file.
|
||||
|
||||
Inspect the YAML with the following command.
|
||||
|
||||
```
|
||||
$ cat hello-world.dockerapp
|
||||
# Application metadata - equivalent to metadata.yml.
|
||||
version: 0.1.0
|
||||
name: hello-world
|
||||
description:
|
||||
---
|
||||
# Application services - equivalent to docker-compose.yml.
|
||||
version: "3.6"
|
||||
services: {}
|
||||
---
|
||||
# Default application parameters - equivalent to parameters.yml.
|
||||
```
|
||||
|
||||
Your file may be more verbose.
|
||||
|
||||
Notice that each of the three sections is separated by a set of three dashes ("---"). Let's quickly describe each section.
|
||||
|
||||
The first section of the file is where you specify identification metadata such as name, version, and description. It accepts key-value pairs. This part of the file can be a separate file called `metadata.yml`
|
||||
|
||||
The second section of the file describes the application. It can be a separate file called `docker-compose.yml`.
|
||||
|
||||
The final section is where default values for application parameters can be expressed. It can be a separate file called `parameters.yml`
|
||||
|
||||
### Populate the project
|
||||
|
||||
In this section, we'll edit the project YAML file so that it runs a simple web app.
|
||||
|
||||
Use your preferred editor to edit the `hello-world.dockerapp` YMAL file and update the application section to the following:
|
||||
|
||||
```
|
||||
version: "3.6"
|
||||
services:
|
||||
hello:
|
||||
image: hashicorp/http-echo
|
||||
command: ["-text", "${text}"]
|
||||
ports:
|
||||
- ${port}:5678
|
||||
```
|
||||
|
||||
Update the Parameters section to the following:
|
||||
|
||||
```
|
||||
port: 8080
|
||||
text: Hello world!
|
||||
```
|
||||
|
||||
The sections of the YAML file are currently order-based. This means it's important they remain in the order we've explained, with the _metadata_ section being first, the _app_ section being second, and the _parameters_ section being last. This may change to name-based sections in future releases.
|
||||
|
||||
Save the changes.
|
||||
|
||||
The application has been updated to run a single-container application based on the `hashicorp/http-echo` web server image. This image will have it execute a single command that displays some text and exposes itself on a network port.
|
||||
|
||||
Following best-practices, the configuration of the application has been decoupled form the application itself using variables. In this case, the text displayed by the app, and the port it will be published on, are controlled by two variables defined in the Parameters section of the file.
|
||||
|
||||
Docker App provides the `inspect` sub-command to provide a prettified summary of the application configuration. It's important to note that the application is not running at this point, and that the `inspect` operation inspects the configuration file(s).
|
||||
|
||||
```
|
||||
$ docker app inspect hello-world.dockerapp
|
||||
hello-world 0.1.0
|
||||
|
||||
Service (1) Replicas Ports Image
|
||||
----------- -------- ----- -----
|
||||
hello 1 8080 hashicorp/http-echo
|
||||
|
||||
Parameters (2) Value
|
||||
-------------- -----
|
||||
port 8080
|
||||
text Hello world!
|
||||
```
|
||||
|
||||
`docker app inspect` operations will fail if the parameters section doesn't specify a default value for every parameter expressed in the app section.
|
||||
|
||||
The application is ready to validated and rendered.
|
||||
|
||||
### Validate the app
|
||||
Docker App provides the `validate` sub-command to check syntax and other aspects of the configuration. If validation passes, the command returns no arguments.
|
||||
|
||||
```
|
||||
$ docker app validate hello-world.dockerapp
|
||||
Validated "hello-world.dockerapp"
|
||||
```
|
||||
|
||||
`docker app validate` operations will fail if the parameters section doesn't specify a default value for every parameter expressed in the app section.
|
||||
|
||||
|
||||
As the `validate` operation has returned no problems, the app is ready to be deployed.
|
||||
|
||||
### Deploy the app
|
||||
|
||||
There are several options for deploying a Docker App project.
|
||||
|
||||
1. Deploy as a native Docker App application
|
||||
2. Deploy as a Compose app application
|
||||
3. Deploy as a Docker Stack application
|
||||
|
||||
We'll look at all three options, starting with deploying as a native Dock App application.
|
||||
|
||||
#### Deploy as a native Docker App
|
||||
|
||||
The process for deploying as a native Docker app is as follows.
|
||||
|
||||
1. Use `docker app install` to deploy the application
|
||||
|
||||
Use the following command to deploy (install) the application.
|
||||
|
||||
```
|
||||
$ docker app install hello-world.dockerapp --name my-app
|
||||
Creating network my-app_default
|
||||
Creating service my-app_hello
|
||||
```
|
||||
|
||||
The app will be deployed using the stack orchestrator. This means you can inspect it with regular `docker stack` commands.
|
||||
|
||||
```
|
||||
$ docker stack ls
|
||||
NAME SERVICES ORCHESTRATOR
|
||||
my-app 1 Swarm
|
||||
```
|
||||
|
||||
You can also check the status of the app with the `docker app status <app-name>` command.
|
||||
|
||||
```
|
||||
$ docker app status my-app
|
||||
ID NAME MODE REPLICAS IMAGE PORTS
|
||||
miqdk1v7j3zk my-app_hello replicated 1/1 hashicorp/http-echo:latest *:8080->5678/tcp
|
||||
```
|
||||
|
||||
Now that the app is running, you can point a web browser at the DNS name or public IP of the Docker node on port 8080 and see the app in all its glory. You will need to ensure traffic to port 8080 is allowed on the connection form your browser to your Docker host.
|
||||
|
||||
You can uninstall the app with `docker app uninstall my-app`.
|
||||
|
||||
#### Deploy as a Docker Compose app
|
||||
|
||||
The process for deploying a as a Compose app comprises two major steps:
|
||||
|
||||
1. Render the Docker app project as a `docker-compose.yml` file.
|
||||
2. Deploy the app using `docker-compose up`.
|
||||
|
||||
You will need a recent version of Docker Compose tom complete these steps.
|
||||
|
||||
Rendering is the process of reading the entire application configuration and outputting it as a single `docker-compose.yml` file. This will create a Compose file with hard-coded values wherever a parameter was specified as a variable.
|
||||
|
||||
Use the following command to render the app to a Compose file called `docker-compose.yml` in the current directory.
|
||||
|
||||
```
|
||||
$ docker app render --output docker-compose.yml hello-world.dockerapp
|
||||
```
|
||||
|
||||
Check the contents of the resulting `docker-compose.yml` file.
|
||||
|
||||
```
|
||||
$ cat docker-compose.yml
|
||||
version: "3.6"
|
||||
services:
|
||||
hello:
|
||||
command:
|
||||
- -text
|
||||
- Hello world!
|
||||
image: hashicorp/http-echo
|
||||
ports:
|
||||
- mode: ingress
|
||||
target: 5678
|
||||
published: 8080
|
||||
protocol: tcp
|
||||
```
|
||||
|
||||
Notice that the file contains hard-coded values that were expanded based on the contents of the Parameters section of the project's YAML file. For example, ${text} has been expanded to "Hello world!".
|
||||
|
||||
Use `docker-compose up` to deploy the app.
|
||||
|
||||
```
|
||||
$ docker-compose up --detach
|
||||
WARNING: The Docker Engine you're using is running in swarm mode.
|
||||
<Snip>
|
||||
```
|
||||
|
||||
The application is now running as a Docker compose app and should be reachable on port `8080` on your Docker host. You will need to ensure traffic to port 8080 is allowed on the connection form your browser to your Docker host.
|
||||
|
||||
You can use `docker-compose down` to stop and remove the application.
|
||||
|
||||
#### Deploy as a Docker Stack
|
||||
|
||||
Deploying the app as a Docker stack is a two-step process very similar to deploying it as a Docker compose app.
|
||||
|
||||
1. Render the Docker app project as a `docker-compose.yml` file.
|
||||
2. Deploy the app using `docker stack deploy`.
|
||||
|
||||
We'll assume that you've followed the steps to render the Docker app project as a compose file (shown in the previous section) and that you're ready to deploy it as a Docker Stack. Your Docker host will need to be in Swarm mode.
|
||||
|
||||
```
|
||||
$ docker stack deploy hello-world-app -c docker-compose.yml
|
||||
Creating network hello-world-app_default
|
||||
Creating service hello-world-app_hello
|
||||
```
|
||||
|
||||
The app is now deployed as a Docker stack and can be reached on port `8080` on your Docker host.
|
||||
|
||||
Use the `docker stack rm hello-world-app` command to stop and remove the stack. You will need to ensure traffic to port 8080 is allowed on the connection form your browser to your Docker host.
|
||||
|
||||
### Push the app to Docker Hub
|
||||
|
||||
As mentioned in the intro, `docker app` lets you manage entire applications the same way that we currently manage container images. For example, you can push and pull entire applications from registries like Docker Hub with `docker app push` and `docker app pull`. Other `docker app` commands, such as `install`, `upgrade`, and `render` can be performed directly on applications while they are stored in a registry.
|
||||
|
||||
Let's see some examples.
|
||||
|
||||
Push the application to Docker Hub. To complete this step, you'll need a valid Docker ID and you'll need to be logged in to the registry you are pushing the app to.
|
||||
|
||||
Be sure to replace the registry ID in the example below with your own.
|
||||
|
||||
```
|
||||
$ docker app push my-app --tag nigelpoulton/app-test:0.1.0
|
||||
docker app push hello-world.dockerapp --tag nigelpoulton/app-test:0.1.0
|
||||
docker.io/nigelpoulton/app-test:0.1.0-invoc
|
||||
hashicorp/http-echo
|
||||
application/vnd.docker.distribution.manifest.v2+json [2/2] (sha256:ba27d460...)
|
||||
<Snip>
|
||||
```
|
||||
|
||||
The app is now stored in the container registry.
|
||||
|
||||
### Install the app directly from Docker Hub
|
||||
|
||||
Now that the app is pushed to the registry, try an `inspect` and `install` command against it. The location of your app will be different to the one shown in the examples.
|
||||
|
||||
```
|
||||
$ docker app inspect nigelpoulton/app-test:0.1.0
|
||||
hello-world 0.1.0
|
||||
|
||||
Service (1) Replicas Ports Image
|
||||
----------- -------- ----- -----
|
||||
hello 1 8080 nigelpoulton/app-test@sha256:ba27d460cd1f22a1a4331bdf74f4fccbc025552357e8a3249c40ae216275de96
|
||||
|
||||
Parameters (2) Value
|
||||
-------------- -----
|
||||
port 8080
|
||||
text Hello world!
|
||||
```
|
||||
|
||||
This action was performed directly against the app in the registry.
|
||||
|
||||
Now install it as a native Docker App by referencing the app in the registry.
|
||||
|
||||
```
|
||||
$ docker app install nigelpoulton/app-test:0.1.0
|
||||
Creating network hello-world_default
|
||||
Creating service hello-world_hello
|
||||
```
|
||||
|
||||
Test that the app is working.
|
||||
|
||||
The app used in these examples is a simple web server that displays the text "Hello world!" on port 8080, your app may be different.
|
||||
|
||||
```
|
||||
$ curl http://localhost:8080
|
||||
Hello world!
|
||||
```
|
||||
|
||||
Uninstall the app.
|
||||
|
||||
```
|
||||
$ docker app uninstall hello-world
|
||||
Removing service hello-world_hello
|
||||
Removing network hello-world_default
|
||||
```
|
||||
|
||||
You can see the name of your Docker App with the `docker stack ls` command.
|
||||
|
||||
## Convert an existing Compose app into a Docker App project
|
||||
|
||||
Content TBA
|
||||
|
|
@ -1,90 +0,0 @@
|
|||
---
|
||||
title: Advanced backend management
|
||||
description: Advanced backend management for Docker Assemble
|
||||
keywords: Backend, Assemble, Docker Enterprise, plugin, Spring Boot, .NET, c#, F#
|
||||
---
|
||||
|
||||
## Backend access to host ports
|
||||
|
||||
Docker Assemble requires its own buildkit instance to be running in a Docker container on the local system. You can start and manage the backend using the `backend` subcommand of `docker assemble`. For more information, see [Install Docker Assemble](/install).
|
||||
|
||||
As the backend runs in a container with its own network namespace, it cannot access host resources directly. This is most noticeable when trying to push to a local registry as `localhost:5000`.
|
||||
|
||||
The backend supports a sidecar container which proxies ports from within the backend container to the container's gateway (which is in effect a host IP). This is sufficient to allow access to host ports which have been bound to `0.0.0.0` (or to the gateway specifically), but not ones which are bound to `127.0.0.1`.
|
||||
|
||||
By default, port 5000 is proxied in this way, as that is the most common port used for a local registry to allow access to a local registry on `localhost:5000` (the most common setup). You can proxy other ports using the `--allow-host-port` option to docker assemble backend start.
|
||||
|
||||
For example, to expose port `6000` instead of port `5000`, run:
|
||||
|
||||
```
|
||||
$ docker assemble backend start --allow-host-port 6000
|
||||
```
|
||||
> **Notes:**
|
||||
>
|
||||
> - You can repeat the `--allow-host-port` option or give it a comma separated list of ports.
|
||||
> - Passing `--allow-host-port 0` disables the default and no ports are exposed. For example:
|
||||
>
|
||||
> `$ docker assemble backend start --allow-host-port 0`
|
||||
> - On Docker Desktop, this functionality allows the backend to access ports on the Docker Desktop VM host, rather than the Windows or macOS host. To access the the Windows or macOS host port, you can use `host.docker.internal` as usual.
|
||||
|
||||
## Backend sub-commands
|
||||
|
||||
### Info
|
||||
|
||||
The info sub-command describes the backend:
|
||||
|
||||
```
|
||||
~$ docker assemble backend info
|
||||
ID: 2f03e7d288e6bea770a2acba4c8c918732aefcd1946c94c918e8a54792e4540f (running)
|
||||
Image: docker/assemble-backend@sha256:«…»
|
||||
|
||||
Sidecar containers:
|
||||
- 0f339c0cc8d7 docker-assemble-backend-username-proxy-port-5000 (running)
|
||||
|
||||
Found 1 worker(s):
|
||||
|
||||
- 70it95b8x171u5g9jbixkscz9
|
||||
Platforms:
|
||||
- linux/amd64
|
||||
Labels:
|
||||
- com.docker.assemble.commit: «…»
|
||||
- org.mobyproject.buildkit.worker.executor: oci
|
||||
- org.mobyproject.buildkit.worker.hostname: 2f03e7d288e6
|
||||
- org.mobyproject.buildkit.worker.snapshotter: overlayfs
|
||||
|
||||
Build cache contains 54 entries, total size 3.65GB (0B currently in use)
|
||||
```
|
||||
|
||||
### Stop
|
||||
|
||||
The stop sub-command destroys the backend container
|
||||
|
||||
```
|
||||
~$ docker assemble backend stop
|
||||
```
|
||||
|
||||
### Logs
|
||||
|
||||
The logs sub-command displays the backend logs.
|
||||
|
||||
```
|
||||
~$ docker assemble backend logs
|
||||
```
|
||||
|
||||
### Cache
|
||||
|
||||
The build cache gets lost when the backend is stopped. To avoid this, you can create a volume named `docker-assemble-backend-cache-«username»` and it will automatically be used as the build cache.
|
||||
|
||||
Alternatively you can specify a named docker volume to use for the cache. For example:
|
||||
|
||||
```
|
||||
~$ docker volume create $USER-assemble-cache
|
||||
username-assemble-cache
|
||||
~$ docker assemble backend start --cache-volume=username-assemble-cache
|
||||
Pulling image «…»: Success
|
||||
Started container "docker-assemble-backend-username" (74476d3fdea7)
|
||||
```
|
||||
|
||||
For information regarding the current cache contents, run the command `docker assemble backend cache`.
|
||||
|
||||
To clean the cache, run`docker assemble backend cache purge`.
|
||||
|
|
@ -1,134 +0,0 @@
|
|||
---
|
||||
title: Docker Assemble CLI reference
|
||||
description: Docker Assemble CLI reference
|
||||
keywords: Docker, assemble, Spring Boot, ASP .NET, backend
|
||||
---
|
||||
|
||||
This page provides information about the `docker assemble` command.
|
||||
|
||||
## Overview
|
||||
|
||||
Docker Assemble (`docker assemble`) is a CLI plugin which provides a language and framework-aware tool that enables users to build an application into an optimized Docker container.
|
||||
|
||||
For more information about Docker Assemble, see [Docker Assemble](/assemble/install/).
|
||||
|
||||
## `docker assemble` commands
|
||||
|
||||
To view the commands and sub-commands available in `docker assemble`, run:
|
||||
|
||||
`docker assemble --help`
|
||||
|
||||
```
|
||||
Usage: docker assemble [OPTIONS] COMMAND
|
||||
|
||||
assemble is a high-level build tool
|
||||
|
||||
Options:
|
||||
--addr string backend address (default
|
||||
"docker-container://docker-assemble-backend-Usha-Mandya")
|
||||
|
||||
Management Commands:
|
||||
backend Manage build backend service
|
||||
|
||||
Commands:
|
||||
build Build a project into a container
|
||||
version Print the version number of docker assemble
|
||||
|
||||
Run 'docker assemble COMMAND --help' for more information on a command.
|
||||
```
|
||||
|
||||
### backend
|
||||
|
||||
The `docker assemble backend` command allows you to manage and build backend services. Docker Assemble requires its own buildkit instance to be running in a Docker container on the local system.
|
||||
|
||||
```
|
||||
Usage: docker assemble backend [OPTIONS] COMMAND
|
||||
|
||||
Manage build backend service
|
||||
|
||||
Options:
|
||||
--addr string backend address (default
|
||||
"docker-container://docker-assemble-backend-username")
|
||||
|
||||
Management Commands:
|
||||
cache Manage build cache
|
||||
|
||||
Commands:
|
||||
info Print information about build backend service
|
||||
logs Show logs for build backend service
|
||||
start Start build backend service
|
||||
stop Stop build backend service
|
||||
|
||||
Run 'docker assemble backend COMMAND --help' for more information on a command.
|
||||
```
|
||||
|
||||
For example:
|
||||
|
||||
```
|
||||
docker assemble backend start
|
||||
Pulling image «…»: Success
|
||||
Started backend container "docker-assemble-backend-username" (3e627bb365a4)
|
||||
```
|
||||
|
||||
For more information about `backend`, see [Advanced backend management](/assemble/adv-backend-manage).
|
||||
|
||||
### build
|
||||
|
||||
The `docker assemble build` command enables you to build a project into a container.
|
||||
|
||||
```
|
||||
Usage: docker assemble build [PATH]
|
||||
|
||||
Build a project into a container
|
||||
|
||||
Options:
|
||||
--addr string backend address (default
|
||||
"docker-container://docker-assemble-backend-username")
|
||||
--label KEY=VALUE label to write into the image as KEY=VALUE
|
||||
--name NAME build image with repository NAME (default
|
||||
taken from project metadata)
|
||||
--namespace NAMESPACE build image within repository NAMESPACE
|
||||
(default no namespace)
|
||||
-o, --option OPTION=VALUE set an option as OPTION=VALUE
|
||||
--port stringArray port to expose from container
|
||||
--progress string set type of progress (auto, plain, tty).
|
||||
Use plain to show container output (default
|
||||
"auto")
|
||||
--push push result to registry, not local image store
|
||||
--push-insecure push result to insecure (http) registry,
|
||||
not local image store
|
||||
--tag TAG tag image with TAG (default taken from
|
||||
project metadata or "latest")
|
||||
```
|
||||
|
||||
For example:
|
||||
|
||||
```
|
||||
~$ docker assemble build docker-springframework
|
||||
«…»
|
||||
Successfully built: docker.io/library/hello-boot:1
|
||||
```
|
||||
|
||||
## version
|
||||
|
||||
The `docker assemble version` command displays the version number of Docker Assemble.
|
||||
|
||||
```
|
||||
Usage: docker assemble version
|
||||
|
||||
Print the version number of docker assemble
|
||||
|
||||
Options:
|
||||
--addr string backend address (default
|
||||
"docker-container://docker-assemble-backend-username")
|
||||
```
|
||||
|
||||
For example:
|
||||
|
||||
```
|
||||
> docker assemble version
|
||||
docker assemble v0.31.0
|
||||
commit: d089e2be00b0f7d7f565aeba11cb8bc6dd56a40b
|
||||
buildkit: 2bd8e6cb2b42
|
||||
os/arch: windows/amd64
|
||||
```
|
||||
|
|
@ -1,81 +0,0 @@
|
|||
---
|
||||
title: Configure Docker Assemble
|
||||
description: Installing Docker Assemble
|
||||
keywords: Assemble, Docker Enterprise, plugin, Spring Boot, .NET, c#, F#
|
||||
---
|
||||
|
||||
Although you don’t need to configure anything to build a project using Docker Assemble, you may wish to override the defaults, and in some cases, add fields that weren’t automatically detected from the project file. To support this, Docker Assemble allows you to add a file `docker-assemble.yaml` to the root of your project. The settings you provide in the `docker-assemble.yaml` file overrides any auto-detection and can themselves be overridden by command-line arguments
|
||||
|
||||
The `docker-assemble.yaml` file is in YAML syntax and has the following informal schema:
|
||||
|
||||
- `version`: (_string_) mandatory, must contain `0.2.0`
|
||||
|
||||
- `image`: (_map_) contains options related to the output image.
|
||||
|
||||
- `platforms`: (_list of strings_) lists the possible platforms which can be built (for example, `linux/amd64`, `windows/amd64`). The default is determined automatically from the project type and content. Note that by default Docker Assemble will build only for `linux/amd64` unless `--push` is used. See [Building Multiplatform images](/assemble/images/#multi-platform-images).
|
||||
|
||||
- `ports`: (_list of strings_) contains ports to expose from a container running the image. e.g `80/tcp` or `8080`. Default is to automatically determine the set of ports to expose where possible. To disable this and export no ports specify a list containing precisely one element of `none`.
|
||||
|
||||
- `labels`: (_map_) contains labels to write into the image as `key`-`value` (_string_) pairs.
|
||||
|
||||
- `repository-namespace`: (_string_) the registry and path component of the desired output image. e.g. `docker.io/library` or `docker.io/user`.
|
||||
|
||||
- `repository-name`: (_string_) the name of the specific image within `repository-namespace`. Overrides any name derived from the build system specific configuration.
|
||||
|
||||
- `tag`: (_string_) the default tag to use. Overrides and version/tag derived from the build system specific configuration.
|
||||
|
||||
- `healthcheck`: (_map_) describes how to check a container running the image is healthy.
|
||||
|
||||
- `kind`: (_string_) sets the type of Healthcheck to perform. Valid values are `none`, `simple-tcpport-open` and `springboot`. See [Health checks](/assemble/images/#health-checks).
|
||||
|
||||
- `interval`: (_duration_) the time to wait between checks.
|
||||
|
||||
- `timeout`: (_duration_) the time to wait before considering the check to have hung.
|
||||
|
||||
- `start-period`: (_duration_) period for the container to initialize before the retries starts to count down
|
||||
|
||||
- `retries`: (_integer_) number of consecutive failures needed to consider a container as unhealthy.
|
||||
|
||||
- `springboot`: (_map_) if this is a Spring Boot project then contains related configuration options.
|
||||
|
||||
- `enabled`: (_boolean_) true if this is a springboot project.
|
||||
|
||||
- `java-version`: (_string_) configures the Java version to use. Valid options are `8` and `10`.
|
||||
|
||||
- `build-image`: (_string_) sets a custom base build image
|
||||
|
||||
- `runtime-images` (_map_) sets a custom base runtime image by platform. For valid keys, refer to the **Spring Boot** section in [Custom base images](/assemble/images/#custom-base-images).
|
||||
|
||||
- `aspnetcore`: (_map_) if this is an ASP.NET Core project then contains related configuration options.
|
||||
|
||||
- `enabled`: (_boolean_) true if this is an ASP.NET Core project.
|
||||
|
||||
- `version`: (_string_) configures the ASP.NET Core version to use. Valid options are `1.0`, `1.1`, `2.0` and `2.1`.
|
||||
|
||||
- `build-image`: (_string_) sets a custom base build image
|
||||
|
||||
- `runtime-images` (_map_) sets a custom base runtime image by platform. For valid keys, refer to the **ASP.NET Core** section in [Custom base images](/assemble/images/#custom-base-images).
|
||||
|
||||
> **Notes:**
|
||||
>
|
||||
> - The only mandatory field in `docker-assemble.yaml` is `version`. All other parameters are optional.
|
||||
>
|
||||
> - At most one of `dotnet` or `springboot` can be present in the yaml file.
|
||||
>
|
||||
> - Fields of type duration are integers with nanosecond granularity. However the following units of time are supported: `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. For example, `25s`.
|
||||
|
||||
Each setting in the configuration file has a command line equivalent which can be used with the `-o/--option` argument, which takes a `KEY=VALUE` string where `KEY` is constructed by joining each element of the YAML hierarchy with a period (.).
|
||||
|
||||
For example, the `image → repository-namespace` key in the YAML becomes `-o image.repository-namespace=NAME` on the command line and `springboot → enabled` becomes `-o springboot.enabled=BOOLEAN`.
|
||||
|
||||
The following convenience aliases take precedence over the `-o/--option` equivalents:
|
||||
|
||||
- `--namespace` is an alias for `image.repository-namespace`;
|
||||
|
||||
- `--name` corresponds to `image.repository-name`;
|
||||
|
||||
- `--tag` corresponds to `image.tag`;
|
||||
|
||||
- `--label` corresponds to `image.labels` (can be used multiple times);
|
||||
|
||||
- `--port` corresponds to `image.ports` (can be used multiple times)
|
||||
|
|
@ -1,65 +0,0 @@
|
|||
---
|
||||
title: Build a C# ASP.NET Core project
|
||||
description: Building a C# ASP.NET Core project using Docker Assemble
|
||||
keywords: Assemble, Docker Enterprise, Spring Boot, container image
|
||||
---
|
||||
|
||||
Ensure you are running the `backend` before you build any projects using Docker Assemble. For instructions on running the backend, see [Install Docker Assemble](/assemble/install).
|
||||
|
||||
Clone the git repository you would like to use. The following example uses the `dotnetdemo` repository.
|
||||
|
||||
```
|
||||
~$ git clone https://github.com/mbentley/dotnetdemo
|
||||
Cloning into 'dotnetdemo'...
|
||||
«…»
|
||||
```
|
||||
|
||||
Build the project using the `docker assemble build` command by passing it the path to the source repository (or a subdirectory in the following example):
|
||||
|
||||
```
|
||||
~$ docker assemble build dotnetdemo/dotnetdemo
|
||||
«…»
|
||||
Successfully built: docker.io/library/dotnetdemo:latest
|
||||
```
|
||||
The resulting image is exported to the local Docker image store using a name and a tag which are automatically determined by the project metadata.
|
||||
|
||||
```
|
||||
~$ docker image ls
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
dotnetdemo latest a055e61e3a9e 24 seconds ago 349MB
|
||||
```
|
||||
|
||||
An image name consists of `«namespace»/«name»:«tag»`. Where, `«namespace»/` is optional and defaults to `none`. If the project metadata does not contain a ‘tag’ (or a version), then latest is used. If the project metadata does not contain a ‘name’ and it was not provided on the command line, then a fatal error occurs.
|
||||
|
||||
Use the `--namespace`, `--name` and `--tag` options to override each element of the image name:
|
||||
|
||||
```
|
||||
~$ docker assemble build --name testing --tag latest dotnetdemo/
|
||||
«…»
|
||||
INFO[0007] Successfully built "testing:latest"
|
||||
~$ docker image ls
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
testing latest d7f41384814f 32 seconds ago 97.4MB
|
||||
hello-boot 1 0dbc2c425cff 5 minutes ago 97.4MB
|
||||
```
|
||||
|
||||
Run the container:
|
||||
|
||||
```
|
||||
~$ docker run -d --rm -p 8080:80 dotnetdemo:latest
|
||||
e1c54291e96967dad402a81c4217978a544e4d7b0fdd3c0a2e2cca384c3b4adb
|
||||
~$ docker ps
|
||||
CONTAINER ID IMAGE COMMAND «…» PORTS NAMES
|
||||
e1c54291e969 dotnetdemo:latest "dotnet dotnetdemo.d…" «…» 0.0.0.0:8080->80/tcp lucid_murdock
|
||||
~$ docker logs e1c54291e969
|
||||
warn: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35]
|
||||
No XML encryptor configured. Key {11bba23a-71ad-4191-b583-4f974e296033} may be persisted to storage in unencrypted form.
|
||||
Hosting environment: Production
|
||||
Content root path: /app
|
||||
Now listening on: http://[::]:80
|
||||
Application started. Press Ctrl+C to shut down.
|
||||
~$ curl -s localhost:8080 | grep '<h4>'
|
||||
<h4>This environment is </h4>
|
||||
<h4>served from e1c54291e969 at 11/22/2018 16:00:23</h4>
|
||||
~$ docker rm -f e1c54291e969
|
||||
```
|
||||
|
|
@ -1,114 +0,0 @@
|
|||
---
|
||||
title: Docker Assemble images
|
||||
description: Building Docker Assemble images
|
||||
keywords: Assemble, Docker Enterprise, plugin, Spring Boot, .NET, c#, F#
|
||||
---
|
||||
|
||||
## Multi-platform images
|
||||
|
||||
By default, Docker Assemble builds images for the `linux/amd64` platform and exports them to the local Docker image store. This is also true when running Docker Assemble on Windows or macOS. For some application frameworks, Docker Assemble can build multi-platform images to support running on several host platforms. For example, `linux/amd64` and `windows/amd64`.
|
||||
|
||||
To support multi-platform images, images must be pushed to a registry instead of the local image store. This is because the local image store can only import uni-platform images which match its platform.
|
||||
|
||||
To enable the multi-platform mode, use the `--push` option. For example:
|
||||
|
||||
```
|
||||
docker assemble build --push /path/to/my/project
|
||||
```
|
||||
|
||||
To push to an insecure (unencrypted) registry, use `--push-insecure` instead of `--push`.
|
||||
|
||||
## Custom base images
|
||||
|
||||
Docker Assemble allows you to override the base images for building and running your project. For example, the following `docker-assemble.yaml` file defines `maven:3-ibmjava-8-alpine` as the base build image and `openjdk:8-jre-alpine` as the base runtime image (for linux/amd64 platform).
|
||||
|
||||
```
|
||||
version: "0.2.0"
|
||||
springboot:
|
||||
enabled: true
|
||||
build-image: "maven:3-ibmjava-8-alpine"
|
||||
runtime-images:
|
||||
linux/amd64: "openjdk:8-jre-alpine"
|
||||
```
|
||||
|
||||
Linux-based images must be Debian, Red Hat, or Alpine-based and have a standard environment with:
|
||||
|
||||
- `find`
|
||||
|
||||
- `xargs`
|
||||
|
||||
- `grep`
|
||||
|
||||
- `true`
|
||||
|
||||
- a standard POSIX shell (located at `/bin/sh`)
|
||||
|
||||
These tools are required for internal inspection that Docker Assemble performs on the images. Depending on the type of your project and your configuration, the base images must meet other requirements as described in the following sections.
|
||||
|
||||
### Spring Boot
|
||||
|
||||
Install Java JDK and maven on the base build image and ensure it is available in `$PATH`. Install a maven settings file as `/usr/share/maven/ref/settings-docker.xml` (irrespective of the install location of Maven).
|
||||
|
||||
Ensure the base runtime image has Java JRE installed and is available in `$PATH`. The build and runtime image must have the same version of Java installed.
|
||||
|
||||
Supported build platform:
|
||||
|
||||
- `linux/amd64`
|
||||
|
||||
Supported runtime platforms:
|
||||
|
||||
- `linux/amd64`
|
||||
|
||||
- `windows/amd64`
|
||||
|
||||
### ASP.NET Core
|
||||
|
||||
Install .NET Core SDK on the base build image and ensure it includes the [.NET Core command-line interface tools](https://docs.microsoft.com/en-us/dotnet/core/tools/?tabs=netcore2x).
|
||||
|
||||
Install [.NET Core command-line interface tools](https://docs.microsoft.com/en-us/dotnet/core/tools/?tabs=netcore2x) on the base runtime image.
|
||||
|
||||
Supported build platform:
|
||||
|
||||
- `linux/amd64`
|
||||
|
||||
Supported runtime platforms:
|
||||
|
||||
- `linux/amd64`
|
||||
|
||||
- `windows/amd64`
|
||||
|
||||
## Bill of lading
|
||||
|
||||
Docker Assemble generates a bill of lading when building an image. This contains information about the tools, base images, libraries, and packages used by Assemble to build the image and that are included in the runtime image. The bill of lading has two parts – one for build and one for runtime.
|
||||
|
||||
The build part includes:
|
||||
|
||||
- The base image used
|
||||
- A map of packages installed and their versions
|
||||
- A map of libraries used for the build and their versions
|
||||
- A map of build tools and their corresponding versions
|
||||
|
||||
The runtime part includes:
|
||||
|
||||
- The base image used
|
||||
- A map of packages installed and their versions
|
||||
- A map of runtime tools and their versions
|
||||
|
||||
You can find the bill of lading by inspecting the resulting image. It is stored using the label `com.docker.assemble.bill-of-lading`:
|
||||
|
||||
```
|
||||
docker image inspect --format '{{ index .Config.Labels "com.docker.assemble.bill-of-lading" }}' <image>
|
||||
```
|
||||
|
||||
> **Note:** The bill of lading is only supported on the `linux/amd64` platform and only for images which are based on Alpine (`apk`), Red Hat (`rpm`) or Debian (`dpkg-query`).
|
||||
|
||||
## Health checks
|
||||
|
||||
Docker Assemble only supports health checks on `linux/amd64` based runtime images and require certain additional commands to be present depending on the value of `image.healthcheck.kind`:
|
||||
|
||||
- `simple-tcpport-open:` requires the `nc` command
|
||||
- `springboot:` requires the `curl` and `jq` commands
|
||||
|
||||
On Alpine (`apk`) and Debian (`dpkg`) based images, these dependencies are installed automatically. For other base images, you must ensure they are present in the images you specify.
|
||||
|
||||
If your base runtime image lacks the necessary commands, you may need to set `image.healthcheck.kind` to `none` in your `docker-assemble.yaml` file.
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
---
|
||||
title: Install Docker Assemble
|
||||
description: Installing Docker Assemble
|
||||
keywords: Assemble, Docker Enterprise, plugin, Spring Boot, .NET, c#, F#
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Docker Assemble (`docker assemble`) is a plugin which provides a language and framework-aware tool that enables users to build an application into an optimized Docker container. With Docker Assemble, users can quickly build Docker images without providing configuration information (like Dockerfile) by auto-detecting the required information from existing framework configuration.
|
||||
|
||||
Docker Assemble supports the following application frameworks:
|
||||
|
||||
- [Spring Boot](https://spring.io/projects/spring-boot) when using the [Maven](https://maven.apache.org/) build system
|
||||
|
||||
- [ASP.NET Core](https://docs.microsoft.com/en-us/aspnet/core) (with C# and F#)
|
||||
|
||||
## System requirements
|
||||
|
||||
Docker Assemble requires a Linux, Windows, or a macOS Mojave with the Docker Engine installed.
|
||||
|
||||
## Install
|
||||
|
||||
Docker Assemble requires its own buildkit instance to be running in a Docker container on the local system. You can start and manage the backend using the `backend` subcommand of `docker assemble`.
|
||||
|
||||
To start the backend, run:
|
||||
|
||||
```
|
||||
~$ docker assemble backend start`
|
||||
Pulling image «…»: Success
|
||||
Started backend container "docker-assemble-backend-username" (3e627bb365a4)
|
||||
```
|
||||
|
||||
When the backend is running, it can be used for multiple builds and does not need to be restarted.
|
||||
|
||||
> **Note:** For instructions on running a remote backend, accessing logs, saving the build cache in a named volume, accessing a host port, and for information about the buildkit instance, see `--help` .
|
||||
|
||||
For advanced backend user information, see [Advanced Backend Management](/assemble/adv-backend-manage/).
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
---
|
||||
title: Build a Spring Boot project
|
||||
description: Building a Spring Boot project using Docker Assemble
|
||||
keywords: Assemble, Docker Enterprise, Spring Boot, container image
|
||||
---
|
||||
|
||||
Ensure you are running the `backend` before you build any projects using Docker Assemble. For instructions on running the backend, see [Install Docker Assemble](/assemble/install).
|
||||
|
||||
Clone the git repository you would like to use. The following example uses the `docker-springfamework` repository.
|
||||
|
||||
```
|
||||
~$ git clone https://github.com/anokun7/docker-springframework
|
||||
Cloning into 'docker-springframework'...
|
||||
«…»
|
||||
```
|
||||
When you build a Spring Boot project, Docker Assemble automatically detects the information it requires from the `pom.xml` project file.
|
||||
|
||||
Build the project using the `docker assemble build` command by passing it the path to the source repository:
|
||||
|
||||
```
|
||||
~$ docker assemble build docker-springframework
|
||||
«…»
|
||||
Successfully built: docker.io/library/hello-boot:1
|
||||
```
|
||||
The resulting image is exported to the local Docker image store using a name and a tag which are automatically determined by the project metadata.
|
||||
|
||||
```
|
||||
~$ docker image ls | head -n 2
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
hello-boot 1 00b0fbcf3c40 About a minute ago 97.4MB
|
||||
```
|
||||
|
||||
An image name consists of `«namespace»/«name»:«tag»`. Where, `«namespace»/` is optional and defaults to `none`. If the project metadata does not contain a ‘tag’ (or a version), then `latest` is used. If the project metadata does not contain a ‘name’ and it was not provided on the command line, a fatal error occurs.
|
||||
|
||||
Use the `--namespace`, `--name` and `--tag` options to override each element of the image name:
|
||||
|
||||
```
|
||||
~$ docker assemble build --name testing --tag latest docker-springframework/
|
||||
«…»
|
||||
INFO[0007] Successfully built "testing:latest"
|
||||
~$ docker image ls
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
testing latest d7f41384814f 32 seconds ago 97.4MB
|
||||
hello-boot 1 0dbc2c425cff 5 minutes ago 97.4MB
|
||||
```
|
||||
|
||||
Run the container:
|
||||
|
||||
```
|
||||
~$ docker run -d --rm -p 8080:8080 hello-boot:1
|
||||
b2c88bdc35761ba2b99f85ce1f3e3ce9ed98931767b139a0429865cadb46ce13
|
||||
~$ docker ps
|
||||
CONTAINER ID IMAGE COMMAND «…» PORTS NAMES
|
||||
b2c88bdc3576 hello-boot:1 "java -Djava.securit…" «…» 0.0.0.0:8080->8080/tcp silly_villani
|
||||
~$ docker logs b2c88bdc3576
|
||||
|
||||
. ____ _ __ _ _
|
||||
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
|
||||
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
|
||||
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
|
||||
' |____| .__|_| |_|_| |_\__, | / / / /
|
||||
=========|_|==============|___/=/_/_/_/
|
||||
:: Spring Boot :: (v1.5.2.RELEASE)
|
||||
|
||||
«…» : Starting Application v1 on b2c88bdc3576 with PID 1 (/hello-boot-1.jar started by root in /)
|
||||
«…»
|
||||
~$ curl -s localhost:8080
|
||||
Hello from b2c88bdc3576
|
||||
~$ docker rm -f b2c88bdc3576
|
||||
```
|
||||
|
|
@ -1,131 +0,0 @@
|
|||
---
|
||||
title: Configure Docker Desktop Enterprise on Mac
|
||||
description: Learn about Docker Desktop Enterprise
|
||||
keywords: Docker EE, Windows, Mac, Docker Desktop, Enterprise
|
||||
---
|
||||
|
||||
This page contains information on how system administrators can configure Docker Desktop Enterprise (DDE) settings, specify and lock configuration parameters to create a standardized development environment on Mac operating systems.
|
||||
|
||||
## Environment configuration (administrators only)
|
||||
|
||||
The administrator configuration file allows you to customize and standardize your Docker Desktop environment across the organization.
|
||||
|
||||
When you install Docker Desktop Enterprise, a configuration file with default values is installed at the following location. Do not change the location of the `admin-settings.json` file.
|
||||
|
||||
`/Library/Application Support/Docker/DockerDesktop/admin-settings.json`
|
||||
|
||||
To edit `admin-settings.json`, you must have sudo access privileges.
|
||||
|
||||
### Syntax for `admin-settings.json`
|
||||
|
||||
1. `configurationFileVersion`: This must be the first parameter listed in `admin-settings.json`. It specifies the version of the configuration file format and must not be changed.
|
||||
|
||||
2. A nested list of configuration parameters, each of which contains a minimum of the following two settings:
|
||||
|
||||
- `locked`: If set to `true`, users without elevated access privileges are not able to edit this setting from the UI or by directly editing the `settings.json` file (the `settings.json` file stores the user's preferences). If set to `false`, users without elevated access privileges can change this setting from the UI or by directly editing
|
||||
`settings.json`. If this setting is omitted, the default value is `false`.
|
||||
|
||||
- `value`: Specifies the value of the parameter. Docker Desktop Enterprise uses the value when first started and after a reset to factory defaults. If this setting is omitted, a default value that is built into the application is used.
|
||||
|
||||
### Parameters and settings
|
||||
|
||||
The following `admin-settings.json` code and table provide the required syntax and descriptions for parameters and values:
|
||||
|
||||
```json
|
||||
{
|
||||
"configurationFileVersion": 1,
|
||||
"analyticsEnabled": {
|
||||
"locked": false,
|
||||
"value": false
|
||||
},
|
||||
"dockerCliOptions": {
|
||||
"stackOrchestrator": {
|
||||
"locked": false,
|
||||
"value": "swarm"
|
||||
}
|
||||
},
|
||||
"proxy": {
|
||||
"locked": false,
|
||||
"value": {
|
||||
"http": "http://proxy.docker.com:8080",
|
||||
"https": "https://proxy.docker.com:8080",
|
||||
"exclude": "docker.com,github.com"
|
||||
}
|
||||
},
|
||||
"linuxVM": {
|
||||
"cpus": {
|
||||
"locked": false,
|
||||
"value": 2
|
||||
},
|
||||
"memoryMiB": {
|
||||
"locked": false,
|
||||
"value": 2048
|
||||
},
|
||||
"swapMiB": {
|
||||
"locked": false,
|
||||
"value": 1024
|
||||
},
|
||||
"diskSizeMiB": {
|
||||
"locked": false,
|
||||
"value": 65536
|
||||
},
|
||||
"dataFolder" : {
|
||||
"value" : "/Users/...",
|
||||
"locked" : false
|
||||
},
|
||||
"filesharingDirectories": {
|
||||
"locked":false,
|
||||
"value":["/Users", "..."]
|
||||
},
|
||||
"dockerDaemonOptions": {
|
||||
"experimental": {
|
||||
"locked": false,
|
||||
"value": true
|
||||
}
|
||||
}
|
||||
},
|
||||
"kubernetes": {
|
||||
|
||||
"enabled": {
|
||||
"locked": false,
|
||||
"value": false
|
||||
},
|
||||
"showSystemContainers": {
|
||||
"locked": false,
|
||||
"value": false
|
||||
},
|
||||
"podNetworkCIDR": {
|
||||
"locked": false,
|
||||
"value": null
|
||||
},
|
||||
"serviceCIDR": {
|
||||
"locked": false,
|
||||
"value": null
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Parameter values and descriptions for environment configuration on Mac:
|
||||
|
||||
| Parameter | Description |
|
||||
| :--------------------------------- | :--------------------------------- |
|
||||
| `configurationFileVersion` | Specifies the version of the configuration file format. |
|
||||
| `analyticsEnabled` | If `value` is true, allow Docker Desktop Enterprise to sends diagnostics, crash reports, and usage data. This information helps Docker improve and troubleshoot the application. |
|
||||
| `dockerCliOptions` | Specifies key-value pairs in the user's `~/.docker/config.json` file. In the sample code provided, the orchestration for docker stack commands is set to `swarm` rather than `kubernetes`. |
|
||||
| `proxy` | The `http` setting specifies the HTTP proxy setting. The `https` setting specifies the HTTPS proxy setting. The `exclude` setting specifies a comma-separated list of hosts and domains to bypass the proxy. **Warning:** This parameter should be locked after being set: `locked: "true"`. |
|
||||
| `linuxVM` | Parameters and settings related to the Linux VM - grouped together in this example for convenience. |
|
||||
| `cpus` | Specifies the default number of virtual CPUs for the VM. If the physical machine has only 1 core, the default value is set to 1. |
|
||||
| `memoryMiB` | Specifies the amount of memory in MiB (1 MiB = 1048576 bytes) allocated for the VM.|
|
||||
| `swapMiB` | Specifies the amount of memory in MiB (1 MiB = 1048576 bytes) allocated for the swap file. |
|
||||
| `dataFolder` | Specifies the directory containing the VM disk files. |
|
||||
| `diskSizeMiB` | Specifies the amount of disk storage in MiB (1 MiB = 1048576 bytes) allocated for images and containers. |
|
||||
| `filesharingDirectories` | The host folders that users can bind-mount in containers. |
|
||||
| `dockerDaemonOptions` | Overrides the options in the linux daemon config file. For more information, see [Docker engine reference](https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file). |
|
||||
| (End of `linuxVM` section.) | |
|
||||
| `kubernetes` | Parameters and settings related to kubernetes options - grouped together here for convenience. |
|
||||
| `enabled` | If `locked` is set to `true`, the Kubernetes cluster starts when Docker Desktop Enterprise is started. |
|
||||
| `showSystemContainers` | If true, displays Kubernetes internal containers when running docker commands such as `docker ps`. |
|
||||
| `podNetworkCIDR` | This is currently unimplemented. `locked` must be set to true. |
|
||||
| `serviceCIDR` | This is currently unimplemented. `locked` must be set to true. |
|
||||
| (End of `kubernetes` section.) | |
|
||||
|
|
@ -1,182 +0,0 @@
|
|||
---
|
||||
title: Configure Docker Desktop Enterprise on Windows
|
||||
description: Learn about Docker Desktop Enterprise configuration
|
||||
keywords: Docker Admin, Windows, Docker Desktop, Enterprise
|
||||
---
|
||||
|
||||
This page contains information on how system administrators can configure Docker Desktop Enterprise (DDE) settings, specify and lock configuration parameters to create a standardized development environment on Windows operating systems.
|
||||
|
||||
## Environment configuration (administrators only)
|
||||
|
||||
The administrator configuration file allows you to customize and standardize your Docker Desktop environment across the organization.
|
||||
|
||||
When you install Docker Desktop Enterprise, a configuration file with default values is installed at the following location. Do not change the location of the `admin-settings.json` file.
|
||||
|
||||
`\%ProgramData%\DockerDesktop\admin-settings.json`
|
||||
|
||||
which defaults to:
|
||||
|
||||
`C:\ProgramData\DockerDesktop\admin-settings.json`
|
||||
|
||||
You must have administrator access privileges to edit `admin-settings.json`.
|
||||
|
||||
### Syntax for `admin-settings.json`
|
||||
|
||||
1. `configurationFileVersion`: This must be the first parameter listed in `admin-settings.json`. It specifies the version of the configuration file format and must not be changed.
|
||||
|
||||
2. A nested list of configuration parameters, each of which contains a minimum of
|
||||
the following two settings:
|
||||
|
||||
- `locked`: If set to `true`, users without elevated access privileges are not able to edit this setting
|
||||
from the UI or by directly editing the `settings.json` file (the `settings.json` file stores the user's preferences). If set to `false`, users without elevated access privileges can change this setting from the UI or by directly editing
|
||||
`settings.json`. If this setting is omitted, the default value is `false'.
|
||||
|
||||
- `value`: Specifies the value of the parameter. Docker Desktop Enterprise uses the value when first started and after a reset to factory defaults. If this setting is omitted, a default value that is built into the application is used.
|
||||
|
||||
### Parameters and settings
|
||||
|
||||
The following `admin-settings.json` code and table provide the required syntax and descriptions for parameters and values:
|
||||
|
||||
```json
|
||||
{
|
||||
"configurationFileVersion": 1,
|
||||
"engine": {
|
||||
"locked": false,
|
||||
"value": "linux"
|
||||
},
|
||||
"analyticsEnabled": {
|
||||
"locked": false,
|
||||
"value": false
|
||||
},
|
||||
"exposeDockerAPIOnTCP2375": {
|
||||
"locked": false,
|
||||
"value": false
|
||||
},
|
||||
"dockerCliOptions": {
|
||||
"stackOrchestrator": {
|
||||
"locked": false,
|
||||
"value": "swarm"
|
||||
}
|
||||
},
|
||||
"proxy": {
|
||||
"locked": false,
|
||||
"value": {
|
||||
"http": "http://proxy.docker.com:8080",
|
||||
"https": "https://proxy.docker.com:8080",
|
||||
"exclude": "docker.com,github.com"
|
||||
}
|
||||
},
|
||||
|
||||
"linuxVM": {
|
||||
"cpus": {
|
||||
"locked": false,
|
||||
"value": 2
|
||||
},
|
||||
"memoryMiB": {
|
||||
"locked": false,
|
||||
"value": 2048
|
||||
},
|
||||
"swapMiB": {
|
||||
"locked": false,
|
||||
"value": 1024
|
||||
},
|
||||
"dataFolder": {
|
||||
"locked": false,
|
||||
"value": null
|
||||
},
|
||||
"diskSizeMiB": {
|
||||
"locked": false,
|
||||
"value": 65536
|
||||
},
|
||||
"hypervCIDR": {
|
||||
"locked": false,
|
||||
"value": "10.0.75.0/28"
|
||||
},
|
||||
"vpnkitCIDR": {
|
||||
"locked": false,
|
||||
"value": "192.168.65.0/28"
|
||||
},
|
||||
"useDnsForwarder": {
|
||||
"locked": false,
|
||||
"value": true
|
||||
},
|
||||
"dns": {
|
||||
"locked": false,
|
||||
"value": "8.8.8.8"
|
||||
},
|
||||
"dockerDaemonOptions": {
|
||||
"experimental": {
|
||||
"locked": false,
|
||||
"value": true
|
||||
}
|
||||
}
|
||||
},
|
||||
|
||||
"windows": {
|
||||
"dockerDaemonOptions": {
|
||||
"experimental": {
|
||||
"locked": false,
|
||||
"value": true
|
||||
}
|
||||
}
|
||||
},
|
||||
"kubernetes": {
|
||||
"enabled": {
|
||||
"locked": false,
|
||||
"value": false
|
||||
},
|
||||
"showSystemContainers": {
|
||||
"locked": false,
|
||||
"value": false
|
||||
},
|
||||
"podNetworkCIDR": {
|
||||
"locked": false,
|
||||
"value": null
|
||||
},
|
||||
"serviceCIDR": {
|
||||
"locked": false,
|
||||
"value": null
|
||||
}
|
||||
},
|
||||
|
||||
"sharedDrives": {
|
||||
"locked": true,
|
||||
"value": [ ]
|
||||
},
|
||||
"sharedFolders": ["%USERPROFILE%"]
|
||||
}
|
||||
```
|
||||
|
||||
Parameter values and descriptions for environment configuration on Windows:
|
||||
|
||||
| Parameter | Description |
|
||||
| :--------------------------------- | :--------------------------------- |
|
||||
| `configurationFileVersion` | Specifies the version of the configuration file format. |
|
||||
| `engine` | Specifies the default Docker engine to be used. `linux` specifies the Linux engine. `windows` specifies the Windows engine. |
|
||||
| `analyticsEnabled` | If `value` is true, allow Docker Desktop Enterprise to sends diagnostics, crash reports, and usage data. This information helps Docker improve and troubleshoot the application. |
|
||||
| `exposeDockerAPIOnTCP2375` | Exposes Docker API on a specified port. In this example, setting 'locked' to `true` exposes the Docker API on port 2375. **Warning:** This is unauthenticated and should only be enabled if protected by suitable firewall rules.|
|
||||
| `dockerCliOptions` | Specifies key-value pairs in the user's `%HOME%\.docker\config.json` file. In the sample code provided, the orchestration for docker stack commands is set to `swarm` rather than `kubernetes`. |
|
||||
| `proxy` | The `http` setting specifies the HTTP proxy setting. The `https` setting specifies the HTTPS proxy setting. The `exclude` setting specifies a comma-separated list of hosts and domains to bypass the proxy. **Warning:** This parameter should be locked after being set: `locked: "true"`. |
|
||||
| `linuxVM` | Parameters and settings related to the Linux VM - grouped together in this example for convenience. |
|
||||
| `cpus` | Specifies the default number of virtual CPUs for the VM. If the physical machine has only 1 core, the default value is set to 1. |
|
||||
| `memoryMiB` | Specifies the amount of memory in MiB (1 MiB = 1048576 bytes) allocated for the VM.
|
||||
| `swapMiB` | Specifies the amount of memory in MiB (1 MiB = 1048576 bytes) allocated for the swap file. |
|
||||
| `dataFolder` | Specifies the root folder where Docker Desktop should put VM disk files. |
|
||||
| `diskSizeMiB` | Specifies the amount of disk storage in MiB (1 MiB = 1048576 bytes) allocated for images and containers. |
|
||||
| `hypervCIDR` | Specifies the subnet used for Hyper-V networking. The chosen subnet must not conflict with other resources on your network. |
|
||||
| `vpnkitCIDR` | Specifies the subnet used for VPNKit networking and drive sharing. The chosen subnet must not conflict with other resources on your network. |
|
||||
| `useDnsForwarder` | If `value` is set to `true`, this automatically determines the upstream DNS servers based on the host's network adapters. |
|
||||
| `dns` | If `value` for `useDnsForwarder` is set to `false`, the Linux VM uses the server information in this `value` setting for DNS resolution. |
|
||||
| `dockerDaemonOptions` | Overrides the options in the Linux daemon config file. For more information, see [Docker engine reference](https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file). |
|
||||
| (End of `linuxVM` section.) | |
|
||||
| `windows` | Parameters and settings related to the Windows daemon-related options - grouped together in this example for convenience. |
|
||||
| `dockerDaemonOptions` | Overrides the options in the Windows daemon config file. For more information, see [Docker engine reference](https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file). |
|
||||
| (End of `windows` section.) | |
|
||||
| `kubernetes` | Parameters and settings related to kubernetes options - grouped together here for convenience. |
|
||||
| `enabled` | If `locked` is set to `true`, the Kubernetes cluster starts when Docker Desktop Enterprise is started. |
|
||||
| `showSystemContainers` | If true, displays Kubernetes internal containers when running docker commands such as `docker ps`. |
|
||||
| `podNetworkCIDR` | This is currently unimplemented. `locked` must be set to true. |
|
||||
| `serviceCIDR` | This is currently unimplemented. `locked` must be set to true. |
|
||||
| (End of `kubernetes` section.) | |
|
||||
| `sharedDrives` | If `sharedDrives` is set to `true`, this locks the drives users are allowed to share ( `["C", "D"]` ), but does not actually share drives by default (sharing a drive prompts the user for a password). `value` is a whitelist of drives that can be shared. **Warning:** Note that when updating this value, if you remove drives that have been shared, you must also `net share /delete` those drives. |
|
||||
| `sharedFolders` | If specified, restrict the folders the user is allowed to share with Windows containers. |
|
||||
|
|
@ -1,105 +0,0 @@
|
|||
---
|
||||
title: Install Docker Desktop Enterprise on Mac
|
||||
description: Learn about Docker Desktop Enterprise
|
||||
keywords: Docker EE, Mac, Docker Desktop, Enterprise
|
||||
---
|
||||
|
||||
This page contains information about the system requirements and specific instructions that help you install Docker Desktop Enterprise (DDE) on Mac.
|
||||
|
||||
> **Warning:** If you are using the Community version of Docker Desktop, you must uninstall Docker Desktop Community in order to install Docker Desktop Enterprise.
|
||||
|
||||
## System requirements
|
||||
|
||||
- Mac hardware must be a 2010 or newer model, with Intel’s hardware support for memory management unit (MMU) virtualization, including Extended Page Tables (EPT) and Unrestricted Mode. You can check to see if your machine has this support by running the following command in a terminal: `sysctl kern.hv_support`
|
||||
|
||||
- macOS 10.12 and newer macOS releases are supported. We recommend upgrading to the latest version of macOS.
|
||||
|
||||
- At least 4GB of RAM
|
||||
|
||||
- VirtualBox prior to version 4.3.30 must NOT be installed (it is incompatible with Docker for Mac). If you have a newer version of VirtualBox installed, it’s fine.
|
||||
|
||||
> **Note:** Docker supports Docker Desktop Enterprise on the most recent versions of macOS. That is, the current release of macOS and the previous two releases. As new major versions of macOS are made generally available, Docker will stop supporting the oldest version and support the newest version of macOS (in addition to the previous two releases).
|
||||
|
||||
## Installation
|
||||
|
||||
Download Docker Desktop Enterprise for [**Mac**](https://download.docker.com/mac/enterprise/Docker.pkg). The DDE installer includes Docker Engine, Docker CLI client, and Docker Compose.
|
||||
|
||||
Double-click the `.pkg` file to begin the installation and follow the on-screen instructions. When the installation is complete, click the Launchpad icon in the Dock and then **Docker** to start Docker Desktop.
|
||||
|
||||
Mac administrators can use the command line option `\$ sudo installer -pkg Docker.pkg -target /` for fine tuning and mass installation. After running this command, you can start Docker Desktop from the Applications folder on each machine.
|
||||
|
||||
Administrators can configure additional settings by modifying the administrator configuration file. For more information, see [Configure Desktop Enterprise for Mac](/ee/desktop/admin/configure/mac-admin).
|
||||
|
||||
## License file
|
||||
|
||||
Install the Docker Desktop Enterprise license file at the following location:
|
||||
|
||||
`/Library/Group Containers/group.com.docker/docker_subscription.lic`
|
||||
|
||||
You must create the path if it doesn't already exist. If the license file is missing, you will be asked to provide it when you try to run Docker Desktop Enterprise. Contact your system administrator to obtain the license file.
|
||||
|
||||
## Firewall exceptions
|
||||
|
||||
Docker Desktop Enterprise requires the following firewall exceptions. If you do not have firewall access, or are unsure about how to set firewall exceptions, contact your system administrator.
|
||||
|
||||
- The process `com.docker.vpnkit` proxies all outgoing container TCP and
|
||||
UDP traffic. This includes Docker image downloading but not DNS
|
||||
resolution, which is performed over a Unix domain socket connected
|
||||
to the `mDNSResponder` system service.
|
||||
|
||||
- The process `com.docker.vpnkit` binds external ports on behalf of
|
||||
containers. For example, `docker run -p 80:80 nginx` binds port 80 on all
|
||||
interfaces.
|
||||
|
||||
- If using Kubernetes, the API server is exposed with TLS on
|
||||
`127.0.0.1:6443` by `com.docker.vpnkit`.
|
||||
|
||||
## Version packs
|
||||
|
||||
Docker Desktop Enterprise is bundled with default version pack [Enterprise 3.0 (Docker Engine 19.03 / Kubernetes 1.14.1)](https://download.docker.com/mac/enterprise/enterprise-3.0.ddvp). System administrators can install version packs using a command line tool to use a different version of the Docker Engine and Kubernetes for development work:
|
||||
|
||||
- [Docker Enterprise 2.0 (17.06/Kubernetes 1.8.11)](https://download.docker.com/mac/enterprise/enterprise-2.0.ddvp)
|
||||
|
||||
- [Docker Enterprise 2.1 (18.09/Kubernetes 1.11.5)](https://download.docker.com/mac/enterprise/enterprise-2.1.ddvp)
|
||||
|
||||
For information on using the CLI tool for version pack installation, see [Command line installation](#command-line-installation).
|
||||
|
||||
> **Note:** It is not possible to install the version packs using the Docker Desktop user interface or by double-clicking the `.ddvp` file.
|
||||
|
||||
Available version packs are listed within the **Version Selection** option in the Docker Desktop menu. If more than one version pack is installed, you can select the corresponding entry to work with a different version pack. After you select a different version pack, Docker Desktop restarts and the selected Docker Engine and Kubernetes versions are used.
|
||||
|
||||
If more than one version pack is installed, you can select the corresponding entry to work with a different version pack. After you select a different version pack, Docker Desktop restarts and the selected Docker Engine and Kubernetes versions are used.
|
||||
|
||||
## Command line installation
|
||||
|
||||
System administrators can use a command line executable to install and uninstall Docker Desktop Enterprise and version packs.
|
||||
|
||||
When you install Docker Desktop Enterprise, the command line tool is installed at the following location:
|
||||
|
||||
[ApplicationPath]/Contents/Resources/bin/dockerdesktop-admin
|
||||
|
||||
>**Note:** Command line installation is supported for administrators only. You must have `sudo` access privilege to run the CLI commands.
|
||||
|
||||
### Version-pack install
|
||||
|
||||
Run the following command to install or upgrade a version pack to the version contained in the specified `.ddvp` archive:
|
||||
|
||||
dockerdesktop-admin version-pack install [path-to-archive]
|
||||
|
||||
>**Note:** You must stop Docker Desktop before installing a version pack.
|
||||
|
||||
### Version-pack uninstall
|
||||
|
||||
Run the following command to uninstall the specified version pack:
|
||||
|
||||
dockerdesktop-admin version-pack uninstall [version-pack-name]
|
||||
|
||||
>**Note:** You must stop Docker Desktop before uninstalling a version pack.
|
||||
|
||||
### Application uninstall
|
||||
|
||||
Run the following command to uninstall the application:
|
||||
|
||||
sudo /Applications/Docker.app/Contents/Resources/bin/dockerdesktop-admin app uninstall
|
||||
|
||||
The `sudo` command uninstalls files such as version packs that are installed by an administrator, but are not accessible by users.
|
||||
|
|
@ -1,122 +0,0 @@
|
|||
---
|
||||
title: Install Docker Desktop Enterprise on Windows
|
||||
description: Learn about Docker Desktop Enterprise
|
||||
keywords: Docker EE, Windows, Docker Desktop, Enterprise
|
||||
---
|
||||
|
||||
This page contains information about the system requirements and specific instructions that help you install Docker Desktop Enterprise (DDE) on Windows.
|
||||
|
||||
> **Warning:** If you are using the Community version of Docker Desktop, you must uninstall Docker Desktop Community in order to install Docker Desktop Enterprise.
|
||||
|
||||
## System requirements
|
||||
|
||||
- Windows 10 Pro or Enterprise version 15063 or later.
|
||||
|
||||
- Hyper-V and Containers Windows features must be enabled.
|
||||
|
||||
- The following hardware prerequisites are required to successfully run Client
|
||||
Hyper-V on Windows 10:
|
||||
|
||||
- 64 bit processor with [Second Level Address Translation (SLAT)](http://en.wikipedia.org/wiki/Second_Level_Address_Translation)
|
||||
|
||||
- 4GB system RAM
|
||||
|
||||
- BIOS-level hardware virtualization support must be enabled in the
|
||||
BIOS settings:
|
||||
|
||||
|
||||
|
||||
> **Note:** Docker supports Docker Desktop Enterprise on Windows based on Microsoft’s support lifecycle for Windows 10 operating system. For more information, see the [Windows lifecycle fact sheet](https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet).
|
||||
|
||||
## Installation
|
||||
|
||||
Download Docker Desktop Enterprise for [**Windows**](https://download.docker.com/win/enterprise/DockerDesktop.msi).
|
||||
|
||||
The Docker Desktop Enterprise installer includes Docker Engine, Docker CLI client, and Docker Compose.
|
||||
|
||||
Double-click the `.msi` file to begin the installation and follow the on-screen instructions. When the installation is complete, select **Docker Desktop** from the Start menu to start Docker Desktop.
|
||||
|
||||
For information about installing DDE using the command line, see [Command line installation](#command-line-installation).
|
||||
|
||||
## License file
|
||||
|
||||
Install the Docker Desktop Enterprise license file at the following location:
|
||||
|
||||
%ProgramData%\DockerDesktop\docker_subscription.lic
|
||||
|
||||
You must create the path if it doesn't already exist. If the license file is missing, you will be asked to provide it when you try to run Docker Desktop Enterprise. Contact your system administrator to obtain the license file.
|
||||
|
||||
## Firewall exceptions
|
||||
|
||||
Docker Desktop Enterprise requires the following firewall exceptions. If you do not have firewall access, or are unsure about how to set firewall exceptions, contact your system administrator.
|
||||
|
||||
- The process `com.docker.vpnkit` proxies all outgoing container TCP and
|
||||
UDP traffic. This includes Docker image downloading but not DNS
|
||||
resolution, which is performed over a loopback TCP and UDP connection
|
||||
to the main application.
|
||||
|
||||
- The process `com.docker.vpnkit` binds external ports on behalf of
|
||||
containers. For example, `docker run -p 80:80 nginx` binds port 80 on all
|
||||
interfaces.
|
||||
|
||||
- If using Kubernetes, the API server is exposed with TLS on `127.0.0.1:6445` by `com.docker.vpnkit`.
|
||||
|
||||
## Version packs
|
||||
|
||||
Docker Desktop Enterprise is bundled with default version pack [Enterprise 3.0 (Docker Engine 19.03 / Kubernetes 1.14.1)](https://download.docker.com/win/enterprise/enterprise-3.0.ddvp). System administrators can install version packs using a command line tool to use a different version of the Docker Engine and Kubernetes for development work:
|
||||
|
||||
- [Docker Enterprise 2.0 (17.06/Kubernetes 1.8.11)](https://download.docker.com/win/enterprise/enterprise-2.0.ddvp)
|
||||
|
||||
- [Docker Enterprise 2.1 (18.09/Kubernetes 1.11.5)](https://download.docker.com/win/enterprise/enterprise-2.1.ddvp)
|
||||
|
||||
For information on using the CLI tool for version pack installation, see [Command line installation](#command-line-installation).
|
||||
|
||||
Available version packs are listed within the **Version Selection** option in the Docker Desktop menu. If more than one version pack is installed, you can select the corresponding entry to work with a different version pack. After you select a different version pack, Docker Desktop restarts and the selected Docker Engine and Kubernetes versions are used.
|
||||
|
||||
## Command line installation
|
||||
|
||||
>**Note:** Command line installation is supported for administrators only. You must have `administrator` access to run the CLI commands.
|
||||
|
||||
System administrators can use the command line for mass installation and fine tuning the Docker Desktop Enterprise deployment. Run the following command as an administrator to perform a silent installation:
|
||||
|
||||
msiexec /i DockerDesktop.msi /quiet
|
||||
|
||||
You can also set the following properties:
|
||||
|
||||
- `INSTALLDIR [string]:` configures the folder to install Docker Desktop to (default is C:\Program Files\Docker\Docker)
|
||||
- `STARTMENUSHORTCUT [yes|no]:` specifies whether to create an entry in the Start menu for Docker Desktop (default is yes)
|
||||
- `DESKTOPSHORTCUT [yes|no]:` specifies whether to create a shortcut on the desktop for Docker Desktop (default is yes)
|
||||
|
||||
For example:
|
||||
|
||||
msiexec /i DockerDesktop.msi /quiet AUTOSTART=no STARTMENUSHORTCUT=no INSTALLDIR=”D:\Docker Desktop”
|
||||
|
||||
Docker Desktop Enterprise includes a command line executable to install and uninstall version packs. When you install DDE, the command line tool is installed at the following location:
|
||||
|
||||
[ApplicationPath]\dockerdesktop-admin.exe
|
||||
|
||||
### Version-pack install
|
||||
|
||||
Run the following command to install or upgrade a version pack to the version contained in the specified `.ddvp` archive:
|
||||
|
||||
dockerdesktop-admin.exe -InstallVersionPack=['path-to-archive']
|
||||
|
||||
>**Note:** You must stop Docker Desktop before installing a version pack.
|
||||
|
||||
### Version-pack uninstall
|
||||
|
||||
Run the following command to uninstall the specified version pack:
|
||||
|
||||
dockerdesktop-admin.exe -UninstallVersionPack=[version-pack-name|'path-to-archive']
|
||||
|
||||
>**Note:** You must stop Docker Desktop before uninstalling a version pack.
|
||||
|
||||
### Application uninstall
|
||||
|
||||
To uninstall the application:
|
||||
|
||||
1. Open the **Add or remove programs** dialog
|
||||
|
||||
1. Select **Docker Desktop** from the **Apps & features** list.
|
||||
|
||||
1. Click **Uninstall**.
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
---
|
||||
title: Application Designer
|
||||
description: Docker Desktop Enterprise Application Designer
|
||||
keywords: Docker EE, Windows, Mac, Docker Desktop, Enterprise, templates, designer
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
The Application Designer helps Docker developers quickly create new
|
||||
Docker apps using a library of templates. To start the Application
|
||||
Designer, select the **Design new application** menu entry.
|
||||
|
||||
|
||||
|
||||
The list of available templates is provided:
|
||||
|
||||
|
||||
|
||||
After selecting a template, you can then customize your application, For
|
||||
example, if you select **Flask / NGINX / MySQL**, you can then
|
||||
|
||||
- select a different version of python or mysql; and
|
||||
|
||||
- choose different external ports:
|
||||
|
||||
|
||||
|
||||
You can then name your application and customize the disk location:
|
||||
|
||||
|
||||
|
||||
When you select **Assemble**, your application is created.
|
||||
|
||||
|
||||
|
||||
Once assembled, the following screen allows you to run the application. Select **Run application** to pull the images and start the containers:
|
||||
|
||||
|
||||
|
||||
Use the corresponding buttons to start and stop your application. Select **Open in Finder** on Mac or **Open in Explorer** on Windows to
|
||||
view application files on disk. Select **Open in Visual Studio Code** to open files with an editor. Note that debug logs from the application are displayed in the lower part of the Application Designer
|
||||
window.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 244 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 152 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 204 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 105 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 259 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 198 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 288 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 73 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 54 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 95 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 81 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 56 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 9.5 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 43 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 45 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 108 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 88 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 37 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 67 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 142 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 125 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 133 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 155 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 137 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 125 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 127 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 94 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 115 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 93 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 43 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 59 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 566 B |
Binary file not shown.
|
Before Width: | Height: | Size: 38 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 302 KiB |
|
|
@ -1,55 +0,0 @@
|
|||
---
|
||||
title: Docker Desktop Enterprise overview
|
||||
description: Learn about Docker Desktop Enterprise
|
||||
keywords: Docker EE, Windows, Mac, Docker Desktop, Enterprise
|
||||
---
|
||||
|
||||
Docker Desktop Enterprise (DDE) provides local development, testing, and building of Docker applications on Mac and Windows. With work performed locally, developers can leverage a rapid feedback loop before pushing code or Docker images to shared servers / continuous integration infrastructure.
|
||||
|
||||
Docker Desktop Enterprise takes Docker Desktop Community, formerly known as Docker for Windows and Docker for Mac, a step further with simplified enterprise application development and maintenance. With DDE, IT organizations can ensure developers are working with the same version of Docker Desktop and can easily distribute Docker Desktop to large teams using third-party endpoint management applications. With the Docker Desktop graphical user interface (GUI), developers do not have to work with lower-level Docker commands and can auto-generate Docker artifacts.
|
||||
|
||||
Installed with a single click or command line command, Docker Desktop Enterprise is integrated with the host OS framework, networking, and filesystem. DDE is also designed to integrate with existing development environments (IDEs) such as Visual Studio and IntelliJ. With support for defined application templates, Docker Desktop Enterprise allows organizations to specify the look and feel of their applications.
|
||||
|
||||
Feature comparison of Docker Desktop Community versus Docker Desktop Enterprise:
|
||||
|
||||
| Feature | Docker Desktop (Community) | Docker Desktop Enterprise |
|
||||
| :------------------------- |:--------------------------:|:-------------------------:|
|
||||
| Docker Engine | X | X |
|
||||
| Certified Kubernetes | X | X |
|
||||
| Docker Compose | X | X |
|
||||
| CLI | X | X |
|
||||
| Windows and Mac support | X | X |
|
||||
| Version Selection | | X |
|
||||
| Application Designer | | X |
|
||||
| Custom application templates| | X |
|
||||
| Docker Assemble | | X |
|
||||
| Device management | | X |
|
||||
| Administrative control | | X |
|
||||
|
||||
## Docker Desktop Enterprise features
|
||||
|
||||
The following section lists features that are exclusive to Docker Desktop Enterprise:
|
||||
|
||||
### Version Selection
|
||||
|
||||
Configurable version packs ensure the local instance of Docker Desktop Enterprise is a precise copy of the production environment where applications are deployed.
|
||||
|
||||
System administrators can install version packs using a built-in command line tool. Once installed, developers can switch between versions of Docker and Kubernetes with a single click and ensure Docker and Kubernetes versions match UCP cluster versions.
|
||||
|
||||
### Application Designer
|
||||
|
||||
Application Designer provides a library of application and service templates to help developers quickly create new Docker applications.
|
||||
|
||||
### Application templates
|
||||
|
||||
Application templates allow you to choose a technology stack and focus on business logic and code, and require only minimal Docker syntax knowledge. Template support includes .NET, Spring, and more.
|
||||
|
||||
### Device management
|
||||
|
||||
The Docker Desktop Enterprise installer is available as standard MSI (Windows) and PKG (Mac) downloads, which allows administrators to script an installation across many developer workstations.
|
||||
|
||||
### Administrative control
|
||||
|
||||
IT organizations can specify and lock configuration parameters for the creation of standardized development environments, including disabling drive sharing.
|
||||
|
||||
Developers can then run commands using the command line without worrying about configuration settings.
|
||||
|
|
@ -1,75 +0,0 @@
|
|||
---
|
||||
title: Docker Desktop Enterprise release notes
|
||||
description: Release notes for Docker Desktop Enterprise
|
||||
keywords: Docker Desktop Enterprise, Windows, Mac, Docker Desktop, Enterprise,
|
||||
---
|
||||
|
||||
This topic contains information about the main improvements and issues, starting with the
|
||||
current release. The documentation is updated for each release.
|
||||
|
||||
For information on system requirements, installation, and download, see:
|
||||
|
||||
- [Install Docker Desktop Enterprise on Mac](/ee/desktop/admin/install/mac)
|
||||
- [Install Docker Desktop Enterprise on Windows](/ee/desktop/admin/install/windows)
|
||||
|
||||
For Docker Enterprise Engine release notes, see [Docker Engine release notes](/engine/release-notes).
|
||||
|
||||
## Docker Desktop Enterprise Releases of 2019
|
||||
|
||||
### Docker Desktop Enterprise 2.0.0.1
|
||||
|
||||
2019-03-01
|
||||
|
||||
**WARNING:** You must upgrade the previously installed Version Packs to the latest revision.
|
||||
|
||||
#### Windows
|
||||
|
||||
Upgrades:
|
||||
|
||||
- Docker 18.09.3 for Version Pack Enterprise 2.1, fixes [CVE-2019-5736](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736)
|
||||
|
||||
- Docker 17.06.2-ee-20 for Version Pack Enterprise 2.0, fixes [CVE-2019-5736](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736)
|
||||
|
||||
Bug fixes and minor changes:
|
||||
|
||||
- Fixed port 8080 that was used on localhost when starting Kubernetes.
|
||||
- Fixed Hub login through the desktop UI not sync with login through `docker login` command line.
|
||||
- Fixed crash in system tray menu when the Hub login fails or Air gap mode.
|
||||
|
||||
#### Mac
|
||||
|
||||
New features:
|
||||
|
||||
- Added ability to list all installed version packs with the admin CLI command `dockerdesktop-admin version-pack list`.
|
||||
- `dockerdesktop-admin app uninstall` will also remove Docker Desktop user files.
|
||||
|
||||
Upgrades:
|
||||
|
||||
- Docker 18.09.3 for Version Pack Enterprise 2.1, fixes [CVE-2019-5736](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736)
|
||||
|
||||
- Docker 17.06.2-ee-20 for Version Pack Enterprise 2.0, fixes [CVE-2019-5736](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736)
|
||||
|
||||
Bug fixes and minor changes:
|
||||
|
||||
- Fixed port 8080 that was used on localhost when starting Kubernetes.
|
||||
- Improved error messaging to suggest running diagnostics / resetting to factory default only when it is appropriate.
|
||||
|
||||
### Docker Desktop Enterprise 2.0.0.0
|
||||
|
||||
2019-01-31
|
||||
|
||||
New features:
|
||||
|
||||
- **Version selection**: Configurable version packs ensure the local
|
||||
instance of Docker Desktop Enterprise is a precise copy of the
|
||||
production environment where applications are deployed, and
|
||||
developers can switch between versions of Docker and
|
||||
Kubernetes with a single click.
|
||||
|
||||
- **Application Designer**: Application templates allow you to choose a
|
||||
technology and focus on business logic. Updates can be made with
|
||||
minimal syntax knowledge.
|
||||
|
||||
- **Device management**: The Docker Desktop Enterprise installer is available as standard MSI (Win) and PKG (Mac) downloads, which allows administrators to script an installation across many developer machines.
|
||||
|
||||
- **Administrative control**: IT organizations can specify and lock configuration parameters for creation of a standardized development environment, including disabling drive sharing and limiting version pack installations. Developers run commands in the command line without worrying about configuration settings.
|
||||
|
|
@ -1,78 +0,0 @@
|
|||
---
|
||||
title: Troubleshoot Docker Desktop Enterprise issues on Mac
|
||||
description: Troubleshoot Mac issues
|
||||
keywords: Troubleshoot, diagnose, Mac, issues, Docker Enterprise, Docker Desktop, Enterprise
|
||||
---
|
||||
|
||||
This page contains information on how to diagnose Docker Desktop Enterprise (DDE) issues on Mac.
|
||||
|
||||
## Creating a diagnostics file in Docker Desktop Enterprise
|
||||
|
||||
Select **Diagnose and Feedback** from the Docker menu in the menu bar.
|
||||
|
||||
|
||||
|
||||
Once diagnostics are available, select the **Open** button to display the list of available diagnostics in Finder.
|
||||
|
||||
Diagnostics are provided in .zip files identified by date and time. The uncompressed contents are also visible in the Finder window. Send your diagnostics file to your administrator for assistance.
|
||||
|
||||
### Creating a diagnostics file from a terminal
|
||||
|
||||
In some cases, it is useful to run diagnostics yourself, for instance if Docker Desktop Enterprise cannot start.
|
||||
|
||||
To run diagnostics from a terminal, enter the following command:
|
||||
|
||||
```
|
||||
/Applications/Docker.app/Contents/MacOS/com.docker.diagnose gather
|
||||
```
|
||||
|
||||
This command displays the information that it is gathering, and when it finishes, it displays information resembling the following example:
|
||||
|
||||
```
|
||||
Diagnostics Bundle: /tmp/2A989798-1658-4BF0-934D-AC4F148D0782/20190115142942.zip
|
||||
Diagnostics ID: 2A989798-1658-4BF0-934D-AC4F148D0782/20190115142942
|
||||
```
|
||||
|
||||
The name of the diagnostics file is displayed next to “Diagnostics Bundle” (`/tmp/2A989798-1658-4BF0-934D-AC4F148D0782/20190115142942.zip` in this example). This is the file that you attach to the support ticket.
|
||||
|
||||
You can view the content of your diagnostics file using the **open** command and specifying the name of your diagnostics file:
|
||||
|
||||
```sh
|
||||
$ open /tmp/2A989798-1658-4BF0-934D-AC4F148D0782/20190115142942.zip
|
||||
```
|
||||
|
||||
### Viewing logs in a terminal
|
||||
|
||||
In addition to using the **Diagnose and Feedback** option to generate a diagnostics file, you can
|
||||
browse Docker Desktop Enterprise logs in a terminal or with the Console app.
|
||||
|
||||
To watch the live flow of Docker Desktop Enterprise logs at the command line, run the following command from
|
||||
your favorite shell:
|
||||
|
||||
```bash
|
||||
$ pred='process matches ".*(ocker|vpnkit).*"
|
||||
|| (process in {"taskgated-helper", "launchservicesd", "kernel"} && eventMessage contains[c] "docker")'
|
||||
$ /usr/bin/log stream --style syslog --level=debug --color=always --predicate "$pred"
|
||||
```
|
||||
|
||||
Alternatively, to collect the last day of logs (`1d`) in a file, run:
|
||||
|
||||
```
|
||||
$ /usr/bin/log show --debug --info --style syslog --last 1d --predicate "$pred" >/tmp/logs.txt
|
||||
```
|
||||
|
||||
### Viewing logs with the Console app
|
||||
|
||||
The Console log viewer is located in `/Applications/Utilities`; you can search for it with Spotlight Search.
|
||||
|
||||
In the Console window search bar, type
|
||||
`docker` and press Enter. Then select **ANY** to expand the drop-down list next to your 'docker' search entry, and select **Process**.
|
||||
|
||||
|
||||
|
||||
You can use the Console app to search logs, filter the results in various
|
||||
ways, and create reports.
|
||||
|
||||
### Additional Docker Desktop Enterprise troubleshooting topics
|
||||
|
||||
You can also find additional information about various troubleshooting topics in the [Docker Desktop for Mac community](https://docs.docker.com/docker-for-mac/troubleshoot/) documentation.
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
---
|
||||
title: Troubleshoot Docker Desktop Enterprise issues on Windows
|
||||
description: Learn about Docker Desktop Enterprise
|
||||
keywords: Docker EE, Windows, Docker Desktop, Enterprise, troubleshoot
|
||||
---
|
||||
|
||||
This page contains information on how to diagnose Docker Desktop Enterprise (DDE) issues on Windows.
|
||||
|
||||
## Creating a diagnostics file in Docker Desktop Enterprise
|
||||
|
||||
Right-click the Docker icon in the system tray and select **Diagnose and Feedback** from the menu. When the **Diagnose & Feedback** window opens, it starts collecting diagnostics.
|
||||
|
||||
|
||||
|
||||
When the log capture is complete, select **You can find diagnostics here**. The file explorer window displays the path to the diagnostics .zip file and allows you to view the contents. Diagnostics are provided in .zip files identified by date and time.
|
||||
|
||||
Send your diagnostics file to your administrator for assistance.
|
||||
|
||||
### Creating a diagnostics file from a terminal
|
||||
|
||||
In some cases, it is useful to run diagnostics yourself, for instance if
|
||||
Docker Desktop Enterprise cannot start.
|
||||
|
||||
To run diagnostics from a terminal, enter the following command from a powershell window:
|
||||
|
||||
```powershell
|
||||
'C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe' gather
|
||||
```
|
||||
|
||||
This command displays the information that it is gathering, and when it finishes, it displays information resembling the following example:
|
||||
|
||||
```powershell
|
||||
Diagnostics Bundle: C:\Users\djs\AppData\Local\Temp\6CE654F6-7B17-4FC7-AAE0-CC53B73B76A2\20190115163621.zip
|
||||
Diagnostics ID: 6CE654F6-7B17-4FC7-AAE0-CC53B73B76A2/20190115163621
|
||||
```
|
||||
|
||||
The name of the diagnostics file is displayed next to “Diagnostics Bundle” (`\Temp\6CE654F6-7B17-4FC7-AAE0-CC53B73B76A2\20190115163621.zip` in this example). This is the file that you attach to the support ticket.
|
||||
|
||||
### Additional Docker Desktop Enterprise troubleshooting topics
|
||||
|
||||
You can also find additional information about various troubleshooting topics in the [Docker Desktop for Windows community](https://docs.docker.com/docker-for-windows/troubleshoot/) documentation.
|
||||
|
|
@ -1,424 +0,0 @@
|
|||
---
|
||||
title: Use Docker Desktop Enterprise on Mac
|
||||
description: Exploring the Mac user interface
|
||||
keywords: Docker EE, Windows, Mac, Docker Desktop, Enterprise
|
||||
---
|
||||
|
||||
This page contains information about testing the installation and configuring Docker Desktop Enterprise (DDE) runtime options on Mac.
|
||||
|
||||
## Test your installation
|
||||
|
||||
1. Open a command-line terminal and test that your installation works by
|
||||
running the simple Docker image, [hello-world](https://hub.docker.com/_/hello-world/).
|
||||
|
||||
```shell
|
||||
$ docker run hello-world
|
||||
|
||||
Unable to find image 'hello-world:latest' locally
|
||||
latest: Pulling from library/hello-world
|
||||
ca4f61b1923c: Pull complete
|
||||
Digest: sha256:ca0eeb6fb05351dfc8759c20733c91def84cb8007aa89a5bf606bc8b315b9fc7
|
||||
Status: Downloaded newer image for hello-world:latest
|
||||
|
||||
Hello from Docker!
|
||||
This message shows that your installation appears to be working correctly.
|
||||
...
|
||||
```
|
||||
|
||||
2. Start a Dockerized web server. Like the `hello-world` image above, if the
|
||||
image is not found locally, Docker pulls it from Docker Hub.
|
||||
|
||||
```bash
|
||||
$ docker run --detach --publish=80:80 --name=webserver nginx
|
||||
```
|
||||
|
||||
3. In a web browser, go to `http://localhost/` to view the nginx homepage.
|
||||
Because we specified the default HTTP port, it isn't necessary to append
|
||||
`:80` at the end of the URL.
|
||||
|
||||
|
||||
|
||||
4. View the details on the container while your web server is running (with
|
||||
`docker container ls` or `docker ps`):
|
||||
|
||||
```none
|
||||
$ docker container ls
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
56f433965490 nginx "nginx -g 'daemon off" About a minute ago Up About a minute 0.0.0.0:80->80/tcp, 443/tcp webserver
|
||||
```
|
||||
|
||||
5. Stop and remove containers and images with the following commands. Use the
|
||||
"all" flag (`--all` or `-a`) to view stopped containers.
|
||||
|
||||
```shell
|
||||
$ docker container ls
|
||||
$ docker container stop webserver
|
||||
$ docker container ls -a
|
||||
$ docker container rm webserver
|
||||
$ docker image ls
|
||||
$ docker image rm nginx
|
||||
```
|
||||
|
||||
## Docker Desktop user interface
|
||||
|
||||
The Docker Desktop Enterprise user interface provides options to configure Docker Desktop preferences such as installation, version packs, Docker Hub login, and more. Right-click the Docker icon from the menu bar to open the Docker Desktop user interface.
|
||||
|
||||
### Version Selection
|
||||
|
||||
The **Version Selection** option lists the version packs installed on your Docker Desktop environment and allows you to switch between Docker Engine and Kubernetes versions using a single click. When you select a different version pack, Docker Desktop restarts and the selected versions of Docker Engine and Kubernetes will be used.
|
||||
|
||||
To switch to a different version pack, simply click on the version pack you would like to use.
|
||||
|
||||
### Preferences
|
||||
|
||||
Click on the Docker icon from the menu bar and then **Preferences** to configure the runtime options described below.
|
||||
|
||||
> **Note:** Administrators have the ability to lock some configuration options. Locked options cannot be selected, and are displayed with a lock icon.
|
||||
|
||||
|
||||
|
||||
#### General
|
||||
|
||||
|
||||
|
||||
General settings include:
|
||||
|
||||
- **Start Docker Desktop when you log in:** Starts Docker Desktop when you open your session. (Enabled by default)
|
||||
|
||||
- **Include VM in Time Machine backups:** Backs up the Docker Desktop Enterprise virtual machine. (Disabled by default)
|
||||
|
||||
**Securely store Docker logins in macOS keychain:** Stores your Docker login
|
||||
credentials. (Enabled by default)
|
||||
|
||||
- **Send usage statistics:** Sends diagnostics, crash reports, and usage
|
||||
data to Docker. This information helps Docker improve the application and get
|
||||
more context for troubleshooting problems. (Enabled by default)
|
||||
|
||||
#### File Sharing
|
||||
|
||||
Choose which local directories to share with your containers. File sharing is
|
||||
required for volume mounting if the project lives outside of the `/Users`
|
||||
directory. In that case, share the drive where the Dockerfile and volume are
|
||||
located. Otherwise, you get `file not found` or `cannot start service` errors at
|
||||
runtime.
|
||||
|
||||
|
||||
|
||||
File sharing settings include the following options:
|
||||
|
||||
- **Add a Directory**: Click `+` and navigate to the directory you want to add.
|
||||
|
||||
- **Apply & Restart** makes the directory available to containers using Docker's
|
||||
bind mount (`-v`) feature.
|
||||
|
||||
There are some limitations on the directories that can be shared:
|
||||
|
||||
- They cannot be a subdirectory of a directory that has been shared already.
|
||||
- They cannot already exist inside of Docker.
|
||||
|
||||
For more information, see:
|
||||
|
||||
- [Namespaces](https://docs.docker.com/docker-for-mac/osxfs/#namespaces) in [osxfs file system sharing](https://docs.docker.com/docker-for-mac/osxfs/).
|
||||
|
||||
- [Volume mounting requires file sharing for any project directories outside of `/Users`](https://docs.docker.com/docker-for-mac/troubleshoot/#volume-mounting-requires-file-sharing-for-any-project-directories-outside-of-users).
|
||||
|
||||
#### Disk
|
||||
|
||||
Specify the **Disk image location** of the Linux volume, where containers and
|
||||
images are stored.
|
||||
|
||||
You can also move the disk image location. If you attempt to move the disk image
|
||||
to a location that already has one, you get a prompt asking if you want to use
|
||||
the existing image or replace it.
|
||||
|
||||
|
||||
|
||||
#### Advanced
|
||||
|
||||
On the Advanced tab, you can limit resources available to Docker.
|
||||
|
||||
|
||||
|
||||
Advanced settings include the following options:
|
||||
|
||||
- **CPUs**: By default, Docker Desktop Enterprise is set to use half the number of processors
|
||||
available on the host machine. To increase processing power, set this to a
|
||||
higher number; to decrease, lower the number.
|
||||
|
||||
- **Memory**: By default, Docker Desktop Enterprise is set to use 2 GB runtime memory,
|
||||
allocated from the total available memory on your Mac. To increase RAM, set this
|
||||
to a higher number; to decrease it, lower the number.
|
||||
|
||||
- **Swap**: Configure swap file size as needed. The default is 1 GB.
|
||||
|
||||
#### Proxies
|
||||
|
||||
Docker Desktop Enterprise detects HTTP/HTTPS Proxy Settings from macOS and automatically
|
||||
propagates these to Docker and to your containers. For example, if you set your
|
||||
proxy settings to `http://proxy.example.com`, Docker uses this proxy when
|
||||
pulling containers.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
When you start a container, your proxy settings propagate into the containers.
|
||||
For example:
|
||||
|
||||
```
|
||||
$ docker run -it alpine env
|
||||
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
|
||||
HOSTNAME=b7edf988b2b5
|
||||
TERM=xterm
|
||||
HOME=/root
|
||||
HTTP_PROXY=http://proxy.example.com:3128
|
||||
http_proxy=http://proxy.example.com:3128
|
||||
no_proxy=*.local, 169.254/16
|
||||
```
|
||||
|
||||
You can see from the above output that the `HTTP_PROXY`, `http_proxy`, and
|
||||
`no_proxy` environment variables are set. When your proxy configuration changes,
|
||||
Docker restarts automatically to pick up the new settings. If you have
|
||||
containers that you wish to keep running across restarts, you should consider
|
||||
using [restart policies](https://docs.docker.com/engine/reference/run/#restart-policies---restart).
|
||||
|
||||
#### Daemon
|
||||
|
||||
You can configure options on the Docker daemon that determine how your
|
||||
containers run.
|
||||
|
||||
Select **Basic** to configure the daemon with interactive settings, or select
|
||||
**Advanced** to edit the JSON directly.
|
||||
|
||||
|
||||
|
||||
##### Experimental features
|
||||
|
||||
Docker Desktop Enterprise has experimental features enabled
|
||||
on Docker Engine, as described in [Docker Experimental Features](https://github.com/docker/cli/blob/master/experimental/README.md) Readme. If you don't select **Experimental Features**, Docker Desktop Enterprise uses the current generally available release of Docker Engine.
|
||||
|
||||
> **Note:** Do not enable experimental features in production. Experimental features are not appropriate for production environments or workloads. They are meant to be sandbox experiments for new ideas.
|
||||
|
||||
You can see whether you are running experimental mode at the command line. If
|
||||
`Experimental` is `true`, then Docker is running in experimental mode, as shown
|
||||
here. (If `false`, Experimental mode is off.)
|
||||
|
||||
```bash
|
||||
{% raw %}$ docker version -f {{.Server.Experimental}}{% endraw %}
|
||||
true
|
||||
```
|
||||
|
||||
##### Insecure registries
|
||||
|
||||
You can set up a custom and insecure [registry](https://docs.docker.com/registry/introduction) to store your public or private images (instead of
|
||||
using [Docker Hub](https://hub.docker.com/) or [Docker Trusted Registry](https://docs.docker.com/ee/dtr/). Add URLs for
|
||||
your insecure registries and registry mirrors on which to host your images.
|
||||
|
||||
For more information, see:
|
||||
|
||||
- [How do I add custom CA certificates?](https://docs.docker.com/docker-for-mac/faqs/#how-do-i-add-custom-ca-certificates)
|
||||
|
||||
- [How do I add client certificates?](https://docs.docker.com/docker-for-mac/faqs/#how-do-i-add-client-certificates)
|
||||
|
||||
##### Daemon configuration file
|
||||
|
||||
Click the **Advanced** tab to configure the daemon from the JSON file. For a
|
||||
full list of options, see the Docker Engine [dockerd command line reference](https://docs.docker.com/engine/reference/commandline/dockerd).
|
||||
|
||||
Click **Apply & Restart** to save your settings and reboot Docker. Or, to cancel
|
||||
changes, click another preference tab, then choose to discard or not apply
|
||||
changes when asked.
|
||||
|
||||
|
||||
|
||||
#### Kubernetes
|
||||
|
||||
Docker Desktop Enterprise includes a standalone Kubernetes server that runs on your Mac, so
|
||||
that you can test deploying your Docker workloads on Kubernetes.
|
||||
|
||||
The Kubernetes client command, `kubectl`, is included and configured to connect
|
||||
to the local Kubernetes server. If you have `kubectl` already installed and
|
||||
pointing to some other environment, such as `minikube` or a GKE cluster, be sure
|
||||
to change context so that `kubectl` is pointing to `docker-for-desktop`:
|
||||
|
||||
```bash
|
||||
$ kubectl config get-contexts
|
||||
$ kubectl config use-context docker-for-desktop
|
||||
```
|
||||
|
||||
If you installed `kubectl` with Homebrew, or by some other method, and
|
||||
experience conflicts, remove `/usr/local/bin/kubectl`.
|
||||
|
||||
To enable Kubernetes support and install a standalone instance of Kubernetes running as a Docker container, select **Enable Kubernetes**, choose the [default orchestrator](https://docs.docker.com/docker-for-mac/kubernetes/#override-the-default-orchestrator) and click the **Apply** button.
|
||||
|
||||
|
||||
|
||||
Images required to run the Kubernetes server are downloaded and instantiated as containers, and the `/usr/local/bin/kubectl` command is installed on your Mac.
|
||||
|
||||
When Kubernetes is enabled and running, an additional status bar item displays at the bottom right of the Docker Desktop Enterprise **Preferences** dialog.
|
||||
|
||||
|
||||
|
||||
The status of Kubernetes shows in the Docker menu and the context points to `docker-desktop`.
|
||||
|
||||
|
||||
|
||||
By default, Kubernetes containers are hidden from commands like `docker
|
||||
service ls`, because managing them manually is not supported. To view these containers, select **Show system containers (advanced)** and click **Apply and restart**. Most users do not have to use this option.
|
||||
|
||||
To disable Kubernetes support at any time, clear the **Enable Kubernetes** check box. The
|
||||
Kubernetes containers are stopped and removed, and the
|
||||
`/usr/local/bin/kubectl` command is removed.
|
||||
|
||||
For more information about using the Kubernetes integration with Docker Desktop Enterprise, see [Deploy on Kubernetes](https://docs.docker.com/docker-for-mac/kubernetes).
|
||||
|
||||
#### Reset
|
||||
|
||||
Click on the Docker icon from the menu bar and then **Preferences**. Click **Reset** to reset to factory defaults, restart the Docker daemon, reset Kubernetes cluster, or to reset the disk image.
|
||||
|
||||
|
||||
|
||||
### Diagnose and Feedback
|
||||
|
||||
The **Diagnose and Feedback** option allows you troubleshoot any issues you may be experiencing with Docker Desktop Enterprise. For more information, see [Troubleshoot DDE issues on Mac](/ee/desktop/troubleshoot/mac-issues).
|
||||
|
||||
### Design new application
|
||||
|
||||
Select this option to open the Application Designer user interface. Application Designer provides a library of application and service templates to help Docker developers quickly create new Docker applications. For more information, see [Application Designer](/ee/desktop/app-designer).
|
||||
|
||||
### Docker Hub
|
||||
|
||||
Select **Sign in /Create Docker ID** from the Docker Desktop Enterprise menu to access your [Docker Hub](https://hub.docker.com/) account. Once logged in, select **Repositories** on the Docker Desktop Enterprise menu to access your Docker Hub repositories directly.
|
||||
|
||||
See the following [Docker Hub topics](https://docs.docker.com/docker-hub/) to learn more:
|
||||
|
||||
- [Organizations and Teams in Docker Hub](https://docs.docker.com/docker-hub/orgs/)
|
||||
|
||||
- [Builds and Images](https://docs.docker.com/docker-hub/official_images/)
|
||||
|
||||
### Add TLS certificates
|
||||
|
||||
You can add trusted Certificate Authorities (CAs) (used to verify registry
|
||||
server certificates) and client certificates (used to authenticate to
|
||||
registries) to your Docker daemon.
|
||||
|
||||
#### Add custom CA certificates (server side)
|
||||
|
||||
All trusted CAs (root or intermediate) are supported. Docker Desktop Enterprise creates a
|
||||
certificate bundle of all user-trusted CAs based on the Mac Keychain, and
|
||||
appends it to Moby trusted certificates. So if an enterprise SSL certificate is
|
||||
trusted by the user on the host, it is trusted by Docker Desktop Enterprise.
|
||||
|
||||
To manually add a custom, self-signed certificate, start by adding the
|
||||
certificate to the macOS keychain, which is picked up by Docker Desktop Enterprise. Here is
|
||||
an example.
|
||||
|
||||
```bash
|
||||
$ sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ca.crt
|
||||
```
|
||||
|
||||
Or, if you prefer to add the certificate to your own local keychain only (rather
|
||||
than for all users), run this command instead:
|
||||
|
||||
```
|
||||
$ security add-trusted-cert -d -r trustRoot -k ~/Library/Keychains/login.keychain ca.crt
|
||||
```
|
||||
|
||||
See also, [Directory structures for
|
||||
certificates](#directory-structures-for-certificates).
|
||||
|
||||
> **Note:** You need to restart Docker Desktop Enterprise after making any changes to the
|
||||
keychain or to the `~/.docker/certs.d` directory in order for the changes to
|
||||
take effect.
|
||||
|
||||
For a complete explanation of how to do this, see the blog post [Adding
|
||||
Self-signed Registry Certs to Docker & Docker Desktop Enterprise](http://container-solutions.com/adding-self-signed-registry-certs-docker-mac/).
|
||||
|
||||
#### Add client certificates
|
||||
|
||||
You can put your client certificates in
|
||||
`~/.docker/certs.d/<MyRegistry>:<Port>/client.cert` and
|
||||
`~/.docker/certs.d/<MyRegistry>:<Port>/client.key`.
|
||||
|
||||
When the Docker Desktop Enterprise application starts up, it copies the `~/.docker/certs.d`
|
||||
folder on your Mac to the `/etc/docker/certs.d` directory on Moby (the Docker
|
||||
Desktop Enterprise `xhyve` virtual machine).
|
||||
|
||||
> * You need to restart Docker Desktop Enterprise after making any changes to the keychain
|
||||
> or to the `~/.docker/certs.d` directory in order for the changes to take
|
||||
> effect.
|
||||
>
|
||||
> * The registry cannot be listed as an _insecure registry_ (see [Docker Daemon](#daemon)). Docker Desktop Enterprise ignores certificates listed
|
||||
> under insecure registries, and does not send client certificates. Commands
|
||||
> like `docker run` that attempt to pull from the registry produce error
|
||||
> messages on the command line, as well as on the registry.
|
||||
|
||||
#### Directory structures for certificates
|
||||
|
||||
If you have this directory structure, you do not need to manually add the CA
|
||||
certificate to your macOS system login:
|
||||
|
||||
```
|
||||
/Users/<user>/.docker/certs.d/
|
||||
└── <MyRegistry>:<Port>
|
||||
├── ca.crt
|
||||
├── client.cert
|
||||
└── client.key
|
||||
```
|
||||
|
||||
The following further illustrates and explains a configuration with custom
|
||||
certificates:
|
||||
|
||||
```
|
||||
/etc/docker/certs.d/ <-- Certificate directory
|
||||
└── localhost:5000 <-- Hostname:port
|
||||
├── client.cert <-- Client certificate
|
||||
├── client.key <-- Client key
|
||||
└── ca.crt <-- Certificate authority that signed
|
||||
the registry certificate
|
||||
```
|
||||
|
||||
You can also have this directory structure, as long as the CA certificate is
|
||||
also in your keychain.
|
||||
|
||||
```
|
||||
/Users/<user>/.docker/certs.d/
|
||||
└── <MyRegistry>:<Port>
|
||||
├── client.cert
|
||||
└── client.key
|
||||
```
|
||||
|
||||
To learn more about how to install a CA root certificate for the registry and
|
||||
how to set the client TLS certificate for verification, see [Verify repository client with certificates](https://docs.docker.com/engine/security/certificates) in the Docker Engine
|
||||
topics.
|
||||
|
||||
### Install shell completion
|
||||
|
||||
Docker Desktop Enterprise comes with scripts to enable completion for `docker` and `docker-compose` commands. The completion scripts may be
|
||||
found inside `Docker.app`, in the `Contents/Resources/etc/` directory and can be
|
||||
installed both in Bash and Zsh.
|
||||
|
||||
#### Bash
|
||||
|
||||
Bash has [built-in support for completion](https://www.debian-administration.org/article/316/An_introduction_to_bash_completion_part_1). To activate completion for Docker commands, these files need to be
|
||||
copied or symlinked to your `bash_completion.d/` directory. For example, if you have
|
||||
installed bash through [Homebrew](http://brew.sh/).
|
||||
|
||||
```bash
|
||||
etc=/Applications/Docker.app/Contents/Resources/etc
|
||||
ln -s $etc/docker.bash-completion $(brew --prefix)/etc/bash_completion.d/docker
|
||||
ln -s $etc/docker-compose.bash-completion $(brew --prefix)/etc/bash_completion.d/docker-compose
|
||||
```
|
||||
|
||||
#### Zsh
|
||||
|
||||
In Zsh, the [completion
|
||||
system](http://zsh.sourceforge.net/Doc/Release/Completion-System.html) takes care of things. To activate completion for Docker commands,
|
||||
these files need to be copied or symlinked to your Zsh `site-functions/`
|
||||
directory. For example, if you installed Zsh through [Homebrew](http://brew.sh/):
|
||||
|
||||
```bash
|
||||
etc=/Applications/Docker.app/Contents/Resources/etc
|
||||
ln -s $etc/docker.zsh-completion /usr/local/share/zsh/site-functions/_docker
|
||||
ln -s $etc/docker-compose.zsh-completion /usr/local/share/zsh/site-functions/_docker-compose
|
||||
```
|
||||
|
|
@ -1,496 +0,0 @@
|
|||
---
|
||||
title: Use Docker Desktop Enterprise on Windows
|
||||
description: Exploring the Windows user interface
|
||||
keywords: Desktop Enterprise, Docker for Windows, Docker Desktop, Enterprise, User guide, user
|
||||
---
|
||||
|
||||
This page contains information about testing the installation and configuring Docker Desktop Enterprise (DDE) runtime options on Windows.
|
||||
|
||||
## Test your installation
|
||||
|
||||
1. Open a terminal window (Command Prompt or PowerShell, _but not_ PowerShell ISE).
|
||||
|
||||
2. Run `docker --version` to ensure that you have a supported version of Docker:
|
||||
|
||||
3. Pull the [hello-world image](https://hub.docker.com/r/library/hello-world) from Docker Hub and run a container:
|
||||
|
||||
```shell
|
||||
> docker run hello-world
|
||||
|
||||
docker : Unable to find image 'hello-world:latest' locally
|
||||
...
|
||||
|
||||
latest:
|
||||
Pulling from library/hello-world
|
||||
ca4f61b1923c:
|
||||
Pulling fs layer
|
||||
ca4f61b1923c:
|
||||
Download complete
|
||||
ca4f61b1923c:
|
||||
Pull complete
|
||||
Digest: sha256:97ce6fa4b6cdc0790cda65fe7290b74cfebd9fa0c9b8c38e979330d547d22ce1
|
||||
Status: Downloaded newer image for hello-world:latest
|
||||
|
||||
Hello from Docker!
|
||||
This message shows that your installation appears to be working correctly.
|
||||
...
|
||||
```
|
||||
|
||||
4. List the `hello-world` _image_ that was downloaded from Docker Hub:
|
||||
|
||||
```shell
|
||||
> docker image ls
|
||||
```
|
||||
|
||||
5. List the `hello-world` _container_ (that exited after displaying "Hello from Docker!"):
|
||||
|
||||
```shell
|
||||
> docker container ls --all
|
||||
```
|
||||
|
||||
6. Explore the Docker help pages by running some help commands:
|
||||
|
||||
```shell
|
||||
> docker --help
|
||||
> docker container --help
|
||||
> docker container ls --help
|
||||
> docker run --help
|
||||
```
|
||||
|
||||
## Explore the application
|
||||
|
||||
In this section, we demonstrate the ease and power of Dockerized applications by
|
||||
running something more complex, such as an OS and a webserver.
|
||||
|
||||
1. Pull an image of the [Ubuntu OS](https://hub.docker.com/r/_/ubuntu/) and run an interactive terminal inside the spawned container:
|
||||
|
||||
```shell
|
||||
> docker run --interactive --tty ubuntu bash
|
||||
|
||||
docker : Unable to find image 'ubuntu:latest' locally
|
||||
...
|
||||
|
||||
latest:
|
||||
Pulling from library/ubuntu
|
||||
22dc81ace0ea:
|
||||
Pulling fs layer
|
||||
1a8b3c87dba3:
|
||||
Pulling fs layer
|
||||
91390a1c435a:
|
||||
Pulling fs layer
|
||||
...
|
||||
Digest: sha256:e348fbbea0e0a0e73ab0370de151e7800684445c509d46195aef73e090a49bd6
|
||||
Status: Downloaded newer image for ubuntu:latest
|
||||
```
|
||||
|
||||
> Do not use PowerShell ISE
|
||||
>
|
||||
> Interactive terminals do not work in PowerShell ISE (but they do in PowerShell). See [docker/for-win/issues/223](https://github.com/docker/for-win/issues/223).
|
||||
|
||||
2. You are in the container. At the root `#` prompt, check the `hostname` of the container:
|
||||
|
||||
```shell
|
||||
root@8aea0acb7423:/# hostname
|
||||
8aea0acb7423
|
||||
```
|
||||
|
||||
Notice that the hostname is assigned as the container ID (and is also used in the prompt).
|
||||
|
||||
3. Exit the shell with the `exit` command (which also stops the container):
|
||||
|
||||
```shell
|
||||
root@8aea0acb7423:/# exit
|
||||
>
|
||||
```
|
||||
|
||||
4. List containers with the `--all` option (because no containers are running).
|
||||
|
||||
The `hello-world` container (randomly named, `relaxed_sammet`) stopped after displaying its message. The `ubuntu` container (randomly named, `laughing_kowalevski`) stopped when you exited the container.
|
||||
|
||||
```shell
|
||||
> docker container ls --all
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
8aea0acb7423 ubuntu "bash" 2 minutes ago Exited (0) 2 minutes ago laughing_kowalevski
|
||||
45f77eb48e78 hello-world "/hello" 3 minutes ago Exited (0) 3 minutes ago relaxed_sammet
|
||||
```
|
||||
|
||||
5. Pull and run a Dockerized [nginx](https://hub.docker.com/_/nginx/) web server that we name, `webserver`:
|
||||
|
||||
```shell
|
||||
> docker run --detach --publish 80:80 --name webserver nginx
|
||||
|
||||
Unable to find image 'nginx:latest' locally
|
||||
latest: Pulling from library/nginx
|
||||
|
||||
fdd5d7827f33: Pull complete
|
||||
a3ed95caeb02: Pull complete
|
||||
716f7a5f3082: Pull complete
|
||||
7b10f03a0309: Pull complete
|
||||
Digest: sha256:f6a001272d5d324c4c9f3f183e1b69e9e0ff12debeb7a092730d638c33e0de3e
|
||||
Status: Downloaded newer image for nginx:latest
|
||||
dfe13c68b3b86f01951af617df02be4897184cbf7a8b4d5caf1c3c5bd3fc267f
|
||||
```
|
||||
|
||||
6. Point your web browser at `http://localhost` to display the nginx start page. (You don't need to append `:80` because you specified the default HTTP port in the `docker` command.)
|
||||
|
||||
|
||||
|
||||
7. List only your _running_ containers:
|
||||
|
||||
```shell
|
||||
> docker container ls
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
0e788d8e4dfd nginx "nginx -g 'daemon of…" 2 minutes ago Up 2 minutes 0.0.0.0:80->80/tcp webserver
|
||||
```
|
||||
|
||||
8. Stop the running nginx container by the name we assigned it, `webserver`:
|
||||
|
||||
```shell
|
||||
> docker container stop webserver
|
||||
```
|
||||
|
||||
9. Remove all three containers by their names -- the latter two names will differ for you:
|
||||
|
||||
```shell
|
||||
> docker container rm webserver laughing_kowalevski relaxed_sammet
|
||||
```
|
||||
|
||||
## Docker Desktop user interface
|
||||
|
||||
The Docker Desktop Enterprise user interface provides options to configure Docker Desktop settings such as installation, version packs, Docker Hub login, and more. Right-click the Docker icon in the Notifications area (or System tray) to open the Docker Desktop user interface:
|
||||
|
||||
|
||||
|
||||
> **Note:** Administrators have the ability to lock some configuration options. Locked options cannot be selected, and are displayed with a lock icon.
|
||||
|
||||
### Settings
|
||||
|
||||
The **Settings** dialog allows you to configure your Docker Desktop Enterprise settings. The following section explains various configuration options available from the **Settings** dialog.
|
||||
|
||||
> **Note:** Administrators have the ability to lock some configuration options. Locked options cannot be selected, and are displayed with a lock icon.
|
||||
|
||||
Select **Settings** to open the Settings dialog:
|
||||
|
||||
|
||||
|
||||
#### General
|
||||
|
||||
On the **General** tab of the Settings dialog, you can configure when to start Docker Desktop.
|
||||
|
||||
|
||||
|
||||
- **Start Docker Desktop when you log in** - Automatically start the Docker Desktop application upon Windows system login.
|
||||
|
||||
- **Send usage statistics** - By default, Docker Desktop sends diagnostics,
|
||||
crash reports, and usage data. This information helps Docker improve and troubleshoot the application. Clear the check box to opt out. Docker might prompt you for more information.
|
||||
|
||||
- **Expose daemon on tcp://localhost:2375 without TLS** - Click this option to enable legacy clients to connect to the Docker daemon. You must use this option with caution as exposing the daemon without TLS can result in remote code execution attacks.
|
||||
|
||||
#### Shared drives
|
||||
|
||||
Share your local drives (volumes) with Docker Desktop, so that they are
|
||||
available to your [Linux containers](#switch-between-windows-and-linux-containers).
|
||||
|
||||
|
||||
|
||||
Permission for shared drives are tied to the credentials you provide here. If you run `docker` commands under a different username than the one configured here, your containers cannot access the mounted volumes.
|
||||
|
||||
To apply shared drives, you are prompted for your Windows system (domain) username and password. You can select an option to have Docker store the credentials so that you don't need to enter them every time.
|
||||
|
||||
Tips on shared drives, permissions, and volume mounts:
|
||||
|
||||
- Shared drives are only required for mounting volumes in [Linux containers](#switch-between-windows-and-linux-containers), not for Windows containers. For Linux containers, you need to share the drive where the Dockerfile and volume are located. If you get errors such as `file not found` or `cannot start service` you may need to enable shared drives. See [Volume mounting requires shared drives for Linux containers](/docker-for-windows/troubleshoot#volume-mounting-requires-shared-drives-for-linux-containers).
|
||||
|
||||
- If possible, avoid volume mounts from the Windows host, and instead mount on
|
||||
the Linux VM, or use a [data volume](https://docs.docker.com/storage/volumes/) (named volume) or [data container](https://docs.docker.com/storage/volumes/). There are a number of issues with using host-mounted volumes and network paths
|
||||
for database files. See [Volume mounts from host paths use a nobrl option to override database locking](https://docs.docker.com/docker-for-windows/troubleshoot/#volume-mounts-from-host-paths-use-a-nobrl-option-to-override-database-locking).
|
||||
|
||||
- Docker Desktop sets permissions to read/write/execute for users, groups and others [0777 or a+rwx](http://permissions-calculator.org/decode/0777/).
|
||||
This is not configurable. See [Permissions errors on data directories for shared volumes](https://docs.docker.com/docker-for-windows/troubleshoot/#permissions-errors-on-data-directories-for-shared-volumes).
|
||||
|
||||
- Ensure the domain user has access to shared drives, as described in [Verify domain user has permissions for shared drives](https://docs.docker.com/docker-for-windows/troubleshoot/#verify-domain-user-has-permissions-for-shared-drives-volumes).
|
||||
|
||||
##### Firewall rules for shared drives
|
||||
|
||||
Shared drives require port 445 to be open between the host machine and the
|
||||
virtual machine that runs Linux containers. Docker detects if port 445 is closed
|
||||
and shows the following message when you try to add a shared drive:
|
||||
|
||||
|
||||
|
||||
To share the drive, allow connections between the Windows host machine and the
|
||||
virtual machine in Windows Firewall or your third party firewall software. You
|
||||
do not need to open port 445 on any other network.
|
||||
|
||||
By default, allow connections to `10.0.75.1` on port 445 (the Windows host) from
|
||||
`10.0.75.2` (the virtual machine). If your firewall rules seem correct, you may
|
||||
need to toggle or [reinstall the File and Print sharing service on the Hyper-V virtual network card](http://stackoverflow.com/questions/42203488/settings-to-windows-firewall-to-allow-docker-for-windows-to-share-drive/43904051#43904051).
|
||||
|
||||
##### Shared drives on demand
|
||||
|
||||
You can share a drive "on demand" the first time a particular mount is requested.
|
||||
|
||||
If you run a Docker command from a shell with a volume mount (as shown in the
|
||||
example below) or kick off a Compose file that includes volume mounts, you get a
|
||||
popup asking if you want to share the specified drive.
|
||||
|
||||
You can select to **Share it**, in which case it is added your Docker Desktop Enterprise [Shared Drives List](#shared-drives) and available to
|
||||
containers. Alternatively, you can opt not to share it by selecting **Cancel**.
|
||||
|
||||
|
||||
|
||||
#### Advanced
|
||||
|
||||
The Linux VM restarts after changing the settings on the **Advanced** tab. This takes a few seconds.
|
||||
|
||||
|
||||
|
||||
- **CPUs** - Change the number of processors assigned to the Linux VM.
|
||||
|
||||
- **Memory** - Change the amount of memory the Docker Desktop Enterprise Linux VM uses.
|
||||
|
||||
#### Network
|
||||
|
||||
You can configure Docker Desktop Enterprise networking to work on a virtual private network (VPN).
|
||||
|
||||
|
||||
|
||||
> **Note:** Administrators have the ability to lock some configuration options. Locked options cannot be selected, and are displayed with a lock icon.
|
||||
|
||||
- **Internal Virtual Switch** - You can specify a network address translation (NAT) prefix and subnet mask to enable Internet connectivity.
|
||||
|
||||
- **DNS Server** - You can configure the DNS server to use dynamic or static IP addressing.
|
||||
|
||||
> **Note**: Some users reported problems connecting to Docker Hub on Docker Desktop Enterprise. This would manifest as an error when trying to run
|
||||
> `docker` commands that pull images from Docker Hub that are not already
|
||||
> downloaded, such as a first time run of `docker run hello-world`. If you
|
||||
> encounter this, reset the DNS server to use the Google DNS fixed address:
|
||||
> `8.8.8.8`. For more information, see [Networking issues](https://docs.docker.com/docker-for-windows/troubleshoot/#networking-issues) in Troubleshooting.
|
||||
|
||||
Updating these settings requires a reconfiguration and reboot of the Linux VM.
|
||||
|
||||
#### Proxies
|
||||
|
||||
Docker Desktop Enterprise lets you configure HTTP/HTTPS Proxy Settings and
|
||||
automatically propagates these to Docker and to your containers. For example,
|
||||
if you set your proxy settings to `http://proxy.example.com`, Docker uses this
|
||||
proxy when pulling containers.
|
||||
|
||||
|
||||
|
||||
When you start a container, your proxy settings propagate into the containers. For example:
|
||||
|
||||
```ps
|
||||
> docker run alpine env
|
||||
|
||||
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
|
||||
HOSTNAME=b7edf988b2b5
|
||||
TERM=xterm
|
||||
HOME=/root
|
||||
HTTP_PROXY=http://proxy.example.com:3128
|
||||
http_proxy=http://proxy.example.com:3128
|
||||
no_proxy=*.local, 169.254/16
|
||||
```
|
||||
|
||||
In the output above, the `HTTP_PROXY`, `http_proxy`, and `no_proxy` environment
|
||||
variables are set. When your proxy configuration changes, Docker restarts
|
||||
automatically to pick up the new settings. If you have containers that you wish
|
||||
to keep running across restarts, you should consider using
|
||||
[restart policies](https://docs.docker.com/engine/reference/run/#restart-policies---restart).
|
||||
|
||||
#### Daemon
|
||||
|
||||
Docker Desktop Enterprise enables you to configure the Docker daemon based on your preferences.
|
||||
The **Basic** mode lets you configure the more common daemon options with interactive settings and the **Advanced** mode lets you edit the JSON file directly.
|
||||
|
||||
|
||||
|
||||
> **Note:** Administrators have the ability to lock some configuration options. Locked options cannot be selected, and are displayed with a lock icon.
|
||||
|
||||
##### Experimental mode
|
||||
|
||||
Docker Desktop Enterprise has the experimental version
|
||||
of Docker Engine enabled, described in the [Docker Experimental Features](https://github.com/docker/cli/blob/master/experimental/README.md) readme. If you don't select **Experimental Features**, Docker Desktop Enterprise uses the current generally available release of Docker Engine.
|
||||
|
||||
> **Note:** Do not enable experimental features in production. Experimental features are not appropriate for production environments or
|
||||
workloads. They are meant to be sandbox experiments for new ideas.
|
||||
|
||||
Run `docker version` to see if you are in Experimental mode. Experimental mode
|
||||
is listed under `Server` data. If `Experimental` is `true`, then Docker is
|
||||
running in experimental mode, as shown here:
|
||||
|
||||
```shell
|
||||
> docker version
|
||||
|
||||
Client:
|
||||
Version: 18.03.0-ce
|
||||
API version: 1.37
|
||||
Go version: go1.9.4
|
||||
Git commit: 0520e24
|
||||
Built: Wed Mar 21 23:06:28 2018
|
||||
OS/Arch: windows/amd64
|
||||
Experimental: true
|
||||
Orchestrator: swarm
|
||||
|
||||
Server:
|
||||
Engine:
|
||||
Version: 18.03.0-ce
|
||||
API version: 1.37 (minimum version 1.24)
|
||||
Go version: go1.9.4
|
||||
Git commit: 0520e24
|
||||
Built: Wed Mar 21 23:21:06 2018
|
||||
OS/Arch: windows/amd64
|
||||
Experimental: true
|
||||
```
|
||||
|
||||
##### Insecure registries
|
||||
|
||||
You can set up your own [registries](https://docs.docker.com/registry/introduction) on the **Basic** Daemon settings.
|
||||
|
||||
Normally, you store public or private images in [Docker Hub](https://hub.docker.com/)
|
||||
and [Docker Trusted Registry](https://docs.docker.com/ee/dtr/). Here, you
|
||||
can use Docker to set up your own [insecure registry](https://docs.docker.com/registry/insecure/).
|
||||
Simply add URLs for insecure registries and registry mirrors on which to host your images.
|
||||
|
||||
For more information, see:
|
||||
|
||||
- [How do I add custom CA certificates?](https://docs.docker.com/docker-for-windows/faqs/#how-do-i-add-custom-ca-certificates)
|
||||
|
||||
- [How do I add client certificates?](https://docs.docker.com/docker-for-windows/faqs/#how-do-i-add-client-certificates)
|
||||
|
||||
#### Daemon configuration file
|
||||
|
||||
The **Advanced** daemon settings provide the original option to directly edit
|
||||
the JSON configuration file for the [daemon](https://docs.docker.com/engine/reference/commandline/dockerd).
|
||||
|
||||
> Updating these settings requires a reconfiguration and reboot of the Linux VM.
|
||||
|
||||
|
||||
|
||||
For a full list of options on the Docker daemon, see [daemon](https://docs.docker.com/engine/reference/commandline/dockerd), and also sub-topics:
|
||||
|
||||
- [Daemon configuration file](https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file)
|
||||
|
||||
- [Linux configuration file](https://docs.docker.com/engine/reference/commandline/dockerd/#linux-configuration-file)
|
||||
|
||||
- [Windows configuration file](https://docs.docker.com/engine/reference/commandline/dockerd/#windows-configuration-file)
|
||||
|
||||
#### Kubernetes
|
||||
|
||||
Kubernetes is available on Docker Desktop Enterprise. A standalone Kubernetes server is included that runs on your Windows host, so that you can test deploying your
|
||||
Docker workloads on Kubernetes.
|
||||
|
||||
|
||||
|
||||
The Kubernetes client command, `kubectl`, is included and configured to connect
|
||||
to the local Kubernetes server. If you have `kubectl` already installed and
|
||||
pointing to some other environment, such as `minikube` or a GKE cluster, be sure
|
||||
to change context so that `kubectl` is pointing to `docker-for-desktop`:
|
||||
|
||||
```bash
|
||||
> kubectl config get-contexts
|
||||
> kubectl config use-context docker-for-desktop
|
||||
```
|
||||
|
||||
You can also change it through the Docker Desktop Enterprise menu:
|
||||
|
||||
|
||||
|
||||
If you installed `kubectl` by another method, and
|
||||
experience conflicts, remove it.
|
||||
|
||||
- To enable Kubernetes support and install a standalone instance of Kubernetes
|
||||
running as a Docker container, select **Enable Kubernetes** and click the
|
||||
**Install** button.
|
||||
|
||||
Images required to run the Kubernetes server are instantiated as containers, and the `kubectl.exe` command is installed in the path.
|
||||
|
||||
- By default, Kubernetes containers are hidden from commands like `docker
|
||||
service ls`, because managing them manually is not supported. To make them
|
||||
visible, select **Show system containers (advanced)** and click **Apply and restart**.
|
||||
Most users do not have to use this option.
|
||||
|
||||
- To disable Kubernetes support at any time, deselect **Enable Kubernetes**.
|
||||
The Kubernetes containers are stopped and removed, and the
|
||||
`kubectl` command is removed.
|
||||
|
||||
For more about using the Kubernetes integration with Docker Desktop Enterprise,
|
||||
see [Deploy on Kubernetes](https://docs.docker.com/docker-for-windows/kubernetes).
|
||||
|
||||
#### Reset
|
||||
|
||||
On the Reset tab, you can restart Docker or reset its configuration.
|
||||
|
||||
|
||||
|
||||
- **Restart Docker Desktop** - Shuts down and restarts the Docker Desktop application.
|
||||
|
||||
- **Reset to factory defaults** - Resets Docker to factory defaults. This is
|
||||
useful in cases where Docker stops working or becomes unresponsive.
|
||||
|
||||
### Version Selection
|
||||
|
||||
The **Version Selection** option lists the version packs installed on your Docker Desktop environment and allows you to switch between Docker Engine and Kubernetes versions using a single click. When you select a different version pack, Docker Desktop restarts and the selected versions of Docker Engine and Kubernetes will be used.
|
||||
|
||||
To switch to a different version pack, simply click on the version pack you would like to use.
|
||||
|
||||
|
||||
|
||||
### Diagnose and Feedback
|
||||
|
||||
The **Diagnose and Feedback** option allows you troubleshoot any issues you may be experiencing with Docker Desktop Enterprise. For more information, see [Troubleshoot DDE issues on Windows](/ee/desktop/troubleshoot/windows-issues).
|
||||
|
||||
### Switch between Windows and Linux containers
|
||||
|
||||
From the Docker Desktop Enterprise menu, you can toggle which daemon (Linux or Windows) the Docker CLI talks to. Select **Switch to Windows containers** to use Windows containers, or select **Switch to Linux containers** to use Linux containers.
|
||||
|
||||
|
||||
|
||||
For more information on Windows containers, refer to the following documentation:
|
||||
|
||||
- Microsoft documentation on [Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/index).
|
||||
|
||||
- [Build and Run Your First Windows Server Container](https://blog.docker.com/2016/09/build-your-first-docker-windows-server-container/) (blog post) gives a quick tour of how to build and run native Docker Windows containers on Windows 10 and Windows Server 2016 evaluation releases.
|
||||
|
||||
- [Getting Started with Windows Containers (Lab)](https://github.com/docker/labs/blob/master/windows/windows-containers/README.md)
|
||||
shows you how to use the [MusicStore](https://github.com/aspnet/MusicStore/)
|
||||
application with Windows containers. The MusicStore is a standard .NET application and, [forked here to use containers](https://github.com/friism/MusicStore), is a good example of a multi-container application.
|
||||
|
||||
- To understand how to connect to Windows containers from the local host, see [Limitations of Windows containers for `localhost` and published ports](https://docs.docker.com/docker-for-windows/troubleshoot/#limitations-of-windows-containers-for-localhost-and-published-ports).
|
||||
|
||||
The **Settings** dialog changes with Windows containers. When you switch to Windows containers, the **Settings** dialog only shows those tabs that are active and apply to your Windows containers:
|
||||
|
||||
- [General](#general)
|
||||
|
||||
- [Proxies](#proxies)
|
||||
|
||||
- [Daemon](#daemon)
|
||||
|
||||
- [Diagnose and Feedback](#diagnose-and-feedback)
|
||||
|
||||
- [Reset](#reset)
|
||||
|
||||
If you set proxies or daemon configuration in Windows containers mode, these apply only on Windows containers. If you switch back to Linux containers, proxies and daemon configurations return to what you had set for Linux containers. Your Windows container settings are retained and become available again when you switch back.
|
||||
|
||||
### Docker Hub
|
||||
|
||||
Select **Sign in /Create Docker ID** from the Docker Desktop Enterprise menu to access your [Docker Hub](https://hub.docker.com/) account. Once logged in, select **Repositories** on the Docker Desktop Enterprise menu to access your Docker Hub repositories directly.
|
||||
|
||||
See the following [Docker Hub topics](https://docs.docker.com/docker-hub/) to learn more:
|
||||
|
||||
- [Organizations and Teams in Docker Hub](https://docs.docker.com/docker-hub/orgs/)
|
||||
|
||||
- [Builds and Images](https://docs.docker.com/docker-hub/official_images/)
|
||||
|
||||
### Design new application
|
||||
|
||||
Select this option to open the Application Designer user interface. Application Designer provides a library of application and service templates to help Docker developers quickly create new Docker applications. For more information, see [Application Designer](/ee/desktop/app-designer).
|
||||
|
||||
## Adding TLS certificates
|
||||
|
||||
You can add trusted **Certificate Authorities (CAs)** to your Docker daemon to verify registry server certificates, and **client certificates**, to authenticate to registries.
|
||||
|
||||
For more information, see [How do I add custom CA certificates?](https://docs.docker.com/docker-for-windows/faqs/#how-do-i-add-custom-ca-certificates) and
|
||||
and [How do I add client certificates?](https://docs.docker.com/docker-for-windows/faqs/#how-do-i-add-client-certificates) in the FAQs.
|
||||
|
|
@ -1,304 +0,0 @@
|
|||
---
|
||||
title: Custom templates
|
||||
description: Learn how to use a custom extension template
|
||||
keywords: routing, proxy
|
||||
---
|
||||
|
||||
# Using a custom extension template
|
||||
A custom extension template can be
|
||||
used if a needed option is not available in the extension configuration.
|
||||
|
||||
> Warning:
|
||||
This should be used with extreme caution as this completely bypasses the built-in
|
||||
extension template. Therefore, if you update the extension image in the future,
|
||||
you will not receive the updated template because you are using a custom one.
|
||||
|
||||
To use a custom template:
|
||||
|
||||
1. Create a Swarm configuration using a new template
|
||||
2. Create a Swarm configuration object
|
||||
3. Update the extension
|
||||
|
||||
## Creating a Swarm configuration using a new template
|
||||
First, create a Swarm config using the new template, as shown in the following example. This example uses a custom Nginx configuration template, but you can use any extension configuration (for example, HAProxy).
|
||||
|
||||
The contents of the example `custom-template.conf` include:
|
||||
|
||||
```
|
||||
# CUSTOM INTERLOCK CONFIG
|
||||
user {{ .ExtensionConfig.User }};
|
||||
worker_processes {{ .ExtensionConfig.WorkerProcesses }};
|
||||
|
||||
error_log {{ .ExtensionConfig.ErrorLogPath }} warn;
|
||||
pid {{ .ExtensionConfig.PidPath }};
|
||||
|
||||
|
||||
events {
|
||||
worker_connections {{ .ExtensionConfig.MaxConnections }};
|
||||
|
||||
}
|
||||
|
||||
http {
|
||||
include /etc/nginx/mime.types;
|
||||
default_type application/octet-stream;
|
||||
server_names_hash_bucket_size 128;
|
||||
|
||||
# add custom HTTP options here, etc.
|
||||
|
||||
log_format main {{ .ExtensionConfig.MainLogFormat }}
|
||||
|
||||
log_format trace {{ .ExtensionConfig.TraceLogFormat }}
|
||||
|
||||
access_log {{ .ExtensionConfig.AccessLogPath }} main;
|
||||
|
||||
sendfile on;
|
||||
#tcp_nopush on;
|
||||
|
||||
keepalive_timeout {{ .ExtensionConfig.KeepaliveTimeout }};
|
||||
client_max_body_size {{ .ExtensionConfig.ClientMaxBodySize }};
|
||||
client_body_buffer_size {{ .ExtensionConfig.ClientBodyBufferSize }};
|
||||
client_header_buffer_size {{ .ExtensionConfig.ClientHeaderBufferSize }};
|
||||
large_client_header_buffers {{ .ExtensionConfig.LargeClientHeaderBuffers }};
|
||||
client_body_timeout {{ .ExtensionConfig.ClientBodyTimeout }};
|
||||
underscores_in_headers {{ if .ExtensionConfig.UnderscoresInHeaders }}on{{ else }}off{{ end }};
|
||||
|
||||
add_header x-request-id $request_id;
|
||||
add_header x-proxy-id $hostname;
|
||||
add_header x-server-info "{{ .Version }}";
|
||||
add_header x-upstream-addr $upstream_addr;
|
||||
add_header x-upstream-response-time $upstream_response_time;
|
||||
|
||||
proxy_connect_timeout {{ .ExtensionConfig.ConnectTimeout }};
|
||||
proxy_send_timeout {{ .ExtensionConfig.SendTimeout }};
|
||||
proxy_read_timeout {{ .ExtensionConfig.ReadTimeout }};
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header Host $http_host;
|
||||
proxy_set_header x-request-id $request_id;
|
||||
send_timeout {{ .ExtensionConfig.SendTimeout }};
|
||||
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
|
||||
|
||||
ssl_prefer_server_ciphers on;
|
||||
ssl_ciphers {{ .ExtensionConfig.SSLCiphers }};
|
||||
ssl_protocols {{ .ExtensionConfig.SSLProtocols }};
|
||||
{{ if (and (gt .ExtensionConfig.SSLDefaultDHParam 0) (ne .ExtensionConfig.SSLDefaultDHParamPath "")) }}ssl_dhparam {{ .ExtensionConfig.SSLDefaultDHParamPath }};{{ end }}
|
||||
|
||||
map $http_upgrade $connection_upgrade {
|
||||
default upgrade;
|
||||
'' close;
|
||||
}
|
||||
|
||||
{{ if not .HasDefaultBackend }}
|
||||
# default host return 503
|
||||
server {
|
||||
listen {{ .Port }} default_server;
|
||||
server_name _;
|
||||
|
||||
root /usr/share/nginx/html;
|
||||
|
||||
error_page 503 /503.html;
|
||||
location = /503.html {
|
||||
try_files /503.html @error;
|
||||
internal;
|
||||
}
|
||||
|
||||
location @error {
|
||||
root /usr/share/nginx/html;
|
||||
}
|
||||
|
||||
location / {
|
||||
return 503;
|
||||
|
||||
}
|
||||
|
||||
location /nginx_status {
|
||||
stub_status on;
|
||||
access_log off;
|
||||
}
|
||||
|
||||
}
|
||||
{{ end }}
|
||||
|
||||
{{ range $host, $backends := .Hosts }}
|
||||
{{ with $hostBackend := index $backends 0 }}
|
||||
{{ $sslBackend := index $.SSLBackends $host }}
|
||||
upstream {{ backendName $host }} {
|
||||
{{ if $hostBackend.IPHash }}ip_hash; {{else}}zone {{ backendName $host }}_backend 64k;{{ end }}
|
||||
{{ if ne $hostBackend.StickySessionCookie "" }}hash $cookie_{{ $hostBackend.StickySessionCookie }} consistent; {{ end }}
|
||||
{{ range $backend := $backends }}
|
||||
{{ range $up := $backend.Targets }}server {{ $up }};
|
||||
{{ end }}
|
||||
{{ end }} {{/* end range backends */}}
|
||||
|
||||
}
|
||||
{{ if not $sslBackend.Passthrough }}
|
||||
server {
|
||||
listen {{ $.Port }}{{ if $hostBackend.DefaultBackend }} default_server{{ end }};
|
||||
{{ if $hostBackend.DefaultBackend }}server_name _;{{ else }}server_name {{$host}};{{ end }}
|
||||
|
||||
{{ if (isRedirectHost $host $hostBackend.Redirects) }}
|
||||
{{ range $redirect := $hostBackend.Redirects }}
|
||||
{{ if isRedirectMatch $redirect.Source $host }}return 302 {{ $redirect.Target }}$request_uri;{{ end }}
|
||||
{{ end }}
|
||||
{{ else }}
|
||||
|
||||
{{ if eq ( len $hostBackend.ContextRoots ) 0 }}
|
||||
{{ if not (isWebsocketRoot $hostBackend.WebsocketEndpoints) }}
|
||||
location / {
|
||||
proxy_pass {{ if $hostBackend.SSLBackend }}https://{{ else }}http://{{ backendName $host }};{{ end }}
|
||||
}
|
||||
{{ end }}
|
||||
|
||||
{{ range $ws := $hostBackend.WebsocketEndpoints }}
|
||||
location {{ $ws }} {
|
||||
proxy_pass {{ if $hostBackend.SSLBackend }}https://{{ else }}http://{{ backendName $host }};{{ end }}
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection $connection_upgrade;
|
||||
proxy_set_header Origin '';
|
||||
}
|
||||
{{ end }} {{/* end range WebsocketEndpoints */}}
|
||||
{{ else }}
|
||||
|
||||
{{ range $ctxroot := $hostBackend.ContextRoots }}
|
||||
location {{ $ctxroot.Path }} {
|
||||
{{ if $ctxroot.Rewrite }}rewrite ^([^.]*[^/])$ $1/ permanent;
|
||||
rewrite ^{{ $ctxroot.Path }}/(.*) /$1 break;{{ end }}
|
||||
proxy_pass http://{{ backendName $host }};
|
||||
}
|
||||
{{ end }} {{/* end range contextroots */}}
|
||||
|
||||
{{ end }} {{/* end len $hostBackend.ContextRoots */}}
|
||||
location /nginx_status {
|
||||
stub_status on;
|
||||
access_log off;
|
||||
}
|
||||
{{ end }}{{/* end isRedirectHost */}}
|
||||
|
||||
}
|
||||
{{ end }} {{/* end if not sslBackend.Passthrough */}}
|
||||
|
||||
{{/* SSL */}}
|
||||
{{ if ne $hostBackend.SSLCert "" }}
|
||||
{{ $sslBackend := index $.SSLBackends $host }}
|
||||
server {
|
||||
listen 127.0.0.1:{{ $sslBackend.Port }} ssl proxy_protocol;
|
||||
server_name {{ $host }};
|
||||
ssl on;
|
||||
ssl_certificate /run/secrets/{{ $hostBackend.SSLCertTarget }};
|
||||
{{ if ne $hostBackend.SSLKey "" }}ssl_certificate_key /run/secrets/{{ $hostBackend.SSLKeyTarget }};{{ end }}
|
||||
set_real_ip_from 127.0.0.1/32;
|
||||
real_ip_header proxy_protocol;
|
||||
|
||||
{{ if eq ( len $hostBackend.ContextRoots ) 0 }}
|
||||
{{ if not (isWebsocketRoot $hostBackend.WebsocketEndpoints) }}
|
||||
location / {
|
||||
proxy_pass {{ if $hostBackend.SSLBackend }}https://{{ else }}http://{{ backendName $host }};{{ end }}
|
||||
}
|
||||
{{ end }}
|
||||
|
||||
{{ range $ws := $hostBackend.WebsocketEndpoints }}
|
||||
location {{ $ws }} {
|
||||
proxy_pass {{ if $hostBackend.SSLBackend }}https://{{ else }}http://{{ backendName $host }};{{ end }}
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection $connection_upgrade;
|
||||
proxy_set_header Origin {{$host}};
|
||||
|
||||
}
|
||||
{{ end }} {{/* end range WebsocketEndpoints */}}
|
||||
{{ else }}
|
||||
|
||||
{{ range $ctxroot := $hostBackend.ContextRoots }}
|
||||
location {{ $ctxroot.Path }} {
|
||||
{{ if $ctxroot.Rewrite }}rewrite ^([^.]*[^/])$ $1/ permanent;
|
||||
rewrite ^{{ $ctxroot.Path }}/(.*) /$1 break;{{ end }}
|
||||
proxy_pass http://{{ backendName $host }};
|
||||
}
|
||||
{{ end }} {{/* end range contextroots */}}
|
||||
|
||||
{{ end }} {{/* end len $hostBackend.ContextRoots */}}
|
||||
location /nginx_status {
|
||||
stub_status on;
|
||||
access_log off;
|
||||
}
|
||||
|
||||
} {{ end }} {{/* end $hostBackend.SSLCert */}}
|
||||
{{ end }} {{/* end with hostBackend */}}
|
||||
|
||||
{{ end }} {{/* end range .Hosts */}}
|
||||
|
||||
include /etc/nginx/conf.d/*.conf;
|
||||
}
|
||||
stream {
|
||||
# main log compatible format
|
||||
log_format stream '$remote_addr - - [$time_local] "$ssl_preread_server_name -> $name ($protocol)" '
|
||||
'$status $bytes_sent "" "" "" ';
|
||||
map $ssl_preread_server_name $name {
|
||||
{{ range $host, $sslBackend := $.SSLBackends }}
|
||||
{{ $sslBackend.Host }} {{ if $sslBackend.Passthrough }}pt-{{ backendName $host }};{{ else }}127.0.0.1:{{ $sslBackend.Port }}; {{ end }}
|
||||
{{ if $sslBackend.DefaultBackend }}default {{ if $sslBackend.Passthrough }}pt-{{ backendName $host }};{{ else }}127.0.0.1:{{ $sslBackend.Port }}; {{ end }}{{ end }}
|
||||
{{ end }}
|
||||
|
||||
}
|
||||
{{ range $host, $sslBackend := $.SSLBackends }}
|
||||
upstream pt-{{ backendName $sslBackend.Host }} {
|
||||
{{ $h := index $.Hosts $sslBackend.Host }}{{ $hostBackend := index $h 0 }}
|
||||
{{ if $sslBackend.Passthrough }}
|
||||
server 127.0.0.1:{{ $sslBackend.ProxyProtocolPort }};
|
||||
{{ else }}
|
||||
{{ range $up := $hostBackend.Targets }}server {{ $up }};
|
||||
{{ end }} {{/* end range backend targets */}}
|
||||
{{ end }} {{/* end range sslbackend */}}
|
||||
|
||||
}{{ end }} {{/* end range SSLBackends */}}
|
||||
|
||||
{{ range $host, $sslBackend := $.SSLBackends }}
|
||||
{{ $proxyProtocolPort := $sslBackend.ProxyProtocolPort }}
|
||||
{{ $h := index $.Hosts $sslBackend.Host }}{{ $hostBackend := index $h 0 }}
|
||||
{{ if ne $proxyProtocolPort 0 }}
|
||||
upstream proxy-{{ backendName $sslBackend.Host }} {
|
||||
{{ range $up := $hostBackend.Targets }}server {{ $up }};
|
||||
{{ end }} {{/* end range backend targets */}}
|
||||
|
||||
}
|
||||
server {
|
||||
listen {{ $proxyProtocolPort }} proxy_protocol;
|
||||
proxy_pass proxy-{{ backendName $sslBackend.Host }};
|
||||
|
||||
}
|
||||
{{ end }} {{/* end if ne proxyProtocolPort 0 */}}
|
||||
{{ end }} {{/* end range SSLBackends */}}
|
||||
|
||||
server {
|
||||
listen {{ $.SSLPort }};
|
||||
proxy_pass $name;
|
||||
proxy_protocol on;
|
||||
ssl_preread on;
|
||||
access_log {{ .ExtensionConfig.AccessLogPath }} stream;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Creating a Swarm configuration object
|
||||
To create a Swarm config object:
|
||||
|
||||
```
|
||||
$> docker config create interlock-custom-template custom.conf
|
||||
```
|
||||
|
||||
## Updating the extension
|
||||
Now update the extension to use this new template:
|
||||
|
||||
```
|
||||
$> docker service update --config-add source=interlock-custom-template,target=/etc/docker/extension-template.conf interlock-ext
|
||||
```
|
||||
|
||||
This should trigger an update and a new proxy configuration will be generated.
|
||||
|
||||
## Removing the custom template
|
||||
To remove the custom template and revert to using the built-in template:
|
||||
|
||||
```
|
||||
$> docker service update --config-rm interlock-custom-template interlock-ext
|
||||
```
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
---
|
||||
title: HAProxy configuration
|
||||
description: Learn how to configure an HAProxy extension
|
||||
keywords: routing, proxy
|
||||
---
|
||||
|
||||
# Configuring an HAProxy extension
|
||||
The following configuration options are available:
|
||||
|
||||
| Option | Type | Description |
|
||||
| --- | --- | --- |
|
||||
| `PidPath` | string | path to the pid file for the proxy service |
|
||||
| `MaxConnections` | int | maximum number of connections for proxy service |
|
||||
| `ConnectTimeout` | int | timeout in seconds for clients to connect |
|
||||
| `ClientTimeout` | int | timeout in seconds for the service to send a request to the proxied upstream |
|
||||
| `ServerTimeout` | int | timeout in seconds for the service to read a response from the proxied upstream |
|
||||
| `AdminUser` | string | username to be used with authenticated access to the proxy service |
|
||||
| `AdminPass` | string | password to be used with authenticated access to the proxy service |
|
||||
| `SSLOpts` | string | options to be passed when configuring SSL |
|
||||
| `SSLDefaultDHParam` | int | size of DH parameters |
|
||||
| `SSLVerify` | string | SSL client verification |
|
||||
| `SSLCiphers` | string | SSL ciphers to use for the proxy service |
|
||||
| `SSLProtocols` | string | enable the specified TLS protocols |
|
||||
| `GlobalOptions` | []string | list of options that are included in the global configuration |
|
||||
| `DefaultOptions` | []string | list of options that are included in the default configuration |
|
||||
|
||||
# Notes
|
||||
|
||||
When using SSL termination, the certificate and key must be combined into a single certificate (i.e. `cat cert.pem key.pem > combined.pem`). The HAProxy extension only uses the certificate label to configure SSL.
|
||||
|
|
@ -1,129 +0,0 @@
|
|||
---
|
||||
title: Layer 7 routing upgrade
|
||||
description: Learn how to upgrade your existing layer 7 routing solution
|
||||
keywords: routing, proxy, hrm
|
||||
redirect_from:
|
||||
- /ee/ucp/interlock/upgrade/
|
||||
---
|
||||
|
||||
The [HTTP routing mesh](/datacenter/ucp/2.2/guides/admin/configure/use-domain-names-to-access-services.md)
|
||||
functionality was redesigned in UCP 3.0 for greater security and flexibility.
|
||||
The functionality was also renamed to "layer 7 routing", to make it easier for
|
||||
new users to get started.
|
||||
|
||||
[Learn about the new layer 7 routing functionality](../index.md).
|
||||
|
||||
To route traffic to your service you apply specific labels to your swarm
|
||||
services, describing the hostname for the service and other configurations.
|
||||
Things work in the same way as they did with the HTTP routing mesh, with the
|
||||
only difference being that you use different labels.
|
||||
|
||||
You don't have to manually update your services. During the upgrade process to
|
||||
3.0, UCP updates the services to start using new labels.
|
||||
|
||||
This article describes the upgrade process for the routing component, so that
|
||||
you can troubleshoot UCP and your services, in case something goes wrong with
|
||||
the upgrade.
|
||||
|
||||
If you are using the HTTP routing mesh, and start an upgrade to UCP 3.0:
|
||||
|
||||
1. UCP starts a reconciliation process to ensure all internal components are
|
||||
deployed. As part of this, services using HRM labels are inspected.
|
||||
2. UCP creates the `com.docker.ucp.interlock.conf-<id>` based on HRM configurations.
|
||||
3. The HRM service is removed.
|
||||
4. The `ucp-interlock` service is deployed with the configuration created.
|
||||
5. The `ucp-interlock` service deploys the `ucp-interlock-extension` and
|
||||
`ucp-interlock-proxy-services`.
|
||||
|
||||
The only way to rollback from an upgrade is by restoring from a backup taken
|
||||
before the upgrade. If something goes wrong during the upgrade process, you
|
||||
need to troubleshoot the interlock services and your services, since the HRM
|
||||
service won't be running after the upgrade.
|
||||
|
||||
[Learn more about the interlock services and architecture](../architecture.md).
|
||||
|
||||
## Check that routing works
|
||||
|
||||
After upgrading to UCP 3.0, you should check if all swarm services are still
|
||||
routable.
|
||||
|
||||
For services using HTTP:
|
||||
|
||||
```bash
|
||||
curl -vs http://<ucp-url>:<hrm-http-port>/ -H "Host: <service-hostname>"
|
||||
```
|
||||
|
||||
For services using HTTPS:
|
||||
|
||||
```bash
|
||||
curl -vs https://<ucp-url>:<hrm-https-port>
|
||||
```
|
||||
|
||||
After the upgrade, check that you can still use the same hostnames to access
|
||||
the swarm services.
|
||||
|
||||
## The ucp-interlock services are not running
|
||||
|
||||
After the upgrade to UCP 3.0, the following services should be running:
|
||||
|
||||
* `ucp-interlock`: monitors swarm workloads configured to use layer 7 routing.
|
||||
* `ucp-interlock-extension`: Helper service that generates the configuration for
|
||||
the `ucp-interlock-proxy` service.
|
||||
* `ucp-interlock-proxy`: A service that provides load balancing and proxying for
|
||||
swarm workloads.
|
||||
|
||||
To check if these services are running, use a client bundle with administrator
|
||||
permissions and run:
|
||||
|
||||
```bash
|
||||
docker ps --filter "name=ucp-interlock"
|
||||
```
|
||||
|
||||
* If the `ucp-interlock` service doesn't exist or is not running, something went
|
||||
wrong with the reconciliation step.
|
||||
* If this still doesn't work, it's possible that UCP is having problems creating
|
||||
the `com.docker.ucp.interlock.conf-1`, due to name conflicts. Make sure you
|
||||
don't have any configuration with the same name by running:
|
||||
```
|
||||
docker config ls --filter "name=com.docker.ucp.interlock"
|
||||
```
|
||||
* If either the `ucp-interlock-extension` or `ucp-interlock-proxy` services are
|
||||
not running, it's possible that there are port conflicts.
|
||||
As a workaround re-enable the layer 7 routing configuration from the
|
||||
[UCP settings page](deploy/index.md). Make sure the ports you choose are not
|
||||
being used by other services.
|
||||
|
||||
## Workarounds and clean-up
|
||||
|
||||
If you have any of the problems above, disable and enable the layer 7 routing
|
||||
setting on the [UCP settings page](index.md). This redeploys the
|
||||
services with their default configuration.
|
||||
|
||||
When doing that make sure you specify the same ports you were using for HRM,
|
||||
and that no other services are listening on those ports.
|
||||
|
||||
You should also check if the `ucp-hrm` service is running. If it is, you should
|
||||
stop it since it can conflict with the `ucp-interlock-proxy` service.
|
||||
|
||||
## Optionally remove labels
|
||||
|
||||
As part of the upgrade process UCP adds the
|
||||
[labels specific to the new layer 7 routing solution](../usage/labels-reference.md).
|
||||
|
||||
You can update your services to remove the old HRM labels, since they won't be
|
||||
used anymore.
|
||||
|
||||
## Optionally segregate control traffic
|
||||
|
||||
Interlock is designed so that all the control traffic is kept separate from
|
||||
the application traffic.
|
||||
|
||||
If before upgrading you had all your applications attached to the `ucp-hrm`
|
||||
network, after upgrading you can update your services to start using a
|
||||
dedicated network for routing that's not shared with other services.
|
||||
[Learn how to use a dedicated network](../usage/index.md).
|
||||
|
||||
If before upgrading you had a dedicate network to route traffic to each service,
|
||||
Interlock will continue using those dedicated networks. However the
|
||||
`ucp-interlock` will be attached to each of those networks. You can update
|
||||
the `ucp-interlock` service so that it is only connected to the `ucp-hrm` network.
|
||||
|
|
@ -1,130 +0,0 @@
|
|||
---
|
||||
title: Layer 7 routing upgrade
|
||||
description: Learn how to upgrade your existing layer 7 routing solution
|
||||
keywords: routing, proxy, hrm
|
||||
redirect_from:
|
||||
- /ee/ucp/interlock/upgrade/
|
||||
---
|
||||
# UCP upgrade process
|
||||
|
||||
The [HTTP routing mesh](/datacenter/ucp/2.2/guides/admin/configure/use-domain-names-to-access-services.md)
|
||||
functionality was redesigned in UCP 3.0 for greater security and flexibility.
|
||||
The functionality was also renamed to "layer 7 routing", to make it easier for
|
||||
new users to get started.
|
||||
|
||||
[Learn about the new layer 7 routing functionality](../index.md).
|
||||
|
||||
To route traffic to your service you apply specific labels to your swarm
|
||||
services, describing the hostname for the service and other configurations.
|
||||
Things work in the same way as they did with the HTTP routing mesh, with the
|
||||
only difference being that you use different labels.
|
||||
|
||||
You don't have to manually update your services. During the upgrade process to
|
||||
3.0, UCP updates the services to start using new labels.
|
||||
|
||||
This article describes the upgrade process for the routing component, so that
|
||||
you can troubleshoot UCP and your services, in case something goes wrong with
|
||||
the upgrade.
|
||||
|
||||
If you are using the HTTP routing mesh, and start an upgrade to UCP 3.0:
|
||||
|
||||
1. UCP starts a reconciliation process to ensure all internal components are
|
||||
deployed. As part of this, services using HRM labels are inspected.
|
||||
2. UCP creates the `com.docker.ucp.interlock.conf-<id>` based on HRM configurations.
|
||||
3. The HRM service is removed.
|
||||
4. The `ucp-interlock` service is deployed with the configuration created.
|
||||
5. The `ucp-interlock` service deploys the `ucp-interlock-extension` and
|
||||
`ucp-interlock-proxy-services`.
|
||||
|
||||
The only way to rollback from an upgrade is by restoring from a backup taken
|
||||
before the upgrade. If something goes wrong during the upgrade process, you
|
||||
need to troubleshoot the interlock services and your services, since the HRM
|
||||
service won't be running after the upgrade.
|
||||
|
||||
[Learn more about the interlock services and architecture](../architecture.md).
|
||||
|
||||
## Check that routing works
|
||||
|
||||
After upgrading to UCP 3.0, you should check if all swarm services are still
|
||||
routable.
|
||||
|
||||
For services using HTTP:
|
||||
|
||||
```bash
|
||||
curl -vs http://<ucp-url>:<hrm-http-port>/ -H "Host: <service-hostname>"
|
||||
```
|
||||
|
||||
For services using HTTPS:
|
||||
|
||||
```bash
|
||||
curl -vs https://<ucp-url>:<hrm-https-port>
|
||||
```
|
||||
|
||||
After the upgrade, check that you can still use the same hostnames to access
|
||||
the swarm services.
|
||||
|
||||
## The ucp-interlock services are not running
|
||||
|
||||
After the upgrade to UCP 3.0, the following services should be running:
|
||||
|
||||
* `ucp-interlock`: monitors swarm workloads configured to use layer 7 routing.
|
||||
* `ucp-interlock-extension`: Helper service that generates the configuration for
|
||||
the `ucp-interlock-proxy` service.
|
||||
* `ucp-interlock-proxy`: A service that provides load balancing and proxying for
|
||||
swarm workloads.
|
||||
|
||||
To check if these services are running, use a client bundle with administrator
|
||||
permissions and run:
|
||||
|
||||
```bash
|
||||
docker ps --filter "name=ucp-interlock"
|
||||
```
|
||||
|
||||
* If the `ucp-interlock` service doesn't exist or is not running, something went
|
||||
wrong with the reconciliation step.
|
||||
* If this still doesn't work, it's possible that UCP is having problems creating
|
||||
the `com.docker.ucp.interlock.conf-1`, due to name conflicts. Make sure you
|
||||
don't have any configuration with the same name by running:
|
||||
```
|
||||
docker config ls --filter "name=com.docker.ucp.interlock"
|
||||
```
|
||||
* If either the `ucp-interlock-extension` or `ucp-interlock-proxy` services are
|
||||
not running, it's possible that there are port conflicts.
|
||||
As a workaround re-enable the layer 7 routing configuration from the
|
||||
[UCP settings page](deploy/index.md). Make sure the ports you choose are not
|
||||
being used by other services.
|
||||
|
||||
## Workarounds and clean-up
|
||||
|
||||
If you have any of the problems above, disable and enable the layer 7 routing
|
||||
setting on the [UCP settings page](index.md). This redeploys the
|
||||
services with their default configuration.
|
||||
|
||||
When doing that make sure you specify the same ports you were using for HRM,
|
||||
and that no other services are listening on those ports.
|
||||
|
||||
You should also check if the `ucp-hrm` service is running. If it is, you should
|
||||
stop it since it can conflict with the `ucp-interlock-proxy` service.
|
||||
|
||||
## Optionally remove labels
|
||||
|
||||
As part of the upgrade process UCP adds the
|
||||
[labels specific to the new layer 7 routing solution](../usage/labels-reference.md).
|
||||
|
||||
You can update your services to remove the old HRM labels, since they won't be
|
||||
used anymore.
|
||||
|
||||
## Optionally segregate control traffic
|
||||
|
||||
Interlock is designed so that all the control traffic is kept separate from
|
||||
the application traffic.
|
||||
|
||||
If before upgrading you had all your applications attached to the `ucp-hrm`
|
||||
network, after upgrading you can update your services to start using a
|
||||
dedicated network for routing that's not shared with other services.
|
||||
[Learn how to use a dedicated network](../usage/index.md).
|
||||
|
||||
If before upgrading you had a dedicate network to route traffic to each service,
|
||||
Interlock will continue using those dedicated networks. However the
|
||||
`ucp-interlock` will be attached to each of those networks. You can update
|
||||
the `ucp-interlock` service so that it is only connected to the `ucp-hrm` network.
|
||||
|
|
@ -1,225 +0,0 @@
|
|||
---
|
||||
title: Applications with SSL
|
||||
description: Learn how to configure your swarm services with SSL.
|
||||
keywords: routing, proxy, tls
|
||||
redirect_from:
|
||||
- /ee/ucp/interlock/usage/ssl/
|
||||
---
|
||||
|
||||
# Implementing SSL
|
||||
This topic covers implementing Swarm services with SLL:
|
||||
|
||||
- SSL termination
|
||||
- SSL passthrough
|
||||
|
||||
## SSL termination
|
||||
In the following example, Docker [Secrets](https://docs.docker.com/engine/swarm/secrets/)
|
||||
are used to centrally and securely store SSL certificates in order to terminate SSL at the proxy service.
|
||||
Application traffic is encrypted in transport to the proxy service, which terminates SSL and then
|
||||
uses unencrypted traffic inside the secure datacenter.
|
||||
|
||||
|
||||
|
||||
First, certificates are generated:
|
||||
|
||||
```bash
|
||||
$> openssl req \
|
||||
-new \
|
||||
-newkey rsa:4096 \
|
||||
-days 3650 \
|
||||
-nodes \
|
||||
-x509 \
|
||||
-subj "/C=US/ST=SomeState/L=SomeCity/O=Interlock/CN=demo.local" \
|
||||
-keyout demo.local.key \
|
||||
-out demo.local.cert
|
||||
```
|
||||
|
||||
Two files are created: `demo.local.cert` and `demo.local.key`. Next, we
|
||||
use these to create Docker Secrets.
|
||||
|
||||
```bash
|
||||
$> docker secret create demo.local.cert demo.local.cert
|
||||
ywn8ykni6cmnq4iz64um1pj7s
|
||||
$> docker secret create demo.local.key demo.local.key
|
||||
e2xo036ukhfapip05c0sizf5w
|
||||
```
|
||||
|
||||
Next, we create an overlay network so that service traffic is isolated and secure:
|
||||
|
||||
```bash
|
||||
$> docker network create -d overlay demo
|
||||
1se1glh749q1i4pw0kf26mfx5
|
||||
```
|
||||
|
||||
```bash
|
||||
$> docker service create \
|
||||
--name demo \
|
||||
--network demo \
|
||||
--label com.docker.lb.hosts=demo.local \
|
||||
--label com.docker.lb.port=8080 \
|
||||
--label com.docker.lb.ssl_cert=demo.local.cert \
|
||||
--label com.docker.lb.ssl_key=demo.local.key \
|
||||
ehazlett/docker-demo
|
||||
6r0wiglf5f3bdpcy6zesh1pzx
|
||||
```
|
||||
|
||||
Interlock detects when the service is available and publishes it. After tasks are running
|
||||
and the proxy service is updated, the application should be available via `https://demo.local`.
|
||||
|
||||
Note: You must have an entry for `demo.local` in your local hosts (i.e. `/etc/hosts`) file.
|
||||
You cannot use a host header as shown in other examples due to the way [SNI](https://tools.ietf.org/html/rfc3546#page-8) works.
|
||||
|
||||
```bash
|
||||
$> curl -vsk https://demo.local/ping
|
||||
* Trying 127.0.0.1...
|
||||
* TCP_NODELAY set
|
||||
* Connected to demo.local (127.0.0.1) port 443 (#0)
|
||||
* ALPN, offering http/1.1
|
||||
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
|
||||
* successfully set certificate verify locations:
|
||||
* CAfile: /etc/ssl/certs/ca-certificates.crt
|
||||
CApath: none
|
||||
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
|
||||
* TLSv1.2 (IN), TLS handshake, Server hello (2):
|
||||
* TLSv1.2 (IN), TLS handshake, Certificate (11):
|
||||
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
|
||||
* TLSv1.2 (IN), TLS handshake, Server finished (14):
|
||||
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
|
||||
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
|
||||
* TLSv1.2 (OUT), TLS handshake, Finished (20):
|
||||
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
|
||||
* TLSv1.2 (IN), TLS handshake, Finished (20):
|
||||
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
|
||||
* ALPN, server accepted to use http/1.1
|
||||
* Server certificate:
|
||||
* subject: C=US; ST=SomeState; L=SomeCity; O=Interlock; CN=demo.local
|
||||
* start date: Nov 8 16:23:03 2017 GMT
|
||||
* expire date: Nov 6 16:23:03 2027 GMT
|
||||
* issuer: C=US; ST=SomeState; L=SomeCity; O=Interlock; CN=demo.local
|
||||
* SSL certificate verify result: self signed certificate (18), continuing anyway.
|
||||
> GET /ping HTTP/1.1
|
||||
> Host: demo.local
|
||||
> User-Agent: curl/7.54.0
|
||||
> Accept: */*
|
||||
>
|
||||
< HTTP/1.1 200 OK
|
||||
< Server: nginx/1.13.6
|
||||
< Date: Wed, 08 Nov 2017 16:26:55 GMT
|
||||
< Content-Type: text/plain; charset=utf-8
|
||||
< Content-Length: 92
|
||||
< Connection: keep-alive
|
||||
< Set-Cookie: session=1510158415298009207; Path=/; Expires=Thu, 09 Nov 2017 16:26:55 GMT; Max-Age=86400
|
||||
< x-request-id: 4b15ab2aaf2e0bbdea31f5e4c6b79ebd
|
||||
< x-proxy-id: a783b7e646af
|
||||
< x-server-info: interlock/2.0.0-development (147ff2b1) linux/amd64
|
||||
< x-upstream-addr: 10.0.2.3:8080
|
||||
|
||||
{"instance":"c2f1afe673d4","version":"0.1",request_id":"7bcec438af14f8875ffc3deab9215bc5"}
|
||||
```
|
||||
|
||||
Because the certificate and key are stored securely in Swarm, you can safely scale this service, as well as the proxy
|
||||
service, and Swarm handles granting access to the credentials as needed.
|
||||
|
||||
## SSL passthrough
|
||||
In the following example, SSL passthrough is used to ensure encrypted communication from the request to the application
|
||||
service. This ensures maximum security because there is no unencrypted transport.
|
||||
|
||||
|
||||
|
||||
First, generate certificates for the application:
|
||||
|
||||
```bash
|
||||
$> openssl req \
|
||||
-new \
|
||||
-newkey rsa:4096 \
|
||||
-days 3650 \
|
||||
-nodes \
|
||||
-x509 \
|
||||
-subj "/C=US/ST=SomeState/L=SomeCity/O=Interlock/CN=demo.local" \
|
||||
-keyout app.key \
|
||||
-out app.cert
|
||||
```
|
||||
|
||||
Two files are created: `app.cert` and `app.key`. Next, we
|
||||
use these to create Docker Secrets.
|
||||
|
||||
```bash
|
||||
$> docker secret create app.cert app.cert
|
||||
ywn8ykni6cmnq4iz64um1pj7s
|
||||
$> docker secret create app.key app.key
|
||||
e2xo036ukhfapip05c0sizf5w
|
||||
```
|
||||
|
||||
Now create an overlay network to isolate and secure service traffic:
|
||||
|
||||
```bash
|
||||
$> docker network create -d overlay demo
|
||||
1se1glh749q1i4pw0kf26mfx5
|
||||
```
|
||||
|
||||
```bash
|
||||
$> docker service create \
|
||||
--name demo \
|
||||
--network demo \
|
||||
--detach=false \
|
||||
--secret source=app.cert,target=/run/secrets/cert.pem \
|
||||
--secret source=app.key,target=/run/secrets/key.pem \
|
||||
--label com.docker.lb.hosts=demo.local \
|
||||
--label com.docker.lb.port=8080 \
|
||||
--label com.docker.lb.ssl_passthrough=true \
|
||||
--env METADATA="demo-ssl-passthrough" \
|
||||
ehazlett/docker-demo --tls-cert=/run/secrets/cert.pem --tls-key=/run/secrets/key.pem
|
||||
```
|
||||
|
||||
Interlock detects when the service is available and publishes it. When tasks are running
|
||||
and the proxy service is updated, the application is available via `https://demo.local`.
|
||||
|
||||
Note: You must have an entry for `demo.local` in your local hosts (i.e. `/etc/hosts`) file.
|
||||
You cannot use a host header as in other examples due to the way [SNI](https://tools.ietf.org/html/rfc3546#page-8) works.
|
||||
|
||||
```bash
|
||||
$> curl -vsk https://demo.local/ping
|
||||
* Trying 127.0.0.1...
|
||||
* TCP_NODELAY set
|
||||
* Connected to demo.local (127.0.0.1) port 443 (#0)
|
||||
* ALPN, offering http/1.1
|
||||
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
|
||||
* successfully set certificate verify locations:
|
||||
* CAfile: /etc/ssl/certs/ca-certificates.crt
|
||||
CApath: none
|
||||
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
|
||||
* TLSv1.2 (IN), TLS handshake, Server hello (2):
|
||||
* TLSv1.2 (IN), TLS handshake, Certificate (11):
|
||||
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
|
||||
* TLSv1.2 (IN), TLS handshake, Server finished (14):
|
||||
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
|
||||
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
|
||||
* TLSv1.2 (OUT), TLS handshake, Finished (20):
|
||||
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
|
||||
* TLSv1.2 (IN), TLS handshake, Finished (20):
|
||||
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
|
||||
* ALPN, server accepted to use http/1.1
|
||||
* Server certificate:
|
||||
* subject: C=US; ST=SomeState; L=SomeCity; O=Interlock; CN=demo.local
|
||||
* start date: Nov 8 16:39:45 2017 GMT
|
||||
* expire date: Nov 6 16:39:45 2027 GMT
|
||||
* issuer: C=US; ST=SomeState; L=SomeCity; O=Interlock; CN=demo.local
|
||||
* SSL certificate verify result: self signed certificate (18), continuing anyway.
|
||||
> GET /ping HTTP/1.1
|
||||
> Host: demo.local
|
||||
> User-Agent: curl/7.54.0
|
||||
> Accept: */*
|
||||
>
|
||||
< HTTP/1.1 200 OK
|
||||
< Connection: close
|
||||
< Set-Cookie: session=1510159255159600720; Path=/; Expires=Thu, 09 Nov 2017 16:40:55 GMT; Max-Age=86400
|
||||
< Date: Wed, 08 Nov 2017 16:40:55 GMT
|
||||
< Content-Length: 78
|
||||
< Content-Type: text/plain; charset=utf-8
|
||||
<
|
||||
{"instance":"327d5a26bc30","version":"0.1","metadata":"demo-ssl-passthrough"}
|
||||
```
|
||||
|
||||
Application traffic travels securely, fully encrypted from the request to the application service.
|
||||
Notice that Interlock cannot add the metadata response headers (version info, request ID, etc), because this is using
|
||||
TCP passthrough and cannot add the metadata.
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
datafolder: registry-cli
|
||||
datafile: docker_registry
|
||||
title: docker registry
|
||||
---
|
||||
|
||||
<!--
|
||||
Sorry, but the contents of this page are automatically generated from
|
||||
Docker's source code. If you want to suggest a change to the text that appears
|
||||
here, you'll need to open a ticket in the documentation repository:
|
||||
|
||||
https://github.com/docker/docker.github.io/issues/new
|
||||
-->
|
||||
|
||||
{% include cli.md datafolder=page.datafolder datafile=page.datafile %}
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
datafolder: registry-cli
|
||||
datafile: docker_registry_events
|
||||
title: docker registry events
|
||||
---
|
||||
|
||||
<!--
|
||||
Sorry, but the contents of this page are automatically generated from
|
||||
Docker's source code. If you want to suggest a change to the text that appears
|
||||
here, you'll need to open a ticket in the documentation repository:
|
||||
|
||||
https://github.com/docker/docker.github.io/issues/new
|
||||
-->
|
||||
|
||||
{% include cli.md datafolder=page.datafolder datafile=page.datafile %}
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
datafolder: registry-cli
|
||||
datafile: docker_registry_history
|
||||
title: docker registry history
|
||||
---
|
||||
|
||||
<!--
|
||||
Sorry, but the contents of this page are automatically generated from
|
||||
Docker's source code. If you want to suggest a change to the text that appears
|
||||
here, you'll need to open a ticket in the documentation repository:
|
||||
|
||||
https://github.com/docker/docker.github.io/issues/new
|
||||
-->
|
||||
|
||||
{% include cli.md datafolder=page.datafolder datafile=page.datafile %}
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
datafolder: registry-cli
|
||||
datafile: docker_registry_info
|
||||
title: docker registry info
|
||||
---
|
||||
|
||||
<!--
|
||||
Sorry, but the contents of this page are automatically generated from
|
||||
Docker's source code. If you want to suggest a change to the text that appears
|
||||
here, you'll need to open a ticket in the documentation repository:
|
||||
|
||||
https://github.com/docker/docker.github.io/issues/new
|
||||
-->
|
||||
|
||||
{% include cli.md datafolder=page.datafolder datafile=page.datafile %}
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
datafolder: registry-cli
|
||||
datafile: docker_registry_inspect
|
||||
title: docker registry inspect
|
||||
---
|
||||
|
||||
<!--
|
||||
Sorry, but the contents of this page are automatically generated from
|
||||
Docker's source code. If you want to suggest a change to the text that appears
|
||||
here, you'll need to open a ticket in the documentation repository:
|
||||
|
||||
https://github.com/docker/docker.github.io/issues/new
|
||||
-->
|
||||
|
||||
{% include cli.md datafolder=page.datafolder datafile=page.datafile %}
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
datafolder: registry-cli
|
||||
datafile: docker_registry_joblogs
|
||||
title: docker registry joblogs
|
||||
---
|
||||
|
||||
<!--
|
||||
Sorry, but the contents of this page are automatically generated from
|
||||
Docker's source code. If you want to suggest a change to the text that appears
|
||||
here, you'll need to open a ticket in the documentation repository:
|
||||
|
||||
https://github.com/docker/docker.github.io/issues/new
|
||||
-->
|
||||
|
||||
{% include cli.md datafolder=page.datafolder datafile=page.datafile %}
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
datafolder: registry-cli
|
||||
datafile: docker_registry_jobs
|
||||
title: docker registry jobs
|
||||
---
|
||||
|
||||
<!--
|
||||
Sorry, but the contents of this page are automatically generated from
|
||||
Docker's source code. If you want to suggest a change to the text that appears
|
||||
here, you'll need to open a ticket in the documentation repository:
|
||||
|
||||
https://github.com/docker/docker.github.io/issues/new
|
||||
-->
|
||||
|
||||
{% include cli.md datafolder=page.datafolder datafile=page.datafile %}
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
datafolder: registry-cli
|
||||
datafile: docker_registry_ls
|
||||
title: docker registry ls
|
||||
---
|
||||
|
||||
<!--
|
||||
Sorry, but the contents of this page are automatically generated from
|
||||
Docker's source code. If you want to suggest a change to the text that appears
|
||||
here, you'll need to open a ticket in the documentation repository:
|
||||
|
||||
https://github.com/docker/docker.github.io/issues/new
|
||||
-->
|
||||
|
||||
{% include cli.md datafolder=page.datafolder datafile=page.datafile %}
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
datafolder: registry-cli
|
||||
datafile: docker_registry_rmi
|
||||
title: docker registry rmi
|
||||
---
|
||||
|
||||
<!--
|
||||
Sorry, but the contents of this page are automatically generated from
|
||||
Docker's source code. If you want to suggest a change to the text that appears
|
||||
here, you'll need to open a ticket in the documentation repository:
|
||||
|
||||
https://github.com/docker/docker.github.io/issues/new
|
||||
-->
|
||||
|
||||
{% include cli.md datafolder=page.datafolder datafile=page.datafile %}
|
||||
Loading…
Reference in New Issue