<?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 My personal blog</title>
		<link>https://jens.dev/tags/containers.html</link>
		<description>Recent content in Containers on My personal blog</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Sun, 28 Jun 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://jens.dev/tags/containers/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Shipping CPU-optimized Rust binaries in container images</title>
				<link>https://jens.dev/2026/06/28/cpu-optimized-container-images.html</link>
				<pubDate>Sun, 28 Jun 2026 00:00:00 +0000</pubDate>
				<guid>https://jens.dev/2026/06/28/cpu-optimized-container-images.html</guid>
				<description>&lt;p&gt;In an &lt;a href=&#34;https://jens.dev/2026/03/08/gguf-runner-update.html&#34;&gt;earlier post&lt;/a&gt; about gguf-runner I made a point that kept nagging at me afterwards.&lt;/p&gt;&#xA;&lt;p&gt;The point was this: prebuilt binaries are compiled for a conservative baseline so they run everywhere, and if you build locally with &lt;code&gt;target-cpu=native&lt;/code&gt; instead, the compiler can light up the SIMD instructions your specific CPU supports. On an AMD Ryzen 7 PRO 8700GE that was worth about &lt;strong&gt;+20.8% tokens/sec&lt;/strong&gt; for LLM inference. Real, measurable, free.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Building containers on Codeberg</title>
				<link>https://jens.dev/2026/03/15/building-containers-on-codeberg.html</link>
				<pubDate>Sun, 15 Mar 2026 00:00:00 +0000</pubDate>
				<guid>https://jens.dev/2026/03/15/building-containers-on-codeberg.html</guid>
				<description>&lt;p&gt;I have been moving more and more of my smaller projects over to Codeberg lately.&lt;/p&gt;&#xA;&lt;p&gt;For plain git hosting and Forgejo based CI, it is a very pleasant setup. The one area where I had to do a bit more work than expected was container builds.&lt;/p&gt;&#xA;&lt;p&gt;At first glance this looks like it should be boring:&lt;/p&gt;&#xA;&lt;ol&gt;&#xA;&lt;li&gt;write a &lt;code&gt;Dockerfile&lt;/code&gt;&lt;/li&gt;&#xA;&lt;li&gt;add a CI step&lt;/li&gt;&#xA;&lt;li&gt;build the image&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;p&gt;But on a hosted Codeberg runner this is exactly the type of thing where the defaults are not quite the defaults you may be used to from GitHub Actions or from your own machine.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Reaping some benefits of containerization</title>
				<link>https://jens.dev/2023/02/27/reaping-some-benefits.html</link>
				<pubDate>Mon, 27 Feb 2023 18:08:54 +0000</pubDate>
				<guid>https://jens.dev/2023/02/27/reaping-some-benefits.html</guid>
				<description>&lt;p&gt;We just started the migration and saw some impressive results very early on.&lt;/p&gt;&#xA;&lt;h3 id=&#34;deployment&#34;&gt;Deployment&lt;/h3&gt;&#xA;&lt;p&gt;We started with some very heavy custom scripting to deploy large composites. These composite container definitions for BW engines, SQL script, EMS definitions and file system deployment. Overall, this process became so complex that even a &amp;ldquo;simple&amp;rdquo; composite deployment could easily take 2-3 hours.&lt;/p&gt;&#xA;&lt;p&gt;By splitting the composite into containers and building our composite structure on top of Docker Compose, deployment times were now down to minutes (up to 5 minutes for container pulls and restarts). This is a huge improvement over existing deployment times.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Containerizing a BusinessWorks Stack</title>
				<link>https://jens.dev/2023/02/27/containerizing-businessworks.html</link>
				<pubDate>Mon, 27 Feb 2023 14:08:54 +0000</pubDate>
				<guid>https://jens.dev/2023/02/27/containerizing-businessworks.html</guid>
				<description>&lt;p&gt;Containerizing BusinessWorks 5 comes with its own set of challenges. Most of these are related to the surrounding ecosystem and the architectures that have evolved around it.&lt;/p&gt;&#xA;&lt;p&gt;In a classic scenario, a BusinessWorks engine runs within an administrator domain and reports its lifecycle through Hawk. Deployment of an engine is also typically handled by a combination of these tools.&lt;/p&gt;&#xA;&lt;p&gt;It is important to note that only BusinessWorks provides the interface implementations. The other tools are used to manage/monitor/maintain BW engines and keep them running.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Containerizing TIBCO BusinessWorks 5</title>
				<link>https://jens.dev/2020/08/09/containerizing-businessworks-5.html</link>
				<pubDate>Sun, 09 Aug 2020 10:08:54 +0000</pubDate>
				<guid>https://jens.dev/2020/08/09/containerizing-businessworks-5.html</guid>
				<description>&lt;h3 id=&#34;preparation&#34;&gt;Preparation&lt;/h3&gt;&#xA;&lt;p&gt;To prepare the container build, I downloaded the current versions of TRA/BW/EMS from the TIBCO &lt;a href=&#34;https://edelivery.tibco.com/&#34;&gt;edelivery platform&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;I downloaded the following artifacts:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;TIB_TRA_5.11.0_linux_x86_64.zip&lt;/li&gt;&#xA;&lt;li&gt;TIB_BW_5.14.0_linux26gl23_x86_64.zip&lt;/li&gt;&#xA;&lt;li&gt;TIB_rv_8.4.6_linux_x86.zip&lt;/li&gt;&#xA;&lt;li&gt;TIB_ems_8.5.1_linux_x86_64.zip&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Now to bring those together into a container I copied all of those into a &lt;code&gt;tibco-businessworks-runtime&lt;/code&gt; directory.&lt;/p&gt;&#xA;&lt;h3 id=&#34;installation&#34;&gt;Installation&lt;/h3&gt;&#xA;&lt;p&gt;To support a headless installation, the TIBCO universal installer uses silent files. I attached my silent file at the end of this post.&lt;/p&gt;&#xA;&lt;p&gt;The Dockerfile is also attached.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
