mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-07-18 20:39:17 +00:00
A batch of fix for 3rd day
This commit is contained in:
@@ -39,6 +39,7 @@ chapters:
|
||||
- k8s/helm-create-basic-chart.md
|
||||
- k8s/helm-create-better-chart.md
|
||||
- k8s/helm-secrets.md
|
||||
|
||||
-
|
||||
# - k8s/shippingimages.md # some overlap
|
||||
- k8s/registries.md
|
||||
@@ -52,14 +53,10 @@ chapters:
|
||||
- k8s/devs-and-ops-joined-topics.md
|
||||
|
||||
-
|
||||
#- k8s/prometheus-intro.md
|
||||
- k8s/prometheus-endpoint.md
|
||||
- k8s/exercise-prometheus.md
|
||||
- k8s/opentelemetry.md
|
||||
- k8s/exercise-opentelemetry.md
|
||||
|
||||
|
||||
-
|
||||
- k8s/kubernetes-security.md
|
||||
#-
|
||||
# - k8s/rollout.md
|
||||
|
||||
@@ -4,9 +4,9 @@
|
||||
|
||||
- Self-hosted CI for kubernetes
|
||||
|
||||
- Testing in namespace, feature branch
|
||||
|
||||
<!-- FIXME explain what the line above means? -->
|
||||
- create a namespace per commit and apply manifests in the namespace
|
||||
</br>
|
||||
"A deploy per feature-branch"
|
||||
|
||||
.small[
|
||||
```shell
|
||||
@@ -27,15 +27,12 @@ helm install gitlab gitlab/gitlab
|
||||
```
|
||||
|
||||
---
|
||||
## Tekton / knative
|
||||
|
||||
- knative is serverless project from google
|
||||
## ArgoCD / flux
|
||||
|
||||
- Tekton leverages knative to run pipelines
|
||||
- Watch a git repository and apply changes to kubernetes
|
||||
|
||||
---
|
||||
|
||||
## ArgoCD
|
||||
- provide UI to see changes, rollback
|
||||
|
||||
.small[
|
||||
```shell
|
||||
@@ -43,7 +40,12 @@ kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manif
|
||||
```
|
||||
]
|
||||
|
||||
<!--
|
||||
FIXME I think we should add some details about these projects,
|
||||
otherwise it feels like an enumeration
|
||||
-->
|
||||
---
|
||||
|
||||
## Tekton / knative
|
||||
|
||||
- knative is serverless project from google
|
||||
|
||||
- Tekton leverages knative to run pipelines
|
||||
|
||||
- not really user friendly today, but stay tune for wrappers/products
|
||||
|
||||
@@ -13,7 +13,9 @@
|
||||
---
|
||||
## Kaniko
|
||||
|
||||
*kaniko doesn't depend on a Docker daemon and executes each command
|
||||
- https://github.com/GoogleContainerTools/kaniko
|
||||
|
||||
- *kaniko doesn't depend on a Docker daemon and executes each command
|
||||
within a Dockerfile completely in userspace*
|
||||
|
||||
- Kaniko is only a build system, there is no runtime like docker does
|
||||
@@ -21,3 +23,12 @@ within a Dockerfile completely in userspace*
|
||||
- generates OCI compatible image, so could be run on Docker or other CRI
|
||||
|
||||
- use a different cache system than Docker
|
||||
|
||||
---
|
||||
## Rootless docker and rootless buildkit
|
||||
|
||||
- This is experimental
|
||||
|
||||
- Have a lot of requirement of kernel param, options to set
|
||||
|
||||
- But it exists
|
||||
|
||||
@@ -163,9 +163,17 @@ Can we do better?
|
||||
|
||||
---
|
||||
|
||||
## Skaffold
|
||||
## Helpers
|
||||
|
||||
- Skaffold (https://skaffold.dev/):
|
||||
- build with docker, kaniko, google builder
|
||||
- install with pure yaml manifests, kustomize, helm
|
||||
|
||||
Note: Draft and Forge are softwares with some functional overlap
|
||||
- Tilt (https://tilt.dev/)
|
||||
- Titfile is programmatic format (python ?)
|
||||
- Primitive for building with docker
|
||||
- Primitive for deploying with pure yaml manifestsn kustomize, helm
|
||||
|
||||
<!-- FIXME Draft semble à l'abandon. Il y a aussi Tilt Garden ... -->
|
||||
- Garden (https://garden.io/)
|
||||
|
||||
- Forge (https://forge.sh/)
|
||||
|
||||
@@ -1,3 +1,34 @@
|
||||
# sealed-secrets
|
||||
|
||||
TODO
|
||||
- https://github.com/bitnami-labs/sealed-secrets
|
||||
|
||||
- has a server side (standard kubernetes deployment) and a client side *kubeseal* binary
|
||||
|
||||
- server-side start by generating a key pair, keep the private, expose the public.
|
||||
|
||||
- To create a sealed-secret, you only need access to public key
|
||||
|
||||
- You can enforce access with RBAC rules of kubernetes
|
||||
|
||||
---
|
||||
|
||||
## sealed-secrets how to
|
||||
|
||||
- adding a secret: *kubeseal* will cipher it with the public key
|
||||
|
||||
- server side controller will re-create original secret, when the ciphered one are added to the cluster
|
||||
|
||||
- it "safe" to add those secret to your source tree
|
||||
|
||||
- since version 0.9 key rotation are enable by default, so remember to backup private keys regularly.
|
||||
</br> (or you won't be able to decrypt all you keys, in a case of *disaster recovery*)
|
||||
|
||||
---
|
||||
|
||||
# Alternative: sops / git crypt
|
||||
|
||||
- You can work a VCS level (ie totally abstracted from kubernetess)
|
||||
|
||||
- sops (https://github.com/mozilla/sops), VCS agnostic, encrypt portion of files
|
||||
|
||||
- git-crypt that work with git to transparently encrypt (some) files in git
|
||||
|
||||
Reference in New Issue
Block a user