Containers: the journey to painless software deployments

Slides from my presentation at the Lagos Software Engineering Group meetup, in June.

Transcript

1. Containers The journey to painless deployments* *Terms and conditions apply
2. Deployment (noun) 1. the movement of troops or equipment to a place or position for military action. 2. the process of bringing resources into effective action. Definitions from Google
3. Deployment (noun) 1. the movement of troops or equipment to a place or position for military action. 2. the process of bringing resources code into effective action.
4. So, software deployments bring our code into effective action, by moving it from our development machines, to servers, where it can be used by our customers.
5. What kind of Servers?
6. • Shared: a single, multi-tenant* server, hosting many apps. Sometimes, a rude app could slow down the entire server for everyone. Not cool • Dedicated: one server per app. Safe from rude apps, but you could end up paying for more that you use. Also not cool • Virtual-Private Server: one server, shared by several tenants, using clever virtualisation technologies to isolate each tenant, so they don’t interfere with each other Multi-tenant means one server serves multiple customers
7. • Cloud: 
 Did we say servers? Stop thinking about servers, and start thinking about resources: memory, compute, storage - you want it, we’ve got it. Use as much or as little as you want, and you only pay for what you use.
 Very cool
8. So how do we deploy with no servers?
9. There are still servers. We just don’t care. The cloud is an abstraction for our infrastructure. And like other abstractions, it enables us reason about our software systems at a higher level. We can think about services and resources, instead of servers and hardware, just like our programming languages allow us think about functions and objects, instead of memory and registers.
10. Okay
11. But how do we deploy?
12. Deployment concerns • Packaging: collect our app and its dependencies into a single bundle, which we can ship to the cloud • Reproducibility: make our app run reliably on other machines, the same way it runs on ours • Isolation & Security: each app should believe it’s the only app on the cloud; apps should not be able to interfere with each other, or with their host • Cost: cheaper is better
13. Attempt 1: Full Virtualisation Run a program called a hypervisor, which shares the server’s hardware among multiple “guest” operating systems. Each app would be packaged, along with the guest OS and all its dependencies, and run on the server (the host OS). https://en.wikipedia.org/wiki/Virtual_machine
14. Attempt 1: Full Virtualisation
15. Virtualisation Scorecard • Packaging: check, but creates very large bundles. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle* • Reproducibility: check, so long as the server understands the VM image format • Isolation & Security: check • Cost: guest OS overhead means we aren’t using all our server resources for our apps, so we end up with fewer apps per ₦ *Quote repurposed (without permission) from Joe Armstrong
16. Attempt 2: Containers What if we could eliminate the guest OS, and have apps share the host OS, but run each app within its own “container”? 
 Each container would appear to the app as its own OS - apps would be completely isolated from each other.
17. Attempt 2: Containers Turns out that over the years, Linux has acquired several features that make this possible*: 1. Namespaces 2. Control Groups 3. Layered Filesystems https://dzone.com/articles/evolution-of-linux-containers-future
18. Attempt 2: Containers Namespaces determine what a process can see on the host. Linux provides the following namespaces: PID (each process can have its own view of running processes)
 MNT (each process can have its own filesystem)
 NET (each process can have its own network stack)
 UTS (each process can set its host and domain names)
 IPC
 USER (each process can have root-like access without actually being root)
 CGROUPS (can hide a process’s actual CGroups) https://en.wikipedia.org/wiki/Linux_namespaces
19. Attempt 2: Containers Control Groups (CGroups) determine what resources a process can use on the host. Fundamentally, they collect one or more PIDs (Process IDs) and apply limits to them. Where namespaces isolate a process, CGroups enforce fair resource sharing between processes. https://en.wikipedia.org/wiki/Cgroups
20. Attempt 2: Containers Namespaces and CGroups are the isolation and resource- sharing sides of containers. They’re the big metal sides and the security guard at the dock. Layered Filesystems are how we can efficiently move whole machine images around; they're why the ship floats rather than sinks. That’s all we’ll say about them, for now. https://www.infoq.com/articles/build-a-container-golang
21. Attempt 2: Containers Docker (developed by Docker Inc) uses the Linux features mentioned, to allow isolated “containers” run within a single Linux host, avoiding the guest OS overhead. It replaces the hypervisor with the Docker daemon - a background service on the host OS that manages interactions between the host and running containers.
22. Attempt 2: Containers
23. Containers Scorecard • Packaging: check - creates much smaller bundles than virtualisation (unless you’re Oracle) • Reproducibility: check • Isolation & Security: check • Cost: no more guest OS overhead - we can run more apps per ₦
24. Finally
25. Well, not exactly
26. Demo Package an app in a Docker image
27. The App • A simple Python web application, that returns a friendly greeting • One file, to keep things simple - focus on the packaging process, not the app • First, install Docker CE from: https://www.docker.com/ community-edition • Get the source code here: https://gist.github.com/ elo80ka/3f49eeb3d5beab0f37c1bb369cd6700e
28. Lets do this Create a directory called “first”, and type the code that follows
29. Save as code.py
30. Save as Dockerfile
31. Dockerfile • A text file that contains commands used to build a Docker image • Sent to the Docker daemon, along with a “context” - a set of files at a specified path or URL. Our context will be our app directory • FROM specifies the base image our new image will be built on. Our app is a Python app, so we specify a Python 3.6 base image • ADD copies our single source file, to the container working directory • CMD specifies the command to run when we run our container https://docs.docker.com/engine/reference/builder/#usage
32. Build it mac-n-cheese:first Chuchu$ docker build -t first:0.0.1 . Sending build context to Docker daemon 3.072kB Step 1/4 : FROM python:3.6.4-alpine3.7 ---> 02e54b114dbc Step 2/4 : WORKDIR /app ---> Using cache ---> 4bdc0ca98bc1 Step 3/4 : ADD code.py /app ---> Using cache ---> f2691fa42b7c Step 4/4 : CMD ["python", "/app/code.py"] ---> Running in aeb964f83ea8 Removing intermediate container aeb964f83ea8 ---> d12dff848b8b Successfully built d12dff848b8b Successfully tagged first:0.0.1 https://docs.docker.com/engine/reference/commandline/image_build/
33. Build it mac-n-cheese:first Chuchu$ docker images | grep first first 0.0.1 d12dff848b8b 55 seconds ago 84.2MB Remember that the 84.2mb includes Python and its dependencies
34. Run it mac-n-cheese:first Chuchu$ docker run --name first-run -p 8008:8008 -d first:0.0.1 3677dc778b821b119b8988f4852571fc5794f7e9184d8bd3f3ef16986d5de478 mac-n-cheese:first Chuchu$ docker ps | grep first 3677dc778b82 first:0.0.1 "python /app/code.py" Less than a second ago Up 4 seconds 0.0.0.0:8008->8008/tcp first-run
35. Test it Tested using HTTPie: https://httpie.org/
36. Stop it mac-n-cheese:first Chuchu$ docker stop first-run first-run mac-n-cheese:first Chuchu$ docker ps | grep first mac-n-cheese:first Chuchu$
37. Summary
38. • Containers are just groups of one or more processes, completely isolated from each other, and from the host system • To create a (Docker) container, you first package your app into an image • You can use Docker’s CLI (Command Line Interface) to build images and run them • You can run other images exactly the same way - check out Docker Store for lots of pre-built images, for common apps and services: https://store.docker.com/search? q=&type=image&source=verified • We’ve only just scratched the surface - there’s so much more to discover
39. Links • https://www.katacoda.com/courses/docker • https://www.katacoda.com/ • https://docs.docker.com/reference/
40. Now, we’re done