Docker and Containers

Intro

Docker is the world leading software container platform.

A container  has everything required to make a piece of software run is packaged into isolated containers. Unlike VMs, containers do not bundle a full operating system - only libraries and settings required to make the software work are needed. This makes for efficient, lightweight, self-contained systems and guarantees that software will always run the same, regardless of where it’s deployed.

You patch the underlying image and redeploy it (much easier for upgrading especially at scale)

As of 2017 docker is very new tech and is only 4 years old.

The earliest version of containers goes back to chroot (filesystem virtualization) in bsd

Docker is not a lightweight Vm (different architectures , different benefits) so don't try and replicate what you do in Vm in containers.

Its important to note every container shares a kernel

Variables to consider when you are setting up containers are what do you want to prioritize:

  • performance?
  • scalability?
  • costs?
  • security?

this will then effect how you build out your system.

For the lack of a better  term i am going to call Containers at the most basic level  "Virtualization for applications with a different model of sharing resources "

Analogue

Taken from Docker?!? But I'm a SYSADMIN!

Think of a Vm as a house (it can stand alone on its own, its fully self contained unit i.e electricity,plumbing ) but houses can only get so small in size.

i.e 1 bedroom, 1 kitchen...1GB memory 10Gb disk space..., it has its own os, it has its own resources)

Containers are like a flat (shared resources i.e heating/pluming/elevator, can vary in size depending on needs i.e penthouse v shared flat) i.e shared kernel

Containers (Flats in our analogue) live in an apartment building that we call a Docket host, which is any server that runs the docker engine which is like the doorman. In the apartment building it starts and stops containers but unlike a hypervisor it doesn't get in the way)

Containers (Flats in our analogue) are isolated though (i.e they have a front door)

you can optimize applications for cost/performance/security/scaleability... (i.e your flat could be student flat with 4 people living in it or a penthouse with amazing views)

+Ve

Because of the use of the way resources are used (depending on setup) it can be a better use of memory/cpu/storage meaning less servers may be needed

Containers are faster to boot because of how light they can  be and can be very small in size (i.e at smallest it could be 60k for a hello world container).

potentially less patching because you patch the underlying image and redeploy it.

good for fast deploys.

very quick to provision (v Vm's)

very good for scaling (v a Vm) size makes easily transferable to other machines.

as they share the OS they are much quicker to boot.

you can get 100/1000 of containers per host, which can complicate networking , containers can exist for minutes of months.

Look here at the growth and popularity of Docker

-Ve and limitations to be aware off.

need to be careful of running window and linux on the same host as they cannot share kernel

security wise virtualization is potentially better (although there is a hyper v isolation for linux containers new feature in docker which allows you better isolation for a machine -good for security)

All containers share tcp/ip stack (unlike Vm's). This means the Docker host can only expose port 80 1 time (not great with hardwired applications). This is why planning and understanding your applications is so important.

 

Related terminology

Greenfield project

In software development, a greenfield project could be one of developing a system for a totally new environment, without concern for integrating with other systems, especially not legacy systems. Such projects are deemed as higher risk, as they are often for new infrastructure, new customers, and even new owners. For this reason, agile software development is often deemed the best approach, as it proposes how to handle those risks by developing small slices of complete functionality and getting them in the hands of customers (internal or external) quickly for immediate feedback.[1]

Brownfield development

Brownfield development is a term commonly used in the IT industry to describe problem spaces needing the development and deployment of new software systems in the immediate presence of existing (legacy) software applications/systems. This implies that any new software architecture must take into account and coexist with live software already in situ. In contemporary civil engineering, Brownfield land means places where new buildings may need to be designed and erected considering the other structures and services already in place.

Brownfield development adds a number of improvements to conventional software engineering practices. These traditionally assume a "clean sheet of paper" or "greenfield land" target environment throughout the design and implementation phases of software development. Brownfield extends such traditions by insisting that the context (local landscape) of the system being created be factored into any development exercise. This requires a detailed knowledge of the systems, services and data in the immediate vicinity of the solution under construction

Blue/Green deployment

Blue-green deployment is a technique that reduces downtime and risk by running two identical production environments called Blue and Green.

At any time, only one of the environments is live, with the live environment serving all production traffic. For this example, Blue is currently live and Green is idle.

As you prepare a new version of your software, deployment and the final stage of testing takes place in the environment that is not live: in this example, Green. Once you have deployed and fully tested the software in Green, you switch the router so all incoming requests now go to Green instead of Blue. Green is now live, and Blue is idle.

This technique can eliminate downtime due to application deployment. In addition, blue-green deployment reduces risk: if something unexpected happens with your new version on Green, you can immediately roll back to the last version by switching back to Blue.

from https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html

Microservices

Moving away from 1 application on 1 server to microservices . Containers allow developers and operators to collaborate on micro services

Microservices architecture is an approach to application development in which a large application is built as a suite of modular services. Each module supports a specific business goal and uses a simple, well-defined interface to communicate with other sets of services.
The microservices architecture is quickly becoming the default mechanism for building enterprise applications.

Swarm

Docker Engine 1.12 includes swarm mode for natively managing a cluster of Docker Engines called a swarm.

https://docs.docker.com/engine/swarm/key-concepts/

 

Summary

The technology around docker is still evolving & its early in the docker journey so unless you want to run on bleeding edge technology it seems sensible not to jump in without fully understanding and appreciating the risk/rewards on offer. If you do want to take the leap i would strongly advise looking at the case studies in the useful videos section.

don't think as containers as vm (and don't try and replicate what you do in Vm in containers)

you have to know how you application works to make the most of containers , just dumping it in with no changes will have limited impact

Hello world

from Hello world docker example

root@docker-512mb-lon1-01:~# docker run ubuntu echo "hello world"
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
bd97b43c27e3: Pull complete
6960dc1aba18: Pull complete
2b61829b0db5: Pull complete
1f88dc826b14: Pull complete
73b3859b1e43: Pull complete
Digest: sha256:ea1d854d38be82f54d39efe2c67000bed1b03348bcc2f3dc094f260855dff368
Status: Downloaded newer image for ubuntu:latest
hello world

root@docker-512mb-lon1-01:~# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu latest 7b9b13f7b9c0 2 days ago 118 MB

root@docker-512mb-lon1-01:~# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f453bf23201d ubuntu "echo 'hello world'" 2 minutes ago Exited (0) 2 minutes ago loving_shirley

root@docker-512mb-lon1-01:~# docker version
Client:
Version: 17.03.0-ce
API version: 1.26
Go version: go1.7.5
Git commit: 60ccb22
Built: Thu Feb 23 10:57:47 2017
OS/Arch: linux/amd64

Server:
Version: 17.03.0-ce
API version: 1.26 (minimum version 1.12)
Go version: go1.7.5
Git commit: 60ccb22
Built: Thu Feb 23 10:57:47 2017
OS/Arch: linux/amd64
Experimental: false
root@docker-512mb-lon1-01:~#

Diagrams

Using Brendon Gregg use method for troubleshooting (note i would advise watching his Video under useful videos to understand how to  troubleshoot containers)

An example of how a hypervisor v a docker setup works

taken from Docker?!? But I'm a SYSADMIN!

Useful Videos

 

Best video i have found Docker?!? But I'm a SYSADMIN!
Case Study 1 Docker 0 to 60 in 5 Months: How a Traditional Fortune 40 Company Turns on a Dime
Case Study 2 Taking Docker from Local To Production at Intuit
Case Study 3 Docker at Shopify: From This-Looks-Fun to Production
Docker con 2017 General Session Day 1
Another great video from Brendan Gregg troubleshooting Containers Container Performance Analysis
Hello world docker example
Good intro to containers from another stand point Docker and Container Apps on Oracle Bare Metal Cloud OOW16