Revert "Merge branch 'amberjack' into master"

This reverts commit 87e1870d92, reversing
changes made to 4d3d196bb6.
This commit is contained in:
Maria Bermudez 2019-05-12 17:48:01 -07:00
parent 82cd7ac178
commit 5612fcbff8
95 changed files with 3 additions and 4016 deletions

2
Jenkinsfile vendored
View File

@ -168,4 +168,4 @@ pipeline {
}
}
}
}
}

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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`.

View File

@ -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
```

View File

@ -1,81 +0,0 @@
---
title: Configure Docker Assemble
description: Installing Docker Assemble
keywords: Assemble, Docker Enterprise, plugin, Spring Boot, .NET, c#, F#
---
Although you dont 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 werent 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)

View File

@ -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
```

View File

@ -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.

View 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/).

View File

@ -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
```

View File

@ -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.) | |

View File

@ -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. |

View File

@ -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 Intels 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, its 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.

View File

@ -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:
![Virtualization Technology (VTx) must be enabled in BIOS settings](../../images/windows-prereq.png "BIOS setting information for hardware virtualization support")
> **Note:** Docker supports Docker Desktop Enterprise on Windows based on Microsofts 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**.

View File

@ -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 Application Designer lets you choose an existing template or create a custom application.](./images/app-design-start.png "Application Designer")
The list of available templates is provided:
![You can tab through the available application templates. A description of each template is provided.](./images/app-design-choose.png "Available templates for application creation")
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 customize your application, which includes specifying database, proxy, and other details.](./images/app-design-custom.png "Customizing your application")
You can then name your application and customize the disk location:
![You can also customize the name and location of your application.](./images/app-design-custom2.png "Naming and specifying a location for your application")
When you select **Assemble**, your application is created.
![When you assemble your application, a status screen is displayed.](./images/app-design-test.png "Assembling your application")
Once assembled, the following screen allows you to run the application. Select **Run application** to pull the images and start the containers:
![When you run your application, the terminal displays output from the application.](./images/app-design-run.png "Running your application")
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

View File

@ -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.

View File

@ -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.

View File

@ -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.
![A diagnostics file is created.](../images/diagnose-mac.png)
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**.
![Mac Console search for Docker app](../images/console.png)
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.

View File

@ -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.
![A diagnostics file is created.](../images/diagnose-windows.png)
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.

View File

@ -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.
![nginx home page](../images/hello-world-nginx.png)
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.
![Docker context menu](../images/prefs.png)
#### General
![Preferences](../images/./prefs-general.png)
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](../images/prefs-fileshare.png)
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.
![Disk settings](../images/prefs-disk.png)
#### Advanced
On the Advanced tab, you can limit resources available to Docker.
![Advanced Preference settings](../images/prefs-advanced.png)
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.
![Proxies settings](../images/prefs-proxies.png)
![macOS Proxy Settings](../images/proxy-settings.png)
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.
![Daemon](../images/prefs-daemon-basic.png)
##### 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.
![Docker Daemon](../images/prefs-daemon-adv.png)
#### 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.
![Enable Kubernetes](../images/prefs-kubernetes.png)
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.
![Installation complete](../images/kubernetes-install-complete.png)
The status of Kubernetes shows in the Docker menu and the context points to `docker-desktop`.
![Docker Menu with Kubernetes](../images/kube-context.png)
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.
![Uninstall or reset Docker](../images/prefs-reset-mac.png)
### 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
```

View File

@ -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.)
![Run nginx edge](../images/nginx-homepage.png)
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:
![Showing hidden apps in the taskbar](../images/whale-icon-systray-hidden.png)
> **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:
![Docker Desktop Enterprise popup menu](../images/docker-menu-settings.png)
#### General
On the **General** tab of the Settings dialog, you can configure when to start Docker Desktop.
![Settings](../images/settings-general.png)
- **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).
![Shared drives](../images/settings-shared-drives.png)
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:
![Port 445 blocked](../images/shared-drive-firewall-blocked.png)
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**.
![Shared drive on demand](../images/shared-drive-on-demand.png)
#### Advanced
The Linux VM restarts after changing the settings on the **Advanced** tab. This takes a few seconds.
![CPU and Memory settings](../images/settings-advanced.png)
- **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).
![Network settings](../images/settings-network.png)
> **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.
![Proxies](../images/settings-proxies.png)
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.
![Docker Daemon](../images/settings-daemon-basic.png)
> **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.
![Docker Daemon](../images/settings-daemon-advanced.png)
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.
![Enable Kubernetes](../images/settings-kubernetes.png)
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:
![Change Kubernetes Context](../images/docker-menu-context-switch.png)
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.
![Reset](../images/settings-reset.png)
- **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.
![Version Selection](../images/win-ver-select.PNG)
### 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.
![Windows-Linux container types switch](../images/docker-menu-switch.png)
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.

View File

@ -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
```

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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.
![Interlock SSL Termination](../../images/interlock_ssl_termination.png)
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.
![Interlock SSL Passthrough](../../images/interlock_ssl_passthrough.png)
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.

View File

@ -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 %}

View File

@ -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 %}

View File

@ -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 %}

View File

@ -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 %}

View File

@ -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 %}

View File

@ -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 %}

View File

@ -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 %}

View File

@ -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 %}

View File

@ -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 %}