pre lunch break

content/day2/07_is_your_image_distroless.md

@@ -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

content/day2/99_networking.md

@@ -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

content/lessons_learned/02_flux.md

@@ -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)