mirror of https://github.com/docker/cli.git
Merge pull request #658 from arehman199/fix-a-number-of-typos
fix a number of minor typos
This commit is contained in:
commit
a0140b4ddb
|
@ -305,8 +305,8 @@ func runBuild(dockerCli command.Cli, options buildOptions) error {
|
|||
progressOutput = &lastProgressOutput{output: progressOutput}
|
||||
}
|
||||
|
||||
// if up to this point nothing has set the context then we must have have
|
||||
// another way for sending it(streaming) and set the context to the Dockerfile
|
||||
// if up to this point nothing has set the context then we must have another
|
||||
// way for sending it(streaming) and set the context to the Dockerfile
|
||||
if dockerfileCtx != nil && buildCtx == nil {
|
||||
buildCtx = dockerfileCtx
|
||||
}
|
||||
|
|
|
@ -177,7 +177,7 @@ func (configFile *ConfigFile) Save() error {
|
|||
return configFile.SaveToWriter(f)
|
||||
}
|
||||
|
||||
// ParseProxyConfig computes proxy configuration by retreiving the config for the provided host and
|
||||
// ParseProxyConfig computes proxy configuration by retrieving the config for the provided host and
|
||||
// then checking this against any environment variables provided to the container
|
||||
func (configFile *ConfigFile) ParseProxyConfig(host string, runOpts []string) map[string]*string {
|
||||
var cfgKey string
|
||||
|
|
|
@ -299,7 +299,7 @@ type ImageRefAndAuth struct {
|
|||
}
|
||||
|
||||
// GetImageReferencesAndAuth retrieves the necessary reference and auth information for an image name
|
||||
// as a ImageRefAndAuth struct
|
||||
// as an ImageRefAndAuth struct
|
||||
func GetImageReferencesAndAuth(ctx context.Context, authResolver func(ctx context.Context, index *registrytypes.IndexInfo) types.AuthConfig, imgName string) (ImageRefAndAuth, error) {
|
||||
ref, err := reference.ParseNormalizedNamed(imgName)
|
||||
if err != nil {
|
||||
|
|
|
@ -126,7 +126,7 @@ Config provides the base accessible fields for working with V0 plugin format
|
|||
- **`propagatedMount`** *string*
|
||||
|
||||
path to be mounted as rshared, so that mounts under that path are visible to docker. This is useful for volume plugins.
|
||||
This path will be bind-mounted outisde of the plugin rootfs so it's contents
|
||||
This path will be bind-mounted outside of the plugin rootfs so it's contents
|
||||
are preserved on upgrade.
|
||||
|
||||
- **`env`** *PluginEnv array*
|
||||
|
|
|
@ -765,7 +765,7 @@ type of documentation between the person who builds the image and the person who
|
|||
runs the container, about which ports are intended to be published. To actually
|
||||
publish the port when running the container, use the `-p` flag on `docker run`
|
||||
to publish and map one or more ports, or the `-P` flag to publish all exposed
|
||||
ports and map them to to high-order ports.
|
||||
ports and map them to high-order ports.
|
||||
|
||||
To set up port redirection on the host system, see [using the -P
|
||||
flag](run.md#expose-incoming-ports). The `docker network` command supports
|
||||
|
|
|
@ -512,7 +512,7 @@ The `--squash` option has a number of known limitations:
|
|||
layers in tact, and one for the squashed version.
|
||||
- While squashing layers may produce smaller images, it may have a negative
|
||||
impact on performance, as a single layer takes longer to extract, and
|
||||
downloading a single layer cannot be paralellized.
|
||||
downloading a single layer cannot be parallelized.
|
||||
- When attempting to squash an image that does not make changes to the
|
||||
filesystem (for example, the Dockerfile only contains `ENV` instructions),
|
||||
the squash step will fail (see [issue #33823](https://github.com/moby/moby/issues/33823)
|
||||
|
|
|
@ -217,7 +217,7 @@ For the `devicemapper`, `btrfs`, `windowsfilter` and `zfs` graph drivers,
|
|||
user cannot pass a size less than the Default BaseFS Size.
|
||||
For the `overlay2` storage driver, the size option is only available if the
|
||||
backing fs is `xfs` and mounted with the `pquota` mount option.
|
||||
Under these conditions, user can pass any size less then the backing fs size.
|
||||
Under these conditions, user can pass any size less than the backing fs size.
|
||||
|
||||
### Specify isolation technology for container (--isolation)
|
||||
|
||||
|
|
|
@ -393,7 +393,7 @@ $ sudo dockerd --storage-opt dm.thinp_autoextend_threshold=80
|
|||
|
||||
##### `dm.thinp_autoextend_percent`
|
||||
|
||||
Sets the value percentage value to increase the thin pool by when when `lvm`
|
||||
Sets the value percentage value to increase the thin pool by when `lvm`
|
||||
attempts to autoextend the available space [100 = disabled]
|
||||
|
||||
###### Example:
|
||||
|
|
|
@ -47,7 +47,7 @@ describes all the details of the format.
|
|||
|
||||
The `docker inspect` command matches any type of object by either ID or name.
|
||||
In some cases multiple type of objects (for example, a container and a volume)
|
||||
exist with the same name, making the result ambigious.
|
||||
exist with the same name, making the result ambiguous.
|
||||
|
||||
To restrict `docker inspect` to a specific type of object, use the `--type`
|
||||
option.
|
||||
|
|
|
@ -204,7 +204,7 @@ to create an externally isolated `overlay` network, you can specify the
|
|||
You can create the network which will be used to provide the routing-mesh in the
|
||||
swarm cluster. You do so by specifying `--ingress` when creating the network. Only
|
||||
one ingress network can be created at the time. The network can be removed only
|
||||
if no services depend on it. Any option available when creating a overlay network
|
||||
if no services depend on it. Any option available when creating an overlay network
|
||||
is also available when creating the ingress network, besides the `--attachable` option.
|
||||
|
||||
```bash
|
||||
|
|
|
@ -207,7 +207,7 @@ $ docker network inspect ingress
|
|||
details such as the service's VIP and port mappings. It also shows IPs of service tasks,
|
||||
and the IPs of the nodes where the tasks are running.
|
||||
|
||||
Following is an example output for a overlay network `ov1` that has one service `s1`
|
||||
Following is an example output for an overlay network `ov1` that has one service `s1`
|
||||
attached to. service `s1` in this case has three replicas.
|
||||
|
||||
```bash
|
||||
|
|
|
@ -240,7 +240,7 @@ For the `devicemapper`, `btrfs`, `windowsfilter` and `zfs` graph drivers,
|
|||
user cannot pass a size less than the Default BaseFS Size.
|
||||
For the `overlay2` storage driver, the size option is only available if the
|
||||
backing fs is `xfs` and mounted with the `pquota` mount option.
|
||||
Under these conditions, user can pass any size less then the backing fs size.
|
||||
Under these conditions, user can pass any size less than the backing fs size.
|
||||
|
||||
### Mount tmpfs (--tmpfs)
|
||||
|
||||
|
|
|
@ -353,7 +353,7 @@ volumes in a service:
|
|||
<li><tt>default</tt>: Equivalent to <tt>consistent</tt>.</li>
|
||||
<li><tt>consistent</tt>: Full consistency. The container runtime and the host maintain an identical view of the mount at all times.</li>
|
||||
<li><tt>cached</tt>: The host's view of the mount is authoritative. There may be delays before updates made on the host are visible within a container.</li>
|
||||
<li><tt>delegated</tt>: The container runtime's view of the mount is authoritative. There may be delays before updates made in a container are are visible on the host.</li>
|
||||
<li><tt>delegated</tt>: The container runtime's view of the mount is authoritative. There may be delays before updates made in a container are visible on the host.</li>
|
||||
</ul>
|
||||
</p>
|
||||
</td>
|
||||
|
|
|
@ -220,7 +220,7 @@ $$ ip a show eth0
|
|||
|
||||
The mode ` -o ipvlan_mode=l3` must be explicitly specified since the default ipvlan mode is `l2`.
|
||||
|
||||
The following example does not specify a parent interface. The network drivers will create a dummy type link for the user rather then rejecting the network creation and isolating containers from only communicating with one another.
|
||||
The following example does not specify a parent interface. The network drivers will create a dummy type link for the user rather than rejecting the network creation and isolating containers from only communicating with one another.
|
||||
|
||||
```
|
||||
# Create the Ipvlan L3 network
|
||||
|
|
|
@ -582,7 +582,7 @@ incompatible with any restart policy other than `none`.
|
|||
This option is only available for the `devicemapper`, `btrfs`, `overlay2` and `zfs` graph drivers.
|
||||
For the `devicemapper`, `btrfs` and `zfs` storage drivers, user cannot pass a size less than the Default BaseFS Size.
|
||||
For the `overlay2` storage driver, the size option is only available if the backing fs is `xfs` and mounted with the `pquota` mount option.
|
||||
Under these conditions, user can pass any size less then the backing fs size.
|
||||
Under these conditions, user can pass any size less than the backing fs size.
|
||||
|
||||
**--stop-signal**=*SIGTERM*
|
||||
Signal to stop a container. Default is SIGTERM.
|
||||
|
|
|
@ -480,7 +480,7 @@ autoextend the available space [100 = disabled]
|
|||
|
||||
##### dm.thinp_autoextend_percent
|
||||
|
||||
Sets the value percentage value to increase the thin pool by when when `lvm`
|
||||
Sets the value percentage value to increase the thin pool by when `lvm`
|
||||
attempts to autoextend the available space [100 = disabled]
|
||||
|
||||
###### Example:
|
||||
|
|
|
@ -123,7 +123,7 @@ to create an externally isolated `overlay` network, you can specify the
|
|||
You can create the network which will be used to provide the routing-mesh in the
|
||||
swarm cluster. You do so by specifying `--ingress` when creating the network. Only
|
||||
one ingress network can be created at the time. The network can be removed only
|
||||
if no services depend on it. Any option available when creating a overlay network
|
||||
if no services depend on it. Any option available when creating an overlay network
|
||||
is also available when creating the ingress network, besides the `--attachable` option.
|
||||
|
||||
```bash
|
||||
|
|
|
@ -92,7 +92,7 @@ $ docker network inspect simple-network
|
|||
details such as the service's VIP and port mappings. It also shows IPs of service tasks,
|
||||
and the IPs of the nodes where the tasks are running.
|
||||
|
||||
Following is an example output for a overlay network `ov1` that has one service `s1`
|
||||
Following is an example output for an overlay network `ov1` that has one service `s1`
|
||||
attached to. service `s1` in this case has three replicas.
|
||||
|
||||
```bash
|
||||
|
|
Loading…
Reference in New Issue