diff --git a/slides/containers/Macro_View.md b/slides/containers/Macro_View.md new file mode 100644 index 00000000..ab288f12 --- /dev/null +++ b/slides/containers/Macro_View.md @@ -0,0 +1,318 @@ + + +class: title + +# The Macroscopic View + +--- + +## Macroscopic Items + +* The business case for containers + +* The problem containers are solving + +* What applications need + +* What is the OS doing provides? + +--- + +## What do CIOs worry about? + +Who are the CIO's customers? + +* Business Units: Need Computers to Run Applications + * Peak Capacity + +* CFO: Demanding Budget Justifications + * Spend Less + +--- + +## History of Solutions + +For Each Business Application Buy a Machine + +* Buy a machine for each application + + * Big enough for Peak Load (CPU, Memory, Disk) + +The Age of VMs + +* Buy bigger machines and chop them up into logical machines + + * Distribute your applications as VMs theses machines + +* Observe what and when the application load actually is + + * Possibly rebalance be to inform possibly moving + +But Maintaining Machines (Bare Metal or VM) is hard (Patches, Packages, Drivers, etc) + +--- + +## What Developers and Ops worry about + +* Getting Software deployed + +* Mysterious reasons why deployed application doesn't work + + * Developer to Ops: + + * "Hey it works on my development machine..." + + * "I don't know why it isn't working for ***you***" + + * "Everything ***looks*** the same" + + * "I have no idea what could be different" + +--- + +## The History of Software Deployment + +Software Deployment is just a reproducible way to install files: + +* Cards + +* Tapes + +* Floppy Disks + +* Zip/Tar Files + +* Installation "Files" (rpm/deb/msi) + +* VM Images + +--- + +## What is the Problem Containers are Solving? + +It depends on who you are: + + * For the CIO: Better resource utilization + + * For Ops: Software Distribution + + * For the Developer & Ops: Reproducible Environment + +

+ +Ummm, but what exactly are containers.... + + * Wait a few more slides... + +--- + +## Macroscopic view: Applications and the OS + +Applications: + +* What are the inputs/outputs to a program? + +The OS: + +* What does the OS provide? + +--- + +## What are the inputs/outputs to a program? + +Explicitly: +* Command Line Arguments +* Environment Variables +* Standard In +* Standard Out/Err + +Implicitly (via the File System): + +* Configuration Files +* Other Installed Applications +* Any other files + +Also Implicitly + +* Memory +* Network + + +--- + + +## What does the OS provide? + +* OS Kernel + * Kernel loded at boot time + * Sets up disk drives, network cards, other hardware, etc + * Manages all hardware, processes, memory, etc + * Kernel Space + * Low level innards of Kernel (fluid internal API) + * No direct access by applications of most Kernel functionality + + +* User Space (userland) Processes + * Code running outside the Kernel + * Very stable shim library access from User Space to Kernel Space (Think "fopen") + +* The "init" Process + * User Space Process run after Kernel has booted + * Always PID 1 + +--- + +## OS Processes + +* Created when an application is launched + * Each has a unique Process ID (PID) + +* Provides it its own logical 'view' of all implicit inputs/output when launching app + * File System ( root directory, / ) + * Memory + * Network Adaptors + * Other running processes + +--- + +## What do we mean by "The OS" + +Different Linux's + +* Ubuntu / Debian; Centos / RHEL; Raspberry Pi; etc + +What do they have in common? + +* They all have a kernel that provides access to Userland (ie fopen) + +* They typically have all the commands (bash, sh, ls, grep, ...) + +What may be different? + +* May use different versions of the Kernel (4.18, 5.4, ...) + * Internally different, but providing same Userland API + +* Many other bundled commands, packages and package management tools + * Namely what makes it 'Debian' vs 'Centos' + +--- + +## What might a 'Minimal' Linux be? + +You could actually just have: + +* A Linux Kernel + +* An application (for simplicity a statically linked C program) + +* The kernel configured to run that application as its 'init' process + +Would you ever do this? + +* Why not? + + * It certainly would be very secure + +--- + +## So Finally... What are Containers? + +Containers just a Linux process that 'thinks' it is it's own machine + +* With its own 'view' of things like: + * File System ( root directory, / ), Memory, Network Adaptors, Other running processes + +* Leverages our understanding that a (logical) Linux Machine is + * A kernel + * A bunch of files ( Maybe a few Environment Variables ) + +Since it is a process running on a host machine + +* It uses the kernel of the host machine +* And of course you need some tools to create the running container process + +--- + +## Container Runtimes and Container Images + +The Linux kernel actually has no concept of a container. + +* There have been many 'container' technologies + +* See [A Brief History of containers: From the 1970's till now](https://blog.aquasec.com/a-brief-history-of-containers-from-1970s-chroot-to-docker-2016) + +* Over the years more capabilities have been added to the kernel to make it easier + +
+A 'Container technology' is: + +* A Container Image Format of the unit of software deployment + * A bundle of all the files and miscellaneous configuration + +* A Container Runtime Engine + * Software that takes a Container Image and creates a running container + +--- + +## The Container Runtime War is now Over + +The Cloud Native Computing Foundation (CNCF) has standardized containers + +* A standard container image format + +* A standard for building and configuring container runtimes + +* A standard REST API for loading/downloading container image to a registries + +There primary Container Runtimes are: + +* containerd: using the 'docker' Command Line Interface (or Kubernetes) + +* CRI-O: using the 'podman' Command Line Interface (or Kubernetes/OpenShift) + +* Others exists, for example Singularity which has a history in HPC + +--- + +## Linux Namespaces Makes Containers Possible + +- Provide processes with their own isolated view of the system. + + - Namespaces limit what you can see (and therefore, what you can use). + +- These namespaces are available in modern kernels: + + - pid: processes + - net: network + - mnt: root file system (ie chroot) + - uts: hostname + - ipc + - user: UID/GID mapping + - time: time + - cgroup: Resource Monitoring and Limiting + +- Each process belongs to one namespace of each type. + +--- + +## Namespaces are always active + +- Namespaces exist even when you don't use containers. + +- This is a bit similar to the UID field in UNIX processes: + + - all processes have the UID field, even if no user exists on the system + + - the field always has a value / the value is always defined +
+ (i.e. any process running on the system has some UID) + + - the value of the UID field is used when checking permissions +
+ (the UID field determines which resources the process can access) + +- You can replace "UID field" with "namespace" above and it still works! + +- In other words: even when you don't use containers, +
there is one namespace of each type, containing all the processes on the system. + diff --git a/slides/containers/Training_Environment_And_Tmux.md b/slides/containers/Training_Environment_And_Tmux.md new file mode 100644 index 00000000..ab5f190a --- /dev/null +++ b/slides/containers/Training_Environment_And_Tmux.md @@ -0,0 +1,224 @@ + +class: title + +# Our training environment + +![SSH terminal](images/title-our-training-environment.jpg) + + +--- + +class: in-person + +## Connecting to your Virtual Machine + +You need an SSH client. + +* On OS X, Linux, and other UNIX systems, just use `ssh`: + +```bash +$ ssh @ +``` + +* On Windows, if you don't have an SSH client, you can download: + + * Putty (www.putty.org) + + * Git BASH (https://git-for-windows.github.io/) + + * MobaXterm (https://mobaxterm.mobatek.net/) + +--- + +class: in-person + +## Connecting to our lab environment + +.lab[ + +- Log into your VM with your SSH client: + ```bash + ssh `user`@`A.B.C.D` + ``` + + (Replace `user` and `A.B.C.D` with the user and IP address provided to you) + + +] + +You should see a prompt looking like this: +``` +[A.B.C.D] (...) user@node1 ~ +$ +``` +If anything goes wrong — ask for help! + +--- +## Our Docker VM + +About the Lab VM + +- The VM is created just before the training. + +- It will stay up during the whole training. + +- It will be destroyed shortly after the training. + +- It comes pre-loaded with Docker and some other useful tools. + +--- + +## Why don't we run Docker locally? + +- I can log into your VMs to help you with labs + +- Installing docker is out of the scope of this class (lots of online docs) + + - It's better to spend time learning containers than fiddling with the installer! + +--- +class: in-person + +## `tailhist` + +- The shell history of the instructor is available online in real time + +- Note the IP address of the instructor's virtual machine (A.B.C.D) + +- Open http://A.B.C.D:1088 in your browser and you should see the history + +- The history is updated in real time (using a WebSocket connection) + +- It should be green when the WebSocket is connected + + (if it turns red, reloading the page should fix it) + +- If you want to play with it on your lab machine, tailhist is installed + + - sudo apt install firewalld + - sudo firewall-cmd --add-port=1088/tcp +--- + +## Checking your Virtual Machine + +Once logged in, make sure that you can run a basic Docker command: + +.small[ +```bash +$ docker version +Client: + Version: 18.03.0-ce + API version: 1.37 + Go version: go1.9.4 + Git commit: 0520e24 + Built: Wed Mar 21 23:10:06 2018 + OS/Arch: linux/amd64 + Experimental: false + Orchestrator: swarm + +Server: + Engine: + Version: 18.03.0-ce + API version: 1.37 (minimum version 1.12) + Go version: go1.9.4 + Git commit: 0520e24 + Built: Wed Mar 21 23:08:35 2018 + OS/Arch: linux/amd64 + Experimental: false +``` +] + +If this doesn't work, raise your hand so that an instructor can assist you! + +??? + +:EN:Container concepts +:FR:Premier contact avec les conteneurs + +:EN:- What's a container engine? +:FR:- Qu'est-ce qu'un *container engine* ? + + +--- + +## Doing or re-doing the workshop on your own? + +- Use something like + [Play-With-Docker](http://play-with-docker.com/) or + [Play-With-Kubernetes](https://training.play-with-kubernetes.com/) + + Zero setup effort; but environment are short-lived and + might have limited resources + +- Create your own cluster (local or cloud VMs) + + Small setup effort; small cost; flexible environments + +- Create a bunch of clusters for you and your friends + ([instructions](https://@@GITREPO@@/tree/master/prepare-vms)) + + Bigger setup effort; ideal for group training + +--- + +class: self-paced + +## Get your own Docker nodes + +- If you already have some Docker nodes: great! + +- If not: let's get some thanks to Play-With-Docker + +.lab[ + +- Go to http://www.play-with-docker.com/ + +- Log in + +- Create your first node + + + +] + +You will need a Docker ID to use Play-With-Docker. + +(Creating a Docker ID is free.) + +--- + +## Terminals + +Once in a while, the instructions will say: +
"Open a new terminal." + +There are multiple ways to do this: + +- create a new window or tab on your machine, and SSH into the VM; + +- use screen or tmux on the VM and open a new window from there. + +You are welcome to use the method that you feel the most comfortable with. + +--- + +## Tmux cheat sheet + +[Tmux](https://en.wikipedia.org/wiki/Tmux) is a terminal multiplexer like `screen`. + +*You don't have to use it or even know about it to follow along. +
+But some of us like to use it to switch between terminals. +
+It has been preinstalled on your workshop nodes.* + +- Ctrl-b c → creates a new window +- Ctrl-b n → go to next window +- Ctrl-b p → go to previous window +- Ctrl-b " → split window top/bottom +- Ctrl-b % → split window left/right +- Ctrl-b Alt-1 → rearrange windows in columns +- Ctrl-b Alt-2 → rearrange windows in rows +- Ctrl-b arrows → navigate to other windows +- Ctrl-b d → detach session +- tmux attach → re-attach to session diff --git a/slides/pp.yml b/slides/pp.yml index c6bb60b7..0fbc40d6 100644 --- a/slides/pp.yml +++ b/slides/pp.yml @@ -1,7 +1,7 @@ title: | Docker & Kubernetes -chat: "[Teams](#FIXME)" +chat: "Zoom" gitrepo: github.com/jpetazzo/container.training @@ -18,13 +18,16 @@ content: - containers/intro.md - shared/about-slides.md - shared/chat-room-im.md -- shared/chat-room-zoom-meeting.md -#- shared/chat-room-zoom-webinar.md -#- shared/toc.md +# - shared/chat-room-zoom-meeting.md +- shared/chat-room-zoom-webinar.md +- shared/toc.md - # DAY 1 #- containers/Docker_Overview.md #- containers/Docker_History.md - - containers/Training_Environment.md + - containers/Training_Environment_And_Tmux.md + - containers/Macro_View.md + # - containers/Macro_View_What_Is_The_Problem.md + # - containers/Macro_View_of_Apps_and_OS.md #- containers/Installing_Docker.md - containers/First_Containers.md - containers/Background_Containers.md