fundamentals.rst 3.8 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697
  1. :title: Image & Container
  2. :description: Definitions of an image and container
  3. :keywords: containers, lxc, concepts, explanation, image, container
  4. File Systems
  5. ============
  6. .. image:: images/docker-filesystems-generic.png
  7. In order for a Linux system to run, it typically needs two `file
  8. systems <http://en.wikipedia.org/wiki/Filesystem>`_:
  9. 1. boot file system (bootfs)
  10. 2. root file system (rootfs)
  11. The **boot file system** contains the bootloader and the kernel. The
  12. user never makes any changes to the boot file system. In fact, soon
  13. after the boot process is complete, the entire kernel is in memory,
  14. and the boot file system is unmounted to free up the RAM associated
  15. with the initrd disk image.
  16. The **root file system** includes the typical directory structure we
  17. associate with Unix-like operating systems: ``/dev, /proc, /bin, /etc,
  18. /lib, /usr,`` and ``/tmp`` plus all the configuration files, binaries
  19. and libraries required to run user applications (like bash, ls, and so
  20. forth).
  21. While there can be important kernal differences between different
  22. Linux distributions, the contents and organization of the root file
  23. system are usually what make your software packages dependent on one
  24. distribution versus another. Docker can help solve this problem by
  25. running multiple distributions at the same time.
  26. .. image:: images/docker-filesystems-multiroot.png
  27. Layers and Union Mounts
  28. =======================
  29. In a traditional Linux boot, the kernel first mounts the root file
  30. system as read-only, checks its integrity, and then switches the whole
  31. rootfs volume to read-write mode. Docker does something similar,
  32. *except* that instead of changing the file system to read-write mode,
  33. it takes advantage of a `union mount
  34. <http://en.wikipedia.org/wiki/Union_mount>`_ to add a read-write file
  35. system *over* the read-only file system. In fact there may be multiple
  36. read-only file systems stacked on top of each other.
  37. .. image:: images/docker-filesystems-multilayer.png
  38. At first, the top layer has nothing in it, but any time a process
  39. creates a file, this happens in the top layer. And if something needs
  40. to update an existing file in a lower layer, then the file gets copied
  41. to the upper layer and changes go into the copy. The version of the
  42. file on the lower layer cannot be seen by the applications anymore,
  43. but it is there, unchanged.
  44. We call the union of the read-write layer and all the read-only layers
  45. a **union file system**.
  46. Image
  47. =====
  48. In Docker terminology, a read-only layer is called an **image**. An
  49. image never changes. Because Docker uses a union file system, the
  50. applications think the whole file system is mounted read-write,
  51. because any file can be changed. But all the changes go to the
  52. top-most layer, and underneath, the image is unchanged. Since they
  53. don't change, images do not have state.
  54. Each image may depend on one more image which forms the layer beneath
  55. it. We sometimes say that the lower image is the **parent** of the
  56. upper image.
  57. Base Image
  58. ==========
  59. An image that has no parent is a **base image**.
  60. Container
  61. =========
  62. Once you start a process in Docker from an image, Docker fetches the
  63. image and its parent, and repeats the process until it reaches the
  64. base image. Then the union file system adds a read-write layer on
  65. top. That read-write layer, plus the information about its parent and
  66. some additional information like its unique id, is called a
  67. **container**.
  68. Containers can change, and so they have state. A container may be
  69. running or exited. In either case, the state of the file system and
  70. its exit value is preserved. You can start, stop, and restart a
  71. container. The processes restart from scratch (their memory state is
  72. **not** preserved in a container), but the file system is just as it
  73. was when the container was stopped.
  74. You can promote a container to an image with ``docker commit``. Once a
  75. container is an image, you can use it as a parent for new containers.