<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Docker on Martin Ahrer</title><link>https://www.martinahrer.at/tags/docker/</link><description>Recent content in Docker on Martin Ahrer</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 03 Dec 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://www.martinahrer.at/tags/docker/index.xml" rel="self" type="application/rss+xml"/><item><title>Building Docker Images with bake</title><link>https://www.martinahrer.at/2024/12/03/building-docker-images-with-bake/</link><pubDate>Tue, 03 Dec 2024 00:00:00 +0000</pubDate><guid>https://www.martinahrer.at/2024/12/03/building-docker-images-with-bake/</guid><description>&lt;div class="paragraph">
&lt;p>Platform engineers and build pipeline engineers constantly are faced with the challenge of building container images for providing images to be used as application base or for running pipeline tasks. Probably such images have to be provided as multiple variants for multiple versions of software packages to be included.&lt;/p>
&lt;/div></description></item><item><title>Docker Multiplatform Build</title><link>https://www.martinahrer.at/2024/09/12/docker-multiplatform-build/</link><pubDate>Thu, 12 Sep 2024 00:00:00 +0000</pubDate><guid>https://www.martinahrer.at/2024/09/12/docker-multiplatform-build/</guid><description>&lt;div class="paragraph">
&lt;p>The Arm CPU architecture is getting more and more popular even on desktop developer devices.&lt;/p>
&lt;/div>
&lt;div class="quoteblock">
&lt;blockquote>
A comparative analysis of Arm, AMD, and Intel costs in the Amazon cloud has shown that Graviton2 processors can be significantly more cost-efficient than other platforms. The study compared the 16xlarge instances based on the m6g (Graviton2, Arm), m5a (EPYC1, AMD), and m5n (Xeon Cascade Lake, Intel) for the 64-vCPU count. Not only are the Arm-based instances cheaper than AMD and Intel, they can achieve 40% better performance per dollar when translating the time to completion of SPEC tests to hours and multiplying the result by hourly cost.
&lt;/blockquote>
&lt;div class="attribution">
— https://bell-sw.com/blog/application-cost-reduction-with-arm-servers
&lt;/div></description></item><item><title>Google Container Tools - Jib</title><link>https://www.martinahrer.at/2020/04/19/google-container-tools-jib/</link><pubDate>Sun, 19 Apr 2020 00:00:00 +0000</pubDate><guid>https://www.martinahrer.at/2020/04/19/google-container-tools-jib/</guid><description>&lt;div class="paragraph">
&lt;p>With this post we close the &lt;a href="https://www.martinahrer.at/tags/building-docker-images/">series&lt;/a> of articles taking a deep dive on building Docker images.
We look at a building Docker images for running Java applications in a Docker container with &lt;a href="https://github.com/GoogleContainerTools/jib">Jib&lt;/a> which is part of the &lt;a href="https://github.com/GoogleContainerTools">Google Container Tools&lt;/a>.&lt;/p>
&lt;/div>
&lt;div class="sect1">
&lt;h2 id="_jib">Jib&lt;/h2>
&lt;div class="sectionbody">
&lt;div class="paragraph">
&lt;p>Jib is highly opinionated about building Java Docker containers using Maven or Gradle as build tool.
So it offers plugin support for the above mentioned build tools.&lt;/p>
&lt;/div></description></item><item><title>Docker BuildKit</title><link>https://www.martinahrer.at/2020/04/16/docker-buildkit/</link><pubDate>Thu, 16 Apr 2020 00:00:00 +0000</pubDate><guid>https://www.martinahrer.at/2020/04/16/docker-buildkit/</guid><description>&lt;div class="paragraph">
&lt;p>In the previous blog post of the building docker images series we had a look at Docker image build &lt;a href="https://www.martinahrer.at/code/docker-build-pipeline.html">pipelines&lt;/a>.
We revealed typical problems and looked at how to overcome some by utilizing multistage builds.&lt;/p>
&lt;/div>
&lt;div class="paragraph">
&lt;p>In part 4 of this series we work with an addition to the Docker tooling which is &lt;a href="https://docs.docker.com/develop/develop-images/build_enhancements/">BuildKit&lt;/a>.&lt;/p>
&lt;/div></description></item><item><title>Docker image build pipeline</title><link>https://www.martinahrer.at/2019/08/30/docker-image-build-pipeline/</link><pubDate>Fri, 30 Aug 2019 00:00:00 +0000</pubDate><guid>https://www.martinahrer.at/2019/08/30/docker-image-build-pipeline/</guid><description>&lt;div class="paragraph">
&lt;p>Let’s recap what we have covered in this blog post series so far.
In &lt;a href="https://www.martinahrer.at/code/docker-building-an-image.html">Building a Docker Image&lt;/a> we had a look at the anatomy of a Docker image.
And &lt;a href="https://www.martinahrer.at/code/docker-optimizing-build.html">Optimizing a Docker Image&lt;/a> shed some light on optimizations when building an image.&lt;/p>
&lt;/div></description></item><item><title>Optimizing a Docker Image</title><link>https://www.martinahrer.at/2019/08/20/optimizing-a-docker-image/</link><pubDate>Tue, 20 Aug 2019 00:00:00 +0000</pubDate><guid>https://www.martinahrer.at/2019/08/20/optimizing-a-docker-image/</guid><description>&lt;div class="paragraph">
&lt;p>This post continues where we left off with &lt;a href="https://www.martinahrer.at/code/docker-building-an-image.html">Building a Docker Image&lt;/a>.
We are looking into how we can optimize the process of building a Docker image.
This optimization can aim at reducing the size of images built or the time it takes for packaging an image.&lt;/p>
&lt;/div></description></item><item><title>Building a Docker Image</title><link>https://www.martinahrer.at/2019/08/17/building-a-docker-image/</link><pubDate>Sat, 17 Aug 2019 00:00:00 +0000</pubDate><guid>https://www.martinahrer.at/2019/08/17/building-a-docker-image/</guid><description>&lt;div class="paragraph">
&lt;p>This post starts a &lt;a href="https://www.martinahrer.at/tags/building-docker-images/">series&lt;/a> of articles taking a deep dive on building Docker images.
But before we look at building a Docker image let’s briefly recap the essentials we need to know about container images.&lt;/p>
&lt;/div>
&lt;div class="paragraph">
&lt;p>A Docker image is built up from a series of layers where each layer represents an instruction in the image’s Dockerfile.
When Docker materializes an image and creates a container from this image, a storage driver handles the details about the way these layers interact with each other.
Different &lt;a href="https://docs.docker.com/v17.09/engine/userguide/storagedriver/imagesandcontainers/">storage drivers&lt;/a> are available, which have advantages and disadvantages in different situations (e.g. AUFS, overlay, overlay2, btrfs,zfs).
All drivers have in common that they use stackable image layers and the copy-on-write (&lt;a href="https://en.wikipedia.org/wiki/Copy-on-write">CoW&lt;/a>) strategy for writing files.&lt;/p>
&lt;/div></description></item><item><title>Continuous delivery infrastructure as code</title><link>https://www.martinahrer.at/2017/05/10/continuous-delivery-infrastructure-as-code/</link><pubDate>Wed, 10 May 2017 00:00:00 +0000</pubDate><guid>https://www.martinahrer.at/2017/05/10/continuous-delivery-infrastructure-as-code/</guid><description>&lt;div id="preamble">
&lt;div class="sectionbody">
&lt;div class="paragraph">
&lt;p>This is part 1 of a series of posts covering Docker in a Continuous Delivery environment.&lt;/p>
&lt;/div>
&lt;div class="paragraph">
&lt;p>Today I’m showing how simple it is to setup a continuous delivery build pipeline infrastructure using Docker.
In an upcoming post we will look at Jenkins pipeline as code creating Docker images and running integration tests against Docker containers.
The series will close with an article explaining how we can move all containers built throughout this series of posts in a Docker swarm environment.&lt;/p>
&lt;/div></description></item><item><title>docker-compose scripting</title><link>https://www.martinahrer.at/2017/02/07/docker-compose-scripting/</link><pubDate>Tue, 07 Feb 2017 00:00:00 +0000</pubDate><guid>https://www.martinahrer.at/2017/02/07/docker-compose-scripting/</guid><description>&lt;div class="paragraph">
&lt;p>This time we look at managing large numbers of compose projects.&lt;/p>
&lt;/div>
&lt;div class="paragraph">
&lt;p>When building complex infrastructure using docker-compose we soon end in a mess of scripts for starting, updating, etc. containers.
I will try to describe an approach that has helped to get this done in a very structured way.&lt;/p>
&lt;/div></description></item><item><title>docker-compose modularization</title><link>https://www.martinahrer.at/2017/02/06/docker-compose-modularization/</link><pubDate>Mon, 06 Feb 2017 00:00:00 +0000</pubDate><guid>https://www.martinahrer.at/2017/02/06/docker-compose-modularization/</guid><description>&lt;div id="preamble">
&lt;div class="sectionbody">
&lt;div class="paragraph">
&lt;p>In this blog post we are looking into how we can create modular compose projects.&lt;/p>
&lt;/div>
&lt;div class="paragraph">
&lt;p>With &lt;code>docker-compose&lt;/code> we can describe a bunch of containers and container related resources such as networks and volumes that make up an application. All this is usually going into a &lt;code>docker-compose.yml&lt;/code> file.&lt;/p>
&lt;/div></description></item></channel></rss>