<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Containers on PG Blog</title><link>https://pg-blogs.netlify.app/tags/containers/</link><description>Recent content in Containers on PG Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 03 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://pg-blogs.netlify.app/tags/containers/index.xml" rel="self" type="application/rss+xml"/><item><title>Production-Grade Docker Images for Java</title><link>https://pg-blogs.netlify.app/posts/6-production-grade-docker-images-for-java/</link><pubDate>Fri, 03 Jul 2026 00:00:00 +0000</pubDate><guid>https://pg-blogs.netlify.app/posts/6-production-grade-docker-images-for-java/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;A Java &lt;code&gt;Dockerfile&lt;/code&gt; can be three lines and technically work — or it can be a 700 MB image that runs as root, rebuilds from scratch on every code change, and gets OOM-killed under load. The difference is a handful of well-understood practices.&lt;/p&gt;
&lt;p&gt;This post walks through building Java images that are &lt;strong&gt;small, secure, cache-friendly, and container-aware&lt;/strong&gt;.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="start-from-a-slim-current-jre--not-a-jdk"&gt;Start From a Slim, Current JRE — Not a JDK&lt;/h2&gt;
&lt;p&gt;You need a JDK to &lt;em&gt;build&lt;/em&gt;, but only a JRE to &lt;em&gt;run&lt;/em&gt;. Shipping a full JDK bloats the image and widens the attack surface.&lt;/p&gt;</description></item><item><title>Production-Grade Docker Images for Python</title><link>https://pg-blogs.netlify.app/posts/7-production-grade-docker-images-for-python/</link><pubDate>Fri, 03 Jul 2026 00:00:00 +0000</pubDate><guid>https://pg-blogs.netlify.app/posts/7-production-grade-docker-images-for-python/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;The typical first-draft Python &lt;code&gt;Dockerfile&lt;/code&gt; — &lt;code&gt;FROM python&lt;/code&gt;, &lt;code&gt;COPY . .&lt;/code&gt;, &lt;code&gt;pip install -r requirements.txt&lt;/code&gt; — produces an image that is close to a gigabyte, reinstalls every dependency whenever a single source file changes, and runs as root with a Python process that ignores &lt;code&gt;SIGTERM&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;This post covers how to fix all of that: &lt;strong&gt;small images, cached dependency installs, a non-root runtime, and clean shutdowns.&lt;/strong&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="pick-the-right-base-image"&gt;Pick the Right Base Image&lt;/h2&gt;
&lt;p&gt;&lt;code&gt;python:3.12-slim&lt;/code&gt; is the pragmatic default: a Debian-based image with Python but without the large build toolchain. Avoid the full &lt;code&gt;python:3.12&lt;/code&gt; (hundreds of MB of tools you don&amp;rsquo;t run) and be cautious with &lt;code&gt;alpine&lt;/code&gt; — its &lt;code&gt;musl&lt;/code&gt; libc frequently breaks or slows down packages with C extensions (NumPy, pandas, database drivers), forcing slow source builds.&lt;/p&gt;</description></item></channel></rss>