Files
container.training/slides
Jerome Petazzoni a95e5c960e Make build and push optional
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.
2018-12-06 20:21:14 -06:00
..
2018-10-29 20:38:01 -05:00
2018-12-06 20:21:14 -06:00
2018-11-19 20:51:52 +01:00
2018-11-28 01:45:49 +01:00
2017-11-15 23:41:14 +01:00
2018-11-26 16:55:47 +01:00
2018-11-30 23:37:53 +01:00
2018-10-30 16:42:43 -05:00
2018-10-30 16:42:43 -05:00
2018-10-30 16:42:43 -05:00
2018-10-30 16:42:43 -05:00
2018-04-09 13:18:25 -05:00
2017-11-03 18:31:06 -07:00
2017-11-03 18:31:06 -07:00
2017-11-08 10:41:56 -08:00
2017-11-03 18:31:06 -07:00
2018-09-29 02:18:03 +02:00

MarkMaker

General principles:

  • each slides deck is described in a YAML manifest;
  • the YAML manifest lists a number of Markdown files that compose the slides deck;
  • a Python script "compiles" the YAML manifest into a HTML file;
  • that HTML file can be displayed in your browser (you don't need to host it), or you can publish it (along with a few static assets) if you want.

Getting started

Look at the YAML file corresponding to the deck that you want to edit. The format should be self-explanatory.

I (Jérôme) am still in the process of fine-tuning that format. Once I settle for something, I will add better documentation.

Make changes in the YAML file, and/or in the referenced Markdown files. If you have never used Remark before:

  • use --- to separate slides,
  • use .foo[bla] if you want bla to have CSS class foo,
  • define (or edit) CSS classes in workshop.css.

After making changes, run ./build.sh once; it will compile each foo.yml file into foo.yml.html.

You can also run ./build.sh forever: it will monitor the current directory and rebuild slides automatically when files are modified.

Publishing pipeline

Each time we push to master, a webhook pings Netlify, which will pull the repo, build the slides (by running build.sh once), and publish them to http://container.training/.

Pull requests are automatically deployed to testing subdomains. I had no idea that I would ever say this about a static page hosting service, but it is seriously awesome. 💥

Extra bells and whistles

You can run ./slidechecker foo.yml.html to check for missing images and show the number of slides in that deck. It requires phantomjs to be installed. It takes some time to run so it is not yet integrated with the publishing pipeline.