mirror of https://github.com/docker/docs.git
Synced Docs Public Master with Docs Private Master
This commit is contained in:
ollypom
commit
c39ba281fd
|
|
@ -135,14 +135,14 @@ defaults:
|
|||
hide_from_sitemap: true
|
||||
dtr_org: "docker"
|
||||
dtr_repo: "dtr"
|
||||
dtr_version: "2.5.12"
|
||||
dtr_version: "2.5.13"
|
||||
- scope:
|
||||
path: "datacenter/dtr/2.4"
|
||||
values:
|
||||
hide_from_sitemap: true
|
||||
dtr_org: "docker"
|
||||
dtr_repo: "dtr"
|
||||
dtr_version: "2.4.12"
|
||||
dtr_version: "2.4.13"
|
||||
- scope:
|
||||
path: "datacenter/dtr/2.3"
|
||||
values:
|
||||
|
|
@ -193,14 +193,14 @@ defaults:
|
|||
hide_from_sitemap: true
|
||||
ucp_org: "docker"
|
||||
ucp_repo: "ucp"
|
||||
ucp_version: "3.0.12"
|
||||
ucp_version: "3.0.13"
|
||||
- scope:
|
||||
path: "datacenter/ucp/2.2"
|
||||
values:
|
||||
hide_from_sitemap: true
|
||||
ucp_org: "docker"
|
||||
ucp_repo: "ucp"
|
||||
ucp_version: "2.2.19"
|
||||
ucp_version: "2.2.20"
|
||||
- scope:
|
||||
path: "datacenter/ucp/2.1"
|
||||
values:
|
||||
|
|
|
|||
|
|
@ -6,6 +6,14 @@
|
|||
- product: "ucp"
|
||||
version: "3.1"
|
||||
tar-files:
|
||||
- description: "3.1.9 Linux"
|
||||
url: https://packages.docker.com/caas/ucp_images_3.1.9.tar.gz
|
||||
- description: "3.1.9 Windows Server 2016 LTSC"
|
||||
url: https://packages.docker.com/caas/ucp_images_win_2016_3.1.9.tar.gz
|
||||
- description: "3.1.9 Windows Server 1803"
|
||||
url: https://packages.docker.com/caas/ucp_images_win_1803_3.1.9.tar.gz
|
||||
- description: "3.1.9 Windows Server 2019 LTSC"
|
||||
url: https://packages.docker.com/caas/ucp_images_win_2019_3.1.9.tar.gz
|
||||
- description: "3.1.8 Linux"
|
||||
url: https://packages.docker.com/caas/ucp_images_3.1.8.tar.gz
|
||||
- description: "3.1.8 Windows Server 2016 LTSC"
|
||||
|
|
@ -91,6 +99,14 @@
|
|||
- product: "ucp"
|
||||
version: "3.0"
|
||||
tar-files:
|
||||
- description: "3.0.13 Linux"
|
||||
url: https://packages.docker.com/caas/ucp_images_3.0.13.tar.gz
|
||||
- description: "3.0.13 IBM Z"
|
||||
url: https://packages.docker.com/caas/ucp_images_s390x_3.0.13.tar.gz
|
||||
- description: "3.0.13 Windows Server 2016 LTSC"
|
||||
url: https://packages.docker.com/caas/ucp_images_win_2016_3.0.13.tar.gz
|
||||
- description: "3.0.13 Windows Server 1803"
|
||||
url: https://packages.docker.com/caas/ucp_images_win_1803_3.0.13.tar.gz
|
||||
- description: "3.0.12 Linux"
|
||||
url: https://packages.docker.com/caas/ucp_images_3.0.12.tar.gz
|
||||
- description: "3.0.12 IBM Z"
|
||||
|
|
@ -202,12 +218,18 @@
|
|||
- product: "ucp"
|
||||
version: "2.2"
|
||||
tar-files:
|
||||
- description: "2.2.20 Linux"
|
||||
url: https://packages.docker.com/caas/ucp_images_2.2.20.tar.gz
|
||||
- description: "2.2.20 IBM Z"
|
||||
url: https://packages.docker.com/caas/ucp_images_s390x_2.2.20.tar.gz
|
||||
- description: "2.2.20 Windows"
|
||||
url: https://packages.docker.com/caas/ucp_images_win_2.2.20.tar.gz
|
||||
- description: "2.2.19 Linux"
|
||||
url: https://packages.docker.com/caas/ucp_images_2.2.19.tar.gz
|
||||
- description: "2.2.19 IBM Z"
|
||||
url: https://packages.docker.com/caas/ucp_images_s390x_2.2.19.tar.gz
|
||||
- description: "2.2.19 Windows"
|
||||
url: https://packages.docker.com/caas/ucp_images_win_2.2.19.tar.gz
|
||||
url: https://packages.docker.com/caas/ucp_images_win_2.2.19.tar.gz
|
||||
- description: "2.2.18 Linux"
|
||||
url: https://packages.docker.com/caas/ucp_images_2.2.18.tar.gz
|
||||
- description: "2.2.18 IBM Z"
|
||||
|
|
@ -318,6 +340,8 @@
|
|||
- product: "dtr"
|
||||
version: "2.6"
|
||||
tar-files:
|
||||
- description: "DTR 2.6.8 Linux x86"
|
||||
url: https://packages.docker.com/caas/dtr_images_2.6.8.tar.gz
|
||||
- description: "DTR 2.6.7 Linux x86"
|
||||
url: https://packages.docker.com/caas/dtr_images_2.6.7.tar.gz
|
||||
- description: "DTR 2.6.6 Linux x86"
|
||||
|
|
@ -337,6 +361,8 @@
|
|||
- product: "dtr"
|
||||
version: "2.5"
|
||||
tar-files:
|
||||
- description: "DTR 2.5.13 Linux x86"
|
||||
url: https://packages.docker.com/caas/dtr_images_2.5.13.tar.gz
|
||||
- description: "DTR 2.5.12 Linux x86"
|
||||
url: https://packages.docker.com/caas/dtr_images_2.5.12.tar.gz
|
||||
- description: "DTR 2.5.11 Linux x86"
|
||||
|
|
@ -364,6 +390,8 @@
|
|||
- product: "dtr"
|
||||
version: "2.4"
|
||||
tar-files:
|
||||
- description: "DTR 2.4.13 Linux x86"
|
||||
url: https://packages.docker.com/caas/dtr_images_2.4.13.tar.gz
|
||||
- description: "DTR 2.4.12 Linux x86"
|
||||
url: https://packages.docker.com/caas/dtr_images_2.4.12.tar.gz
|
||||
- description: "DTR 2.4.11 Linux x86"
|
||||
|
|
|
|||
|
|
@ -1248,7 +1248,7 @@ samples:
|
|||
- path: /engine/examples/apt-cacher-ng/
|
||||
title: apt-cacher-ng
|
||||
- path: /engine/examples/dotnetcore/
|
||||
title: .NET Core application
|
||||
title: ASP.NET Core application
|
||||
- path: /compose/aspnet-mssql-compose/
|
||||
title: ASP.NET Core + SQL Server on Linux
|
||||
- path: /engine/examples/couchdb_data_volumes/
|
||||
|
|
|
|||
|
|
@ -88,14 +88,14 @@ bash _scripts/fetch-upstream-resources.sh -l
|
|||
# /docker-hub/
|
||||
# These rely on _layout/archive-redirect.html
|
||||
|
||||
only_live_contents=("samples" "docker-id" "docker-cloud" "docker-hub" "docker-store")
|
||||
only_live_contents=("samples" "docker-id" "docker-hub")
|
||||
|
||||
for dir in "${only_live_contents[@]}"; do
|
||||
echo "Replacing contents of $dir with a redirect stub"
|
||||
# Figure out the title, which should be title case with spaces instead of dashes
|
||||
dir_title=$(echo $dir | sed 's/-/\ /g' | awk '{for(i=1;i<=NF;i++){ $i=toupper(substr($i,1,1)) substr($i,2) }}1')
|
||||
echo "dir_title is ${dir_title}"
|
||||
rm -Rf \"$dir\"
|
||||
rm -Rf $dir/*
|
||||
cat << EOF > "$dir/index.html"
|
||||
---
|
||||
layout: archive-redirect
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ How long to wait between retries. Defaults to 1 second.
|
|||
|
||||
### fluentd-max-retries
|
||||
|
||||
The maximum number of retries. Defaults to `10`.
|
||||
The maximum number of retries. Defaults to `4294967295` (2**32 - 1).
|
||||
|
||||
### fluentd-sub-second-precision
|
||||
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ To accomplish this, set the following flags in the `daemon.json` file:
|
|||
```none
|
||||
{
|
||||
"data-root": "/mnt/docker-data",
|
||||
"storage-driver": "overlay"
|
||||
"storage-driver": "overlay2"
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ description: Learn how to route traffic to your Kubernetes workloads in
|
|||
Docker Enterprise Edition.
|
||||
keywords: UCP, Kubernetes, ingress, routing
|
||||
redirect_from:
|
||||
- /ee/ucp/kubernetes/deploy-ingress-controller/
|
||||
---
|
||||
|
||||
When you deploy a Kubernetes application, you may want to make it accessible
|
||||
|
|
|
|||
|
|
@ -867,7 +867,7 @@ like `RUN groupadd -r postgres && useradd --no-log-init -r -g postgres postgres`
|
|||
Avoid installing or using `sudo` as it has unpredictable TTY and
|
||||
signal-forwarding behavior that can cause problems. If you absolutely need
|
||||
functionality similar to `sudo`, such as initializing the daemon as `root` but
|
||||
running it as non-`root`), consider using ["gosu"](https://github.com/tianon/gosu).
|
||||
running it as non-`root`, consider using [“gosu”](https://github.com/tianon/gosu).
|
||||
|
||||
Lastly, to reduce layers and complexity, avoid switching `USER` back and forth
|
||||
frequently.
|
||||
|
|
@ -896,7 +896,7 @@ A Docker build executes `ONBUILD` commands before any command in a child
|
|||
`ONBUILD` is useful for images that are going to be built `FROM` a given
|
||||
image. For example, you would use `ONBUILD` for a language stack image that
|
||||
builds arbitrary user software written in that language within the
|
||||
`Dockerfile`, as you can see in [Ruby’s `ONBUILD` variants](https://github.com/docker-library/ruby/blob/master/2.4/jessie/onbuild/Dockerfile).
|
||||
`Dockerfile`, as you can see in [Ruby’s `ONBUILD` variants](https://github.com/docker-library/ruby/blob/c43fef8a60cea31eb9e7d960a076d633cb62ba8d/2.4/jessie/onbuild/Dockerfile).
|
||||
|
||||
Images built from `ONBUILD` should get a separate tag, for example:
|
||||
`ruby:1.9-onbuild` or `ruby:2.0-onbuild`.
|
||||
|
|
|
|||
|
|
@ -301,7 +301,7 @@ Docker Desktop for Windows requires a Hyper-V as well as the Hyper-V Module for
|
|||
Powershell to be installed and enabled. The Docker Desktop for Windows installer enables
|
||||
it for you.
|
||||
|
||||
Docker Desktop for Windows also needs two CPU hardware features to use Hyper-V: Virtualization and SLAT (Second Level Adress Translation), which is also called RVI (Rapid Virtualization Indexing).
|
||||
Docker Desktop for Windows also needs two CPU hardware features to use Hyper-V: Virtualization and SLAT (Second Level Address Translation), which is also called RVI (Rapid Virtualization Indexing).
|
||||
On some systems, Virtualization needs to be enabled in the BIOS. The steps required are vendor-specific, but typically the BIOS option is called `Virtualization Technology (VTx)` or something similar. Run the command `systeminfo` to check all required Hyper-V features. See [Pre-requisites for Hyper-V on Windows 10](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/hyper-v-requirements) for more details.
|
||||
|
||||
To install Hyper-V manually, see [Install Hyper-V on Windows 10](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install). A reboot is *required* after installation. If you install Hyper-V without rebooting, Docker Desktop for Windows does not work correctly.
|
||||
|
|
|
|||
|
|
@ -77,6 +77,33 @@ to upgrade your installation to the latest release.
|
|||
|
||||
# Version 2.6
|
||||
|
||||
## 2.6.8
|
||||
(2019-7-17)
|
||||
|
||||
### Bug fixes
|
||||
|
||||
* Fixed a bug where non-admin user repository pagination was broken. (docker/dhe-deploy #10464)
|
||||
* Fixed a bug where the `dockersearch` API returned incorrect results when the search query ended in a digit. (docker/dhe-deploy #10434)
|
||||
|
||||
### Security
|
||||
|
||||
* Bumped the Golang version for DTR to `1.12.7`. (docker/dhe-deploy #10460)
|
||||
* Bumped the Alpine version of the base images to `3.9.4`. (docker/dhe-deploy #10460)
|
||||
|
||||
### Known issues
|
||||
|
||||
* Docker Engine Enterprise Edition (Docker EE) Upgrade
|
||||
* There are [important changes to the upgrade process](/ee/upgrade) that, if not correctly followed, can have impact on the availability of applications running on the Swarm during upgrades. These constraints impact any upgrades coming from any version before `18.09` to version `18.09` or greater. For DTR-specific changes, see [2.5 to 2.6 upgrade](/ee/dtr/admin/upgrade/#25-to-26-upgrade).
|
||||
* Web Interface
|
||||
* Poll mirroring for Docker plugins such as `docker/imagefs` is currently broken. (docker/dhe-deploy #9490)
|
||||
* When viewing the details of a scanned image tag, the header may display a different vulnerability count from the layer details. (docker/dhe-deploy #9474)
|
||||
* In order to set a tag limit for pruning purposes, immutability must be turned off for a repository. This limitation is not clear in the **Repository Settings** view. (docker/dhe-deploy #9554)
|
||||
* Webhooks
|
||||
* When configured for "Image promoted from repository" events, a webhook notification is triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
* HTTPS webhooks do not go through HTTPS proxy when configured. (docker/dhe-deploy #9492)
|
||||
* System
|
||||
* When upgrading from `2.5` to `2.6`, the system will run a `metadatastoremigration` job after a successful upgrade. This is necessary for online garbage collection. If the three system attempts fail, you will have to retrigger the `metadatastoremigration` job manually. [Learn about manual metadata store migration](/ee/dtr/admin/upgrade/#25-to-26-upgrade).
|
||||
|
||||
## 2.6.7
|
||||
(2019-6-27)
|
||||
|
||||
|
|
@ -361,6 +388,45 @@ to upgrade your installation to the latest release.
|
|||
>
|
||||
> Upgrade path from 2.5.x to 2.6: Upgrade directly to 2.6.4.
|
||||
|
||||
## 2.5.13
|
||||
(2019-07-17)
|
||||
|
||||
### Bug fix
|
||||
|
||||
* Fixed a bug where the dockersearch API returned incorrect results when the search query ended in a digit. (docker/dhe-deploy #10435)
|
||||
|
||||
### Security
|
||||
|
||||
* Bumped the Golang version for DTR to `1.12.7`. (docker/dhe-deploy#10463)
|
||||
* Bumped the Alpine version of the base images to `3.9.4`. (docker/dhe-deploy#10463)
|
||||
|
||||
### Known issues
|
||||
|
||||
* Web Interface
|
||||
* The web interface shows "This repository has no tags" in repositories where tags
|
||||
have long names. As a workaround, reduce the length of the name for the
|
||||
repository and tag.
|
||||
* When deleting a repository with signed images, the DTR web interface no longer
|
||||
shows instructions on how to delete trust data.
|
||||
* There's no web interface support to update mirroring policies when rotating the TLS
|
||||
certificates used by DTR. Use the API instead.
|
||||
* The web interface for promotion policies is currently broken if you have a large number
|
||||
of repositories.
|
||||
* Clicking "Save & Apply" on a promotion policy doesn't work.
|
||||
* Webhooks
|
||||
* There is no webhook event for when an image is pulled.
|
||||
* HTTPS webhooks do not go through HTTPS proxy when configured. (docker/dhe-deploy #9492)
|
||||
* When configured for "Image promoted from repository" events, a webhook notification will be triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
* Online garbage collection
|
||||
* The events API won't report events when tags and manifests are deleted.
|
||||
* The events API won't report blobs deleted by the garbage collection job.
|
||||
* Docker EE Advanced features
|
||||
* Scanning any new push after metadatastore migration will not yet work.
|
||||
* Pushes to repos with promotion policies (repo as source) are broken when an
|
||||
image has a layer over 100MB.
|
||||
* On upgrade the scanningstore container may restart with this error message:
|
||||
FATAL: database files are incompatible with server
|
||||
|
||||
## 2.5.12
|
||||
(2019-06-27)
|
||||
|
||||
|
|
@ -905,9 +971,22 @@ specify `--log-protocol`.
|
|||
> **Important DTR Upgrade Information**
|
||||
> If you have manifest lists enabled on any of your repositories:
|
||||
>
|
||||
> Upgrade path from 2.4.x to 2.5: Do not opt into garbage collection, or directly upgrade to 2.5.10 if you need to opt into > garbage collection.
|
||||
> Upgrade path from 2.4.x to 2.5: Do not opt into garbage collection, or directly upgrade to 2.5.10 if you need to opt into garbage collection.
|
||||
> Upgrade path from 2.5.x to 2.6: Upgrade directly to 2.6.4.
|
||||
|
||||
## 2.4.13
|
||||
|
||||
(2019-07-17)
|
||||
|
||||
### Bug fix
|
||||
|
||||
* Fixed a bug where duplicate scan jobs were causing scans to never exit. (docker/dhe-deploy#10314)
|
||||
|
||||
### Security
|
||||
|
||||
* Bumped the Golang version for DTR to `1.12.7`. (docker/dhe-deploy#10461)
|
||||
* Bumped the Alpine version of the base images to `3.9.4`. (docker/dhe-deploy#10461)
|
||||
|
||||
## 2.4.12
|
||||
|
||||
(2019-05-06)
|
||||
|
|
|
|||
|
|
@ -13,18 +13,20 @@ green-check: '{: style="height: 14px; mar
|
|||
install-prefix-ee: '/install/linux/docker-ee'
|
||||
---
|
||||
|
||||
Docker Enterprise is designed for enterprise development as well as IT teams who build, ship, and run business-critical
|
||||
applications in production and at scale. Docker Enterprise is integrated, certified,
|
||||
Docker Enterprise is designed for enterprise development as well as IT teams who
|
||||
build, ship, and run business-critical applications
|
||||
in production and at scale. Docker Enterprise is integrated, certified,
|
||||
and supported to provide enterprises with the most secure container platform
|
||||
in the industry. For more info about Docker Enterprise, including purchasing
|
||||
options, see [Docker Enterprise](https://www.docker.com/enterprise-edition/).
|
||||
|
||||
> Compatibility Matrix
|
||||
>
|
||||
> Refer to the [Compatibility Matrix](https://success.docker.com/article/compatibility-matrix) for the latest list of supported platforms.
|
||||
> Refer to the [Compatibility Matrix](https://success.docker.com/article/compatibility-matrix)
|
||||
> for the latest list of supported platforms.
|
||||
{: .important}
|
||||
|
||||
## Docker EE tiers
|
||||
## Docker Enterprise tiers
|
||||
|
||||
{% include docker_ee.md %}
|
||||
|
||||
|
|
@ -47,20 +49,23 @@ maintenance cycles for patches for up to 24 months.
|
|||
|
||||
### New Licensing for Docker Enterprise
|
||||
|
||||
In version 18.09, the Docker Enterprise --- Engine is aware of the license applied on the system. The
|
||||
license summary is available in the `docker info` output on standalone or manager nodes.
|
||||
In version 18.09, the Docker Enterprise --- Engine is aware of the license
|
||||
applied on the system. The license summary is available in the `docker info`
|
||||
output on standalone or manager nodes.
|
||||
|
||||
For EE platform customers, when you license UCP, this same license is applied to the underlying
|
||||
engines in the cluster. Docker recommends platform customers use UCP to manage their license.
|
||||
For EE platform customers, when you license UCP, this same license is applied to
|
||||
the underlying engines in the cluster. Docker recommends platform customers use
|
||||
UCP to manage their license.
|
||||
|
||||
Standalone EE engines can be licensed using `docker engine activate`.
|
||||
|
||||
Offline activation of standalone EE engines can be performed by downloading the license and
|
||||
using the command `docker engine activate --license filename.lic`.
|
||||
Offline activation of standalone EE engines can be performed by downloading the
|
||||
license and using the command `docker engine activate --license filename.lic`.
|
||||
|
||||
Additionally, Docker is now distributing the CLI as a separate installation package.
|
||||
This gives Enterprise users the ability to install as many CLI packages as needed
|
||||
without using the Engine node licenses for client-only systems.
|
||||
Additionally, Docker is now distributing the CLI as a separate installation
|
||||
package. This gives Enterprise users the ability to install as many CLI
|
||||
packages as needed without using the Engine node licenses for client-only
|
||||
systems.
|
||||
|
||||
[Learn more about Docker Enterprise](/ee/index.md).
|
||||
|
||||
|
|
@ -91,22 +96,21 @@ and third-party ecosystem solution briefs.
|
|||
Each Docker Enterprise release is supported and maintained for 24 months, and
|
||||
receives security and critical bug fixes during this period.
|
||||
|
||||
The Docker API version is independent of the Docker platform version. We maintain
|
||||
careful API backward compatibility and deprecate APIs and features slowly and
|
||||
conservatively. We remove features after deprecating them for a period of
|
||||
three stable releases. Docker 1.13 introduced improved interoperability
|
||||
between clients and servers using different API versions, including dynamic
|
||||
feature negotiation.
|
||||
The Docker API version is independent of the Docker platform version. We
|
||||
maintain careful API backward compatibility and deprecate APIs and features
|
||||
slowly and conservatively. We remove features after deprecating them for a
|
||||
period of three stable releases. Docker 1.13 introduced improved
|
||||
interoperability between clients and servers using different API versions,
|
||||
including dynamic feature negotiation.
|
||||
|
||||
## Upgrades and support
|
||||
|
||||
If you're a Docker DDC or CS Engine customer, you don't need to upgrade to
|
||||
Docker Enterprise to continue to get support. We will continue to support customers
|
||||
with valid subscriptions whether the subscription covers Docker EE or
|
||||
Commercially Supported Docker. You can choose to stay with your current
|
||||
deployed version, or you can upgrade to the latest Docker EE version. For
|
||||
more info, see [Scope of Coverage and Maintenance
|
||||
Lifecycle](https://success.docker.com/Policies/Scope_of_Support).
|
||||
Docker Enterprise to continue to get support. We will continue to support
|
||||
customers with valid subscriptions whether the subscription covers Docker
|
||||
Enterprise or Commercially Supported Docker. You can choose to stay with your
|
||||
current deployed version, or you can upgrade to the latest Docker Enterprise
|
||||
version. For more info, see [Scope of Coverage and Maintenance Lifecycle](https://success.docker.com/Policies/Scope_of_Support).
|
||||
|
||||
## Where to go next
|
||||
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ level.
|
|||
|
||||
Enabling UCP audit logging via the UCP Configuration file can be done before
|
||||
or after a UCP installation. Following the UCP Configuration file documentation
|
||||
[here](../ucp-configuration-file/).
|
||||
[here](./ucp-configuration-file/).
|
||||
|
||||
The section of the UCP configuration file that controls UCP auditing logging is:
|
||||
|
||||
|
|
|
|||
|
|
@ -77,11 +77,11 @@ docker container run --rm {{ page.ucp_org }}/{{ page.ucp_repo }}:{{ page.ucp_ver
|
|||
|
||||
### auth.sessions
|
||||
|
||||
| Parameter | Required | Description |
|
||||
|:----------------------------|:---------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `lifetime_minutes` | no | The initial session lifetime, in minutes. The default is 4320, which is 72 hours. |
|
||||
| `renewal_threshold_minutes` | no | The length of time, in minutes, before the expiration of a session where, if used, a session will be extended by the current configured lifetime from then. A zero value disables session extension. The default is 1440, which is 24 hours. |
|
||||
| `per_user_limit` | no | The maximum number of sessions that a user can have active simultaneously. If creating a new session would put a user over this limit, the least recently used session will be deleted. A value of zero disables limiting the number of sessions that users may have. The default is 5. |
|
||||
| Parameter | Required | Description |
|
||||
|:----------------------------|:---------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `lifetime_minutes` | no | The initial session lifetime, in minutes. The default is 60 minutes. |
|
||||
| `renewal_threshold_minutes` | no | The length of time, in minutes, before the expiration of a session where, if used, a session will be extended by the current configured lifetime from then. A zero value disables session extension. The default is 20 minutes. |
|
||||
| `per_user_limit` | no | The maximum number of sessions that a user can have active simultaneously. If creating a new session would put a user over this limit, the least recently used session will be deleted. A value of zero disables limiting the number of sessions that users may have. The default is 10. |
|
||||
|
||||
### registries array (optional)
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ The interlock proxy.1 is then rescheduled with the new nginx configuration that
|
|||
|
||||
|
||||
|
||||
After proxy.1 is complete, proxy.2 redeploys with the updated ngix configuration for the app.1 task.
|
||||
After proxy.1 is complete, proxy.2 redeploys with the updated ngnix configuration for the app.1 task.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -30,5 +30,5 @@ updates, such as to let a service settle, use the `update-delay` setting. For e
|
|||
thirty (30) seconds between updates, use the following command:
|
||||
|
||||
```bash
|
||||
$> docker service update --update-delay=30s interlock=proxy
|
||||
$> docker service update --update-delay=30s interlock-proxy
|
||||
```
|
||||
|
|
|
|||
|
|
@ -217,6 +217,37 @@ https://github.com/kubernetes/kubernetes/pull/67432
|
|||
|
||||
# Version 3.1
|
||||
|
||||
## 3.1.9
|
||||
(2019-07-17)
|
||||
|
||||
### Bug fixes
|
||||
|
||||
* Fixed an issue where sensitive command line arguments provided to the UCP installer command were also printed in the debug logs.
|
||||
* Added a restrictive `robots.txt` to the root of the UCP API server.
|
||||
|
||||
### Known issues
|
||||
|
||||
* There are important changes to the upgrade process that, if not correctly followed, can impact the availability of applications running on the Swarm during upgrades. These constraints impact any upgrades coming from any Docker Engine version before 18.09 to version 18.09 or greater. For more information about upgrading Docker Enterprise to version 2.1, see [Upgrade Docker](../upgrade).
|
||||
* To deploy Pods with containers using Restricted Parameters, the user must be an admin and a service account must explicitly have a **ClusterRoleBinding** with `cluster-admin` as the **ClusterRole**. Restricted Parameters on Containers include:
|
||||
* Host Bind Mounts
|
||||
* Privileged Mode
|
||||
* Extra Capabilities
|
||||
* Host Networking
|
||||
* Host IPC
|
||||
* Host PID
|
||||
* If you delete the built-in **ClusterRole** or **ClusterRoleBinding** for `cluster-admin`, restart the `ucp-kube-apiserver` container on any manager node to recreate them. (#14483)
|
||||
* Pod Security Policies are not supported in this release. (#15105)
|
||||
* The default Kubelet configuration for UCP Manager nodes is expecting 4GB of free disk space in the `/var` partition. See [System Requirements](/ee/ucp/admin/install/system-requirements) for details.
|
||||
|
||||
### Components
|
||||
|
||||
| Component | Version |
|
||||
| ----------- | ----------- |
|
||||
| UCP | 3.1.9 |
|
||||
| Kubernetes | 1.11.10 |
|
||||
| Calico | 3.5.3 |
|
||||
| Interlock (nginx) | 1.14.0 |
|
||||
|
||||
## 3.1.8
|
||||
(2019-06-27)
|
||||
|
||||
|
|
@ -626,6 +657,24 @@ The following features are deprecated in UCP 3.1.
|
|||
|
||||
# Version 3.0
|
||||
|
||||
## 3.0.13
|
||||
2019-07-17
|
||||
|
||||
### Bug fixes
|
||||
|
||||
* Fixed an issue that caused sensitive command line arguments provided to the UCP installer command to also print in debug logs.
|
||||
* Added a restrictive robots.txt to the root of the UCP API server.
|
||||
|
||||
### Components
|
||||
|
||||
| Component | Version |
|
||||
| ----------- | ----------- |
|
||||
| UCP | 3.0.13 |
|
||||
| Kubernetes | 1.8.15 |
|
||||
| Calico | 3.0.8 |
|
||||
| Interlock (nginx) | 1.13.12 |
|
||||
|
||||
|
||||
## 3.0.12
|
||||
2019-06-27
|
||||
|
||||
|
|
@ -1124,6 +1173,31 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
|
|||
|
||||
# Version 2.2
|
||||
|
||||
## Version 2.2.20
|
||||
2019-07-17
|
||||
|
||||
### Bug fixes
|
||||
|
||||
* Fixed an issue that caused sensitive command line arguments provided to the UCP installer command to also print in debug logs.
|
||||
* Added a restrictive robots.txt to the root of the UCP API server.
|
||||
|
||||
### Known issues
|
||||
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
## Version 2.2.19
|
||||
2019-06-27
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
description: Create a Docker image by layering your ASP.NET Core app on debian for Linux Containers or with Windows Nano Server containers using a Dockerfile.
|
||||
keywords: dockerize, dockerizing, dotnet, .NET, Core, article, example, platform, installation, containers, images, image, dockerfile, build, asp.net, asp.net core
|
||||
title: Dockerize a .NET Core application
|
||||
title: Dockerize an ASP.NET Core application
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
|
@ -27,13 +27,13 @@ constructing your solutions
|
|||
|
||||
This example assumes you already have an ASP.NET Core app
|
||||
on your machine. If you are new to ASP.NET you can follow a [simple
|
||||
tutorial](https://www.asp.net/get-started) to initialize a project or clone our [ASP.NET Docker Sample](https://github.com/dotnet/dotnet-docker-samples/tree/master/aspnetapp).
|
||||
tutorial](https://www.asp.net/get-started) to initialize a project or clone our [ASP.NET Docker Sample](https://github.com/dotnet/dotnet-docker/tree/master/samples/aspnetapp).
|
||||
|
||||
## Create a Dockerfile for an ASP.NET Core application
|
||||
|
||||
1. Create a `Dockerfile` in your project folder.
|
||||
2. Add the text below to your `Dockerfile` for either Linux or [Windows
|
||||
Containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/).
|
||||
Containers](https://docs.microsoft.com/virtualization/windowscontainers/about/).
|
||||
The tags below are multi-arch meaning they pull either Windows or
|
||||
Linux containers depending on what mode is set in [Docker Desktop for
|
||||
Windows](/docker-for-windows/). Read more on [switching containers](/docker-for-windows/#switch-between-windows-and-linux-containers).
|
||||
|
|
@ -95,7 +95,7 @@ $ docker run -d -p 8080:80 --name myapp aspnetapp
|
|||
|
||||
## Further reading
|
||||
|
||||
- [ASP.NET Core](https://docs.microsoft.com/en-us/aspnet/core/)
|
||||
- [ASP.NET Core](https://docs.microsoft.com/aspnet/core/)
|
||||
- [Microsoft ASP.NET Core on Docker Hub](https://hub.docker.com/r/microsoft/dotnet/)
|
||||
- [Building Docker Images for .NET Core Applications](https://docs.microsoft.com/dotnet/core/docker/building-net-docker-images)
|
||||
- [Building Docker Docker Images for ASP.NET Core](https://docs.microsoft.com/aspnet/core/host-and-deploy/docker/building-net-docker-images)
|
||||
- [Docker Tools for Visual Studio](https://docs.microsoft.com/dotnet/articles/core/docker/visual-studio-tools-for-docker)
|
||||
|
|
|
|||
|
|
@ -11,5 +11,5 @@ This section contains the following:
|
|||
* [Dockerizing PostgreSQL](postgresql_service.md)
|
||||
* [Dockerizing a CouchDB service](couchdb_data_volumes.md)
|
||||
* [Dockerizing an apt-cacher-ng service](apt-cacher-ng.md)
|
||||
* [Dockerizing a .NET Core application](dotnetcore.md)
|
||||
* [Dockerizing an ASP.NET Core application](dotnetcore.md)
|
||||
* [Get Started](/get-started/)
|
||||
|
|
|
|||
|
|
@ -29,6 +29,22 @@ consistency and compatibility reasons.
|
|||
> `sudo apt install docker-ce docker-ce-cli containerd.io`. See the install instructions
|
||||
> for the corresponding linux distro for details.
|
||||
|
||||
## 18.09.08
|
||||
2019-07-17
|
||||
|
||||
### Runtime
|
||||
|
||||
* Masked the secrets updated to the log files when running Docker Engine in debug mode. [CVE-2019-13509](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13509): If a Docker engine is running in debug mode, and `docker stack deploy` is used to redeploy a stack which includes non-external secrets, the logs will contain the secret.
|
||||
|
||||
|
||||
### Client
|
||||
|
||||
* Fixed rollback config type interpolation for `parallelism` and `max_failure_ratio` fields.
|
||||
|
||||
### Known Issue
|
||||
|
||||
* There are [important changes](/ee/upgrade) to the upgrade process that, if not correctly followed, can have an impact on the availability of applications running on the Swarm during upgrades. These constraints impact any upgrades coming from any version before 18.09 to version 18.09 or later.
|
||||
|
||||
## 18.09.7
|
||||
2019-06-27
|
||||
|
||||
|
|
@ -64,7 +80,6 @@ consistency and compatibility reasons.
|
|||
### Networking
|
||||
* Cleaned up the cluster provider when the agent is closed. [docker/libnetwork#2354](https://github.com/docker/libnetwork/pull/2354)
|
||||
* Windows: Now selects a random host port if the user does not specify a host port. [docker/libnetwork#2369](https://github.com/docker/libnetwork/pull/2369)
|
||||
* `--service-cluster-ip-range` is now configurable for UCP install. [docker/orca#10263](https://github.com/docker/orca/issues/10263)
|
||||
|
||||
### Known Issues
|
||||
* There are [important changes](/ee/upgrade) to the upgrade process that, if not correctly followed, can have an impact on the availability of applications running on the Swarm during upgrades. These constraints impact any upgrades coming from any version before 18.09 to version 18.09 or later.
|
||||
|
|
@ -106,7 +121,7 @@ consistency and compatibility reasons.
|
|||
|
||||
### Builder
|
||||
|
||||
* Added validation for `git ref` to avoid misinterpretation as a flag. [moby/moby#38944](https://github.com/moby/moby/pull/38944)
|
||||
* Fixed [CVE-2019-13139](https://nvd.nist.gov/vuln/detail/CVE-2019-13139) by adding validation for `git ref` to avoid misinterpretation as a flag. [moby/moby#38944](https://github.com/moby/moby/pull/38944)
|
||||
|
||||
### Runtime
|
||||
|
||||
|
|
@ -358,6 +373,14 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
|
||||
## Older Docker Engine EE Release notes
|
||||
|
||||
## 18.03.1-ee-10
|
||||
|
||||
2019-07-17
|
||||
|
||||
### Runtime
|
||||
|
||||
* Masked the secrets updated to the log files when running Docker Engine in debug mode. [CVE-2019-13509](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13509): If a Docker engine is running in debug mode, and `docker stack deploy` is used to redeploy a stack which includes non-external secrets, the logs will contain the secret.
|
||||
|
||||
## 18.03.1-ee-9
|
||||
|
||||
2019-06-27
|
||||
|
|
@ -518,6 +541,35 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
+ Support for `--chown` with `COPY` and `ADD` in `Dockerfile`.
|
||||
+ Added functionality for the `docker logs` command to include the output of multiple logging drivers.
|
||||
|
||||
## 17.06.2-ee-23
|
||||
2019-07-17
|
||||
|
||||
### Runtime
|
||||
|
||||
* Masked the secrets updated to the log files when running Docker Engine in debug mode. [CVE-2019-13509](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13509): If a Docker engine is running in debug mode, and `docker stack deploy` is used to redeploy a stack which includes non-external secrets, the logs will contain the secret.
|
||||
|
||||
### Known issues
|
||||
|
||||
* When all Swarm managers are stopped at the same time, the swarm might end up in a
|
||||
split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
||||
* Under certain conditions, swarm leader re-election may timeout
|
||||
prematurely. During this period, docker commands may fail. Also during
|
||||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-22
|
||||
2019-06-27
|
||||
|
||||
|
|
@ -3173,4 +3225,3 @@ use `--detach` to keep the old behaviour.
|
|||
#### Windows
|
||||
|
||||
* Block pulling Windows images on non-Windows daemons [#29001](https://github.com/docker/docker/pull/29001)
|
||||
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ counter whenever you visit it.
|
|||
## Test the app with Compose
|
||||
|
||||
1. Start the app with `docker-compose up`. This builds the web app image,
|
||||
pull the Redis image if you don't already have it, and create two
|
||||
pulls the Redis image if you don't already have it, and creates two
|
||||
containers.
|
||||
|
||||
You see a warning about the Engine being in swarm mode. This is because
|
||||
|
|
|
|||
|
|
@ -321,7 +321,7 @@ The notation for associating a local image with a repository on a registry is
|
|||
the mechanism that registries use to give Docker images a version. Give the
|
||||
repository and tag meaningful names for the context, such as
|
||||
`get-started:part2`. This puts the image in the `get-started` repository and
|
||||
tag it as `part2`.
|
||||
tags it as `part2`.
|
||||
|
||||
Now, put it all together to tag the image. Run `docker tag image` with your
|
||||
username, repository, and tag names so that the image uploads to your
|
||||
|
|
@ -402,7 +402,7 @@ application by running this container in a **service**.
|
|||
|
||||
[Continue to Part 3 >>](part3.md){: class="button outline-btn"}
|
||||
|
||||
Or, learn how to [launch your container on your own machine using Digital Ocean](https://docs.docker.com/machine/examples/ocean/){: target="_blank" class="_" }.
|
||||
Or, learn how to [launch your container on your own machine using DigitalOcean](https://docs.docker.com/machine/examples/ocean/){: target="_blank" class="_" }.
|
||||
|
||||
## Recap and cheat sheet (optional)
|
||||
|
||||
|
|
|
|||
|
|
@ -338,7 +338,7 @@ myvm2 - hyperv Running tcp://192.168.200.181:2376 v17.06.
|
|||
|
||||
Now that you have `myvm1`, you can use its powers as a swarm manager to
|
||||
deploy your app by using the same `docker stack deploy` command you used in part
|
||||
3 to `myvm1`, and your local copy of `docker-compose.yml.`. This command may take a few seconds
|
||||
3 to `myvm1`, and your local copy of `docker-compose.yml`. This command may take a few seconds
|
||||
to complete and the deployment takes some time to be available. Use the
|
||||
`docker service ps <service_name>` command on a swarm manager to verify that
|
||||
all services have been redeployed.
|
||||
|
|
@ -415,7 +415,7 @@ You can access your app from the IP address of **either** `myvm1` or `myvm2`.
|
|||
|
||||
The network you created is shared between them and load-balancing. Run
|
||||
`docker-machine ls` to get your VMs' IP addresses and visit either of them on a
|
||||
browser, hitting refresh (or just `curl` them).
|
||||
browser on port 4000, hitting refresh (or just `curl` them).
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -281,7 +281,7 @@ Redis service. Be sure to replace `username/repo:tag` with your image details.
|
|||
|
||||
|
||||
|
||||
Also, check the visualizer at port 8080 on either node's IP address, and notice see the `redis` service running along with the `web` and `visualizer` services.
|
||||
Also, check the visualizer at port 8080 on either node's IP address, and notice the `redis` service running along with the `web` and `visualizer` services.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -44,8 +44,14 @@ To create the `docker` group and add your user:
|
|||
3. Log out and log back in so that your group membership is re-evaluated.
|
||||
|
||||
If testing on a virtual machine, it may be necessary to restart the virtual machine for changes to take effect.
|
||||
|
||||
|
||||
On a desktop Linux environment such as X Windows, log out of your session completely and then log back in.
|
||||
|
||||
On Linux, you can also run the following command to activate the changes to groups:
|
||||
|
||||
```bash
|
||||
$ newgrp docker
|
||||
```
|
||||
|
||||
4. Verify that you can run `docker` commands without `sudo`.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Docker Machine allows you to provision Docker machines in a variety of environme
|
|||
|
||||
## Drivers for creating machines
|
||||
|
||||
To create a virtual machine, you supply Docker Machine with the name of the driver you want to use. The driver determines where the virtual machine is created. For example, on a local Mac or Windows system, the driver is typically Oracle VirtualBox. For provisioning physical machines, a generic driver is provided. For cloud providers, Docker Machine supports drivers such as AWS, Microsoft Azure, Digital Ocean, and many more. The Docker Machine reference includes a complete [list of supported drivers](drivers/index.md).
|
||||
To create a virtual machine, you supply Docker Machine with the name of the driver you want to use. The driver determines where the virtual machine is created. For example, on a local Mac or Windows system, the driver is typically Oracle VirtualBox. For provisioning physical machines, a generic driver is provided. For cloud providers, Docker Machine supports drivers such as AWS, Microsoft Azure, DigitalOcean, and many more. The Docker Machine reference includes a complete [list of supported drivers](drivers/index.md).
|
||||
|
||||
## Default base operating systems for local and cloud hosts
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
description: Digital Ocean driver for machine
|
||||
keywords: machine, Digital Ocean, driver
|
||||
title: Digital Ocean
|
||||
description: DigitalOcean driver for machine
|
||||
keywords: machine, digitalocean, driver
|
||||
title: DigitalOcean
|
||||
---
|
||||
|
||||
Create Docker machines on [Digital Ocean](https://www.digitalocean.com/).
|
||||
Create Docker machines on [DigitalOcean](https://www.digitalocean.com/).
|
||||
|
||||
You need to create a personal access token under "Apps & API" in the Digital Ocean
|
||||
You need to create a personal access token under "Apps & API" in the DigitalOcean
|
||||
Control Panel and pass that to `docker-machine create` with the `--digitalocean-access-token` option.
|
||||
|
||||
## Usage
|
||||
|
|
@ -26,14 +26,14 @@ Control Panel and pass that to `docker-machine create` with the `--digitalocean-
|
|||
|
||||
## Options
|
||||
|
||||
- `--digitalocean-access-token`: **required**. Your personal access token for the Digital Ocean API.
|
||||
- `--digitalocean-backups`: Enable Digital Ocean backups for the droplet.
|
||||
- `--digitalocean-image`: The name of the Digital Ocean image to use.
|
||||
- `--digitalocean-access-token`: **required**. Your personal access token for the DigitalOcean API.
|
||||
- `--digitalocean-backups`: Enable DigitalOcean backups for the droplet.
|
||||
- `--digitalocean-image`: The name of the DigitalOcean image to use.
|
||||
- `--digitalocean-ipv6`: Enable IPv6 support for the droplet.
|
||||
- `--digitalocean-monitoring`: Enable monitoring for the droplet.
|
||||
- `--digitalocean-private-networking`: Enable private networking support for the droplet.
|
||||
- `--digitalocean-region`: The region to create the droplet in, see [Regions API](https://developers.digitalocean.com/documentation/v2/#regions) for how to get a list.
|
||||
- `--digitalocean-size`: The size of the Digital Ocean droplet (larger than default options are of the form `2gb`).
|
||||
- `--digitalocean-size`: The size of the DigitalOcean droplet (larger than default options are of the form `2gb`).
|
||||
- `--digitalocean-ssh-key-fingerprint`: Use an existing SSH key instead of creating a new one, see [SSH keys](https://developers.digitalocean.com/documentation/v2/#ssh-keys).
|
||||
- `--digitalocean-ssh-key-path`: SSH private key path.
|
||||
- `--digitalocean-ssh-port`: SSH port.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ title: Machine drivers
|
|||
|
||||
- [Amazon Web Services](aws.md)
|
||||
- [Microsoft Azure](azure.md)
|
||||
- [Digital Ocean](digital-ocean.md)
|
||||
- [DigitalOcean](digital-ocean.md)
|
||||
- [Exoscale](exoscale.md)
|
||||
- [Google Compute Engine](gce.md)
|
||||
- [Linode](linode.md) (unofficial plugin, not supported by Docker)
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Creates machines locally on [VMware Fusion](http://www.vmware.com/products/fusio
|
|||
- `--vmwarefusion-no-share`: Disable the mount of your home directory.
|
||||
|
||||
The VMware Fusion driver uses the latest boot2docker image.
|
||||
See [frapposelli/boot2docker](https://github.com/frapposelli/boot2docker/tree/vmware-64bit)
|
||||
See [frapposelli/boot2docker](https://github.com/boot2docker/boot2docker)
|
||||
|
||||
#### Environment variables and default values
|
||||
|
||||
|
|
@ -29,4 +29,4 @@ See [frapposelli/boot2docker](https://github.com/frapposelli/boot2docker/tree/vm
|
|||
| `--vmwarefusion-cpu-count` | `FUSION_CPU_COUNT` | `1` |
|
||||
| `--vmwarefusion-disk-size` | `FUSION_DISK_SIZE` | `20000` |
|
||||
| `--vmwarefusion-memory-size` | `FUSION_MEMORY_SIZE` | `1024` |
|
||||
| `--vmwarefusion-no-share` | `FUSION_NO_SHARE` | `false` |
|
||||
| `--vmwarefusion-no-share` | `FUSION_NO_SHARE` | `false` |
|
||||
|
|
|
|||
|
|
@ -3,5 +3,5 @@ description: Examples of cloud installs
|
|||
keywords: docker, machine, amazonec2, azure, digitalocean, google, openstack, rackspace, softlayer, virtualbox, vmwarefusion, vmwarevcloudair, vmwarevsphere, exoscale
|
||||
title: Learn by example
|
||||
---
|
||||
- [Digital Ocean Example](ocean.md)
|
||||
- [DigitalOcean Example](ocean.md)
|
||||
- [AWS Example](aws.md)
|
||||
|
|
|
|||
|
|
@ -1,22 +1,22 @@
|
|||
---
|
||||
description: Using Docker Machine to provision hosts on Digital Ocean
|
||||
keywords: docker, machine, cloud, digital ocean
|
||||
title: Digital Ocean example
|
||||
description: Using Docker Machine to provision hosts on DigitalOcean
|
||||
keywords: docker, machine, cloud, digitalocean
|
||||
title: DigitalOcean example
|
||||
---
|
||||
|
||||
Follow along with this example to create a Dockerized [Digital Ocean](https://digitalocean.com) Droplet (cloud host).
|
||||
Follow along with this example to create a Dockerized [DigitalOcean](https://digitalocean.com) Droplet (cloud host).
|
||||
|
||||
### Step 1. Create a Digital Ocean account
|
||||
### Step 1. Create a DigitalOcean account
|
||||
|
||||
If you have not done so already, go to [Digital Ocean](https://digitalocean.com), create an account, and log in.
|
||||
If you have not done so already, go to [DigitalOcean](https://digitalocean.com), create an account, and log in.
|
||||
|
||||
### Step 2. Generate a personal access token
|
||||
|
||||
To generate your access token:
|
||||
|
||||
1. Go to the Digital Ocean administrator console and click **API** in the header.
|
||||
1. Go to the DigitalOcean administrator console and click **API** in the header.
|
||||
|
||||
|
||||
|
||||
|
||||
2. Click **Generate new token** to get to the token generator.
|
||||
|
||||
|
|
@ -59,9 +59,9 @@ To generate your access token:
|
|||
|
||||
When the Droplet is created, Docker generates a unique SSH key and stores it on your local system in `~/.docker/machines`. Initially, this is used to provision the host. Later, it's used under the hood to access the Droplet directly with the `docker-machine ssh` command. Docker Engine is installed on the cloud server and the daemon is configured to accept remote connections over TCP using TLS for authentication.
|
||||
|
||||
2. Go to the Digital Ocean console to view the new Droplet.
|
||||
2. Go to the DigitalOcean console to view the new Droplet.
|
||||
|
||||
|
||||
|
||||
|
||||
3. At the command terminal, run `docker-machine ls`.
|
||||
|
||||
|
|
@ -131,7 +131,7 @@ To remove a host and all of its containers and images, first stop the machine, t
|
|||
NAME ACTIVE DRIVER STATE URL SWARM
|
||||
default * virtualbox Running tcp:////xxx.xxx.xx.xxx:xxxx
|
||||
|
||||
If you monitor the Digital Ocean console while you run these commands, notice
|
||||
If you monitor the DigitalOcean console while you run these commands, notice
|
||||
that it updates first to reflect that the Droplet was stopped, and then removed.
|
||||
|
||||
If you create a host with Docker Machine, but remove it through the cloud
|
||||
|
|
|
|||
|
|
@ -13,15 +13,15 @@ cloud provider.
|
|||
|
||||
Then you provide account verification, security credentials, and configuration
|
||||
options for the providers as flags to `docker-machine create`. The flags are
|
||||
unique for each cloud-specific driver. For instance, to pass a Digital Ocean
|
||||
unique for each cloud-specific driver. For instance, to pass a DigitalOcean
|
||||
access token you use the `--digitalocean-access-token` flag. Take a look at the
|
||||
examples below for Digital Ocean and AWS.
|
||||
examples below for DigitalOcean and AWS.
|
||||
|
||||
## Examples
|
||||
|
||||
### Digital Ocean
|
||||
### DigitalOcean
|
||||
|
||||
For Digital Ocean, this command creates a Droplet (cloud host) called
|
||||
For DigitalOcean, this command creates a Droplet (cloud host) called
|
||||
"docker-sandbox".
|
||||
|
||||
```shell
|
||||
|
|
@ -29,7 +29,7 @@ $ docker-machine create --driver digitalocean --digitalocean-access-token xxxxx
|
|||
```
|
||||
|
||||
For a step-by-step guide on using Machine to create Docker hosts on Digital
|
||||
Ocean, see the [Digital Ocean Example](examples/ocean.md).
|
||||
Ocean, see the [DigitalOcean Example](examples/ocean.md).
|
||||
|
||||
### Amazon Web Services (AWS)
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ Machine driver reference.
|
|||
## Drivers for cloud providers
|
||||
|
||||
When you install Docker Machine, you get a set of drivers for various cloud
|
||||
providers (like Amazon Web Services, Digital Ocean, or Microsoft Azure) and
|
||||
providers (like Amazon Web Services, DigitalOcean, or Microsoft Azure) and
|
||||
local providers (like Oracle VirtualBox, VMWare Fusion, or Microsoft Hyper-V).
|
||||
|
||||
See [Docker Machine driver reference](/machine/drivers/index.md){:
|
||||
|
|
@ -120,7 +120,7 @@ tutorials:
|
|||
|
||||
|
||||
## Where to go next
|
||||
- Example: Provision Dockerized [Digital Ocean Droplets](examples/ocean.md)
|
||||
- Example: Provision Dockerized [DigitalOcean Droplets](examples/ocean.md)
|
||||
- Example: Provision Dockerized [AWS EC2 Instances](examples/aws.md)
|
||||
- [Understand Machine concepts](concepts.md)
|
||||
- [Docker Machine driver reference](drivers/index.md)
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ title: Docker Machine
|
|||
- [Install Docker Machine](install-machine.md)
|
||||
- [Install a machine on your local system using VirtualBox](get-started.md)
|
||||
- [Install multiple machines on your cloud provider](get-started-cloud.md)
|
||||
- [Digital Ocean Example](examples/ocean.md)
|
||||
- [DigitalOcean Example](examples/ocean.md)
|
||||
- [AWS Example](examples/aws.md)
|
||||
- [Machine concepts and help](concepts.md)
|
||||
- [Migrate from Boot2Docker to Docker Machine](migrate-to-machine.md)
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ You can use Docker Machine to:
|
|||
Docker Machine is a tool that lets you install Docker Engine on virtual hosts,
|
||||
and manage the hosts with `docker-machine` commands. You can use Machine to
|
||||
create Docker hosts on your local Mac or Windows box, on your company network,
|
||||
in your data center, or on cloud providers like Azure, AWS, or Digital Ocean.
|
||||
in your data center, or on cloud providers like Azure, AWS, or DigitalOcean.
|
||||
|
||||
Using `docker-machine` commands, you can start, inspect, stop, and restart a
|
||||
managed host, upgrade the Docker client and daemon, and configure a Docker
|
||||
|
|
|
|||
|
|
@ -4,27 +4,40 @@ description: All about exposing containers on the Docker host's network
|
|||
keywords: network, host, standalone
|
||||
---
|
||||
|
||||
If you use the `host` network driver for a container, that container's network
|
||||
stack is not isolated from the Docker host. For instance, if you run a container
|
||||
which binds to port 80 and you use `host` networking, the container's
|
||||
application will be available on port 80 on the host's IP address.
|
||||
If you use the `host` network mode for a container, that container's network
|
||||
stack is not isolated from the Docker host (the container shares the host's
|
||||
networking namespace), and the container does not get its own IP-address allocated.
|
||||
For instance, if you run a container which binds to port 80 and you use `host`
|
||||
networking, the container's application is available on port 80 on the host's IP
|
||||
address.
|
||||
|
||||
> **Note**: Given that the container does not have its own IP-address when using
|
||||
> `host` mode networking, [port-mapping](/network/overlay/#publish-ports) does not
|
||||
> take effect, and the `-p`, `--publish`, `-P`, and `--publish-all` option are
|
||||
> ignored, producing a warning instead:
|
||||
>
|
||||
> ```
|
||||
> WARNING: Published ports are discarded when using host network mode
|
||||
> ```
|
||||
|
||||
Host mode networking can be useful to optimize performance, and in situations where
|
||||
a container needs to handle a large range of ports, as it does not require network
|
||||
address translation (NAT), and no "userland-proxy" is created for each port.
|
||||
|
||||
The host networking driver only works on Linux hosts, and is not supported on
|
||||
Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.
|
||||
|
||||
In Docker 17.06 and higher, you can also use a `host` network for a swarm
|
||||
service, by passing `--network host` to the `docker container create` command.
|
||||
In this case, control traffic (traffic related to managing the swarm and the
|
||||
service) is still sent across an overlay network, but the individual swarm
|
||||
service containers send data using the Docker daemon's host network and ports.
|
||||
This creates some extra limitations. For instance, if a service container binds
|
||||
to port 80, only one service container can run on a given swarm node.
|
||||
|
||||
If your container or service publishes no ports, host networking has no effect.
|
||||
You can also use a `host` network for a swarm service, by passing `--network host`
|
||||
to the `docker service create` command. In this case, control traffic (traffic
|
||||
related to managing the swarm and the service) is still sent across an overlay
|
||||
network, but the individual swarm service containers send data using the Docker
|
||||
daemon's host network and ports. This creates some extra limitations. For instance,
|
||||
if a service container binds to port 80, only one service container can run on a
|
||||
given swarm node.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Go through the [host networking tutorial](/network/network-tutorial-host.md)
|
||||
- Go through the [host networking tutorial](/network/network-tutorial-host.md)
|
||||
- Learn about [networking from the container's point of view](/config/containers/container-networking.md)
|
||||
- Learn about [bridge networks](/network/bridge.md)
|
||||
- Learn about [overlay networks](/network/overlay.md)
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ If you are installing on Azure, see [Install UCP on Azure](/ee/ucp/admin/install
|
|||
| `--registry-password` *value* | Password to use when pulling images [$REGISTRY_PASSWORD] |
|
||||
| `--registry-username` *value* | Username to use when pulling images [$REGISTRY_USERNAME] |
|
||||
| `--san` *value* | Add subject alternative names to certificates (e.g. --san www1.acme.com --san www2.acme.com) [$UCP_HOSTNAMES] |
|
||||
| `--service-cluster-ip-range` *value* | Kubernetes Cluster IP Range for Services (Default: 10.96.0.0/16) (default: "10.96.0.0/16") |
|
||||
| `--service-cluster-ip-range` *value* | Kubernetes Cluster IP Range for Services (default: "10.96.0.0/16") |
|
||||
| `--skip-cloud-provider-check` | Disables checks which rely on detecting which (if any) cloud provider the cluster is currently running on |
|
||||
| `--swarm-experimental` | Enable Docker Swarm experimental features. Used for backwards compatibility |
|
||||
| `--swarm-grpc-port` *value* | Port for communication between nodes (default: 2377) |
|
||||
|
|
|
|||
|
|
@ -11,7 +11,8 @@ Create a support dump for specified UCP nodes
|
|||
```
|
||||
docker container run --rm \
|
||||
--name ucp \
|
||||
-v /var/run/docker.sock:/var/run/docker.sock \
|
||||
--log-driver none \
|
||||
--volume /var/run/docker.sock:/var/run/docker.sock \
|
||||
docker/ucp \
|
||||
support [command options] > docker-support.tgz
|
||||
```
|
||||
|
|
|
|||
|
|
@ -5,7 +5,12 @@ keywords: release notes, compose
|
|||
toc_max: 2
|
||||
---
|
||||
|
||||
## 1.24.0
|
||||
## 1.24.1
|
||||
(2019-06-24)
|
||||
|
||||
This release contains minor improvements and bug fixes.
|
||||
|
||||
## 1.24.0
|
||||
(2019-03-28)
|
||||
|
||||
### Features
|
||||
|
|
@ -29,7 +34,7 @@ toc_max: 2
|
|||
- Fixed an issue where the output of `docker-compose start` before containers were created
|
||||
was misleading.
|
||||
|
||||
- Compose will no longer accept whitespace in variable names sourced from environment files.
|
||||
- Compose will no longer accept whitespace in variable names sourced from environment files.
|
||||
This matches the Docker CLI behavior.
|
||||
|
||||
- Compose will now report a configuration error if a service attempts to declare
|
||||
|
|
@ -44,7 +49,7 @@ toc_max: 2
|
|||
- Fixed an issue that caused some container events to not appear in the output of
|
||||
the `docker-compose events` command.
|
||||
|
||||
- Missing images will no longer stop the execution of `docker-compose down` commands. A warning is
|
||||
- Missing images will no longer stop the execution of `docker-compose down` commands. A warning is
|
||||
now displayed instead.
|
||||
|
||||
- Force `virtualenv` version for macOS CI.
|
||||
|
|
@ -57,7 +62,7 @@ toc_max: 2
|
|||
|
||||
- Fixed release script and some typos on release documentation.
|
||||
|
||||
## 1.23.2
|
||||
## 1.23.2
|
||||
(2018-11-28)
|
||||
|
||||
### Bug Fixes
|
||||
|
|
@ -81,7 +86,7 @@ toc_max: 2
|
|||
- Fixed a bug where some invalid Compose files would raise an uncaught
|
||||
exception during validation.
|
||||
|
||||
## 1.23.1
|
||||
## 1.23.1
|
||||
(2018-11-01)
|
||||
|
||||
### Bug Fixes
|
||||
|
|
@ -92,7 +97,7 @@ toc_max: 2
|
|||
- Fixed an issue where the behavior of the `--project-directory` flag would
|
||||
vary depending on which subcommand was used.
|
||||
|
||||
## 1.23.0
|
||||
## 1.23.0
|
||||
(2018-10-30)
|
||||
|
||||
### Important note
|
||||
|
|
@ -167,7 +172,7 @@ naming scheme accordingly before upgrading.
|
|||
- The `zsh` completion script has been updated with new options, and no
|
||||
longer suggests container names where service names are expected.
|
||||
|
||||
## 1.22.0
|
||||
## 1.22.0
|
||||
(2018-07-17)
|
||||
|
||||
### New features
|
||||
|
|
@ -221,7 +226,7 @@ naming scheme accordingly before upgrading.
|
|||
- Fixed a bug that caused auth values in legacy `.dockercfg` files to be ignored
|
||||
- `docker-compose build` will no longer attempt to create image names starting with an invalid character
|
||||
|
||||
## 1.21.2
|
||||
## 1.21.2
|
||||
(2018-05-03)
|
||||
|
||||
### Bug Fixes
|
||||
|
|
@ -229,7 +234,7 @@ naming scheme accordingly before upgrading.
|
|||
- Fixed a bug where the ip_range attribute in IPAM configs was prevented
|
||||
from passing validation
|
||||
|
||||
## 1.21.1
|
||||
## 1.21.1
|
||||
(2018-04-27)
|
||||
|
||||
### Bug Fixes
|
||||
|
|
@ -255,7 +260,7 @@ naming scheme accordingly before upgrading.
|
|||
elements with some v3.2 files, triggering errors at the Engine level during
|
||||
deployment.
|
||||
|
||||
## 1.21.0
|
||||
## 1.21.0
|
||||
(2018-04-11)
|
||||
|
||||
### New features
|
||||
|
|
@ -319,7 +324,7 @@ naming scheme accordingly before upgrading.
|
|||
recognized as inexistent by Compose, interrupting otherwise valid
|
||||
operations.
|
||||
|
||||
## 1.20.0
|
||||
## 1.20.0
|
||||
(2018-03-20)
|
||||
|
||||
### New features
|
||||
|
|
@ -406,7 +411,7 @@ naming scheme accordingly before upgrading.
|
|||
|
||||
- Fixed an encoding bug when streaming build progress
|
||||
|
||||
## 1.19.0
|
||||
## 1.19.0
|
||||
(2018-02-07)
|
||||
|
||||
### Breaking changes
|
||||
|
|
@ -499,7 +504,7 @@ naming scheme accordingly before upgrading.
|
|||
containing scalar types (number, boolean) now get automatically converted
|
||||
to strings
|
||||
|
||||
## 1.18.0
|
||||
## 1.18.0
|
||||
(2017-12-18)
|
||||
|
||||
### New features
|
||||
|
|
@ -582,7 +587,7 @@ naming scheme accordingly before upgrading.
|
|||
- The CLI now explicit prevents using `-d` and `--timeout` together
|
||||
in `docker-compose up`
|
||||
|
||||
## 1.17.0
|
||||
## 1.17.0
|
||||
(2017-11-01)
|
||||
|
||||
### New features
|
||||
|
|
@ -640,7 +645,7 @@ naming scheme accordingly before upgrading.
|
|||
- Fixed an issue where networks with identical names would sometimes be
|
||||
created when running `up` commands concurrently.
|
||||
|
||||
## 1.16.0
|
||||
## 1.16.0
|
||||
(2017-08-31)
|
||||
|
||||
### New features
|
||||
|
|
@ -700,7 +705,7 @@ naming scheme accordingly before upgrading.
|
|||
- Fixed the output of `docker-compose config` when a port definition used
|
||||
`0` as the value for the published port
|
||||
|
||||
## 1.15.0
|
||||
## 1.15.0
|
||||
(2017-07-26)
|
||||
|
||||
### New features
|
||||
|
|
@ -747,7 +752,7 @@ naming scheme accordingly before upgrading.
|
|||
- Fixed an issue preventing `up` operations on a previously created stack on
|
||||
Windows Engine.
|
||||
|
||||
## 1.14.0
|
||||
## 1.14.0
|
||||
(2017-06-19)
|
||||
|
||||
### New features
|
||||
|
|
@ -802,7 +807,7 @@ naming scheme accordingly before upgrading.
|
|||
- Fixed a bug where the output of `docker-compose config` would sometimes
|
||||
contain invalid port definitions
|
||||
|
||||
## 1.13.0
|
||||
## 1.13.0
|
||||
(2017-05-02)
|
||||
|
||||
### Breaking changes
|
||||
|
|
@ -858,7 +863,7 @@ naming scheme accordingly before upgrading.
|
|||
`volumes` would result in an invalid config state
|
||||
|
||||
|
||||
## 1.12.0
|
||||
## 1.12.0
|
||||
(2017-04-04)
|
||||
|
||||
### New features
|
||||
|
|
@ -955,7 +960,7 @@ naming scheme accordingly before upgrading.
|
|||
- Fixed an issue where Compose would not pick up on the value of
|
||||
COMPOSE_TLS_VERSION when used in combination with command-line TLS flags
|
||||
|
||||
## 1.11.2
|
||||
## 1.11.2
|
||||
(2017-02-17)
|
||||
|
||||
### Bug Fixes
|
||||
|
|
@ -976,7 +981,7 @@ naming scheme accordingly before upgrading.
|
|||
- Fixed an issue where recursive wildcard patterns `**` were not being
|
||||
recognized in `.dockerignore` files.
|
||||
|
||||
## 1.11.1
|
||||
## 1.11.1
|
||||
(2017-02-09)
|
||||
|
||||
### Bug Fixes
|
||||
|
|
@ -984,7 +989,7 @@ naming scheme accordingly before upgrading.
|
|||
- Fixed a bug where the 3.1 file format was not being recognized as valid
|
||||
by the Compose parser
|
||||
|
||||
## 1.11.0
|
||||
## 1.11.0
|
||||
(2017-02-08)
|
||||
|
||||
### New Features
|
||||
|
|
@ -1008,7 +1013,7 @@ naming scheme accordingly before upgrading.
|
|||
- Fixed an issue where the `pid` entry in a service definition was being
|
||||
ignored when using multiple Compose files.
|
||||
|
||||
## 1.10.1
|
||||
## 1.10.1
|
||||
(2017-02-01)
|
||||
|
||||
### Bug Fixes
|
||||
|
|
@ -1031,7 +1036,7 @@ naming scheme accordingly before upgrading.
|
|||
- Fixed a bug where Compose would occasionally crash while streaming logs
|
||||
when containers would stop or restart
|
||||
|
||||
## 1.10.0
|
||||
## 1.10.0
|
||||
(2017-01-18)
|
||||
|
||||
### New Features
|
||||
|
|
@ -1079,7 +1084,7 @@ naming scheme accordingly before upgrading.
|
|||
being parsed correctly on Windows
|
||||
|
||||
|
||||
## 1.9.0
|
||||
## 1.9.0
|
||||
(2016-11-16)
|
||||
|
||||
**Breaking changes**
|
||||
|
|
@ -1137,7 +1142,7 @@ naming scheme accordingly before upgrading.
|
|||
mismatch for overlay networks.
|
||||
|
||||
|
||||
## 1.8.1
|
||||
## 1.8.1
|
||||
(2016-09-22)
|
||||
|
||||
### Bug Fixes
|
||||
|
|
@ -1179,7 +1184,7 @@ naming scheme accordingly before upgrading.
|
|||
a connection timeout.
|
||||
|
||||
|
||||
## 1.8.0
|
||||
## 1.8.0
|
||||
(2016-06-14)
|
||||
|
||||
### Breaking Changes
|
||||
|
|
@ -1241,7 +1246,7 @@ naming scheme accordingly before upgrading.
|
|||
descriptive error messages when something goes wrong.
|
||||
|
||||
|
||||
## 1.7.1
|
||||
## 1.7.1
|
||||
(2016-05-04)
|
||||
|
||||
### Bug Fixes
|
||||
|
|
@ -1282,7 +1287,7 @@ naming scheme accordingly before upgrading.
|
|||
location as the Compose file.
|
||||
|
||||
|
||||
## 1.7.0
|
||||
## 1.7.0
|
||||
(2016-04-13)
|
||||
|
||||
### Breaking Changes
|
||||
|
|
@ -1370,13 +1375,13 @@ naming scheme accordingly before upgrading.
|
|||
- Fixed a bug where empty values for build args would cause file validation
|
||||
to fail.
|
||||
|
||||
## 1.6.2
|
||||
## 1.6.2
|
||||
(2016-02-23)
|
||||
|
||||
- Fixed a bug where connecting to a TLS-enabled Docker Engine would fail with
|
||||
a certificate verification error.
|
||||
|
||||
## 1.6.1
|
||||
## 1.6.1
|
||||
(2016-02-23)
|
||||
|
||||
### Bug Fixes
|
||||
|
|
@ -1431,7 +1436,7 @@ naming scheme accordingly before upgrading.
|
|||
as a value in a mapping.
|
||||
|
||||
|
||||
## 1.6.0
|
||||
## 1.6.0
|
||||
(2016-01-15)
|
||||
|
||||
### Major Features:
|
||||
|
|
@ -1548,7 +1553,7 @@ naming scheme accordingly before upgrading.
|
|||
non-standard logging driver (or none at all).
|
||||
|
||||
|
||||
## 1.5.2
|
||||
## 1.5.2
|
||||
(2015-12-03)
|
||||
|
||||
- Fixed a bug which broke the use of `environment` and `env_file` with
|
||||
|
|
@ -1570,7 +1575,7 @@ naming scheme accordingly before upgrading.
|
|||
- Improved the validation of the `expose` option
|
||||
|
||||
|
||||
## 1.5.1
|
||||
## 1.5.1
|
||||
(2015-11-12)
|
||||
|
||||
- Add the `--force-rm` option to `build`.
|
||||
|
|
@ -1623,7 +1628,7 @@ naming scheme accordingly before upgrading.
|
|||
error message.
|
||||
|
||||
|
||||
## 1.5.0
|
||||
## 1.5.0
|
||||
(2015-11-03)
|
||||
|
||||
### Breaking changes
|
||||
|
|
@ -1724,13 +1729,13 @@ https://github.com/docker/compose/blob/8cc8e61/docs/compose-file.md#variable-sub
|
|||
- `docker-compose build` can now be run successfully against a Swarm cluster.
|
||||
|
||||
|
||||
## 1.4.2
|
||||
## 1.4.2
|
||||
(2015-09-22)
|
||||
|
||||
- Fixed a regression in the 1.4.1 release that would cause `docker-compose up`
|
||||
without the `-d` option to exit immediately.
|
||||
|
||||
## 1.4.1
|
||||
## 1.4.1
|
||||
(2015-09-10)
|
||||
|
||||
### Bug fixes
|
||||
|
|
@ -1746,7 +1751,7 @@ https://github.com/docker/compose/blob/8cc8e61/docs/compose-file.md#variable-sub
|
|||
the configuration had not changed.
|
||||
|
||||
|
||||
## 1.4.0
|
||||
## 1.4.0
|
||||
(2015-08-04)
|
||||
|
||||
- By default, `docker-compose up` now only recreates containers for services whose configuration has changed since they were created. This should result in a dramatic speed-up for many applications.
|
||||
|
|
@ -1785,7 +1790,7 @@ https://github.com/docker/compose/blob/8cc8e61/docs/compose-file.md#variable-sub
|
|||
|
||||
Thanks @mnowster, @dnephin, @ekristen, @funkyfuture, @jeffk and @lukemarsden!
|
||||
|
||||
## 1.3.3
|
||||
## 1.3.3
|
||||
(2015-07-15)
|
||||
|
||||
### Regression fixes
|
||||
|
|
@ -1793,7 +1798,7 @@ Thanks @mnowster, @dnephin, @ekristen, @funkyfuture, @jeffk and @lukemarsden!
|
|||
- When stopping containers gracefully, Compose was setting the timeout to 0, effectively forcing a SIGKILL every time.
|
||||
- Compose would sometimes crash depending on the formatting of container data returned from the Docker API.
|
||||
|
||||
## 1.3.2
|
||||
## 1.3.2
|
||||
(2015-07-14)
|
||||
|
||||
### Bug fixes
|
||||
|
|
@ -1808,7 +1813,7 @@ Thanks @mnowster, @dnephin, @ekristen, @funkyfuture, @jeffk and @lukemarsden!
|
|||
|
||||
Thanks @dano, @josephpage, @kevinsimper, @lieryan, @phemmer, @soulrebel and @sschepens!
|
||||
|
||||
## 1.3.1
|
||||
## 1.3.1
|
||||
(2015-06-21)
|
||||
|
||||
### Bug fixes
|
||||
|
|
@ -1817,7 +1822,7 @@ Thanks @dano, @josephpage, @kevinsimper, @lieryan, @phemmer, @soulrebel and @ssc
|
|||
- `docker-compose help migrate-to-labels` failed with an error.
|
||||
- If no network mode was specified, Compose would set it to "bridge", rather than allowing the Docker daemon to use its configured default network mode.
|
||||
|
||||
## 1.3.0
|
||||
## 1.3.0
|
||||
(2015-06-18)
|
||||
|
||||
### Important notes
|
||||
|
|
@ -1862,7 +1867,7 @@ Several new configuration keys have been added to `docker-compose.yml`:
|
|||
|
||||
Thanks @ahromis, @albers, @aleksandr-vin, @antoineco, @ccverak, @chernjie, @dnephin, @edmorley, @fordhurley, @josephpage, @KyleJamesWalker, @lsowen, @mchasal, @noironetworks, @sdake, @sdurrheimer, @sherter, @stephenlawrence, @thaJeztah, @thieman, @turtlemonvh, @twhiteman, @vdemeester, @xuxinkun and @zwily!
|
||||
|
||||
## 1.2.0
|
||||
## 1.2.0
|
||||
(2015-04-16)
|
||||
|
||||
- `docker-compose.yml` now supports an `extends` option, which enables a service to inherit configuration from another service in another configuration file. This is really good for sharing common configuration between apps, or for configuring the same app for different environments. Here's the [documentation](https://github.com/docker/compose/blob/master/docs/yml.md#extends).
|
||||
|
|
@ -1885,7 +1890,7 @@ Thanks @ahromis, @albers, @aleksandr-vin, @antoineco, @ccverak, @chernjie, @dnep
|
|||
|
||||
Thanks, @abesto, @albers, @alunduil, @dnephin, @funkyfuture, @gilclark, @IanVS, @KingsleyKelly, @knutwalker, @thaJeztah and @vmalloc!
|
||||
|
||||
## 1.1.0
|
||||
## 1.1.0
|
||||
(2015-02-25)
|
||||
|
||||
Fig has been renamed to Docker Compose, or just Compose for short. This has several implications for you:
|
||||
|
|
@ -1918,14 +1923,14 @@ Besides that, there’s a lot of new stuff in this release:
|
|||
|
||||
Thanks @dnephin, @squebe, @jbalonso, @raulcd, @benlangfield, @albers, @ggtools, @bersace, @dtenenba, @petercv, @drewkett, @TFenby, @paulRbr, @Aigeruth and @salehe!
|
||||
|
||||
## 1.0.1
|
||||
## 1.0.1
|
||||
(2014-11-04)
|
||||
|
||||
- Added an `--allow-insecure-ssl` option to allow `fig up`, `fig run` and `fig pull` to pull from insecure registries.
|
||||
- Fixed `fig run` not showing output in Jenkins.
|
||||
- Fixed a bug where Fig couldn't build Dockerfiles with ADD statements pointing at URLs.
|
||||
|
||||
## 1.0.0
|
||||
## 1.0.0
|
||||
(2014-10-16)
|
||||
|
||||
The highlights:
|
||||
|
|
@ -1969,7 +1974,7 @@ Other things:
|
|||
|
||||
Thanks @dnephin, @d11wtq, @marksteve, @rubbish, @jbalonso, @timfreund, @alunduil, @mieciu, @shuron, @moss, @suzaku and @chmouel! Whew.
|
||||
|
||||
## 0.5.2
|
||||
## 0.5.2
|
||||
(2014-07-28)
|
||||
|
||||
- Added a `--no-cache` option to `fig build`, which bypasses the cache just like `docker build --no-cache`.
|
||||
|
|
@ -1980,7 +1985,7 @@ Thanks @dnephin, @d11wtq, @marksteve, @rubbish, @jbalonso, @timfreund, @alunduil
|
|||
Thanks @dnephin and @marksteve!
|
||||
|
||||
|
||||
## 0.5.1
|
||||
## 0.5.1
|
||||
(2014-07-11)
|
||||
|
||||
- If a service has a command defined, `fig run [service]` with no further arguments will run it.
|
||||
|
|
@ -1991,7 +1996,7 @@ Thanks @dnephin and @marksteve!
|
|||
Thanks @ryanbrainard and @d11wtq!
|
||||
|
||||
|
||||
## 0.5.0
|
||||
## 0.5.0
|
||||
(2014-07-11)
|
||||
|
||||
- Fig now starts links when you run `fig run` or `fig up`.
|
||||
|
|
@ -2029,19 +2034,19 @@ Thanks @ryanbrainard and @d11wtq!
|
|||
Thanks to @d11wtq, @ryanbrainard, @rail44, @j0hnsmith, @binarin, @Elemecca, @mozz100 and @marksteve for their help with this release!
|
||||
|
||||
|
||||
## 0.4.2
|
||||
## 0.4.2
|
||||
(2014-06-18)
|
||||
|
||||
- Fix various encoding errors when using `fig run`, `fig up` and `fig build`.
|
||||
|
||||
## 0.4.1
|
||||
## 0.4.1
|
||||
(2014-05-08)
|
||||
|
||||
- Add support for Docker 0.11.0. (Thanks @marksteve!)
|
||||
- Make project name configurable. (Thanks @jefmathiot!)
|
||||
- Return correct exit code from `fig run`.
|
||||
|
||||
## 0.4.0
|
||||
## 0.4.0
|
||||
(2014-04-29)
|
||||
|
||||
- Support Docker 0.9 and 0.10
|
||||
|
|
@ -2053,20 +2058,20 @@ Thanks to @d11wtq, @ryanbrainard, @rail44, @j0hnsmith, @binarin, @Elemecca, @moz
|
|||
- Handle UTF-8 correctly when streaming `fig build/run/up` output (thanks @mauvm and @shanejonas!)
|
||||
- Error message improvements
|
||||
|
||||
## 0.3.2
|
||||
## 0.3.2
|
||||
(2014-03-05)
|
||||
|
||||
- Added an `--rm` option to `fig run`. (Thanks @marksteve!)
|
||||
- Added an `expose` option to `fig.yml`.
|
||||
|
||||
## 0.3.1
|
||||
## 0.3.1
|
||||
(2014-03-04)
|
||||
|
||||
- Added contribution instructions. (Thanks @kvz!)
|
||||
- Fixed `fig rm` throwing an error.
|
||||
- Fixed a bug in `fig ps` on Docker 0.8.1 when there is a container with no command.
|
||||
|
||||
## 0.3.0
|
||||
## 0.3.0
|
||||
(2014-03-03)
|
||||
|
||||
- We now ship binaries for OS X and Linux. No more having to install with Pip!
|
||||
|
|
@ -2079,7 +2084,7 @@ Thanks to @d11wtq, @ryanbrainard, @rail44, @j0hnsmith, @binarin, @Elemecca, @moz
|
|||
|
||||
Thanks @marksteve, @Gazler and @teozkr!
|
||||
|
||||
## 0.2.2
|
||||
## 0.2.2
|
||||
(2014-02-17)
|
||||
|
||||
- Resolve dependencies using Cormen/Tarjan topological sort
|
||||
|
|
@ -2089,12 +2094,12 @@ Thanks @marksteve, @Gazler and @teozkr!
|
|||
|
||||
Thanks to @barnybug and @dustinlacewell for their work on this release.
|
||||
|
||||
## 0.2.1
|
||||
## 0.2.1
|
||||
(2014-02-04)
|
||||
|
||||
- General improvements to error reporting (#77, #79)
|
||||
|
||||
## 0.2.0
|
||||
## 0.2.0
|
||||
(2014-01-31)
|
||||
|
||||
- Link services to themselves so run commands can access the running service. (#67)
|
||||
|
|
@ -2104,30 +2109,30 @@ Thanks to @barnybug and @dustinlacewell for their work on this release.
|
|||
|
||||
Big thanks to @cameronmaske, @mrchrisadams and @damianmoore for their help with this release.
|
||||
|
||||
## 0.1.4
|
||||
## 0.1.4
|
||||
(2014-01-27)
|
||||
|
||||
- Add a link alias without the project name. This makes the environment variables a little shorter: `REDIS_1_PORT_6379_TCP_ADDR`. (#54)
|
||||
|
||||
## 0.1.3
|
||||
## 0.1.3
|
||||
(2014-01-23)
|
||||
|
||||
- Fix ports sometimes being configured incorrectly. (#46)
|
||||
- Fix log output sometimes not displaying. (#47)
|
||||
|
||||
## 0.1.2
|
||||
## 0.1.2
|
||||
(2014-01-22)
|
||||
|
||||
- Add `-T` option to `fig run` to disable pseudo-TTY. (#34)
|
||||
- Fix `fig up` requiring the ubuntu image to be pulled to recreate containers. (#33) Thanks @cameronmaske!
|
||||
- Improve reliability, fix arrow keys and fix a race condition in `fig run`. (#34, #39, #40)
|
||||
|
||||
## 0.1.1
|
||||
## 0.1.1
|
||||
(2014-01-17)
|
||||
|
||||
- Fix bug where ports were not exposed correctly (#29). Thanks @dustinlacewell!
|
||||
|
||||
## 0.1.0
|
||||
## 0.1.0
|
||||
(2014-01-16)
|
||||
|
||||
- Containers are recreated on each `fig up`, ensuring config is up-to-date with `fig.yml` (#2)
|
||||
|
|
@ -2142,7 +2147,7 @@ Big thanks to @cameronmaske, @mrchrisadams and @damianmoore for their help with
|
|||
|
||||
Big thanks to @tomstuart, @EnTeQuAk, @schickling, @aronasorman and @GeoffreyPlitt.
|
||||
|
||||
## 0.0.2
|
||||
## 0.0.2
|
||||
(2014-01-02)
|
||||
|
||||
- Improve documentation
|
||||
|
|
@ -2151,7 +2156,7 @@ Big thanks to @tomstuart, @EnTeQuAk, @schickling, @aronasorman and @GeoffreyPlit
|
|||
- Add confirmation prompt to `fig rm`
|
||||
- Add `fig build` command
|
||||
|
||||
## 0.0.1
|
||||
## 0.0.1
|
||||
(2013-12-20)
|
||||
|
||||
Initial release.
|
||||
|
|
|
|||
|
|
@ -505,7 +505,7 @@ toc_max: 2
|
|||
- Amazon EC2
|
||||
- Convert API calls to official SDK
|
||||
- Make DeviceName configurable
|
||||
- Digital Ocean
|
||||
- DigitalOcean
|
||||
- Custom SSH port support
|
||||
- Generic
|
||||
- Don't support `kill` since `stop` is not supported
|
||||
|
|
@ -594,7 +594,7 @@ Non-core driver plugins should still work as intended (in externally distributed
|
|||
- Activate the plugin only on OSX
|
||||
- Add id/gid option to mount when using vmhgfs
|
||||
- Fix for vSphere driver boot2docker ISO issues
|
||||
- Digital Ocean
|
||||
- DigitalOcean
|
||||
- Support for creating Droplets with Cloud-init User Data
|
||||
- Openstack
|
||||
- Sanitize keynames by replacing dots with underscores
|
||||
|
|
@ -877,7 +877,7 @@ Initial beta release.
|
|||
### Included drivers
|
||||
|
||||
- Amazon EC2
|
||||
- Digital Ocean
|
||||
- DigitalOcean
|
||||
- Google
|
||||
- Microsoft Azure
|
||||
- Microsoft Hyper-V
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ should already have Machine installed. If you need to install, see the
|
|||
instructions for [macOS](/docker-for-mac/) or
|
||||
[Windows](/docker-for-windows/).
|
||||
|
||||
Machine supports installing on AWS, Digital Ocean, Google Cloud Platform, IBM
|
||||
Machine supports installing on AWS, DigitalOcean, Google Cloud Platform, IBM
|
||||
Softlayer, Microsoft Azure and Hyper-V, OpenStack, Rackspace, VirtualBox, VMware
|
||||
Fusion®, vCloud® Air<sup>TM</sup> and vSphere®. This example uses
|
||||
VirtualBox to run several VMs based on the `boot2docker.iso` image.
|
||||
|
|
|
|||
Loading…
Reference in New Issue