Level Up Your Java Container Images
summary
Docker images are just layered tarballs that unpack into a root filesystem and run as normal Linux processes using namespaces and cgroups, so inspect with docker info/images/inspect to see lowerdir merged upperdir and remember upperdir is ephemeral and use volumes for persistent data. Kubernetes shifts runtimes away from Docker to containerd and runc. Avoid image bloat by using multi-stage builds, .dockerignore, and not shipping Maven in production images. For Java prefer java 8 update 131 or Java 11 so the JVM is container-aware, and run processes as nonroot and set resource limits; host a private registry (JFrog, etc.) for reliable image access.
AI-written summary · about
chapters (25)
- 0:00Introduction
- 0:45Welcome
- 1:36Melissas Background
- 3:37Agenda
- 4:15Bananas
- 5:47Limits on Time
- 7:58History
- 11:13What Happened
- 12:08Container Run Times
- 13:49What is Docker
- 14:45Why Docker is so strong
- 15:16What we need
- 17:54History Lesson
- 20:36Alternatives
- 24:22My Experience with Containers
- 25:41Docker Info
- 26:29Docker Images
- 28:25Docker Pruning
- 29:12Gotchas
- 29:24Running as root
- 30:54No constraints
- 31:29Never updating
- 32:26Java 7 8
- 33:37Image Bloat
- 36:19Managing Your Images
related talks
01h 01mDistilling Java Containers for Kubernetes
49mJava and Containers Make it Awesome
48mJava in Containers - Part Deux
46mJava in Container - Best Practicies for containerized Java Apps
46mDockerfiles, Buildpacks, Jib and more, best way to run Java code in Containers?
40mJdeps, Jlink and Layers: Slim Down Your Java Docker Images
49mJava Container Mastery: Optimizing Images Across Build Tools
49mDockerfiles, Jib ..., what's the best way to run your Java code in Containers?
