Docker Most Useful Commands

About Docker

Docker has quite an amount of buzz around it today because it makes so many things easy that were difficult with virtual machines.

Docker containers makes it easy for Developers, Systems Administrators, Architects, Consultants and others to quickly test a piece of software in a container; much quicker than a virtual machine, and using less resources. The average command in Docker takes under a second to complete.

Docker most useful commands:

» Pull an Image
This will pull the latest Hello World example from the remote repository and cache it in the local index. If the image you are pulling is made up of layers, all of the layers will be pulled.

» List Images
This will list all of the images in the local index and display how they are linked to each other. Every time a new container is spawned from an image, it will create another copy on write image to save it’s changes too. The tree structure will help make things clear.

Warning: ‘–tree’ is deprecated, it will be removed soon. See usage. there is not other parameter that could replace this functionality yet.

» Remove all images
This will remove all images from the local index along with the containers. It will not be possible to restore them!

» Remove all containers

» Run image
This will run an image. Since multiple parameters can change the run behaviour, I’ll list the most common along with a brief explanation.
As a prerequisite, run the following command to get a fresh ubuntu image first

  • Detached vs Foreground
    When starting a Docker container, you must first decide if you want to run the container in the background in a “detached” mode or in the default foreground modeDetached (-d)
    In detached mode (-d=true or just -d), all I/O should be done through network connections or shared volumes because the container is no longer listening to the command line where you executed docker run. You can reattach to a detached container with docker attach. If you choose to run a container in the detached mode, then you cannot use the –rm option.Foreground (-d=false)
    In foreground mode (the default when -d is not specified), docker run can start the process in the container and attach the console to the process’s standard input, output, and standard error. It can even pretend to be a TTY (this is what most command line executables expect) and pass along signals. All of that is configurable:

    If you do not specify -a then Docker will attach all standard streams. You can specify to which of the three standard streams (STDIN, STDOUT, STDERR) you’d like to connect instead, as in:
  • Container Identification
    Name (–-name)
    The operator can identify a container in three ways:UUID long identifier (“f78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778”)
    UUID short identifier (“f78375b1c487”)
    Name (“evil_ptolemy”)
    The UUID identifiers come from the Docker daemon, and if you do not assign a name to the container with –name then the daemon will also generate a random string name too. The name can become a handy way to add meaning to a container since you can use this name when defining links (or any other place you need to identify a container). This works for both background and foreground Docker containers.Image[:tag]
    While not strictly a means of identifying a container, you can specify a version of an image you’d like to run the container with by adding image[:tag] to the command. For example, docker run ubuntu:14.04.
  • Clean Up (–-rm)
    By default a container’s file system persists even after the container exits. This makes debugging a lot easier (since you can inspect the final state) and you retain all your data by default. But if you are running short-term foreground processes, these container file systems can really pile up. If instead you’d like Docker to automatically clean up the container and remove the file system when the container exits, you can add the –rm flag:
  • EXPOSE (Incoming Ports)
    The Dockerfile doesn’t give much control over networking, only providing the EXPOSE instruction to give a hint to the operator about what incoming ports might provide services. Example:
  • ENV (Environment Variables)
    The operator can set any environment variable in the container by using one or more -e flags, even overriding those already defined by the developer with a Dockerfile ENV:
  • VOLUME (Shared Filesystems)

    A developer can define one or more VOLUME’s associated with an image, but only the operator can give access from one container to another (or from a container to a volume mounted on the host).
  • User
    The default user within a container is root (id = 0), but if the developer created additional users, those are accessible too. The developer can set a default user to run the first process with the Dockerfile USER instruction, but the operator can override it:
  • WORKDIR
    The default working directory for running binaries within a container is the root directory (/), but the developer can set a different default with the Dockerfile WORKDIR command. The operator can override this with:


» Log in to the Hosted Docker Registry

To create repositories on the public Docker Registry, it is necessary to sign up at:
https://www.docker.io/account/signup/
Once you have created an account, you will need to login from the command line:

» Dockerfile: Commit an Image
Once logged in to the public Docker Registry, new images can be built and committed with code using a Dockerfile. This allows an administrator to automatically rebuild a known good starting point quickly and easily. It is recommended to always start with an image defined by a Dockerfile.

There are a couple of important things to notice with this Dockerfile. First, the FROM directive specifies a username and repository. This will pull the latest image of ubuntu repository. In this example, I have provided the source repository for you. Second, the only change we have specified in the Dockerfile, is to update Ubuntu to latest available packages.

    •  Build and tag the image
    • Inspect the new image


      Notice that the new image is now available for deployment.
    • Test the new image

    • Manually: Commit an Image
      Once a container has changes made locally, they can be committed to the local index. This allows you to check point and continue. It also allows you to create new images based off of this modified container.
    • Modify the image
      Make some changes inside the container. In this example, change the hostname and exit

» Commit the container
First, get a list of containers. Notice that every container has a CONTAINTER ID and a STATUS. A status of Up means the container is currently running, while a status of Exit indicates that the container has been stopped. Think of the CONTAINER ID as a branch from the base image that contains all of the changes that were made to the container while it was running. By default this data is saved even after the container is shut down.

Now, commit the container back as a branch of it’s base image

Notice that the image is now available in the tree output. Also, notice that it is a branch of the root ubuntu:14.04 image, not the ubuntu-updated:latest image, which we previously built with a Dockerfile.

Tag the new image with something meaningful

» Push a Container
Once a container is committed locally, it can be pushed back to the registry server to be shared. The changes will be pushed as a layered image. Notice how quickly it is able to push only the differences between your modified image and the base image. This is a big part of the value.

So what are your Docker most useful commands?