Docker Concepts: Difference between revisions
No edit summary |
|||
| Line 7: | Line 7: | ||
Docker is at the same time a ''packaging format'', a ''set of tools'' with server and client components, and a ''development and operations workflow''. Because it defines a workflow, Docker can be seen as a tool that reduces the complexity of communication between the development and the operations teams. | Docker is at the same time a ''packaging format'', a ''set of tools'' with server and client components, and a ''development and operations workflow''. Because it defines a workflow, Docker can be seen as a tool that reduces the complexity of communication between the development and the operations teams. | ||
Docker architecture centers on atomic and throwaway [[#Container|containers]]. During the deployment of a new version of an application, the whole runtime environment of the old version of the application is thrown away with it, including dependencies, configuration, all the way | Docker architecture centers on atomic and throwaway [[#Container|containers]]. During the deployment of a new version of an application, the whole runtime environment of the old version of the application is thrown away with it, including dependencies, configuration, all the way to, but excluding the O/S kernel. This means the new version of the application won't accidentally use artifacts left by the previous release, and the ephemeral debugging changes are not going to survive. This approach also makes the application portable between servers, which act as places where to dock standardized containers. | ||
=Container= | =Container= | ||
Revision as of 19:24, 29 March 2017
Internal
Overview
Docker is at the same time a packaging format, a set of tools with server and client components, and a development and operations workflow. Because it defines a workflow, Docker can be seen as a tool that reduces the complexity of communication between the development and the operations teams.
Docker architecture centers on atomic and throwaway containers. During the deployment of a new version of an application, the whole runtime environment of the old version of the application is thrown away with it, including dependencies, configuration, all the way to, but excluding the O/S kernel. This means the new version of the application won't accidentally use artifacts left by the previous release, and the ephemeral debugging changes are not going to survive. This approach also makes the application portable between servers, which act as places where to dock standardized containers.