notes on containerization (docker)

DevOps/Docker/Containers_in_general.md

@@ -5,3 +5,60 @@ tags: [docker, containerization]
 ---
 
 # Containers in general
+
+> 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](/Operating_Systems/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](/Operating_Systems/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_
+
+![](/_img/standard-userspace.png)
+
+_Userspace with containerization_
+
+![](/_img/containers-in-userspace.png)
+
+## 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 |
+
+![](/_img/container-versus-vm.png)

DevOps/Docker/Docker_notes.md

@@ -1,47 +1,3 @@
-# Unit 1
-
-A (shipping) container is a standard unit of shipping.
-
-Standardisd modular unit to transport goods from one location to another. Ships, trains, back of lorries.
-
-Beforehand, shipping world was chaotic: inefficient, complex, frictional.
-
-With containers, friction reduced driving down cost and increasing speeds of transport. Also led to automation.
-
-Analogy is with software containers. Compare differences between local machine and production environment, test environment etc. Friction removed by containers.
-
-> Linux containers are technologies that allow you to package and isolate applications with their entire runtime environment. This makes it easy to move the contained application between environments (dev, test, production, etc.) while retaining full functionality.
-
-> Containers as a technology are distinct from Docker. You don't need Docker to create and run a container. Docker just makes the process much easier and standardises it.
-
-> Containers are _Linux_ technology and are part of the Linux kernel. Running Linux containers do not require Docker.
-
-There are Windows containers and Linux containers. You cannot run either on the other. (Windows uses Docker to run containers. Linux can do it natively.)
-
-## How containers work
-
-Using `cgroups` (control groups) feature of Linux, group bunch of processes together and constrain their resource usage (e.g. CPU and memory). Originally called "process containers" for this reason.
-
-Use namespaces to provide _process isolation_ -> groups of processes are isolated so that they cannot access other processes on the system.
-
-Containerisation = resource control + process isolation
-
-TODO: Add diagrams from slides
-
-In standard user space, applications and processes share the **same** processor, memory and file system resources. This means there can be resource challenges, dependency challenges and security challenges.
-
-One application could fill up the hard drive preventing other applications from storing to it. One application can "bring down" another application.
-
-In enterprise environment most of system administration was managing these resources to avoid resource expenditure (before containers) and security challenges.
-
-Containers demarcate resource-constrained sub-sections of the user space that are ignorant of each other and the broader user space.
-
-Docker exploited the capacity of the Linux kernel to create containers and simplified the setup and deployment of them.
-
-> An image is a blueprint that contains the instructions to build a container. It's an immutable snapshot of the file system and configuration of an application. Images can be easily shared between developers.
-
-> A container is a executable package that contains everything needed to run an application. It will always run the same, regardless of infrastructure, in a sandboxed environment. It is a running instance of an image.
-
 ## Difference with virtual machines
 
 VMs require an OS. Containers do not. A VM contains a complete installation of a guest OS. Also provides isolation of resources (because you have an entirely separate OS).
@@ -70,6 +26,10 @@ The OCI standardises the follwoing:
 
 Docker company used to offer a platform for companies to run docker containers but they eventually sold this and focused solely on Docker desktop (local running of images for development).
 
+> An image is a blueprint that contains the instructions to build a container. It's an immutable snapshot of the file system and configuration of an application. Images can be easily shared between developers.
+
+> A container is a executable package that contains everything needed to run an application. It will always run the same, regardless of infrastructure, in a sandboxed environment. It is a running instance of an image.
+
 ## Why use containers?
 
 - portability