111 lines
		
	
	
	
		
			4.6 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
			
		
		
	
	
			111 lines
		
	
	
	
		
			4.6 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
---
 | 
						|
tags: [docker, containerization, Linux]
 | 
						|
---
 | 
						|
 | 
						|
# Containerizaton
 | 
						|
 | 
						|
> In this entry we look at containerization as a general technology that is
 | 
						|
> distinct from its particular implementation by Docker.
 | 
						|
 | 
						|
We can understand the role and significance of containers and containerization
 | 
						|
by analogy with shipping containers. Before the invention of shipping containers
 | 
						|
as a **standardised modular unit** for transporting goods, shipping and supply
 | 
						|
chains were chaotic: inefficient, complex, frictional. With the advent of the
 | 
						|
shipping container, the same artefact could be used for transportation via
 | 
						|
ships, trains, lorries etc.
 | 
						|
 | 
						|
With containers we can share and transport software via a single standardised
 | 
						|
unit that works regardless of the host operating system or server. We can also
 | 
						|
iterate different software environments easily: local, production, test etc. As
 | 
						|
with the shipping of goods, standardisation has driven down running costs and
 | 
						|
increased the speed of transport.
 | 
						|
 | 
						|
## Containers and software
 | 
						|
 | 
						|
- Containers are a technology that allow you to package and isolate applications
 | 
						|
  with their entire runtime environment. This makes it easy to move the
 | 
						|
  contained application between various environments whilst retaining full
 | 
						|
  functionality.
 | 
						|
 | 
						|
- The technology of containerization is distinct from _Docker_. Docker is a
 | 
						|
  particular implementation of containerization that simplifies the process and
 | 
						|
  bases it on a standardised specification.
 | 
						|
 | 
						|
- Containers are native to the Linux [kernal](The_kernel.md)
 | 
						|
  and are key part of how it works. Thus when you run containers on Linux, you
 | 
						|
  are using native capability. When you use containers on Windows or Mac you
 | 
						|
  have to run a virtual version of Linux in order to exploit the capabilities of
 | 
						|
  that kernel. (Docker provides this)
 | 
						|
 | 
						|
## How containers work
 | 
						|
 | 
						|
A key feature of the Linux kernal is the existence of **cgroups** (control
 | 
						|
groups).
 | 
						|
 | 
						|
> Containerization = resource control + process isolation
 | 
						|
 | 
						|
- A cgroup **groups a series of processes together and contrains their access to
 | 
						|
  system resources (CPU, memory, disk)**
 | 
						|
- Cgroups use namespaces to provide **process isolation**: groups of processes
 | 
						|
  are isolated so that they cannot access other processes on the system. For
 | 
						|
  example a container is ignorant of the underlying operating system and
 | 
						|
  network, by default.
 | 
						|
 | 
						|
In ordinary [user space](User_Space.md) applications share
 | 
						|
the _same_ processor, memory and file system resources. This increases the
 | 
						|
likelihood of resourcing challenges, dependency conflicts and security threats.
 | 
						|
Without modularisation and the titration of resources, you are opened up to much
 | 
						|
greater possibility of failure.
 | 
						|
 | 
						|
For example one application could fill up the harddrive preventing other
 | 
						|
applications from writing to it. One application can "bring down" another
 | 
						|
applicaton.
 | 
						|
 | 
						|
Prior to containerization, in an enterprise environment most of the system
 | 
						|
administration consisted in managing resouces to avoid excessive resource
 | 
						|
expenditure and security challenges.
 | 
						|
 | 
						|
_Standard userspace_
 | 
						|
 | 
						|

 | 
						|
 | 
						|
_Userspace with containerization_
 | 
						|
 | 
						|

 | 
						|
 | 
						|
## Differences with virtual machines
 | 
						|
 | 
						|
Containers are similar in many regards to VMs. They both offer a virtualized
 | 
						|
environment in which to run software and they both provide isolation of
 | 
						|
resources. (When you start up a VM you specify the available RAM and disk
 | 
						|
space.)
 | 
						|
 | 
						|
The central difference is that VMs require the existence of a full operating
 | 
						|
system. Containers can run without an OS although it is often convenient to run
 | 
						|
them with stripped-down Linux distributions.
 | 
						|
 | 
						|
A VM contains a complete installation of a guest OS and requires a hypervisor on
 | 
						|
the host OS to manage the different operating environments. This makes them
 | 
						|
slower and consume more resources.
 | 
						|
 | 
						|
A containerized system radically reduces this overhead. It just starts up the
 | 
						|
container and after that it's job is done since the Linux kernel handles the
 | 
						|
rest as it would any other process on the OS.
 | 
						|
 | 
						|
| Virtual Machine                             | Container                               |
 | 
						|
| ------------------------------------------- | --------------------------------------- |
 | 
						|
| Isolation of resources and operating system | Isolation of resources only             |
 | 
						|
| Require a hypervisor to run                 | Require a container runtime to run      |
 | 
						|
| Slower due to additional abstraction        | Faster due to less overhead             |
 | 
						|
| Less portable                               | More portable                           |
 | 
						|
| Slower and more difficult to run            | Scale rapidly due to lightweight nature |
 | 
						|
 | 
						|

 | 
						|
 | 
						|
## Why use containers?
 | 
						|
 | 
						|
- portability
 | 
						|
- scalability
 | 
						|
- efficiency
 | 
						|
- isolation
 | 
						|
- DevOps agility
 |