toolshed/docker-cli
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Enabled GitHub Flavored Markdown

Browse Source 
GitHub flavored markdown is now supported for links and images. Also, ran LinkChecker and FileResolver. Yay!
Fixes from Spider check
Output for docker/docker now goes into engine directory

Signed-off-by: Mary Anthony <mary@docker.com>
Upstream-commit: 8fee1c2020186ac100b45e64864b94ae3a169ad5
Component: engine
This commit is contained in:
Mary Anthony
2015-10-09 16:50:41 -07:00
parent 9816980864
commit 6b6c7cc2b6
112 changed files with 502 additions and 630 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
components/engine/docs/security/trust/content_trust.md
View File

@ -61,7 +61,7 @@ tag could be unsigned while the `3.1.6` tag could be signed. It is the
responsibility of the image publisher to decide if an image tag is signed or
not. In this representation, some image tags are signed, others are not:
![Signed tags](../images/tag_signing.png)
![Signed tags](images/tag_signing.png)
Publishers can choose to sign a specific tag or not. As a result, the content of
an unsigned tag and that of a signed tag with the same name may not match. For
@ -77,7 +77,7 @@ with trusted images. Enabling content trust is like wearing a pair of
rose-colored glasses. Consumers "see" only signed images tags and the less
desirable, unsigned image tags are "invisible" to them.
![Trust view](../images/trust_view.png)
![Trust view](images/trust_view.png)
To the consumer who does not enabled content trust, nothing about how they
work with Docker images changes. Every image is visible regardless of whether it
@ -121,7 +121,7 @@ service that isn't directly exposed to the internet and are encrypted at rest.
The following image depicts the various signing keys and their relationships:
![Content trust components](../images/trust_components.png)
![Content trust components](images/trust_components.png)
>**WARNING**: Loss of the root key is **very difficult** to recover from.
>Correcting this loss requires intervention from [Docker
@ -131,8 +131,8 @@ The following image depicts the various signing keys and their relationships:
You should backup the root key somewhere safe. Given that it is only required
to create new repositories, it is a good idea to store it offline. Make sure you
read [Manage keys for content trust](/security/trust/trust_key_mng) information
for details on securing, and backing up your keys.
read [Manage keys for content trust](trust_key_mng.md) information
for details on securing, and backing up your keys.
## Survey of typical content trust operations
@ -297,6 +297,6 @@ $ docker push --disable-content-trust docker/trusttest:untrusted
## Related information
* [Manage keys for content trust](/security/trust/trust_key_mng)
* [Automation with content trust](/security/trust/trust_automation)
* [Play in a content trust sandbox](/security/trust/trust_sandbox)
* [Manage keys for content trust](trust_key_mng.md)
* [Automation with content trust](trust_automation.md)
* [Play in a content trust sandbox](trust_sandbox.md)

8
components/engine/docs/security/trust/index.md
View File

@ -14,8 +14,8 @@ weight=4
The following topics are available:
* [Content trust in Docker](/security/trust/content_trust)
* [Manage keys for content trust](/security/trust/trust_key_mng)
* [Automation with content trust](/security/trust/trust_automation)
* [Play in a content trust sandbox](/security/trust/trust_sandbox)
* [Content trust in Docker](content_trust.md)
* [Manage keys for content trust](trust_key_mng.md)
* [Automation with content trust](trust_automation.md)
* [Play in a content trust sandbox](trust_sandbox.md)

6
components/engine/docs/security/trust/trust_automation.md
View File

@ -73,7 +73,7 @@ unable to process Dockerfile: No trust data for notrust
## Related information
* [Content trust in Docker](/security/trust/content_trust)
* [Manage keys for content trust](/security/trust/trust_key_mng)
* [Play in a content trust sandbox](/security/trust/trust_sandbox)
* [Content trust in Docker](content_trust.md)
* [Manage keys for content trust](trust_key_mng.md)
* [Play in a content trust sandbox](trust_sandbox.md)

6
components/engine/docs/security/trust/trust_key_mng.md
View File

@ -68,6 +68,6 @@ the new key.
## Related information
* [Content trust in Docker](/security/trust/content_trust)
* [Automation with content trust](/security/trust/trust_automation)
* [Play in a content trust sandbox](/security/trust/trust_sandbox)
* [Content trust in Docker](content_trust.md)
* [Automation with content trust](trust_automation.md)
* [Play in a content trust sandbox](trust_sandbox.md)

6
components/engine/docs/security/trust/trust_sandbox.md
View File

@ -15,7 +15,7 @@ The sandbox allows you to configure and try trust operations locally without
impacting your production images.
Before working through this sandbox, you should have read through the [trust
overview](/security/trust/content_trust).
overview](content_trust.md).
### Prerequisites
@ -25,8 +25,8 @@ have `sudo` privileges on your local machine or in the VM.
This sandbox requires you to install two Docker tools: Docker Engine and Docker
Compose. To install the Docker Engine, choose from the [list of supported
platforms](/installation). To install Docker Compose, see the
[detailed instructions here](/compose/install).
platforms](../../installation). To install Docker Compose, see the
[detailed instructions here](https://docs.docker.com/compose/install.md).
Finally, you'll need to have `git` installed on your local system or VM.