mirror of https://github.com/docker/docs.git
Merging master into vnext-compose
includes conflict resolution Signed-off-by: Misty Stanley-Jones <misty@docker.com>
This commit is contained in:
commit
ac0cef5d0f
|
@ -0,0 +1,31 @@
|
|||
# Files and directories here are not edited in the docker.github.io repo.
|
||||
# Instead, they are edited in the appropriate upstream repo and pulled
|
||||
# into this repo periodically. The intent is that if you submit a PR
|
||||
# with changes to these files or directories, a CI job will fail in the
|
||||
# PR, indicating that it should not be merged.
|
||||
|
||||
# If you need to edit these files or directories, submit a PR in one of the
|
||||
# following repos. The file will probably be located within the docs/ subdirectory.
|
||||
|
||||
# docker-trusted-registry: n/a, file an issue
|
||||
# engine: https://github.com/docker/docker
|
||||
# compose: https://github.com/docker/compose
|
||||
# notary: https://github.com/docker/notary
|
||||
# registry: https://github.com/docker/distribution
|
||||
# swarm: https://github.com/docker/swarm
|
||||
# ucp: n/a, file an issue
|
||||
|
||||
# Make sure directories have the trailing slash, keep the list alphabetical
|
||||
|
||||
apidocs/
|
||||
compose/reference/
|
||||
docker-trusted-registry/reference/
|
||||
engine/deprecated.md
|
||||
engine/extend/
|
||||
engine/reference/
|
||||
machine/reference/
|
||||
notary/reference/
|
||||
registry/configuration.md
|
||||
registry/spec/
|
||||
swarm/reference/
|
||||
ucp/reference/
|
|
@ -1,3 +0,0 @@
|
|||
{
|
||||
"phabricator.uri" : "https://docker-saas.phacility.com/"
|
||||
}
|
6
.babelrc
6
.babelrc
|
@ -1,6 +0,0 @@
|
|||
{
|
||||
"presets": ["es2015", "react", "stage-0"],
|
||||
"plugins": [
|
||||
["transform-decorators-legacy"],
|
||||
]
|
||||
}
|
|
@ -1,5 +0,0 @@
|
|||
[bumpversion]
|
||||
current_version = 1.1.0
|
||||
commit = True
|
||||
tag = True
|
||||
|
|
@ -1 +0,0 @@
|
|||
{"https://index.docker.io/v1/":{"auth":"<AUTH>","email":"<EMAIL>"}}
|
21
.drone.yml
21
.drone.yml
|
@ -1,21 +0,0 @@
|
|||
image: go1.3
|
||||
env:
|
||||
- RETHINKDB_TEST_PORT_28015_TCP_ADDR=127.0.0.1
|
||||
- RETHINKDB_TEST_PORT_28015_TCP_PORT=28015
|
||||
- RETHINKDB_TEST_DATABASE=shipyard_test
|
||||
- DOCKER_TEST_ADDR=http://10.0.1.32:2375
|
||||
script:
|
||||
- echo "Using env vars:"
|
||||
- echo $RETHINKDB_TEST_PORT_28015_TCP_ADDR
|
||||
- echo $RETHINKDB_TEST_PORT_28015_TCP_PORT
|
||||
- echo $RETHINKDB_TEST_DATABASE
|
||||
- echo $DOCKER_TEST_ADDR
|
||||
- go get github.com/tools/godep
|
||||
- pushd controller
|
||||
- make test-drone
|
||||
- popd
|
||||
- pushd cli
|
||||
- make test-drone
|
||||
- popd
|
||||
services:
|
||||
- shipyard/rethinkdb
|
|
@ -1,29 +0,0 @@
|
|||
# EditorConfig helps developers define and maintain consistent
|
||||
# coding styles between different editors and IDEs
|
||||
# editorconfig.org
|
||||
|
||||
root = true
|
||||
|
||||
|
||||
[*]
|
||||
|
||||
# Change these settings to your own preference
|
||||
indent_style = space
|
||||
indent_size = 4
|
||||
|
||||
# We recommend you to keep these unchanged
|
||||
end_of_line = lf
|
||||
charset = utf-8
|
||||
trim_trailing_whitespace = true
|
||||
insert_final_newline = true
|
||||
|
||||
[*.md]
|
||||
trim_trailing_whitespace = false
|
||||
|
||||
[package.json]
|
||||
indent_style = space
|
||||
indent_size = 2
|
||||
|
||||
[bower.json]
|
||||
indent_style = space
|
||||
indent_size = 2
|
14
.flowconfig
14
.flowconfig
|
@ -1,14 +0,0 @@
|
|||
[ignore]
|
||||
.*/app/scripts/build.*
|
||||
.*/.tmp/.*
|
||||
.*/node_modules/webpack.*
|
||||
.*/node_modules/gulp-sass/.*
|
||||
|
||||
[include]
|
||||
app/scripts
|
||||
node_modules/hub-js-sdk
|
||||
|
||||
[libs]
|
||||
./flow-libs
|
||||
|
||||
[options]
|
|
@ -0,0 +1,88 @@
|
|||
## Contributing
|
||||
|
||||
We value your documentation contributions, and we want to make it as easy
|
||||
as possible to work in this repository. One of the first things to decide is
|
||||
which branch to base your work on. If you get confused, just ask and we will
|
||||
help. If a reviewer realizes you have based your work on the wrong branch, we'll
|
||||
let you know so that you can rebase it.
|
||||
|
||||
>**Note**: To contribute code to Docker projects, see the
|
||||
[Contribution guidelines](opensource/project/who-written-for).
|
||||
|
||||
### Quickstart
|
||||
|
||||
If you spot a problem while reading the documentation and want to try to fix it
|
||||
yourself, click the **Edit this page** link at the bottom of that page. The
|
||||
page will open in the Github editor, which means you don't need to know a lot
|
||||
about Git, or even about Markdown.
|
||||
|
||||
When you save, you will be prompted to create a fork if you don't already have
|
||||
one, and to create a branch in your fork and submit the pull request. We hope
|
||||
you give it a try!
|
||||
|
||||
### Overall doc improvements
|
||||
|
||||
Most commits will be made against the `master` branch. This include:
|
||||
|
||||
- Conceptual and task-based information not specific to new features
|
||||
- Restructuring / rewriting
|
||||
- Doc bug fixing
|
||||
- Typos and grammar errors
|
||||
|
||||
One quirk of this project is that the `master` branch is where the live docs are
|
||||
published from, so upcoming features can't be documented there. See
|
||||
[Specific new features for a project](#specific-new-features-for-a-project)
|
||||
for how to document upcoming features. These feature branches will be periodically
|
||||
merged with `master`, so don't worry about fixing typos and documentation bugs
|
||||
there.
|
||||
|
||||
>Do you enjoy creating graphics? Good graphics are key to great documentation,
|
||||
and we especially value contributions in this area.
|
||||
|
||||
### Specific new features for a project
|
||||
|
||||
Our docs cover many projects which release at different times. **If, and only if,
|
||||
your pull request relates to a currently unreleased feature of a project, base
|
||||
your work on that project's `vnext` branch.** These branches were created by
|
||||
cloning `master` and then importing a project's `master` branch's docs into it
|
||||
(at the time of the migration), in a way that preserved the commit history. When
|
||||
a project has a release, its `vnext` branch will be merged into `master` and your
|
||||
work will be visible on docs.docker.com.
|
||||
|
||||
The following `vnext` branches currently exist:
|
||||
|
||||
- **[vnext-engine](https://github.com/docker/docker.github.io/tree/vnext-engine):**
|
||||
docs for upcoming features in the [docker/docker](https://github.com/docker/docker/)
|
||||
project
|
||||
|
||||
- **[vnext-compose](https://github.com/docker/docker.github.io/tree/vnext-compose):**
|
||||
docs for upcoming features in the [docker/compose](https://github.com/docker/compose/)
|
||||
project
|
||||
|
||||
- **[vnext-distribution](https://github.com/docker/docker.github.io/tree/vnext-distribution):**
|
||||
docs for upcoming features in the [docker/distribution](https://github.com/docker/distribution/)
|
||||
project
|
||||
|
||||
- **[vnext-opensource](https://github.com/docker/docker.github.io/tree/vnext-opensource):**
|
||||
docs for upcoming features in the [docker/opensource](https://github.com/docker/opensource/)
|
||||
project
|
||||
|
||||
- **[vnext-swarm](https://github.com/docker/docker.github.io/tree/vnext-swarm):**
|
||||
docs for upcoming features in the [docker/swarm](https://github.com/docker/swarm/)
|
||||
project
|
||||
|
||||
- **[vnext-toolbox](https://github.com/docker/docker.github.io/tree/vnext-toolbox):**
|
||||
docs for upcoming features in the [docker/toolbox](https://github.com/docker/toolbox/)
|
||||
project
|
||||
|
||||
- **[vnext-kitematic](https://github.com/docker/docker.github.io/tree/vnext-kitematic):**
|
||||
docs for upcoming features in the [docker/kitematic](https://github.com/docker/kitematic/)
|
||||
project
|
||||
|
||||
## Style guide
|
||||
|
||||
If you have questions about how to write for Docker's documentation, please see
|
||||
the [style guide](https://docs.docker.com/opensource/doc-style/). The style guide provides
|
||||
guidance about grammar, syntax, formatting, styling, language, or tone. If
|
||||
something isn't clear in the guide, please submit an issue to let us know or
|
||||
submit a pull request to help us improve it.
|
|
@ -0,0 +1,26 @@
|
|||
### Problem description
|
||||
|
||||
<!-- Briefly describe the problem that you found. Only documentation issues should be filed here.
|
||||
For general questions, go to https://forums.docker.com/. -->
|
||||
|
||||
### Problem location
|
||||
|
||||
<!-- Help us find the problem quickly by choosing one of these. -->
|
||||
|
||||
- I saw a problem on the following URL: <URL>
|
||||
|
||||
- I couldn't find the information I wanted. I expected to find it near the following URL: <URL>
|
||||
|
||||
- Other: <DETAILS>
|
||||
|
||||
### Project version(s) affected
|
||||
|
||||
<!-- If this problem only affects specific versions of a project (like Docker
|
||||
Engine 1.13), tell us here. The fix may need to take that into account. -->
|
||||
|
||||
### Suggestions for a fix
|
||||
|
||||
<!--If you have specific ideas about how we can fix this, let us know. -->
|
||||
|
||||
|
||||
<!-- To improve this template, edit the .github/ISSUE_TEMPLATE.md file -->
|
|
@ -0,0 +1,33 @@
|
|||
<!--Thanks for your contribution. See [CONTRIBUTING](CONTRIBUTING.md)
|
||||
for this project's contribution guidelines. -->
|
||||
|
||||
<!--DO NOT edit files and directories listed in .NOT_EDITED_HERE.txt.
|
||||
These are maintained in upstream repos and changes here will be lost.-->
|
||||
|
||||
### Describe the proposed changes
|
||||
|
||||
<!-- Tell us what you did and why. You can leave this off if the PR title
|
||||
is descriptive. The commit message will be added to the end of this form.-->
|
||||
|
||||
### Project version
|
||||
|
||||
<!-- If this change only applies to a future version of a project (like
|
||||
Docker Engine 1.13), note that here and base your work on the `vnext-`
|
||||
branch for your project. -->
|
||||
|
||||
### Related issue
|
||||
|
||||
<!-- If this relates to an issue or PR in this repo, refer to it like
|
||||
#1234, or 'Fixes #1234' or 'Closes #1234'. -->
|
||||
|
||||
### Related issue or PR in another project
|
||||
|
||||
<!-- Links to issues or pull requests in other repositories if applicable. -->
|
||||
|
||||
### Please take a look
|
||||
|
||||
<!-- At-mention specific individuals or groups who should take a
|
||||
look at this PR. For instance, @exampleuser123 -->
|
||||
|
||||
|
||||
<!-- To improve this template, edit .github/PULL_REQUEST_TEMPLATE.md. -->
|
|
@ -1,8 +0,0 @@
|
|||
{
|
||||
// names of npm modules to load into htmllint
|
||||
"plugins": [],
|
||||
"indent-style": "spaces",
|
||||
"indent-width": 2,
|
||||
"attr-name-style": "dash",
|
||||
"html-req-lang": true
|
||||
}
|
|
@ -1,3 +0,0 @@
|
|||
[lfs]
|
||||
url = git@github.com:docker/pinata
|
||||
concurrenttransfers = 8
|
254
.mailmap
254
.mailmap
|
@ -1,254 +0,0 @@
|
|||
# Generate AUTHORS: hack/generate-authors.sh
|
||||
|
||||
# Tip for finding duplicates (besides scanning the output of AUTHORS for name
|
||||
# duplicates that aren't also email duplicates): scan the output of:
|
||||
# git log --format='%aE - %aN' | sort -uf
|
||||
#
|
||||
# For explanation on this file format: man git-shortlog
|
||||
|
||||
Patrick Stapleton <github@gdi2290.com>
|
||||
Shishir Mahajan <shishir.mahajan@redhat.com> <smahajan@redhat.com>
|
||||
Erwin van der Koogh <info@erronis.nl>
|
||||
Ahmed Kamal <email.ahmedkamal@googlemail.com>
|
||||
Tejesh Mehta <tejesh.mehta@gmail.com> <tj@init.me>
|
||||
Cristian Staretu <cristian.staretu@gmail.com>
|
||||
Cristian Staretu <cristian.staretu@gmail.com> <unclejacksons@gmail.com>
|
||||
Cristian Staretu <cristian.staretu@gmail.com> <unclejack@users.noreply.github.com>
|
||||
Marcus Linke <marcus.linke@gmx.de>
|
||||
Aleksandrs Fadins <aleks@s-ko.net>
|
||||
Christopher Latham <sudosurootdev@gmail.com>
|
||||
Hu Keping <hukeping@huawei.com>
|
||||
Wayne Chang <wayne@neverfear.org>
|
||||
Chen Chao <cc272309126@gmail.com>
|
||||
Daehyeok Mun <daehyeok@gmail.com>
|
||||
<daehyeok@gmail.com> <daehyeok@daehyeokui-MacBook-Air.local>
|
||||
<jt@yadutaf.fr> <admin@jtlebi.fr>
|
||||
<jeff@docker.com> <jefferya@programmerq.net>
|
||||
<charles.hooper@dotcloud.com> <chooper@plumata.com>
|
||||
<daniel.mizyrycki@dotcloud.com> <daniel@dotcloud.com>
|
||||
<daniel.mizyrycki@dotcloud.com> <mzdaniel@glidelink.net>
|
||||
Guillaume J. Charmes <guillaume.charmes@docker.com> <charmes.guillaume@gmail.com>
|
||||
<guillaume.charmes@docker.com> <guillaume@dotcloud.com>
|
||||
<guillaume.charmes@docker.com> <guillaume@docker.com>
|
||||
<guillaume.charmes@docker.com> <guillaume.charmes@dotcloud.com>
|
||||
<guillaume.charmes@docker.com> <guillaume@charmes.net>
|
||||
<kencochrane@gmail.com> <KenCochrane@gmail.com>
|
||||
Thatcher Peskens <thatcher@docker.com>
|
||||
Thatcher Peskens <thatcher@docker.com> <thatcher@dotcloud.com>
|
||||
Thatcher Peskens <thatcher@docker.com> dhrp <thatcher@gmx.net>
|
||||
Jérôme Petazzoni <jerome.petazzoni@dotcloud.com> jpetazzo <jerome.petazzoni@dotcloud.com>
|
||||
Jérôme Petazzoni <jerome.petazzoni@dotcloud.com> <jp@enix.org>
|
||||
Joffrey F <joffrey@docker.com>
|
||||
Joffrey F <joffrey@docker.com> <joffrey@dotcloud.com>
|
||||
Joffrey F <joffrey@docker.com> <f.joffrey@gmail.com>
|
||||
Tim Terhorst <mynamewastaken+git@gmail.com>
|
||||
Andy Smith <github@anarkystic.com>
|
||||
<kalessin@kalessin.fr> <louis@dotcloud.com>
|
||||
<victor.vieux@docker.com> <victor.vieux@dotcloud.com>
|
||||
<victor.vieux@docker.com> <victor@dotcloud.com>
|
||||
<victor.vieux@docker.com> <dev@vvieux.com>
|
||||
<victor.vieux@docker.com> <victor@docker.com>
|
||||
<victor.vieux@docker.com> <vieux@docker.com>
|
||||
<victor.vieux@docker.com> <victorvieux@gmail.com>
|
||||
<dominik@honnef.co> <dominikh@fork-bomb.org>
|
||||
<ehanchrow@ine.com> <eric.hanchrow@gmail.com>
|
||||
Walter Stanish <walter@pratyeka.org>
|
||||
<daniel@gasienica.ch> <dgasienica@zynga.com>
|
||||
Roberto Hashioka <roberto_hashioka@hotmail.com>
|
||||
Konstantin Pelykh <kpelykh@zettaset.com>
|
||||
David Sissitka <me@dsissitka.com>
|
||||
Nolan Darilek <nolan@thewordnerd.info>
|
||||
<mastahyeti@gmail.com> <mastahyeti@users.noreply.github.com>
|
||||
Benoit Chesneau <bchesneau@gmail.com>
|
||||
Jordan Arentsen <blissdev@gmail.com>
|
||||
Daniel Garcia <daniel@danielgarcia.info>
|
||||
Miguel Angel Fernández <elmendalerenda@gmail.com>
|
||||
Bhiraj Butala <abhiraj.butala@gmail.com>
|
||||
Faiz Khan <faizkhan00@gmail.com>
|
||||
Victor Lyuboslavsky <victor@victoreda.com>
|
||||
Jean-Baptiste Barth <jeanbaptiste.barth@gmail.com>
|
||||
Matthew Mueller <mattmuelle@gmail.com>
|
||||
<mosoni@ebay.com> <mohitsoni1989@gmail.com>
|
||||
Shih-Yuan Lee <fourdollars@gmail.com>
|
||||
Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com> root <root@vagrant-ubuntu-12.10.vagrantup.com>
|
||||
Jean-Baptiste Dalido <jeanbaptiste@appgratis.com>
|
||||
<proppy@google.com> <proppy@aminche.com>
|
||||
<michael@docker.com> <michael@crosbymichael.com>
|
||||
<michael@docker.com> <crosby.michael@gmail.com>
|
||||
<michael@docker.com> <crosbymichael@gmail.com>
|
||||
<github@developersupport.net> <github@metaliveblog.com>
|
||||
<brandon@ifup.org> <brandon@ifup.co>
|
||||
<dano@spotify.com> <daniel.norberg@gmail.com>
|
||||
<danny@codeaholics.org> <Danny.Yates@mailonline.co.uk>
|
||||
<gurjeet@singh.im> <singh.gurjeet@gmail.com>
|
||||
<shawn@churchofgit.com> <shawnlandden@gmail.com>
|
||||
<sjoerd-github@linuxonly.nl> <sjoerd@byte.nl>
|
||||
<solomon@docker.com> <solomon.hykes@dotcloud.com>
|
||||
<solomon@docker.com> <solomon@dotcloud.com>
|
||||
<solomon@docker.com> <s@docker.com>
|
||||
Sven Dowideit <SvenDowideit@home.org.au>
|
||||
Sven Dowideit <SvenDowideit@home.org.au> <SvenDowideit@fosiki.com>
|
||||
Sven Dowideit <SvenDowideit@home.org.au> <SvenDowideit@docker.com>
|
||||
Sven Dowideit <SvenDowideit@home.org.au> <¨SvenDowideit@home.org.au¨>
|
||||
Sven Dowideit <SvenDowideit@home.org.au> <SvenDowideit@home.org.au>
|
||||
Sven Dowideit <SvenDowideit@home.org.au> <SvenDowideit@users.noreply.github.com>
|
||||
Sven Dowideit <SvenDowideit@home.org.au> <sven@t440s.home.gateway>
|
||||
<alexl@redhat.com> <alexander.larsson@gmail.com>
|
||||
Alexander Morozov <lk4d4@docker.com> <lk4d4math@gmail.com>
|
||||
Alexander Morozov <lk4d4@docker.com>
|
||||
<git.nivoc@neverbox.com> <kuehnle@online.de>
|
||||
O.S. Tezer <ostezer@gmail.com>
|
||||
<ostezer@gmail.com> <ostezer@users.noreply.github.com>
|
||||
Roberto G. Hashioka <roberto.hashioka@docker.com> <roberto_hashioka@hotmail.com>
|
||||
<justin.p.simonelis@gmail.com> <justin.simonelis@PTS-JSIMON2.toronto.exclamation.com>
|
||||
<taim@bosboot.org> <maztaim@users.noreply.github.com>
|
||||
<viktor.vojnovski@amadeus.com> <vojnovski@gmail.com>
|
||||
<vbatts@redhat.com> <vbatts@hashbangbash.com>
|
||||
<altsysrq@gmail.com> <iamironbob@gmail.com>
|
||||
Sridhar Ratnakumar <sridharr@activestate.com>
|
||||
Sridhar Ratnakumar <sridharr@activestate.com> <github@srid.name>
|
||||
Liang-Chi Hsieh <viirya@gmail.com>
|
||||
Aleksa Sarai <asarai@suse.de>
|
||||
Aleksa Sarai <asarai@suse.de> <asarai@suse.com>
|
||||
Aleksa Sarai <asarai@suse.de> <cyphar@cyphar.com>
|
||||
Will Weaver <monkey@buildingbananas.com>
|
||||
Timothy Hobbs <timothyhobbs@seznam.cz>
|
||||
Nathan LeClaire <nathan.leclaire@docker.com> <nathan.leclaire@gmail.com>
|
||||
Nathan LeClaire <nathan.leclaire@docker.com> <nathanleclaire@gmail.com>
|
||||
<github@hollensbe.org> <erik+github@hollensbe.org>
|
||||
<github@albersweb.de> <albers@users.noreply.github.com>
|
||||
<lsm5@fedoraproject.org> <lsm5@redhat.com>
|
||||
<marc@marc-abramowitz.com> <msabramo@gmail.com>
|
||||
Matthew Heon <mheon@redhat.com> <mheon@mheonlaptop.redhat.com>
|
||||
<bernat@luffy.cx> <vincent@bernat.im>
|
||||
<bernat@luffy.cx> <Vincent.Bernat@exoscale.ch>
|
||||
<p@pwaller.net> <peter@scraperwiki.com>
|
||||
<andrew.weiss@outlook.com> <andrew.weiss@microsoft.com>
|
||||
Francisco Carriedo <fcarriedo@gmail.com>
|
||||
<julienbordellier@gmail.com> <git@julienbordellier.com>
|
||||
<ahmetb@microsoft.com> <ahmetalpbalkan@gmail.com>
|
||||
<arnaud.porterie@docker.com> <icecrime@gmail.com>
|
||||
<baloo@gandi.net> <superbaloo+registrations.github@superbaloo.net>
|
||||
Brian Goff <cpuguy83@gmail.com>
|
||||
<cpuguy83@gmail.com> <bgoff@cpuguy83-mbp.home>
|
||||
<eric@windisch.us> <ewindisch@docker.com>
|
||||
<frank.rosquin+github@gmail.com> <frank.rosquin@gmail.com>
|
||||
Hollie Teal <hollie@docker.com>
|
||||
<hollie@docker.com> <hollie.teal@docker.com>
|
||||
<hollie@docker.com> <hollietealok@users.noreply.github.com>
|
||||
<huu@prismskylabs.com> <whoshuu@gmail.com>
|
||||
Jessica Frazelle <jess@mesosphere.com>
|
||||
Jessica Frazelle <jess@mesosphere.com> <jfrazelle@users.noreply.github.com>
|
||||
Jessica Frazelle <jess@mesosphere.com> <acidburn@docker.com>
|
||||
Jessica Frazelle <jess@mesosphere.com> <jess@docker.com>
|
||||
Jessica Frazelle <jess@mesosphere.com> <princess@docker.com>
|
||||
<konrad.wilhelm.kleine@gmail.com> <kwk@users.noreply.github.com>
|
||||
<tintypemolly@gmail.com> <tintypemolly@Ohui-MacBook-Pro.local>
|
||||
<estesp@linux.vnet.ibm.com> <estesp@gmail.com>
|
||||
<github@gone.nl> <thaJeztah@users.noreply.github.com>
|
||||
Thomas LEVEIL <thomasleveil@gmail.com> Thomas LÉVEIL <thomasleveil@users.noreply.github.com>
|
||||
<oi@truffles.me.uk> <timruffles@googlemail.com>
|
||||
<Vincent.Bernat@exoscale.ch> <bernat@luffy.cx>
|
||||
Antonio Murdaca <antonio.murdaca@gmail.com> <amurdaca@redhat.com>
|
||||
Antonio Murdaca <antonio.murdaca@gmail.com> <runcom@redhat.com>
|
||||
Antonio Murdaca <antonio.murdaca@gmail.com> <me@runcom.ninja>
|
||||
Antonio Murdaca <antonio.murdaca@gmail.com> <runcom@linux.com>
|
||||
Antonio Murdaca <antonio.murdaca@gmail.com> <runcom@users.noreply.github.com>
|
||||
Darren Shepherd <darren.s.shepherd@gmail.com> <darren@rancher.com>
|
||||
Deshi Xiao <dxiao@redhat.com> <dsxiao@dataman-inc.com>
|
||||
Deshi Xiao <dxiao@redhat.com> <xiaods@gmail.com>
|
||||
Doug Davis <dug@us.ibm.com> <duglin@users.noreply.github.com>
|
||||
Jacob Atzen <jacob@jacobatzen.dk> <jatzen@gmail.com>
|
||||
Jeff Nickoloff <jeff.nickoloff@gmail.com> <jeff@allingeek.com>
|
||||
John Howard (VM) <John.Howard@microsoft.com> <jhowardmsft@users.noreply.github.com>
|
||||
John Howard (VM) <John.Howard@microsoft.com>
|
||||
John Howard (VM) <John.Howard@microsoft.com> <john.howard@microsoft.com>
|
||||
John Howard (VM) <John.Howard@microsoft.com> <jhoward@microsoft.com>
|
||||
Madhu Venugopal <madhu@socketplane.io> <madhu@docker.com>
|
||||
Mary Anthony <mary.anthony@docker.com> <mary@docker.com>
|
||||
Mary Anthony <mary.anthony@docker.com> moxiegirl <mary@docker.com>
|
||||
Mary Anthony <mary.anthony@docker.com> <moxieandmore@gmail.com>
|
||||
mattyw <mattyw@me.com> <gh@mattyw.net>
|
||||
resouer <resouer@163.com> <resouer@gmail.com>
|
||||
AJ Bowen <aj@gandi.net> soulshake <amy@gandi.net>
|
||||
AJ Bowen <aj@gandi.net> soulshake <aj@gandi.net>
|
||||
Tibor Vass <teabee89@gmail.com> <tibor@docker.com>
|
||||
Tibor Vass <teabee89@gmail.com> <tiborvass@users.noreply.github.com>
|
||||
Vincent Bernat <bernat@luffy.cx> <Vincent.Bernat@exoscale.ch>
|
||||
Yestin Sun <sunyi0804@gmail.com> <yestin.sun@polyera.com>
|
||||
bin liu <liubin0329@users.noreply.github.com> <liubin0329@gmail.com>
|
||||
John Howard (VM) <John.Howard@microsoft.com> jhowardmsft <jhoward@microsoft.com>
|
||||
Ankush Agarwal <ankushagarwal11@gmail.com> <ankushagarwal@users.noreply.github.com>
|
||||
Tangi COLIN <tangicolin@gmail.com> tangicolin <tangicolin@gmail.com>
|
||||
Allen Sun <allen.sun@daocloud.io>
|
||||
Adrien Gallouët <adrien@gallouet.fr> <angt@users.noreply.github.com>
|
||||
<aanm90@gmail.com> <martins@noironetworks.com>
|
||||
Anuj Bahuguna <anujbahuguna.dev@gmail.com>
|
||||
Anusha Ragunathan <anusha.ragunathan@docker.com> <anusha@docker.com>
|
||||
Avi Miller <avi.miller@oracle.com> <avi.miller@gmail.com>
|
||||
Brent Salisbury <brent.salisbury@docker.com> <brent@docker.com>
|
||||
Chander G <chandergovind@gmail.com>
|
||||
Chun Chen <ramichen@tencent.com> <chenchun.feed@gmail.com>
|
||||
Ying Li <cyli@twistedmatrix.com>
|
||||
Daehyeok Mun <daehyeok@gmail.com> <daehyeok@daehyeok-ui-MacBook-Air.local>
|
||||
<dqminh@cloudflare.com> <dqminh89@gmail.com>
|
||||
Daniel, Dao Quang Minh <dqminh@cloudflare.com>
|
||||
Daniel Nephin <dnephin@docker.com> <dnephin@gmail.com>
|
||||
Dave Tucker <dt@docker.com> <dave@dtucker.co.uk>
|
||||
Doug Tangren <d.tangren@gmail.com>
|
||||
Frederick F. Kautz IV <fkautz@redhat.com> <fkautz@alumni.cmu.edu>
|
||||
Ben Golub <ben.golub@dotcloud.com>
|
||||
Harold Cooper <hrldcpr@gmail.com>
|
||||
hsinko <21551195@zju.edu.cn> <hsinko@users.noreply.github.com>
|
||||
Josh Hawn <josh.hawn@docker.com> <jlhawn@berkeley.edu>
|
||||
Justin Cormack <justin.cormack@docker.com>
|
||||
<justin.cormack@docker.com> <justin.cormack@unikernel.com>
|
||||
<justin.cormack@docker.com> <justin@specialbusservice.com>
|
||||
Kamil Domański <kamil@domanski.co>
|
||||
Lei Jitang <leijitang@huawei.com>
|
||||
<leijitang@huawei.com> <leijitang@gmail.com>
|
||||
Linus Heckemann <lheckemann@twig-world.com>
|
||||
<lheckemann@twig-world.com> <anonymouse2048@gmail.com>
|
||||
Lynda O'Leary <lyndaoleary29@gmail.com>
|
||||
<lyndaoleary29@gmail.com> <lyndaoleary@hotmail.com>
|
||||
Marianna Tessel <mtesselh@gmail.com>
|
||||
Michael Huettermann <michael@huettermann.net>
|
||||
Moysés Borges <moysesb@gmail.com>
|
||||
<moysesb@gmail.com> <moyses.furtado@wplex.com.br>
|
||||
Nigel Poulton <nigelpoulton@hotmail.com>
|
||||
Qiang Huang <h.huangqiang@huawei.com>
|
||||
<h.huangqiang@huawei.com> <qhuang@10.0.2.15>
|
||||
Boaz Shuster <ripcurld.github@gmail.com>
|
||||
Shuwei Hao <haosw@cn.ibm.com>
|
||||
<haosw@cn.ibm.com> <haoshuwei24@gmail.com>
|
||||
Soshi Katsuta <soshi.katsuta@gmail.com>
|
||||
<soshi.katsuta@gmail.com> <katsuta_soshi@cyberagent.co.jp>
|
||||
Stefan Berger <stefanb@linux.vnet.ibm.com>
|
||||
<stefanb@linux.vnet.ibm.com> <stefanb@us.ibm.com>
|
||||
Stephen Day <stephen.day@docker.com>
|
||||
<stephen.day@docker.com> <stevvooe@users.noreply.github.com>
|
||||
Toli Kuznets <toli@docker.com>
|
||||
Tristan Carel <tristan@cogniteev.com>
|
||||
<tristan@cogniteev.com> <tristan.carel@gmail.com>
|
||||
Vincent Demeester <vincent@sbr.pm>
|
||||
<vincent@sbr.pm> <vincent+github@demeester.fr>
|
||||
Vishnu Kannan <vishnuk@google.com>
|
||||
xlgao-zju <xlgao@zju.edu.cn> xlgao <xlgao@zju.edu.cn>
|
||||
yuchangchun <yuchangchun1@huawei.com> y00277921 <yuchangchun1@huawei.com>
|
||||
<zij@case.edu> <zjaffee@us.ibm.com>
|
||||
<anujbahuguna.dev@gmail.com> <abahuguna@fiberlink.com>
|
||||
<eungjun.yi@navercorp.com> <semtlenori@gmail.com>
|
||||
<haosw@cn.ibm.com> <haoshuwei1989@163.com>
|
||||
Hao Shu Wei <haosw@cn.ibm.com>
|
||||
<matt.bentley@docker.com> <mbentley@mbentley.net>
|
||||
<MihaiBorob@gmail.com> <MihaiBorobocea@gmail.com>
|
||||
<redmond.martin@gmail.com> <xgithub@redmond5.com>
|
||||
<redmond.martin@gmail.com> <martin@tinychat.com>
|
||||
<srbrahma@us.ibm.com> <sbrahma@us.ibm.com>
|
||||
<suda.akihiro@lab.ntt.co.jp> <suda.kyoto@gmail.com>
|
||||
<thomas@gazagnaire.org> <thomas@gazagnaire.com>
|
||||
Shengbo Song <thomassong@tencent.com> mYmNeo <mymneo@163.com>
|
||||
Shengbo Song <thomassong@tencent.com>
|
||||
<sylvain@ascribe.io> <sylvain.bellemare@ezeep.com>
|
||||
Sylvain Bellemare <sylvain@ascribe.io>
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
- repo: git://github.com/pre-commit/pre-commit-hooks
|
||||
sha: 'v0.4.2'
|
||||
hooks:
|
||||
- id: check-added-large-files
|
||||
- id: check-docstring-first
|
||||
- id: check-merge-conflict
|
||||
- id: check-yaml
|
||||
- id: check-json
|
||||
- id: debug-statements
|
||||
- id: end-of-file-fixer
|
||||
- id: flake8
|
||||
- id: name-tests-test
|
||||
exclude: 'tests/(integration/testcases\.py|helpers\.py)'
|
||||
- id: requirements-txt-fixer
|
||||
- id: trailing-whitespace
|
||||
- repo: git://github.com/asottile/reorder_python_imports
|
||||
sha: v0.1.0
|
||||
hooks:
|
||||
- id: reorder-python-imports
|
||||
language_version: 'python2.7'
|
||||
args:
|
||||
- --add-import
|
||||
- from __future__ import absolute_import
|
||||
- --add-import
|
||||
- from __future__ import unicode_literals
|
11
.stylelintrc
11
.stylelintrc
|
@ -1,11 +0,0 @@
|
|||
{
|
||||
"extends": "stylelint-config-standard",
|
||||
"rules": {
|
||||
"color-hex-length": "long"
|
||||
},
|
||||
"ignoreFiles": [
|
||||
"node_modules/**/**.css",
|
||||
"coverage/**/**.css",
|
||||
"dist/**/**.css"
|
||||
]
|
||||
}
|
87
404.md
87
404.md
|
@ -5,29 +5,53 @@ permalink: /404.html
|
|||
---
|
||||
|
||||
<script language="JavaScript">
|
||||
function doFwd() {
|
||||
var forwardingURL=window.location.href;
|
||||
var domainName = window.location.hostname;
|
||||
var portNumber = window.location.port;
|
||||
var gonnaFwd = false;
|
||||
var newURL = "";
|
||||
console.log(forwardingURL);
|
||||
var forwardingURL=window.location.pathname;
|
||||
if (forwardingURL.charAt(forwardingURL.length - 1) != "/") forwardingURL += "/";
|
||||
var gonnaFwd = false;
|
||||
var newURL = "";
|
||||
var baseURL = "";
|
||||
var archive = false;
|
||||
console.log(forwardingURL);
|
||||
|
||||
// .MD EXTENSION CHECK
|
||||
if (forwardingURL.indexOf(".md") > -1)
|
||||
{
|
||||
gonnaFwd = true;
|
||||
newURL = forwardingURL.replace(".md","");
|
||||
} else {
|
||||
|
||||
// DOCS ARCHIVE CHECK
|
||||
{% for item in site.data.docsarchive.docker-compose %}
|
||||
if (forwardingURL.indexOf("/{{ item[0] }}") > -1)
|
||||
{
|
||||
console.log("Found via Docker Compose file for Acrhive")
|
||||
gonnaFwd = true;
|
||||
archive = true;
|
||||
// make it so redirects cascade; first, use the base URL, then append path
|
||||
baseURL = "{{ page.archiveserver }}:{{ item[1].ports[0] | replace:':4000','' }}";
|
||||
newURL = forwardingURL.replace("/{{ item[0] }}","");
|
||||
}{% endfor %}
|
||||
|
||||
if (archive==false) {
|
||||
// CSV CHECK
|
||||
{% for item in site.data.redirects %}
|
||||
var redirectVal = {{ item | jsonify }};
|
||||
if (forwardingURL.indexOf(redirectVal.source) > -1)
|
||||
if (forwardingURL == redirectVal.source)
|
||||
{
|
||||
console.log("Found via CSV @ ", redirectVal.source, redirectVal.destination);
|
||||
gonnaFwd = true;
|
||||
newURL = forwardingURL.replace(redirectVal.source,redirectVal.destination);
|
||||
}
|
||||
{% endfor %}
|
||||
{% for page in site.pages %}{% if page.aliases %}
|
||||
{% endfor %}
|
||||
|
||||
// PAGE ALIASES CHECK
|
||||
{% for page in site.pages %}{% if page.aliases %}
|
||||
var aliases = {{ page.aliases | jsonify }};
|
||||
if( Object.prototype.toString.call( aliases ) === '[object Array]' ) {
|
||||
// aliases is an array, therefore, there are multiple aliases
|
||||
for (i=0; i< aliases.length; i++)
|
||||
{
|
||||
if (forwardingURL.indexOf(aliases[i]) > -1)
|
||||
if (forwardingURL == aliases[i])
|
||||
{
|
||||
console.log("Found via Page Aliases on a multi-alias page @", "{{ page.url }}", aliases[i])
|
||||
gonnaFwd = true;
|
||||
|
@ -36,36 +60,27 @@ function doFwd() {
|
|||
}
|
||||
} else {
|
||||
// only one alias for this page.
|
||||
if (forwardingURL.indexOf(aliases) > -1)
|
||||
if (forwardingURL == aliases)
|
||||
{
|
||||
console.log("Found via Page Aliases on a single-alias page @", forwardingURL.indexOf(aliases[i]), aliases[i])
|
||||
gonnaFwd = true;
|
||||
newURL = "{{ page.url }}";
|
||||
}
|
||||
}
|
||||
{% endif %}{% endfor %}
|
||||
{% for item in site.data.docsarchive.docker-compose %}
|
||||
if (forwardingURL.indexOf("/{{ item[0] }}") > -1)
|
||||
{
|
||||
console.log("Found via Docker Compose file for Acrhive")
|
||||
gonnaFwd = true;
|
||||
if(portNumber.length > 0) {
|
||||
// there is a port number in the location; make sure to replace it
|
||||
newURL = forwardingURL.replace(domainName + ":"+ portNumber +"/{{ item[0] }}","{{ page.archiveserver }}:{{ item[1].ports[0] | replace:':4000','' }}");
|
||||
} else {
|
||||
// no port number in the location; just foward them on
|
||||
newURL = forwardingURL.replace(domainName + "/{{ item[0] }}","{{ page.archiveserver }}:{{ item[1].ports[0] | replace:':4000','' }}");
|
||||
}
|
||||
newURL = newURL.replace("https:","http:")
|
||||
}{% endfor %}
|
||||
if (gonnaFwd) {
|
||||
console.log("Forwarding to: " + newURL);
|
||||
window.location.replace(newURL);
|
||||
document.write('<meta http-equiv="refresh" content="0; url=' + newURL + '">')
|
||||
} else {
|
||||
window.location.replace("/sorry/#" + forwardingURL);
|
||||
document.write('<meta http-equiv="refresh" content="0; url=/sorry/#' + forwardingURL + '">')
|
||||
}
|
||||
{% endif %}{% endfor %}
|
||||
|
||||
} // end of check for .md
|
||||
} // end of check for archive
|
||||
|
||||
if (gonnaFwd) {
|
||||
newURL = baseURL + newURL;
|
||||
console.log("Forwarding to: " + newURL);
|
||||
window.location.replace(newURL);
|
||||
window.location.href = newURL;
|
||||
document.write('<meta http-equiv="refresh" content="0; url=' + newURL + '">')
|
||||
} else {
|
||||
window.location.replace("/sorry/#" + forwardingURL);
|
||||
window.location.href = "/sorry/#" + forwardingURL;
|
||||
document.write('<meta http-equiv="refresh" content="0; url=/sorry/#' + forwardingURL + '">')
|
||||
}
|
||||
window.onload = doFwd;
|
||||
</script>
|
||||
|
|
63
Dockerfile
63
Dockerfile
|
@ -1,9 +1,62 @@
|
|||
FROM starefossen/github-pages:onbuild
|
||||
FROM starefossen/github-pages
|
||||
|
||||
ONBUILD RUN git clone https://www.github.com/docker/docker.github.io docs
|
||||
RUN git clone https://www.github.com/docker/docker.github.io allv
|
||||
RUN jekyll build -s allv -d allvbuild
|
||||
|
||||
ONBUILD WORKDIR docs
|
||||
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.4
|
||||
RUN mkdir allvbuild/v1.4
|
||||
RUN jekyll build -s allv -d allvbuild/v1.4
|
||||
RUN find allvbuild/v1.4 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="/#href="/v1.4/#g'
|
||||
RUN find allvbuild/v1.4 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.4/#g'
|
||||
RUN find allvbuild/v1.4 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.4/#g'
|
||||
|
||||
ONBUILD COPY . /usr/src/app
|
||||
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.5
|
||||
RUN mkdir allvbuild/v1.5
|
||||
RUN jekyll build -s allv -d allvbuild/v1.5
|
||||
RUN find allvbuild/v1.5 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="/#href="/v1.5/#g'
|
||||
RUN find allvbuild/v1.5 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.5/#g'
|
||||
RUN find allvbuild/v1.5 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.5/#g'
|
||||
|
||||
CMD jekyll serve -d /_site --watch -H 0.0.0.0 -P 4000
|
||||
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.6
|
||||
RUN mkdir allvbuild/v1.6
|
||||
RUN jekyll build -s allv -d allvbuild/v1.6
|
||||
RUN find allvbuild/v1.6 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="/#href="/v1.6/#g'
|
||||
RUN find allvbuild/v1.6 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.6/#g'
|
||||
RUN find allvbuild/v1.6 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.6/#g'
|
||||
|
||||
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.7
|
||||
RUN mkdir allvbuild/v1.7
|
||||
RUN jekyll build -s allv -d allvbuild/v1.7
|
||||
RUN find allvbuild/v1.7 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="/#href="/v1.7/#g'
|
||||
RUN find allvbuild/v1.7 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.7/#g'
|
||||
RUN find allvbuild/v1.7 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.7/#g'
|
||||
|
||||
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.8
|
||||
RUN mkdir allvbuild/v1.8
|
||||
RUN jekyll build -s allv -d allvbuild/v1.8
|
||||
RUN find allvbuild/v1.8 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="/#href="/v1.8/#g'
|
||||
RUN find allvbuild/v1.8 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.8/#g'
|
||||
RUN find allvbuild/v1.8 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.8/#g'
|
||||
|
||||
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.9
|
||||
RUN mkdir allvbuild/v1.9
|
||||
RUN jekyll build -s allv -d allvbuild/v1.9
|
||||
RUN find allvbuild/v1.9 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="/#href="/v1.9/#g'
|
||||
RUN find allvbuild/v1.9 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.9/#g'
|
||||
RUN find allvbuild/v1.9 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.9/#g'
|
||||
|
||||
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.10
|
||||
RUN mkdir allvbuild/v1.10
|
||||
RUN jekyll build -s allv -d allvbuild/v1.10
|
||||
RUN find allvbuild/v1.10 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="/#href="/v1.10/#g'
|
||||
RUN find allvbuild/v1.10 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.10/#g'
|
||||
RUN find allvbuild/v1.10 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.10/#g'
|
||||
|
||||
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.11
|
||||
RUN mkdir allvbuild/v1.11
|
||||
RUN jekyll build -s allv -d allvbuild/v1.11
|
||||
RUN find allvbuild/v1.11 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="/#href="/v1.11/#g'
|
||||
RUN find allvbuild/v1.11 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.11/#g'
|
||||
RUN find allvbuild/v1.11 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.11/#g'
|
||||
|
||||
CMD jekyll serve -s /usr/src/app/allvbuild -d /_site --no-watch -H 0.0.0.0 -P 4000
|
||||
|
|
125
README.md
125
README.md
|
@ -1,18 +1,104 @@
|
|||
# Docs @ Docker
|
||||
|
||||
Welcome to the repo for our documentation. This is the source for the URL
|
||||
served at docs.docker.com.
|
||||
served at https://docs.docker.com/.
|
||||
|
||||
Feel free to send us pull requests and file issues. Our docs are completely
|
||||
open source and we deeply appreciate contributions from our community!
|
||||
|
||||
## Providing feedback
|
||||
|
||||
We really want your feedback, and we've made it easy. You can edit, rate, or
|
||||
file an issue at the bottom of every page on docs.docker.com.
|
||||
|
||||
**Please only file issues about the documentation in this repository.** One way
|
||||
to think about this is that you should file a bug here if your issue is that you
|
||||
don't see something that should be in the docs, or you see something incorrect
|
||||
or confusing in the docs.
|
||||
|
||||
- If your problem is a general question about how to configure or use Docker,
|
||||
consider asking a question on https://forums.docker.com instead.
|
||||
|
||||
- If you have an idea for a new feature or behavior change in a specific aspect
|
||||
of Docker, or have found a bug in part of Docker, please file that issue in
|
||||
the project's code repository.
|
||||
|
||||
## Contributing
|
||||
|
||||
We value your documentation contributions, and we want to make it as easy
|
||||
as possible to work in this repository. One of the first things to decide is
|
||||
which branch to base your work on. If you get confused, just ask and we will
|
||||
help. If a reviewer realizes you have based your work on the wrong branch, we'll
|
||||
let you know so that you can rebase it.
|
||||
|
||||
>**Note**: To contribute code to Docker projects, see the
|
||||
[Contribution guidelines](opensource/project/who-written-for).
|
||||
|
||||
### Overall doc improvements
|
||||
|
||||
Most commits will be made against the `master` branch. This include:
|
||||
|
||||
- Conceptual and task-based information not specific to new features
|
||||
- Restructuring / rewriting
|
||||
- Doc bug fixing
|
||||
- Typos and grammar errors
|
||||
|
||||
One quirk of this project is that the `master` branch is where the live docs are
|
||||
published from, so upcoming features can't be documented there. See
|
||||
[Specific new features for a project](#specific-new-features-for-a-project)
|
||||
for how to document upcoming features. These feature branches will be periodically
|
||||
merged with `master`, so don't worry about fixing typos and documentation bugs
|
||||
there.
|
||||
|
||||
>Do you enjoy creating graphics? Good graphics are key to great documentation,
|
||||
and we especially value contributions in this area.
|
||||
|
||||
### Specific new features for a project
|
||||
|
||||
Our docs cover many projects which release at different times. **If, and only if,
|
||||
your pull request relates to a currently unreleased feature of a project, base
|
||||
your work on that project's `vnext` branch.** These branches were created by
|
||||
cloning `master` and then importing a project's `master` branch's docs into it
|
||||
(at the time of the migration), in a way that preserved the commit history. When
|
||||
a project has a release, its `vnext` branch will be merged into `master` and your
|
||||
work will be visible on docs.docker.com.
|
||||
|
||||
The following `vnext` branches currently exist:
|
||||
|
||||
- **[vnext-engine](https://github.com/docker/docker.github.io/tree/vnext-engine):**
|
||||
docs for upcoming features in the [docker/docker](https://github.com/docker/docker/)
|
||||
project
|
||||
|
||||
- **[vnext-compose](https://github.com/docker/docker.github.io/tree/vnext-compose):**
|
||||
docs for upcoming features in the [docker/compose](https://github.com/docker/compose/)
|
||||
project
|
||||
|
||||
- **[vnext-distribution](https://github.com/docker/docker.github.io/tree/vnext-distribution):**
|
||||
docs for upcoming features in the [docker/distribution](https://github.com/docker/distribution/)
|
||||
project
|
||||
|
||||
- **[vnext-opensource](https://github.com/docker/docker.github.io/tree/vnext-opensource):**
|
||||
docs for upcoming features in the [docker/opensource](https://github.com/docker/opensource/)
|
||||
project
|
||||
|
||||
- **[vnext-swarm](https://github.com/docker/docker.github.io/tree/vnext-swarm):**
|
||||
docs for upcoming features in the [docker/swarm](https://github.com/docker/swarm/)
|
||||
project
|
||||
|
||||
- **[vnext-toolbox](https://github.com/docker/docker.github.io/tree/vnext-toolbox):**
|
||||
docs for upcoming features in the [docker/toolbox](https://github.com/docker/toolbox/)
|
||||
project
|
||||
|
||||
- **[vnext-kitematic](https://github.com/docker/docker.github.io/tree/vnext-kitematic):**
|
||||
docs for upcoming features in the [docker/kitematic](https://github.com/docker/kitematic/)
|
||||
project
|
||||
|
||||
|
||||
## Staging
|
||||
|
||||
You have three options:
|
||||
|
||||
1. (Most performant, slowest setup) Clone this repo, [install Ruby 2.3 or higher (required)](https://www.ruby-lang.org/en/documentation/installation/), [install the GitHub Pages Ruby gem](https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/), then run `jekyll serve` from within the directory.
|
||||
2. (Slow performance on Mac/Windows, fast setup) Clone this repo and run our
|
||||
staging container:
|
||||
1. Clone this repo and run our staging container:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/docker/docker.github.io.git
|
||||
|
@ -20,12 +106,33 @@ You have three options:
|
|||
docker-compose up
|
||||
```
|
||||
|
||||
If you haven't got Docker Compose installed, [follow these installation instructions](https://docs.docker.com/compose/install/).
|
||||
3. (Edit entirely in the browser, no local clone) Fork this repo in GitHub, change your fork's repository name to `YOUR_GITHUB_USERNAME.github.io`, and make any changes.
|
||||
If you haven't got Docker Compose installed,
|
||||
[follow these installation instructions](/compose/install/).
|
||||
|
||||
In the first two options, the site will be staged at `http://localhost:4000` (unless Jekyll is behaving in some non-default way).
|
||||
The container runs in the background and incrementally rebuilds the site each
|
||||
time a file changes. You can keep your browser open to http://localhost:4000/
|
||||
and refresh to see your changes. The container runs in the foreground, but
|
||||
you can use `CTRL+C` to get the command prompt back. To stop the container,
|
||||
issue the following command:
|
||||
|
||||
In the third option, the site will be viewable at `http://YOUR_GITHUB_USERNAME.github.io`, about a minute after your first change is merged into your fork.
|
||||
```bash
|
||||
docker-compose down
|
||||
```
|
||||
|
||||
2. Use Jekyll directly. Clone this repo, [install Ruby 2.3 or higher
|
||||
(required)](https://www.ruby-lang.org/en/documentation/installation/),
|
||||
[install the GitHub Pages Ruby gem](https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/),
|
||||
then run `jekyll serve` from within the directory.
|
||||
|
||||
The `jekyll serve` process runs in the foreground, and starts a web server
|
||||
running on http://localhost:4000/ by default. To stop it, use `CTRL+C`.
|
||||
You can continue working in a second terminal and Jekyll will rebuild the
|
||||
website incrementally. Refresh the browser to preview your changes.
|
||||
|
||||
3. Use Github Pages, with or without a local clone. Fork this repo in GitHub,
|
||||
change your fork's repository name to `YOUR_GITHUB_USERNAME.github.io`, and
|
||||
make changes to the Markdown files in your `master` branch. Browse to
|
||||
https://<YOUR_GITHUB_USERNAME>.github.io/ to preview the changes.
|
||||
|
||||
## Important files
|
||||
|
||||
|
@ -43,7 +150,7 @@ directly on docs.docker.com.
|
|||
## Style guide
|
||||
|
||||
If you have questions about how to write for Docker's documentation, please see
|
||||
the [style guide](https://docs.docker.com/opensource/doc-style/). The style guide provides
|
||||
the [style guide](/opensource/doc-style/). The style guide provides
|
||||
guidance about grammar, syntax, formatting, styling, language, or tone. If
|
||||
something isn't clear in the guide, please submit an issue to let us know or
|
||||
submit a pull request to help us improve it.
|
||||
|
|
12
_config.yml
12
_config.yml
|
@ -9,15 +9,17 @@ incremental: true
|
|||
permalink: pretty
|
||||
safe: false
|
||||
lsi: false
|
||||
exclude:
|
||||
- vendor
|
||||
- bin
|
||||
url: https://docs.docker.com
|
||||
|
||||
gems:
|
||||
- jekyll-redirect-from
|
||||
- jekyll-sitemap
|
||||
- jekyll-gist
|
||||
- jekyll-seo-tag
|
||||
|
||||
webrick:
|
||||
headers:
|
||||
Cache-Control: 600
|
||||
|
||||
defaults:
|
||||
-
|
||||
scope:
|
||||
|
@ -25,4 +27,4 @@ defaults:
|
|||
type: "pages"
|
||||
values:
|
||||
layout: docs
|
||||
archiveserver: "54.71.194.30"
|
||||
archiveserver: "http://54.71.194.30"
|
||||
|
|
|
@ -9,4 +9,4 @@ ONBUILD RUN git checkout vnext-compose
|
|||
|
||||
ONBUILD COPY . /usr/src/app
|
||||
|
||||
CMD jekyll serve -d /_site --watch -H 0.0.0.0 -P 4000
|
||||
CMD jekyll serve -d /_site -H 0.0.0.0 -P 4000
|
||||
|
|
|
@ -0,0 +1,12 @@
|
|||
|
||||
FROM starefossen/github-pages:onbuild
|
||||
|
||||
ONBUILD RUN git clone https://www.github.com/docker/docker.github.io docs
|
||||
|
||||
ONBUILD WORKDIR docs
|
||||
|
||||
ONBUILD RUN git checkout vnext-distribution
|
||||
|
||||
ONBUILD COPY . /usr/src/app
|
||||
|
||||
CMD jekyll serve -d /_site -H 0.0.0.0 -P 4000
|
|
@ -0,0 +1,12 @@
|
|||
|
||||
FROM starefossen/github-pages:onbuild
|
||||
|
||||
ONBUILD RUN git clone https://www.github.com/docker/docker.github.io docs
|
||||
|
||||
ONBUILD WORKDIR docs
|
||||
|
||||
ONBUILD RUN git checkout vnext-engine
|
||||
|
||||
ONBUILD COPY . /usr/src/app
|
||||
|
||||
CMD jekyll serve -d /_site -H 0.0.0.0 -P 4000
|
|
@ -0,0 +1,12 @@
|
|||
|
||||
FROM starefossen/github-pages:onbuild
|
||||
|
||||
ONBUILD RUN git clone https://www.github.com/docker/docker.github.io docs
|
||||
|
||||
ONBUILD WORKDIR docs
|
||||
|
||||
ONBUILD RUN git checkout vnext-kitematic
|
||||
|
||||
ONBUILD COPY . /usr/src/app
|
||||
|
||||
CMD jekyll serve -d /_site -H 0.0.0.0 -P 4000
|
|
@ -9,4 +9,4 @@ ONBUILD RUN git checkout vnext-machine
|
|||
|
||||
ONBUILD COPY . /usr/src/app
|
||||
|
||||
CMD jekyll serve -d /_site --watch -H 0.0.0.0 -P 4000
|
||||
CMD jekyll serve -d /_site -H 0.0.0.0 -P 4000
|
||||
|
|
|
@ -0,0 +1,12 @@
|
|||
|
||||
FROM starefossen/github-pages:onbuild
|
||||
|
||||
ONBUILD RUN git clone https://www.github.com/docker/docker.github.io docs
|
||||
|
||||
ONBUILD WORKDIR docs
|
||||
|
||||
ONBUILD RUN git checkout vnext-toolbox
|
||||
|
||||
ONBUILD COPY . /usr/src/app
|
||||
|
||||
CMD jekyll serve -d /_site -H 0.0.0.0 -P 4000
|
|
@ -1,50 +1,50 @@
|
|||
source,destination
|
||||
engine/quickstart/,engine/getstarted/
|
||||
engine/containers/,engine/tutorials/
|
||||
win/,docker-for-windows/
|
||||
mac/,docker-for-mac/
|
||||
linux/,engine/
|
||||
article-img/,engine/article-img/
|
||||
articles/,engine/articles/
|
||||
examples/,engine/examples/
|
||||
extend/,engine/extend/
|
||||
installation/,engine/installation/
|
||||
introduction/,engine/introduction/
|
||||
misc/,engine/misc/
|
||||
project/,opensource/project/
|
||||
reference/,engine/reference/
|
||||
security/,engine/security/
|
||||
static_files/,engine/static_files/
|
||||
userguide/,engine/userguide/
|
||||
en/latest/installation/,engine/installation/
|
||||
docker-hub-enterprise/install/,docker-trusted-registry/install/
|
||||
docker-io/builds/,docker-hub/builds/
|
||||
docker-trusted-registry/license/install-csengine.md,docker-trusted-registry/install/install-csengine/
|
||||
engine/articles/basics/,engine/userguide/basics/
|
||||
engine/project/set-up-git/,opensource/project/set-up-git/
|
||||
engine/reference/articles/basics.md,engine/userguide/basics/
|
||||
engine/userguide/dockerlinks/,engine/userguide/networking/default_network/dockerlinks/
|
||||
installation/,engine/installation/
|
||||
networking/,engine/userguide/networking/
|
||||
opensource/project/advanced-contributing/,opensource/workflow/advanced-contributing/
|
||||
opensource/project/create-pr/,opensource/workflow/create-pr/
|
||||
opensource/project/find-an-issue/,opensource/workflow/find-an-issue/
|
||||
opensource/project/get-help/,opensource/get-help/
|
||||
opensource/project/make-a-contribution/,opensource/workflow/make-a-contribution/
|
||||
opensource/project/review-pr/,opensource/workflow/review-pr/
|
||||
opensource/project/work-issue/,opensource/workflow/work-issue/
|
||||
opensource/workflow/doc-style/,opensource/doc-style/
|
||||
opensource/workflow/get-help/,opensource/get-help/
|
||||
opensource/workflow/set-up-dev-env/,opensource/project/set-up-dev-env/
|
||||
opensource/workflow/set-up-git/,opensource/project/set-up-git/
|
||||
opensource/workflow/test-and-docs/,opensource/project/test-and-docs/
|
||||
userguide/,engine/userguide/
|
||||
docker-trusted-registry/adminguide/upgrade.md,docker-trusted-registry/install/upgrade/
|
||||
docker-trusted-registry/quick-start/install.md,docker-trusted-registry/install/
|
||||
docker-trusted-registry/adminguide/docker-trusted-registry/install.md,docker-trusted-registry/install/
|
||||
v1.6/docker-hub/,docker-hub/
|
||||
v1.7/docker-hub/,docker-hub/
|
||||
v1.8/docker-hub/,docker-hub/
|
||||
v1.9/docker-hub/,docker-hub/
|
||||
v1.10/docker-hub/,docker-hub/
|
||||
v1.11/docker-hub/,docker-hub/
|
||||
/source,destination
|
||||
/engine/quickstart/,/engine/getstarted/
|
||||
/engine/containers/,/engine/tutorials/
|
||||
/win/,/docker-for-windows/
|
||||
/mac/,/docker-for-mac/
|
||||
/linux/,/engine/
|
||||
/article-img/,/engine/article-img/
|
||||
/articles/,/engine/articles/
|
||||
/examples/,/engine/examples/
|
||||
/extend/,/engine/extend/
|
||||
/installation/,/engine/installation/
|
||||
/introduction/,/engine/introduction/
|
||||
/misc/,/engine/misc/
|
||||
/project/,/opensource/project/
|
||||
/reference/,/engine/reference/
|
||||
/security/,/engine/security/
|
||||
/static_files/,/engine/static_files/
|
||||
/userguide/,/engine/userguide/
|
||||
/en/latest/installation/,/engine/installation/
|
||||
/docker-hub-enterprise/install/,/docker-trusted-registry/install/
|
||||
/docker-io/builds/,/docker-hub/builds/
|
||||
/docker-trusted-registry/license/install-csengine.md,/docker-trusted-registry/install/install-csengine/
|
||||
/engine/articles/basics/,/engine/userguide/basics/
|
||||
/engine/project/set-up-git/,/opensource/project/set-up-git/
|
||||
/engine/reference/articles/basics.md,/engine/userguide/basics/
|
||||
/engine/userguide/dockerlinks/,/engine/userguide/networking/default_network/dockerlinks/
|
||||
/installation/,/engine/installation/
|
||||
/networking/,/engine/userguide/networking/
|
||||
/opensource/project/advanced-contributing/,/opensource/workflow/advanced-contributing/
|
||||
/opensource/project/create-pr/,/opensource/workflow/create-pr/
|
||||
/opensource/project/find-an-issue/,/opensource/workflow/find-an-issue/
|
||||
/opensource/project/get-help/,/opensource/get-help/
|
||||
/opensource/project/make-a-contribution/,/opensource/workflow/make-a-contribution/
|
||||
/opensource/project/review-pr/,/opensource/workflow/review-pr/
|
||||
/opensource/project/work-issue/,/opensource/workflow/work-issue/
|
||||
/opensource/workflow/doc-style/,/opensource/doc-style/
|
||||
/opensource/workflow/get-help/,/opensource/get-help/
|
||||
/opensource/workflow/set-up-dev-env/,/opensource/project/set-up-dev-env/
|
||||
/opensource/workflow/set-up-git/,/opensource/project/set-up-git/
|
||||
/opensource/workflow/test-and-docs/,/opensource/project/test-and-docs/
|
||||
/userguide/,/engine/userguide/
|
||||
/docker-trusted-registry/adminguide/upgrade.md,/docker-trusted-registry/install/upgrade/
|
||||
/docker-trusted-registry/quick-start/install.md,/docker-trusted-registry/install/
|
||||
/docker-trusted-registry/adminguide/docker-trusted-registry/install.md,/docker-trusted-registry/install/
|
||||
/v1.6/docker-hub/,/docker-hub/
|
||||
/v1.7/docker-hub/,/docker-hub/
|
||||
/v1.8/docker-hub/,/docker-hub/
|
||||
/v1.9/docker-hub/,/docker-hub/
|
||||
/v1.10/docker-hub/,/docker-hub/
|
||||
/v1.11/docker-hub/,/docker-hub/
|
||||
|
|
|
|
@ -6,7 +6,7 @@ toc:
|
|||
- sectiontitle: Install
|
||||
section:
|
||||
- path: /engine/installation/mac/
|
||||
title: Installation on Mac OS X
|
||||
title: Installation on macOS
|
||||
- path: /engine/installation/windows/
|
||||
title: Installation on Windows
|
||||
- sectiontitle: On Linux distributions
|
||||
|
@ -25,8 +25,6 @@ toc:
|
|||
title: Installation on Arch Linux
|
||||
- path: /engine/installation/linux/cruxlinux/
|
||||
title: Installation on CRUX Linux
|
||||
- path: /engine/installation/linux/frugalware/
|
||||
title: Installation on FrugalWare
|
||||
- path: /engine/installation/linux/gentoolinux/
|
||||
title: Installation on Gentoo
|
||||
- path: /engine/installation/linux/oracle/
|
||||
|
@ -111,6 +109,8 @@ toc:
|
|||
title: Work with network commands
|
||||
- path: /engine/userguide/networking/get-started-overlay/
|
||||
title: Get started with multi-host networking
|
||||
- path: /engine/userguide/networking/get-started-macvlan/
|
||||
title: Get started with macvlan network driver
|
||||
- path: /engine/userguide/networking/overlay-security-model/
|
||||
title: Swarm mode overlay network security model
|
||||
- path: /engine/userguide/networking/configure-dns/
|
||||
|
@ -167,6 +167,8 @@ toc:
|
|||
title: Splunk logging driver
|
||||
- path: /engine/admin/dsc/
|
||||
title: PowerShell DSC Usage
|
||||
- path: /engine/admin/ansible/
|
||||
title: Using Ansible
|
||||
- path: /engine/admin/chef/
|
||||
title: Using Chef
|
||||
- path: /engine/admin/puppet/
|
||||
|
@ -253,6 +255,8 @@ toc:
|
|||
title: Seccomp security profiles for Docker
|
||||
- sectiontitle: Extend Engine
|
||||
section:
|
||||
- path: /engine/extend/
|
||||
title: Managed plugin system
|
||||
- path: /engine/extend/plugins_authorization/
|
||||
title: Access authorization plugin
|
||||
- path: /engine/extend/plugins/
|
||||
|
@ -630,7 +634,9 @@ toc:
|
|||
- path: /ucp/overview/
|
||||
title: Universal Control Plane overview
|
||||
- path: /ucp/install-sandbox/
|
||||
title: Evaluate UCP in a sandbox
|
||||
title: Install DDC in a sandbox for evaluation
|
||||
- path: /ucp/install-sandbox-2/
|
||||
title: Evaluate DDC in a sandbox deployment
|
||||
- path: /ucp/architecture/
|
||||
title: Architecture
|
||||
- sectiontitle: Installation
|
||||
|
@ -769,6 +775,8 @@ toc:
|
|||
title: backup
|
||||
- path: /docker-trusted-registry/reference/dumpcerts/
|
||||
title: dumpcerts
|
||||
- path: /docker-trusted-registry/reference/images/
|
||||
title: images
|
||||
- path: /docker-trusted-registry/reference/install/
|
||||
title: install
|
||||
- path: /docker-trusted-registry/reference/join/
|
||||
|
@ -781,6 +789,8 @@ toc:
|
|||
title: remove
|
||||
- path: /docker-trusted-registry/reference/restore/
|
||||
title: restore
|
||||
- path: /docker-trusted-registry/reference/upgrade/
|
||||
title: upgrade
|
||||
- sectiontitle: Configuration
|
||||
section:
|
||||
- path: /docker-trusted-registry/configure/configuration/
|
||||
|
@ -1095,6 +1105,8 @@ toc:
|
|||
section:
|
||||
- path: /docker-store/
|
||||
title: Docker Store Overview
|
||||
- path: /docker-store/
|
||||
title: Submit a product to Docker Store
|
||||
- path: /docker-store/faq/
|
||||
title: Docker Store FAQs
|
||||
- sectiontitle: Docker Toolbox
|
||||
|
@ -1206,7 +1218,7 @@ toc:
|
|||
- path: /registry/recipes/mirror/
|
||||
title: Mirroring Docker Hub
|
||||
- path: /registry/recipes/osx-setup-guide/
|
||||
title: Running on OS X
|
||||
title: Running on macOS
|
||||
- sectiontitle: Reference
|
||||
section:
|
||||
- path: /registry/spec/
|
||||
|
|
|
@ -1,2 +0,0 @@
|
|||
* TOC
|
||||
{: toc}
|
|
@ -3,7 +3,6 @@
|
|||
{% else %}
|
||||
{% assign crumbs = page.url | split: '/' %}
|
||||
{% assign stoppingpoint = crumbs | size | minus: 1 %}
|
||||
{% assign output = "" %}
|
||||
{% for crumb in crumbs %}
|
||||
{% if forloop.index == stoppingpoint %}
|
||||
{% capture basehref %}{{basehref}}{{ crumb }}/{% endcapture %}
|
||||
|
@ -30,23 +29,17 @@ ng\:form {
|
|||
</style>
|
||||
<script type="text/javascript" async="" src="/js/analytics.js"></script><script async="" src="/js/gtm.js"></script>
|
||||
<script type="text/javascript">window.NREUM||(NREUM={}),__nr_require=function(e,t,n){function r(n){if(!t[n]){var o=t[n]={exports:{}};e[n][0].call(o.exports,function(t){var o=e[n][1][t];return r(o||t)},o,o.exports)}return t[n].exports}if("function"==typeof __nr_require)return __nr_require;for(var o=0;o<n.length;o++)r(n[o]);return r}({1:[function(e,t,n){function r(e,t){return function(){o(e,[(new Date).getTime()].concat(a(arguments)),null,t)}}var o=e("handle"),i=e(2),a=e(3);"undefined"==typeof window.newrelic&&(newrelic=NREUM);var u=["setPageViewName","setCustomAttribute","finished","addToTrace","inlineHit"],c=["addPageAction"],f="api-";i(u,function(e,t){newrelic[t]=r(f+t,"api")}),i(c,function(e,t){newrelic[t]=r(f+t)}),t.exports=newrelic,newrelic.noticeError=function(e){"string"==typeof e&&(e=new Error(e)),o("err",[e,(new Date).getTime()])}},{}],2:[function(e,t,n){function r(e,t){var n=[],r="",i=0;for(r in e)o.call(e,r)&&(n[i]=t(r,e[r]),i+=1);return n}var o=Object.prototype.hasOwnProperty;t.exports=r},{}],3:[function(e,t,n){function r(e,t,n){t||(t=0),"undefined"==typeof n&&(n=e?e.length:0);for(var r=-1,o=n-t||0,i=Array(0>o?0:o);++r<o;)i[r]=e[t+r];return i}t.exports=r},{}],ee:[function(e,t,n){function r(){}function o(e){function t(e){return e&&e instanceof r?e:e?u(e,a,i):i()}function n(n,r,o){e&&e(n,r,o);for(var i=t(o),a=l(n),u=a.length,c=0;u>c;c++)a[c].apply(i,r);var s=f[g[n]];return s&&s.push([m,n,r,i]),i}function p(e,t){w[e]=l(e).concat(t)}function l(e){return w[e]||[]}function d(e){return s[e]=s[e]||o(n)}function v(e,t){c(e,function(e,n){t=t||"feature",g[n]=t,t in f||(f[t]=[])})}var w={},g={},m={on:p,emit:n,get:d,listeners:l,context:t,buffer:v};return m}function i(){return new r}var a="nr@context",u=e("gos"),c=e(2),f={},s={},p=t.exports=o();p.backlog=f},{}],gos:[function(e,t,n){function r(e,t,n){if(o.call(e,t))return e[t];var r=n();if(Object.defineProperty&&Object.keys)try{return Object.defineProperty(e,t,{value:r,writable:!0,enumerable:!1}),r}catch(i){}return e[t]=r,r}var o=Object.prototype.hasOwnProperty;t.exports=r},{}],handle:[function(e,t,n){function r(e,t,n,r){o.buffer([e],r),o.emit(e,t,n)}var o=e("ee").get("handle");t.exports=r,r.ee=o},{}],id:[function(e,t,n){function r(e){var t=typeof e;return!e||"object"!==t&&"function"!==t?-1:e===window?0:a(e,i,function(){return o++})}var o=1,i="nr@id",a=e("gos");t.exports=r},{}],loader:[function(e,t,n){function r(){if(!w++){var e=v.info=NREUM.info,t=s.getElementsByTagName("script")[0];if(e&&e.licenseKey&&e.applicationID&&t){c(l,function(t,n){e[t]||(e[t]=n)});var n="https"===p.split(":")[0]||e.sslForHttp;v.proto=n?"https://":"http://",u("mark",["onload",a()],null,"api");var r=s.createElement("script");r.src=v.proto+e.agent,t.parentNode.insertBefore(r,t)}}}function o(){"complete"===s.readyState&&i()}function i(){u("mark",["domContent",a()],null,"api")}function a(){return(new Date).getTime()}var u=e("handle"),c=e(2),f=window,s=f.document;NREUM.o={ST:setTimeout,CT:clearTimeout,XHR:f.XMLHttpRequest,REQ:f.Request,EV:f.Event,PR:f.Promise,MO:f.MutationObserver},e(1);var p=""+location,l={beacon:"bam.nr-data.net",errorBeacon:"bam.nr-data.net",agent:"js-agent.newrelic.com/nr-943.min.js"},d=window.XMLHttpRequest&&XMLHttpRequest.prototype&&XMLHttpRequest.prototype.addEventListener&&!/CriOS/.test(navigator.userAgent),v=t.exports={offset:a(),origin:p,features:{},xhrWrappable:d};s.addEventListener?(s.addEventListener("DOMContentLoaded",i,!1),f.addEventListener("load",r,!1)):(s.attachEvent("onreadystatechange",o),f.attachEvent("onload",r)),u("mark",["firstbyte",a()],null,"api");var w=0},{}]},{},["loader"]);</script>
|
||||
<meta name="keywords" content="docker, docker open source, docker platform, distributed applications, microservices, containers, docker containers, docker software, docker virtualization">
|
||||
<meta property="og:site_name" content="Docker">
|
||||
<meta property="og:type" content="website">
|
||||
<meta property="og:title" content="Docker Docs">
|
||||
<meta property="og:updated_time" content="2016-06-07T22:58:05-07:00">
|
||||
<meta property="og:updated_time" content="{% if page.date %}{{ page.date | date_to_xmlschema }}{% else %}{{ site.time | date_to_xmlschema }}{% endif %}">
|
||||
<meta property="og:image" content="https://www.docker.com/sites/default/files/social/docker-facebook-share.png">
|
||||
<meta name="twitter:card" content="summary_large_image">
|
||||
<meta name="twitter:site" content="@docker_docs">
|
||||
<meta name="twitter:url" content="https://twitter.com/docker_docs">
|
||||
<meta name="twitter:title" content="Docs team">
|
||||
<meta name="twitter:title" content="{{ page.title }}">
|
||||
<meta name="twitter:image:src" content="https://www.docker.com/sites/default/files/social/docker-twitter-share.png">
|
||||
<meta property="article:published_time" content="2016-05-30T01:18:23-07:00">
|
||||
<meta property="article:modified_time" content="2016-06-07T22:58:05-07:00">
|
||||
<meta property="article:published_time" content="{% if page.date %}{{ page.date | date_to_xmlschema }}{% else %}{{ site.time | date_to_xmlschema }}{% endif %}">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Docker Docs{% if page.title %}: {{ page.title }}{% endif %}</title>
|
||||
<meta name="description" content="">
|
||||
<meta name="keywords" content="">
|
||||
<meta name="keywords" content="{% if page.keywords %}{{ page.keywords }}{% else %}docker, docker open source, docker platform, distributed applications, microservices, containers, docker containers, docker software, docker virtualization{% endif %}">
|
||||
<link rel="apple-touch-icon" sizes="57x57" href="/favicons/apple-touch-icon-57x57.png">
|
||||
<link rel="apple-touch-icon" sizes="60x60" href="/favicons/apple-touch-icon-60x60.png">
|
||||
<link rel="apple-touch-icon" sizes="72x72" href="/favicons/apple-touch-icon-72x72.png">
|
||||
|
@ -81,6 +74,7 @@ ng\:form {
|
|||
<meta class="foundation-mq-topbar">
|
||||
<link id="mktoForms2BaseStyle" rel="stylesheet" type="text/css" href="/css/forms2.css">
|
||||
<link id="mktoForms2ThemeStyle" rel="stylesheet" type="text/css" href="/css/forms2-theme-simple.css">
|
||||
{% seo %}
|
||||
</head>
|
||||
<body class="html front not-logged-in no-sidebars page-node page-node- page-node-1 node-type-front-page path-docker ng-scope short retina-display all_loaded" ng-app="Docker" ng-controller="DockerController" style="">
|
||||
<div class="off-canvas-wrap" data-offcanvas="" style="min-height: 548px;">
|
||||
|
@ -191,13 +185,13 @@ ng\:form {
|
|||
</div>
|
||||
<div {% if page.notoc %} class="col-xs-12 col-sm-9 col-md-10" {% else %} class="col-xs-12 col-sm-9 col-md-8 col-xl-9" {% endif %} >
|
||||
<section class="section" id="DocumentationText">
|
||||
{{ content }}
|
||||
{{ content }}
|
||||
{% if page.noratings != true %}
|
||||
<div style="text-align: center; margin-top: 50px">
|
||||
<img src="/images/chat.png" alt="chat icon" style="margin-right: 10px">
|
||||
<b>Feedback?</b> Questions? Suggestions?<br/>
|
||||
<a href="https://github.com/docker/docker.github.io/edit/master/{{ page.path }}" class="nomunge">Edit this page</a>,
|
||||
<a href="https://github.com/docker/docker.github.io/issues/new?title=Feedback for: {{ page.path }}&body=URL: {{ page.path }}" class="nomunge">file a ticket</a>, or rate this page:
|
||||
<a href="https://github.com/docker/docker.github.io/issues/new?title=Feedback for: {{ page.path }}&body=URL: [https://docs.docker.com/{{ page.path }}](https://docs.docker.com{{ page.url }})" class="nomunge">file a ticket</a>, or rate this page:
|
||||
<div id="pd_rating_holder_8453675"></div>
|
||||
<script type="text/javascript">
|
||||
PDRTJS_settings_8453675 = {
|
||||
|
@ -214,10 +208,19 @@ ng\:form {
|
|||
|
||||
<script language="javascript">
|
||||
var x = document.links.length;
|
||||
var baseHref = document.getElementsByTagName('base')[0].href
|
||||
for (i = 0; i < x; i++) {
|
||||
var munged = false;
|
||||
var thisHREF = document.links[i].href;
|
||||
if (thisHREF.indexOf(window.location.hostname) > -1 && document.links[i].className.indexOf("nomunge")<0)
|
||||
var originalURL = "{{ page.url }}";
|
||||
if (thisHREF.indexOf(baseHref + "#") > -1)
|
||||
{
|
||||
// hash fix
|
||||
//console.log('BEFORE: base:',baseHref,'thisHREF:',thisHREF,'originalURL:',originalURL);
|
||||
thisHREF = originalURL + thisHREF.replace(baseHref,"");
|
||||
//console.log('AFTER: base:',baseHref,'thisHREF:',thisHREF,'originalURL:',originalURL);
|
||||
}
|
||||
if ((thisHREF.indexOf(window.location.hostname) > -1 || thisHREF.indexOf('http') == -1) && document.links[i].className.indexOf("nomunge")<0)
|
||||
{
|
||||
munged = true;
|
||||
thisHREF = thisHREF.replace(".md","/").replace("/index/","/");
|
||||
|
|
|
@ -54,8 +54,8 @@ Wrote bundle to vossibility-stack.dab
|
|||
> you need to install an experimental build of Docker Engine to use it.
|
||||
>
|
||||
> If you're on Mac or Windows, download the “Beta channel” version of
|
||||
> [Docker for Mac](https://docs.docker.com/docker-for-mac/) or
|
||||
> [Docker for Windows](https://docs.docker.com/docker-for-windows/) to install
|
||||
> [Docker for Mac](/docker-for-mac/) or
|
||||
> [Docker for Windows](/docker-for-windows/) to install
|
||||
> it. If you're on Linux, follow the instructions in the
|
||||
> [experimental build README](https://github.com/docker/docker/blob/master/experimental/README.md).
|
||||
|
||||
|
|
|
@ -70,8 +70,8 @@ This will result in an image named `webapp` and tagged `tag`, built from `./dir`
|
|||
> **Note**: In the [version 1 file format](compose-file.md#version-1), `build` is different in
|
||||
> two ways:
|
||||
>
|
||||
> - Only the string form (`build: .`) is allowed - not the object form.
|
||||
> - Using `build` together with `image` is not allowed. Attempting to do so
|
||||
> 1. Only the string form (`build: .`) is allowed - not the object form.
|
||||
> 2. Using `build` together with `image` is not allowed. Attempting to do so
|
||||
> results in an error.
|
||||
|
||||
#### context
|
||||
|
@ -103,13 +103,15 @@ specified.
|
|||
|
||||
> **Note**: In the [version 1 file format](compose-file.md#version-1), `dockerfile` is
|
||||
> different in two ways:
|
||||
|
||||
* It appears alongside `build`, not as a sub-option:
|
||||
|
||||
build: .
|
||||
dockerfile: Dockerfile-alternate
|
||||
|
||||
* Using `dockerfile` together with `image` is not allowed. Attempting to do so results in an error.
|
||||
>
|
||||
> 1. It appears alongside `build`, not as a sub-option:
|
||||
>
|
||||
> ```
|
||||
> build: .
|
||||
> dockerfile: Dockerfile-alternate
|
||||
> ```
|
||||
>
|
||||
> 2. Using `dockerfile` together with `image` is not allowed. Attempting to do so results in an error.
|
||||
|
||||
#### args
|
||||
|
||||
|
@ -478,7 +480,7 @@ Containers for the linked service will be reachable at a hostname identical to
|
|||
the alias, or the service name if no alias was specified.
|
||||
|
||||
Links also express dependency between services in the same way as
|
||||
[depends_on](compose-file.md#depends-on), so they determine the order of service startup.
|
||||
[depends_on](compose-file.md#dependson), so they determine the order of service startup.
|
||||
|
||||
> **Note:** If you define both links and [networks](compose-file.md#networks), services with
|
||||
> links between them must share at least one network in common in order to
|
||||
|
|
|
@ -146,7 +146,7 @@ In this section, you set up the database connection for Django.
|
|||
|
||||
DATABASES = {
|
||||
'default': {
|
||||
'ENGINE': 'django.db.backends.postgresql_psycopg2',
|
||||
'ENGINE': 'django.db.backends.postgresql',
|
||||
'NAME': 'postgres',
|
||||
'USER': 'postgres',
|
||||
'HOST': 'db',
|
||||
|
|
|
@ -68,21 +68,21 @@ dependencies the Python application requires, including Python itself.
|
|||
RUN pip install -r requirements.txt
|
||||
CMD python app.py
|
||||
|
||||
This tells Docker to:
|
||||
|
||||
* Build an image starting with the Python 2.7 image.
|
||||
* Add the current directory `.` into the path `/code` in the image.
|
||||
* Set the working directory to `/code`.
|
||||
* Install the Python dependencies.
|
||||
* Set the default command for the container to `python app.py`
|
||||
|
||||
For more information on how to write Dockerfiles, see the [Docker user guide](/engine/tutorials/dockerimages.md#building-an-image-from-a-dockerfile) and the [Dockerfile reference](/engine/reference/builder.md).
|
||||
This tells Docker to:
|
||||
|
||||
* Build an image starting with the Python 2.7 image.
|
||||
* Add the current directory `.` into the path `/code` in the image.
|
||||
* Set the working directory to `/code`.
|
||||
* Install the Python dependencies.
|
||||
* Set the default command for the container to `python app.py`
|
||||
<br>
|
||||
For more information on how to write Dockerfiles, see the [Docker user guide](/engine/tutorials/dockerimages.md#building-an-image-from-a-dockerfile) and the [Dockerfile reference](/engine/reference/builder.md).
|
||||
<br>
|
||||
2. Build the image.
|
||||
|
||||
$ docker build -t web .
|
||||
|
||||
This command builds an image named `web` from the contents of the current
|
||||
This command builds an image named `web` from the contents of the current
|
||||
directory. The command automatically locates the `Dockerfile`, `app.py`, and
|
||||
`requirements.txt` files.
|
||||
|
||||
|
@ -91,7 +91,7 @@ dependencies the Python application requires, including Python itself.
|
|||
|
||||
Define a set of services using `docker-compose.yml`:
|
||||
|
||||
1. Create a file called docker-compose.yml in your project directory and add
|
||||
Create a file called docker-compose.yml in your project directory and add
|
||||
the following:
|
||||
|
||||
|
||||
|
@ -157,27 +157,27 @@ If you want to run your services in the background, you can pass the `-d` flag
|
|||
(for "detached" mode) to `docker-compose up` and use `docker-compose ps` to
|
||||
see what is currently running:
|
||||
|
||||
$ docker-compose up -d
|
||||
Starting composetest_redis_1...
|
||||
Starting composetest_web_1...
|
||||
$ docker-compose ps
|
||||
Name Command State Ports
|
||||
-------------------------------------------------------------------
|
||||
composetest_redis_1 /usr/local/bin/run Up
|
||||
composetest_web_1 /bin/sh -c python app.py Up 5000->5000/tcp
|
||||
$ docker-compose up -d
|
||||
Starting composetest_redis_1...
|
||||
Starting composetest_web_1...
|
||||
$ docker-compose ps
|
||||
Name Command State Ports
|
||||
-------------------------------------------------------------------
|
||||
composetest_redis_1 /usr/local/bin/run Up
|
||||
composetest_web_1 /bin/sh -c python app.py Up 5000->5000/tcp
|
||||
|
||||
The `docker-compose run` command allows you to run one-off commands for your
|
||||
services. For example, to see what environment variables are available to the
|
||||
`web` service:
|
||||
|
||||
$ docker-compose run web env
|
||||
$ docker-compose run web env
|
||||
|
||||
See `docker-compose --help` to see other available commands. You can also install [command completion](completion.md) for the bash and zsh shell, which will also show you available commands.
|
||||
|
||||
If you started Compose with `docker-compose up -d`, you'll probably want to stop
|
||||
your services once you've finished with them:
|
||||
|
||||
$ docker-compose stop
|
||||
$ docker-compose stop
|
||||
|
||||
At this point, you have seen the basics of how Compose works.
|
||||
|
||||
|
|
|
@ -20,7 +20,7 @@ Compose is a tool for defining and running multi-container Docker applications.
|
|||
- [Get started with Rails](rails.md)
|
||||
- [Get started with WordPress](wordpress.md)
|
||||
- [Frequently asked questions](faq.md)
|
||||
- [Command line reference](./reference/index.md)
|
||||
- [Command-line reference](./reference/index.md)
|
||||
- [Compose file reference](compose-file.md)
|
||||
- [Environment file](env-file.md)
|
||||
|
||||
|
|
|
@ -11,13 +11,13 @@ title: Install Compose
|
|||
|
||||
# Install Docker Compose
|
||||
|
||||
You can run Compose on OS X, Windows and 64-bit Linux. To install it, you'll need to install Docker first.
|
||||
You can run Compose on macOS, Windows and 64-bit Linux. To install it, you'll need to install Docker first.
|
||||
|
||||
To install Compose, do the following:
|
||||
|
||||
1. Install Docker Engine:
|
||||
|
||||
* <a href="/engine/installation/mac/" target="_blank">Mac OS X installation</a>
|
||||
* <a href="/engine/installation/mac/" target="_blank">macOS installation</a>
|
||||
|
||||
* <a href="/engine/installation/windows/" target="_blank">Windows installation</a>
|
||||
|
||||
|
@ -38,7 +38,7 @@ which the release page specifies, in your terminal.
|
|||
|
||||
The following is an example command illustrating the format:
|
||||
|
||||
curl -L https://github.com/docker/compose/releases/download/1.8.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
|
||||
curl -L "https://github.com/docker/compose/releases/download/1.8.1/docker-compose-$(uname -s)-$(uname -m)" > /usr/local/bin/docker-compose
|
||||
|
||||
If you have problems installing with `curl`, see
|
||||
[Alternative Install Options](install.md#alternative-install-options).
|
||||
|
@ -53,7 +53,7 @@ which the release page specifies, in your terminal.
|
|||
7. Test the installation.
|
||||
|
||||
$ docker-compose --version
|
||||
docker-compose version: 1.8.0
|
||||
docker-compose version: 1.8.1
|
||||
|
||||
|
||||
## Alternative install options
|
||||
|
@ -76,13 +76,13 @@ to get started.
|
|||
Compose can also be run inside a container, from a small bash script wrapper.
|
||||
To install compose as a container run:
|
||||
|
||||
$ curl -L https://github.com/docker/compose/releases/download/1.8.0/run.sh > /usr/local/bin/docker-compose
|
||||
$ curl -L https://github.com/docker/compose/releases/download/1.8.1/run.sh > /usr/local/bin/docker-compose
|
||||
$ chmod +x /usr/local/bin/docker-compose
|
||||
|
||||
## Master builds
|
||||
|
||||
If you're interested in trying out a pre-release build you can download a
|
||||
binary from https://dl.bintray.com/docker-compose/master/. Pre-release
|
||||
binary from [https://dl.bintray.com/docker-compose/master/](https://dl.bintray.com/docker-compose/master/). Pre-release
|
||||
builds allow you to try out new features before they are released, but may
|
||||
be less stable.
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ title: Networking in Compose
|
|||
> **Note:** This document only applies if you're using [version 2 of the Compose file format](compose-file.md#versioning). Networking features are not supported for version 1 (legacy) Compose files.
|
||||
|
||||
By default Compose sets up a single
|
||||
[network](https://docs.docker.com/engine/reference/commandline/network_create/) for your app. Each
|
||||
[network](/engine/reference/commandline/network_create/) for your app. Each
|
||||
container for a service joins the default network and is both *reachable* by
|
||||
other containers on that network, and *discoverable* by them at a hostname
|
||||
identical to the container name.
|
||||
|
@ -77,11 +77,11 @@ See the [links reference](compose-file.md#links) for more information.
|
|||
|
||||
When [deploying a Compose application to a Swarm cluster](swarm.md), you can make use of the built-in `overlay` driver to enable multi-host communication between containers with no changes to your Compose file or application code.
|
||||
|
||||
Consult the [Getting started with multi-host networking](https://docs.docker.com/engine/userguide/networking/get-started-overlay/) to see how to set up a Swarm cluster. The cluster will use the `overlay` driver by default, but you can specify it explicitly if you prefer - see below for how to do this.
|
||||
Consult the [Getting started with multi-host networking](/engine/userguide/networking/get-started-overlay/) to see how to set up a Swarm cluster. The cluster will use the `overlay` driver by default, but you can specify it explicitly if you prefer - see below for how to do this.
|
||||
|
||||
## Specifying custom networks
|
||||
|
||||
Instead of just using the default app network, you can specify your own networks with the top-level `networks` key. This lets you create more complex topologies and specify [custom network drivers](https://docs.docker.com/engine/extend/plugins_network/) and options. You can also use it to connect services to externally-created networks which aren't managed by Compose.
|
||||
Instead of just using the default app network, you can specify your own networks with the top-level `networks` key. This lets you create more complex topologies and specify [custom network drivers](/engine/extend/plugins_network/) and options. You can also use it to connect services to externally-created networks which aren't managed by Compose.
|
||||
|
||||
Each service can specify what networks to connect to with the *service-level* `networks` key, which is a list of names referencing entries under the *top-level* `networks` key.
|
||||
|
||||
|
|
|
@ -184,4 +184,4 @@ individuals, we have a number of open channels for communication.
|
|||
|
||||
* To contribute code or documentation changes: please submit a [pull request on Github](https://github.com/docker/compose/pulls).
|
||||
|
||||
For more information and resources, please visit the [Getting Help project page](https://docs.docker.com/opensource/get-help/).
|
||||
For more information and resources, please visit the [Getting Help project page](/opensource/get-help/).
|
||||
|
|
|
@ -34,7 +34,7 @@ Specify the path to a Compose file. If not provided, Compose looks for a file na
|
|||
succession until a file by that name is found.
|
||||
|
||||
This variable supports multiple compose files separate by a path separator (on
|
||||
Linux and OSX the path separator is `:`, on Windows it is `;`). For example:
|
||||
Linux and macOS the path separator is `:`, on Windows it is `;`). For example:
|
||||
`COMPOSE_FILE=docker-compose.yml:docker-compose.prod.yml`
|
||||
|
||||
See also the `-f` [command-line option](overview.md).
|
||||
|
|
|
@ -77,7 +77,7 @@ add to their successors.
|
|||
For example, consider this command line:
|
||||
|
||||
```
|
||||
$ docker-compose -f docker-compose.yml -f docker-compose.admin.yml run backup_db`
|
||||
$ docker-compose -f docker-compose.yml -f docker-compose.admin.yml run backup_db
|
||||
```
|
||||
|
||||
The `docker-compose.yml` file might specify a `webapp` service.
|
||||
|
|
|
@ -11,7 +11,7 @@ title: ps
|
|||
|
||||
# ps
|
||||
|
||||
```
|
||||
```none
|
||||
Usage: ps [options] [SERVICE...]
|
||||
|
||||
Options:
|
||||
|
@ -19,3 +19,11 @@ Options:
|
|||
```
|
||||
|
||||
Lists containers.
|
||||
|
||||
```bash
|
||||
$ docker-compose ps
|
||||
Name Command State Ports
|
||||
--------------------------------------------------------------------------------------------
|
||||
mywordpress_db_1 docker-entrypoint.sh mysqld Up 3306/tcp
|
||||
mywordpress_wordpress_1 /entrypoint.sh apache2-for ... Restarting 0.0.0.0:8000->80/tcp
|
||||
```
|
||||
|
|
|
@ -53,9 +53,11 @@ script:
|
|||
db:
|
||||
image: postgres
|
||||
|
||||
- Write your own wrapper script to perform a more application-specific health
|
||||
- Alternatively, write your own wrapper script to perform a more application-specific health
|
||||
check. For example, you might want to wait until Postgres is definitely
|
||||
ready to accept commands:
|
||||
|
||||
wait-for-postgres.sh
|
||||
|
||||
#!/bin/bash
|
||||
|
||||
|
|
|
@ -25,10 +25,10 @@ format](compose-file.md#versioning) you are using:
|
|||
|
||||
- subject to the [limitations](swarm.md#limitations) described below,
|
||||
|
||||
- as long as the Swarm cluster is configured to use the [overlay driver](https://docs.docker.com/engine/userguide/networking/dockernetworks/#an-overlay-network),
|
||||
- as long as the Swarm cluster is configured to use the [overlay driver](/engine/userguide/networking/dockernetworks/#an-overlay-network),
|
||||
or a custom driver which supports multi-host networking.
|
||||
|
||||
Read [Get started with multi-host networking](https://docs.docker.com/engine/userguide/networking/get-started-overlay/) to see how to
|
||||
Read [Get started with multi-host networking](/engine/userguide/networking/get-started-overlay/) to see how to
|
||||
set up a Swarm cluster with [Docker Machine](/machine/overview.md) and the overlay driver. Once you've got it running, deploying your app to it should be as simple as:
|
||||
|
||||
$ eval "$(docker-machine env --swarm <name of swarm master machine>)"
|
||||
|
@ -89,15 +89,15 @@ all three services end up on the same node:
|
|||
image: foo
|
||||
volumes_from: ["bar"]
|
||||
network_mode: "service:baz"
|
||||
environment:
|
||||
labels:
|
||||
- "constraint:node==node-1"
|
||||
bar:
|
||||
image: bar
|
||||
environment:
|
||||
labels:
|
||||
- "constraint:node==node-1"
|
||||
baz:
|
||||
image: baz
|
||||
environment:
|
||||
labels:
|
||||
- "constraint:node==node-1"
|
||||
|
||||
### Host ports and recreating containers
|
||||
|
@ -165,15 +165,15 @@ environment variables, so you can use Compose's `environment` option to set
|
|||
them.
|
||||
|
||||
# Schedule containers on a specific node
|
||||
environment:
|
||||
labels:
|
||||
- "constraint:node==node-1"
|
||||
|
||||
# Schedule containers on a node that has the 'storage' label set to 'ssd'
|
||||
environment:
|
||||
labels:
|
||||
- "constraint:storage==ssd"
|
||||
|
||||
# Schedule containers where the 'redis' image is already pulled
|
||||
environment:
|
||||
labels:
|
||||
- "affinity:image==redis"
|
||||
|
||||
For the full set of available filters and expressions, see the [Swarm
|
||||
|
|
|
@ -27,35 +27,40 @@ with Docker containers. This quick-start guide demonstrates how to use Compose t
|
|||
|
||||
For example, if you named your directory `my_wordpress`:
|
||||
|
||||
$ cd my-wordpress/
|
||||
$ cd my_wordpress/
|
||||
|
||||
3. Create a `docker-compose.yml` file that will start your `Wordpress` blog and a separate `MySQL` instance with a volume mount for data persistence:
|
||||
3. Create a `docker-compose.yml` file that will start your
|
||||
`Wordpress` blog and a separate `MySQL` instance with a volume
|
||||
mount for data persistence:
|
||||
|
||||
version: '2'
|
||||
services:
|
||||
db:
|
||||
image: mysql:5.7
|
||||
volumes:
|
||||
- "./.data/db:/var/lib/mysql"
|
||||
restart: always
|
||||
environment:
|
||||
MYSQL_ROOT_PASSWORD: wordpress
|
||||
MYSQL_DATABASE: wordpress
|
||||
MYSQL_USER: wordpress
|
||||
MYSQL_PASSWORD: wordpress
|
||||
```none
|
||||
version: '2'
|
||||
|
||||
wordpress:
|
||||
depends_on:
|
||||
- db
|
||||
image: wordpress:latest
|
||||
links:
|
||||
- db
|
||||
ports:
|
||||
- "8000:80"
|
||||
restart: always
|
||||
environment:
|
||||
WORDPRESS_DB_HOST: db:3306
|
||||
WORDPRESS_DB_PASSWORD: wordpress
|
||||
services:
|
||||
db:
|
||||
image: mysql:5.7
|
||||
volumes:
|
||||
- "./.data/db:/var/lib/mysql"
|
||||
restart: always
|
||||
environment:
|
||||
MYSQL_ROOT_PASSWORD: wordpress
|
||||
MYSQL_DATABASE: wordpress
|
||||
MYSQL_USER: wordpress
|
||||
MYSQL_PASSWORD: wordpress
|
||||
|
||||
wordpress:
|
||||
depends_on:
|
||||
- db
|
||||
image: wordpress:latest
|
||||
links:
|
||||
- db
|
||||
ports:
|
||||
- "8000:80"
|
||||
restart: always
|
||||
environment:
|
||||
WORDPRESS_DB_HOST: db:3306
|
||||
WORDPRESS_DB_PASSWORD: wordpress
|
||||
```
|
||||
|
||||
**NOTE**: The folder `./.data/db` will be automatically created in the project directory
|
||||
alongside the `docker-compose.yml` which will persist any updates made by wordpress to the
|
||||
|
@ -89,7 +94,7 @@ This pulls the needed images, and starts the wordpress and database containers,
|
|||
|
||||
### Bring up WordPress in a web browser
|
||||
|
||||
If you're using [Docker Machine](https://docs.docker.com/machine/), then `docker-machine ip MACHINE_VM` gives you the machine address and you can open `http://MACHINE_VM_IP:8000` in a browser.
|
||||
If you're using [Docker Machine](/machine/), then `docker-machine ip MACHINE_VM` gives you the machine address and you can open `http://MACHINE_VM_IP:8000` in a browser.
|
||||
|
||||
At this point, WordPress should be running on port `8000` of your Docker Host, and you can complete the "famous five-minute installation" as a WordPress administrator.
|
||||
|
||||
|
|
|
@ -340,5 +340,5 @@ Because this addition is preventative, no CVE-ID is requested.
|
|||
## CS Engine 1.6.0-cs2
|
||||
(23 Apr 2015)
|
||||
|
||||
First release, see the [Docker Engine 1.6.0 Release notes](https://docs.docker.com/v1.6/release-notes/)
|
||||
First release, see the [Docker Engine 1.6.0 Release notes](/v1.6/release-notes/)
|
||||
for more details.
|
||||
|
|
|
@ -30,14 +30,28 @@ cannot be adopted as quickly for consistency and compatibility reasons.
|
|||
These notes refer to the current and immediately prior releases of the
|
||||
CS Engine. For notes on older versions, see the [CS Engine prior release notes archive](prior-release-notes.md).
|
||||
|
||||
## CS Engine 1.12.3-cs3
|
||||
(27 Oct 2016)
|
||||
|
||||
Refer to the [detailed list](https://github.com/docker/docker/releases) of all
|
||||
changes since the release of CS Engine 1.12.2-cs2.
|
||||
|
||||
## CS Engine 1.12.2-cs2
|
||||
(13 Oct 2016)
|
||||
|
||||
Refer to the [detailed list](https://github.com/docker/docker/releases) of all
|
||||
changes since the release of CS Engine 1.12.1-cs1.
|
||||
|
||||
## CS Engine 1.12.1-cs1
|
||||
(20 Sep 2016)
|
||||
|
||||
Refer to the [detailed list](https://github.com/docker/docker/releases) of all changes since the release of CS Engine 1.11.2-cs5
|
||||
Refer to the [detailed list](https://github.com/docker/docker/releases) of all
|
||||
changes since the release of CS Engine 1.11.2-cs5
|
||||
|
||||
This release addresses the following issues:
|
||||
|
||||
* [#25962](https://github.com/docker/docker/pull/25962) Allow normal containers to connect to swarm-mode overlay network
|
||||
* [#25962](https://github.com/docker/docker/pull/25962) Allow normal containers
|
||||
to connect to swarm-mode overlay network
|
||||
* Various bug fixes in swarm mode networking
|
||||
|
||||
## CS Engine 1.11.2-cs5
|
||||
|
@ -99,4 +113,3 @@ https://github.com/docker/docker/issues/22486
|
|||
(27 April 2016)
|
||||
|
||||
In this release the CS Engine is supported on RHEL 7.2 OS
|
||||
|
||||
|
|
|
@ -16,10 +16,15 @@
|
|||
font-size: 16px;
|
||||
border-left: 4px solid #6db9d1;
|
||||
padding: 6px;
|
||||
background-color: #f5f5f5;
|
||||
background-color: #fafafa;
|
||||
color: black !important;
|
||||
}
|
||||
#DocumentationText blockquote li div.highlighter-rouge {
|
||||
padding-left: 20px;
|
||||
padding-right: 20px;
|
||||
}
|
||||
#DocumentationText blockquote p {
|
||||
color: black;
|
||||
color: black !important;
|
||||
margin: 0;
|
||||
padding: 10px 20px;
|
||||
}
|
||||
|
@ -27,6 +32,9 @@
|
|||
color: #6db9d1;
|
||||
/* most Note's have a non-strong ':' display: block;*/
|
||||
}
|
||||
#DocumentationText blockquote ol, #DocumentationText blockquote ul {
|
||||
padding-left: 20px !important;
|
||||
}
|
||||
#DocumentationText code {
|
||||
border-width: 0px !important;
|
||||
background-color: #f5f5f5 !important;
|
||||
|
@ -328,7 +336,7 @@ color: #F04124;
|
|||
border: 0;
|
||||
text-indent: -9999px;
|
||||
background-color: transparent;
|
||||
background-image: url("https://blog.docker.com/wp-content/themes/whale_roots/assets/img/search-icon.png");
|
||||
background-image: url("/images/search-icon.png");
|
||||
/* background-size: 38px 38px; */
|
||||
background-repeat: no-repeat;
|
||||
background-position: center center;
|
||||
|
|
|
@ -1,14 +0,0 @@
|
|||
---
|
||||
description: Manage Applications in Docker Cloud
|
||||
keywords:
|
||||
- applications, images, Cloud
|
||||
menu:
|
||||
main:
|
||||
identifier: apps
|
||||
parent: docker-cloud
|
||||
type: menu
|
||||
weight: -80
|
||||
title: Manage Applications
|
||||
---
|
||||
|
||||
If you can see this page, please file a bug by emailing docs@docker.com
|
|
@ -12,7 +12,7 @@ title: Publish and expose service or container ports
|
|||
|
||||
# Publish and expose service or container ports
|
||||
|
||||
In Docker Cloud you can **publish** or **expose** ports in services and containers, just like you can in Docker Engine (as documented [here](https://docs.docker.com/reference/run/#expose-incoming-ports) ).
|
||||
In Docker Cloud you can **publish** or **expose** ports in services and containers, just like you can in Docker Engine (as documented [here](/reference/run/#expose-incoming-ports) ).
|
||||
|
||||
* **Exposed ports** are ports that a container or service is using either to
|
||||
provide a service, or listen on. By default, exposed ports in Docker Cloud are
|
||||
|
|
|
@ -17,7 +17,7 @@ Docker Cloud creates a per-user overlay network which connects all containers ac
|
|||
Docker Cloud gives your containers two ways find other services:
|
||||
|
||||
* Using service and container names directly as **hostnames**
|
||||
* Using **service links**, which are based on [Docker Compose links](https://docs.docker.com/compose/compose-file/#links)
|
||||
* Using **service links**, which are based on [Docker Compose links](/compose/compose-file/#links)
|
||||
|
||||
**Service and Container Hostnames** update automatically when a service scales up or down or redeploys. As a user, you can configure service names, and Docker Cloud uses these names to find the IP of the services and containers for you. You can use hostnames in your code to provide abstraction that allows you to easily swap service containers or components.
|
||||
|
||||
|
@ -55,7 +55,7 @@ If the container making the query is part of a stack, and there is a local match
|
|||
|
||||
## Using service links for service discovery
|
||||
|
||||
Docker Cloud's service linking is modeled on [Docker Compose links](https://docs.docker.com/compose/compose-file/#links) to provide a basic service discovery functionality using directional links recorded in environment variables.
|
||||
Docker Cloud's service linking is modeled on [Docker Compose links](/compose/compose-file/#links) to provide a basic service discovery functionality using directional links recorded in environment variables.
|
||||
|
||||
When you link a "client" service to a "server" service, Docker Cloud performs the following actions on the "client" service:
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ redeployment, or shared with other services.
|
|||
## Add a data volume to a service
|
||||
|
||||
Data volumes can be either specified in the image's `Dockerfile` using the
|
||||
[VOLUME instruction](https://docs.docker.com/reference/builder/#volume), or when
|
||||
[VOLUME instruction](/reference/builder/#volume), or when
|
||||
creating a service.
|
||||
|
||||
To define a data volume in a service, specify the **container path** where it
|
||||
|
@ -60,16 +60,16 @@ You might find it helpful to download or back up the data from volumes that are
|
|||
|
||||
1. Run an SSH service that mounts the volumes of the service you want to back up.
|
||||
|
||||
In the example snippet below, replace `mysql` with the actual service name.
|
||||
In the example snippet below, replace `mysql` with the actual service name.
|
||||
|
||||
```
|
||||
$ docker-cloud service run -n downloader -p 22:2222 -e AUTHORIZED_KEYS="$(cat ~/.ssh/id_rsa.pub)" --volumes-from mysql tutum/ubuntu
|
||||
```
|
||||
```
|
||||
$ docker-cloud service run -n downloader -p 22:2222 -e AUTHORIZED_KEYS="$(cat ~/.ssh/id_rsa.pub)" --volumes-from mysql tutum/ubuntu
|
||||
```
|
||||
|
||||
2. Run a `scp` (secure-copy) to download the files to your local machine.
|
||||
|
||||
In the example snippet below, replace `downloader-1.uuid.cont.dockerapp.io` with the container's Fully Qualified Domain Name (FQDN), and replace `/var/lib/mysql` with the path within the container from which you want to download the data. The data will be downloaded to the current local folder.
|
||||
In the example snippet below, replace `downloader-1.uuid.cont.dockerapp.io` with the container's Fully Qualified Domain Name (FQDN), and replace `/var/lib/mysql` with the path within the container from which you want to download the data. The data will be downloaded to the current local folder.
|
||||
|
||||
```
|
||||
$ scp -r -P 2222 root@downloader-1.uuid.cont.dockerapp.io:/var/lib/mysql .
|
||||
```
|
||||
```
|
||||
$ scp -r -P 2222 root@downloader-1.uuid.cont.dockerapp.io:/var/lib/mysql .
|
||||
```
|
||||
|
|
|
@ -29,9 +29,9 @@ processes and do not affect your service's run environment.
|
|||
* `DOCKER_TAG`: the Docker repository tag being built.
|
||||
* `IMAGE_NAME`: the name and tag of the Docker repository being built. (This variable is a combination of `DOCKER_REPO`/`DOCKER_TAG`.)
|
||||
|
||||
If you are using these environment variables in a `docker-compose.test.yml` file
|
||||
for automated testing, declare them in your `sut` service's environment as shows
|
||||
below.
|
||||
If you are using these build environment variables in a
|
||||
`docker-compose.test.yml` file for automated testing, declare them in your `sut`
|
||||
service's environment as shown below.
|
||||
|
||||
```yml
|
||||
sut:
|
||||
|
@ -41,6 +41,22 @@ sut:
|
|||
- SOURCE_BRANCH
|
||||
```
|
||||
|
||||
## Override build, test or push commands
|
||||
|
||||
Docker Cloud allows you to override and customize the `build`, `test` and `push`
|
||||
commands during automated build and test processes using hooks. For example, you
|
||||
might use a build hook to set build arguments used only during the build
|
||||
process. (You can also set up [custom build phase hooks](#custom-build-phase-hooks) to perform actions in between these commands.)
|
||||
|
||||
**Use these hooks with caution.** The contents of these hook files replace the
|
||||
basic `docker` commands, so you must include a similar build, test or push
|
||||
command in the hook or your automated process will not complete.
|
||||
|
||||
To override these phases, create a folder called `hooks` in your source code
|
||||
repository at the same directory level as your Dockerfile. Create a file called
|
||||
`hooks/build`, `hooks/test`, or `hooks/push` and include commands that the
|
||||
builder process can execute, such as `docker` and `bash` commands (prefixed appropriately with `#!/bin/bash`).
|
||||
|
||||
## Custom build phase hooks
|
||||
|
||||
You can run custom commands between phases of the build process by creating
|
||||
|
@ -49,7 +65,7 @@ autotest processes.
|
|||
|
||||
Create a folder called `hooks` in your source code repository at the same
|
||||
directory level as your Dockerfile. Place files that define the hooks in that
|
||||
folder. The builder executes them before and after each step.
|
||||
folder. Hook files can include both `docker` commands, and `bash` commands as long as they are prefixed appropriately with `#!/bin/bash`. The builder executes the commands in the files before and after each step.
|
||||
|
||||
The following hooks are available:
|
||||
|
||||
|
@ -61,13 +77,44 @@ The following hooks are available:
|
|||
* `hooks/pre_push` (only used when executing a build rule or [automated build](automated-build.md) )
|
||||
* `hooks/post_push` (only used when executing a build rule or [automated build](automated-build.md) )
|
||||
|
||||
### Build hook examples
|
||||
|
||||
## Override build, test or push commands
|
||||
#### Override the "build" phase to set variables
|
||||
|
||||
In addition to the custom build phase hooks above, you can also use
|
||||
`hooks/build`, `hooks/test`, and `hooks/push` to override and customize the
|
||||
`build`, `test` and `push` commands during automated build and test processes.
|
||||
Docker Cloud allows you to define build environment variables either in the hook files, or from the automated build UI (which you can then reference in hooks).
|
||||
|
||||
**Use these hooks with caution.** The contents of these hook files replace the
|
||||
basic `docker` commands, so you must include a similar build, test or push
|
||||
command in the hook or your automated process will not complete.
|
||||
In the following example, we define a build hook that uses `docker build` arguments to set the variable `CUSTOM` based on the value of variable we defined using the Docker Cloud build settings. `$IMAGE_NAME` is a variable that we provide with the name of the image being built.
|
||||
|
||||
```none
|
||||
docker build --build-arg CUSTOM=$VAR -t $IMAGE_NAME
|
||||
```
|
||||
|
||||
> **Caution**: A `hooks/build` file overrides the basic `docker build` command
|
||||
used by the builder, so you must include a similar build command in the hook or
|
||||
the automated build will fail.
|
||||
|
||||
To learn more about Docker build-time variables, see the [docker build documentation]( https://docs.docker.com/engine/reference/commandline/build/#/set-build-time-variables---build-arg).
|
||||
|
||||
#### Two-phase build
|
||||
|
||||
If your build process requires a component that is not a dependency for your application, you can use a `pre-build` hook to collect and compile required components. In the example below, the hook uses a Docker container to compile a Golang binary required before the build.
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
echo "=> Building the binary"
|
||||
docker run --privileged \
|
||||
-v $(pwd):/src \
|
||||
-v /var/run/docker.sock:/var/run/docker.sock \
|
||||
centurylink/golang-builder
|
||||
```
|
||||
|
||||
#### Push to multiple tags
|
||||
|
||||
By default the build process tags the resulting Docker image with a single tag and pushes the image only to the repository where the build settings are configured.
|
||||
|
||||
If you needed to give the resulting image multiple tags, or push the same image to multiple repositories, you could set up a `post_push` hook to add additional tags and push to more repositories.
|
||||
|
||||
```none
|
||||
docker tag $IMAGE_NAME $DOCKER_REPO:$SOURCE_COMMIT
|
||||
docker push $DOCKER_REPO:$SOURCE_COMMIT
|
||||
```
|
||||
|
|
|
@ -47,40 +47,34 @@ Before you set up automated builds you need to [create a repository](repos.md) t
|
|||
|
||||
2. Click the **Builds** tab.
|
||||
|
||||
3. The first time you configure automated builds for a repository, you'll see
|
||||
buttons that allow you to link to a hosted source code repository. Select the
|
||||
repository service where the image's source code is stored.
|
||||
3. If you are setting up automated builds for the first time, select
|
||||
the code repository service where the image's source code is stored.
|
||||
|
||||
(If you haven't yet linked a source provider, follow the instructions
|
||||
[here](link-source.md) to link your account.)
|
||||
|
||||
If you are editing an existing the build settings for an existing automated
|
||||
Otherwise, if you are editing the build settings for an existing automated
|
||||
build, click **Configure automated builds**.
|
||||
|
||||
4. If necessary, select the **source repository** to build the repository from.
|
||||
|
||||
5. Select the **source repository** to build the Docker images from.
|
||||
4. Select the **source repository** to build the Docker images from.
|
||||
|
||||
You might need to specify an organization or user from the source code
|
||||
provider to find the code repository you want to build.
|
||||
|
||||
6. Choose where to run your build processes.
|
||||
5. Choose where to run your build processes.
|
||||
|
||||
You can either run the process on your own infrastructure and optionally
|
||||
[set up specific nodes to build on](automated-build.md#set-up-builder-nodes), or use the
|
||||
[set up specific nodes to build on](automated-build.md#set-up-builder-nodes), or you can use the
|
||||
hosted build service offered on Docker Cloud's infrastructure. If you use
|
||||
Docker's infrastructure, select a builder size to run the build process on.
|
||||
This hosted build service is free while it is in Beta.
|
||||
|
||||

|
||||
|
||||
7. Optionally, enable [autotests](automated-testing.md#enable-automated-tests-on-a-repository).
|
||||
6. Optionally, enable [autotests](automated-testing.md#enable-automated-tests-on-a-repository).
|
||||
|
||||
8. In the **Tag mappings** section, enter one or more tags to build.
|
||||
8. In the **Build Rules** section, enter one or more sources to build.
|
||||
|
||||
For each tag:
|
||||
For each source:
|
||||
|
||||
* Select the **Source type** to build: either a **tag** or a
|
||||
* Select the **Source type** to build either a **tag** or a
|
||||
**branch**. This tells the build system what to look for in the source code
|
||||
repository.
|
||||
|
||||
|
@ -90,13 +84,14 @@ repository service where the image's source code is stored.
|
|||
names to build. To learn more, see
|
||||
[regexes](automated-build.md#regexes-and-automated-builds).
|
||||
|
||||
* Specify the **Dockerfile location** as a path relative to the root of the source code repository. (If the Dockerfile is at the repository root, leave this path set to `/`.)
|
||||
|
||||
* Enter the tag to apply to Docker images built from this source.
|
||||
|
||||
If you configured a regex to select the source, you can reference the
|
||||
capture groups and use its result as part of the tag. To learn more, see
|
||||
[regexes](automated-build.md#regexes-and-automated-builds).
|
||||
|
||||
* Specify the **Dockerfile location** as a path relative to the root of the source code repository. (If the Dockerfile is at the repository root, leave this path set to `/`.)
|
||||
|
||||
9. For each branch or tag, enable or disable the **Autobuild** toggle.
|
||||
|
||||
Only branches or tags with autobuild enabled are built, tested, *and* have
|
||||
|
@ -110,6 +105,24 @@ run an initial test.
|
|||
Docker Cloud on every push. Only pushes to branches that are listed as the
|
||||
source for one or more tags will trigger a build.
|
||||
|
||||
### Environment variables for builds
|
||||
|
||||
You can set the values for environment variables used in your build processes
|
||||
when you configure an automated build. Add your build environment variables by
|
||||
clicking the plus sign next to the **Build environment variables** section, and
|
||||
then entering a variable name and the value.
|
||||
|
||||
When you set variable values from the Docker Cloud UI, they can be used by the
|
||||
commands you set in `hooks` files, but they are stored so that only users who
|
||||
have `admin` access to the Docker Cloud repository can see their values. This
|
||||
means you can use them to safely store access tokens or other information that
|
||||
should remain secret.
|
||||
|
||||
> **Note**: The variables set on the build configuration screen are used during
|
||||
the build processes _only_ and should not be confused with the environment
|
||||
values used by your service (for example to create service links).
|
||||
|
||||
|
||||
## Check your active builds
|
||||
|
||||
1. To view active builds, go to the repository view and click **Timeline**.
|
||||
|
@ -137,10 +150,10 @@ To disable an automated build:
|
|||
|
||||
2. Click **Configure automated builds** to edit the repository's build settings.
|
||||
|
||||
3. In the **Tag mappings** section, locate the branch or tag you no longer want
|
||||
3. In the **Build Rules** section, locate the branch or tag you no longer want
|
||||
to automatically build.
|
||||
|
||||
4. Click the **autobuild** toggle next to the branch configuration line.
|
||||
4. Click the **autobuild** toggle next to the configuration line.
|
||||
|
||||
The toggle turns gray when disabled.
|
||||
|
||||
|
@ -156,7 +169,7 @@ You can use the variable `{sourceref}` to use the branch or tag name that
|
|||
matched the regex. (The variable includes the whole source name, not just the
|
||||
portion that matched the regex.) You can also use up to nine regular expression
|
||||
capture groups (expressions enclosed in parentheses) to select a source to
|
||||
build, and reference these in the Docker Tag field using `{/1}` through `{/9}`.
|
||||
build, and reference these in the Docker Tag field using `{\1}` through `{\9}`.
|
||||
|
||||
**Regex example: build from version number branch and tag with version number**
|
||||
|
||||
|
@ -193,7 +206,7 @@ To work around this, you can set up your automated build using the `SSH_PRIVATE`
|
|||
This step is optional, but allows you to revoke the build-only keypair without removing other access. <!-- (TODO: Link to instructions for GH & BB ) -->
|
||||
2. Copy the private half of the keypair to your clipboard.
|
||||
3. In Docker Cloud, navigate to the build page for the repository that has linked private submodules. (If necessary, follow the steps [here](automated-build.md#configure-automated-build-settings) to configure the automated build.)
|
||||
4. At the bottom of the screen, click the plus sign ( **+** ) next to **Environment Variables**.
|
||||
4. At the bottom of the screen, click the plus sign ( **+** ) next to **Build Environment variables**.
|
||||
5. Enter `SSH_PRIVATE` as the name for the new environment variable.
|
||||
6. Paste the private half of the keypair into the **Value** field.
|
||||
7. Click **Save**, or **Save and Build** to validate that the build now completes.
|
||||
|
|
|
@ -73,15 +73,15 @@ Docker repository, regardless of the Autotest settings.
|
|||
|
||||
* The source code repository
|
||||
* the build location
|
||||
* at least one tag mapping
|
||||
* at least one build rule
|
||||
|
||||
8. Choose your **Autotest** option.
|
||||
|
||||
The following options are available:
|
||||
|
||||
* `Off`: no additional tests. Test commits only to branches that are using Autobuild to build and push images.
|
||||
* `Source Repository`: test commits to all branches of the source code repository, regardless of their Autobuild setting.
|
||||
* `Source Repository & External Pull Requests`: tests commits to all branches of the source code repository, including any pull requests opened against it.
|
||||
* `Off`: No additional test builds. Tests only run if they're configured as part of an automated build.
|
||||
* `Source repository`: Run a test build for any pull requests to branches that match a build rule, but only when the pull request comes from the same source repository.
|
||||
* `Source repository & external pull requests`: Run a test build for any pull requests to branches that match a build rule, including when the pull request originated in an external source repository.
|
||||
|
||||
> **Note**: For security purposes, autotest on _external pull requests_ is
|
||||
disabled on public repositories. If you select this option on a public
|
||||
|
|
|
@ -188,4 +188,4 @@ components.
|
|||
## Related information
|
||||
|
||||
* [Learn about CVE and how it compiles data](https://cve.mitre.org/about/index.html).
|
||||
* [How to create a Docker Official image](https://docs.docker.com/docker-hub/official_repos/)
|
||||
* [How to create a Docker Official image](/docker-hub/official_repos/)
|
||||
|
|
|
@ -1,7 +1,6 @@
|
|||
---
|
||||
aliases: /docker-cloud/tutorials/link-source/
|
||||
description:
|
||||
- Link to your source code repository
|
||||
description: Link to your source code repository
|
||||
keywords:
|
||||
- sourcecode, github, bitbucket, Cloud
|
||||
menu:
|
||||
|
|
|
@ -1,14 +0,0 @@
|
|||
---
|
||||
description: Manage Builds and Images in Docker Cloud
|
||||
keywords:
|
||||
- builds, images, Cloud
|
||||
menu:
|
||||
main:
|
||||
identifier: builds
|
||||
parent: docker-cloud
|
||||
type: menu
|
||||
weight: -80
|
||||
title: Manage Builds and Images
|
||||
---
|
||||
|
||||
If you can see this page, please file a bug by emailing docs@docker.com
|
|
@ -30,10 +30,22 @@ account.
|
|||
You can also link to source code repositories such as GitHub and
|
||||
Bitbucket from your Docker Cloud account settings.
|
||||
|
||||
<!-- TODO:
|
||||
## API keys
|
||||
API keys are used for what?
|
||||
-->
|
||||
## Email addresses
|
||||
|
||||
You can associate multiple email addresses with your Docker ID, and one of these addresses becomes the primary address for the account. The primary address is used by Docker to send password reset notifications and other important information, so be sure to keep it updated.
|
||||
|
||||
To add another email address to your Docker ID:
|
||||
|
||||
1. In Docker Cloud, click the user icon menu at top right, and click **Account Settings**.
|
||||
2. In the **Emails** section, enter a new email address for the account.
|
||||
3. Click the **plus sign** icon (**+**) to add the address and send a verification email.
|
||||
|
||||
The new email address is not added to the account until you confirm it by
|
||||
clicking the link in the verification email. This link is only good for a
|
||||
limited time. To send a new verification email, click the envelope icon next to
|
||||
the email address that you want to verify.
|
||||
|
||||
If you have multiple verified email addresses associated with the account, you can click **Set as primary** to change the primary email address.
|
||||
|
||||
## Notifications
|
||||
|
||||
|
|
|
@ -139,6 +139,6 @@ Docker Cloud, deploy an app to your Cloud nodes, set environment variables,
|
|||
scale the service, view logs, set up a load balancer and a data back end, and
|
||||
set up a volume to save the data.
|
||||
|
||||
There's lots more to learn about Docker Cloud, so check out [the rest of our documentation](https://docs.docker.com/docker-cloud/), the [API and CLI Documentation](../../../apidocs/docker-cloud.md), and our [Knowledge Hub](https://success.docker.com/Cloud) and [Docker Cloud Forums](https://forums.docker.com/c/docker-cloud).
|
||||
There's lots more to learn about Docker Cloud, so check out [the rest of our documentation](/docker-cloud/), the [API and CLI Documentation](../../../apidocs/docker-cloud.md), and our [Knowledge Hub](https://success.docker.com/Cloud) and [Docker Cloud Forums](https://forums.docker.com/c/docker-cloud).
|
||||
|
||||
Happy Docking!
|
||||
|
|
|
@ -14,7 +14,7 @@ title: Introduction to Deploying an app in Docker Cloud
|
|||
|
||||
# Introduction and tutorial prerequisites
|
||||
|
||||
In this tutorial you will an application to Docker Cloud using either Go or
|
||||
In this tutorial you will bring an application to Docker Cloud using either Go or
|
||||
Python. This tutorial is intended for more advanced beginners who have some
|
||||
experience with web applications, and who want to learn more about
|
||||
multi-container services in Docker Cloud.
|
||||
|
@ -23,7 +23,7 @@ This tutorial assumes that you have:
|
|||
|
||||
- a free <a href="https://hub.docker.com/" target="_blank">Docker ID account</a>.
|
||||
- at least one node running. If you don't have any nodes set up in Docker Cloud yet, [start here](../../getting-started/your_first_node.md) to set these up.
|
||||
- (optional) Docker Engine installed - see the installation guides for <a href="https://docs.docker.com/installation/#installation" target="_blank">OS X, Windows and Linux</a>.
|
||||
- (optional) Docker Engine installed - see the installation guides for <a href="https://docs.docker.com/installation/#installation" target="_blank">macOS, Windows and Linux</a>.
|
||||
|
||||
Let's get started!
|
||||
|
||||
|
|
|
@ -38,9 +38,9 @@ Open your shell or terminal application and execute the following command:
|
|||
$ pip install docker-cloud
|
||||
```
|
||||
|
||||
#### Install on Mac OS X
|
||||
#### Install on macOS
|
||||
|
||||
We recommend installing Docker CLI for OS X using Homebrew. If you don't have `brew` installed, follow the instructions here: <a href="http://brew.sh" target="_blank">http://brew.sh</a>
|
||||
We recommend installing Docker CLI for macOS using Homebrew. If you don't have `brew` installed, follow the instructions here: <a href="http://brew.sh" target="_blank">http://brew.sh</a>
|
||||
|
||||
Once Homebrew is installed, open Terminal and run the following command:
|
||||
|
||||
|
@ -66,7 +66,7 @@ The documentation for the Docker Cloud CLI tool and API [here](/apidocs/docker-c
|
|||
Use the `login` CLI command to log in to Docker Cloud. Use the username and password you used when creating your Docker ID. If you use Docker Hub, you can use the same username and password you use to log in to Docker Hub.
|
||||
|
||||
```
|
||||
$ docker-cloud login
|
||||
$ docker login
|
||||
Username: my-username
|
||||
Password:
|
||||
Login succeeded!
|
||||
|
|
|
@ -23,14 +23,14 @@ install Python or Go to follow the tutorial.
|
|||
|
||||
```bash
|
||||
$ git clone https://github.com/docker/dockercloud-quickstart-python.git
|
||||
$ cd quickstart-python
|
||||
$ cd dockercloud-quickstart-python
|
||||
```
|
||||
|
||||
**Go quickstart**
|
||||
|
||||
```bash
|
||||
$ git clone https://github.com/docker/dockercloud-quickstart-go.git
|
||||
$ cd quickstart-go
|
||||
$ cd dockercloud-quickstart-go
|
||||
```
|
||||
|
||||
## Build the application
|
||||
|
@ -42,13 +42,13 @@ Next, we have to build this application to create an image. Run the following co
|
|||
**Python quickstart**
|
||||
|
||||
```bash
|
||||
$ docker build --tag quickstart-python
|
||||
$ docker build --tag quickstart-python .
|
||||
```
|
||||
|
||||
**Go quickstart**
|
||||
|
||||
```bash
|
||||
$ docker build --tag quickstart-go
|
||||
$ docker build --tag quickstart-go .
|
||||
```
|
||||
|
||||
Next, we [Push the Docker image to Docker Cloud's Registry](4_push_to_cloud_registry.md).
|
||||
|
|
|
@ -29,7 +29,7 @@ $ docker-cloud service run \
|
|||
-p 80:80/tcp \
|
||||
--role global \
|
||||
--autorestart ALWAYS \
|
||||
--link-service quickstart-python:web \
|
||||
--link-service web:web \
|
||||
--name lb \
|
||||
dockercloud/haproxy
|
||||
```
|
||||
|
@ -40,7 +40,7 @@ dockercloud/haproxy
|
|||
|
||||
**--autorestart ALWAYS** tells Docker Cloud to always [restart the containers](../../apps/autorestart.md) if they stop.
|
||||
|
||||
**--link-service quickstart-python:web** links your load balancer service *haproxy* with the service *quickstart-python*, and names the link *web*. (Learn more about Service Linking [here](../../apps/service-links.md).)
|
||||
**--link-service web:web** links your load balancer service *haproxy* with the *web* service, and names the link *web*. (Learn more about Service Linking [here](../../apps/service-links.md).)
|
||||
|
||||
**--name lb** names the service *lb* (short for *load balancer*).
|
||||
|
||||
|
|
|
@ -120,6 +120,7 @@ Following the example in the previous section, you have a node cluster deployed
|
|||
What if you have another VPC for some other purpose, (the components already exist) and you want to deploy a node cluster in that VPC.
|
||||
|
||||
Docker Cloud:
|
||||
|
||||
1. Looks for the selected VPC. Found!
|
||||
2. Looks for selected subnets. If you do not select any subnets, Docker Cloud tries to create them using the rules previously described.
|
||||
3. If you selected more than one subnet, Docker Cloud distributes the nodes in the cluster among those subnets. If not, all nodes are placed in the same subnet.
|
||||
|
|
|
@ -1,14 +0,0 @@
|
|||
---
|
||||
description: Manage Infrastructure in Docker Cloud
|
||||
keywords:
|
||||
- nodes, hosts, infrastructure, Cloud
|
||||
menu:
|
||||
main:
|
||||
identifier: infrastructure
|
||||
parent: docker-cloud
|
||||
type: menu
|
||||
weight: -80
|
||||
title: Manage Infrastructure
|
||||
---
|
||||
|
||||
If you can see this page, please file a bug by emailing docs@docker.com
|
|
@ -3,7 +3,7 @@ aliases:
|
|||
- /docker-cloud/getting-started/intermediate/installing-cli/
|
||||
- /docker-cloud/getting-started/installing-cli/
|
||||
- /docker-cloud/tutorials/installing-cli/
|
||||
description: Using the Docker Cloud CLI on Linux, Windows, and Mac OS X, installing,
|
||||
description: Using the Docker Cloud CLI on Linux, Windows, and macOS, installing,
|
||||
updating, uninstall
|
||||
keywords:
|
||||
- cloud, command-line, CLI
|
||||
|
@ -42,10 +42,12 @@ Open your terminal or command shell and execute the following command:
|
|||
```bash
|
||||
$ pip install docker-cloud
|
||||
```
|
||||
If you encounter errors on Linux machines, make sure that `python-dev` is installed.
|
||||
For example, on Ubuntu, run the following command: `apt-get install python-dev`
|
||||
|
||||
#### Install on Mac OS X
|
||||
#### Install on macOS
|
||||
|
||||
We recommend installing Docker CLI for OS X using Homebrew. If you don't have `brew` installed, follow the instructions here: <a href="http://brew.sh" target="_blank">http://brew.sh</a>
|
||||
We recommend installing Docker CLI for macOS using Homebrew. If you don't have `brew` installed, follow the instructions here: <a href="http://brew.sh" target="_blank">http://brew.sh</a>
|
||||
|
||||
Once Homebrew is installed, open Terminal and run the following command:
|
||||
|
||||
|
@ -90,7 +92,7 @@ Periodically, Docker will add new features and fix bugs in the existing CLI. To
|
|||
$ pip install -U docker-cloud
|
||||
```
|
||||
|
||||
#### Upgrade the docker-cloud CLI on Mac OS X
|
||||
#### Upgrade the docker-cloud CLI on macOS
|
||||
|
||||
```
|
||||
$ brew update && brew upgrade docker-cloud
|
||||
|
@ -109,7 +111,7 @@ Open your terminal or command shell and execute the following command:
|
|||
$ pip uninstall docker-cloud
|
||||
```
|
||||
|
||||
#### Uninstall on Mac OS X
|
||||
#### Uninstall on macOS
|
||||
|
||||
Open your Terminal application and execute the following command:
|
||||
|
||||
|
|
|
@ -171,12 +171,12 @@ Optionally, override the default access level for specific repositories. -->
|
|||
| ------------- | ------------- |
|
||||
| **Repositories** | |
|
||||
| Read | Pull |
|
||||
| Read/Write | Pull, push, update description, delete |
|
||||
| Admin | All of the above, plus create |
|
||||
| Read/Write | Pull, push |
|
||||
| Admin | All of the above, plus update description, create and delete |
|
||||
| **Build** | |
|
||||
| Read | View build and build settings |
|
||||
| Read/write | View, cancel build, retry or trigger build |
|
||||
| Admin | All of the above, plus change a build source, create and delete |
|
||||
| Read | View basic build settings and Timeline |
|
||||
| Read/write | All of the above plus start, retry, or cancel build |
|
||||
| Admin | All of the above, plus view and change build configuration, change build source, create and delete |
|
||||
| **Nodes** | |
|
||||
| Read | View |
|
||||
| Read/write | View, scale, check node health |
|
||||
|
|
|
@ -55,7 +55,7 @@ The following release notes document changes since [Tutum v0.19.5](https://suppo
|
|||
- **Docker Cloud is Generally Available**: all features of Docker Cloud are Generally Available with the exception of the build features which remain in beta.
|
||||
- **Docker Hub Registry Integration**: All of your Docker Hub image repositories are available and accessible when you login to Docker Cloud. Changes you make to your repositories are reflected in both Docker Hub and Docker Cloud.
|
||||
- **Autoredeploy from Docker Hub**: services that use a repository stored in the Docker Hub now have the [**autoredeploy** option](apps/auto-redeploy.md) available, which allows automatic redeployments on push without setting up webhooks.
|
||||
- **Environment variable substitution on CLI**: the `docker-cloud` CLI now substitutes environment variables in stack files, [the same way Docker Compose does it](https://docs.docker.com/compose/compose-file/#variable-substitution:91de898b5f5cdb090642a917d3dedf68).
|
||||
- **Environment variable substitution on CLI**: the `docker-cloud` CLI now substitutes environment variables in stack files, [the same way Docker Compose does it](/compose/compose-file/#variable-substitution:91de898b5f5cdb090642a917d3dedf68).
|
||||
|
||||
|
||||
### Changed
|
||||
|
|
|
@ -18,7 +18,7 @@ If you already have an installation of Docker Toolbox, please read these topics
|
|||
|
||||
## The Docker Toolbox environment
|
||||
|
||||
Docker Toolbox installs `docker`, `docker-compose` and `docker-machine` in `/usr/local/bin` on your Mac. It also installs VirtualBox. At installation time, Toolbox uses `docker-machine` to provision a VirtualBox VM called `default`, running the `boot2docker` Linux distribution, with [Docker Engine](https://docs.docker.com/engine/) with certificates located on your Mac at `$HOME/.docker/machine/machines/default`.
|
||||
Docker Toolbox installs `docker`, `docker-compose` and `docker-machine` in `/usr/local/bin` on your Mac. It also installs VirtualBox. At installation time, Toolbox uses `docker-machine` to provision a VirtualBox VM called `default`, running the `boot2docker` Linux distribution, with [Docker Engine](/engine/) with certificates located on your Mac at `$HOME/.docker/machine/machines/default`.
|
||||
|
||||
Before you use `docker` or `docker-compose` on your Mac, you typically use the command `eval $(docker-machine env default)` to set environment variables so that `docker` or `docker-compose` know how to talk to Docker Engine running on VirtualBox.
|
||||
|
||||
|
@ -33,7 +33,7 @@ Docker for Mac is a Mac native application, that you install in `/Applications`.
|
|||
|
||||
Here are some key points to know about Docker for Mac before you get started:
|
||||
|
||||
* Docker for Mac does not use VirtualBox, but rather <a href="https://github.com/docker/HyperKit/" target="_blank">HyperKit</a>, a lightweight OS X virtualization solution built on top of Hypervisor.framework in OS X 10.10 Yosemite and higher.
|
||||
* Docker for Mac does not use VirtualBox, but rather <a href="https://github.com/docker/HyperKit/" target="_blank">HyperKit</a>, a lightweight macOS virtualization solution built on top of Hypervisor.framework in macOS 10.10 Yosemite and higher.
|
||||
|
||||
* Installing Docker for Mac does not affect machines you created with Docker Machine. The install offers to copy containers and images from your local `default` machine (if one exists) to the new Docker for Mac HyperKit VM. If chosen, content from `default` is copied to the new Docker for Mac HyperKit VM, and your original `default` machine is kept as is.
|
||||
|
||||
|
|
|
@ -53,8 +53,8 @@ Do the following each time:
|
|||
### What is Docker.app?
|
||||
|
||||
`Docker.app` is Docker for Mac, a bundle of Docker client, and Docker
|
||||
Engine. `Docker.app` uses the OS X
|
||||
Hypervisor.framework (part of MacOS X 10.10 Yosemite and higher)
|
||||
Engine. `Docker.app` uses the macOS
|
||||
Hypervisor.framework (part of macOS 10.10 Yosemite and higher)
|
||||
to run containers, meaning that _**no separate VirtualBox is required**_.
|
||||
|
||||
### What kind of feedback are we looking for?
|
||||
|
@ -116,13 +116,13 @@ Networking topic.
|
|||
|
||||
### How do I add custom CA certificates?
|
||||
|
||||
Starting with Docker for Mac 1.12.1, 2016-09-16 (stable) and Beta 27 Release Notes (2016-09-28 1.12.2-rc1-beta27), all trusted certificate authorities (CAs) (root or intermediate) are supported.
|
||||
Starting with Docker for Mac Beta 27 Release Notes (2016-09-28 1.12.2-rc1-beta27) and follow-on Beta releases, all trusted certificate authorities (CAs) (root or intermediate) are supported. (**Note:** Custom CA certificates are not yet supported on stable releases.)
|
||||
|
||||
Docker for Mac creates a certificate bundle of all user-trusted CAs based on the Mac Keychain, and appends it to Moby trusted certificates. So if an enterprise SSL certificate is trusted by the user on the host, it will be trusted by Docker for Mac.
|
||||
|
||||
### What are system requirements for Docker for Mac?
|
||||
|
||||
Note that you need a Mac that supports hardware virtualization, which is most non ancient ones; i.e., use OS X `10.10.3+` or `10.11` (OS X Yosemite or OS X El Capitan). See also "What to know before you install" in [Getting Started](index.md).
|
||||
Note that you need a Mac that supports hardware virtualization, which is most non ancient ones; i.e., use macOS `10.10.3+` or `10.11` (macOS Yosemite or macOS El Capitan). See also "What to know before you install" in [Getting Started](index.md).
|
||||
|
||||
### Do I need to uninstall Docker Toolbox to use Docker for Mac?
|
||||
|
||||
|
@ -140,7 +140,7 @@ Toolbox Mac topics.
|
|||
|
||||
### What is HyperKit?
|
||||
|
||||
HyperKit is a hypervisor built on top of the Hypervisor.framework in OS X 10.10 Yosemite and higher. It runs entirely in userspace and has no other dependencies.
|
||||
HyperKit is a hypervisor built on top of the Hypervisor.framework in macOS 10.10 Yosemite and higher. It runs entirely in userspace and has no other dependencies.
|
||||
|
||||
We use HyperKit to eliminate the need for other VM products, such as Oracle Virtualbox or VMWare Fusion.
|
||||
|
||||
|
|
|
@ -5,6 +5,7 @@ aliases:
|
|||
- /mac/
|
||||
- /mac/started/
|
||||
- /docker-for-mac/started/
|
||||
- /installation/mac/
|
||||
description: Getting Started
|
||||
keywords:
|
||||
- mac, beta, alpha, tutorial
|
||||
|
@ -54,30 +55,37 @@ For more about stable and beta channels, see the [FAQs](faqs.md#stable-and-beta-
|
|||
|
||||
>**Important Notes**:
|
||||
>
|
||||
>* Docker for Mac requires OS X 10.10.3 Yosemite or newer running on a 2010 or newer Mac, with Intel's hardware support for MMU virtualization. Please see [What to know before you install](index.md#what-to-know-before-you-install) for a full list of prerequisites.
|
||||
>- Docker for Mac requires macOS 10.10.3 Yosemite or newer running on a 2010 or
|
||||
> newer Mac, with Intel's hardware support for MMU virtualization. Please see
|
||||
> [What to know before you install](index.md#what-to-know-before-you-install)
|
||||
> for a full list of prerequisites.
|
||||
>
|
||||
>* <font color="#CC3366">You can switch between beta and stable versions, but _you must have only one app installed at a time_.</font> Also, you will need to save images and export containers you want to keep before uninstalling the current version before installing another. For more about this, see the [FAQs about beta and stable channels](faqs.md#stable-and-beta-channels).
|
||||
>- You can switch between beta and stable versions, but you must have only one
|
||||
> app installed at a time. Also, you will need to save images and export
|
||||
> containers you want to keep before uninstalling the current version before
|
||||
> installing another. For more about this, see the
|
||||
> [FAQs about beta and stable channels](faqs.md#stable-and-beta-channels).
|
||||
|
||||
## What to know before you install
|
||||
|
||||
|
||||
* **README FIRST for Docker Toolbox and Docker Machine users**: If you are already running Docker on your machine, first read [Docker for Mac vs. Docker Toolbox](docker-toolbox.md) to understand the impact of this installation on your existing setup, how to set your environment for Docker for Mac, and how the two products can coexist.
|
||||
|
||||
<p />
|
||||
* **Relationship to Docker Machine**: Installing Docker for Mac does not affect machines you created with Docker Machine. You'll get the option to copy containers and images from your local `default` machine (if one exists) to the new Docker for Mac <a href="https://github.com/docker/HyperKit/" target="_blank">HyperKit</a> VM. When you are running Docker for Mac, you do not need Docker Machine nodes running at all locally (or anywhere else). With Docker for Mac, you have a new, native virtualization system running (HyperKit) which takes the place of the VirtualBox system. To learn more, see [Docker for Mac vs. Docker Toolbox](docker-toolbox.md).
|
||||
|
||||
<p />
|
||||
* **System Requirements**: Docker for Mac will launch only if all these requirements are met.
|
||||
|
||||
- Mac must be a 2010 or newer model, with Intel's hardware support for memory management unit (MMU) virtualization; i.e., Extended Page Tables (EPT)
|
||||
|
||||
- OS X 10.10.3 Yosemite or newer
|
||||
- macOS 10.10.3 Yosemite or newer
|
||||
|
||||
- At least 4GB of RAM
|
||||
|
||||
- VirtualBox prior to version 4.3.30 must NOT be installed (it is incompatible with Docker for Mac)
|
||||
|
||||
> **Note**: If your system does not satisfy these requirements, you can install [Docker Toolbox](/toolbox/overview.md), which uses Oracle Virtual Box instead of HyperKit.
|
||||
>**Note**: If your system does not satisfy these requirements, you can install [Docker Toolbox](/toolbox/overview.md), which uses Oracle Virtual Box instead of HyperKit.
|
||||
|
||||
* **What the install includes**: The installation provides [Docker Engine](https://docs.docker.com/engine/userguide/intro/), Docker CLI client, [Docker Compose](https://docs.docker.com/compose/overview/), and [Docker Machine](https://docs.docker.com/machine/overview/).
|
||||
<p />
|
||||
* **What the install includes**: The installation provides [Docker Engine](/engine/userguide/intro/), Docker CLI client, [Docker Compose](/compose/overview/), and [Docker Machine](/machine/overview/).
|
||||
|
||||
## Step 1. Install and Run Docker for Mac
|
||||
|
||||
|
@ -130,20 +138,19 @@ Run these commands to test if your versions of `docker`, `docker-compose`, and `
|
|||
|
||||
Some good commands to try are `docker version` to check that you have the latest release installed, and `docker ps` and `docker run hello-world` to verify that Docker is running.
|
||||
|
||||
2. For something more adventurous, start a Dockerized web server.
|
||||
2. For something more adventurous, start a Dockerized web server.
|
||||
|
||||
```shell
|
||||
docker run -d -p 80:80 --name webserver nginx
|
||||
```
|
||||
```
|
||||
docker run -d -p 80:80 --name webserver nginx
|
||||
```
|
||||
|
||||
If the image is not found locally, Docker will pull it from Docker Hub.
|
||||
If the image is not found locally, Docker will pull it from Docker Hub.
|
||||
|
||||
In a web browser, go to `http://localhost/` to bring up the home page. (Since you specified the default HTTP port, it isn't necessary to append `:80` at the end of the URL.)
|
||||
In a web browser, go to `http://localhost/` to bring up the home page. (Since you specified the default HTTP port, it isn't necessary to append `:80` at the end of the URL.)
|
||||
|
||||

|
||||

|
||||
|
||||
>**Note:** Early beta releases used `docker` as the hostname to build the URL. Now, ports are exposed on the private IP addresses of the VM and forwarded to `localhost` with no other host name set. See also, [Release Notes](release-notes.md) for Beta 9.
|
||||
>
|
||||
>**Note:** Early beta releases used `docker` as the hostname to build the URL. Now, ports are exposed on the private IP addresses of the VM and forwarded to `localhost` with no other host name set. See also, [Release Notes](release-notes.md) for Beta 9.
|
||||
|
||||
3. Run `docker ps` while your web server is running to see details on the webserver container.
|
||||
|
||||
|
@ -180,7 +187,13 @@ Choose <img src="images/whale-x.png"> --> **Preferences** from the menu bar. You
|
|||
|
||||

|
||||
|
||||
* **Adding registries** - As an alternative to using [Docker Hub](https://hub.docker.com/) to store your public or private images or [Docker Trusted Registry](https://docs.docker.com/docker-trusted-registry/overview/), you can use Docker to set up your own insecure [registry](https://docs.docker.com/registry/introduction/). Add URLs for insecure registries and registry mirrors on which to host your images.
|
||||
* **Adding registries** - As an alternative to using [Docker Hub](https://hub.docker.com/) to store your public or private images or [Docker
|
||||
Trusted Registry](/docker-trusted-registry/overview/),
|
||||
you can use Docker to set up your own insecure
|
||||
[registry](/registry/introduction/). Add URLs for
|
||||
insecure registries and registry mirrors on which to host your images. (See
|
||||
also, [How do I add custom CA
|
||||
certificates?](faqs.md#how-do-i-add-custom-ca-certificates) in the FAQs.)
|
||||
|
||||
* **HTTP proxy settings** - Docker for Mac will detect HTTP/HTTPS Proxy Settings and automatically propagate these to Docker and to your containers.
|
||||
For example, if you set your proxy settings to `http://proxy.example.com`, Docker will use this proxy when pulling containers.
|
||||
|
|
|
@ -1,13 +0,0 @@
|
|||
---
|
||||
aliases: []
|
||||
description: Docker Mac
|
||||
keywords:
|
||||
- docker, mac, desktop, editions
|
||||
menu:
|
||||
main:
|
||||
identifier: pinata_mac_menu
|
||||
weight: -80
|
||||
title: Docker for Mac
|
||||
---
|
||||
|
||||
# Docker for Mac
|
|
@ -21,7 +21,7 @@ Docker for Mac provides several networking features to make it easier to use.
|
|||
### VPN Passthrough
|
||||
|
||||
Docker for Mac's networking can work when attached to a VPN.
|
||||
To do this, Docker for Mac intercepts traffic from the `HyperKit` and injects it into OSX as if it originated from the Docker application.
|
||||
To do this, Docker for Mac intercepts traffic from the `HyperKit` and injects it into macOS as if it originated from the Docker application.
|
||||
|
||||
### Port Mapping
|
||||
|
||||
|
@ -33,10 +33,10 @@ Docker for Mac will make the container port available at `localhost`.
|
|||
|
||||
### HTTP/HTTPS Proxy Support
|
||||
|
||||
Docker for Mac will detect HTTP/HTTPS Proxy Settings from OSX and automatically propagate these to Docker and to your containers.
|
||||
For example, if you set your proxy settings to `http://proxy.example.com` in OSX, Docker will use this proxy when pulling containers.
|
||||
Docker for Mac will detect HTTP/HTTPS Proxy Settings from macOS and automatically propagate these to Docker and to your containers.
|
||||
For example, if you set your proxy settings to `http://proxy.example.com` in macOS, Docker will use this proxy when pulling containers.
|
||||
|
||||

|
||||

|
||||
|
||||
When you start a container, you will see that your proxy settings propagate into the containers. For example:
|
||||
|
||||
|
@ -53,24 +53,24 @@ no_proxy=*.local, 169.254/16
|
|||
|
||||
You can see from the above output that the `HTTP_PROXY`, `http_proxy` and `no_proxy` environment variables are set.
|
||||
When your proxy configuration changes, Docker restarts automatically to pick up the new settings.
|
||||
If you have containers that you wish to keep running across restarts, you should consider using [restart policies](https://docs.docker.com/engine/reference/run/#restart-policies-restart)
|
||||
If you have containers that you wish to keep running across restarts, you should consider using [restart policies](/engine/reference/run/#restart-policies-restart)
|
||||
|
||||
## Known Limitations, Use Cases, and Workarounds
|
||||
|
||||
Following is a summary of current limitations on the Docker for Mac networking stack, along with some ideas for workarounds.
|
||||
|
||||
### There is no docker0 bridge on OSX
|
||||
### There is no docker0 bridge on macOS
|
||||
|
||||
Because of the way networking is implemented in Docker for Mac, you cannot see a `docker0` interface in OSX.
|
||||
Because of the way networking is implemented in Docker for Mac, you cannot see a `docker0` interface in macOS.
|
||||
This interface is actually within `HyperKit`.
|
||||
|
||||
### I cannot ping my containers
|
||||
|
||||
Unfortunately, due to limitations in OSX, we're unable to route traffic to containers, and from containers back to the host.
|
||||
Unfortunately, due to limitations in macOS, we're unable to route traffic to containers, and from containers back to the host.
|
||||
|
||||
### Per-container IP addressing is not possible
|
||||
|
||||
The docker (Linux) bridge network is not reachable from the OSX host.
|
||||
The docker (Linux) bridge network is not reachable from the macOS host.
|
||||
|
||||
### Use cases and workarounds
|
||||
|
||||
|
@ -105,6 +105,6 @@ See the [run commmand](/engine/reference/commandline/run.md) for more details on
|
|||
|
||||
#### A view into implementation
|
||||
|
||||
We understand that these workarounds are not ideal, but there are several problems. In particular, there is a bug in OSX that is only fixed in 10.12 and is not being backported as far as we can tell, which means that we could not support this in all supported OSX versions. In addition, this network setup would require root access which we are trying to avoid entirely in Docker for Mac (we currently have a very small root helper that we are trying to remove).
|
||||
We understand that these workarounds are not ideal, but there are several problems. In particular, there is a bug in macOS that is only fixed in 10.12 and is not being backported as far as we can tell, which means that we could not support this in all supported macOS versions. In addition, this network setup would require root access which we are trying to avoid entirely in Docker for Mac (we currently have a very small root helper that we are trying to remove).
|
||||
|
||||
|
||||
|
|
|
@ -20,17 +20,6 @@ user experience for bind mounting OS X file system trees into Docker
|
|||
containers. To this end, `osxfs` features a number of unique
|
||||
capabilities as well as differences from a classical Linux file system.
|
||||
|
||||
- [Case sensitivity](osxfs.md#case-sensitivity)
|
||||
- [Access control](osxfs.md#access-control)
|
||||
- [Namespaces](osxfs.md#namespaces)
|
||||
- [Ownership](osxfs.md#ownership)
|
||||
- [File system events](osxfs.md#file-system-events)
|
||||
- [Mounts](osxfs.md#mounts)
|
||||
- [Symlinks](osxfs.md#symlinks)
|
||||
- [File types](osxfs.md#file-types)
|
||||
- [Extended attributes](osxfs.md#extended-attributes)
|
||||
- [Technology](osxfs.md#technology)
|
||||
|
||||
### Case sensitivity
|
||||
|
||||
With Docker for Mac, file systems are shared from OS X into containers
|
||||
|
@ -69,7 +58,7 @@ sharing**. (See [Preferences](index.md#preferences).) All other paths
|
|||
used in `-v` bind mounts are sourced from the Moby Linux VM running the
|
||||
Docker containers, so arguments such as `-v
|
||||
/var/run/docker.sock:/var/run/docker.sock` should work as expected. If
|
||||
an OS X path is not shared and does not exist in th VM, an attempt to
|
||||
an OS X path is not shared and does not exist in the VM, an attempt to
|
||||
bind mount it will fail rather than create it in the VM. Paths that
|
||||
already exist in the VM and contain files are reserved by Docker and
|
||||
cannot be exported from OS X.
|
||||
|
@ -85,9 +74,11 @@ requests for ownership metadata will return the previously set
|
|||
values. Ownership-based permissions are only enforced at the OS X file
|
||||
system level with all accessing processes behaving as the user running
|
||||
Docker. If the user does not have permission to read extended attributes
|
||||
on an object, e.g. when that object's permissions are `0000`, ownership
|
||||
will be reported as the accessing process until the extended attribute
|
||||
is again readable.
|
||||
on an object (such as when that object's permissions are `0000`), `osxfs`
|
||||
will attempt to add an access control list (ACL) entry that allows
|
||||
the user to read and write extended attributes. If this attempt
|
||||
fails, the object will appear to be owned by the process accessing
|
||||
it until the extended attribute is readable again.
|
||||
|
||||
### File system events
|
||||
|
||||
|
@ -124,11 +115,11 @@ containers, only to those events originating in OS X.
|
|||
### Mounts
|
||||
|
||||
The OS X mount structure is not visible in the shared volume, but volume
|
||||
contents are visible. Volume contents appear in the same file system as the
|
||||
rest of the shared file system. Mounting/unmounting OS X volumes that
|
||||
are also bind mounted into containers may result in unexpected behavior
|
||||
in those containers. Unmount events are not supported. Mount export
|
||||
support is planned but is still under development.
|
||||
contents are visible. Volume contents appear in the same file system as the rest
|
||||
of the shared file system. Mounting/unmounting OS X volumes that are also bind
|
||||
mounted into containers may result in unexpected behavior in those containers.
|
||||
Unmount events are not supported. Mount export support is planned but is still
|
||||
under development.
|
||||
|
||||
### Symlinks
|
||||
|
||||
|
@ -152,3 +143,200 @@ Extended attributes are not yet supported.
|
|||
|
||||
`osxfs` does not use OSXFUSE. `osxfs` does not run under, inside, or
|
||||
between OS X userspace processes and the OS X kernel.
|
||||
|
||||
### Performance issues, solutions, and roadmap
|
||||
|
||||
With regard to reported performance issues ([GitHub issue 77: File access in
|
||||
mounted volumes extremely slow](https://github.com/docker/for-mac/issues/77)),
|
||||
and a similar thread on [Docker for Mac forums on topic: File access in mounted
|
||||
volumes extremely
|
||||
slow](https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/),
|
||||
this topic provides an explanation of the issues, what we are doing to
|
||||
address them, how the community can help us, and what you can expect in the
|
||||
future. This explanation is a slightly re-worked version of an [understanding
|
||||
performance
|
||||
post](https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/158?u=orangesnap)
|
||||
from David Sheets (@dsheets) on the [Docker development
|
||||
team](https://forums.docker.com/groups/Docker) to the forum topic just
|
||||
mentioned. We want to surface it in the documentation for wider reach.
|
||||
|
||||
#### Understanding performance
|
||||
|
||||
Perhaps the most important thing to understand is that shared file system
|
||||
performance is multi-dimensional. This means that, depending on your workload,
|
||||
you may experience exceptional, adequate, or poor performance with `osxfs`, the
|
||||
file system server in Docker for Mac. File system APIs are very wide (20-40
|
||||
message types) with many intricate semantics involving on-disk state, in-memory
|
||||
cache state, and concurrent access by multiple processes. Additionally, `osxfs`
|
||||
integrates a mapping between OS X's FSEvents API and Linux's inotify API
|
||||
which is implemented inside of the file system itself complicating matters
|
||||
further (cache behavior in particular).
|
||||
|
||||
At the highest level, there are two dimensions to file system performance:
|
||||
throughput (read/write IO) and latency (roundtrip time). In a traditional file
|
||||
system on a modern SSD, applications can generally expect throughput of a few
|
||||
GB/s. With large sequential IO operations, `osxfs` can achieve throughput of
|
||||
around 250 MB/s which, while not native speed, will not be the bottleneck for
|
||||
most applications which perform acceptably on HDDs.
|
||||
|
||||
Latency is the time it takes for a file system system call to complete. For
|
||||
instance, the time between a thread issuing write in a container and resuming
|
||||
with the number of bytes written. With a classical block-based file system, this
|
||||
latency is typically under 10μs (microseconds). With `osxfs`, latency is
|
||||
presently around 200μs for most operations or 20x slower. For workloads which
|
||||
demand many sequential roundtrips, this results in significant observable
|
||||
slowdown. To reduce the latency, we need to shorten the data path from a Linux
|
||||
system call to OS X and back again. This requires tuning each component in the
|
||||
data path in turn -- some of which require significant engineering effort. Even
|
||||
if we achieve a huge latency reduction of 100μs/roundtrip, we will still "only"
|
||||
see a doubling of performance. This is typical of performance engineering, which
|
||||
requires significant effort to analyze slowdowns and develop optimized
|
||||
components. We know how we can likely halve the roundtrip time but we haven't
|
||||
implemented those improvements yet (more on this below in [What you can
|
||||
do](osxfs.md#what-you-can-do)).
|
||||
|
||||
There is hope for significant performance improvement in the near term despite
|
||||
these fundamental communication channel properties, which are difficult to
|
||||
overcome (latency in particular). This hope comes in the form of increased
|
||||
caching (storing "recent" values closer to their use to prevent roundtrips
|
||||
completely). The Linux kernel's VFS layer contains a number of caches which can
|
||||
be used to greatly improve performance by reducing the required communication
|
||||
with the file system. Using this caching comes with a number of trade-offs:
|
||||
|
||||
* It requires understanding the cache behavior in detail in order to write
|
||||
correct, stateful functionality on top of those caches.
|
||||
|
||||
* It harms the coherence or consistency of the file system as observed
|
||||
from Linux containers and the OS X file system interfaces.
|
||||
|
||||
#### What we are doing
|
||||
|
||||
We are actively working on both increasing caching while mitigating the
|
||||
associated issues and on reducing the file system data path latency. This
|
||||
requires significant analysis of file system traces and speculative development
|
||||
of system improvements to try to address specific performance issues. Perhaps
|
||||
surprisingly, application workload can have a huge effect on performance. As an
|
||||
example, here are two different use cases contributed on the [forum topic]([File
|
||||
access in mounted volumes extremely
|
||||
slow](https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/)))
|
||||
and how their performance differs and suffers due to latency, caching, and
|
||||
coherence:
|
||||
|
||||
1. A rake example (see below) appears to attempt to access 37000+
|
||||
different files that don't exist on the shared volume. We can work very hard to
|
||||
speed up all use cases by 2x via latency reduction but this use case will still
|
||||
seem "slow". The ultimate solution for rake is to use a "negative dcache" that
|
||||
keeps track of, in the Linux kernel itself, the files that do not exist.
|
||||
Unfortunately, even this is not sufficient for the first time rake is run on a
|
||||
shared directory. To handle that case, we actually need to develop a Linux
|
||||
kernel patch which negatively caches all directory entries not in a
|
||||
specified set -- and this cache must be kept up-to-date in real-time with the OS
|
||||
X file system state even in the presence of missing OS X FSEvents messages and
|
||||
so must be invalidated if OS X ever reports an event delivery failure.
|
||||
|
||||
2. Running ember build in a shared file system results in ember creating many
|
||||
different temporary directories and performing lots of intermediate activity
|
||||
within them. An empty ember project is over 300MB. This usage pattern does not
|
||||
require coherence between Linux and OS X but, because we cannot distinguish this
|
||||
fact at run-time, we maintain coherence during its hundreds of thousands of file
|
||||
system accesses to manipulate temporary state. There is no "correct" solution in
|
||||
this case. Either ember needs to change, the volume mount needs to have
|
||||
coherence properties specified on it somehow, some heuristic needs to be
|
||||
introduced to detect this access pattern and compensate, or the behavior needs
|
||||
to be indicated via, e.g., extended attributes in the OS X file system.
|
||||
|
||||
These two examples come from performance use cases contributed by users and they
|
||||
are incredibly helpful in prioritizing aspects of file system performance to
|
||||
improve. We are developing statistical file system trace analysis tools
|
||||
to characterize slow-performing workloads more easily in order to decide what to
|
||||
work on next.
|
||||
|
||||
Under development, we have:
|
||||
|
||||
1. A Linux kernel patch to reduce data path latency by 2/7 copies and 2/5
|
||||
context switches
|
||||
|
||||
2. Increased OS X integration to reduce the latency between the hypervisor and
|
||||
the file system server
|
||||
|
||||
3. A server-side directory read cache to speed up traversal of large directories
|
||||
|
||||
4. User-facing file system tracing capabilities so that you can send us
|
||||
recordings of slow workloads for analysis
|
||||
|
||||
5. A growing performance test suite of real world use cases (more on this below
|
||||
in What you can do)
|
||||
|
||||
6. Experimental support for using Linux's inode, writeback, and page caches
|
||||
|
||||
7. End-user controls to configure the coherence of subsets of cross-OS bind
|
||||
mounts without exposing all of the underlying complexity
|
||||
|
||||
#### What you can do
|
||||
|
||||
When you report shared file system performance issues, it is most helpful to
|
||||
include a minimal Real World reproduction test case that demonstrates poor
|
||||
performance.
|
||||
|
||||
Without a reproduction, it is very difficult for us to analyze your use case and
|
||||
determine what improvements would speed it up. When you don't provide a
|
||||
reproduction, one of us has to take the time to figure out the specific software
|
||||
you are using and guess and hope that we have configured it in a typical way or
|
||||
a way that has poor performance. That usually takes 1-4 hours depending on your
|
||||
use case and once it is done, we must then determine what regular performance is
|
||||
like and what kind of slow-down your use case is experiencing. In some cases, it
|
||||
is not obvious what operation is even slow in your specific development
|
||||
workflow. The additional set-up to reproduce the problem means we have less time
|
||||
to fix bugs, develop analysis tools, or improve performance. So, please include
|
||||
simple, immediate performance issue reproduction test cases. The [rake
|
||||
reproduction
|
||||
case](https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/103)
|
||||
by @hirowatari shown in the forums thread is a great example.
|
||||
|
||||
This example originally provided:
|
||||
|
||||
1. A version-controlled repository so any changes/improvements to the test case
|
||||
can be easily tracked.
|
||||
|
||||
2. A Dockerfile which constructs the exact image to run
|
||||
|
||||
3. A command-line invocation of how to start the container
|
||||
|
||||
4. A straight-forward way to measure the performance of the use case
|
||||
|
||||
5. A clear explanation (README) of how to run the test case
|
||||
|
||||
#### What you can expect
|
||||
|
||||
We will continue to work toward an optimized shared file system implementation
|
||||
on the Beta channel of Docker for Mac.
|
||||
|
||||
You can expect some of the performance improvement work mentioned above to reach
|
||||
the Beta channel in the coming release cycles.
|
||||
|
||||
In due course, we will open source all of our shared file system components. At
|
||||
that time, we would be very happy to collaborate with you on improving the
|
||||
implementation of osxfs and related software.
|
||||
|
||||
We still have on the slate to write up and publish details of shared file system
|
||||
performance analysis and improvement on the Docker blog. Look for or nudge
|
||||
@dsheets about those articles, which should serve as a jumping off point for
|
||||
understanding the system, measuring it, or contributing to it.
|
||||
|
||||
#### Wrapping Up
|
||||
|
||||
We hope this gives you a rough idea of where `osxfs` performance is and where
|
||||
it's going. We are treating good performance as a top priority feature of the
|
||||
file system sharing component and we are actively working on improving it
|
||||
through a number of different avenues. The osxfs project started in December
|
||||
2015. Since the first integration into Docker for Mac in February 2016, we've
|
||||
improved performance by 50x or more for many workloads while achieving nearly
|
||||
complete POSIX compliance and without compromising coherence (it is shared and
|
||||
not simply synced). Of course, in the beginning there was lots of low-hanging
|
||||
fruit and now many of the remaining performance improvements require significant
|
||||
engineering work on custom low-level components.
|
||||
|
||||
We appreciate your understanding as we continue development of the product and
|
||||
work on all dimensions of performance. We want to continue to work with the
|
||||
community on this, so please continue to report issues as you find them. We look
|
||||
forward to collaborting with you on ideas and on the source code itself.
|
||||
|
|
|
@ -29,7 +29,7 @@ Release notes for _stable_ and _beta_ releases are listed below. You can learn a
|
|||
|
||||
**New**
|
||||
|
||||
* Support for OSX 10.12 Sierra
|
||||
* Support for macOS 10.12 Sierra
|
||||
|
||||
**Upgrades**
|
||||
|
||||
|
@ -43,12 +43,12 @@ Release notes for _stable_ and _beta_ releases are listed below. You can learn a
|
|||
**General**
|
||||
|
||||
* Fixed communications glitch when UI talks to com.docker.vmnetd
|
||||
Fixes https://github.com/docker/for-mac/issues/90
|
||||
Fixes [https://github.com/docker/for-mac/issues/90](https://github.com/docker/for-mac/issues/90)
|
||||
|
||||
* `docker-diagnose`: display and record the time the diagnosis was captured
|
||||
|
||||
* Don't compute the container folder in `com.docker.vmnetd`
|
||||
Fixes https://github.com/docker/for-mac/issues/47
|
||||
Fixes [https://github.com/docker/for-mac/issues/47](https://github.com/docker/for-mac/issues/47)
|
||||
|
||||
* Warn the user if BlueStacks is installed (potential kernel panic)
|
||||
|
||||
|
@ -69,11 +69,11 @@ Release notes for _stable_ and _beta_ releases are listed below. You can learn a
|
|||
* Entries from `/etc/hosts` should now resolve from within containers
|
||||
|
||||
* Allow ports to be bound on host addresses other than `0.0.0.0` and `127.0.0.1`
|
||||
Fixes issue reported in https://github.com/docker/for-mac/issues/68
|
||||
Fixes issue reported in [https://github.com/docker/for-mac/issues/68](https://github.com/docker/for-mac/issues/68)
|
||||
|
||||
* Use Mac System Configuration database to detect DNS
|
||||
|
||||
**Filesharing (OSXFS)**
|
||||
**Filesharing (osxfs)**
|
||||
|
||||
* Fixed thread leak
|
||||
|
||||
|
@ -107,15 +107,15 @@ This bug fix release contains osxfs improvements. The fixed issues may have
|
|||
been seen as failures with apt-get and npm in containers, missed inotify
|
||||
events or unexpected unmounts.
|
||||
|
||||
* Bug fixes
|
||||
- osxfs: fixed an issue causing access to children of renamed
|
||||
directories to fail (symptoms: npm failures, apt-get failures)
|
||||
- osxfs: fixed an issue causing some ATTRIB and CREATE inotify
|
||||
events to fail delivery and other inotify events to stop
|
||||
- osxfs: fixed an issue causing all inotify events to stop when an
|
||||
ancestor directory of a mounted directory was mounted
|
||||
- osxfs: fixed an issue causing volumes mounted under other mounts
|
||||
to spontaneously unmount
|
||||
**Bug fixes**
|
||||
|
||||
* osxfs: fixed an issue causing access to children of renamed directories to fail (symptoms: npm failures, apt-get failures)
|
||||
|
||||
* osxfs: fixed an issue causing some ATTRIB and CREATE inotify events to fail delivery and other inotify events to stop
|
||||
|
||||
* osxfs: fixed an issue causing all inotify events to stop when an ancestor directory of a mounted directory was mounted
|
||||
|
||||
* osxfs: fixed an issue causing volumes mounted under other mounts to spontaneously unmount
|
||||
|
||||
### Docker for Mac 1.12.0-a, 2016-08-03 (stable)
|
||||
|
||||
|
@ -145,6 +145,61 @@ events or unexpected unmounts.
|
|||
|
||||
## Beta Release Notes
|
||||
|
||||
### Beta 29.3 Release Notes (2016-11-02 1.12.3-beta29.3)
|
||||
|
||||
**Upgrades**
|
||||
|
||||
- Docker Compose 1.9.0-rc2
|
||||
- `osxfs`: Fixed a simultaneous volume mount race which can result in a crash
|
||||
|
||||
### Beta 29.2 Release Notes (2016-10-27 1.12.2-beta29.2)
|
||||
|
||||
**Hotfixes**
|
||||
|
||||
- Upgrade to Docker 1.12.3
|
||||
|
||||
### Beta 29.1 Release Notes (2016-10-26 1.12.1-beta29.1)
|
||||
|
||||
**Hotfixes**
|
||||
|
||||
- Fixed missing `/dev/pty/ptmx`
|
||||
|
||||
### Beta 29 Release Notes (2016-10-25 1.12.3-rc1-beta29)
|
||||
|
||||
**New**
|
||||
|
||||
- Overlay2 is now the default storage driver. You must do a factory reset for overlay2 to be automatically used. (#5545)
|
||||
|
||||
**Upgrades**
|
||||
|
||||
- Docker 1.12.3-rc1
|
||||
- Linux kernel 4.4.27
|
||||
|
||||
**Bug fixes and minor changes**
|
||||
|
||||
- Fix an issue where the whale animation during setting change was inconsistent
|
||||
- Fix an issue where some windows stayed hidden behind another app
|
||||
- Fix application of system or custom proxy settings over container restart
|
||||
- Increase default ulimit for memlock (fixes [https://github.com/docker/for-mac/issues/801](https://github.com/docker/for-mac/issues/801) )
|
||||
- Fix an issue where the Docker status would continue to be
|
||||
yellow/animated after the VM had started correctly
|
||||
- osxfs: fix the prohibition of chown on read-only or mode 0 files (fixes [https://github.com/docker/for-mac/issues/117](https://github.com/docker/for-mac/issues/117), [https://github.com/docker/for-mac/issues/263](https://github.com/docker/for-mac/issues/263), [https://github.com/docker/for-mac/issues/633](https://github.com/docker/for-mac/issues/633) )
|
||||
|
||||
### Beta 28 Release Notes (2016-10-13 1.12.2-rc3-beta28)
|
||||
|
||||
**Upgrades**
|
||||
|
||||
- Docker 1.12.2
|
||||
- Kernel 4.4.24
|
||||
- Notary 0.4.2
|
||||
|
||||
**Bug fixes and minor changes**
|
||||
|
||||
- Fixed an issue where Docker for Mac was incorrectly reported as updated
|
||||
- osxfs: Fixed race condition causing some reads to run forever
|
||||
- Channel is now displayed in About box
|
||||
- Crash reports are sent over Bugsnag rather than HockeyApp
|
||||
|
||||
### Beta 27 Release Notes (2016-09-28 1.12.2-rc1-beta27)
|
||||
|
||||
**Upgrades**
|
||||
|
@ -158,15 +213,15 @@ events or unexpected unmounts.
|
|||
|
||||
**Bug fixes and minor changes**
|
||||
|
||||
* Fix an issue where some windows did not claim focus correctly
|
||||
* Add UI when switching channel to prevent user losing containers and settings
|
||||
* Fixed an issue where some windows did not claim focus correctly
|
||||
* Added UI when switching channel to prevent user losing containers and settings
|
||||
* Check disk capacity before Toolbox import
|
||||
* Import certificates in `etc/ssl/certs/ca-certificates.crt`
|
||||
* DNS: reduce the number of UDP sockets consumed on the host
|
||||
* VPNkit: improve the connection-limiting code to avoid running out of sockets on the host
|
||||
* UDP: handle diagrams bigger than 2035, up to the configured macOS kernel limit
|
||||
* UDP: make the forwarding more robust; drop packets and continue rather than stopping
|
||||
* disk: make the "flush" behaviour configurable for database-like workloads. This works around a performance regression in `v1.12.1`.
|
||||
* UDP: made the forwarding more robust; now, drop packets and continue rather than stopping
|
||||
* disk: made the "flush" behaviour configurable for database-like workloads. This works around a performance regression in `v1.12.1`.
|
||||
|
||||
### Beta 26 Release Notes (2016-09-14 1.12.1-beta26)
|
||||
|
||||
|
@ -181,7 +236,7 @@ events or unexpected unmounts.
|
|||
|
||||
**Bug fixes and minor changes**
|
||||
|
||||
* Fixed communications glitch when UI talks to `com.docker.vmnetd`. Fixes https://github.com/docker/for-mac/issues/90
|
||||
* Fixed communications glitch when UI talks to `com.docker.vmnetd`. Fixes [https://github.com/docker/for-mac/issues/90](https://github.com/docker/for-mac/issues/90)
|
||||
|
||||
* UI fix for macOs 10.12
|
||||
|
||||
|
@ -193,13 +248,13 @@ events or unexpected unmounts.
|
|||
|
||||
* `docker-diagnose` displays and records the time the diagnosis was captured
|
||||
|
||||
* Ports are allowed to bind to host addresses other than `0.0.0.0` and `127.0.0.1`. Fixes issue reported in https://github.com/docker/for-mac/issues/68.
|
||||
* Ports are allowed to bind to host addresses other than `0.0.0.0` and `127.0.0.1`. Fixes issue reported in [https://github.com/docker/for-mac/issues/68](https://github.com/docker/for-mac/issues/68).
|
||||
|
||||
* We no longer compute the container folder in `com.docker.vmnetd`. Fixes https://github.com/docker/for-mac/issues/47.
|
||||
* We no longer compute the container folder in `com.docker.vmnetd`. Fixes [https://github.com/docker/for-mac/issues/47](https://github.com/docker/for-mac/issues/47).
|
||||
|
||||
**Known Issues**
|
||||
|
||||
* `Docker.app` sometimes uses 200% CPU after OS X wakes up from sleep mode. The
|
||||
* `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode. The
|
||||
issue is being investigated. The workaround is to restart Docker.app.
|
||||
|
||||
* There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks and
|
||||
|
@ -214,7 +269,7 @@ available in [Known Issues](troubleshoot.md#known-issues) in Troubleshooting.
|
|||
|
||||
**Upgrades**
|
||||
|
||||
* Experimental support for OSX 10.12 Sierra (beta)
|
||||
* Experimental support for macOS 10.12 Sierra (beta)
|
||||
|
||||
**Bug fixes and minor changes**
|
||||
|
||||
|
@ -228,7 +283,7 @@ available in [Known Issues](troubleshoot.md#known-issues) in Troubleshooting.
|
|||
investigated. This includes failure to launch the app and being unable to
|
||||
upgrade to a new version.
|
||||
|
||||
* Docker.app sometimes uses 200% CPU after OS X wakes up from sleep mode. The
|
||||
* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The
|
||||
issue is being investigated. The workaround is to restart Docker.app
|
||||
|
||||
* There are a number of issues with the performance of directories bind-mounted
|
||||
|
@ -266,7 +321,7 @@ Issues](troubleshoot.md#known-issues) in Troubleshooting.
|
|||
* Several problems have been reported on macOS 10.12 Sierra and are being investigated. This includes failure to launch the app and being unable to
|
||||
upgrade to a new version.
|
||||
|
||||
* `Docker.app` sometimes uses 200% CPU after OS X wakes up from sleep mode. The issue is being investigated. The workaround is to restart `Docker.app`.
|
||||
* `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart `Docker.app`.
|
||||
|
||||
* There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks and traversals of large
|
||||
directories are currently slow. Additionally, containers that perform large
|
||||
|
@ -293,9 +348,9 @@ trees, may suffer from poor performance. For more information and workarounds, s
|
|||
|
||||
**Known issues**
|
||||
|
||||
* Docker for Mac is not supported on OSX 10.12 Sierra
|
||||
* Docker for Mac is not supported on macOS 10.12 Sierra
|
||||
|
||||
* Docker.app sometimes uses 200% CPU after OS X wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
|
||||
* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
|
||||
|
||||
* There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks and traversals of large directories are currently slow. Additionally, containers that perform large numbers of directory operations, such as repeated scans of large directory trees, may suffer from poor performance. For more information and workarounds, see the bullet on [performance of bind-mounted directories](troubleshoot.md#bind-mounted-dirs) in [Known Issues](troubleshoot.md#known-issues) in Troubleshooting.
|
||||
|
||||
|
@ -318,7 +373,7 @@ trees, may suffer from poor performance. For more information and workarounds, s
|
|||
|
||||
**Known issues**
|
||||
|
||||
* Docker.app sometimes uses 200% CPU after OS X wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
|
||||
* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
|
||||
|
||||
* There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks and traversals of large directories are currently slow. Additionally, containers that perform large numbers of directory operations, such as repeated scans of large directory trees, may suffer from poor performance. More information is available in [Known Issues](troubleshoot.md#known-issues) in [Troubleshooting](troubleshoot.md)
|
||||
|
||||
|
@ -365,7 +420,7 @@ events or unexpected unmounts.
|
|||
|
||||
**Known issues**
|
||||
|
||||
* Docker.app sometimes uses 200% CPU after OS X wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
|
||||
* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
|
||||
|
||||
* There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks, and traversals of large directories are currently slow. Additionally, containers that perform large numbers of directory operations, such as repeated scans of large directory trees, may suffer from poor performance. For more information and workarounds, see [Known Issues](troubleshoot.md#known-issues) in [Logs and Troubleshooting](troubleshoot.md).
|
||||
|
||||
|
@ -384,7 +439,7 @@ events or unexpected unmounts.
|
|||
|
||||
**Known issues**
|
||||
|
||||
* `Docker.app` sometimes uses 200% CPU after OS X wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker for Mac (`Docker.app`).
|
||||
* `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker for Mac (`Docker.app`).
|
||||
|
||||
### Beta 19 Release Notes (2016-07-14 1.12.0-rc4-beta19)
|
||||
|
||||
|
@ -468,7 +523,7 @@ events or unexpected unmounts.
|
|||
|
||||
**Bug fixes and minor changes**
|
||||
|
||||
* Documentation moved to https://docs.docker.com/docker-for-mac/
|
||||
* Documentation moved to [https://docs.docker.com/docker-for-mac/](/docker-for-mac/)
|
||||
* Allow non-admin users to launch the app for the first time (using admin creds)
|
||||
* Prompt non-admin users for admin password when needed in Preferences
|
||||
* Fixed download links, documentation links
|
||||
|
@ -533,7 +588,7 @@ events or unexpected unmounts.
|
|||
|
||||
**Known issues**
|
||||
|
||||
* `Docker.app` sometimes uses 200% CPU after OS X wakes up from sleep mode with OSX 10.10. The issue is being investigated. The workaround is to restart `Docker.app`.
|
||||
* `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode with macOS 10.10. The issue is being investigated. The workaround is to restart `Docker.app`.
|
||||
|
||||
**Bug fixes and minor changes**
|
||||
|
||||
|
@ -564,7 +619,7 @@ events or unexpected unmounts.
|
|||
|
||||
**Known issues**
|
||||
|
||||
* Docker.app sometimes uses 200% CPU after OS X wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
|
||||
* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
|
||||
|
||||
**Bug fixes and minor changes**
|
||||
|
||||
|
@ -583,7 +638,7 @@ events or unexpected unmounts.
|
|||
|
||||
**Known issues**
|
||||
|
||||
* Docker.app sometimes uses 200% CPU after OS X wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
|
||||
* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
|
||||
|
||||
**Bug fixes and minor changes**
|
||||
|
||||
|
@ -594,7 +649,7 @@ events or unexpected unmounts.
|
|||
|
||||
**New**
|
||||
|
||||
The `osxfs` file system now persists ownership changes in an extended attribute. (See the topic on [ownership](osxfs.md#ownership) in [Sharing the OS X file system with Docker containers](osxfs.md).)
|
||||
The `osxfs` file system now persists ownership changes in an extended attribute. (See the topic on [ownership](osxfs.md#ownership) in [Sharing the macOS file system with Docker containers](osxfs.md).)
|
||||
|
||||
**Upgrades**
|
||||
|
||||
|
@ -644,7 +699,7 @@ The `osxfs` file system now persists ownership changes in an extended attribute.
|
|||
|
||||
**Known issues**
|
||||
|
||||
* Docker.app sometimes uses 200% CPU after OS X wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
|
||||
* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
|
||||
|
||||
**Bug fixes and minor changes**
|
||||
|
||||
|
@ -679,7 +734,7 @@ The `osxfs` file system now persists ownership changes in an extended attribute.
|
|||
|
||||
**Known issues**
|
||||
|
||||
* Docker.app sometimes uses 200% CPU after OS X wakes up from sleep mode. The issue is being investigated. The workaround is to restart `Docker.app`
|
||||
* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart `Docker.app`
|
||||
|
||||
**Bug fixes and minor changes**
|
||||
|
||||
|
@ -708,7 +763,7 @@ The `osxfs` file system now persists ownership changes in an extended attribute.
|
|||
|
||||
**Known issues**
|
||||
|
||||
* Docker.app sometimes uses 200% CPU after OS X wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
|
||||
* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
|
||||
|
||||
* If VPN mode is enabled and then disabled and then re-enabled again, `docker ps` will block for 90s
|
||||
|
||||
|
@ -732,7 +787,7 @@ The `osxfs` file system now persists ownership changes in an extended attribute.
|
|||
|
||||
**Known issues**
|
||||
|
||||
* `Docker.app` sometimes uses 200% CPU after OS X wakes up from sleep mode.
|
||||
* `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode.
|
||||
The issue is being investigated. The workaround is to restart
|
||||
`Docker.app`.
|
||||
|
||||
|
@ -768,7 +823,7 @@ lead to `Docker.app` not starting on reboot
|
|||
|
||||
- There is a race on startup between docker and networking which can lead to Docker.app not starting on reboot. The workaround is to restart the application manually.
|
||||
|
||||
- Docker.app sometimes uses 200% CPU after OS X wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
|
||||
- Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
|
||||
|
||||
- In VPN mode, the `-p` option needs to be explicitly of the form `-p <host port>:<container port>`. `-p <port>` and `-P` will not work yet.
|
||||
|
||||
|
@ -798,7 +853,7 @@ lead to `Docker.app` not starting on reboot
|
|||
|
||||
- There is a race on startup between Docker and networking that can lead to `Docker.app` not starting on reboot. The workaround is to restart the application manually.
|
||||
|
||||
- `Docker.app` sometimes uses 200% CPU after OS X wakes up from sleep mode. The issue is being investigated. The workaround is to restart `Docker.app`.
|
||||
- `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart `Docker.app`.
|
||||
|
||||
- VPN/Hostnet: In VPN mode, the `-p` option needs to be explicitly of the form
|
||||
`-p <host port>:<container port>`. `-p <port>` and `-P` will not
|
||||
|
@ -810,7 +865,7 @@ work yet.
|
|||
|
||||
- `docker ps` shows IP address rather than `docker.local`
|
||||
|
||||
- Re-enabled support for OS X Yosemite version 10.10
|
||||
- Re-enabled support for macOS Yosemite version 10.10
|
||||
|
||||
- Ensured binaries are built for 10.10 rather than 10.11
|
||||
|
||||
|
@ -823,7 +878,7 @@ work yet.
|
|||
|
||||
**New Features and Upgrades**
|
||||
|
||||
- Improved file sharing write speed in OSXFS
|
||||
- Improved file sharing write speed in osxfs
|
||||
|
||||
- User space networking: Renamed `bridged` mode to `nat` mode
|
||||
|
||||
|
@ -836,8 +891,8 @@ work yet.
|
|||
- GUI: Auto update automatically checks for new versions again
|
||||
|
||||
- File System
|
||||
- Fixed OSXFS chmod on sockets
|
||||
- FixED OSXFS EINVAL from `open` using O_NOFOLLOW
|
||||
- Fixed osxfs chmod on sockets
|
||||
- FixED osxfs EINVAL from `open` using O_NOFOLLOW
|
||||
|
||||
|
||||
- Hypervisor stability fixes, resynced with upstream repository
|
||||
|
|
|
@ -99,7 +99,7 @@ The diagnostics and usage information to the left of the results provide auto-ge
|
|||
|
||||
## Troubleshooting
|
||||
|
||||
#### Recreate or update your containers after Beta 18 upgrade
|
||||
### Recreate or update your containers after Beta 18 upgrade
|
||||
|
||||
Docker 1.12.0 RC3 release introduces a backward incompatible change from RC2 to RC3. (For more information, see https://github.com/docker/docker/issues/24343#issuecomment-230623542.)
|
||||
|
||||
|
@ -111,13 +111,13 @@ You can fix this by either [recreating](troubleshoot.md#recreate-your-containers
|
|||
|
||||
If you get the error message shown above, we recommend recreating them.
|
||||
|
||||
##### Recreate your containers
|
||||
#### Recreate your containers
|
||||
|
||||
To recreate your containers, use Docker Compose.
|
||||
|
||||
docker-compose down && docker-compose up
|
||||
|
||||
##### Update your containers
|
||||
#### Update your containers
|
||||
|
||||
To fix existing containers, follow these steps.
|
||||
|
||||
|
@ -153,7 +153,7 @@ To fix existing containers, follow these steps.
|
|||
$ docker start old-container
|
||||
old-container
|
||||
|
||||
#### Incompatible CPU detected
|
||||
### Incompatible CPU detected
|
||||
|
||||
Docker for Mac requires a processor (CPU) that supports virtualization and, more specifically, the [Apple Hypervisor framework](https://developer.apple.com/library/mac/documentation/DriversKernelHardware/Reference/Hypervisor/). Docker for Mac is only compatible with Macs that have a CPU that supports the Hypervisor framework. Most Macs built in 2010 and later support it, as described in the Apple Hypervisor Framework documentation about supported hardware:
|
||||
|
||||
|
@ -171,7 +171,7 @@ If not, the command will print `kern.hv_support: 0`.
|
|||
See also, [Hypervisor Framework Reference](https://developer.apple.com/library/mac/documentation/DriversKernelHardware/Reference/Hypervisor/) in the Apple documentation, and Docker for Mac system requirements in [What to know before you install](index.md#what-to-know-before-you-install).
|
||||
|
||||
|
||||
#### Workarounds for common problems
|
||||
### Workarounds for common problems
|
||||
|
||||
* IPv6 workaround to auto-filter DNS addresses - IPv6 is not yet supported on Docker for Mac, which typically manifests as a network timeout when running `docker` commands that need access to external network servers (e.g., `docker pull busybox`).
|
||||
|
||||
|
@ -220,7 +220,7 @@ ${!DOCKER_*}` will unset existing `DOCKER` environment variables you have set.
|
|||
|
||||
<p></p>
|
||||
|
||||
* Note that network connections will fail if the OS X Firewall is set to
|
||||
* Note that network connections will fail if the macOS Firewall is set to
|
||||
"Block all incoming connections". You can enable the firewall, but `bootpd` must be allowed incoming connections so that the VM can get an IP address.
|
||||
|
||||
<p></p>
|
||||
|
@ -244,8 +244,6 @@ environments, see [Docker for Mac vs. Docker Toolbox](docker-toolbox.md).
|
|||
|
||||
See also [Known Issues](troubleshoot.md#known-issues) on this page, and the [FAQs](faqs.md) topic.
|
||||
|
||||
<a name="issues"></a>
|
||||
|
||||
## Known issues
|
||||
|
||||
* IPv6 is not yet supported on Docker for Mac. If you are using IPv6, and haven't upgraded to Beta 24 or v1.12.1 stable or newer, you will see a network
|
||||
|
@ -268,7 +266,7 @@ Docker for Mac does not yet support IPv6. See "IPv6 workaround to auto-filter DN
|
|||
|
||||
<p></p>
|
||||
|
||||
* Docker for Mac uses the `HyperKit` hypervisor (https://github.com/docker/hyperkit) in Mac OS X 10.10 Yosemite and higher. If you are developing with tools that have conflicts with `HyperKit`, such as [Intel Hardware Accelerated Execution Manager (HAXM)](https://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager/), the current workaround is not to run them at the same time. You can pause `HyperKit` by quitting Docker for Mac temporarily while you work with HAXM. This will allow you to continue work with the other tools and prevent `HyperKit` from interfering.
|
||||
* Docker for Mac uses the `HyperKit` hypervisor (https://github.com/docker/hyperkit) in macOS 10.10 Yosemite and higher. If you are developing with tools that have conflicts with `HyperKit`, such as [Intel Hardware Accelerated Execution Manager (HAXM)](https://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager/), the current workaround is not to run them at the same time. You can pause `HyperKit` by quitting Docker for Mac temporarily while you work with HAXM. This will allow you to continue work with the other tools and prevent `HyperKit` from interfering.
|
||||
|
||||
<p></p>
|
||||
|
||||
|
@ -299,18 +297,14 @@ Alternatively you could create a plain-text TCP proxy on localhost:1234 using:
|
|||
- Symfony
|
||||
- Magento
|
||||
- Zend Framework
|
||||
- PHP applications that use [Composer](https://getcomposer.org) to install dependencies in a ```vendor``` folder
|
||||
|
||||
<p></p>
|
||||
- PHP applications that use [Composer](https://getcomposer.org) to install dependencies in a ```vendor``` folder<br><br>
|
||||
|
||||
As a work-around for this behavior, you can put vendor or third-party library directories in Docker volumes, perform temporary file system
|
||||
operations outside of `osxfs` mounts, and use third-party tools like
|
||||
Unison or `rsync` to synchronize between container directories and
|
||||
bind-mounted directories. We are actively working on `osxfs`
|
||||
performance using a number of different techniques and we look forward
|
||||
to sharing improvements with you soon.
|
||||
performance using a number of different techniques. To learn more, please see the topic on [Performance issues, solutions, and roadmap](osxfs.md#performance-issues-solutions-and-roadmap).
|
||||
|
||||
<p></p>
|
||||
|
||||
* If your system does not have access to an NTP server, then after a hibernate the time seen by Docker for Mac may be considerably out of sync with the host. Furthermore, the time may slowly drift out of sync during use. To manually reset the time after hibernation, run:
|
||||
|
||||
|
|
|
@ -157,6 +157,15 @@ cycles. Exit and start Docker to restore connectivity.
|
|||
Unfortunately, VirtualBox (and other hypervisors like VMWare) cannot run when
|
||||
Hyper-V is enabled on Windows.
|
||||
|
||||
### How do I run Windows containers on Docker on Windows Server 2016?
|
||||
|
||||
See [About Windows containers and Windows Server
|
||||
2016](index.md#about-windows-containers-and-windows-server-2016).
|
||||
|
||||
A full tutorial is available in [docker/labs](https://github.com/docker/labs) at
|
||||
[Getting Started with Windows
|
||||
Containers](https://github.com/docker/labs/blob/master/windows/windows-containers/README.md).
|
||||
|
||||
### Why is Windows 10 Home not supported?
|
||||
|
||||
Docker for Windows requires the Hyper-V Windows feature which is not
|
||||
|
|
Binary file not shown.
After Width: | Height: | Size: 41 KiB |
Binary file not shown.
After Width: | Height: | Size: 37 KiB |
|
@ -5,6 +5,7 @@ aliases:
|
|||
- /windows/
|
||||
- /windows/started/
|
||||
- /docker-for-windows/started/
|
||||
- /installation/windows/
|
||||
description: Getting Started
|
||||
keywords:
|
||||
- windows, beta, alpha, tutorial
|
||||
|
@ -24,7 +25,6 @@ Please read through these topics on how to get started. To **give us your feedba
|
|||
|
||||
>**Already have Docker for Windows?** If you already have Docker for Windows installed, and are ready to get started, skip over to the [Getting Started with Docker](/engine/getstarted/index.md) tutorial.
|
||||
|
||||
|
||||
## Download Docker for Windows
|
||||
|
||||
If you have not already done so, please install Docker for Windows. You can download installers from the stable or beta channel. For more about stable and beta channels, see the [FAQs](faqs.md#questions-about-stable-and-beta-channels).
|
||||
|
@ -51,25 +51,61 @@ If you have not already done so, please install Docker for Windows. You can down
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
>**Important Notes**:
|
||||
>**Important Notes:**
|
||||
>
|
||||
>* Docker for Windows requires 64bit Windows 10 Pro, Enterprise and Education (1511 November update, Build 10586 or later) and Microsoft Hyper-V. Please see [What to know before you install](index.md#what-to-know-before-you-install) for a full list of prerequisites.
|
||||
>- Docker for Windows requires 64bit Windows 10 Pro, Enterprise and Education
|
||||
> (1511 November update, Build 10586 or later) and Microsoft Hyper-V. Please
|
||||
> see [What to know before you install](index.md#what-to-know-before-you-install)
|
||||
> for a full list of prerequisites.
|
||||
>
|
||||
>* <font color="#CC3366">You can switch between beta and stable versions, but _you must have only one app installed at a time_.</font> Also, you will need to save images and export containers you want to keep before uninstalling the current version before installing another. For more about this, see the [FAQs about beta and stable channels](faqs.md#questions-about-stable-and-beta-channels).
|
||||
>- You can switch between beta and stable versions, but you must have only one
|
||||
> app installed at a time. Also, you will need to save images and export
|
||||
> containers you want to keep before uninstalling the current version before
|
||||
> installing another. For more about this, see the
|
||||
> [FAQs about beta and stable channels](faqs.md#questions-about-stable-and-beta-channels).
|
||||
|
||||
## What to know before you install
|
||||
|
||||
* **README FIRST for Docker Toolbox and Docker Machine users**: Docker for Windows requires Microsoft Hyper-V to run. After Hyper-V is enabled, VirtualBox will no longer work, but any VirtualBox VM images will remain. VirtualBox VMs created with `docker-machine` (including the `default` one typically created during Toolbox install) will no longer start. These VMs cannot be used side-by-side with Docker for Windows. However, you can still use `docker-machine` to manage remote VMs.
|
||||
|
||||
* **README FIRST for Docker Toolbox and Docker Machine users**: Docker for Windows requires Microsoft Hyper-V to run. After Hyper-V is enabled,
|
||||
VirtualBox will no longer work, but any VirtualBox VM images will remain.
|
||||
VirtualBox VMs created with `docker-machine` (including the `default` one
|
||||
typically created during Toolbox install) will no longer start. These VMs cannot
|
||||
be used side-by-side with Docker for Windows. However, you can still use
|
||||
`docker-machine` to manage remote VMs.
|
||||
<p />
|
||||
* The current version of Docker for Windows runs on 64bit Windows 10 Pro, Enterprise and Education (1511 November update, Build 10586 or later). In the future we will support more versions of Windows 10.
|
||||
<p />
|
||||
* Containers and images created with Docker for Windows are shared between all user accounts on machines where it is installed. This is because all
|
||||
Windows accounts will use the same VM to build and run containers. In the
|
||||
future, Docker for Windows will better isolate user content.
|
||||
<p />
|
||||
* The Hyper-V package must be enabled for Docker for Windows to work. The Docker for Windows installer will enable it for you, if needed. (This requires a
|
||||
reboot). If your system does not satisfy these requirements, you can install
|
||||
[Docker Toolbox](/toolbox/overview.md), which uses Oracle Virtual Box instead of
|
||||
Hyper-V.
|
||||
<p />
|
||||
* Virtualization must be enabled. Typically, virtualization is enabled by default. (Note that this is different from having Hyper-V enabled.) For more
|
||||
detail see [Virtualization must be
|
||||
enabled](troubleshoot.md#virtualization-must-be-enabled) in Troubleshooting.
|
||||
<p />
|
||||
* **What the Docker for Windows install includes**: The installation provides [Docker Engine](https://docs.docker.com/engine/userguide/intro/), Docker CLI client, [Docker Compose](https://docs.docker.com/compose/overview/), and [Docker Machine](https://docs.docker.com/machine/overview/).
|
||||
|
||||
* Containers and images created with Docker for Windows are shared between all user accounts on machines where it is installed. This is because all Windows accounts will use the same VM to build and run containers. In the future, Docker for Windows will better isolate user content.
|
||||
### About Windows containers and Windows Server 2016
|
||||
|
||||
* The Hyper-V package must be enabled for Docker for Windows to work. The Docker for Windows installer will enable it for you, if needed. (This requires a reboot).
|
||||
Looking for information on using Windows containers?
|
||||
|
||||
>**Note**: If your system does not satisfy these requirements, you can install [Docker Toolbox](/toolbox/overview.md), which uses Oracle Virtual Box instead of Hyper-V.
|
||||
|
||||
* **What the install includes**: The installation provides [Docker Engine](https://docs.docker.com/engine/userguide/intro/), Docker CLI client, [Docker Compose](https://docs.docker.com/compose/overview/), and [Docker Machine](https://docs.docker.com/machine/overview/).
|
||||
* [Getting Started with Windows Containers (Lab)](https://github.com/docker/labs/blob/master/windows/windows-containers/README.md)
|
||||
provides a tutorial on how to set up and run Windows containers on Windows 10 or
|
||||
with Windows Server 2016. It shows you how to use a MusicStore application with
|
||||
Windows containers.
|
||||
<p />
|
||||
* [Setup - Windows Server 2016 (Lab)](https://github.com/docker/labs/blob/master/windows/windows-containers/Setup-Server2016.md) specifically describes environment setup.
|
||||
<p />
|
||||
* [Switch
|
||||
between Windows and Linux containers (Beta
|
||||
feature)](index.md#switch-between-windows-and-linux-containers-beta-feature) describes the Linux / Windows containers toggle in Docker for Windows and points you to the tutorial mentioned above.
|
||||
<p />
|
||||
* Docker Container Platform for Windows Server 2016 [articles and blog posts](https://www.docker.com/microsoft) on the Docker website
|
||||
|
||||
## Step 1. Install Docker for Windows
|
||||
|
||||
|
@ -301,6 +337,21 @@ Permissions to access shared drives are tied to the credentials you provide here
|
|||
|
||||
See also [Verify domain user has permissions for shared drives](troubleshoot.md#verify-domain-user-has-permissions-for-shared-drives-volumes) in Troubleshooting.
|
||||
|
||||
#### Firewall rules for shared drives
|
||||
|
||||
Shared drives require port 445 to be open between the host machine and the virtual
|
||||
machine that runs Linux containers.
|
||||
|
||||
>**Note**: In Docker for Windows Beta 29 and higher,
|
||||
Docker detects if port 445 is closed and shows the following message when you
|
||||
try to add a shared drive: 
|
||||
|
||||
|
||||
To share the drive, allow connections between the Windows host machine and the
|
||||
virtual machine in Windows Firewall or your third party firewall software. You
|
||||
do not need to open port 445 on any other network. By default, allow connections
|
||||
to 10.0.75.1 port 445 (the Windows host) from 10.0.75.2 (the virtual machine).
|
||||
|
||||
### Advanced
|
||||
|
||||

|
||||
|
@ -347,12 +398,12 @@ no_proxy=*.local, 169.254/16
|
|||
|
||||
You can see from the above output that the `HTTP_PROXY`, `http_proxy` and `no_proxy` environment variables are set.
|
||||
When your proxy configuration changes, Docker restarts automatically to pick up the new settings.
|
||||
If you have containers that you wish to keep running across restarts, you should consider using [restart policies](https://docs.docker.com/engine/reference/run/#restart-policies-restart)
|
||||
If you have containers that you wish to keep running across restarts, you should consider using [restart policies](/engine/reference/run/#restart-policies-restart)
|
||||
|
||||
### Docker daemon
|
||||
You can configure options on the Docker daemon in the given JSON configuration file, and determine how your containers will run.
|
||||
|
||||
For a full list of options on the Docker daemon, see <a href="https://docs.docker.com/engine/reference/commandline/daemon/" target="_blank">daemon</a> in the Docker Engine command line reference.
|
||||
For a full list of options on the Docker daemon, see <a href="https://docs.docker.com/engine/reference/commandline/dockerd/" target="_blank">daemon</a> in the Docker Engine command line reference.
|
||||
|
||||

|
||||
|
||||
|
@ -368,6 +419,16 @@ This feature is not yet available on stable builds.
|
|||
|
||||
See also [Shared Drives](#shared-drives)
|
||||
|
||||
#### Getting started with Windows containers (Beta feature)
|
||||
|
||||
If you are interested in working with Windows containers, here are some guides to help you get started.
|
||||
|
||||
* [Build and Run Your First Windows Server Container (Blog Post)](https://blog.docker.com/2016/09/build-your-first-docker-windows-server-container/) gives a quick tour of how to build and run native Docker Windows containers on Windows 10 and Windows Server 2016 evaluation releases.
|
||||
|
||||
* [Getting Started with Windows Containers (Lab)](https://github.com/docker/labs/blob/master/windows/windows-containers/README.md) shows you how to use the [MusicStore](https://github.com/aspnet/MusicStore/blob/dev/README.md) application with Windows containers. The MusicStore is a standard .NET application and, [forked here to use containers](https://github.com/friism/MusicStore), is a good example of a multi-container application.
|
||||
|
||||
>**Disclaimer:** This lab is still in work, and is based off of the blog, but you can test and leverage the example walkthroughs now, if you want to start experimenting. Please checking back as the lab evolves.
|
||||
|
||||
### Diagnose and Feedback
|
||||
|
||||
If you encounter problems for which you do not find solutions in this documentation, searching [Docker for Windows issues on GitHub](https://github.com/docker/for-win/issues) already filed by other users, or on the [Docker for Windows forum](https://forums.docker.com/c/docker-for-windows), we can help you troubleshoot the log data.
|
||||
|
|
|
@ -1,13 +0,0 @@
|
|||
---
|
||||
aliases: []
|
||||
description: Docker Windows
|
||||
keywords:
|
||||
- docker, windows, desktop, editions
|
||||
menu:
|
||||
main:
|
||||
identifier: pinata_win_menu
|
||||
weight: -78
|
||||
title: Docker for Windows
|
||||
---
|
||||
|
||||
# Docker for Mac and Docker for Windows
|
|
@ -12,7 +12,7 @@ title: Open Source Licensing
|
|||
|
||||
# Open Source Components and Licensing
|
||||
|
||||
Docker Desktop Editions are built using open source software software. For details on the licensing, choose <img src="../images/whale-x.png"> --> **About** from within the application, then click **Acknowledgements**.
|
||||
Docker Desktop Editions are built using open source software software. For details on the licensing, choose <img src="../images/whale-x.png"> --> **About** from within the application, then click **Acknowledgements**.
|
||||
|
||||
Docker Desktop Editions distribute some components that are licensed under the GNU General Public License. You can download the source for these components [here](https://download.docker.com/opensource/License.tar.gz).
|
||||
|
||||
|
|
|
@ -132,6 +132,99 @@ Release notes for _stable_ and _beta_ releases are listed below. You can learn a
|
|||
|
||||
## Beta Release Notes
|
||||
|
||||
### Beta 29.3 Release Notes (2016-11-02 1.12.3-beta29.3)
|
||||
|
||||
**Upgrades**
|
||||
|
||||
- Docker Compose 1.9.0-rc2
|
||||
|
||||
### Beta 29.2 Release Notes (2016-10-27 1.12.2-beta29.2)
|
||||
|
||||
**Hotfixes**
|
||||
|
||||
- Upgrade to Docker 1.12.3
|
||||
|
||||
### Beta 29.1 Release Notes (2016-10-26 1.12.1-beta29.1)
|
||||
|
||||
**Hotfixes**
|
||||
|
||||
- Fixed missing `/dev/pty/ptmx`
|
||||
|
||||
### Beta 29 Release Notes (2016-10-25 1.12.3-rc1-beta29)
|
||||
|
||||
>**Important Note**:
|
||||
>
|
||||
> The auto-update function in Beta 21 will not be able to install this update. To install the latest beta manually if you are still on Beta 21, please download the installer here:
|
||||
|
||||
> [https://download.docker.com/win/beta/InstallDocker.msi](https://download.docker.com/win/beta/InstallDocker.msi)
|
||||
|
||||
> This problem is fixed as of Beta 23 for subsequent auto-updates.
|
||||
>
|
||||
Windows Container support relies on the Windows 10 container feature, which is
|
||||
**experimental** at this point. Windows 10 Pro (1607, build number 14393)
|
||||
requires update `KB3192366` (soon to be released via Windows Update) to fully
|
||||
work. Some insider builds may not work.
|
||||
|
||||
**New**
|
||||
|
||||
- Restore the VM's configuration when it was changed by the user
|
||||
- Overlay2 is now the default storage driver. After a factory reset overlay2 will automatically be used
|
||||
- Detect firewall configuration that might block the file sharing
|
||||
- Send more GUI usage statistics to help us improve the product
|
||||
|
||||
**Upgrades**
|
||||
|
||||
- Docker 1.12.3-rc1
|
||||
- Linux Kernel 4.4.27
|
||||
|
||||
**Bug fixes and minor changes**
|
||||
|
||||
- Faster mount/unmount of shared drives
|
||||
- Added a timeout to mounting/unmounting a shared drive
|
||||
- Add the settings to the diagnostics
|
||||
- Increase default ulimit for memlock (fixes https://github.com/docker/for-mac/issues/801)
|
||||
- Make sure we don't use an older Nlog library from the GAC
|
||||
|
||||
|
||||
### Beta 28 Release Notes (2016-10-13 1.12.2-rc3-beta28)
|
||||
|
||||
>**Important Note**:
|
||||
>
|
||||
> The auto-update function in Beta 21 will not be able to install this update. To install the latest beta manually if you are still on Beta 21, please download the installer here:
|
||||
|
||||
> [https://download.docker.com/win/beta/InstallDocker.msi](https://download.docker.com/win/beta/InstallDocker.msi)
|
||||
|
||||
> This problem is fixed as of Beta 23 for subsequent auto-updates.
|
||||
>
|
||||
Windows Container support relies on the Windows 10 container feature, which is
|
||||
**experimental** at this point. Windows 10 Pro (1607, build number 14393)
|
||||
requires update `KB3192366` (soon to be released via Windows Update) to fully
|
||||
work. Some insider builds may not work.
|
||||
|
||||
**New**
|
||||
|
||||
- Path to HyperV disks in no longer hardcoded, making the Toolbox import work with non-standard path
|
||||
- Verify that ALL HyperV features are enabled
|
||||
- Make it clear why user cannot switch to Windows Containers with a tooltip in the systray
|
||||
- Added Moby console to the logs
|
||||
- Save the current engine with the other settings
|
||||
- Notary version 0.4.2 installed
|
||||
|
||||
|
||||
**Upgrades**
|
||||
|
||||
- Docker 1.12.2
|
||||
- Kernel 4.4.24
|
||||
|
||||
**Bug fixes and minor changes**
|
||||
|
||||
- Fixed a password escaping regression
|
||||
- Support writing large values to the database, especially for trusted CAs
|
||||
- VpnKit is now restarted if it dies
|
||||
- Make sure invalid "DockerNat" switches are not used
|
||||
- Preserve the Powershell stacktraces
|
||||
- Write OS and Application versions at the top of each log file
|
||||
|
||||
### Beta 27 Release Notes (2016-09-28 1.12.2-rc1-beta27)
|
||||
|
||||
>**Important Note**:
|
||||
|
@ -814,8 +907,8 @@ are working on a solution.
|
|||
- Rename `console` to `debug console`
|
||||
- Remove `machine` from notification
|
||||
- Open the feedback forum
|
||||
- Use same MixPanel project for Windows and OSX
|
||||
- Align MixPanel events with OSX
|
||||
- Use same MixPanel project for Windows and macOS
|
||||
- Align MixPanel events with macOS
|
||||
- Added a script to diagnose problems
|
||||
- Submit diagnostic with bugsnag reports
|
||||
- MixPanel heartbeat every hour
|
||||
|
|
|
@ -22,7 +22,7 @@ Here is information about how to diagnose and troubleshoot problems, send logs a
|
|||
|
||||
## Submitting diagnostics, feedback, and GitHub issues
|
||||
|
||||
If you encounter problems for which you do not find solutions in this documentation, on [Docker for Windows issues on GitHub](https://github.com/docker/for-win/issues), or the [Docker for Windows forum](https://forums.docker.com/c/docker-for-windows), we can help you troubleshoot the log data. See [Diagnose and Feedback](index.md#diagnose-and-feedback) to learn about diagnostics and how to create new issues on GitHub.
|
||||
If you encounter problems for which you do not find solutions in this documentation, on [Docker for Windows issues on GitHub](https://github.com/docker/for-win/issues), or the [Docker for Windows forum](https://forums.docker.com/c/docker-for-windows), we can help you troubleshoot the log data. See [Diagnose and Feedback](index.md#diagnose-and-feedback) to learn about diagnostics and how to create new issues on GitHub.
|
||||
|
||||
## Checking the Logs
|
||||
|
||||
|
@ -97,7 +97,7 @@ Symlinks will work within and across containers. However, symlinks created outsi
|
|||
|
||||
Any file destined to run inside a container must use Unix style `\n` line endings. This includes files referenced at the command line for builds and in RUN commands in Docker files.
|
||||
|
||||
Docker containers and `docker build` run in a Unix environment, so files in containers must use Unix style line endings `\n`, _not_ Windows style: `\r\n`. Keep this in mind when authoring files such as shell scripts using Windows tools, where the default is likely to be Windows style line endings. These commands ultimately get passed to Unix commands inside a Unix based container (for example, a shell script passed to `/bin/sh`). If Windows style line endings are used, `docker run` will fail with syntax errors.
|
||||
Docker containers and `docker build` run in a Unix environment, so files in containers must use Unix style line endings: `\n`, _not_ Windows style: `\r\n`. Keep this in mind when authoring files such as shell scripts using Windows tools, where the default is likely to be Windows style line endings. These commands ultimately get passed to Unix commands inside a Unix based container (for example, a shell script passed to `/bin/sh`). If Windows style line endings are used, `docker run` will fail with syntax errors.
|
||||
|
||||
For an example of this issue and the resolution, see this issue on GitHub: <a href="https://github.com/docker/docker/issues/24388" target="_blank">Docker RUN fails to execute shell script (https://github.com/docker/docker/issues/24388)</a>.
|
||||
|
||||
|
@ -160,7 +160,52 @@ To fix existing containers, follow these steps.
|
|||
```
|
||||
|
||||
### Hyper-V
|
||||
Docker for Windows requires a Hyper-V as well as the Hyper-V Module for Windows Powershell to be installed and enabled. See [these instructions](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install) to install Hyper-V manually. A reboot is *required*. If you install Hyper-V without the reboot, Docker for Windows will not work correctly. On some systems, Virtualization needs to be enabled in the BIOS. The steps to do so are Vendor specific, but typically the BIOS option is called `Virtualization Technology (VTx)` or similar.
|
||||
|
||||
Docker for Windows requires a Hyper-V as well as the Hyper-V Module for Windows
|
||||
Powershell to be installed and enabled. The Docker for Windows installer will
|
||||
enable it for you.
|
||||
|
||||
See [these
|
||||
instructions](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
|
||||
to install Hyper-V manually. A reboot is *required*. If you install Hyper-V
|
||||
without the reboot, Docker for Windows will not work correctly. On some systems,
|
||||
Virtualization needs to be enabled in the BIOS. The steps to do so are Vendor
|
||||
specific, but typically the BIOS option is called `Virtualization Technology
|
||||
(VTx)` or similar.
|
||||
|
||||
### Virtualization must be enabled
|
||||
|
||||
In addition to [Hyper-V](#hyper-v), virtualization must be enabled.
|
||||
|
||||
If, at some point, if you manually uninstall Hyper-V or disable virtualization, Docker for Windows will not start.
|
||||
|
||||
Verify that virtualization is enabled on Task Manager.
|
||||
|
||||

|
||||
|
||||
See also, the user reported issue [Unable to run Docker for Windows on Windows
|
||||
10 Enterprise](https://github.com/docker/for-win/issues/74)
|
||||
|
||||
### Windows containers and Windows Server 2016
|
||||
|
||||
If you have questions about how to set up and run Windows containers on Windows
|
||||
Server 2016 or Windows 10, see [About Windows containers and Windows Server
|
||||
2016](index.md#about-windows-containers-and-windows-server-2016).
|
||||
|
||||
A full tutorial is available in [docker/labs](https://github.com/docker/labs) at
|
||||
[Getting Started with Windows
|
||||
Containers](https://github.com/docker/labs/blob/master/windows/windows-containers/README.md).
|
||||
|
||||
You can install a native Windows binary which allows you to develop and run
|
||||
Windows containers without Docker for Windows. However, if you install Docker
|
||||
this way, you cannot develop or run Linux containers. If you try to run a Linux
|
||||
container on the native Docker daemon, an error occurs:
|
||||
|
||||
```no-highlight
|
||||
C:\Program Files\Docker\docker.exe:
|
||||
image operating system "linux" cannot be used on this platform.
|
||||
See 'C:\Program Files\Docker\docker.exe run --help'.
|
||||
```
|
||||
|
||||
### Networking issues
|
||||
|
||||
|
|
|
@ -34,12 +34,12 @@ to create a Docker Hub repository from which to create the Automatic Build.
|
|||
## Creating an Automated Build
|
||||
|
||||
You can [create an Automated Build](
|
||||
https://hub.docker.com/add/automated-build/bitbucket/orgs/) from any of your
|
||||
https://hub.docker.com/add/automated-build/bitbucket/) from any of your
|
||||
public or private Bitbucket repositories with a `Dockerfile`.
|
||||
|
||||
To get started, log in to Docker Hub and click the
|
||||
"Create ▼" menu item at the top right of the screen. Then select
|
||||
[Create Automated Build](https://hub.docker.com/add/automated-build).
|
||||
[Create Automated Build](https://hub.docker.com/add/automated-build/bitbucket/).
|
||||
|
||||
Select the the linked Bitbucket account, and then choose a repository to set up
|
||||
an Automated Build for.
|
||||
|
|
|
@ -16,8 +16,7 @@ You can build your images automatically from a build context stored in a reposit
|
|||
Automated Builds have several advantages:
|
||||
|
||||
* Images built in this way are built exactly as specified.
|
||||
* The `Dockerfile` is available to anyone with access to
|
||||
your Docker Hub repository.
|
||||
* The `Dockerfile` is available to anyone with access to your Docker Hub repository.
|
||||
* Your repository is kept up-to-date with code changes automatically.
|
||||
|
||||
Automated Builds are supported for both public and private repositories
|
||||
|
@ -27,15 +26,22 @@ on both [GitHub](http://github.com) and [Bitbucket](https://bitbucket.org/). Thi
|
|||
|
||||
To use automated builds you must have an [account on Docker Hub](accounts.md) and on the hosted repository provider (GitHub or Bitbucket). If
|
||||
you have previously linked your Github or Bitbucket account, you must have
|
||||
chosen the Public and Private connection type. To view your current connection
|
||||
settings, log in to Docker Hub and choose <a href="https://hub.docker.com/account/authorized-services/" target=\_blank>Profile > Settings > Linked Accounts & Services</a>.
|
||||
chosen the Public and Private connection type.
|
||||
|
||||
To view your current connection
|
||||
settings, log in to Docker Hub and choose **Profile > Settings > Linked Accounts & Services**.
|
||||
|
||||
## Limitations
|
||||
|
||||
Currently Docker Hub does not support Git LFS (Large File Storage). If you have binaries in your build context that are managed by Git LFS, only the pointer file will be present in the clone made during the automated build, which is not what you want.
|
||||
|
||||
Subscribe to the [GitHub issue](https://github.com/docker/hub-feedback/issues/500) tracking this limitation.
|
||||
|
||||
## Link to a hosted repository service
|
||||
|
||||
1. Log into Docker Hub.
|
||||
|
||||
2. Navigate to <a href="https://hub.docker.com/account/authorized-services/" target=\_blank>Profile > Settings > Linked Accounts & Services</a>.
|
||||
2. Navigate to **Profile > Settings > Linked Accounts & Services**.
|
||||
|
||||
3. Click the service you want to link.
|
||||
|
||||
|
@ -125,17 +131,16 @@ build request, Docker ignores new requests.
|
|||
|
||||
### Build statuses explained
|
||||
|
||||
Check your build status through the Build Details screen as seen in the following example.
|
||||
You can view the status of the builds for a specific repository by looking at the Build Details screen. If you have builds that are queued or in progress, you can click **Cancel** to end them.
|
||||
|
||||

|
||||
|
||||
The statuses are:
|
||||
|
||||
* **Queued**: You're in line and your image will be built soon. Queue time varies depending on number of concurrent builds available to you.
|
||||
* **Building**: Your image is currently being constructed.
|
||||
* **Building**: The image is being built.
|
||||
* **Success**: The image has been built with no issues.
|
||||
* **Error**: There was an issue with your image. Click the row to access the Builds Details screen. The banner at the top of the page displays the last sentence of the log file indicating what the error was. If you need more information, scroll to the bottom of the screen to the logs section.
|
||||
|
||||
* **Error**: There was an issue with your image. Click the row to go to the Builds Details screen. The banner at the top of the page displays the last sentence of the log file, which indicates what the error was. If you need more information, scroll to the bottom of the screen to the logs section.
|
||||
|
||||
## Use the Build Settings page
|
||||
|
||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 114 KiB After Width: | Height: | Size: 85 KiB |
|
@ -15,7 +15,7 @@ title: Overview of Docker Hub
|
|||
|
||||
[Docker Hub](https://hub.docker.com) is a cloud-based registry service which
|
||||
allows you to link to code repositories, build your images and test them, stores
|
||||
manually pushed images, and links to [Docker Cloud](https://docs.docker.com/docker-cloud/) so you can deploy images to your
|
||||
manually pushed images, and links to [Docker Cloud](/docker-cloud/) so you can deploy images to your
|
||||
hosts. It provides a centralized resource for container image discovery,
|
||||
distribution and change management, [user and team collaboration](orgs.md), and
|
||||
workflow automation throughout the development pipeline.
|
||||
|
@ -61,7 +61,7 @@ the repositories you can access and their status, view your "Dashboard" page on
|
|||
[Docker Hub](https://hub.docker.com).
|
||||
|
||||
|
||||
You can find more information on working with Docker images in the [Docker userguide](https://docs.docker.com/userguide/dockerimages/).
|
||||
You can find more information on working with Docker images in the [Docker userguide](/userguide/dockerimages/).
|
||||
|
||||
### Use Official Repositories
|
||||
|
||||
|
@ -90,5 +90,5 @@ You can create public repositories which can be accessed by any other Hub user,
|
|||
|
||||
### Docker commands and Docker Hub
|
||||
|
||||
Docker itself provides access to Docker Hub services via the [`docker search`](http://docs.docker.com/reference/commandline/search),
|
||||
[`pull`](http://docs.docker.com/reference/commandline/pull), [`login`](http://docs.docker.com/reference/commandline/login), and [`push`](http://docs.docker.com/reference/commandline/push) commands.
|
||||
Docker itself provides access to Docker Hub services via the [`docker search`](/reference/commandline/search),
|
||||
[`pull`](/reference/commandline/pull), [`login`](/reference/commandline/login), and [`push`](/reference/commandline/push) commands.
|
||||
|
|
|
@ -1,13 +0,0 @@
|
|||
---
|
||||
description: this is a menu
|
||||
keywords: none
|
||||
menu:
|
||||
main:
|
||||
identifier: mn_pubhub
|
||||
title: Docker Hub
|
||||
type: menu
|
||||
---
|
||||
|
||||
# Menu topic
|
||||
|
||||
If you can view this content, please raise a bug report.
|
|
@ -24,7 +24,7 @@ curated set of Docker repositories that are promoted on Docker Hub. They are des
|
|||
stores, and other services, similar to what a Platform-as-a-Service (PAAS)
|
||||
would offer.
|
||||
|
||||
* Exemplify [`Dockerfile` best practices](https://docs.docker.com/articles/dockerfile_best-practices)
|
||||
* Exemplify [`Dockerfile` best practices](/articles/dockerfile_best-practices)
|
||||
and provide clear documentation to serve as a reference for other `Dockerfile`
|
||||
authors.
|
||||
|
||||
|
@ -72,7 +72,7 @@ these efforts.
|
|||
|
||||
## How do I know the Official Repositories are secure?
|
||||
|
||||
Docker provides a preview version of Docker Cloud's [Security Scanning service](http://docs.docker.com/docker-cloud/builds/image-scan/) for all of the
|
||||
Docker provides a preview version of Docker Cloud's [Security Scanning service](/docker-cloud/builds/image-scan/) for all of the
|
||||
Official Repositories located on Docker Hub. These security scan results provide
|
||||
valuable information about which images contain security vulnerabilities, which
|
||||
you should use to help you choose secure components for your own projects.
|
||||
|
|
|
@ -102,7 +102,7 @@ You can name your local images either when you build it, using
|
|||
by re-tagging an existing local image `docker tag <existing-image> <hub-user>/<repo-name>[:<tag>]`,
|
||||
or by using `docker commit <exiting-container> <hub-user>/<repo-name>[:<tag>]` to commit
|
||||
changes.
|
||||
See [Working with Docker images](https://docs.docker.com/userguide/dockerimages) for a detailed description.
|
||||
See [Working with Docker images](/userguide/dockerimages) for a detailed description.
|
||||
|
||||
Now you can push this repository to the registry designated by its name or tag.
|
||||
|
||||
|
|
|
@ -31,8 +31,8 @@ With your webhook, you specify a target URL and a JSON payload to deliver. The e
|
|||
"comment_count": "0",
|
||||
"date_created": 1.417494799e+09,
|
||||
"description": "",
|
||||
"dockerfile": "#\n# BUILD\u0009\u0009docker build -t svendowideit/apt-cacher .\n# RUN\u0009\u0009docker run -d -p 3142:3142 -name apt-cacher-run apt-cacher\n#\n# and then you can run containers with:\n# \u0009\u0009docker run -t -i -rm -e http_proxy http://192.168.1.2:3142/ debian bash\n#\nFROM\u0009\u0009ubuntu\nMAINTAINER\u0009SvenDowideit@home.org.au\n\n\nVOLUME\u0009\u0009[\/var/cache/apt-cacher-ng\]\nRUN\u0009\u0009apt-get update ; apt-get install -yq apt-cacher-ng\n\nEXPOSE \u0009\u00093142\nCMD\u0009\u0009chmod 777 /var/cache/apt-cacher-ng ; /etc/init.d/apt-cacher-ng start ; tail -f /var/log/apt-cacher-ng/*\n,
|
||||
full_description: Docker Hub based automated build from a GitHub repo",
|
||||
"dockerfile": "#\n# BUILD\u0009\u0009docker build -t svendowideit/apt-cacher .\n# RUN\u0009\u0009docker run -d -p 3142:3142 -name apt-cacher-run apt-cacher\n#\n# and then you can run containers with:\n# \u0009\u0009docker run -t -i -rm -e http_proxy http://192.168.1.2:3142/ debian bash\n#\nFROM\u0009\u0009ubuntu\nMAINTAINER\u0009SvenDowideit@home.org.au\n\n\nVOLUME\u0009\u0009[\/var/cache/apt-cacher-ng\]\nRUN\u0009\u0009apt-get update ; apt-get install -yq apt-cacher-ng\n\nEXPOSE \u0009\u00093142\nCMD\u0009\u0009chmod 777 /var/cache/apt-cacher-ng ; /etc/init.d/apt-cacher-ng start ; tail -f /var/log/apt-cacher-ng/*\n",
|
||||
"full_description": "Docker Hub based automated build from a GitHub repo",
|
||||
"is_official": false,
|
||||
"is_private": true,
|
||||
"is_trusted": true,
|
||||
|
|
|
@ -1,12 +0,0 @@
|
|||
---
|
||||
description: Docker Store menu
|
||||
keywords:
|
||||
- Docker, docker, store, purchase images
|
||||
menu:
|
||||
main:
|
||||
identifier: docker-store
|
||||
title: Docker Store
|
||||
type: menu
|
||||
---
|
||||
|
||||
If you can see this page, please file a bug by emailing docs@docker.com
|
|
@ -53,8 +53,10 @@ Additionally, the Trusted Registry supports these cloud-based storage drivers:
|
|||
|
||||
### Filesystem
|
||||
|
||||
Use of the `filesystem` storage driver is incompatible when deploying DTR in High Availability with multiple replicas.
|
||||
|
||||
If you select `filesystem`, then the Trusted Registry uses the local disk to
|
||||
store registry files. This backend has a single, required `rootdirectory`
|
||||
store registry files. This backend has a single, required `rootdirectory`
|
||||
parameter which specifies a subdirectory of `/var/local/dtr/imagestorage` in
|
||||
which all registry files are stored. The default value of `/local` means the
|
||||
files are stored in `/var/local/dtr/image-storage/local`.
|
||||
|
|
|
@ -74,7 +74,7 @@ $ docker run -i --rm docker/dtr backup \
|
|||
--ucp-ca "$(cat ucp-ca.pem)" \
|
||||
--existing-replica-id <replica-id> \
|
||||
--ucp-username <ucp-admin> \
|
||||
--ucp-password <ucp-password> > /tmp/backup.tar
|
||||
--ucp-password <ucp-password> > /var/tmp/backup.tar
|
||||
```
|
||||
|
||||
Where:
|
||||
|
@ -109,8 +109,8 @@ consideration whether your DTR installation is configured to store images on
|
|||
the filesystem or using a cloud provider.
|
||||
|
||||
You can check the
|
||||
[reference documentation](../reference/backup.md), for the
|
||||
backup command to learn about all the available flags.
|
||||
[reference documentation](../reference/restore.md), for the
|
||||
restore command to learn about all the available flags.
|
||||
|
||||
|
||||
As an example, to install DTR on the host and restore its
|
||||
|
@ -127,7 +127,7 @@ $ docker run -i --rm \
|
|||
--ucp-ca "$(cat ucp-ca.pem)" \
|
||||
--ucp-username <ucp-admin> \
|
||||
--ucp-password <ucp-password> \
|
||||
--dtr-load-balancer <dtr-domain-name> < /tmp/backup.tar
|
||||
--dtr-external-url <dtr-domain-name> < /var/tmp/backup.tar
|
||||
```
|
||||
|
||||
Where:
|
||||
|
@ -135,7 +135,7 @@ Where:
|
|||
* `--ucp-url` is the address of UCP,
|
||||
* `--ucp-ca` is the UCP certificate authority,
|
||||
* `--ucp-username`, and `--ucp-password` are the credentials of a UCP administrator,
|
||||
* `--dtr-load-balancer` is the domain name or ip where DTR can be reached.
|
||||
* `--dtr-external-url` is the domain name or ip where DTR can be reached.
|
||||
|
||||
|
||||
## Where to go next
|
||||
|
|
|
@ -82,7 +82,7 @@ or cloud-based load balancer to balance requests across multiple DTR replicas.
|
|||
Make sure you configure your load balancer to:
|
||||
|
||||
* Load-balance TCP traffic on ports 80 and 443,
|
||||
* Not terminate HTTPS connections,
|
||||
* Use a TCP load balancer that doesn't terminate HTTPS connections,
|
||||
* Use the `/load_balancer_status` endpoint on each DTR replica, to check if
|
||||
the replica is healthy and if it should remain on the load balancing pool or
|
||||
not.
|
||||
|
|
|
@ -1,14 +0,0 @@
|
|||
---
|
||||
description: Learn how to set up Docker Trusted Registry for high availability.
|
||||
keywords:
|
||||
- docker, registry, high-availability, backup, recovery
|
||||
menu:
|
||||
main:
|
||||
identifier: dtr_menu_high_availability
|
||||
parent: workw_dtr
|
||||
weight: 70
|
||||
title: High-availability
|
||||
type: menu
|
||||
---
|
||||
|
||||
<![end-metadata]-->
|
|
@ -32,7 +32,7 @@ infrastructure has all the [requirements DTR needs to run](system-requirements.m
|
|||
|
||||
Since DTR requires a Docker Universal Control Plane (UCP) cluster
|
||||
to run, you need to install UCP first.
|
||||
[Learn how to install UCP](https://docs.docker.com/ucp/installation/install-production/). Make sure that the node you install DTR on is already joined to the UCP cluster.
|
||||
[Learn how to install UCP](/ucp/installation/install-production/). Make sure that the node you install DTR on is already joined to the UCP cluster.
|
||||
|
||||
|
||||
## Step 3. Install DTR
|
||||
|
@ -46,7 +46,7 @@ To install DTR:
|
|||
|
||||
Having a UCP client bundle allows you to run Docker commands on a UCP
|
||||
cluster.
|
||||
[Download a UCP client bundle](https://docs.docker.com/ucp/access-ucp/cli-based-access/)
|
||||
[Download a UCP client bundle](/ucp/access-ucp/cli-based-access/)
|
||||
and set up your CLI client to use it.
|
||||
|
||||
2. Run the following command to install DTR.
|
||||
|
|
|
@ -26,7 +26,7 @@ copy that package to the nodes where you’ll install DTR.
|
|||
Use a computer with internet access to download a single package with all
|
||||
Docker Datacenter components:
|
||||
|
||||
```bash
|
||||
```none
|
||||
$ wget https://packages.docker.com/caas/ucp-1.1.2_dtr-2.0.3.tar.gz -O docker-datacenter.tar.gz
|
||||
```
|
||||
|
||||
|
@ -36,7 +36,7 @@ copy that package to the nodes where you’ll install DTR.
|
|||
want to install Docker Trusted Registry. You can use the `scp` command
|
||||
for this.
|
||||
|
||||
```bash
|
||||
```none
|
||||
$ scp docker-datacenter.tag.gz $USER@$DTR_HOST:/tmp
|
||||
```
|
||||
|
||||
|
@ -47,7 +47,7 @@ copy that package to the nodes where you’ll install DTR.
|
|||
Once the package is on the node where you want to install DTR, you can use
|
||||
the `docker load` command, to load the images from the .tar file.
|
||||
|
||||
```bash
|
||||
```none
|
||||
$ docker load < /tmp/docker-datacenter.tar.gz
|
||||
```
|
||||
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue