docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #223 from danix800/fix-typos 

Fix typos.
This commit is contained in:
John Mulhausen 2016-10-18 16:31:21 -07:00 committed by GitHub
parent 83ec5da00d 371be6dacf
commit f8776699de
14 changed files with 150 additions and 137 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
engine/swarm/swarm-tutorial/index.md
View File

@ -25,7 +25,7 @@ The tutorial guides you through the following activities:
This tutorial uses Docker Engine CLI commands entered on the command line of a
terminal window. You should be able to install Docker on networked machines and
be comfortable running commands in the shell of your choice.
be comfortable with running commands in the shell of your choice.
If you are brand new to Docker, see [About Docker Engine](../../index.md).

3
engine/userguide/networking/default_network/dockerlinks.md
View File

@ -100,8 +100,7 @@ configurations. For example, if you've bound the container port to the
> **Note**:
> This section covers the legacy link feature in the default `bridge` network.
> Please refer to [linking containers in user-defined networks]
> (../work-with-networks.md#linking-containers-in-user-defined-networks)
> Please refer to [linking containers in user-defined networks](../work-with-networks.md#linking-containers-in-user-defined-networks)
> for more information on links in user-defined networks.
Network port mappings are not the only way Docker containers can connect to one

5
engine/userguide/networking/default_network/ipv6.md
View File

@ -71,6 +71,7 @@ $ sysctl net.ipv6.conf.eth0.accept_ra=2
Every new container will get an IPv6 address from the defined subnet. Further a
default route will be added on `eth0` in the container via the address specified
by the daemon option `--default-gateway-v6` if present, otherwise via `fe80::1`:
```
docker run -it ubuntu bash -c "ip -6 addr show dev eth0; ip -6 route show"
@ -107,9 +108,9 @@ containers.
### Using NDP proxying
If your Docker host is only part of an IPv6 subnet but has not got an IPv6
If your Docker host is the only part of an IPv6 subnet but has not got an IPv6
subnet assigned you can use NDP proxying to connect your containers via IPv6 to
the internet. For example your host has the IPv6 address `2001:db8::c001`, is
the internet. For example your host with the IPv6 address `2001:db8::c001`, is
part of the subnet `2001:db8::/64` and your IaaS provider allows you to
configure the IPv6 addresses `2001:db8::c000` to `2001:db8::c00f`:

4
engine/userguide/storagedriver/aufs-driver.md
View File

@ -191,7 +191,7 @@ also in this directory.
A container's thin writable layer is stored in a directory under
`/var/lib/docker/aufs/diff/`. With Docker 1.10 and higher, container IDs no
longer correspond to directory names. However, the containers thin writable
layer still exists under here and is stacked by AUFS as the top writable layer
layer still exists here and is stacked by AUFS as the top writable layer
and is where all changes to the container are stored. The directory exists even
if the container is stopped. This means that restarting a container will not
lose changes made to it. Once a container is deleted, it's thin writable layer
@ -211,7 +211,7 @@ containers uses the systems page cache very efficiently.
- The AUFS storage driver can introduce significant latencies into container
write performance. This is because the first time a container writes to any
file, the file has be located and copied into the containers top writable
file, the file has to be located and copied into the containers top writable
layer. These latencies increase and are compounded when these files exist below
many image layers and the files themselves are large.

4
engine/userguide/storagedriver/btrfs-driver.md
View File

@ -167,6 +167,8 @@ loaded. To verify this, use the following command:
$ cat /proc/filesystems | grep btrfs
btrfs
### Configure Btrfs on Ubuntu 14.04 LTS
Assuming your system meets the prerequisites, do the following:
@ -277,7 +279,7 @@ density container use cases.
- **Small writes**. Containers performing lots of small writes (including
Docker hosts that start and stop many containers) can lead to poor use of Btrfs
chunks. This can ultimately lead to out-of-space conditions on your Docker
host and stop it working. This is currently a major drawback to using current
host and stop working. This is currently a major drawback to use current
versions of Btrfs.
If you use the `btrfs` storage driver, closely monitor the free space on

2
engine/userguide/storagedriver/device-mapper-driver.md
View File

@ -322,7 +322,7 @@ assumes that the Docker daemon is in the `stopped` state.
Now that your storage is configured, configure the Docker daemon to use it. There are two ways to do this. You can set options on the command line if you start the daemon there:
```bash
--storage-driver=devicemapper --storage-opt=dm.thinpooldev=/dev/mapper/docker-thinpool --storage-opt=dm.use_deferred_removal=true --storage-opt=dm.use_deferred_deletion=true
--storage-driver=devicemapper --storage-opt=dm.thinpooldev=/dev/mapper/docker-thinpool-tpool --storage-opt=dm.use_deferred_removal=true --storage-opt=dm.use_deferred_deletion=true
```
You can also set them for startup in the `daemon.json` configuration, for example:

2
engine/userguide/storagedriver/selectadriver.md
View File

@ -12,7 +12,7 @@ title: Select a storage driver
# Select a storage driver
This page describes Docker's storage driver feature. It lists the storage
driver's that Docker supports and the basic commands associated with managing
drivers that Docker supports and the basic commands associated with managing
them. Finally, this page provides guidance on choosing a storage driver.
The material on this page is intended for readers who already have an

4
opensource/code.md
View File

@ -38,7 +38,7 @@ target="_blank">Get the software</a> you need.
target="_blank">Configure Git and fork the repo</a>.
Your Git configuration can make it easier for you to contribute.
Configuration is especially key if are new to contributing or to Docker.
Configuration is especially key if you are new to contributing or to Docker.
3. <a href="http://docs.docker.com/opensource/project/set-up-dev-env/"
target="_blank">Learn to work with the Docker development container</a>.
@ -77,7 +77,7 @@ pull request</a>.
![Sign commits and issues](images/bonus.png)
We have also have checklist that describes [what each pull request
We also have checklist that describes [what each pull request
needs](code.md#what-is-the-pre-pull-request-checklist).

8
opensource/project/set-up-dev-env.md
View File

@ -99,7 +99,7 @@ can take over 15 minutes to complete.
1. Open a terminal.
Mac users, use `docker-machine status your_vm_name` to make sure your VM is running. You
For Mac users, use `docker-machine status your_vm_name` to make sure your VM is running. You
may need to run `eval "$(docker-machine env your_vm_name)"` to initialize your
shell environment.
@ -206,6 +206,8 @@ can take over 15 minutes to complete.
```none
root@5f8630b873fe:/go/src/github.com/docker/docker# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
hello-world latest c54a2cc56cbb 3 months ago 1.85 kB
```
12. Open another terminal on your local host.
@ -218,7 +220,7 @@ can take over 15 minutes to complete.
a8b2885ab900 docker-dev:dry-run-test "hack/dind bash" 43 minutes ago Up 43 minutes hungry_payne
```
Notice that the tag on the container is marked with the `dry-run-branch` name.
Notice that the tag on the container is marked with the `dry-run-test` branch name.
## Task 3. Make a code change
@ -235,7 +237,7 @@ you have:
your development container
Running the `make shell` command mounted your local Docker repository source into
your Docker container. When you start to developing code though, you'll
your Docker container. When you start to develop code though, you'll
want to iterate code changes and builds inside the container. If you have
followed this guide exactly, you have a BASH shell running a development
container.

186
opensource/project/set-up-git.md
View File

@ -55,39 +55,39 @@ target="_blank">docker/docker repository</a>.
5. Open a terminal window on your local host and change to your home directory.
```bash
$ cd ~
```
```bash
$ cd ~
```
In Windows, you'll work in your Docker Quickstart Terminal window instead of
Powershell or a `cmd` window.
6. Create a `repos` directory.
```bash
$ mkdir repos
```
```bash
$ mkdir repos
```
7. Change into your `repos` directory.
```bash
$ cd repos
```
```bash
$ cd repos
```
8. Clone the fork to your local host into a repository called `docker-fork`.
```bash
$ git clone https://github.com/moxiegirl/docker.git docker-fork
```
```bash
$ git clone https://github.com/moxiegirl/docker.git docker-fork
```
Naming your local repo `docker-fork` should help make these instructions
easier to follow; experienced coders don't typically change the name.
9. Change directory into your new `docker-fork` directory.
```bash
$ cd docker-fork
```
```bash
$ cd docker-fork
```
Take a moment to familiarize yourself with the repository's contents. List
the contents.
@ -117,55 +117,55 @@ To configure your username, email, and add a remote:
1. Change to the root of your `docker-fork` repository.
```bash
$ cd docker-fork
```
```bash
$ cd docker-fork
```
2. Set your `user.name` for the repository.
```bash
$ git config --local user.name "FirstName LastName"
```
```bash
$ git config --local user.name "FirstName LastName"
```
3. Set your `user.email` for the repository.
```bash
$ git config --local user.email "emailname@mycompany.com"
```
```bash
$ git config --local user.email "emailname@mycompany.com"
```
4. Set your local repo to track changes upstream, on the `docker` repository.
```bash
$ git remote add upstream https://github.com/docker/docker.git
```
```bash
$ git remote add upstream https://github.com/docker/docker.git
```
5. Check the result in your `git` configuration.
```bash
$ git config --local -l
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=https://github.com/moxiegirl/docker.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
user.name=Mary Anthony
user.email=mary@docker.com
remote.upstream.url=https://github.com/docker/docker.git
remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/*
```
```bash
$ git config --local -l
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=https://github.com/moxiegirl/docker.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
user.name=Mary Anthony
user.email=mary@docker.com
remote.upstream.url=https://github.com/docker/docker.git
remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/*
```
To list just the remotes use:
```bash
$ git remote -v
origin https://github.com/moxiegirl/docker.git (fetch)
origin https://github.com/moxiegirl/docker.git (push)
upstream https://github.com/docker/docker.git (fetch)
upstream https://github.com/docker/docker.git (push)
```
```bash
$ git remote -v
origin https://github.com/moxiegirl/docker.git (fetch)
origin https://github.com/moxiegirl/docker.git (push)
upstream https://github.com/docker/docker.git (fetch)
upstream https://github.com/docker/docker.git (push)
```
## Task 3. Create and push a branch
@ -179,32 +179,34 @@ the branch to your fork on GitHub:
1. Open a terminal and go to the root of your `docker-fork`.
```bash
$ cd docker-fork
```
```bash
$ cd docker-fork
```
2. Create a `dry-run-test` branch.
```bash
$ git checkout -b dry-run-test
```
```bash
$ git checkout -b dry-run-test
```
This command creates the branch and switches the repository to it.
3. Verify you are in your new branch.
$ git branch
* dry-run-test
master
```bash
$ git branch
* dry-run-test
master
```
The current branch has an * (asterisk) marker. So, these results shows you
are on the right branch.
4. Create a `TEST.md` file in the repository's root.
```bash
$ touch TEST.md
```
```bash
$ touch TEST.md
```
5. Edit the file and add your email and location.
@ -216,43 +218,43 @@ the branch to your fork on GitHub:
7. Check the status of your branch.
```bash
$ git status
On branch dry-run-test
Untracked files:
(use "git add <file>..." to include in what will be committed)
TEST.md
nothing added to commit but untracked files present (use "git add" to track)
```
```bash
$ git status
On branch dry-run-test
Untracked files:
(use "git add <file>..." to include in what will be committed)
TEST.md
nothing added to commit but untracked files present (use "git add" to track)
```
You've only changed the one file. It is untracked so far by git.
8. Add your file.
```bash
$ git add TEST.md
```
```bash
$ git add TEST.md
```
That is the only _staged_ file. Stage is fancy word for work that Git is
tracking.
9. Sign and commit your change.
```
$ git commit -s -m "Making a dry run test."
[dry-run-test 6e728fb] Making a dry run test
1 file changed, 1 insertion(+)
create mode 100644 TEST.md
```
```bash
$ git commit -s -m "Making a dry run test."
[dry-run-test 6e728fb] Making a dry run test
1 file changed, 1 insertion(+)
create mode 100644 TEST.md
```
Commit messages should have a short summary sentence of no more than 50
characters. Optionally, you can also include a more detailed explanation
after the summary. Separate the summary from any explanation with an empty
line.
8. Push your changes to GitHub.
10. Push your changes to GitHub.
```bash
$ git push --set-upstream origin dry-run-test
@ -263,19 +265,21 @@ the branch to your fork on GitHub:
Git prompts you for your GitHub username and password. Then, the command
returns a result.
Counting objects: 13, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 320 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/moxiegirl/docker.git
* [new branch] dry-run-test -> dry-run-test
Branch dry-run-test set up to track remote branch dry-run-test from origin.
```bash
Counting objects: 13, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 320 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/moxiegirl/docker.git
* [new branch] dry-run-test -> dry-run-test
Branch dry-run-test set up to track remote branch dry-run-test from origin.
```
9. Open your browser to GitHub.
11. Open your browser to GitHub.
10. Navigate to your Docker fork.
12. Navigate to your Docker fork.
11. Make sure the `dry-run-test` branch exists, that it has your commit, and the
13. Make sure the `dry-run-test` branch exists, that it has your commit, and the
commit is signed.
![Branch Signature](images/branch-sig.png)

2
opensource/project/software-req-win.md
View File

@ -11,7 +11,7 @@ title: Set up for development on Windows
# Get the required software for Windows
This page explains how to get the software you need to use a a Windows Server
This page explains how to get the software you need to use a Windows Server
2012 or Windows 8 machine for Docker development. Before you begin contributing
you must have:

59
opensource/project/test-and-docs.md
View File

@ -55,8 +55,8 @@ change an existing one.
## Run tests on your local host
Before submitting a pull request with a code change, you should run the entire
Docker Engine test suite. The `Makefile` contains a target for the entire test suite.
The target's name is simply `test`. The `Makefile` contains several targets for
Docker Engine test suite. The `Makefile` contains a target for the entire test
suite, named `test`. Also, it contains several targets for
testing:
| Target | What this target does |
@ -198,27 +198,30 @@ Git for Windows installation. **Git Bash**, just as it sounds, allows you to
run a Bash terminal on Windows.
1. If you don't have one open already, start a Git Bash terminal.
```bash
![Git Bash](images/git_bash.png)
```
2. Change to the `docker` source directory.
```bash
$ cd /c/gopath/src/github.com/docker/docker
```
3. Set `DOCKER_REMOTE_DAEMON` as follows:
```bash
$ export DOCKER_REMOTE_DAEMON=1
```
4. Set `DOCKER_TEST_HOST` to the `tcp://IP_ADDRESS:2376` value; substitute your
Linux machines actual IP address. For example:
```bash
$ export DOCKER_TEST_HOST=tcp://213.124.23.200:2376
```
5. Make the binary and run the tests:
```bash
$ hack/make.sh binary test-integration-cli
```
@ -239,13 +242,13 @@ run a Bash terminal on Windows.
```
You can now choose to make changes to the Docker source or the tests. If you
make any changes just run these commands again.
make any changes, just run these commands again.
## Build and test the documentation
The Docker documentation source files are in a centralized repository at
https://github.com/docker/docker.github.io. The content is
[https://github.com/docker/docker.github.io](https://github.com/docker/docker.github.io). The content is
written using extended Markdown, which you can edit in a plain text editor such
Atom or Notepad. The docs are built using [Jekyll](https://jekyllrb.com/).
@ -253,8 +256,8 @@ Most documentation is developed in the centralized repository. The exceptions ar
a project's API and CLI references and man pages, which are developed alongside
the project's code and periodically imported into the documentation repository.
Always check your documentation for grammar and spelling. You can user
an online grammar checker such as http://www.hemingwayapp.com/ or a spelling or
Always check your documentation for grammar and spelling. You can use
an online grammar checker such as [Hemingway Editor](http://www.hemingwayapp.com/) or a spelling or
grammar checker built into your text editor. If you spot spelling or grammar errors,
fixing them is one of the easiest ways to get started contributing to opensource
projects.
@ -275,26 +278,28 @@ The easiest way to build the docs locally on macOS, Windows, or Linux is to use
`docker-compose`. If you have not yet installed `docker-compose`,
[follow these installation instructions](https://docs.docker.com/compose/install/).
In the root of the repository, issue the following command:
In the root of the repository, issue the following command:
```bash
$ docker-compose up
```
This launches a container which has Jekyll and all its dependencies configured
correctly, and uses Jekyll to incrementally build and serve the site using the
This command will create and start service `docs` defined in `docker-compose.yml`,
which will build an image named `docs/docstage` and launch a container with Jekyll and all its dependencies configured
correctly. The container uses Jekyll to incrementally build and serve the site using the
files in the local repository.
Go to http://localhost:4000/ in your web browser to view the documentation.
Go to [http://localhost:4000/](http://localhost:4000/) in your web browser to view the documentation.
The container runs in the foreground. To send it to the background, use `CTRL+C`.
It will continue to run and incrementally build the site when changes are detected,
even if you change branches.
The container runs in the foreground. It will continue to run and incrementally build the site when changes are
detected, even if you change branches.
To stop the container, use the following command:
To stop the container, use `CTRL+C`.
To start the container again, use the following command:
```bash
$ docker-compose down
$ docker-compose start docs
```
#### Using Jekyll directly
@ -305,16 +310,20 @@ If for some reason you are unable to use Docker Compose, you can use Jekyll dire
- You need a recent version of Ruby installed. If you are on macOS, install Ruby
and Bundle using homebrew.
```bash
brew install ruby
brew install bundle
```
```bash
brew install ruby
brew install bundle
```
- Use `bundle` to install Jekyll and its dependencies from the bundle in the
centralized documentation repository. Within your clone of the
https://github.com/docker/docker.github.io repository, issue the following command:
```bash
bundle install
```
[https://github.com/docker/docker.github.io](https://github.com/docker/docker.github.io)
repository, issue the following command:
```bash
bundle install
```
**To build the website locally:**

4
opensource/workflow/find-an-issue.md
View File

@ -56,7 +56,6 @@ experience, and priority. You can filter using one or more labels. The
kind and experience labels are useful for new contributors.
The following table describes the kind labels.
<strong class="foobar">kind/bug</strong>
<table>
<thead>
@ -234,9 +233,6 @@ To sync your repository:
From github.com:docker/docker
* branch master -> FETCH_HEAD
This command says get all the changes from the `master` branch belonging to
the `upstream` remote.
7. Rebase your local master with the `upstream/master`.
$ git rebase upstream/master

2
opensource/workflow/work-issue.md
View File

@ -11,7 +11,7 @@ title: Work on your issue
# Work on your issue
The work you do for your issue depends on the specific issue you picked.
The work you do depends on the specific issue you picked.
This section gives you a step-by-step workflow. Where appropriate, it provides
command examples.