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.
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.
The last 5(ish) times I presented DockerCoins, I ended up
explaining it slightly differently. While the application
is building, I explain what it does and its architecture
(instead of watching the build and pointing out, 'oh look
there is ruby... and python...') and I found that it
worked better. It may also be better for shorter
workshops, because we can deliver useful information
while the app is building (instead of filling with
a tapdancing show).
@bretfisher and @bridgetkromhout, do you like the new
flow for that section? If not, I can figure something
out so that we each have our own section here, but I
hope you will actually like this one better. :)
Committing straight to master since this file
is not used by @bridgetkromhout, and people use
that file by cloning the repo (so it has to be
merged in master for people to see it).
HASHTAG YOLO
We have images on the Docker Hub for the various components
of dockercoins. Let's add one slide explaining how to use that,
for people who would be lost or would have issues with their
registry, so that they can catch up.
In some cases, I would like Prometheus to be pre-installed (so that
it shows a bunch of metrics) without relying on people doing it (and
setting up Helm correctly). This patch allows to run:
./workshopctl helmprom TAG
It will setup Helm with a proper service account, then deploy
the Pormetheus chart, disabling the alert manager, persistence,
and assigning the Prometheus server to NodePort 30090.
This command is idempotent.
kubectl run is being deprecated as a multi-purpose tool.
This PR replaces 'kubectl run' with 'kubectl create deployment'
in most places (except in the very first example, to reduce the
cognitive load; and when we really want a single-shot container).
It also updates the places where we use a 'run' label, since
'kubectl create deployment' uses the 'app' label instead.
NOTE: this hasn't gone through end-to-end testing yet.
