diff --git a/slides/_redirects b/slides/_redirects new file mode 100644 index 00000000..66af9915 --- /dev/null +++ b/slides/_redirects @@ -0,0 +1 @@ +/ /kube-halfday.yml.html 200 diff --git a/slides/k8s/concepts-k8s.md b/slides/k8s/concepts-k8s.md index 78e524a3..6aceb2f9 100644 --- a/slides/k8s/concepts-k8s.md +++ b/slides/k8s/concepts-k8s.md @@ -171,11 +171,7 @@ class: pic --- -## Do we need to run Docker at all? - -No! - --- +## Default container runtime - By default, Kubernetes uses the Docker Engine to run containers @@ -185,42 +181,6 @@ No! (like CRI-O, or containerd) ---- - -## Do we need to run Docker at all? - -Yes! - --- - -- In this workshop, we run our app on a single node first - -- We will need to build images and ship them around - -- We can do these things without Docker -
- (and get diagnosed with NIH¹ syndrome) - -- Docker is still the most stable container engine today -
- (but other options are maturing very quickly) - -.footnote[¹[Not Invented Here](https://en.wikipedia.org/wiki/Not_invented_here)] - ---- - -## Do we need to run Docker at all? - -- On our development environments, CI pipelines ... : - - *Yes, almost certainly* - -- On our production servers: - - *Yes (today)* - - *Probably not (in the future)* - .footnote[More information about CRI [on the Kubernetes blog](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes)] --- @@ -235,11 +195,12 @@ Yes! - node (a machine — physical or virtual — in our cluster) - pod (group of containers running together on a node) + - IP addresses are associated with *pods*, not with individual containers - service (stable network endpoint to connect to one or multiple containers) - namespace (more-or-less isolated group of things) - secret (bundle of sensitive data to be passed to a container) - - And much more! + +- And much more! - We can see the full list by running `kubectl api-resources` @@ -250,25 +211,3 @@ Yes! class: pic ![Node, pod, container](images/k8s-arch3-thanks-weave.png) - ---- - -class: pic - -![One of the best Kubernetes architecture diagrams available](images/k8s-arch4-thanks-luxas.png) - ---- - -## Credits - -- The first diagram is courtesy of Weave Works - - - a *pod* can have multiple containers working together - - - IP addresses are associated with *pods*, not with individual containers - -- The second diagram is courtesy of Lucas Käldström, in [this presentation](https://speakerdeck.com/luxas/kubeadm-cluster-creation-internals-from-self-hosting-to-upgradability-and-ha) - - - it's one of the best Kubernetes architecture diagrams available! - -Both diagrams used with permission. diff --git a/slides/k8s/daemonset.md b/slides/k8s/daemonset.md index cf86bc36..a12d3613 100644 --- a/slides/k8s/daemonset.md +++ b/slides/k8s/daemonset.md @@ -268,7 +268,7 @@ The master node has [taints](https://kubernetes.io/docs/concepts/configuration/t - Check the logs of all the pods having a label `run=rng`: ```bash - kubectl logs -l run=rng --tail 1 + kubectl get pods -l run=rng -o name | xargs -n 1 kubectl logs --tail 1 ``` ] diff --git a/slides/k8s/ourapponkube.md b/slides/k8s/ourapponkube.md index 1f73c14e..d562dec2 100644 --- a/slides/k8s/ourapponkube.md +++ b/slides/k8s/ourapponkube.md @@ -4,22 +4,6 @@ Our app on Kube --- -## What's on the menu? - -In this part, we will: - -- **build** images for our app, - -- **ship** these images with a registry, - -- **run** deployments using these images, - -- expose these deployments so they can communicate with each other, - -- expose the web UI so we can access it from outside. - ---- - ## The plan - Build on our control node (`node1`) @@ -131,47 +115,6 @@ We should see: --- -## Testing our local registry - -- We can retag a small image, and push it to the registry - -.exercise[ - -- Make sure we have the busybox image, and retag it: - ```bash - docker pull busybox - docker tag busybox $REGISTRY/busybox - ``` - -- Push it: - ```bash - docker push $REGISTRY/busybox - ``` - -] - ---- - -## Checking again what's on our local registry - -- Let's use the same endpoint as before - -.exercise[ - -- Ensure that our busybox image is now in the local registry: - ```bash - curl $REGISTRY/v2/_catalog - ``` - -] - -The curl command should now output: -```json -{"repositories":["busybox"]} -``` - ---- - ## Building and pushing our images - We are going to use a convenient feature of Docker Compose diff --git a/slides/k8s/setup-k8s.md b/slides/k8s/setup-k8s.md index 171a9801..e4327d35 100644 --- a/slides/k8s/setup-k8s.md +++ b/slides/k8s/setup-k8s.md @@ -36,10 +36,6 @@ (At least ... not yet! Though it's [experimental in 1.12](https://kubernetes.io/docs/setup/independent/high-availability/).) --- - -- "It's still twice as many steps as setting up a Swarm cluster 😕" -- Jérôme - --- ## Other deployment options diff --git a/slides/k8s/whatsnext.md b/slides/k8s/whatsnext.md index 76d4d9ab..d6d597b8 100644 --- a/slides/k8s/whatsnext.md +++ b/slides/k8s/whatsnext.md @@ -1,26 +1,3 @@ -# Next steps - -*Alright, how do I get started and containerize my apps?* - --- - -Suggested containerization checklist: - -.checklist[ -- write a Dockerfile for one service in one app -- write Dockerfiles for the other (buildable) services -- write a Compose file for that whole app -- make sure that devs are empowered to run the app in containers -- set up automated builds of container images from the code repo -- set up a CI pipeline using these container images -- set up a CD pipeline (for staging/QA) using these images -] - -And *then* it is time to look at orchestration! - ---- - - ## Options for our first production cluster - Get a managed cluster from a major cloud provider (AKS, EKS, GKE...) @@ -57,26 +34,6 @@ And *then* it is time to look at orchestration! --- -## Namespaces - -- Namespaces let you run multiple identical stacks side by side - -- Two namespaces (e.g. `blue` and `green`) can each have their own `redis` service - -- Each of the two `redis` services has its own `ClusterIP` - -- CoreDNS creates two entries, mapping to these two `ClusterIP` addresses: - - `redis.blue.svc.cluster.local` and `redis.green.svc.cluster.local` - -- Pods in the `blue` namespace get a *search suffix* of `blue.svc.cluster.local` - -- As a result, resolving `redis` from a pod in the `blue` namespace yields the "local" `redis` - -.warning[This does not provide *isolation*! That would be the job of network policies.] - ---- - ## Stateful services (databases etc.) - As a first step, it is wiser to keep stateful services *outside* of the cluster @@ -236,16 +193,3 @@ Sorry Star Trek fans, this is not the federation you're looking for! - Discover resources across clusters ---- - -## Developer experience - -*We've put this last, but it's pretty important!* - -- How do you on-board a new developer? - -- What do they need to install to get a dev stack? - -- How does a code change make it from dev to prod? - -- How does someone add a component to a stack? diff --git a/slides/kube-halfday.yml b/slides/kube-halfday.yml index 9ec6a3f1..71ca8d1e 100644 --- a/slides/kube-halfday.yml +++ b/slides/kube-halfday.yml @@ -35,19 +35,18 @@ chapters: - - k8s/kubectlrun.md - k8s/kubectlexpose.md - k8s/ourapponkube.md - #- k8s/kubectlproxy.md - #- k8s/localkubeconfig.md - #- k8s/accessinternal.md + - k8s/kubectlproxy.md +# - k8s/localkubeconfig.md +# - k8s/accessinternal.md - - k8s/dashboard.md - k8s/kubectlscale.md - k8s/daemonset.md - k8s/rollout.md - - k8s/logs-cli.md -# Bridget hasn't added EFK yet - #- k8s/logs-centralized.md +# - k8s/logs-centralized.md - k8s/helm.md - k8s/namespaces.md - #- k8s/netpol.md + - k8s/netpol.md - k8s/whatsnext.md # - k8s/links.md # Bridget-specific diff --git a/slides/logistics-bridget.md b/slides/logistics-bridget.md index 9a4f38bb..da17a724 100644 --- a/slides/logistics-bridget.md +++ b/slides/logistics-bridget.md @@ -2,15 +2,30 @@ - Hello! We are: - - .emoji[✨] Bridget ([@bridgetkromhout](https://twitter.com/bridgetkromhout)) + - .emoji[✨] Bridget Kromhout ([@bridgetkromhout](https://twitter.com/bridgetkromhout)) - - .emoji[🌟] Joe ([@joelaha](https://twitter.com/joelaha)) + - .emoji[💁🏻‍♀️] Karen Chu ([@karenhchu](https://twitter.com/karenhchu)) -- The workshop will run from 13:30-16:45 + - .emoji[🌟] Ralph Squillace ([@ralph_squillace](https://twitter.com/ralph_squillace)) -- There will be a break from 15:00-15:15 + + +- The workshop will run from 9:00am - 12:30pm + +- There will be a break from 10:30am - 11:00am - Feel free to interrupt for questions at any time - *Especially when you see full screen container pictures!* +--- + +## Say hi! + +- We encourage networking at [#velocityconf](https://twitter.com/hashtag/velocityconf?f=tweets&vertical=default&src=hash) + +- Take a minute to introduce yourself to your neighbors + +- Tell them where you're from (where you're based out of & what org you work at) + +- Share what you're hoping to learn in this session! .emoji[✨] diff --git a/slides/shared/prereqs.md b/slides/shared/prereqs.md index 7840b527..8202497f 100644 --- a/slides/shared/prereqs.md +++ b/slides/shared/prereqs.md @@ -1,46 +1,4 @@ -# Pre-requirements - -- Be comfortable with the UNIX command line - - - navigating directories - - - editing files - - - a little bit of bash-fu (environment variables, loops) - -- Some Docker knowledge - - - `docker run`, `docker ps`, `docker build` - - - ideally, you know how to write a Dockerfile and build it -
- (even if it's a `FROM` line and a couple of `RUN` commands) - -- It's totally OK if you are not a Docker expert! - ---- - -class: title - -*Tell me and I forget.* -
-*Teach me and I remember.* -
-*Involve me and I learn.* - -Misattributed to Benjamin Franklin - -[(Probably inspired by Chinese Confucian philosopher Xunzi)](https://www.barrypopik.com/index.php/new_york_city/entry/tell_me_and_i_forget_teach_me_and_i_may_remember_involve_me_and_i_will_lear/) - ---- - -## Hands-on sections - -- The whole workshop is hands-on - -- We are going to build, ship, and run containers! - -- You are invited to reproduce all the demos +## Hands-on - All hands-on sections are clearly identified, like the gray rectangle below @@ -50,53 +8,10 @@ Misattributed to Benjamin Franklin - Go to @@SLIDES@@ to view these slides -- Join the chat room: @@CHAT@@ - - - ] ---- - -class: in-person - -## Where are we going to run our containers? - ---- - -class: in-person, pic - -![You get a cluster](images/you-get-a-cluster.jpg) - ---- - -class: in-person - -## You get a cluster of cloud VMs - - Each person gets a private cluster of cloud VMs (not shared with anybody else) -- They'll remain up for the duration of the workshop - -- You should have a little card with login+password+IP addresses - -- You can automatically SSH from one VM to another - -- The nodes have aliases: `node1`, `node2`, etc. - ---- - -class: in-person - -## Why don't we run containers locally? - -- Installing that stuff can be hard on some machines - - (32 bits CPU or OS... Laptops without administrator access... etc.) - -- *"The whole team downloaded all these container images from the WiFi! -
... and it went great!"* (Literally no-one ever) - - All you need is a computer (or even a phone or tablet!), with: - an internet connection @@ -109,203 +24,18 @@ class: in-person class: in-person -## SSH clients - -- On Linux, OS X, FreeBSD... you are probably all set - -- On Windows, get one of these: - - - [putty](http://www.putty.org/) - - Microsoft [Win32 OpenSSH](https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH) - - [Git BASH](https://git-for-windows.github.io/) - - [MobaXterm](http://mobaxterm.mobatek.net/) - -- On Android, [JuiceSSH](https://juicessh.com/) - ([Play Store](https://play.google.com/store/apps/details?id=com.sonelli.juicessh)) - works pretty well - -- Nice-to-have: [Mosh](https://mosh.org/) instead of SSH, if your internet connection tends to lose packets - ---- - -class: in-person, extra-details - -## What is this Mosh thing? - -*You don't have to use Mosh or even know about it to follow along. -
-We're just telling you about it because some of us think it's cool!* - -- Mosh is "the mobile shell" - -- It is essentially SSH over UDP, with roaming features - -- It retransmits packets quickly, so it works great even on lossy connections - - (Like hotel or conference WiFi) - -- It has intelligent local echo, so it works great even in high-latency connections - - (Like hotel or conference WiFi) - -- It supports transparent roaming when your client IP address changes - - (Like when you hop from hotel to conference WiFi) - ---- - -class: in-person, extra-details - -## Using Mosh - -- To install it: `(apt|yum|brew) install mosh` - -- It has been pre-installed on the VMs that we are using - -- To connect to a remote machine: `mosh user@host` - - (It is going to establish an SSH connection, then hand off to UDP) - -- It requires UDP ports to be open - - (By default, it uses a UDP port between 60000 and 61000) - ---- - -class: in-person - ## Connecting to our lab environment .exercise[ - Log into the first VM (`node1`) with your SSH client - - - Check that you can SSH (without password) to `node2`: ```bash ssh node2 ``` - Type `exit` or `^D` to come back to `node1` - - ] If anything goes wrong — ask for help! - ---- - -## 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 - -.exercise[ - -- 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.) - ---- - -## We will (mostly) interact with node1 only - -*These remarks apply only when using multiple nodes, of course.* - -- Unless instructed, **all commands must be run from the first VM, `node1`** - -- We will only checkout/copy the code on `node1` - -- During normal operations, we do not need access to the other nodes - -- If we had to troubleshoot issues, we would use a combination of: - - - SSH (to access system logs, daemon status...) - - - Docker API (to check running containers and container engine status) - ---- - -## 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 cheatsheet - -[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 → reattach to session diff --git a/slides/shared/sampleapp.md b/slides/shared/sampleapp.md index e96a4021..2d0425a6 100644 --- a/slides/shared/sampleapp.md +++ b/slides/shared/sampleapp.md @@ -77,79 +77,6 @@ and displays aggregated logs. --- -class: extra-details - -## Compose file format version - -*Particularly relevant if you have used Compose before...* - -- Compose 1.6 introduced support for a new Compose file format (aka "v2") - -- Services are no longer at the top level, but under a `services` section - -- There has to be a `version` key at the top level, with value `"2"` (as a string, not an integer) - -- Containers are placed on a dedicated network, making links unnecessary - -- There are other minor differences, but upgrade is easy and straightforward - ---- - -## Service discovery in container-land - -- We do not hard-code IP addresses in the code - -- We do not hard-code FQDN in the code, either - -- We just connect to a service name, and container-magic does the rest - - (And by container-magic, we mean "a crafty, dynamic, embedded DNS server") - ---- - -## Example in `worker/worker.py` - -```python -redis = Redis("`redis`") - - -def get_random_bytes(): - r = requests.get("http://`rng`/32") - return r.content - - -def hash_bytes(data): - r = requests.post("http://`hasher`/", - data=data, - headers={"Content-Type": "application/octet-stream"}) -``` - -(Full source code available [here]( -https://@@GITREPO@@/blob/8279a3bce9398f7c1a53bdd95187c53eda4e6435/dockercoins/worker/worker.py#L17 -)) - ---- - -class: extra-details - -## Links, naming, and service discovery - -- Containers can have network aliases (resolvable through DNS) - -- Compose file version 2+ makes each container reachable through its service name - -- Compose file version 1 did require "links" sections - -- Network aliases are automatically namespaced - - - you can have multiple apps declaring and using a service named `database` - - - containers in the blue app will resolve `database` to the IP of the blue database - - - containers in the green app will resolve `database` to the IP of the green database - ---- - ## What's this application? -- @@ -240,50 +167,6 @@ Stop the app with `^C`, edit `dockercoins.yml`, comment out the `volumes` sectio --- -class: extra-details - -## Why does the speed seem irregular? - -- It *looks like* the speed is approximately 4 hashes/second - -- Or more precisely: 4 hashes/second, with regular dips down to zero - -- Why? - --- - -class: extra-details - -- The app actually has a constant, steady speed: 3.33 hashes/second -
- (which corresponds to 1 hash every 0.3 seconds, for *reasons*) - -- Yes, and? - ---- - -class: extra-details - -## The reason why this graph is *not awesome* - -- The worker doesn't update the counter after every loop, but up to once per second - -- The speed is computed by the browser, checking the counter about once per second - -- Between two consecutive updates, the counter will increase either by 4, or by 0 - -- The perceived speed will therefore be 4 - 4 - 4 - 0 - 4 - 4 - 0 etc. - -- What can we conclude from this? - --- - -class: extra-details - -- "I'm clearly incapable of writing good frontend code!" 😀 — Jérôme - ---- - ## Stopping the application - If we interrupt Compose (with `^C`), it will politely ask the Docker Engine to stop the app diff --git a/slides/shared/thankyou.md b/slides/shared/thankyou.md index e383865f..1ada0ae4 100644 --- a/slides/shared/thankyou.md +++ b/slides/shared/thankyou.md @@ -4,8 +4,15 @@ Thank you! --- -class: title, in-person +# Thank you! -That's all, folks!
Questions? +- The clusters will be shut down tomorrow morning + +- If you like: + + - [rate this tutorial on the Velocity website](https://conferences.oreilly.com/velocity/vl-ny/public/schedule/evaluate/70102) + + - [tweet about it](https://twitter.com/intent/tweet?url=https%3A%2F%2Fcontainer.training&text=Learning%20k8s%20with%20@bridgetkromhout%21&hashtags=VelocityConf), mentioning @bridgetkromhout and #VelocityConf + + - [questions, comments, pull requests, workshop invitations, etc](https://github.com/jpetazzo/container.training/) -![end](images/end.jpg) diff --git a/slides/shared/title.md b/slides/shared/title.md index 4ab52435..b0c746c1 100644 --- a/slides/shared/title.md +++ b/slides/shared/title.md @@ -8,7 +8,13 @@ class: title, self-paced class: title, in-person -@@TITLE@@

+@@TITLE@@ + +WiFi: OReilly18
+Password: velocity + +
+
.footnote[ **Be kind to the WiFi!**