Continuous Delivery with Containers: The Good, the Bad, and the Ugly
summary
A Jenkins-based pipeline builds Java apps into a single image artifact (multistage Docker builds), pushes images to registries (Docker Hub, JFrog, Nexus), and runs functional, performance (Gatling/JMeter) and security checks (OWASP, dependency-check, Clair). Surprising gotchas include the JVM misreading CPU limits from cgroups and dev/random blocks in containers causing crypto hangups; fixes are JVM/cgroup tuning and using urandom. Test-sidecars, Telepresence and Kubernetes/Helm orchestration prove the approach works but demand early Ops/InfoSec involvement and metadata signing for safe deploys.
AI-written summary · about
chapters (18)
- 0:00Intro
- 0:29Containers: Expectations versus reality
- 1:43Setting the scene
- 12:30Microservices multiply the challenges
- 14:09Make your dev environment like production
- 15:52Lesson learned: Dockerfile content is super important
- 19:10Docker multi-stage builds
- 22:50Storing in an image registry (DockerHub)
- 25:02Metadata - Adding Labels at build time
- 26:03Metadata - Adding Labels at runtime
- 28:06Component testing
- 29:00Testing individual containers
- 30:23Integration testing
- 32:16Testing NFRs in the build pipeline
- 41:27Mechanical sympathy: Docker and Java
- 46:58Deployment
- 47:31Observability is core to continuous delivery
- 51:01Bedtime reading
related talks
40mContinuous Delivery with Containers: The Good, the Bad, and the Ugly
47mContinuous Delivery with Containers: The Good, Bad, & Ugly
49mContinuous Delivery at Docker age
41mContinuous Delivery with Docker Containers and Java EE
52mBringing Continuous Delivery to Cloud-Scale with Jenkins, Docker and
31mBuilding a private CI/CD pipeline with Java and Docker in the Cloud
34mContinuous Delivery with Jenkins Workflow
06mBuilding Continuous Delivery Pipelines