mirror of
https://github.com/docker/docs.git
synced 2026-11-04 10:01:00 +00:00
Remove some temp-files (#5382)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
Sebastiaan van Stijn authored and 
Misty Stanley-Jones committed
1 parent
fad85b00d7
commit
86d98fcab4
19 files changed
-4392
No files matched your search
@@ -1,279 +0,0 @@
|
||||
page_title: FAQ
|
||||
page_description: Most frequently asked questions.
|
||||
page_keywords: faq, questions, documentation, docker
|
||||
|
||||
# FAQ
|
||||
|
||||
## Most frequently asked questions
|
||||
|
||||
### How much does Docker cost?
|
||||
|
||||
Docker is 100% free. It is open source, so you can use it without
|
||||
paying.
|
||||
|
||||
### What open source license are you using?
|
||||
|
||||
We are using the Apache License Version 2.0, see it here:
|
||||
[https://github.com/docker/docker/blob/master/LICENSE](
|
||||
https://github.com/docker/docker/blob/master/LICENSE)
|
||||
|
||||
### Does Docker run on Mac OS X or Windows?
|
||||
|
||||
Docker currently runs only on Linux, but you can use VirtualBox to run
|
||||
Docker in a virtual machine on your box, and get the best of both worlds.
|
||||
Check out the [*Mac OS X*](../installation/mac/#macosx) and [*Microsoft
|
||||
Windows*](../installation/windows/#windows) installation guides. The small
|
||||
Linux distribution boot2docker can be run inside virtual machines on these
|
||||
two operating systems.
|
||||
|
||||
{{ include "no-remote-sudo.md" }}
|
||||
|
||||
### How do containers compare to virtual machines?
|
||||
|
||||
They are complementary. VMs are best used to allocate chunks of
|
||||
hardware resources. Containers operate at the process level, which
|
||||
makes them very lightweight and perfect as a unit of software
|
||||
delivery.
|
||||
|
||||
### What does Docker add to just plain LXC?
|
||||
|
||||
Docker is not a replacement for LXC. "LXC" refers to capabilities of
|
||||
the Linux kernel (specifically namespaces and control groups) which
|
||||
allow sandboxing processes from one another, and controlling their
|
||||
resource allocations. On top of this low-level foundation of kernel
|
||||
features, Docker offers a high-level tool with several powerful
|
||||
functionalities:
|
||||
|
||||
- *Portable deployment across machines.*
|
||||
Docker defines a format for bundling an application and all
|
||||
its dependencies into a single object which can be transferred
|
||||
to any Docker-enabled machine, and executed there with the
|
||||
guarantee that the execution environment exposed to the
|
||||
application will be the same. LXC implements process
|
||||
sandboxing, which is an important pre-requisite for portable
|
||||
deployment, but that alone is not enough for portable
|
||||
deployment. If you sent me a copy of your application
|
||||
installed in a custom LXC configuration, it would almost
|
||||
certainly not run on my machine the way it does on yours,
|
||||
because it is tied to your machine's specific configuration:
|
||||
networking, storage, logging, distro, etc. Docker defines an
|
||||
abstraction for these machine-specific settings, so that the
|
||||
exact same Docker container can run - unchanged - on many
|
||||
different machines, with many different configurations.
|
||||
|
||||
- *Application-centric.*
|
||||
Docker is optimized for the deployment of applications, as
|
||||
opposed to machines. This is reflected in its API, user
|
||||
interface, design philosophy and documentation. By contrast,
|
||||
the `lxc` helper scripts focus on
|
||||
containers as lightweight machines - basically servers that
|
||||
boot faster and need less RAM. We think there's more to
|
||||
containers than just that.
|
||||
|
||||
- *Automatic build.*
|
||||
Docker includes [*a tool for developers to automatically
|
||||
assemble a container from their source
|
||||
code*](../reference/builder/#dockerbuilder), with full control
|
||||
over application dependencies, build tools, packaging etc.
|
||||
They are free to use `make`, `maven`, `chef`, `puppet`, `salt,`
|
||||
Debian packages, RPMs, source tarballs, or any combination of the
|
||||
above, regardless of the configuration of the machines.
|
||||
|
||||
- *Versioning.*
|
||||
Docker includes git-like capabilities for tracking successive
|
||||
versions of a container, inspecting the diff between versions,
|
||||
committing new versions, rolling back etc. The history also
|
||||
includes how a container was assembled and by whom, so you get
|
||||
full traceability from the production server all the way back
|
||||
to the upstream developer. Docker also implements incremental
|
||||
uploads and downloads, similar to `git pull`, so new versions
|
||||
of a container can be transferred by only sending diffs.
|
||||
|
||||
- *Component re-use.*
|
||||
Any container can be used as a [*"base image"*](
|
||||
../terms/image/#base-image-def) to create more specialized components.
|
||||
This can be done manually or as part of an automated build. For example
|
||||
you can prepare the ideal Python environment, and use it as a base for
|
||||
10 different applications. Your ideal Postgresql setup can be re-used for
|
||||
all your future projects. And so on.
|
||||
|
||||
- *Sharing.*
|
||||
Docker has access to a [public registry](https://hub.docker.com) where
|
||||
thousands of people have uploaded useful containers: anything from Redis,
|
||||
CouchDB, Postgres to IRC bouncers to Rails app servers to Hadoop to
|
||||
base images for various Linux distros. The
|
||||
[*registry*](../reference/api/registry_index_spec/#registryindexspec)
|
||||
also includes an official "standard library" of useful
|
||||
containers maintained by the Docker team. The registry itself
|
||||
is open-source, so anyone can deploy their own registry to
|
||||
store and transfer private containers, for internal server
|
||||
deployments for example.
|
||||
|
||||
- *Tool ecosystem.*
|
||||
Docker defines an API for automating and customizing the
|
||||
creation and deployment of containers. There are a huge number
|
||||
of tools integrating with Docker to extend its capabilities.
|
||||
PaaS-like deployment (Dokku, Deis, Flynn), multi-node
|
||||
orchestration (Maestro, Salt, Mesos, Openstack Nova),
|
||||
management dashboards (docker-ui, Openstack Horizon,
|
||||
Shipyard), configuration management (Chef, Puppet), continuous
|
||||
integration (Jenkins, Strider, Travis), etc. Docker is rapidly
|
||||
establishing itself as the standard for container-based
|
||||
tooling.
|
||||
|
||||
### What is different between a Docker container and a VM?
|
||||
|
||||
There's a great StackOverflow answer [showing the differences](
|
||||
http://stackoverflow.com/questions/16047306/how-is-docker-io-different-from-a-normal-virtual-machine).
|
||||
|
||||
### Do I lose my data when the container exits?
|
||||
|
||||
Not at all! Any data that your application writes to disk gets preserved
|
||||
in its container until you explicitly delete the container. The file
|
||||
system for the container persists even after the container halts.
|
||||
|
||||
### How far do Docker containers scale?
|
||||
|
||||
Some of the largest server farms in the world today are based on
|
||||
containers. Large web deployments like Google and Twitter, and platform
|
||||
providers such as Heroku and dotCloud all run on container technology,
|
||||
at a scale of hundreds of thousands or even millions of containers
|
||||
running in parallel.
|
||||
|
||||
### How do I connect Docker containers?
|
||||
|
||||
Currently the recommended way to link containers is via the link
|
||||
primitive. You can see details of how to [work with links
|
||||
here](/userguide/dockerlinks).
|
||||
|
||||
Also useful for more flexible service portability is the
|
||||
[Ambassador linking pattern](/articles/ambassador_pattern_linking/).
|
||||
|
||||
### How do I run more than one process in a Docker container?
|
||||
|
||||
Any capable process supervisor such as [http://supervisord.org/](
|
||||
http://supervisord.org/), runit, s6, or daemontools can do the trick.
|
||||
Docker will start up the process management daemon which will then fork
|
||||
to run additional processes. As long as the processor manager daemon continues
|
||||
to run, the container will continue to as well. You can see a more substantial
|
||||
example [that uses supervisord here](/articles/using_supervisord/).
|
||||
|
||||
### What platforms does Docker run on?
|
||||
|
||||
Linux:
|
||||
|
||||
- Ubuntu 12.04, 13.04 et al
|
||||
- Fedora 19/20+
|
||||
- RHEL 6.5+
|
||||
- Centos 6+
|
||||
- Gentoo
|
||||
- ArchLinux
|
||||
- openSUSE 12.3+
|
||||
- CRUX 3.0+
|
||||
|
||||
Cloud:
|
||||
|
||||
- Amazon EC2
|
||||
- Google Compute Engine
|
||||
- Rackspace
|
||||
|
||||
### How do I report a security issue with Docker?
|
||||
|
||||
You can learn about the project's security policy
|
||||
[here](https://www.docker.com/security/) and report security issues to
|
||||
this [mailbox](mailto:security@docker.com).
|
||||
|
||||
### Why do I need to sign my commits to Docker with the DCO?
|
||||
|
||||
Please read [our blog post](
|
||||
http://blog.docker.com/2014/01/docker-code-contributions-require-developer-certificate-of-origin/)
|
||||
on the introduction of the DCO.
|
||||
|
||||
### When building an image, should I prefer system libraries or bundled ones?
|
||||
|
||||
*This is a summary of a discussion on the [docker-dev mailing list](
|
||||
https://groups.google.com/forum/#!topic/docker-dev/L2RBSPDu1L0).*
|
||||
|
||||
Virtually all programs depend on third-party libraries. Most frequently,
|
||||
they will use dynamic linking and some kind of package dependency, so
|
||||
that when multiple programs need the same library, it is installed only once.
|
||||
|
||||
Some programs, however, will bundle their third-party libraries, because
|
||||
they rely on very specific versions of those libraries. For instance,
|
||||
Node.js bundles OpenSSL; MongoDB bundles V8 and Boost (among others).
|
||||
|
||||
When creating a Docker image, is it better to use the bundled libraries,
|
||||
or should you build those programs so that they use the default system
|
||||
libraries instead?
|
||||
|
||||
The key point about system libraries is not about saving disk or memory
|
||||
space. It is about security. All major distributions handle security
|
||||
seriously, by having dedicated security teams, following up closely
|
||||
with published vulnerabilities, and disclosing advisories themselves.
|
||||
(Look at the [Debian Security Information](https://www.debian.org/security/)
|
||||
for an example of those procedures.) Upstream developers, however,
|
||||
do not always implement similar practices.
|
||||
|
||||
Before setting up a Docker image to compile a program from source,
|
||||
if you want to use bundled libraries, you should check if the upstream
|
||||
authors provide a convenient way to announce security vulnerabilities,
|
||||
and if they update their bundled libraries in a timely manner. If they
|
||||
don't, you are exposing yourself (and the users of your image) to
|
||||
security vulnerabilities.
|
||||
|
||||
Likewise, before using packages built by others, you should check if the
|
||||
channels providing those packages implement similar security best practices.
|
||||
Downloading and installing an "all-in-one" .deb or .rpm sounds great at first,
|
||||
except if you have no way to figure out that it contains a copy of the
|
||||
OpenSSL library vulnerable to the [Heartbleed](http://heartbleed.com/) bug.
|
||||
|
||||
### Why is `DEBIAN_FRONTEND=noninteractive` discouraged in Dockerfiles?
|
||||
|
||||
When building Docker images on Debian and Ubuntu you may have seen errors like:
|
||||
|
||||
unable to initialize frontend: Dialog
|
||||
|
||||
These errors don't stop the image from being built but inform you that the
|
||||
installation process tried to open a dialog box, but was unable to.
|
||||
Generally, these errors are safe to ignore.
|
||||
|
||||
Some people circumvent these errors by changing the `DEBIAN_FRONTEND`
|
||||
environment variable inside the Dockerfile using:
|
||||
|
||||
ENV DEBIAN_FRONTEND=noninteractive
|
||||
|
||||
This prevents the installer from opening dialog boxes during installation
|
||||
which stops the errors.
|
||||
|
||||
While this may sound like a good idea, it *may* have side effects.
|
||||
The `DEBIAN_FRONTEND` environment variable will be inherited by all
|
||||
images and containers built from your image, effectively changing
|
||||
their behavior. People using those images will run into problems when
|
||||
installing software interactively, because installers will not show
|
||||
any dialog boxes.
|
||||
|
||||
Because of this, and because setting `DEBIAN_FRONTEND` to `noninteractive` is
|
||||
mainly a 'cosmetic' change, we *discourage* changing it.
|
||||
|
||||
If you *really* need to change its setting, make sure to change it
|
||||
back to its [default value](https://www.debian.org/releases/stable/i386/ch05s03.html.en)
|
||||
afterwards.
|
||||
|
||||
### Can I help by adding some questions and answers?
|
||||
|
||||
Definitely! You can fork [the repo](https://github.com/docker/docker) and
|
||||
edit the documentation sources.
|
||||
|
||||
### Where can I find more answers?
|
||||
|
||||
You can find more answers on:
|
||||
|
||||
- [Docker user mailinglist](https://groups.google.com/d/forum/docker-user)
|
||||
- [Docker developer mailinglist](https://groups.google.com/d/forum/docker-dev)
|
||||
- [IRC, docker on freenode](irc://chat.freenode.net#docker)
|
||||
- [GitHub](https://github.com/docker/docker)
|
||||
- [Ask questions on Stackoverflow](http://stackoverflow.com/search?q=docker)
|
||||
- [Join the conversation on Twitter](http://twitter.com/docker)
|
||||
|
||||
Looking for something else to read? Checkout the [User
|
||||
Guide](/userguide/).
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.4 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 62 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 38 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 99 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 205 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 54 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 9.0 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 59 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 23 KiB |
@@ -1,116 +0,0 @@
|
||||
page_title: Installation on Mac OS X
|
||||
page_description: Instructions for installing Docker on OS X using boot2docker.
|
||||
page_keywords: Docker, Docker documentation, requirements, boot2docker, VirtualBox, SSH, Linux, OSX, OS X, Mac
|
||||
|
||||
# Installing Docker on Mac OS X
|
||||
|
||||
> **Note:**
|
||||
> Docker is supported on Mac OS X 10.6 "Snow Leopard" or newer.
|
||||
|
||||
Because the Docker Engine uses Linux-specific kernel features, you'll need to use a
|
||||
lightweight virtual machine (VM) to run it on OS X. You use the OS X Docker client to
|
||||
control the virtualized Docker Engine to build, run, and manage Docker containers.
|
||||
|
||||
To make this process easier, we've built a helper application called
|
||||
[Boot2Docker](https://github.com/boot2docker/boot2docker) that installs a
|
||||
virtual machine (using VirtualBox) that's all set up to run the Docker daemon.
|
||||
|
||||
## Demonstration
|
||||
|
||||
<iframe width="640" height="360" src="//www.youtube.com/embed/wQsrKX4588U?rel=0" frameborder="0" allowfullscreen></iframe>
|
||||
|
||||
## Installation
|
||||
|
||||
1. Download the latest release of the [Docker for OS X Installer](
|
||||
https://github.com/boot2docker/osx-installer/releases/latest) (Look for the
|
||||
green Boot2Docker-x.x.x.pkg button near the bottom of the page.)
|
||||
|
||||
2. Run the installer by double-clicking the downloaded package, which will install a
|
||||
VirtualBox VM, Docker itself, and the Boot2Docker management tool.
|
||||
|
||||
|
||||
3. Locate the `Boot2Docker` app in your `Applications` folder and run it.
|
||||
Or, you can initialize Boot2Docker from the command line by running:
|
||||
|
||||
$ boot2docker init
|
||||
$ boot2docker start
|
||||
$ $(boot2docker shellinit)
|
||||
|
||||
A terminal window will open and you'll see the virtual machine starting up.
|
||||
Once you have an initialized virtual machine, you can control it with `boot2docker stop`
|
||||
and `boot2docker start`.
|
||||
|
||||
> **Note:**
|
||||
> If you see a message in the terminal that looks something like this:
|
||||
>
|
||||
> `To connect the Docker client to the Docker daemon, please set: export
|
||||
DOCKER_HOST=tcp://192.168.59.103:2375`
|
||||
>
|
||||
you can safely set the environment variable as instructed.
|
||||
|
||||
View the
|
||||
[Boot2Docker ReadMe](https://github.com/boot2docker/boot2docker/blob/master/README.md)
|
||||
for more information.
|
||||
|
||||
## Upgrading
|
||||
|
||||
1. Download the latest release of the [Docker for OS X Installer](
|
||||
https://github.com/boot2docker/osx-installer/releases/latest)
|
||||
|
||||
2. If Boot2Docker is currently running, stop it with `boot2docker stop`. Then, run
|
||||
the installer package, which will update Docker and the Boot2Docker management tool.
|
||||
|
||||
3. To complete the upgrade, you also need to update your existing virtual machine. Open a
|
||||
terminal window and run:
|
||||
|
||||
$ boot2docker stop
|
||||
$ boot2docker download
|
||||
$ boot2docker start
|
||||
|
||||
This will download an .iso image containing a fresh VM and start it up. Your upgrade is
|
||||
complete. You can test it by following the directions below.
|
||||
|
||||
## Running Docker
|
||||
|
||||
{{ include "no-remote-sudo.md" }}
|
||||
|
||||
From your terminal, you can test that Docker is running with our small `hello-world`
|
||||
example image:
|
||||
Start the vm (`boot2docker start`) and then run:
|
||||
|
||||
$ docker run hello-world
|
||||
|
||||
This should download the `hello-world` image, which then creates a small
|
||||
container with an executable that prints a brief `Hello from Docker.` message.
|
||||
|
||||
## Container port redirection
|
||||
|
||||
The latest version of `boot2docker` sets up a host-only network adaptor which provides
|
||||
access to the container's ports.
|
||||
|
||||
If you run a container with an exposed port,
|
||||
|
||||
$ docker run --rm -i -t -p 80:80 nginx
|
||||
|
||||
then you should be able to access that Nginx server using the IP address reported by:
|
||||
|
||||
$ boot2docker ip
|
||||
|
||||
Typically, it is 192.168.59.103:2375, but VirtualBox's DHCP implementation might change
|
||||
this address in the future.
|
||||
|
||||
# Further details
|
||||
|
||||
If you are curious, the username for the boot2docker default user is `docker` and the
|
||||
password is `tcuser`.
|
||||
|
||||
The Boot2Docker management tool provides several additional commands for working with the
|
||||
VM and Docker:
|
||||
|
||||
$ ./boot2docker
|
||||
Usage: ./boot2docker [<options>]
|
||||
{help|init|up|ssh|save|down|poweroff|reset|restart|config|status|info|ip|delete|download|version} [<args>]
|
||||
|
||||
Continue with the [User Guide](/userguide/).
|
||||
|
||||
For further information or to report issues, please visit the [Boot2Docker site](http://boot2docker.io).
|
||||
@@ -1,103 +0,0 @@
|
||||
page_title: Installation on Windows
|
||||
page_description: Docker installation on Microsoft Windows
|
||||
page_keywords: Docker, Docker documentation, Windows, requirements, virtualbox, boot2docker
|
||||
|
||||
# Windows
|
||||
> **Note:**
|
||||
> Docker has been tested on Windows 7.1 and 8; it may also run on older versions.
|
||||
> Your processor needs to support hardware virtualization.
|
||||
|
||||
The Docker Engine uses Linux-specific kernel features, so to run it on Windows
|
||||
we need to use a lightweight virtual machine (vm). You use the Windows Docker client to
|
||||
control the virtualized Docker Engine to build, run, and manage Docker containers.
|
||||
|
||||
To make this process easier, we've designed a helper application called
|
||||
[Boot2Docker](https://github.com/boot2docker/boot2docker) that installs the
|
||||
virtual machine and runs the Docker daemon.
|
||||
|
||||
## Demonstration
|
||||
|
||||
<iframe width="640" height="480" src="//www.youtube.com/embed/oSHN8_uiZd4?rel=0" frameborder="0" allowfullscreen></iframe>
|
||||
|
||||
## Installation
|
||||
|
||||
1. Download the latest release of the [Docker for Windows Installer](https://github.com/boot2docker/windows-installer/releases/latest)
|
||||
2. Run the installer, which will install VirtualBox, MSYS-git, the boot2docker Linux ISO,
|
||||
and the Boot2Docker management tool.
|
||||
|
||||
3. Run the `Boot2Docker Start` shell script from your Desktop or Program Files > Boot2Docker for Windows.
|
||||
The Start script will ask you to enter an ssh key passphrase - the simplest
|
||||
(but least secure) is to just hit [Enter].
|
||||
|
||||
|
||||
|
||||
The `Boot2Docker Start` script will connect you to a shell session in the virtual
|
||||
machine. If needed, it will initialize a new VM and start it.
|
||||
|
||||
## Upgrading
|
||||
|
||||
1. Download the latest release of the [Docker for Windows Installer](
|
||||
https://github.com/boot2docker/windows-installer/releases/latest)
|
||||
|
||||
2. Run the installer, which will update the Boot2Docker management tool.
|
||||
|
||||
3. To upgrade your existing virtual machine, open a terminal and run:
|
||||
|
||||
boot2docker stop
|
||||
boot2docker download
|
||||
boot2docker start
|
||||
|
||||
## Running Docker
|
||||
|
||||
{{ include "no-remote-sudo.md" }}
|
||||
|
||||
Boot2Docker will log you in automatically so you can start using Docker right away.
|
||||
|
||||
Let's try the `hello-world` example image. Run
|
||||
|
||||
$ docker run hello-world
|
||||
|
||||
This should download the very small `hello-world` image and print a `Hello from Docker.` message.
|
||||
|
||||
## Login with PUTTY instead of using the CMD
|
||||
|
||||
Boot2Docker generates and uses the public/private key pair in your `%HOMEPATH%\.ssh`
|
||||
directory so to log in you need to use the private key from this same directory.
|
||||
|
||||
The private key needs to be converted into the format PuTTY uses.
|
||||
|
||||
You can do this with
|
||||
[puttygen](http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html):
|
||||
|
||||
- Open `puttygen.exe` and load ("File"->"Load" menu) the private key from
|
||||
`%HOMEPATH%\.ssh\id_boot2docker`
|
||||
- then click: "Save Private Key".
|
||||
- Then use the saved file to login with PuTTY using `docker@127.0.0.1:2022`.
|
||||
|
||||
# Further Details
|
||||
|
||||
The Boot2Docker management tool provides several commands:
|
||||
|
||||
$ ./boot2docker
|
||||
Usage: ./boot2docker [<options>] {help|init|up|ssh|save|down|poweroff|reset|restart|config|status|info|ip|delete|download|version} [<args>]
|
||||
|
||||
|
||||
## Container port redirection
|
||||
|
||||
If you are curious, the username for the boot2docker default user is `docker` and the password is `tcuser`.
|
||||
|
||||
The latest version of `boot2docker` sets up a host only network adaptor which provides access to the container's ports.
|
||||
|
||||
If you run a container with an exposed port:
|
||||
|
||||
docker run --rm -i -t -p 80:80 nginx
|
||||
|
||||
Then you should be able to access that nginx server using the IP address reported
|
||||
to you using:
|
||||
|
||||
boot2docker ip
|
||||
|
||||
Typically, it is 192.168.59.103, but it could get changed by Virtualbox's DHCP
|
||||
implementation.
|
||||
|
||||
For further information or to report issues, please see the [Boot2Docker site](http://boot2docker.io)
|
||||
File diff suppressed because it is too large.
Load diff
File diff suppressed because it is too large.
Load diff
@@ -1,194 +0,0 @@
|
||||
page_title: Dockerizing Applications: A "Hello world"
|
||||
page_description: A simple "Hello world" exercise that introduced you to Docker.
|
||||
page_keywords: docker guide, docker, docker platform, virtualization framework, how to, dockerize, dockerizing apps, dockerizing applications, container, containers
|
||||
|
||||
# Dockerizing Applications: A "Hello world"
|
||||
|
||||
*So what's this Docker thing all about?*
|
||||
|
||||
Docker allows you to run applications inside containers. Running an
|
||||
application inside a container takes a single command: `docker run`.
|
||||
|
||||
{{ include "no-remote-sudo.md" }}
|
||||
|
||||
## Hello world
|
||||
|
||||
Let's try it now.
|
||||
|
||||
$ sudo docker run ubuntu:14.04 /bin/echo 'Hello world'
|
||||
Hello world
|
||||
|
||||
And you just launched your first container!
|
||||
|
||||
So what just happened? Let's step through what the `docker run` command
|
||||
did.
|
||||
|
||||
First we specified the `docker` binary and the command we wanted to
|
||||
execute, `run`. The `docker run` combination *runs* containers.
|
||||
|
||||
Next we specified an image: `ubuntu:14.04`. This is the source of the container
|
||||
we ran. Docker calls this an image. In this case we used an Ubuntu 14.04
|
||||
operating system image.
|
||||
|
||||
When you specify an image, Docker looks first for the image on your
|
||||
Docker host. If it can't find it then it downloads the image from the public
|
||||
image registry: [Docker Hub](https://hub.docker.com).
|
||||
|
||||
Next we told Docker what command to run inside our new container:
|
||||
|
||||
/bin/echo 'Hello world'
|
||||
|
||||
When our container was launched Docker created a new Ubuntu 14.04
|
||||
environment and then executed the `/bin/echo` command inside it. We saw
|
||||
the result on the command line:
|
||||
|
||||
Hello world
|
||||
|
||||
So what happened to our container after that? Well Docker containers
|
||||
only run as long as the command you specify is active. Here, as soon as
|
||||
`Hello world` was echoed, the container stopped.
|
||||
|
||||
## An Interactive Container
|
||||
|
||||
Let's try the `docker run` command again, this time specifying a new
|
||||
command to run in our container.
|
||||
|
||||
$ sudo docker run -t -i ubuntu:14.04 /bin/bash
|
||||
root@af8bae53bdd3:/#
|
||||
|
||||
Here we've again specified the `docker run` command and launched an
|
||||
`ubuntu:14.04` image. But we've also passed in two flags: `-t` and `-i`.
|
||||
The `-t` flag assigns a pseudo-tty or terminal inside our new container
|
||||
and the `-i` flag allows us to make an interactive connection by
|
||||
grabbing the standard in (`STDIN`) of the container.
|
||||
|
||||
We've also specified a new command for our container to run:
|
||||
`/bin/bash`. This will launch a Bash shell inside our container.
|
||||
|
||||
So now when our container is launched we can see that we've got a
|
||||
command prompt inside it:
|
||||
|
||||
root@af8bae53bdd3:/#
|
||||
|
||||
Let's try running some commands inside our container:
|
||||
|
||||
root@af8bae53bdd3:/# pwd
|
||||
/
|
||||
root@af8bae53bdd3:/# ls
|
||||
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
|
||||
|
||||
You can see we've run the `pwd` to show our current directory and can
|
||||
see we're in the `/` root directory. We've also done a directory listing
|
||||
of the root directory which shows us what looks like a typical Linux
|
||||
file system.
|
||||
|
||||
You can play around inside this container and when you're done you can
|
||||
use the `exit` command or enter Ctrl-D to finish.
|
||||
|
||||
root@af8bae53bdd3:/# exit
|
||||
|
||||
As with our previous container, once the Bash shell process has
|
||||
finished, the container is stopped.
|
||||
|
||||
## A Daemonized Hello world
|
||||
|
||||
Now a container that runs a command and then exits has some uses but
|
||||
it's not overly helpful. Let's create a container that runs as a daemon,
|
||||
like most of the applications we're probably going to run with Docker.
|
||||
|
||||
Again we can do this with the `docker run` command:
|
||||
|
||||
$ sudo docker run -d ubuntu:14.04 /bin/sh -c "while true; do echo hello world; sleep 1; done"
|
||||
1e5535038e285177d5214659a068137486f96ee5c2e85a4ac52dc83f2ebe4147
|
||||
|
||||
Wait what? Where's our "Hello world" Let's look at what we've run here.
|
||||
It should look pretty familiar. We ran `docker run` but this time we
|
||||
specified a flag: `-d`. The `-d` flag tells Docker to run the container
|
||||
and put it in the background, to daemonize it.
|
||||
|
||||
We also specified the same image: `ubuntu:14.04`.
|
||||
|
||||
Finally, we specified a command to run:
|
||||
|
||||
/bin/sh -c "while true; do echo hello world; sleep 1; done"
|
||||
|
||||
This is the (hello) world's silliest daemon: a shell script that echoes
|
||||
`hello world` forever.
|
||||
|
||||
So why aren't we seeing any `hello world`'s? Instead Docker has returned
|
||||
a really long string:
|
||||
|
||||
1e5535038e285177d5214659a068137486f96ee5c2e85a4ac52dc83f2ebe4147
|
||||
|
||||
This really long string is called a *container ID*. It uniquely
|
||||
identifies a container so we can work with it.
|
||||
|
||||
> **Note:**
|
||||
> The container ID is a bit long and unwieldy and a bit later
|
||||
> on we'll see a shorter ID and some ways to name our containers to make
|
||||
> working with them easier.
|
||||
|
||||
We can use this container ID to see what's happening with our `hello world` daemon.
|
||||
|
||||
Firstly let's make sure our container is running. We can
|
||||
do that with the `docker ps` command. The `docker ps` command queries
|
||||
the Docker daemon for information about all the containers it knows
|
||||
about.
|
||||
|
||||
$ sudo docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
1e5535038e28 ubuntu:14.04 /bin/sh -c 'while tr 2 minutes ago Up 1 minute insane_babbage
|
||||
|
||||
Here we can see our daemonized container. The `docker ps` has returned some useful
|
||||
information about it, starting with a shorter variant of its container ID:
|
||||
`1e5535038e28`.
|
||||
|
||||
We can also see the image we used to build it, `ubuntu:14.04`, the command it
|
||||
is running, its status and an automatically assigned name,
|
||||
`insane_babbage`.
|
||||
|
||||
> **Note:**
|
||||
> Docker automatically names any containers you start, a
|
||||
> little later on we'll see how you can specify your own names.
|
||||
|
||||
Okay, so we now know it's running. But is it doing what we asked it to do? To see this
|
||||
we're going to look inside the container using the `docker logs`
|
||||
command. Let's use the container name Docker assigned.
|
||||
|
||||
$ sudo docker logs insane_babbage
|
||||
hello world
|
||||
hello world
|
||||
hello world
|
||||
. . .
|
||||
|
||||
The `docker logs` command looks inside the container and returns its standard
|
||||
output: in this case the output of our command `hello world`.
|
||||
|
||||
Awesome! Our daemon is working and we've just created our first
|
||||
Dockerized application!
|
||||
|
||||
Now we've established we can create our own containers let's tidy up
|
||||
after ourselves and stop our daemonized container. To do this we use the
|
||||
`docker stop` command.
|
||||
|
||||
$ sudo docker stop insane_babbage
|
||||
insane_babbage
|
||||
|
||||
The `docker stop` command tells Docker to politely stop the running
|
||||
container. If it succeeds it will return the name of the container it
|
||||
has just stopped.
|
||||
|
||||
Let's check it worked with the `docker ps` command.
|
||||
|
||||
$ sudo docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
|
||||
Excellent. Our container has been stopped.
|
||||
|
||||
# Next steps
|
||||
|
||||
Now we've seen how simple it is to get started with Docker let's learn how to
|
||||
do some more advanced tasks.
|
||||
|
||||
Go to [Working With Containers](/userguide/usingdocker).
|
||||
|
||||
Reference in new issue
Block a user