image spec formatting fix
Embedded new lines aren't interpreted correctly in markdown renderers (they are treated as preformatted text instead). I removed the embedded newlines in the docker image spec. Signed-off-by: Alex Goodman <wagoodman@gmail.com>
This commit is contained in:
Alex Goodman
Alex Goodman
parent
996eb78fb8
commit
4fb59c20a4
|
|
@ -223,9 +223,7 @@ whitespace. It has been added to this example for clarity.
|
|||
container using the image. This field can be <code>null</code>, in
|
||||
which case any execution parameters should be specified at creation of
|
||||
the container.
|
||||
|
||||
<h4>Container RunConfig Field Descriptions</h4>
|
||||
|
||||
<dl>
|
||||
<dt>
|
||||
User <code>string</code>
|
||||
|
|
@ -234,9 +232,7 @@ whitespace. It has been added to this example for clarity.
|
|||
<p>The username or UID which the process in the container should
|
||||
run as. This acts as a default value to use when the value is
|
||||
not specified when creating a container.</p>
|
||||
|
||||
<p>All of the following are valid:</p>
|
||||
|
||||
<ul>
|
||||
<li><code>user</code></li>
|
||||
<li><code>uid</code></li>
|
||||
|
|
@ -245,7 +241,6 @@ whitespace. It has been added to this example for clarity.
|
|||
<li><code>uid:group</code></li>
|
||||
<li><code>user:gid</code></li>
|
||||
</ul>
|
||||
|
||||
<p>If <code>group</code>/<code>gid</code> is not specified, the
|
||||
default group and supplementary groups of the given
|
||||
<code>user</code>/<code>uid</code> in <code>/etc/passwd</code>
|
||||
|
|
@ -284,13 +279,11 @@ whitespace. It has been added to this example for clarity.
|
|||
<code>map[string]struct{}</code> and is represented in JSON as
|
||||
an object mapping its keys to an empty object. Here is an
|
||||
example:
|
||||
|
||||
<pre>{
|
||||
"8080": {},
|
||||
"53/udp": {},
|
||||
"2356/tcp": {}
|
||||
}</pre>
|
||||
|
||||
Its keys can be in the format of:
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -304,10 +297,8 @@ whitespace. It has been added to this example for clarity.
|
|||
</li>
|
||||
</ul>
|
||||
with the default protocol being <code>"tcp"</code> if not
|
||||
specified.
|
||||
|
||||
These values act as defaults and are merged with any specified
|
||||
when creating a container.
|
||||
specified. These values act as defaults and are merged with any
|
||||
specified when creating a container.
|
||||
</dd>
|
||||
<dt>
|
||||
Env <code>array of strings</code>
|
||||
|
|
@ -367,7 +358,6 @@ whitespace. It has been added to this example for clarity.
|
|||
The rootfs key references the layer content addresses used by the
|
||||
image. This makes the image config hash depend on the filesystem hash.
|
||||
rootfs has two subkeys:
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<code>type</code> is usually set to <code>layers</code>.
|
||||
|
|
@ -376,10 +366,7 @@ whitespace. It has been added to this example for clarity.
|
|||
<code>diff_ids</code> is an array of layer content hashes (<code>DiffIDs</code>), in order from bottom-most to top-most.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
Here is an example rootfs section:
|
||||
|
||||
<pre>"rootfs": {
|
||||
"diff_ids": [
|
||||
"sha256:c6f988f4874bb0add23a778f753c65efe992244e148a1d2ec2a8b664fb66bbd1",
|
||||
|
|
@ -396,7 +383,6 @@ whitespace. It has been added to this example for clarity.
|
|||
<code>history</code> is an array of objects describing the history of
|
||||
each layer. The array is ordered from bottom-most layer to top-most
|
||||
layer. The object has the following fields.
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<code>created</code>: Creation time, expressed as a ISO-8601 formatted
|
||||
|
|
|
|||
|
|
@ -223,9 +223,7 @@ whitespace. It has been added to this example for clarity.
|
|||
container using the image. This field can be <code>null</code>, in
|
||||
which case any execution parameters should be specified at creation of
|
||||
the container.
|
||||
|
||||
<h4>Container RunConfig Field Descriptions</h4>
|
||||
|
||||
<dl>
|
||||
<dt>
|
||||
User <code>string</code>
|
||||
|
|
@ -234,9 +232,7 @@ whitespace. It has been added to this example for clarity.
|
|||
<p>The username or UID which the process in the container should
|
||||
run as. This acts as a default value to use when the value is
|
||||
not specified when creating a container.</p>
|
||||
|
||||
<p>All of the following are valid:</p>
|
||||
|
||||
<ul>
|
||||
<li><code>user</code></li>
|
||||
<li><code>uid</code></li>
|
||||
|
|
@ -245,7 +241,6 @@ whitespace. It has been added to this example for clarity.
|
|||
<li><code>uid:group</code></li>
|
||||
<li><code>user:gid</code></li>
|
||||
</ul>
|
||||
|
||||
<p>If <code>group</code>/<code>gid</code> is not specified, the
|
||||
default group and supplementary groups of the given
|
||||
<code>user</code>/<code>uid</code> in <code>/etc/passwd</code>
|
||||
|
|
@ -284,13 +279,11 @@ whitespace. It has been added to this example for clarity.
|
|||
<code>map[string]struct{}</code> and is represented in JSON as
|
||||
an object mapping its keys to an empty object. Here is an
|
||||
example:
|
||||
|
||||
<pre>{
|
||||
"8080": {},
|
||||
"53/udp": {},
|
||||
"2356/tcp": {}
|
||||
}</pre>
|
||||
|
||||
Its keys can be in the format of:
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -304,10 +297,8 @@ whitespace. It has been added to this example for clarity.
|
|||
</li>
|
||||
</ul>
|
||||
with the default protocol being <code>"tcp"</code> if not
|
||||
specified.
|
||||
|
||||
These values act as defaults and are merged with any specified
|
||||
when creating a container.
|
||||
specified. These values act as defaults and are merged with
|
||||
any specified when creating a container.
|
||||
</dd>
|
||||
<dt>
|
||||
Env <code>array of strings</code>
|
||||
|
|
@ -364,7 +355,6 @@ whitespace. It has been added to this example for clarity.
|
|||
<li><code>["CMD", arg1, arg2, ...]</code> : exec arguments directly</li>
|
||||
<li><code>["CMD-SHELL", command]</code> : run command with system's default shell</li>
|
||||
</ul>
|
||||
|
||||
The test command should exit with a status of 0 if the container is healthy,
|
||||
or with 1 if it is unhealthy.
|
||||
</dd>
|
||||
|
|
@ -387,12 +377,10 @@ whitespace. It has been added to this example for clarity.
|
|||
The number of consecutive failures needed to consider a container as unhealthy.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
In each case, the field can be omitted to indicate that the
|
||||
value should be inherited from the base layer.
|
||||
|
||||
These values act as defaults and are merged with any specified
|
||||
when creating a container.
|
||||
value should be inherited from the base layer. These values act
|
||||
as defaults and are merged with any specified when creating a
|
||||
container.
|
||||
</dd>
|
||||
<dt>
|
||||
Volumes <code>struct</code>
|
||||
|
|
@ -426,7 +414,6 @@ whitespace. It has been added to this example for clarity.
|
|||
The rootfs key references the layer content addresses used by the
|
||||
image. This makes the image config hash depend on the filesystem hash.
|
||||
rootfs has two subkeys:
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<code>type</code> is usually set to <code>layers</code>.
|
||||
|
|
@ -435,10 +422,7 @@ whitespace. It has been added to this example for clarity.
|
|||
<code>diff_ids</code> is an array of layer content hashes (<code>DiffIDs</code>), in order from bottom-most to top-most.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
Here is an example rootfs section:
|
||||
|
||||
<pre>"rootfs": {
|
||||
"diff_ids": [
|
||||
"sha256:c6f988f4874bb0add23a778f753c65efe992244e148a1d2ec2a8b664fb66bbd1",
|
||||
|
|
@ -455,7 +439,6 @@ whitespace. It has been added to this example for clarity.
|
|||
<code>history</code> is an array of objects describing the history of
|
||||
each layer. The array is ordered from bottom-most layer to top-most
|
||||
layer. The object has the following fields.
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<code>created</code>: Creation time, expressed as a ISO-8601 formatted
|
||||
|
|
@ -478,9 +461,7 @@ whitespace. It has been added to this example for clarity.
|
|||
filesystem).
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
Here is an example history section:
|
||||
|
||||
Here is an example history section:
|
||||
<pre>"history": [
|
||||
{
|
||||
"created": "2015-10-31T22:22:54.690851953Z",
|
||||
|
|
|
|||
|
|
@ -17,12 +17,10 @@ This specification uses the following terms:
|
|||
<dd>
|
||||
Images are composed of <i>layers</i>. <i>Image layer</i> is a general
|
||||
term which may be used to refer to one or both of the following:
|
||||
|
||||
<ol>
|
||||
<li>The metadata for the layer, described in the JSON format.</li>
|
||||
<li>The filesystem changes described by a layer.</li>
|
||||
</ol>
|
||||
|
||||
To refer to the former you may use the term <i>Layer JSON</i> or
|
||||
<i>Layer Metadata</i>. To refer to the latter you may use the term
|
||||
<i>Image Filesystem Changeset</i> or <i>Image Diff</i>.
|
||||
|
|
@ -244,9 +242,7 @@ Here is an example image JSON file:
|
|||
container using the image. This field can be <code>null</code>, in
|
||||
which case any execution parameters should be specified at creation of
|
||||
the container.
|
||||
|
||||
<h4>Container RunConfig Field Descriptions</h4>
|
||||
|
||||
<dl>
|
||||
<dt>
|
||||
User <code>string</code>
|
||||
|
|
@ -255,9 +251,7 @@ Here is an example image JSON file:
|
|||
<p>The username or UID which the process in the container should
|
||||
run as. This acts as a default value to use when the value is
|
||||
not specified when creating a container.</p>
|
||||
|
||||
<p>All of the following are valid:</p>
|
||||
|
||||
<ul>
|
||||
<li><code>user</code></li>
|
||||
<li><code>uid</code></li>
|
||||
|
|
@ -266,7 +260,6 @@ Here is an example image JSON file:
|
|||
<li><code>uid:group</code></li>
|
||||
<li><code>user:gid</code></li>
|
||||
</ul>
|
||||
|
||||
<p>If <code>group</code>/<code>gid</code> is not specified, the
|
||||
default group and supplementary groups of the given
|
||||
<code>user</code>/<code>uid</code> in <code>/etc/passwd</code>
|
||||
|
|
@ -305,13 +298,11 @@ Here is an example image JSON file:
|
|||
<code>map[string]struct{}</code> and is represented in JSON as
|
||||
an object mapping its keys to an empty object. Here is an
|
||||
example:
|
||||
|
||||
<pre>{
|
||||
"8080": {},
|
||||
"53/udp": {},
|
||||
"2356/tcp": {}
|
||||
}</pre>
|
||||
|
||||
Its keys can be in the format of:
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -325,9 +316,7 @@ Here is an example image JSON file:
|
|||
</li>
|
||||
</ul>
|
||||
with the default protocol being <code>"tcp"</code> if not
|
||||
specified.
|
||||
|
||||
These values act as defaults and are merged with any specified
|
||||
specified. These values act as defaults and are merged with any specified
|
||||
when creating a container.
|
||||
</dd>
|
||||
<dt>
|
||||
|
|
@ -502,21 +491,21 @@ For example, here's what the full archive of `library/busybox` is (displayed in
|
|||
```
|
||||
.
|
||||
├── 5785b62b697b99a5af6cd5d0aabc804d5748abbb6d3d07da5d1d3795f2dcc83e
|
||||
│ ├── VERSION
|
||||
│ ├── json
|
||||
│ └── layer.tar
|
||||
│ ├── VERSION
|
||||
│ ├── json
|
||||
│ └── layer.tar
|
||||
├── a7b8b41220991bfc754d7ad445ad27b7f272ab8b4a2c175b9512b97471d02a8a
|
||||
│ ├── VERSION
|
||||
│ ├── json
|
||||
│ └── layer.tar
|
||||
│ ├── VERSION
|
||||
│ ├── json
|
||||
│ └── layer.tar
|
||||
├── a936027c5ca8bf8f517923169a233e391cbb38469a75de8383b5228dc2d26ceb
|
||||
│ ├── VERSION
|
||||
│ ├── json
|
||||
│ └── layer.tar
|
||||
│ ├── VERSION
|
||||
│ ├── json
|
||||
│ └── layer.tar
|
||||
├── f60c56784b832dd990022afc120b8136ab3da9528094752ae13fe63a2d28dc8c
|
||||
│ ├── VERSION
|
||||
│ ├── json
|
||||
│ └── layer.tar
|
||||
│ ├── VERSION
|
||||
│ ├── json
|
||||
│ └── layer.tar
|
||||
└── repositories
|
||||
```
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue