Compare commits
2 Commits
3eb8eacd1d
...
78b3826cbb
Author | SHA1 | Date |
---|---|---|
Nicolai Ort | 78b3826cbb | |
Nicolai Ort | c471e24340 |
|
@ -0,0 +1,40 @@
|
|||
---
|
||||
title: Is your image really distroless?
|
||||
weight:7
|
||||
---
|
||||
|
||||
Laurent Goderre from Docker.
|
||||
The entire talk was very short, but it was a nice demo of init containers
|
||||
|
||||
## Baseline
|
||||
|
||||
* Security is hard - distroless sounds like a nice helper
|
||||
* Basic Challenge: Usability-Security Dilemma -> But more usability doesn't mean less secure, but more updating
|
||||
* Distro: Kernel + Software Packages + Package manager (optional) -> In Containers just without the kernel
|
||||
* Distroless: No package manager, no shell, no webcluent (curl/wget) - only minimal sofware bundels
|
||||
|
||||
## Tools for distroless image creation
|
||||
|
||||
* Multi-Stage Builds: No cleanup needed and better caching
|
||||
* Buildkit: More complex, but a pluggable build architecture
|
||||
|
||||
## The title question
|
||||
|
||||
* Well many images don't include a package manager, but a shell and some tools (busybox)
|
||||
* Tools are usually included as config-time tools (init) -> They just stay around after init - unused
|
||||
* Solution: Our lord and savior init containers without any inbound traffic that just does config stuff
|
||||
|
||||
## Demo
|
||||
|
||||
* A (rough) distroless postgres with alpine build step and scratch final step
|
||||
* A basic pg:alpine container used for init with a shared data volume
|
||||
* The init uses the pg admin user to initialize the pg server (you don't need the admin creds after this)
|
||||
|
||||
### Kube
|
||||
|
||||
* K apply failed b/c no internet, but was fixed by connecting to wifi
|
||||
* Without the init container the pod just crashes, with the init container the correct config gets created
|
||||
|
||||
### Docker compose
|
||||
|
||||
* Just use `service_completed_successfully` condition in depends on
|
|
@ -0,0 +1,29 @@
|
|||
---
|
||||
title: Networking
|
||||
weight: 99
|
||||
---
|
||||
|
||||
Who have I talked to today, are there any follow-ups or learnings?
|
||||
|
||||
## Operator Framework
|
||||
|
||||
* We talked about the operator lifecycle manager
|
||||
* They shared the roadmap and the new release 1.0 will bring support for Operator Bundle loading from any oci source (no more public-registry enforcement)
|
||||
|
||||
## Flux
|
||||
|
||||
* We talked about automatic helm release updates (lessons learned from flux)[/lessons_learned/02_flux]
|
||||
|
||||
## Cloudfoundry/Paketo
|
||||
|
||||
* We mostly had some smalltalk
|
||||
* There will be a cloudfoundry day in Karlsruhe in October, they'd be happy to have us ther
|
||||
* The whole KORFI (Cloudfoundry on Kubernetes) Project is still going strong, but no release canidate yet (or in the near future)
|
||||
|
||||
## Traefik
|
||||
|
||||
{{% notice style="note" %}}
|
||||
They will follow up
|
||||
{{% /notice %}}
|
||||
|
||||
* We mostly talked about traefik hub as an API-portal
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
title: Flux
|
||||
weight: 2
|
||||
---
|
||||
|
||||
Some lessonslearned from flux talsk and from talking to the flux team.
|
||||
|
||||
## Helm Autupdate
|
||||
|
||||
* Currently you can just use the normal image autoupdate machanism
|
||||
* Requirement: The helm chart is stored as a OCI-Artifact
|
||||
* How: Just create the usual CRs and annotations
|
||||
* They are also working on generalizing the autoupdate Process to fitt all OCI articacts (comming soon)
|
Loading…
Reference in New Issue