mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-02-14 09:39:56 +00:00
Intro to containers, January 2019 update
This is a bunch of changes that I had staged, + a few typo fixes after going through the deck to check its readiness. There are no deep changes; just a few extra slides (e.g. about Kata containers and gVisor, and about services meshes) and typo fixes.
This commit is contained in:
@@ -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
|
## Section summary
|
||||||
|
|
||||||
We've learned how to:
|
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)
|
* [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/)
|
||||||
@@ -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,
|
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.
|
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
|
## View the logs of a container
|
||||||
|
|||||||
@@ -67,7 +67,8 @@ The following list is not exhaustive.
|
|||||||
|
|
||||||
Furthermore, we limited the scope to Linux containers.
|
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 ...
|
## Overall ...
|
||||||
|
|
||||||
* The Docker Engine is very developer-centric:
|
* 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
|
- Docker is a good default choice
|
||||||
|
|
||||||
- If you use Kubernetes, the engine doesn't matter
|
- If you use Kubernetes, the engine doesn't matter
|
||||||
|
|
||||||
|
|||||||
@@ -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,
|
||||||
|
<br/>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!)
|
||||||
|
|||||||
@@ -169,5 +169,5 @@ Would we give the same answers to the questions on the previous slide?
|
|||||||
|
|
||||||
class: pic
|
class: pic
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
|
|||||||
@@ -66,14 +66,6 @@ class: pic
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
class: pic
|
|
||||||
|
|
||||||
## Multiple containers sharing the same image
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Differences between containers and images
|
## Differences between containers and images
|
||||||
|
|
||||||
* An image is a read-only filesystem.
|
* An image is a read-only filesystem.
|
||||||
@@ -88,6 +80,14 @@ class: pic
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
class: pic
|
||||||
|
|
||||||
|
## Multiple containers sharing the same image
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## Comparison with object-oriented programming
|
## Comparison with object-oriented programming
|
||||||
|
|
||||||
* Images are conceptually similar to *classes*.
|
* 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
|
This namespace holds images which are not hosted on Docker Hub, but on third
|
||||||
party registries.
|
party registries.
|
||||||
@@ -233,6 +233,13 @@ localhost:5000/wordpress
|
|||||||
* `localhost:5000` is the host and port of the registry
|
* `localhost:5000` is the host and port of the registry
|
||||||
* `wordpress` is the name of the image
|
* `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?
|
## 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 that the same version will be used everywhere.
|
||||||
* To ensure repeatability later.
|
* To ensure repeatability later.
|
||||||
|
|
||||||
|
This is similar to what we would do with `pip install`, `npm install`, etc.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Section summary
|
## Section summary
|
||||||
|
|||||||
@@ -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`),
|
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
|
these common images will be pulled only once per node, so they are
|
||||||
virtually "free."
|
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.
|
||||||
|
|||||||
@@ -243,58 +243,76 @@ Scheduling = deciding which hypervisor to use for each VM.
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
class: pic
|
||||||
|
|
||||||
## Scheduling with one resource
|
## Scheduling with one resource
|
||||||
|
|
||||||
.center[]
|
.center[]
|
||||||
|
|
||||||
Can we do better?
|
## Can we do better?
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
class: pic
|
||||||
|
|
||||||
## Scheduling with one resource
|
## Scheduling with one resource
|
||||||
|
|
||||||
.center[]
|
.center[]
|
||||||
|
|
||||||
Yup!
|
## Yup!
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
class: pic
|
||||||
|
|
||||||
## Scheduling with two resources
|
## Scheduling with two resources
|
||||||
|
|
||||||
.center[]
|
.center[]
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
class: pic
|
||||||
|
|
||||||
## Scheduling with three resources
|
## Scheduling with three resources
|
||||||
|
|
||||||
.center[]
|
.center[]
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
class: pic
|
||||||
|
|
||||||
## You need to be good at this
|
## You need to be good at this
|
||||||
|
|
||||||
.center[]
|
.center[]
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
class: pic
|
||||||
|
|
||||||
## But also, you must be quick!
|
## But also, you must be quick!
|
||||||
|
|
||||||
.center[]
|
.center[]
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
class: pic
|
||||||
|
|
||||||
## And be web scale!
|
## And be web scale!
|
||||||
|
|
||||||
.center[]
|
.center[]
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
class: pic
|
||||||
|
|
||||||
## And think outside (?) of the box!
|
## And think outside (?) of the box!
|
||||||
|
|
||||||
.center[]
|
.center[]
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
class: pic
|
||||||
|
|
||||||
## Good luck!
|
## Good luck!
|
||||||
|
|
||||||
.center[]
|
.center[]
|
||||||
|
|||||||
@@ -157,8 +157,8 @@ Places to Look:
|
|||||||
|
|
||||||
- Good Windows Container Blogs and How-To's
|
- 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/)
|
- Docker Captain [Stefan Scherer](https://stefanscherer.github.io/)
|
||||||
|
|||||||
Reference in New Issue
Block a user