mirror of https://github.com/docker/docs.git
Sync published with master (#8898)
* Fix broken links * Update link to webhook types * Rewritten Custom CNI to become Unmanaged CNI in UCP Docs (#8799) Here I have rewritten the Unmanaged CNI page with Docker UCP. The changes are: - Clarifying the support position - Providing clear instructions on how to bring up UCP and then install a custom CNI plugin - Removes unneccesary items like disabling IPIP which is not related to this page. Signed-off-by: Olly Pomeroy <olly@docker.com> * Updated following Uday's feedback * Add editorial review * Fix link preview * Update link to UCP installation * Fix typo * Standardize headings * removed the reference to index.md Though the sections referenced belong to `index.md`, there is no requirement to call it out in the URL. For example: https://docs.docker.com/docker-for-mac/#add-tls-certificates https://docs.docker.com/docker-for-mac/#reset * Update faqs.md * Update ubuntu version and common driver on storagedriver docs (#8746) Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com> * refactor Jenkinsfile - use DTR images for all but `docker.github.io:published` - use environment variables instead of credentials - build and push all images inside VPN container - combine build + image and update swarm stages - remove repetitive steps / stages * 7724 (#8876) * Fix 7724 * Fix broken link * Change to Docker Enterprise (#8877) * Change to Docker Enterprise * Update the new default addr pool for swarm (#8705) The default address pool for swarm is now a `/8` CIDR * Update part2.md (#8535) typo * Update system-requirements.md * Clean up syntax (#8881) * Removed 2018 references. (#8880) * Remove pay thru Docker section (#8879) * Update index.md * Edit signing images (#8882) * Edit signing images * Incorporate feedback * Final edits - Change example Security member name
This commit is contained in:
Maria Bermudez
GitHub
parent
0cfcf41494
commit
168c7b5410
|
|
@ -1371,7 +1371,7 @@ manuals:
|
|||
path: /ee/ucp/kubernetes/layer-7-routing/
|
||||
- title: Create a service account for a Kubernetes app
|
||||
path: /ee/ucp/kubernetes/create-service-account/
|
||||
- title: Install a CNI plugin
|
||||
- title: Install an unmanaged CNI plugin
|
||||
path: /ee/ucp/kubernetes/install-cni-plugin/
|
||||
- title: Kubernetes network encryption
|
||||
path: /ee/ucp/kubernetes/kubernetes-network-encryption/
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ all nodes must have:
|
|||
|
||||
* Linux kernel version 3.10 or higher
|
||||
* CS Docker Engine version 1.10 or higher. Learn about the
|
||||
[operating systems supported by CS Docker Engine](/cs-engine/install/).
|
||||
[operating systems supported by CS Docker Engine](/install/).
|
||||
* 2.00 GB of RAM
|
||||
* 3.00 GB of available disk space
|
||||
* A static IP address
|
||||
|
|
@ -59,4 +59,4 @@ Docker Datacenter is a software subscription that includes 3 products:
|
|||
## Where to go next
|
||||
|
||||
* [UCP architecture](../architecture.md)
|
||||
* [Plan a production installation](plan-production-install.md)
|
||||
* [Plan a production installation](plan-production-install.md)
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
---
|
||||
title: Use externally-signed certificates
|
||||
description: Learn how to configure Docker Universal Control Plane to use your own
|
||||
certificates.
|
||||
keywords: Universal Control Plane, UCP, certificate, authentication, tls
|
||||
title: Use externally-signed certificates
|
||||
---
|
||||
|
||||
All UCP services are exposed using HTTPS, to ensure all communications between
|
||||
|
|
|
|||
|
|
@ -139,4 +139,4 @@ steps as you used to configure your local computer.
|
|||
|
||||
## Where to go next
|
||||
|
||||
* [use your own externally-signed TLS certificates](index.md#customize-the-ucp-tls-certificates)
|
||||
* [Use your own externally-signed TLS certificates](/datacenter/ucp/2.0/guides/configuration/index.md#customize-the-ucp-tls-certificates)
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ is about older releases of Docker for Mac.
|
|||
|
||||
If, after installing Docker for Mac, you [change the name of your macOS user
|
||||
account and home folder](https://support.apple.com/en-us/HT201548), Docker for
|
||||
Mac fails to start. [Reset to Factory Defaults](index.md#reset) is the simplest
|
||||
Mac fails to start. [Reset to Factory Defaults](/docker-for-mac/index/#reset) is the simplest
|
||||
fix, but you'll lose all your settings, containers, images, etc.
|
||||
|
||||
To preserve them, open the `~/Library/Group
|
||||
|
|
@ -246,7 +246,7 @@ Starting with Docker for Mac Beta 27 and Stable 1.12.3, all trusted certificate
|
|||
authorities (CAs) (root or intermediate) are supported.
|
||||
|
||||
For full information on adding server and client side certs, see
|
||||
[Add TLS certificates](index.md#add-tls-certificates) in the Getting Started topic.
|
||||
[Add TLS certificates](/docker-for-mac/index/#add-tls-certificates) in the Getting Started topic.
|
||||
|
||||
### How do I add client certificates?
|
||||
|
||||
|
|
@ -256,7 +256,7 @@ in `~/.docker/certs.d/<MyRegistry>:<Port>/client.cert` and
|
|||
`~/.docker/certs.d/<MyRegistry>:<Port>/client.key`.
|
||||
|
||||
For full information on adding server and client side certs, see
|
||||
[Add TLS certificates](index.md#add-tls-certificates) in the Getting Started topic.
|
||||
[Add TLS certificates](/docker-for-mac/index/#add-tls-certificates) in the Getting Started topic.
|
||||
|
||||
### Can I pass through a USB device to a container?
|
||||
|
||||
|
|
|
|||
|
|
@ -38,14 +38,6 @@ experience the following benefits:
|
|||
Docker Hub welcomes free and open-source content, as well as software sold
|
||||
directly by publishers. We support the following commercial models:
|
||||
|
||||
### Paid through Docker
|
||||
|
||||
This commercial model allows customers to pay for ISV content through Docker, as
|
||||
described in the Store Vendor Partner agreement. Paid-through-Docker content
|
||||
includes both software that can be deployed on a host, as well as software that
|
||||
runs in the cloud and can be accessed by the customer through an agent
|
||||
(containerized cloud services, for example).
|
||||
|
||||
### Licensed content through Docker Hub BYOL program
|
||||
|
||||
ISVs can use Docker Hub as an entitlement and distribution platform. Using
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ We don't support the abiltiy to view available tags for published products becau
|
|||
|
||||
Official images and community images have available tags visible because anyone can access any tag at any time anonymously.
|
||||
|
||||
We aim to have product listings published with the concept of versions, allowing publishers to manage which versions of their products they expose to customers for access. (Expected Q3 2018)
|
||||
We aim to have product listings published with the concept of versions, allowing publishers to manage which versions of their products they expose to customers for access.
|
||||
|
||||
### On the page for another vendor’s product on Docker Hub, I see the following chunks of data: How do these fields map to the following that are required in the publish process?
|
||||
|
||||
|
|
@ -169,11 +169,6 @@ As a publisher you can charge a subscription fee every month in USD. The amount
|
|||
is determined by you. We are working on other pricing options. If you have
|
||||
feedback about pricing, send us an email at publisher-support@docker.com
|
||||
|
||||
### As a publisher, I have not setup any payment account. How does money get to me if my commercial content gets purchased by customers?
|
||||
|
||||
We (Docker) cut you a check post a revenue share. Your Docker Hub Vendor
|
||||
Agreement should cover specifics.
|
||||
|
||||
### How does Docker handle Export control? Can individual countries be specified if differing from Docker's list of embargoed countries?
|
||||
|
||||
We provide export control through blacklisting several countries, IPs and users
|
||||
|
|
@ -212,4 +207,4 @@ Yes
|
|||
|
||||
### Can I have a publish by date for my content?
|
||||
|
||||
Not yet. Potential ETA Q2 2018.
|
||||
Not yet. This is a planned enhancement, but we have no specific availability date at this time.
|
||||
|
|
|
|||
|
|
@ -26,27 +26,26 @@ Docker recommends the following steps for your storage backend and metadata migr
|
|||
|
||||
5. With DTR restored from your backup and your storage data migrated to your new backend, garbage collect any dangling blobs using the following API request:
|
||||
|
||||
```bash
|
||||
curl -u <username>:$TOKEN -X POST "https://<dtr-url>/api/v0/jobs" -H "accept: application/json" -H "content-type: application/json" -d "{ \"action": \"onlinegc_blobs\" }"
|
||||
```
|
||||
On success, you should get a `202 Accepted` response with a job `id` and other related details.
|
||||
|
||||
This ensures any blobs which are not referenced in your previously created backup get destroyed.
|
||||
```bash
|
||||
curl -u <username>:$TOKEN -X POST "https://<dtr-url>/api/v0/jobs" -H "accept: application/json" -H "content-type: application/json" -d "{ \"action": \"onlinegc_blobs\" }"
|
||||
```
|
||||
|
||||
On success, you should get a `202 Accepted` response with a job `id` and other related details. This ensures any blobs which are not referenced in your previously created backup get destroyed.
|
||||
|
||||
### Alternative option for data migration
|
||||
|
||||
- If you have a long maintenance window, you can skip some steps from above and do the following:
|
||||
If you have a long maintenance window, you can skip some steps from above and do the following:
|
||||
|
||||
1. Put DTR in "read-only" mode using the following API request:
|
||||
1. Put DTR in "read-only" mode using the following API request:
|
||||
|
||||
```bash
|
||||
curl -u <username>:$TOKEN -X POST "https://<dtr-url>/api/v0/meta/settings" -H "accept: application/json" -H "content-type: application/json" -d "{ \"readOnlyRegistry\": true }"
|
||||
```
|
||||
On success, you should get a `202 Accepted` response.
|
||||
```bash
|
||||
curl -u <username>:$TOKEN -X POST "https://<dtr-url>/api/v0/meta/settings" -H "accept: application/json" -H "content-type: application/json" -d "{ \"readOnlyRegistry\": true }"
|
||||
```
|
||||
On success, you should get a `202 Accepted` response.
|
||||
|
||||
2. Migrate the contents of your current storage backend to the new one you are switching to. For example, upload your current storage data to your new NFS server.
|
||||
2. Migrate the contents of your current storage backend to the new one you are switching to. For example, upload your current storage data to your new NFS server.
|
||||
|
||||
3. [Reconfigure DTR](/reference/dtr/2.6/cli/reconfigure) while specifying the `--storage-migrated` flag to preserve your existing tags.
|
||||
3. [Reconfigure DTR](/reference/dtr/2.6/cli/reconfigure) while specifying the `--storage-migrated` flag to preserve your existing tags.
|
||||
|
||||
|
||||
## DTR 2.6.0-2.6.4 and DTR 2.5 (with experimental garbage collection)
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ keywords: dtr, webhooks, api, registry
|
|||
|
||||
## Prerequisite
|
||||
|
||||
See [Event types for webhooks](/ee/dtr/admin/manage-webhooks/index.md/#event-types-for-webhooks) for a complete list of event types you can trigger notifications for via the API.
|
||||
See [Webhook types](/ee/dtr/admin/manage-webhooks/index.md/#webhook-types) for a list of events you can trigger notifications for via the API.
|
||||
|
||||
## API Base URL
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ keywords: dtr, webhooks, ui, web interface, registry
|
|||
## Prerequisites
|
||||
|
||||
- You must have admin privileges to the repository in order to create a webhook.
|
||||
- See [Event types](/ee/dtr/admin/manage-webhooks/index.md/#event-types-for-webhooks) for a complete list of event types you can trigger notifications for using the web interface.
|
||||
- See [Webhook types](/ee/dtr/admin/manage-webhooks/index.md/#webhook-types) for a list of events you can trigger notifications for using the web interface.
|
||||
|
||||
## Create a webhook for your repository
|
||||
|
||||
|
|
|
|||
|
|
@ -7,21 +7,21 @@ redirect_from:
|
|||
- /ee/dtr/user/manage-images/sign-images/manage-trusted-repositories/
|
||||
---
|
||||
|
||||
2 Key components of the Docker Trusted Registry are the Notary Server and Notary
|
||||
Signer. These 2 containers give us the required components to use Docker Content
|
||||
Trust right out of the box. [Docker Content
|
||||
Trust](/engine/security/trust/content_trust/) allows us to sign image tags,
|
||||
therefore whoever pulls the image can validate that they are getting the image
|
||||
you create, or a forged one.
|
||||
Two key components of the Docker Trusted Registry are the Notary Server and the Notary
|
||||
Signer. These two containers provide the required components for using Docker Content
|
||||
Trust (DCT) out of the box. [Docker Content
|
||||
Trust](/engine/security/trust/content_trust/) allows you to sign image tags,
|
||||
therefore giving consumers a way to verify the integrity of your image.
|
||||
|
||||
As part of Docker Trusted Registry both the Notary server and the Registry
|
||||
server are accessed through a front end Proxy, with both components sharing the
|
||||
UCP's RBAC Engine. Therefore no additional configuration of the Docker Client
|
||||
is required to use trust.
|
||||
As part of DTR, both the Notary and the Registry
|
||||
servers are accessed through a front-end proxy, with both components sharing the
|
||||
UCP's RBAC (Role-based Access Control) Engine. Therefore, you do not need additional Docker client
|
||||
configuration in order to use DCT.
|
||||
|
||||
Docker Content Trust is integrated into the Docker CLI, allowing you to
|
||||
configure repositories, add signers and sign images all through the `$ docker
|
||||
trust` command.
|
||||
DCT is integrated with the Docker CLI, and allows you to:
|
||||
- Configure repositories
|
||||
- Add signers, and
|
||||
- Sign images using the `docker trust` command
|
||||
|
||||
|
||||
|
||||
|
|
@ -29,31 +29,29 @@ trust` command.
|
|||
|
||||
UCP has a feature which will prevent [untrusted
|
||||
images](/ee/ucp/admin/configure/run-only-the-images-you-trust/) from being
|
||||
deployed on the cluster. To use this feature, we first need to upload and sign
|
||||
images into DTR. To tie the signed images back to UCP, we will actually sign the
|
||||
images with private keys of UCP users. Inside of a UCP Client bundle the
|
||||
`key.pem` can be used a User's private key, with the `cert.pem` being a public
|
||||
key within a x509 certificate.
|
||||
deployed on the cluster. To use the feature, you need to sign and push images to your DTR.
|
||||
To tie the signed images back to UCP, you need to sign the
|
||||
images with the private keys of the UCP users. From a UCP client bundle, use
|
||||
`key.pem` as your private key, and `cert.pem` as your public key
|
||||
on an `x509` certificate.
|
||||
|
||||
To sign images in a way that UCP trusts them, you need to:
|
||||
To sign images in a way that UCP can trust, you need to:
|
||||
|
||||
1. Download a Client Bundle for a User you want to use to sign the images.
|
||||
2. Load the private key of the User into your workstations trust store.
|
||||
1. Download a client bundle for the user account you want to use for signing the images.
|
||||
2. Add the user's private key to your machine's trust store.
|
||||
3. Initialize trust metadata for the repository.
|
||||
4. Delegate signing for that repository to the UCP User.
|
||||
5. Sign the Image.
|
||||
4. Delegate signing for that repository to the UCP user.
|
||||
5. Sign the image.
|
||||
|
||||
In this example we're going to pull a nginx image from the Docker Hub, re-tag it
|
||||
as `dtr.example.com/dev/nginx:1`, push the image to DTR and sign it in a way
|
||||
that is trusted by UCP. If you manage multiple repositories, you'll have to do
|
||||
the same procedure for each repository.
|
||||
The following example shows the `nginx` image getting pulled from Docker Hub, tagged
|
||||
as `dtr.example.com/dev/nginx:1`, pushed to DTR, and signed in a way
|
||||
that is trusted by UCP.
|
||||
|
||||
### Import a UCP User's Private Key
|
||||
### Import a UCP user's private key
|
||||
|
||||
Once you have download and extracted a UCP User's client bundle into your local
|
||||
directory, you need to load the Private key into the local Docker trust store
|
||||
`(~/.docker/trust)`. The name used here is purely metadata to help keep track of
|
||||
which keys you have imported.
|
||||
After downloading and extracting a UCP client bundle into your local
|
||||
directory, you need to load the private key into the local Docker trust store
|
||||
`(~/.docker/trust)`. To illustrate the process, we will use `jeff` as an example user.
|
||||
|
||||
```bash
|
||||
$ docker trust key load --name jeff key.pem
|
||||
|
|
@ -63,16 +61,16 @@ Repeat passphrase for new jeff key with ID a453196:
|
|||
Successfully imported key from key.pem
|
||||
```
|
||||
|
||||
### Initialize the trust metadata and add the Public Key
|
||||
### Initialize the trust metadata and add the user's public certificate
|
||||
|
||||
Next, we need to initiate trust metadata for a DTR repository. If you have not
|
||||
done so already, navigate to the **DTR web UI**, and create a repository for
|
||||
your image. In this example we've created the `prod/nginx` repository.
|
||||
Next,initiate trust metadata for a DTR repository. If you have not
|
||||
already done so, navigate to the **DTR web UI**, and create a repository for
|
||||
your image. This example uses the `nginx` repository in the `prod` namespace.
|
||||
|
||||
As part of initiating the repository, we will add the public key of the UCP User
|
||||
as a signer. You will be asked for a number of passphrases to protect the keys.
|
||||
Make a note of these passphrases, and see [Managing Delegations in a Notary Server](/engine/security/trust/trust_delegation/#managing-delegations-in-a-notary-server)
|
||||
to learn more about managing keys.
|
||||
As part of initiating the repository, the public key of the UCP user needs to be added
|
||||
to the Notary server as a signer for the repository. You will be asked for a number of
|
||||
passphrases to protect the keys.Make a note of these passphrases, and
|
||||
see [Managing Delegations in a Notary Server](/engine/security/trust/trust_delegation/#managing-delegations-in-a-notary-server) to learn more about managing keys.
|
||||
|
||||
|
||||
```bash
|
||||
|
|
@ -86,7 +84,7 @@ Successfully initialized "dtr.example.com/prod/nginx"
|
|||
Successfully added signer: jeff to dtr.example.com/prod/nginx
|
||||
```
|
||||
|
||||
We can inspect the trust metadata of the repository to make sure the User has
|
||||
Inspect the trust metadata of the repository to make sure the user has
|
||||
been added correctly.
|
||||
|
||||
```bash
|
||||
|
|
@ -105,11 +103,10 @@ Administrative keys for dtr.example.com/prod/nginx
|
|||
Root Key: b74854cb27cc25220ede4b08028967d1c6e297a759a6939dfef1ea72fbdd7b9a
|
||||
```
|
||||
|
||||
### Sign the Image
|
||||
### Sign the image
|
||||
|
||||
Finally, we will sign an image tag. These steps download the Image from the
|
||||
Docker Hub, retag the Image to the DTR repository, push the image up to DTR, as
|
||||
well as signing the tag with the UCP User's keys.
|
||||
Finally, user `jeff` can sign an image tag. The following steps include downloading the image from Hub, tagging the image for Jeff's DTR repository, pushing the image to Jeff's DTR, as
|
||||
well as signing the tag with Jeff's keys.
|
||||
|
||||
```bash
|
||||
$ docker pull nginx:latest
|
||||
|
|
@ -128,7 +125,7 @@ Enter passphrase for jeff key with ID 927f303:
|
|||
Successfully signed dtr.example.com/prod/nginx:1
|
||||
```
|
||||
|
||||
We can inspect the trust metadata again to make sure the image tag has been
|
||||
Inspect the trust metadata again to make sure the image tag has been
|
||||
signed successfully.
|
||||
|
||||
```bash
|
||||
|
|
@ -150,49 +147,48 @@ Administrative keys for dtr.example.com/prod/nginx:1
|
|||
Root Key: b74854cb27cc25220ede4b08028967d1c6e297a759a6939dfef1ea72fbdd7b9a
|
||||
```
|
||||
|
||||
Or we can have a look at the signed image from within the **DTR UI**.
|
||||
Alternatively, you can review the signed image from the DTR web UI.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
### Adding Additional Delegations
|
||||
### Add delegations
|
||||
|
||||
If you wanted to sign this image with multiple UCP Users, maybe if you had a use
|
||||
case where an image needed to be signed by a member of the `Security` team and a
|
||||
member of the `Developers` team. Then you can add multiple signers to a
|
||||
repository.
|
||||
You have the option to sign an image using multiple UCP users' keys. For example, an image
|
||||
needs to be signed by a member of the `Security` team and a
|
||||
member of the `Developers` team. Let's assume `jeff` is a member of the Developers team.
|
||||
In this case, we only need to add a member of the Security team.
|
||||
|
||||
To do so, first load a private key from a UCP User of the Security Team's in to
|
||||
the local Docker Trust Store.
|
||||
To do so, first add the private key of the Security team member to
|
||||
the local Docker trust store.
|
||||
|
||||
```bash
|
||||
$ docker trust key load --name security key.pem
|
||||
$ docker trust key load --name ian key.pem
|
||||
Loading key from "key.pem"...
|
||||
Enter passphrase for new security key with ID 5ac7d9a:
|
||||
Repeat passphrase for new security key with ID 5ac7d9a:
|
||||
Enter passphrase for new ian key with ID 5ac7d9a:
|
||||
Repeat passphrase for new ian key with ID 5ac7d9a:
|
||||
Successfully imported key from key.pem
|
||||
```
|
||||
|
||||
Upload the Public Key to the Notary Server and Sign the Image. You will be asked
|
||||
for both the Developers passphrase, as well as the Security Users passphrase to
|
||||
Upload the user's public key to the Notary Server and sign the image. You will be asked
|
||||
for `jeff`, the developer's passphrase, as well as the `ian` user's passphrase to
|
||||
sign the tag.
|
||||
|
||||
```bash
|
||||
$ docker trust signer add --key cert.pem security dtr.example.com/prod/nginx
|
||||
Adding signer "security" to dtr.example.com/prod/nginx...
|
||||
$ docker trust signer add --key cert.pem ian dtr.example.com/prod/nginx
|
||||
Adding signer "ian" to dtr.example.com/prod/nginx...
|
||||
Enter passphrase for repository key with ID e0d15a2:
|
||||
Successfully added signer: security to dtr.example.com/prod/nginx
|
||||
Successfully added signer: ian to dtr.example.com/prod/nginx
|
||||
|
||||
$ docker trust sign dtr.example.com/prod/nginx:1
|
||||
Signing and pushing trust metadata for dtr.example.com/prod/nginx:1
|
||||
Existing signatures for tag 1 digest 5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033 from:
|
||||
jeff
|
||||
Enter passphrase for jeff key with ID 927f303:
|
||||
Enter passphrase for security key with ID 5ac7d9a:
|
||||
Enter passphrase for ian key with ID 5ac7d9a:
|
||||
Successfully signed dtr.example.com/prod/nginx:1
|
||||
```
|
||||
|
||||
Finally, we can check the tag again to make sure it is now signed by 2
|
||||
signatures.
|
||||
Finally, check the tag again to make sure it includes two signers.
|
||||
|
||||
```bash
|
||||
$ docker trust inspect --pretty dtr.example.com/prod/nginx:1
|
||||
|
|
@ -200,13 +196,13 @@ $ docker trust inspect --pretty dtr.example.com/prod/nginx:1
|
|||
Signatures for dtr.example.com/prod/nginx:1
|
||||
|
||||
SIGNED TAG DIGEST SIGNERS
|
||||
1 5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033 jeff, security
|
||||
1 5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033 jeff, ian
|
||||
|
||||
List of signers and their keys for dtr.example.com/prod/nginx:1
|
||||
|
||||
SIGNER KEYS
|
||||
jeff 927f30366699
|
||||
security 5ac7d9af7222
|
||||
ian 5ac7d9af7222
|
||||
|
||||
Administrative keys for dtr.example.com/prod/nginx:1
|
||||
|
||||
|
|
@ -218,13 +214,12 @@ For more advanced use cases like this, see [Delegations for content trust](/engi
|
|||
|
||||
## Delete trust data
|
||||
|
||||
If an Administrator wants to delete a DTR repository that contains Trust
|
||||
metadata, they will be prompted to delete the trust metadata first before the
|
||||
repository can be removed.
|
||||
If an administrator wants to delete a DTR repository that contains trust
|
||||
metadata, they will be prompted to delete the trust metadata first before removing the repository.
|
||||
|
||||
To delete trust metadata we need to use the Notary CLI. For information on how
|
||||
to download and configure the Notary CLI head
|
||||
[here](/engine/security/trust/trust_delegation/#configuring-the-notary-client)
|
||||
To delete trust metadata, you need to use the Notary CLI. For information on how
|
||||
to download and configure the Notary CLI see
|
||||
[Configuring the Notary client](/engine/security/trust/trust_delegation/#configuring-the-notary-client)
|
||||
|
||||
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -75,12 +75,12 @@ To install UCP:
|
|||
To find what other options are available in the install command, check the
|
||||
[reference documentation](/reference/ucp/3.1/cli/install.md).
|
||||
|
||||
> Custom CNI plugins
|
||||
> Custom Container Networking Interface (CNI) plugins
|
||||
>
|
||||
> If you want to use a third-party Container Networking Interface (CNI) plugin,
|
||||
> like Flannel or Weave, modify the previous command line to include the
|
||||
> `--cni-installer-url` option. Learn how to
|
||||
> [install a CNI plugin](../../kubernetes/install-cni-plugin.md).
|
||||
> UCP will install [Project Calico](https://docs.projectcalico.org/v3.7/introduction/)
|
||||
> for container-to-container communication for Kubernetes. A platform operator may
|
||||
> choose to install an alternative CNI plugin, such as Weave or Flannel. Please see
|
||||
>[Install an unmanaged CNI plugin](/ee/ucp/kubernetes/install-cni-plugin/).
|
||||
{: important}
|
||||
|
||||
## Step 5: License your installation
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ this.
|
|||
|
||||
The `service-cluster-ip-range` Kubernetes API Server flag is currently set to `10.96.0.0/16` and cannot be changed.
|
||||
|
||||
Swarm uses a default address pool of `10.0.0.0/16` for its overlay networks. If this conflicts with your current network implementation, please use a custom IP address pool. To specify a custom IP address pool, use the `--default-address-pool` command line option during [Swarm initialization](../../../../engine/swarm/swarm-mode.md).
|
||||
Swarm uses a default address pool of `10.0.0.0/8` for its overlay networks. If this conflicts with your current network implementation, please use a custom IP address pool. To specify a custom IP address pool, use the `--default-address-pool` command line option during [Swarm initialization](../../../../engine/swarm/swarm-mode.md).
|
||||
|
||||
> **Note**: Currently, the UCP installation process does not support this flag. To deploy with a custom IP pool, Swarm must first be installed using this flag and UCP must be installed on top of it.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,98 +1,119 @@
|
|||
---
|
||||
title: Install a CNI plugin
|
||||
description: Learn how to install a Container Networking Interface plugin on Docker Universal Control Plane.
|
||||
keywords: ucp, cli, administration, kubectl, Kubernetes, cni, Container Networking Interface, flannel, weave, ipip, calico
|
||||
title: Install an unmanaged CNI plugin
|
||||
description: Learn how to install a Container Networking Interface (CNI) plugin on Docker Universal Control Plane.
|
||||
keywords: ucp, kubernetes, cni, container networking interface, flannel, weave, calico
|
||||
---
|
||||
|
||||
For Docker Universal Control Plane, [Project Calico](https://docs.projectcalico.org/v3.0/introduction/)
|
||||
provides the secure networking functionality for the container communication with Kubernetes.
|
||||
For Docker Universal Control Plane (UCP), [Calico](https://docs.projectcalico.org/v3.7/introduction/)
|
||||
provides the secure networking functionality for container-to-container communication within
|
||||
Kubernetes. UCP handles the lifecycle of Calico and packages it with UCP
|
||||
installation and upgrade. Additionally, the Calico deployment included with
|
||||
UCP is fully supported with Docker providing guidance on the
|
||||
[CNI components](https://github.com/projectcalico/cni-plugin).
|
||||
|
||||
Docker EE supports Calico and installs the
|
||||
built-in [Calico](https://github.com/projectcalico/cni-plugin) plugin, but you can override that and
|
||||
install a Docker certified plugin.
|
||||
At install time, UCP can be configured to install an alternative CNI plugin
|
||||
to support alternative use cases. The alternative CNI plugin is certified by
|
||||
Docker and its partners, and published on Docker Hub. UCP components are still
|
||||
fully supported by Docker and respective partners. Docker will provide
|
||||
pointers to basic configuration, however for additional guidance on managing third party
|
||||
CNI components, the platform operator will need to refer to the partner documentation
|
||||
or contact that third party.
|
||||
|
||||
> **Note**: The `--cni-installer-url` option is deprecated as of UCP 3.1. It is replaced by the `--unmanaged-cni` option.
|
||||
## Install an unmanaged CNI plugin on Docker UCP
|
||||
|
||||
# Install UCP with a custom CNI plugin
|
||||
Once a platform operator has complied with [UCP system
|
||||
requirements](/ee/ucp/admin/install/system-requirements/) and
|
||||
taken into consideration any requirements for the custom CNI plugin, you can
|
||||
[run the UCP install command](/reference/ucp/3.1/cli/install/) with the `--unmanaged-cni` flag
|
||||
to bring up the platform.
|
||||
|
||||
Modify the [UCP install command-line](../admin/install/index.md#step-4-install-ucp)
|
||||
to add the `--cni-installer-url` [option](/reference/ucp/3.0/cli/install.md),
|
||||
providing a URL for the location of the CNI plugin's YAML file:
|
||||
This command will install UCP, and bring up components
|
||||
like the user interface and the RBAC engine. UCP components that
|
||||
require Kubernetes Networking, such as Metrics, will not start and will stay in
|
||||
a `Container Creating` state in Kubernetes, until a CNI is installed.
|
||||
|
||||
### Install UCP without a CNI plugin
|
||||
|
||||
Once connected to a manager node with the Docker Enterprise Engine installed,
|
||||
you are ready to install UCP with the `--unmanaged-cni` flag.
|
||||
|
||||
```bash
|
||||
docker container run --rm -it --name ucp \
|
||||
-v /var/run/docker.sock:/var/run/docker.sock \
|
||||
{{ page.ucp_org }}/{{ page.ucp_repo }}:{{ page.ucp_version }} install \
|
||||
--host-address <node-ip-address> \
|
||||
--unmanaged-cni <true|false> \
|
||||
--unmanaged-cni \
|
||||
--interactive
|
||||
```
|
||||
|
||||
> **Note**: Setting `--unmanaged-cni` to `true` value installs UCP without a managed CNI plugin. UCP and the
|
||||
> Kubernetes components will be running but pod-to-pod networking will not function until a CNI plugin is manually
|
||||
> installed. This will impact some functionality of UCP until a CNI plugin is running.
|
||||
Once the installation is complete, you will be able to access UCP in the browser.
|
||||
Note that the manager node will be unhealthy as the kubelet will
|
||||
report `NetworkPluginNotReady`. Additionally, the metrics in the UCP dashboard
|
||||
will also be unavailable, as this runs in a Kubernetes pod.
|
||||
|
||||
You must provide a correct YAML installation file for the CNI plugin, but most
|
||||
of the default files work on Docker EE with no modification.
|
||||
### Configure CLI access to UCP
|
||||
|
||||
## YAML files for CNI plugins
|
||||
|
||||
Use the following commands to get the YAML files for popular CNI plugins.
|
||||
|
||||
- [Flannel](https://github.com/coreos/flannel)
|
||||
```bash
|
||||
# Get the URL for the Flannel CNI plugin.
|
||||
CNI_URL="https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml"
|
||||
```
|
||||
- [Weave](https://www.weave.works/)
|
||||
```bash
|
||||
# Get the URL for the Weave CNI plugin.
|
||||
CNI_URL="https://cloud.weave.works/k8s/net?k8s-version=Q2xpZW50IFZlcnNpb246IHZlcnNpb24uSW5mb3tNYWpvcjoiMSIsIE1pbm9yOiI5IiwgR2l0VmVyc2lvbjoidjEuOS4zIiwgR2l0Q29tbWl0OiJkMjgzNTQxNjU0NGYyOThjOTE5ZTJlYWQzYmUzZDA4NjRiNTIzMjNiIiwgR2l0VHJlZVN0YXRlOiJjbGVhbiIsIEJ1aWxkRGF0ZToiMjAxOC0wMi0wN1QxMjoyMjoyMVoiLCBHb1ZlcnNpb246ImdvMS45LjIiLCBDb21waWxlcjoiZ2MiLCBQbGF0Zm9ybToibGludXgvYW1kNjQifQpTZXJ2ZXIgVmVyc2lvbjogdmVyc2lvbi5JbmZve01ham9yOiIxIiwgTWlub3I6IjgrIiwgR2l0VmVyc2lvbjoidjEuOC4yLWRvY2tlci4xNDMrYWYwODAwNzk1OWUyY2UiLCBHaXRDb21taXQ6ImFmMDgwMDc5NTllMmNlYWUxMTZiMDk4ZWNhYTYyNGI0YjI0MjBkODgiLCBHaXRUcmVlU3RhdGU6ImNsZWFuIiwgQnVpbGREYXRlOiIyMDE4LTAyLTAxVDIzOjI2OjE3WiIsIEdvVmVyc2lvbjoiZ28xLjguMyIsIENvbXBpbGVyOiJnYyIsIFBsYXRmb3JtOiJsaW51eC9hbWQ2NCJ9Cg=="
|
||||
```
|
||||
If you have kubectl available, for example by using
|
||||
[Docker Desktop for Mac](/docker-for-mac/kubernetes.md), you can use the following
|
||||
command to get the URL for the [Weave](https://www.weave.works/) CNI plugin:
|
||||
```bash
|
||||
# Get the URL for the Weave CNI plugin.
|
||||
CNI_URL="https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
|
||||
```
|
||||
- [Romana](http://docs.romana.io/)
|
||||
```bash
|
||||
# Get the URL for the Romana CNI plugin.
|
||||
CNI_URL="https://raw.githubusercontent.com/romana/romana/master/docs/kubernetes/romana-kubeadm.yml"
|
||||
```
|
||||
|
||||
## Disable IP in IP overlay tunneling
|
||||
|
||||
The Calico CNI plugin supports both overlay (IPIP) and underlay forwarding
|
||||
technologies. By default, Docker UCP uses IPIP overlay tunneling.
|
||||
|
||||
If you're used to managing applications at the network level through the
|
||||
underlay visibility, or you want to reuse existing networking tools in the
|
||||
underlay, you may want to disable the IPIP functionality. Run the following
|
||||
commands on the Kubernetes master node to disable IPIP overlay tunneling.
|
||||
Next, a platform operator should log into UCP, download a UCP client bundle, and
|
||||
configure the Kubernetes CLI tool, `kubectl`. See [CLI Based
|
||||
Access](ee/ucp/user-access/cli/#download-client-certificates) for more details.
|
||||
|
||||
With `kubectl`, you can see that the UCP components running on
|
||||
Kubernetes are still pending, waiting for a CNI driver before becoming
|
||||
available.
|
||||
|
||||
```bash
|
||||
# Exec into the Calico Kubernetes controller container.
|
||||
docker exec -it $(docker ps --filter name=k8s_calico-kube-controllers_calico-kube-controllers -q) sh
|
||||
|
||||
# Download calicoctl
|
||||
wget https://github.com/projectcalico/calicoctl/releases/download/v3.1.1/calicoctl && chmod +x calicoctl
|
||||
|
||||
# Get the IP pool configuration.
|
||||
./calicoctl get ippool -o yaml > ippool.yaml
|
||||
|
||||
# Edit the file: Disable IPIP in ippool.yaml by setting "ipipMode: Never".
|
||||
|
||||
# Apply the edited file to the Calico plugin.
|
||||
./calicoctl apply -f ippool.yaml
|
||||
|
||||
$ kubectl get nodes
|
||||
NAME STATUS ROLES AGE VERSION
|
||||
manager-01 NotReady master 10m v1.11.9-docker-1
|
||||
|
||||
$ kubectl get pods -n kube-system -o wide
|
||||
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
|
||||
compose-565f7cf9ff-gq2gv 0/1 Pending 0 10m <none> <none> <none>
|
||||
compose-api-574d64f46f-r4c5g 0/1 Pending 0 10m <none> <none> <none>
|
||||
kube-dns-6d96c4d9c6-8jzv7 0/3 Pending 0 10m <none> <none> <none>
|
||||
ucp-metrics-nwt2z 0/3 ContainerCreating 0 10m <none> manager-01 <none>
|
||||
```
|
||||
|
||||
These steps disable overlay tunneling, and Calico uses the underlay networking,
|
||||
in environments where it's supported.
|
||||
### Install an unmanaged CNI plugin
|
||||
|
||||
You can use`kubectl` to install a custom CNI plugin on UCP.
|
||||
Alternative CNI plugins are Weave, Flannel, Canal, Romana and many more.
|
||||
Platform operators have complete flexibility on what to install, but Docker
|
||||
will not support the CNI plugin.
|
||||
|
||||
The steps for installing a CNI plugin typically include:
|
||||
- Downloading the relevant upstream CNI binaries from
|
||||
https://github.com/containernetworking/cni/releases/tag/
|
||||
- Placing them in `/opt/cni/bin`
|
||||
- Downloading the relevant CNI plugin's Kubernetes Manifest YAML, and
|
||||
- Running `$ kubectl apply -f <your-custom-cni-plugin>.yaml`
|
||||
|
||||
Follow the CNI plugin documentation for specific installation
|
||||
instructions.
|
||||
|
||||
> While troubleshooting a custom CNI plugin, you may wish to access logs
|
||||
> within the kubelet. Connect to a UCP manager node and run
|
||||
> `$ docker logs ucp-kubelet`.
|
||||
|
||||
### Verify the UCP installation
|
||||
|
||||
Upon successful installation of the CNI plugin, the related UCP components should have
|
||||
a `Running` status as pods start to become available.
|
||||
|
||||
```
|
||||
$ kubectl get pods -n kube-system -o wide
|
||||
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
|
||||
compose-565f7cf9ff-gq2gv 1/1 Running 0 21m 10.32.0.2 manager-01 <none>
|
||||
compose-api-574d64f46f-r4c5g 1/1 Running 0 21m 10.32.0.3 manager-01 <none>
|
||||
kube-dns-6d96c4d9c6-8jzv7 3/3 Running 0 22m 10.32.0.5 manager-01 <none>
|
||||
ucp-metrics-nwt2z 3/3 Running 0 22m 10.32.0.4 manager-01 <none>
|
||||
weave-net-wgvcd 2/2 Running 0 8m 172.31.6.95 manager-01 <none>
|
||||
```
|
||||
|
||||
> **Note**: The above example deployment uses Weave. If you are using an alternative
|
||||
> CNI plugin, look for the relevant name and review its status.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Install UCP for production](../admin/install.md)
|
||||
- [Deploy a workload to a Kubernetes cluster](../kubernetes.md)
|
||||
- [Make your Cluster Highly Available](https://docs.docker.com/ee/ucp/admin/install/#step-6-join-manager-nodes)
|
||||
- [Install an Ingress Controller on Kubernetes](ee/ucp/kubernetes/layer-7-routing/)
|
||||
|
|
|
|||
18
index.md
18
index.md
|
|
@ -22,14 +22,14 @@ production servers in the cloud. Total reading time is less than an hour.
|
|||
</div>
|
||||
<div markdown="1" class="col-xs-12 col-sm-12 col-md-12 col-lg-6 block">
|
||||
|
||||
## Try Docker Enterprise Edition
|
||||
## Try Docker Enterprise
|
||||
|
||||
Run your solution in production with Docker Enterprise Edition to get a
|
||||
Run your solution in production with Docker Enterprise to get a
|
||||
management dashboard, security scanning, LDAP integration, content signing,
|
||||
multi-cloud support, and more. Click below to test-drive a running instance of
|
||||
Docker EE without installing anything.
|
||||
Docker Enterprise without installing anything.
|
||||
|
||||
[Try Docker Enterprise Edition](https://trial.docker.com){: class="button outline-btn" onclick="ga('send', 'event', 'EE Trial Referral', 'Front Page', 'Click');"}
|
||||
[Try Docker Enterprise](https://trial.docker.com){: class="button outline-btn" onclick="ga('send', 'event', 'EE Trial Referral', 'Front Page', 'Click');"}
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
|
@ -52,15 +52,17 @@ channel for more predictability.
|
|||
</div>
|
||||
<div markdown="1" class="col-xs-12 col-sm-12 col-md-12 col-lg-6 block">
|
||||
|
||||
### Docker Enterprise Edition
|
||||
### Docker Enterprise Platform
|
||||
|
||||
Designed for enterprise development and IT teams who build, ship, and run
|
||||
business critical applications in production at scale. Integrated, certified,
|
||||
and supported to provide enterprises with the most secure container platform in
|
||||
the industry to modernize all applications. Docker EE Advanced comes with enterprise
|
||||
[add-ons](#docker-ee-add-ons) like UCP and DTR.
|
||||
the industry to modernize all applications. Docker Enterprise Advanced comes with enterprise
|
||||
[add-ons](#docker-ee-add-ons) like Universal Control Plane (UCP) for managing and
|
||||
orchestrating the container runtime, and Docker Trusted Registry (DTR) for storing and
|
||||
securing images in an enterprise grade registry.
|
||||
|
||||
[Learn more about Docker EE](/ee/supported-platforms/){: class="button outline-btn"}
|
||||
[Learn more about Docker Enterprise](/ee/supported-platforms/){: class="button outline-btn"}
|
||||
|
||||
</div>
|
||||
</div><!-- end row -->
|
||||
|
|
|
|||
|
|
@ -16,7 +16,10 @@ your applications and avoid performance problems along the way.
|
|||
|
||||
Storage drivers allow you to create data in the writable layer of your container.
|
||||
The files won't be persisted after the container is deleted, and both read and
|
||||
write speeds are low.
|
||||
write speeds are lower than native file system performance.
|
||||
|
||||
> **Note**: Operations that are known to be problematic include write-intensive database storage,
|
||||
particularly when pre-existing data exists in the write-only layer. More details are provided in this document.
|
||||
|
||||
[Learn how to use volumes](../volumes.md) to persist data and improve performance.
|
||||
|
||||
|
|
@ -27,14 +30,14 @@ instruction in the image's Dockerfile. Each layer except the very last one is
|
|||
read-only. Consider the following Dockerfile:
|
||||
|
||||
```conf
|
||||
FROM ubuntu:15.04
|
||||
FROM ubuntu:18.04
|
||||
COPY . /app
|
||||
RUN make /app
|
||||
CMD python /app/app.py
|
||||
```
|
||||
|
||||
This Dockerfile contains four commands, each of which creates a layer. The
|
||||
`FROM` statement starts out by creating a layer from the `ubuntu:15.04` image.
|
||||
`FROM` statement starts out by creating a layer from the `ubuntu:18.04` image.
|
||||
The `COPY` command adds some files from your Docker client's current directory.
|
||||
The `RUN` command builds your application using the `make` command. Finally,
|
||||
the last layer specifies what command to run within the container.
|
||||
|
|
@ -45,7 +48,7 @@ writable layer on top of the underlying layers. This layer is often called the
|
|||
"container layer". All changes made to the running container, such as writing
|
||||
new files, modifying existing files, and deleting files, are written to this thin
|
||||
writable container layer. The diagram below shows a container based on the Ubuntu
|
||||
15.04 image.
|
||||
18.04 image.
|
||||
|
||||
|
||||
|
||||
|
|
@ -63,7 +66,7 @@ deleted. The underlying image remains unchanged.
|
|||
Because each container has its own writable container layer, and all changes are
|
||||
stored in this container layer, multiple containers can share access to the same
|
||||
underlying image and yet have their own data state. The diagram below shows
|
||||
multiple containers sharing the same Ubuntu 15.04 image.
|
||||
multiple containers sharing the same Ubuntu 18.04 image.
|
||||
|
||||
|
||||
|
||||
|
|
@ -130,28 +133,28 @@ usually `/var/lib/docker/` on Linux hosts. You can see these layers being pulled
|
|||
in this example:
|
||||
|
||||
```bash
|
||||
$ docker pull ubuntu:15.04
|
||||
|
||||
15.04: Pulling from library/ubuntu
|
||||
1ba8ac955b97: Pull complete
|
||||
f157c4e5ede7: Pull complete
|
||||
0b7e98f84c4c: Pull complete
|
||||
a3ed95caeb02: Pull complete
|
||||
Digest: sha256:5e279a9df07990286cce22e1b0f5b0490629ca6d187698746ae5e28e604a640e
|
||||
Status: Downloaded newer image for ubuntu:15.04
|
||||
$ docker pull ubuntu:18.04
|
||||
18.04: Pulling from library/ubuntu
|
||||
f476d66f5408: Pull complete
|
||||
8882c27f669e: Pull complete
|
||||
d9af21273955: Pull complete
|
||||
f5029279ec12: Pull complete
|
||||
Digest: sha256:ab6cb8de3ad7bb33e2534677f865008535427390b117d7939193f8d1a6613e34
|
||||
Status: Downloaded newer image for ubuntu:18.04
|
||||
```
|
||||
|
||||
Each of these layers is stored in its own directory inside the Docker host's
|
||||
local storage area. To examine the layers on the filesystem, list the contents
|
||||
of `/var/lib/docker/<storage-driver>/layers/`. This example uses the `aufs`
|
||||
of `/var/lib/docker/<storage-driver>`. This example uses the `overlay2`
|
||||
storage driver:
|
||||
|
||||
```bash
|
||||
$ ls /var/lib/docker/aufs/layers
|
||||
1d6674ff835b10f76e354806e16b950f91a191d3b471236609ab13a930275e24
|
||||
5dbb0cbe0148cf447b9464a358c1587be586058d9a4c9ce079320265e2bb94e7
|
||||
bef7199f2ed8e86fa4ada1309cfad3089e0542fec8894690529e4c04a7ca2d73
|
||||
ebf814eccfe98f2704660ca1d844e4348db3b5ccc637eb905d4818fbfb00a06a
|
||||
$ ls /var/lib/docker/overlay2
|
||||
16802227a96c24dcbeab5b37821e2b67a9f921749cd9a2e386d5a6d5bc6fc6d3
|
||||
377d73dbb466e0bc7c9ee23166771b35ebdbe02ef17753d79fd3571d4ce659d7
|
||||
3f02d96212b03e3383160d31d7c6aeca750d2d8a1879965b89fe8146594c453d
|
||||
ec1ec45792908e90484f7e629330666e7eee599f08729c93890a7205a6ba35f5
|
||||
l
|
||||
```
|
||||
|
||||
The directory names do not correspond to the layer IDs (this has been true since
|
||||
|
|
@ -161,7 +164,7 @@ Now imagine that you have two different Dockerfiles. You use the first one to
|
|||
create an image called `acme/my-base-image:1.0`.
|
||||
|
||||
```conf
|
||||
FROM ubuntu:16.10
|
||||
FROM ubuntu:18.04
|
||||
COPY . /app
|
||||
```
|
||||
|
||||
|
|
@ -209,10 +212,9 @@ layers are the same.
|
|||
|
||||
```bash
|
||||
$ docker build -t acme/my-base-image:1.0 -f Dockerfile.base .
|
||||
|
||||
Sending build context to Docker daemon 4.096kB
|
||||
Step 1/2 : FROM ubuntu:16.10
|
||||
---> 31005225a745
|
||||
Sending build context to Docker daemon 812.4MB
|
||||
Step 1/2 : FROM ubuntu:18.04
|
||||
---> d131e0fa2585
|
||||
Step 2/2 : COPY . /app
|
||||
---> Using cache
|
||||
---> bd09118bcef6
|
||||
|
|
@ -252,7 +254,7 @@ layers are the same.
|
|||
$ docker history bd09118bcef6
|
||||
IMAGE CREATED CREATED BY SIZE COMMENT
|
||||
bd09118bcef6 4 minutes ago /bin/sh -c #(nop) COPY dir:35a7eb158c1504e... 100B
|
||||
31005225a745 3 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B
|
||||
d131e0fa2585 3 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B
|
||||
<missing> 3 months ago /bin/sh -c mkdir -p /run/systemd && echo '... 7B
|
||||
<missing> 3 months ago /bin/sh -c sed -i 's/^#\s*\(deb.*universe\... 2.78kB
|
||||
<missing> 3 months ago /bin/sh -c rm -rf /var/lib/apt/lists/* 0B
|
||||
|
|
@ -266,7 +268,7 @@ layers are the same.
|
|||
IMAGE CREATED CREATED BY SIZE COMMENT
|
||||
dbf995fc07ff 3 minutes ago /bin/sh -c #(nop) CMD ["/bin/sh" "-c" "/a... 0B
|
||||
bd09118bcef6 5 minutes ago /bin/sh -c #(nop) COPY dir:35a7eb158c1504e... 100B
|
||||
31005225a745 3 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B
|
||||
d131e0fa2585 3 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B
|
||||
<missing> 3 months ago /bin/sh -c mkdir -p /run/systemd && echo '... 7B
|
||||
<missing> 3 months ago /bin/sh -c sed -i 's/^#\s*\(deb.*universe\... 2.78kB
|
||||
<missing> 3 months ago /bin/sh -c rm -rf /var/lib/apt/lists/* 0B
|
||||
|
|
|
|||
Loading…
Reference in New Issue