mirror of https://github.com/docker/docs.git
Merge branch 'amberjack' of github.com:bermudezmt/docs-private into amberjack
This commit is contained in:
Maria Bermudez
commit
fc1e83322b
|
|
@ -17,108 +17,11 @@ pipeline {
|
|||
}
|
||||
stages {
|
||||
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 {
|
||||
expression { env.GIT_URL == 'https://github.com/Docker/docker.github.io.git' }
|
||||
}
|
||||
stages {
|
||||
<<<<<<< HEAD
|
||||
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 {
|
||||
branch 'master'
|
||||
}
|
||||
|
|
@ -143,25 +46,7 @@ pipeline {
|
|||
branch 'published'
|
||||
}
|
||||
steps {
|
||||
<<<<<<< HEAD
|
||||
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) {
|
||||
sh """
|
||||
docker build -t docs/docker.github.io:prod-${env.BUILD_NUMBER} .
|
||||
|
|
@ -172,12 +57,8 @@ pipeline {
|
|||
export COMPOSE_TLS_VERSION=TLSv1_2
|
||||
export DOCKER_CERT_PATH=${WORKSPACE}/ucp-bundle-success_bot
|
||||
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
|
||||
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 {
|
||||
withVpn("$DTR_VPN_ADDRESS") {
|
||||
<<<<<<< HEAD
|
||||
sh """
|
||||
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} .
|
||||
|
|
@ -228,18 +108,6 @@ pipeline {
|
|||
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
|
||||
"""
|
||||
=======
|
||||
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
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1529,6 +1529,12 @@ manuals:
|
|||
path: /ee/ucp/interlock/usage/interlock-vip-mode/
|
||||
- title: Using routing labels
|
||||
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
|
||||
path: /ee/ucp/interlock/usage/redirects/
|
||||
- title: Implementing a service cluster
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Working with Docker Template
|
||||
description: Working with Docker Application Template
|
||||
keywords: Docker, application template, Application Designer,
|
||||
keywords: Docker, application template, Application Designer
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
|
@ -442,4 +442,4 @@ The following table lists the `interpolator` binary options:
|
|||
| `-source` | none | Source file or folder to interpolate from|
|
||||
| `-destination` | none | Destination file or folder to copy the interpolated files to|
|
||||
| `-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 |
|
||||
|
|
|
|||
|
|
@ -43,4 +43,4 @@ Once assembled, the following screen allows you to run the application. Select *
|
|||
|
||||
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.
|
||||
window.
|
||||
|
|
|
|||
|
|
@ -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 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
|
||||
|
||||
2019-05-16
|
||||
|
|
@ -32,20 +51,12 @@ 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 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.
|
||||
<<<<<<< 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).
|
||||
- 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 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.
|
||||
=======
|
||||
- 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
|
||||
|
||||
2019-04-26
|
||||
|
|
|
|||
|
|
@ -1,129 +0,0 @@
|
|||
---
|
||||
title: Layer 7 routing upgrade
|
||||
description: Learn how to upgrade your existing layer 7 routing solution
|
||||
keywords: routing, proxy, hrm
|
||||
redirect_from:
|
||||
- /ee/ucp/interlock/upgrade/
|
||||
---
|
||||
|
||||
The [HTTP routing mesh](/datacenter/ucp/2.2/guides/admin/configure/use-domain-names-to-access-services.md)
|
||||
functionality was redesigned in UCP 3.0 for greater security and flexibility.
|
||||
The functionality was also renamed to "layer 7 routing", to make it easier for
|
||||
new users to get started.
|
||||
|
||||
[Learn about the new layer 7 routing functionality](../index.md).
|
||||
|
||||
To route traffic to your service you apply specific labels to your swarm
|
||||
services, describing the hostname for the service and other configurations.
|
||||
Things work in the same way as they did with the HTTP routing mesh, with the
|
||||
only difference being that you use different labels.
|
||||
|
||||
You don't have to manually update your services. During the upgrade process to
|
||||
3.0, UCP updates the services to start using new labels.
|
||||
|
||||
This article describes the upgrade process for the routing component, so that
|
||||
you can troubleshoot UCP and your services, in case something goes wrong with
|
||||
the upgrade.
|
||||
|
||||
If you are using the HTTP routing mesh, and start an upgrade to UCP 3.0:
|
||||
|
||||
1. UCP starts a reconciliation process to ensure all internal components are
|
||||
deployed. As part of this, services using HRM labels are inspected.
|
||||
2. UCP creates the `com.docker.ucp.interlock.conf-<id>` based on HRM configurations.
|
||||
3. The HRM service is removed.
|
||||
4. The `ucp-interlock` service is deployed with the configuration created.
|
||||
5. The `ucp-interlock` service deploys the `ucp-interlock-extension` and
|
||||
`ucp-interlock-proxy-services`.
|
||||
|
||||
The only way to rollback from an upgrade is by restoring from a backup taken
|
||||
before the upgrade. If something goes wrong during the upgrade process, you
|
||||
need to troubleshoot the interlock services and your services, since the HRM
|
||||
service won't be running after the upgrade.
|
||||
|
||||
[Learn more about the interlock services and architecture](../architecture.md).
|
||||
|
||||
## Check that routing works
|
||||
|
||||
After upgrading to UCP 3.0, you should check if all swarm services are still
|
||||
routable.
|
||||
|
||||
For services using HTTP:
|
||||
|
||||
```bash
|
||||
curl -vs http://<ucp-url>:<hrm-http-port>/ -H "Host: <service-hostname>"
|
||||
```
|
||||
|
||||
For services using HTTPS:
|
||||
|
||||
```bash
|
||||
curl -vs https://<ucp-url>:<hrm-https-port>
|
||||
```
|
||||
|
||||
After the upgrade, check that you can still use the same hostnames to access
|
||||
the swarm services.
|
||||
|
||||
## The ucp-interlock services are not running
|
||||
|
||||
After the upgrade to UCP 3.0, the following services should be running:
|
||||
|
||||
* `ucp-interlock`: monitors swarm workloads configured to use layer 7 routing.
|
||||
* `ucp-interlock-extension`: Helper service that generates the configuration for
|
||||
the `ucp-interlock-proxy` service.
|
||||
* `ucp-interlock-proxy`: A service that provides load balancing and proxying for
|
||||
swarm workloads.
|
||||
|
||||
To check if these services are running, use a client bundle with administrator
|
||||
permissions and run:
|
||||
|
||||
```bash
|
||||
docker ps --filter "name=ucp-interlock"
|
||||
```
|
||||
|
||||
* If the `ucp-interlock` service doesn't exist or is not running, something went
|
||||
wrong with the reconciliation step.
|
||||
* If this still doesn't work, it's possible that UCP is having problems creating
|
||||
the `com.docker.ucp.interlock.conf-1`, due to name conflicts. Make sure you
|
||||
don't have any configuration with the same name by running:
|
||||
```
|
||||
docker config ls --filter "name=com.docker.ucp.interlock"
|
||||
```
|
||||
* If either the `ucp-interlock-extension` or `ucp-interlock-proxy` services are
|
||||
not running, it's possible that there are port conflicts.
|
||||
As a workaround re-enable the layer 7 routing configuration from the
|
||||
[UCP settings page](deploy/index.md). Make sure the ports you choose are not
|
||||
being used by other services.
|
||||
|
||||
## Workarounds and clean-up
|
||||
|
||||
If you have any of the problems above, disable and enable the layer 7 routing
|
||||
setting on the [UCP settings page](index.md). This redeploys the
|
||||
services with their default configuration.
|
||||
|
||||
When doing that make sure you specify the same ports you were using for HRM,
|
||||
and that no other services are listening on those ports.
|
||||
|
||||
You should also check if the `ucp-hrm` service is running. If it is, you should
|
||||
stop it since it can conflict with the `ucp-interlock-proxy` service.
|
||||
|
||||
## Optionally remove labels
|
||||
|
||||
As part of the upgrade process UCP adds the
|
||||
[labels specific to the new layer 7 routing solution](../usage/labels-reference.md).
|
||||
|
||||
You can update your services to remove the old HRM labels, since they won't be
|
||||
used anymore.
|
||||
|
||||
## Optionally segregate control traffic
|
||||
|
||||
Interlock is designed so that all the control traffic is kept separate from
|
||||
the application traffic.
|
||||
|
||||
If before upgrading you had all your applications attached to the `ucp-hrm`
|
||||
network, after upgrading you can update your services to start using a
|
||||
dedicated network for routing that's not shared with other services.
|
||||
[Learn how to use a dedicated network](../usage/index.md).
|
||||
|
||||
If before upgrading you had a dedicate network to route traffic to each service,
|
||||
Interlock will continue using those dedicated networks. However the
|
||||
`ucp-interlock` will be attached to each of those networks. You can update
|
||||
the `ucp-interlock` service so that it is only connected to the `ucp-hrm` network.
|
||||
|
|
@ -1,130 +0,0 @@
|
|||
---
|
||||
title: Layer 7 routing upgrade
|
||||
description: Learn how to upgrade your existing layer 7 routing solution
|
||||
keywords: routing, proxy, hrm
|
||||
redirect_from:
|
||||
- /ee/ucp/interlock/upgrade/
|
||||
---
|
||||
# UCP upgrade process
|
||||
|
||||
The [HTTP routing mesh](/datacenter/ucp/2.2/guides/admin/configure/use-domain-names-to-access-services.md)
|
||||
functionality was redesigned in UCP 3.0 for greater security and flexibility.
|
||||
The functionality was also renamed to "layer 7 routing", to make it easier for
|
||||
new users to get started.
|
||||
|
||||
[Learn about the new layer 7 routing functionality](../index.md).
|
||||
|
||||
To route traffic to your service you apply specific labels to your swarm
|
||||
services, describing the hostname for the service and other configurations.
|
||||
Things work in the same way as they did with the HTTP routing mesh, with the
|
||||
only difference being that you use different labels.
|
||||
|
||||
You don't have to manually update your services. During the upgrade process to
|
||||
3.0, UCP updates the services to start using new labels.
|
||||
|
||||
This article describes the upgrade process for the routing component, so that
|
||||
you can troubleshoot UCP and your services, in case something goes wrong with
|
||||
the upgrade.
|
||||
|
||||
If you are using the HTTP routing mesh, and start an upgrade to UCP 3.0:
|
||||
|
||||
1. UCP starts a reconciliation process to ensure all internal components are
|
||||
deployed. As part of this, services using HRM labels are inspected.
|
||||
2. UCP creates the `com.docker.ucp.interlock.conf-<id>` based on HRM configurations.
|
||||
3. The HRM service is removed.
|
||||
4. The `ucp-interlock` service is deployed with the configuration created.
|
||||
5. The `ucp-interlock` service deploys the `ucp-interlock-extension` and
|
||||
`ucp-interlock-proxy-services`.
|
||||
|
||||
The only way to rollback from an upgrade is by restoring from a backup taken
|
||||
before the upgrade. If something goes wrong during the upgrade process, you
|
||||
need to troubleshoot the interlock services and your services, since the HRM
|
||||
service won't be running after the upgrade.
|
||||
|
||||
[Learn more about the interlock services and architecture](../architecture.md).
|
||||
|
||||
## Check that routing works
|
||||
|
||||
After upgrading to UCP 3.0, you should check if all swarm services are still
|
||||
routable.
|
||||
|
||||
For services using HTTP:
|
||||
|
||||
```bash
|
||||
curl -vs http://<ucp-url>:<hrm-http-port>/ -H "Host: <service-hostname>"
|
||||
```
|
||||
|
||||
For services using HTTPS:
|
||||
|
||||
```bash
|
||||
curl -vs https://<ucp-url>:<hrm-https-port>
|
||||
```
|
||||
|
||||
After the upgrade, check that you can still use the same hostnames to access
|
||||
the swarm services.
|
||||
|
||||
## The ucp-interlock services are not running
|
||||
|
||||
After the upgrade to UCP 3.0, the following services should be running:
|
||||
|
||||
* `ucp-interlock`: monitors swarm workloads configured to use layer 7 routing.
|
||||
* `ucp-interlock-extension`: Helper service that generates the configuration for
|
||||
the `ucp-interlock-proxy` service.
|
||||
* `ucp-interlock-proxy`: A service that provides load balancing and proxying for
|
||||
swarm workloads.
|
||||
|
||||
To check if these services are running, use a client bundle with administrator
|
||||
permissions and run:
|
||||
|
||||
```bash
|
||||
docker ps --filter "name=ucp-interlock"
|
||||
```
|
||||
|
||||
* If the `ucp-interlock` service doesn't exist or is not running, something went
|
||||
wrong with the reconciliation step.
|
||||
* If this still doesn't work, it's possible that UCP is having problems creating
|
||||
the `com.docker.ucp.interlock.conf-1`, due to name conflicts. Make sure you
|
||||
don't have any configuration with the same name by running:
|
||||
```
|
||||
docker config ls --filter "name=com.docker.ucp.interlock"
|
||||
```
|
||||
* If either the `ucp-interlock-extension` or `ucp-interlock-proxy` services are
|
||||
not running, it's possible that there are port conflicts.
|
||||
As a workaround re-enable the layer 7 routing configuration from the
|
||||
[UCP settings page](deploy/index.md). Make sure the ports you choose are not
|
||||
being used by other services.
|
||||
|
||||
## Workarounds and clean-up
|
||||
|
||||
If you have any of the problems above, disable and enable the layer 7 routing
|
||||
setting on the [UCP settings page](index.md). This redeploys the
|
||||
services with their default configuration.
|
||||
|
||||
When doing that make sure you specify the same ports you were using for HRM,
|
||||
and that no other services are listening on those ports.
|
||||
|
||||
You should also check if the `ucp-hrm` service is running. If it is, you should
|
||||
stop it since it can conflict with the `ucp-interlock-proxy` service.
|
||||
|
||||
## Optionally remove labels
|
||||
|
||||
As part of the upgrade process UCP adds the
|
||||
[labels specific to the new layer 7 routing solution](../usage/labels-reference.md).
|
||||
|
||||
You can update your services to remove the old HRM labels, since they won't be
|
||||
used anymore.
|
||||
|
||||
## Optionally segregate control traffic
|
||||
|
||||
Interlock is designed so that all the control traffic is kept separate from
|
||||
the application traffic.
|
||||
|
||||
If before upgrading you had all your applications attached to the `ucp-hrm`
|
||||
network, after upgrading you can update your services to start using a
|
||||
dedicated network for routing that's not shared with other services.
|
||||
[Learn how to use a dedicated network](../usage/index.md).
|
||||
|
||||
If before upgrading you had a dedicate network to route traffic to each service,
|
||||
Interlock will continue using those dedicated networks. However the
|
||||
`ucp-interlock` will be attached to each of those networks. You can update
|
||||
the `ucp-interlock` service so that it is only connected to the `ucp-hrm` network.
|
||||
Loading…
Reference in New Issue