DevOpsDays Warsaw 2019 - Adam Kozłowski - Kubernetes buildpacks - from a source code to...

### Overview In this DevOpsDays Warsaw 2019 presentation, Adam Kozłowski, a technical leader at Grape Up and Certified Kubernetes Administrator, discusses using Cloud Native Buildpacks (buildpacks.io) to replicate the developer experience of Cloud Foundry's `cf push` on Kubernetes. Buildpacks transform application source code into runnable OCI-compliant container artifacts at a high level of abstraction, shielding developers from the complexities and security pitfalls of handcrafting Dockerfiles. Kozłowski presents an in-cluster proof of concept that runs the `pack` CLI inside a privileged Docker-in-Docker (dind) pod to package, build, push, and deploy a containerized application directly to Kubernetes.

### Key Topics - **Cloud Foundry Developer Experience**: The historic appeal of platforms like Cloud Foundry and Heroku lies in developer abstraction, exemplified by Onsi's haiku: *"Here's my source code, run it on the cloud for me, I don't care how."* Developers run simple push commands without needing to manage infrastructure or Dockerfiles. - **Origins and Evolution of Buildpacks**: Originally created by Heroku, buildpacks were subsequently adapted by Pivotal for Cloud Foundry (CF Linux FS). Pivotal and Heroku later joined forces under the open-source Buildpacks.io initiative to establish a unified specification generating standard OCI-compliant container images compatible with Docker and CRI runtimes. - **Security and Compliance Challenges in Docker**: While Docker is easy to adopt initially, developers frequently pull unvetted public images without vetting versions, updates, compliance, or base image security. Buildpacks address this by decoupling the build lifecycle and runtime images into maintained, vetted layers. - **Pros and Cons of Buildpacks.io**: Key benefits include OCI compliance, an easy-to-use `pack` CLI, and out-of-the-box support for languages such as Python, Java, Go, Node.js, PHP, Ruby, and .NET Core. Disadvantages highlighted by Kozłowski include sparse documentation, large base builder image downloads (~2 GB), local Docker daemon prerequisites, and concurrency issues with caching across multiple containers.

### Technical Details - **Buildpack Lifecycle Phases**: The build process executes through defined stages: analyzing source code, detecting applicable buildpacks, building layers, and exporting artifacts on top of a secure base run image. - **Cluster-Based Build Pipeline**: To remove the requirement for developers to have Docker installed locally on enterprise workstations, Grape Up built a proof of concept running the `pack` build workflow inside Kubernetes: 1. A Kubernetes pod runs a Docker-in-Docker (dind) container in privileged mode with dedicated Docker storage. 2. Source code is archived and transferred into the builder container using `kubectl cp`. 3. The local Docker daemon inside the pod is started manually. 4. The `pack build` command executes against a configured builder (e.g., Cloud Foundry's `cflinuxfs3` or Heroku-18). 5. For Python workloads, the lifecycle detects and applies the Python runtime buildpack and the pip buildpack (resolving dependencies from `requirements.txt`). 6. Layers (launcher, application code, runtime, dependencies) are assembled into an OCI container image and pushed to a container registry (e.g., Docker Hub or Harbor). 7. The script deploys the application using `kubectl apply` with a dry-run manifest pattern, exposes it via a ClusterIP service, attaches a Traefik ingress resource, and cleans up the builder pod using an exit trap.

### Takeaways Cloud Native Buildpacks allow engineering organizations to bring streamlined PaaS developer workflows to Kubernetes environments while centralizing control over base images, dependencies, and container standards. By packaging the `pack` build tool within an in-cluster Docker-in-Docker execution flow, teams can automate artifact generation and workload deployment directly on Kubernetes without enforcing local Docker installations across developer workstations.