diff --git a/slides/containers/Ambassadors.md b/slides/containers/Ambassadors.md index 261b866d..9da6327b 100644 --- a/slides/containers/Ambassadors.md +++ b/slides/containers/Ambassadors.md @@ -156,6 +156,36 @@ Different deployments will use different underlying technologies. --- +## Service meshes + +* A service mesh is a configurable network layer. + +* It can provide service discovery, high availablity, load balancing, observability... + +* Service meshes are particularly useful for microservices applications. + +* Service meshes are often implemented as proxies. + +* Applications connect to the service mesh, which relays the connection where needed. + +*Does that sound familiar?* + +--- + +## Ambassadors and service messhes + +* When using a service mesh, a "sidecar container" is often used as a proxy + +* Our services connect (transparently) to that sidecar container + +* That sidecar container figures out where to forward the traffic + +... Does that sound familiar? + +(It should, because service meshes are essentially app-wide or cluster-wide ambassadors!) + +--- + ## Section summary We've learned how to: @@ -168,3 +198,10 @@ For more information about the ambassador pattern, including demos on Swarm and * [SwarmWeek video about Swarm+Compose](https://youtube.com/watch?v=qbIvUvwa6As) +Some services meshes and related projects: + +* [Istio](https://istio.io/) + +* [Linkerd](https://linkerd.io/) + +* [Gloo](https://gloo.solo.io/) \ No newline at end of file diff --git a/slides/containers/Background_Containers.md b/slides/containers/Background_Containers.md index b540d7bf..f99b2414 100644 --- a/slides/containers/Background_Containers.md +++ b/slides/containers/Background_Containers.md @@ -144,6 +144,10 @@ At a first glance, it looks like this would be particularly useful in scripts. However, if we want to start a container and get its ID in a reliable way, it is better to use `docker run -d`, which we will cover in a bit. +(Using `docker ps -lq` is prone to race conditions: what happens if someone +else, or another program or script, starts another container just before +we run `docker ps -lq`?) + --- ## View the logs of a container diff --git a/slides/containers/Container_Engines.md b/slides/containers/Container_Engines.md index 0deff1bc..7cc01ae3 100644 --- a/slides/containers/Container_Engines.md +++ b/slides/containers/Container_Engines.md @@ -67,7 +67,8 @@ The following list is not exhaustive. Furthermore, we limited the scope to Linux containers. -Containers also exist (sometimes with other names) on Windows, macOS, Solaris, FreeBSD ... +We can also find containers (or things that look like containers) on other platforms +like Windows, macOS, Solaris, FreeBSD ... --- @@ -155,6 +156,36 @@ We're not aware of anyone using it directly (i.e. outside of Kubernetes). --- +## Kata containers + +* OCI-compliant runtime. + +* Fusion of two projects: Intel Clear Containers and Hyper runV. + +* Run each container in a lightweight virtual machine. + +* Requires to run on bare metal *or* with nested virtualization. + +--- + +## gVisor + +* OCI-compliant runtime. + +* Implements a subset of the Linux kernel system calls. + +* Written in go, uses a smaller subset of system calls. + +* Can be heavily sandboxed. + +* Can run in two modes: + + * KVM (requires bare metal or nested virtualization), + + * ptrace (no requirement, but slower). + +--- + ## Overall ... * The Docker Engine is very developer-centric: @@ -174,4 +205,3 @@ We're not aware of anyone using it directly (i.e. outside of Kubernetes). - Docker is a good default choice - If you use Kubernetes, the engine doesn't matter - diff --git a/slides/containers/Container_Network_Model.md b/slides/containers/Container_Network_Model.md index 8bcf72cf..7f73a64c 100644 --- a/slides/containers/Container_Network_Model.md +++ b/slides/containers/Container_Network_Model.md @@ -721,3 +721,20 @@ eth0 Link encap:Ethernet HWaddr 02:42:AC:15:00:03 ... ``` ] + +--- + +class: extra-details + +## Building with a custom network + +* We can build a Dockerfile with a custom network with `docker build --network NAME`. + +* This can be used to check that a build doesn't access the network. + + (But keep in mind that most Dockerfiles will fail, +
because they need to install remote packages and dependencies!) + +* This may be used to access an internal package repository. + + (But try to use a multi-stage build instead, if possible!) diff --git a/slides/containers/Ecosystem.md b/slides/containers/Ecosystem.md index 20c892e9..4e14f577 100644 --- a/slides/containers/Ecosystem.md +++ b/slides/containers/Ecosystem.md @@ -169,5 +169,5 @@ Would we give the same answers to the questions on the previous slide? class: pic -![Cloud Native Landscape](https://raw.githubusercontent.com/cncf/landscape/master/landscape/CloudNativeLandscape_latest.png) +![Cloud Native Landscape](https://landscape.cncf.io/images/landscape.png) diff --git a/slides/containers/Initial_Images.md b/slides/containers/Initial_Images.md index af22371b..8cff4e41 100644 --- a/slides/containers/Initial_Images.md +++ b/slides/containers/Initial_Images.md @@ -66,14 +66,6 @@ class: pic --- -class: pic - -## Multiple containers sharing the same image - -![layers](images/sharing-layers.jpg) - ---- - ## Differences between containers and images * An image is a read-only filesystem. @@ -88,6 +80,14 @@ class: pic --- +class: pic + +## Multiple containers sharing the same image + +![layers](images/sharing-layers.jpg) + +--- + ## Comparison with object-oriented programming * Images are conceptually similar to *classes*. @@ -216,7 +216,7 @@ clock --- -## Self-Hosted namespace +## Self-hosted namespace This namespace holds images which are not hosted on Docker Hub, but on third party registries. @@ -233,6 +233,13 @@ localhost:5000/wordpress * `localhost:5000` is the host and port of the registry * `wordpress` is the name of the image +Other examples: + +```bash +quay.io/coreos/etcd +gcr.io/google-containers/hugo +``` + --- ## How do you store and manage images? @@ -352,6 +359,8 @@ Do specify tags: * To ensure that the same version will be used everywhere. * To ensure repeatability later. +This is similar to what we would do with `pip install`, `npm install`, etc. + --- ## Section summary diff --git a/slides/containers/Multi_Stage_Builds.md b/slides/containers/Multi_Stage_Builds.md index ed4625cd..8f0f572b 100644 --- a/slides/containers/Multi_Stage_Builds.md +++ b/slides/containers/Multi_Stage_Builds.md @@ -293,3 +293,23 @@ We can achieve even smaller images if we use smaller base images. However, if we use common base images (e.g. if we standardize on `ubuntu`), these common images will be pulled only once per node, so they are virtually "free." + +--- + +## Build targets + +* We can also tag an intermediary stage with `docker build --target STAGE --tag NAME` + +* This will create an image (named `NAME`) corresponding to stage `STAGE` + +* This can be used to easily access an intermediary stage for inspection + + (Instead of parsing the output of `docker build` to find out the image ID) + +* This can also be used to describe multiple images from a single Dockerfile + + (Instead of using multiple Dockerfiles, which could go out of sync) + +* Sometimes, we want to inspect a specific intermediary build stage. + +* Or, we want to describe multiple images using a single Dockerfile. diff --git a/slides/containers/Orchestration_Overview.md b/slides/containers/Orchestration_Overview.md index 5be67d90..f223e80f 100644 --- a/slides/containers/Orchestration_Overview.md +++ b/slides/containers/Orchestration_Overview.md @@ -243,58 +243,76 @@ Scheduling = deciding which hypervisor to use for each VM. --- +class: pic + ## Scheduling with one resource .center[![Not-so-good bin packing](images/binpacking-1d-1.gif)] -Can we do better? +## Can we do better? --- +class: pic + ## Scheduling with one resource .center[![Better bin packing](images/binpacking-1d-2.gif)] -Yup! +## Yup! --- +class: pic + ## Scheduling with two resources .center[![2D bin packing](images/binpacking-2d.gif)] --- +class: pic + ## Scheduling with three resources .center[![3D bin packing](images/binpacking-3d.gif)] --- +class: pic + ## You need to be good at this .center[![Tangram](images/tangram.gif)] --- +class: pic + ## But also, you must be quick! .center[![Tetris](images/tetris-1.png)] --- +class: pic + ## And be web scale! .center[![Big tetris](images/tetris-2.gif)] --- +class: pic + ## And think outside (?) of the box! .center[![3D tetris](images/tetris-3.png)] --- +class: pic + ## Good luck! .center[![FUUUUUU face](images/fu-face.jpg)] diff --git a/slides/containers/Windows_Containers.md b/slides/containers/Windows_Containers.md index 6b090882..0053cb77 100644 --- a/slides/containers/Windows_Containers.md +++ b/slides/containers/Windows_Containers.md @@ -157,8 +157,8 @@ Places to Look: - Good Windows Container Blogs and How-To's - - Dockers DevRel [Elton Stoneman, Microsoft MVP](https://blog.sixeyed.com/) + - Docker DevRel [Elton Stoneman, Microsoft MVP](https://blog.sixeyed.com/) - - Docker Captian [Nicholas Dille](https://dille.name/blog/) + - Docker Captain [Nicholas Dille](https://dille.name/blog/) - Docker Captain [Stefan Scherer](https://stefanscherer.github.io/)