Many small fixes + update on registries

slides/k8s/on-desktop.md

@@ -114,15 +114,15 @@ volumes:
 - Kubernetes-in-Docker
 
 - Uses Docker-in-Docker to run Kubernetes
-
-- Technically, it's more like Containerd-in-Docker
+  <br/>
+  (technically, it's more like Containerd-in-Docker)
 
 - We don't get a real Docker Engine (and cannot build Dockerfiles)
 
 - Single-node by default, but multi-node clusters are possible
 
 - Very convenient to test Kubernetes deployments when only Docker is available
-
+  <br/>
   (e.g. on public CI services like Travis, Circle, GitHub Actions ...)
 
 - Bind mounts require extra configuration

slides/k8s/registries.md

@@ -1,81 +1,99 @@
 # Registries
 
-There is lot of options to ship you container image to a registry
+- There are lots of options to ship our container images to a registry
 
-Those can be group in different categories:
+- We can group them depending on some characteristics:
 
-- hosted / selfhosted
+- SaaS or self-hosted
 
-- with / without build system
+- with or without a build system
 
 ---
+
 ## Docker registry
 
-- [open-source](https://github.com/docker/distribution) and self-hosted
+- Self-hosted and [open source](https://github.com/docker/distribution)
 
-- Simple docker-based registry
+- Runs in a single Docker container
 
-- Support multiple storage backend
+- Supports multiple storage backends
 
-- Only support basic-authentification
+- Supports basic authentication out of the box
+
+- [Other authentication schemes](https://docs.docker.com/registry/deploying/#more-advanced-authentication) through proxy or delegation
 
 - No build system
 
-```shell
-docker run -d -p 5000:5000 --name registry registry:2
-```
-or the dedicated plugin in minikube, microk8s, ...
+- To run it with the Docker engine:
+
+  ```shell
+  docker run -d -p 5000:5000 --name registry registry:2
+  ```
+
+- Or use the dedicated plugin in minikube, microk8s, etc.
 
 ---
+
 ## Harbor
 
-- [open-source](https://github.com/goharbor/harbor) and self-hosted
+- Self-hostend and [open source](https://github.com/goharbor/harbor)
 
-- full-featured registry docker/helm registry
+- Supports both Docker images and Helm charts
 
-- advanced authentification mechanism
+- Advanced authentification mechanism
 
-- multi-site synchronisation
+- Multi-site synchronisation
 
-- vulnerability scanning
+- Vulnerability scanning
 
-- No build-system
+- No build system
 
-```shell
-helm repo add harbor https://helm.goharbor.io
-helm install my-release harbor/harbor
-```
+- To run it with Helm:
+  ```shell
+  helm repo add harbor https://helm.goharbor.io
+  helm install my-release harbor/harbor
+  ```
 
 ---
+
 ## Gitlab
 
-- Some part [open-source](https://gitlab.com/gitlab-org/gitlab-foss/) and self-hosted
+- Available both as a SaaS product and self-hosted
 
-- Or hosted: gitlab.com (free for opensource project, payed subscription otherwise)
+- SaaS product is free for open source projects; paid subscription otherwise
 
-- CI integrated (so in a way: build-system integrated)
+- Some parts are [open source](https://gitlab.com/gitlab-org/gitlab-foss/)
 
-```shell
-helm repo add gitlab https://charts.gitlab.io/
-helm install gitlab gitlab/gitlab
-```
+- Integrated CI
+
+- No build system (but a custom build system can be hooked to the CI)
+
+- To run it with Helm:
+  ```shell
+  helm repo add gitlab https://charts.gitlab.io/
+  helm install gitlab gitlab/gitlab
+  ```
 
 ---
-## Docker HUB
 
-- hosted: [hub.docker.com](https://hub.docker.com)
+## Docker Hub
 
-- free for public image, payed subscription for private ones.
+- SaaS product: [hub.docker.com](https://hub.docker.com)
 
-- build-system included
+- Free for public image; paid subscription for private ones
+
+- Build system included
 
 ---
+
 ## Quay
 
-- hosted (quay.io)[https://quay.io]
+- Available both as a SaaS product (Quay) and self-hosted ([quay.io](https://quay.io))
 
-- free for public repository, payed subscription otherwise
+- SaaS product is free for public repositories; paid subscription otherwise
 
-- acquired by Redhat from CoreOS, opensourced recently (so self-hosted to ?)
+- Some components of Quay and quay.io are open source
 
-- build-system included
+  (see [Project Quay](https://www.projectquay.io/) and the [announcement](https://www.redhat.com/en/blog/red-hat-introduces-open-source-project-quay-container-registry))
+
+- Build system included

slides/k8s/stop-manual.md

@@ -1,17 +1,17 @@
 # Automation && CI/CD
 
-We already achieved:
+What we've done so far:
 
-- Find a way to Develop our application
+- development of our application
 
-- Test it manualy, and explore the way to write automated test for it
+- manual testing, and exploration of automated testing strategies
 
-- Package it the way we wanted it
+- packaging in a container image
 
-- Ship the image to a registry
+- shipping that image to a registry
 
-We now have to:
+What still need to be done:
 
-- Deploy it
+- deployment of our application
 
-And so each time is made a change on the repository. Can we automate this a little bit ?
+- automation of the whole build / ship / run cycle

slides/k8s/testing.md

@@ -1,14 +1,24 @@
 # Testing
 
-There are multiple levels of testing. At this point we will focus on
+There are multiple levels of testing:
 
-*unit-testing*, ([Just Say No to More End-to-End Tests](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html))
+- unit testing (many small tests that run in isolation),
 
-where system interaction are ideally *mocked* everywhere (no real database, no real backend).
+- integration testing (bigger tests involving multiple components),
 
-Sadly this is easier said that to be done...
+- functional or end-to-end testing (even bigger tests involving the whole app).
+
+In this section, we will focus on *unit testing*, where each test case
+should (ideally) be completely isolated from other components and system
+interaction: no real database, no real backend, *mocks* everywhere.
+
+(For a good discussion on the merits of unit testing, we can read
+[Just Say No to More End-to-End Tests](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html).)
+
+Unfortunately, this ideal scenario is easier said than done ...
 
 ---
+
 ## Multi-stage build
 
 ```dockerfile
@@ -26,12 +36,14 @@ RUN <build code>
 CMD, EXPOSE ...
 ```
 
-- If code don't change, test don't run, leveraging the docker cache
+- This leverages the Docker cache: it the code doesn't change, the tests don't need to run
 
-- Could use `docker build --network` to make database or backend available during build
+- If the tests require a database or other backend, we can use `docker build --network`
+
+- If the tests fail, the build fails; and no image is generated
 
-- But no artifact(image) generated if build fails
 ---
+
 ## Docker Compose
 
 ```yaml
@@ -56,12 +68,15 @@ docker-compose build && docker-compose run project pytest -v
 ```
 
 ---
+
 ## Skaffold/Container-structure-test
 
 - The `test` field of the `skaffold.yaml` instructs skaffold to run test against your image.
 
 - It uses the [container-structure-test](https://github.com/GoogleContainerTools/container-structure-test)
 
-- It allows to run custom command
+- It allows to run custom commands
 
-- Sadly nothing to run other docker image to make a database or a backend reachable
+- Unfortunately, nothing to run other Docker images
+
+  (to start a database or a backend that we need to run tests)