diff --git a/slides/3.yml b/slides/3.yml index 9197d887..57124015 100644 --- a/slides/3.yml +++ b/slides/3.yml @@ -16,20 +16,25 @@ chapters: - shared/title.md - shared/toc.md - - - | # Bien démarrer en local (minikube, kind) - - k8s/namespaces.md - - k8s/localkubeconfig.md - - k8s/accessinternal.md + # - k8s/kube-coin-intro.md + - k8s/softwar-dev-banalities.md + - k8s/on-desktop.md + - k8s/testing.md + - k8s/accessinternal.md + #- k8s/localkubeconfig.md #- k8s/kubectlproxy.md + - k8s/namespaces.md + - - - | - # (Industrialiser) - - k8s/volumes.md - k8s/configuration.md + - k8s/sealed-secrets.md - k8s/kustomize.md - k8s/helm.md - k8s/create-chart.md + +# - + #- k8s/volumes.md #- k8s/create-more-charts.md - - | diff --git a/slides/k8s/helm.md b/slides/k8s/helm.md index 5c895daa..dc9f2780 100644 --- a/slides/k8s/helm.md +++ b/slides/k8s/helm.md @@ -22,8 +22,6 @@ - `helm` is a CLI tool -- `tiller` is its companion server-side component - - A "chart" is an archive containing templatized YAML bundles - Charts are versioned diff --git a/slides/k8s/on-desktop.md b/slides/k8s/on-desktop.md new file mode 100644 index 00000000..6b8664fa --- /dev/null +++ b/slides/k8s/on-desktop.md @@ -0,0 +1,133 @@ +# Development Workflow + +In this section we will see how to get started with local development workflow, + +We will list multiple options, yet not all tools are mandatory. + +It's up to the developer to find what's best suit him/her. + +--- +## What does it mean to develop on kubernetes ? + +The generic workflow is: + +- (1) Change code or Dockerfile in one repository + +- (2) Build the docker image with a new tag + +- (3) Push the docker image to a registry + +- (4) Edit the yamls/templates corresponding to the deployment of the docker image + +- (5) Apply the yamls/templates + +- (6) Check if you're satisfied, if no repeat from 1 (or 4 if image is ok) + +- (7) Commit and push + +--- +## A few quirks + +Looking more precisely to the workflow, it's quite complicated + +- Need to have docker container registry that the cluster can access. + + (If you work a opensource project then a free account on DockerHub could just work) + +- Need scripting new tag creation + +- or use `imagePullPolicy=Always` to force image pull, then kill the appropriate pods + +- Require high broadband bandwidth and lot of time to push lot of images + +- Requires a registry's clean-up phase to avoid messy situations of left-over tags + +--- +## Benefits with developping locally + +Some of those problem could be solved using a local one-node cluster: + +- Using the node itself to build the image avoid pushing over network + +- No need of a registry + + or use a local-registry inside the cluster to avoid requiring broadband access + +- Can use bind mounts to make code change directly available in containers + +--- + +## Minikube + +- start a VM with the hypervisor of your choice: virtualbox, kvm, hyperv, ... + +- well supported by the kubernetes community + +- lot of addons + +- easy cleanup: delete the VM ! (`minikube delete`) + +- Bind mounts depends on the underlying hypervisor, and may require additionnal setup + +--- +## Docker-for-Mac/Windows + +- start a VM with the appropriate hypervisor (even better !) + +- bind mount works out of the box + +```yaml +volumes: +- name: repo_dir + hostPath: + path: /C/Users/Enix/my_code_repository +``` + +- ingress and other addons need to be installed manualy + +--- +## Kind + +- Use docker-in-docker to run kubernetes + +- It's actually more "containerd-in-docker" than real "d-in-d" + + So building "Dockerfile" is not a option + +- Able to simulate multiple nodes + +→ Kind is quite handy to test kubernetes deployments on Public CI (Travis/Circle) + where only docker is available + +- Extra configuration for bind mount + +- Extra configuration for a couple of addons, totally custom for other + +- Warning brtfs user: that doesn't work 😢 + +--- +## microk8s + +- snap(container like) distribution of kubernetes + +- work on: Ubuntu and derivative, or Ubuntu VM + +- big list of addons easy to install + +- bind mount work natively, need extra setup if you use a VM + +--- +## Proper tooling + +We ran our neat one-node-cluster. What do we do now ? + +- find the remote docker endpoint and export the DOCKER_HOST variable + +- follow the previous 7-steps workflow + +Can we do better ? +--- +## Skaffold + + +Note: Draft and Forge are softwares with some functional overlap diff --git a/slides/k8s/software-dev-banalities.md b/slides/k8s/software-dev-banalities.md new file mode 100644 index 00000000..1d41a050 --- /dev/null +++ b/slides/k8s/software-dev-banalities.md @@ -0,0 +1,15 @@ +# Software development + +From years, decades, (centuries !), software development has followed the same principles: + +- Development + +- Test + +- Package + +- Ship + +- Deploy + +We will see how this map to kubernetes world diff --git a/slides/k8s/testing.md b/slides/k8s/testing.md new file mode 100644 index 00000000..4923f485 --- /dev/null +++ b/slides/k8s/testing.md @@ -0,0 +1,67 @@ +# Testing + +There multiple levels of testing. At this point we will focus on + +*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)) + +where system interaction are ideally *mocked* everywhere (no real database, no real backend). + +Sadly this is easier said that to be done... + +--- +## Multi-stage build + +```dockerfile +FROM +RUN +COPY +RUN +RUN +COPY +RUN +FROM +RUN +COPY +RUN +CMD, EXPOSE ... +``` + +- If code don't change, test don't run, leveraging the docker cache + +- Could use `docker build --network` to make database or backend available during build + +- But no artifact(image) generated if build fails +--- +## Docker Compose + +```yaml +version: 3 +service: + project: + image: my_image_name + build: + context: . + target: dev + + database: + image: redis + backend: + image: backend + +``` ++ + +```shell +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 + +- Sadly nothing to run other docker image to make a database or a backend reachable