content/day2/07_is_your_image_distroless.md

@@ -1,40 +0,0 @@
----
-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

@@ -1,29 +0,0 @@
----
-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

@@ -1,13 +0,0 @@
----
-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)