What is the difference between a Docker image and a container?
When using docker, we start with a base image. We boot it up, create changes and those changes are saved in layers forming another image.
So eventually I have an image for my Postgres and an image for my web app, changes to which keep on being persisted.
So the question is: what is a container?
An instance of an image is called a container. You have an image, which is a set of layers as you describe. If you start this image, you have a running container of this image. You can have many running containers of the same image.
 You can see all your images with docker images whereas you can see your running containers with docker ps (and you can see all containers with docker ps -a ).  
So a running instance of an image is a container.
From my article on Automating Docker Deployments:
Docker Images vs. Containers
In Dockerland, there are images and there are containers . The two are closely related, but distinct. For me, grasping this dichotomy has clarified Docker immensely.
What's an Image?
An image is an inert, immutable, file that's essentially a snapshot of a container. Images are created with the build command, and they'll produce a container when started with run. Images are stored in a Docker registry such as registry.hub.docker.com. Because they can become quite large, images are designed to be composed of layers of other images, allowing a miminal amount of data to be sent when transferring images over the network.
 Local images can be listed by running docker images :  
REPOSITORY                TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
ubuntu                    13.10               5e019ab7bf6d        2 months ago        180 MB
ubuntu                    14.04               99ec81b80c55        2 months ago        266 MB
ubuntu                    latest              99ec81b80c55        2 months ago        266 MB
ubuntu                    trusty              99ec81b80c55        2 months ago        266 MB
<none>                    <none>              4ab0d9120985        3 months ago        486.5 MB
Some things to note:
-t flag of the docker build command, or from docker tag -ing an existing image.  You're free to tag images using a nomenclature that makes sense to you, but know that docker will use the tag as the registry location in a docker push or docker pull .  [REGISTRYHOST/][USERNAME/]NAME[:TAG] .  For ubuntu above, REGISTRYHOST is inferred to be registry.hub.docker.com .  So if you plan on storing your image called my-application in a registry at docker.example.com , you should tag that image docker.example.com/my-application .  latest tag is not magical, it's simply the default tag when you don't specify a tag.  <none> TAG and REPOSITORY.  It's easy to forget about them.  More info on images is available from the Docker docs and glossary.
What's a container?
To use a programming metaphor, if an image is a class, then a container is an instance of a class—a runtime object. Containers are hopefully why you're using Docker; they're lightweight and portable encapsulations of an environment in which to run applications.
 View local running containers with docker ps :  
CONTAINER ID        IMAGE                               COMMAND                CREATED             STATUS              PORTS                    NAMES
f2ff1af05450        samalba/docker-registry:latest      /bin/sh -c 'exec doc   4 months ago        Up 12 weeks         0.0.0.0:5000->5000/tcp   docker-registry
Here I'm running a dockerized version of the docker registry, so that I have a private place to store my images. Again, some things to note:
docker ps only outputs running containers.  You can view all containers (running or stopped) with docker ps -a .  --name flag.  How to avoid image and container buildup?
One of my early frustrations with Docker was the seemingly constant buildup of untagged images and stopped containers . On a handful of occassions this buildup resulted in maxed out hard drives slowing down my laptop or halting my automated build pipeline. Talk about "containers everywhere"!
 We can remove all untagged images by combining docker rmi with the recent dangling=true query:  
 docker images -q --filter "dangling=true" | xargs docker rmi 
 Docker won't be able to remove images that are behind existing containers, so you may have to remove stopped containers with docker rm first:  
docker rm `docker ps --no-trunc -aq`
These are known pain points with Docker, and may be addressed in future releases. However, with a clear understanding of images and containers, these situations can be avoided with a couple of practices:
docker rm [CONTAINER_ID] .  docker rmi [IMAGE_ID] .  While it's simplest to think of a container as a running image, this isn't quite accurate.
An image is really a template that can be turned into a container. To turn an image into a container, the Docker engine takes the image, adds a read-write filesystem on top and initialises various settings including network ports, container name, ID and resource limits. A running container has a currently executing process, but a container can also be stopped (or exited in Docker's terminology). An exited container is not the same as an image, as it can be restarted and will retain its settings and any filesystem changes.
链接地址: http://www.djcxy.com/p/5106.html上一篇: 在Vagrant与Docker隔离
下一篇: Docker镜像和容器有什么区别?
