mirror of https://github.com/docker/docs.git
Clean up crud from pull request
This commit is contained in:
Maria Bermudez
parent
fc1e83322b
commit
c6a83b1846
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
<<<<<<< HEAD
|
||||
description: Describes how to use the local logging driver.
|
||||
keywords: local, docker, logging, driver
|
||||
redirect_from:
|
||||
|
|
@ -19,42 +18,22 @@ uses automatic compression to reduce the size on disk.
|
|||
> file-format and storage mechanism are designed to be exclusively accessed by
|
||||
> the Docker daemon, and should not be used by external tools as the
|
||||
> implementation may change in future releases.
|
||||
=======
|
||||
description: Describes how to use the local binary (Protobuf) logging driver.
|
||||
keywords: local, protobuf, docker, logging, driver
|
||||
redirect_from:
|
||||
- /engine/reference/logging/local/
|
||||
- /engine/admin/logging/local/
|
||||
title: local binary file Protobuf logging driver
|
||||
---
|
||||
|
||||
This `log-driver` writes to `local` binary files using Protobuf [Protocol Buffers](https://en.wikipedia.org/wiki/Protocol_Buffers)
|
||||
>>>>>>> Sync forked amberjack branch with docs-private (#1068)
|
||||
|
||||
## Usage
|
||||
|
||||
To use the `local` driver as the default logging driver, set the `log-driver`
|
||||
and `log-opt` keys to appropriate values in the `daemon.json` file, which is
|
||||
located in `/etc/docker/` on Linux hosts or
|
||||
<<<<<<< HEAD
|
||||
`C:\ProgramData\docker\config\daemon.json` on Windows Server. For more about
|
||||
configuring Docker using `daemon.json`, see
|
||||
[daemon.json](/engine/reference/commandline/dockerd.md#daemon-configuration-file).
|
||||
|
||||
The following example sets the log driver to `local` and sets the `max-size`
|
||||
option.
|
||||
=======
|
||||
`C:\ProgramData\docker\config\daemon.json` on Windows Server. For more information about
|
||||
configuring Docker using `daemon.json`, see
|
||||
[daemon.json](/engine/reference/commandline/dockerd.md#daemon-configuration-file).
|
||||
|
||||
The following example sets the log driver to `local`.
|
||||
>>>>>>> Sync forked amberjack branch with docs-private (#1068)
|
||||
|
||||
```json
|
||||
{
|
||||
"log-driver": "local",
|
||||
<<<<<<< HEAD
|
||||
"log-opts": {
|
||||
"max-size": "10m"
|
||||
}
|
||||
|
|
@ -62,30 +41,13 @@ The following example sets the log driver to `local`.
|
|||
```
|
||||
|
||||
Restart Docker for the changes to take effect for newly created containers. Existing containers do not use the new logging configuration.
|
||||
=======
|
||||
"log-opts": {}
|
||||
}
|
||||
```
|
||||
|
||||
> **Note**: `log-opt` configuration options in the `daemon.json` configuration
|
||||
> file must be provided as strings. Boolean and numeric values (such as the value
|
||||
> for `max-file` in the example above) must therefore be enclosed in quotes (`"`).
|
||||
|
||||
Restart Docker for the changes to take effect for newly created containers.
|
||||
|
||||
Existing containers will not use the new logging configuration.
|
||||
>>>>>>> Sync forked amberjack branch with docs-private (#1068)
|
||||
|
||||
You can set the logging driver for a specific container by using the
|
||||
`--log-driver` flag to `docker container create` or `docker run`:
|
||||
|
||||
```bash
|
||||
$ docker run \
|
||||
<<<<<<< HEAD
|
||||
--log-driver local --log-opt max-size=10m \
|
||||
=======
|
||||
--log-driver local --log-opt compress="false" \
|
||||
>>>>>>> Sync forked amberjack branch with docs-private (#1068)
|
||||
alpine echo hello world
|
||||
```
|
||||
|
||||
|
|
@ -95,7 +57,6 @@ The `local` logging driver supports the following logging options:
|
|||
|
||||
| Option | Description | Example value |
|
||||
|:------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------|
|
||||
<<<<<<< HEAD
|
||||
| `max-size` | The maximum size of the log before it is rolled. A positive integer plus a modifier representing the unit of measure (`k`, `m`, or `g`). Defaults to 20m. | `--log-opt max-size=10m` |
|
||||
| `max-file` | The maximum number of log files that can be present. If rolling the logs creates excess files, the oldest file is removed. **Only effective when `max-size` is also set.** A positive integer. Defaults to 5. | `--log-opt max-file=3` |
|
||||
| `compress` | Toggle compression of rotated log files. Enabled by default. | `--log-opt compress=false` |
|
||||
|
|
@ -108,8 +69,3 @@ files no larger than 10 megabytes each.
|
|||
```bash
|
||||
$ docker run -it --log-opt max-size=10m --log-opt max-file=3 alpine ash
|
||||
```
|
||||
=======
|
||||
| `max-size` | The maximum size of each binary log file before rotation. A positive integer plus a modifier representing the unit of measure (`k`, `m`, or `g`). Defaults to `20m`. | `--log-opt max-size=10m` |
|
||||
| `max-file` | The maximum number of binary log files. If rotating the logs creates an excess file, the oldest file is removed. **Only effective when `max-size` is also set.** A positive integer. Defaults to `5`. | `--log-opt max-file=5` |
|
||||
| `compress` | Whether or not the binary files should be compressed. Defaults to `true` | `--log-opt compress=true` |
|
||||
>>>>>>> Sync forked amberjack branch with docs-private (#1068)
|
||||
|
|
|
|||
|
|
@ -4,11 +4,7 @@ description: Docker Desktop Enterprise Application Designer
|
|||
keywords: Docker EE, Windows, Mac, Docker Desktop, Enterprise, templates, designer
|
||||
---
|
||||
|
||||
<<<<<<< HEAD
|
||||
## Overview
|
||||
=======
|
||||
# Overview
|
||||
>>>>>>> 1013: Move desktop ent content to docs-private
|
||||
|
||||
The Application Designer helps Docker developers quickly create new
|
||||
Docker apps using a library of templates. To start the Application
|
||||
|
|
|
|||
|
|
@ -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