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

Merge remote-tracking branch 'upstream/master'

This commit is contained in:
Alastair Smith 2019-06-24 11:22:13 -05:00
parent 4c40161382 d02cc3d6ff
commit 87db538a34
10 changed files with 59 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
_data/toc.yaml
View File

@ -3578,13 +3578,13 @@ manuals:
- sectiontitle: Docker Notary
section:
- path: /notary/getting_started/
title: Getting started with Notary
title: Get started with Notary
- path: /notary/advanced_usage/
title: Use the Notary client
- path: /notary/service_architecture/
title: Understand the service architecture
- path: /notary/running_a_service/
title: Running a Notary service
title: Run a Notary service
- path: /notary/changelog/
title: Notary changelog
- sectiontitle: Configuration files
@ -3602,13 +3602,13 @@ manuals:
- path: /registry/
title: Registry overview
- path: /registry/introduction/
title: Understanding the Registry
title: Understand the Registry
- path: /registry/deploying/
title: Deploy a registry server
- path: /registry/configuration/
title: Configuring a registry
title: Configure a registry
- path: /registry/notifications/
title: Working with notifications
title: Work with notifications
- sectiontitle: Recipes
section:
- path: /registry/recipes/

17
compose/aspnet-mssql-compose.md
View File

@ -6,15 +6,15 @@ title: "Quickstart: Compose and ASP.NET Core with SQL Server"
This quick-start guide demonstrates how to use Docker Engine on Linux and Docker
Compose to set up and run the sample ASP.NET Core application using the
[ASP.NET Core Build image](https://hub.docker.com/r/microsoft/aspnetcore-build/)
[.NET Core SDK image](hub.docker.com/_/microsoft-dotnet-core-sdk)
with the
[SQL Server on Linux image](https://hub.docker.com/r/microsoft/mssql-server-linux/).
[SQL Server on Linux image](https://hub.docker.com/_/microsoft-mssql-server).
You just need to have [Docker Engine](/install/index.md)
and [Docker Compose](/compose/install/) installed on your
platform of choice: Linux, Mac or Windows.
For this sample, we create a sample .NET Core Web Application using the
`aspnetcore-build` Docker image. After that, we create a `Dockerfile`,
`microsoft/dotnet:2.1-sdk` Docker image. After that, we create a `Dockerfile`,
configure this app to use our SQL Server database, and then create a
`docker-compose.yml` that defines the behavior of all of these components.
@ -29,12 +29,12 @@ configure this app to use our SQL Server database, and then create a
[Docker Desktop for Mac](/docker-for-mac/#/file-sharing), you
need to set up file sharing for the volume that you need to map.
1. Within your directory, use the `aspnetcore-build` Docker image to generate a
1. Within your directory, use the `dotnet:2.1-sdk` Docker image to generate a
sample web application within the container under the `/app` directory and
into your host machine in the working directory:
```bash
$ docker run -v ${PWD}:/app --workdir /app microsoft/aspnetcore-build:lts dotnet new mvc --auth Individual
$ docker run -v ${PWD}:/app --workdir /app microsoft/dotnet:2.1-sdk dotnet new mvc --auth Individual
```
> **Note**: If running in Docker Desktop for Windows, make sure to use Powershell
@ -43,7 +43,7 @@ configure this app to use our SQL Server database, and then create a
1. Create a `Dockerfile` within your app directory and add the following content:
```conf
FROM microsoft/aspnetcore-build:lts
FROM microsoft/dotnet:2.1-sdk
COPY . /app
WORKDIR /app
RUN ["dotnet", "restore"]
@ -54,7 +54,7 @@ configure this app to use our SQL Server database, and then create a
```
This file defines how to build the web app image. It uses the
[microsoft/aspnetcore-build](https://hub.docker.com/r/microsoft/aspnetcore-build/),
[.NET Core SDK image](https://hub.docker.com/_/microsoft-dotnet-core-sdk),
maps the volume with the generated code, restores the dependencies, builds the
project and exposes port 80. After that, it calls an `entrypoint` script
that we create in the next step.
@ -112,6 +112,9 @@ configure this app to use our SQL Server database, and then create a
This file defines the `web` and `db` micro-services, their relationship, the
ports they are using, and their specific environment variables.
> **Note**: You may receive an error if you choose the wrong Compose file
> version. Be sure to choose a verison that is compatible with your system.
1. Go to `Startup.cs` and locate the function called `ConfigureServices` (Hint:
it should be under line 42). Replace the entire function to use the following

1
ee/ucp/admin/configure/ucp-configuration-file.md
View File

@ -192,6 +192,7 @@ components. Assigning these values overrides the settings in a container's
| `metrics_scrape_interval` | no | Sets the interval for how frequently managers gather metrics from nodes in the cluster. |
| `metrics_disk_usage_interval` | no | Sets the interval for how frequently storage metrics are gathered. This operation can be expensive when large volumes are present. |
| `rethinkdb_cache_size` | no | Sets the size of the cache used by UCP's RethinkDB servers. The default is 1GB, but leaving this field empty or specifying `auto` instructs RethinkDB to determine a cache size automatically. |
| `exclude_server_identity_headers` | no | Set to `true` to disable the `X-Server-Ip` and `X-Server-Name` headers. |
| `cloud_provider` | no | Set the cloud provider for the kubernetes cluster. |
| `pod_cidr` | yes | Sets the subnet pool from which the IP for the Pod should be allocated from the CNI ipam plugin. Default is `192.168.0.0/16`. |
| `calico_mtu` | no | Set the MTU (maximum transmission unit) size for the Calico plugin. |

17
ee/ucp/admin/install/install-on-azure.md
View File

@ -72,7 +72,7 @@ to `0644` to ensure the container user has read access.
The following is an example template for `azure.json`. Replace `***` with real values, and leave the other
parameters as is.
```
```json
{
"cloud":"AzurePublicCloud",
"tenantId": "***",
@ -105,7 +105,7 @@ seperate resource group.
- `routeTableName` - If you have defined multiple Route tables within
an Azure subnet.
See [Kubernetes' azure.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/azure/azure.go) for more details on this configuration file.
See the [Kubernetes Azure Cloud Provider Config](https://github.com/kubernetes/cloud-provider-azure/blob/master/docs/cloud-provider-config.md) for more details on this configuration file.
## Considerations for IPAM Configuration
@ -230,7 +230,7 @@ If you have manually provisioned additional IP addresses for each Virtual
Machine, and want to disallow UCP from dynamically provisioning IP
addresses for you, then your UCP configuration file would be:
```
```bash
$ vi example-config-1
[cluster_config]
azure_ip_count = "0"
@ -239,11 +239,12 @@ $ vi example-config-1
If you want to reduce the IP addresses dynamically allocated from 128 to a
custom value, then your UCP configuration file would be:
```
```bash
$ vi example-config-2
[cluster_config]
azure_ip_count = "20" # This value may be different for your environment
```
See [Considerations for IPAM
Configuration](#considerations-for-ipam-configuration) to calculate an
appropriate value.
@ -254,18 +255,20 @@ To preload this configuration file prior to installing UCP:
2. Initiate a Swarm on that Virtual Machine.
```
```bash
$ docker swarm init
```
3. Upload the configuration file to the Swarm, by using a [Docker Swarm Config](/engine/swarm/configs/).
This Swarm Config will need to be named `com.docker.ucp.config`.
```
```bash
$ docker config create com.docker.ucp.config <local-configuration-file>
```
4. Check that the configuration has been loaded succesfully.
```
```bash
$ docker config list
ID NAME CREATED UPDATED
igca3q30jz9u3e6ecq1ckyofz com.docker.ucp.config 1 days ago 1 days ago

21
ee/ucp/authorization/index.md
View File

@ -99,11 +99,13 @@ resources.
## Secure Kubernetes defaults
For cluster security, only users and service accounts granted the `cluster-admin` ClusterRole for
all Kubernetes namespaces via a ClusterRoleBinding can deploy pods with privileged options. This prevents a
platform user from being able to bypass the Universal Control Plane Security Model.
For cluster security, only UCP admin users and service accounts that are
granted the `cluster-admin` ClusterRole for all Kubernetes namespaces via a
ClusterRoleBinding can deploy pods with privileged options. This prevents a
platform user from being able to bypass the Universal Control Plane Security
Model. These privileged options include:
These privileged options include:
Pods with any of the following defined in the Pod Specification:
- `PodSpec.hostIPC` - Prevents a user from deploying a pod in the host's IPC
Namespace.
@ -121,6 +123,17 @@ These privileged options include:
- `Volume.hostPath` - Prevents a user from mounting a path from the host into
the container. This could be a file, a directory, or even the Docker Socket.
Persistent Volumes using the following storage classes:
- `Local` - Prevents a user from creating a persistent volume with the
[Local Storage
Class](https://kubernetes.io/docs/concepts/storage/volumes/#local). The
Local storage class allows a user to mount directorys from the host into a
pod. This could be a file, a directory, or even the Docker Socket.
> Note: If an Admin has created a persistent volume with the local storage
> class, a non-admin could consume this via a persitent volume claim.
If a user without a cluster admin role tries to deploy a pod with any of these
privileged options, an error similar to the following example is displayed:

8
ee/ucp/release-notes.md
View File

@ -393,7 +393,9 @@ https://github.com/kubernetes/kubernetes/pull/67432
### Bug Fixes
* Fixed system hang following UCP backup and docker daemon shutdown. (docker/escalation#841)
* Non-admin users can no longer create `PersistentVolumes` that mount host directories. (docker/orca#15936)
* Non-admin users can no longer create `PersistentVolumes` using the `Local`
Storage Class, as this allowed non-admins to by pass security controls and
mount host directories. (docker/orca#15936)
* Added support for the limit arg in `docker ps`. (docker/orca#15812)
* Fixed an issue with ucp-proxy health check. (docker/orca#15814, docker/orca#15813, docker/orca#16021, docker/orca#15811)
* Fixed an issue with manual creation of a **ClusterRoleBinding** or **RoleBinding** for `User` or `Group` subjects requiring the ID of the user, organization, or team. (docker/orca#14935)
@ -605,7 +607,9 @@ The following features are deprecated in UCP 3.1.
### Bug fixes
* Upgrading Interlock now also upgrades interlock proxy and interlock extension. (docker/escalation/871)
* Non-admin users can no longer create `PersistentVolumes` that mount host directories. (#15936)
* Non-admin users can no longer create `PersistentVolumes` using the `Local`
Storage Class, as this allowed non-admins to by pass security controls and
mount host directories. (docker/orca#15936)
* Added support for the limit arg in `docker ps`. (#15812)
### Known issue

4
engine/index.md
View File

@ -98,8 +98,8 @@ on the separate [Release Notes page](/release-notes)
As changes are made to Docker there may be times when existing features
need to be removed or replaced with newer features. Before an existing
feature is removed it is labeled as "deprecated" within the documentation
and remains in Docker for at least 3 stable releases. After that time it may be
removed.
and remains in Docker for at least 3 stable releases unless specified
explicitly otherwise. After that time it may be removed.
Users are expected to take note of the list of deprecated features each
release and plan their migration away from those features, and (if applicable)

4
install/linux/linux-postinstall.md
View File

@ -120,6 +120,10 @@ For information about the different storage engines, see
The default storage engine and the list of supported storage engines depend on
your host's Linux distribution and available kernel drivers.
## Configure default logging driver
Docker provides the [capability](/config/containers/logging/) to collect and view log data from all containers running on a host via a series of logging drivers. The default logging driver, `json-file`, writes log data to JSON-formatted files on the host filesystem. Over time, these log files expand in size, leading to potential exhaustion of disk resources. To alleviate such issues, either configure an alternative logging driver such as Splunk or Syslog, or [set up log rotation](/config/containers/logging/configure/#configure-the-default-logging-driver) for the default driver. If you configure an alternative logging driver, see [Use `docker logs` to read container logs for remote logging drivers](/config/containers/logging/dual-logging/).
## Configure where the Docker daemon listens for connections
By default, the Docker daemon listens for connections on a UNIX socket to accept requests from local clients. It is possible to allow Docker to accept requests from remote hosts by configuring it to listen on an IP address and port as well as the UNIX socket. For more detailed information on this configuration option take a look at "Bind Docker to another host/port or a unix socket" section of the [Docker CLI Reference](https://docs.docker.com/engine/reference/commandline/dockerd/) article.

2
reference/dtr/2.6/cli/emergency-repair.md
View File

@ -26,7 +26,7 @@ There are three steps you can take to recover an unhealthy DTR cluster:
2. If the majority of replicas are unhealthy, use this command to revert your
cluster to a single DTR replica.
3. If you can't repair your cluster to a single replica, you'll have to
restore from an existing backup, using the `restore` command.
restore from an existing backup, using the [`restore`](./restore/) command.
When you run this command, a DTR replica of your choice is repaired and
turned into the only replica in the whole DTR cluster.

5
reference/dtr/2.6/cli/restore.md
View File

@ -26,8 +26,9 @@ There are three steps you can take to recover an unhealthy DTR cluster:
1. If the majority of replicas are healthy, remove the unhealthy nodes from
the cluster, and join new nodes for high availability.
2. If the majority of replicas are unhealthy, use this command to revert your
cluster to a single DTR replica.
2. If the majority of replicas are unhealthy, use the
[`emergency-repair`](./emergency-repair/) command to revert your cluster to
a single DTR replica.
3. If you can't repair your cluster to a single replica, you'll have to
restore from an existing backup, using the `restore` command.