docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'amberjack' of github.com:bermudezmt/docs-private into amberjack

This commit is contained in:
Maria Bermudez 2019-05-31 09:58:54 -07:00
parent 69f88ad0fe b22efe3567
commit fc1e83322b
7 changed files with 29 additions and 403 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

132
Jenkinsfile vendored
View File

@ -17,108 +17,11 @@ pipeline {
} }
stages { stages {
stage( 'docker.github.io' ) { stage( 'docker.github.io' ) {
<<<<<<< HEAD
=======
agent {
label 'ubuntu-1604-aufs-stable'
}
environment {
DTR_VPN_ADDRESS = credentials('dtr-vpn-address')
DOCKER_HOST_STRING = credentials('docker-host')
UCP_BUNDLE = credentials('ucp-bundle')
SLACK = credentials('slack-docs-webhook')
}
>>>>>>> d2e9df79bd... make jenkinsfile serve private and public docs
when { when {
expression { env.GIT_URL == 'https://github.com/Docker/docker.github.io.git' } expression { env.GIT_URL == 'https://github.com/Docker/docker.github.io.git' }
} }
stages { stages {
<<<<<<< HEAD
stage( 'build + push stage image, update stage swarm' ) { stage( 'build + push stage image, update stage swarm' ) {
=======
stage( 'build and push stage image' ) {
when {
branch 'master'
}
steps {
withDockerRegistry(reg) {
sh """
docker image build --tag docs/docker.github.io:stage-${env.BUILD_NUMBER} . && \
docker image push docs/docker.github.io:stage-${env.BUILD_NUMBER}
"""
}
}
}
stage( 'build and push prod image' ) {
when {
branch 'published'
}
steps {
withDockerRegistry(reg) {
sh """
docker image build --tag docs/docker.github.io:prod-${env.BUILD_NUMBER} . && \
docker image push docs/docker.github.io:prod-${env.BUILD_NUMBER}
"""
}
}
}
stage( 'update docs stage' ) {
when {
branch 'master'
}
steps {
withVpn("$DTR_VPN_ADDRESS") {
sh "unzip -o $UCP_BUNDLE"
withDockerRegistry(reg) {
sh """
export DOCKER_TLS_VERIFY=1
export COMPOSE_TLS_VERSION=TLSv1_2
export DOCKER_CERT_PATH=${WORKSPACE}/ucp-bundle-success_bot
export DOCKER_HOST=$DOCKER_HOST_STRING
docker service update --detach=false --force --image docs/docker.github.io:stage-${env.BUILD_NUMBER} docs-stage-docker-com_docs --with-registry-auth
"""
}
}
}
}
stage( 'update docs prod' ) {
when {
branch 'published'
}
steps {
withVpn("$DTR_VPN_ADDRESS") {
sh "unzip -o $UCP_BUNDLE"
withDockerRegistry(reg) {
sh """
cd ucp-bundle-success_bot
export DOCKER_TLS_VERIFY=1
export COMPOSE_TLS_VERSION=TLSv1_2
export DOCKER_CERT_PATH=${WORKSPACE}/ucp-bundle-success_bot
export DOCKER_HOST=$DOCKER_HOST_STRING
docker service update --detach=false --force --image docs/docker.github.io:prod-${env.BUILD_NUMBER} docs-docker-com_docs --with-registry-auth
curl -X POST -H 'Content-type: application/json' --data '{"text":"Successfully published docs. https://docs.docker.com/"}' $SLACK
"""
}
}
}
}
}
}
stage( 'docs-private' ) {
agent {
label 'ubuntu-1604-aufs-stable'
}
environment {
DTR_VPN_ADDRESS = credentials('dtr-vpn-address')
DOCKER_HOST_STRING = credentials('docker-host')
UCP_BUNDLE = credentials('ucp-bundle')
}
when {
expression { env.GIT_URL == "https://github.com/docker/docs-private.git" }
}
stages {
stage( 'build and push new beta stage image' ) {
>>>>>>> d2e9df79bd... make jenkinsfile serve private and public docs
when { when {
branch 'master' branch 'master'
} }
@ -143,25 +46,7 @@ pipeline {
branch 'published' branch 'published'
} }
steps { steps {
<<<<<<< HEAD
withVpn("$DTR_VPN_ADDRESS") { withVpn("$DTR_VPN_ADDRESS") {
=======
withDockerRegistry(reg) {
sh """
docker image build --tag docs/docs-private:beta-${env.BUILD_NUMBER} . && \
docker image push docs/docs-private:beta-${env.BUILD_NUMBER}
"""
}
}
}
stage( 'update beta stage service' ) {
when {
branch 'amberjack'
}
steps {
withVpn("$DTR_VPN_ADDRESS") {
sh "unzip -o $UCP_BUNDLE"
>>>>>>> d2e9df79bd... make jenkinsfile serve private and public docs
withDockerRegistry(reg) { withDockerRegistry(reg) {
sh """ sh """
docker build -t docs/docker.github.io:prod-${env.BUILD_NUMBER} . docker build -t docs/docker.github.io:prod-${env.BUILD_NUMBER} .
@ -172,12 +57,8 @@ pipeline {
export COMPOSE_TLS_VERSION=TLSv1_2 export COMPOSE_TLS_VERSION=TLSv1_2
export DOCKER_CERT_PATH=${WORKSPACE}/ucp-bundle-success_bot export DOCKER_CERT_PATH=${WORKSPACE}/ucp-bundle-success_bot
export DOCKER_HOST=$DOCKER_HOST_STRING export DOCKER_HOST=$DOCKER_HOST_STRING
<<<<<<< HEAD
docker service update --detach=false --force --image docs/docker.github.io:prod-${env.BUILD_NUMBER} docs-docker-com_docs --with-registry-auth docker service update --detach=false --force --image docs/docker.github.io:prod-${env.BUILD_NUMBER} docs-docker-com_docs --with-registry-auth
curl -X POST -H 'Content-type: application/json' --data '{"text":"Successfully published docs. https://docs.docker.com/"}' $SLACK curl -X POST -H 'Content-type: application/json' --data '{"text":"Successfully published docs. https://docs.docker.com/"}' $SLACK
=======
docker service update --detach=false --force --image docs/docs-private:beta-stage-${env.BUILD_NUMBER} docs-beta-stage-docker-com_docs --with-registry-auth
>>>>>>> d2e9df79bd... make jenkinsfile serve private and public docs
""" """
} }
} }
@ -216,7 +97,6 @@ pipeline {
} }
steps { steps {
withVpn("$DTR_VPN_ADDRESS") { withVpn("$DTR_VPN_ADDRESS") {
<<<<<<< HEAD
sh """ sh """
cat $SUCCESS_BOT_TOKEN | docker login $DTR_URL --username 'success_bot' --password-stdin cat $SUCCESS_BOT_TOKEN | docker login $DTR_URL --username 'success_bot' --password-stdin
docker build -t $DTR_URL/docker/docs-private:beta-${env.BUILD_NUMBER} . docker build -t $DTR_URL/docker/docs-private:beta-${env.BUILD_NUMBER} .
@ -228,18 +108,6 @@ pipeline {
export DOCKER_HOST=$DOCKER_HOST_STRING export DOCKER_HOST=$DOCKER_HOST_STRING
docker service update --detach=false --force --image $DTR_URL/docker/docs-private:beta-${env.BUILD_NUMBER} docs-beta-docker-com_docs --with-registry-auth docker service update --detach=false --force --image $DTR_URL/docker/docs-private:beta-${env.BUILD_NUMBER} docs-beta-docker-com_docs --with-registry-auth
""" """
=======
sh "unzip -o $UCP_BUNDLE"
withDockerRegistry(reg) {
sh """
export DOCKER_TLS_VERIFY=1
export COMPOSE_TLS_VERSION=TLSv1_2
export DOCKER_CERT_PATH=${WORKSPACE}/ucp-bundle-success_bot
export DOCKER_HOST=$DOCKER_HOST_STRING
docker service update --detach=false --force --image docs/docs-private:beta-${env.BUILD_NUMBER} docs-beta-docker-com_docs --with-registry-auth
"""
}
>>>>>>> d2e9df79bd... make jenkinsfile serve private and public docs
} }
} }
} }

6
_data/toc.yaml
View File

@ -1529,6 +1529,12 @@ manuals:
path: /ee/ucp/interlock/usage/interlock-vip-mode/ path: /ee/ucp/interlock/usage/interlock-vip-mode/
- title: Using routing labels - title: Using routing labels
path: /ee/ucp/interlock/usage/labels-reference/ path: /ee/ucp/interlock/usage/labels-reference/
- title: Publishing a default host service
path: /ee/ucp/interlock/usage/default-backend/
- title: Specifying a routing mode
path: /ee/ucp/interlock/usage/interlock-vip-mode/
- title: Using routing labels
path: /ee/ucp/interlock/usage/labels-reference.md/
- title: Implementing redirects - title: Implementing redirects
path: /ee/ucp/interlock/usage/redirects/ path: /ee/ucp/interlock/usage/redirects/
- title: Implementing a service cluster - title: Implementing a service cluster

4
app-template/working-with-template.md
View File

@ -1,7 +1,7 @@
--- ---
title: Working with Docker Template title: Working with Docker Template
description: Working with Docker Application Template description: Working with Docker Application Template
keywords: Docker, application template, Application Designer, keywords: Docker, application template, Application Designer
--- ---
## Overview ## Overview
@ -442,4 +442,4 @@ The following table lists the `interpolator` binary options:
| `-source` | none | Source file or folder to interpolate from| | `-source` | none | Source file or folder to interpolate from|
| `-destination` | none | Destination file or folder to copy the interpolated files to| | `-destination` | none | Destination file or folder to copy the interpolated files to|
| `-config` | `/run/configuration` | The path to the json configuration file | | `-config` | `/run/configuration` | The path to the json configuration file |
| `-skip-template` | false | If set to `true`, it copies assets without any transformation | | `-skip-template` | false | If set to `true`, it copies assets without any transformation |

27
ee/desktop/release-notes.md
View File

@ -16,6 +16,25 @@ For Docker Enterprise Engine release notes, see [Docker Engine release notes](/e
## Docker Desktop Enterprise Releases of 2019 ## Docker Desktop Enterprise Releases of 2019
### Docker Desktop Enterprise 2.0.0.5
2019-05-30
- Upgrades
- [Docker 19.03.0-rc1](https://docs.docker.com/engine/release-notes/) in Enterprise 3.0 version pack
- Application Designer 0.1.2
- [Qemu 4.0.0](https://github.com/docker/binfmt) to cross-compile ARM devices
- Bug fixes and minor changes
- Application Designer now allows users to copy and paste application logs.
- Users can browse the scaffold logs when scaffolding a new application using the Application Designer.
- Application Designer allows users to set preferences, including the default organization and registry.
- Docker Desktop admins can enforce Application Designer preferences using the `admin-settings.json` file.
- Security improvements: Docker Desktop now checks TLS certificates for the target endpoints when using `kubectl`.
- Fixed an issue where Visual Studio Code IDE path was not detected properly.
### Docker Desktop Enterprise 2.0.0.4 ### Docker Desktop Enterprise 2.0.0.4
2019-05-16 2019-05-16
@ -32,19 +51,11 @@ For Docker Enterprise Engine release notes, see [Docker Engine release notes](/e
- Fixed a race condition where Kubernetes sometimes failed to start after restarting the application. - Fixed a race condition where Kubernetes sometimes failed to start after restarting the application.
- Fixed a bug that causes Docker Compose to fail when a user logs out after logging in. See [docker/compose#6517](https://github.com/docker/compose/issues/6517) - Fixed a bug that causes Docker Compose to fail when a user logs out after logging in. See [docker/compose#6517](https://github.com/docker/compose/issues/6517)
- Improved the reliability of `com.docker.osxfs trace` performance profiling command. - Improved the reliability of `com.docker.osxfs trace` performance profiling command.
<<<<<<< HEAD
- Docker Desktop now supports large lists of resource DNS records on Mac. See [docker/for-mac#2160](https://github.com/docker/for-mac/issues/2160#issuecomment-431571031). - Docker Desktop now supports large lists of resource DNS records on Mac. See [docker/for-mac#2160](https://github.com/docker/for-mac/issues/2160#issuecomment-431571031).
- Users can now run a Docker registry in a container. See [docker/for-mac#3611](https://github.com/docker/for-mac/issues/3611). - Users can now run a Docker registry in a container. See [docker/for-mac#3611](https://github.com/docker/for-mac/issues/3611).
- For Linux containers on Windows (LCOW), one physical computer system running Windows 10 Professional or Windows 10 Enterprise version 1809 or later is required. - For Linux containers on Windows (LCOW), one physical computer system running Windows 10 Professional or Windows 10 Enterprise version 1809 or later is required.
- Added a dialog box during startup when a shared drive fails to mount. This allows users to retry mounting the drive or remove it from the shared drive list. - Added a dialog box during startup when a shared drive fails to mount. This allows users to retry mounting the drive or remove it from the shared drive list.
- Removed the ability to log in using an email address as a username as this is not supported by the Docker command line. - Removed the ability to log in using an email address as a username as this is not supported by the Docker command line.
=======
- Docker Desktop now supports large lists of resource DNS records on Mac. See [docker/for-mac#2160](https://github.com/docker/for-mac/issues/2160#issuecomment-431571031)
- Users can now run a Docker registry in a container. See [docker/for-mac#3611](https://github.com/docker/for-mac/issues/3611).
- For Linux containers on Windows (LCOW), one physical computer system running Windows 10 Professional or Windows 10 Enterprise version 1809 or later is required.
- Added a dialog box during start up when a shared drive fails to mount allowing the user to retry mounting the drive or remove it from the shared drive list.
- Removed the ability to log in using an email address as a username as it is not supported by the Docker command line.
>>>>>>> 911e6599e3... minor updates to the public beta release notes
### Docker Desktop Enterprise 2.0.0.3 ### Docker Desktop Enterprise 2.0.0.3

129
ee/ucp/interlock/deploy/upgrade.md~HEAD
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.

130
ee/ucp/interlock/deploy/upgrade.md~Raw content addition
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.