The slides didn't mention to clone the git repo containing
the Compose file for the ELK stack. This is now fixed.
Also, the version numbers were not all correctly set
in this Compose file. Also fixed.
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.
Consul 1.4 introduces Cloud auto-join, which finds the
IP addresses of the other nodes by querying an API (in
that case, the Kubernetes API).
This involves creating a service account and granting
permissions to list and get pods. It is a little bit
more complex, but it reuses previous notions (like RBAC)
so I like it better.
This reformulates the section where we run DockerCoins
to better explain why we use images (and how they are
essential to the "ship" part of the action), and it
tells upfront that it will be possible to use images
from the Docker Hub (and skip altogether the part where
we run our own registry and build and push images).
It also reshuffles section headers a bit, because that
part had a handful of really small sections. Now we
have:
- Shipping images with a registry
- Running our application on Kubernetes
I think that's better.
It also paves the way to make the entire self-hosted
registry part optional.
We show how to change namespace by creating a new context, then
switching to the new context. It works, but it is very cumbersome.
Instead, let's just update the current context, and give some
details about when it's better to update the current context, and
when it is better to use different contexts and hop between them.
This supersedes #399.
There was a bug in Kubernetes 1.12. It was fixed in 1.13.
Let's just mention the issue in one brief slide but not add
too much extra fluff about it.
In index.yaml, the date can now be specified as a range. For instance,
instead of:
date: 2018-11-28
We can use:
date: [2018-11-28, 2018-12-05]
For now, only the start date is shown (so the event still appears
as happening on 2018-11-28 in that example), but it will be considered
"current" (and show up in the list of "coming soon" events) until
the end date.
This way, when updating the content during a multi-day event, the
event stays in the top list and is not pushed to the "past events"
section.
Single-day events can still use the old syntax, of course.