Free AI web copilot to create summaries, insights and extended knowledge, download it at here

2092

Abstract

ps://docs.docker.com/buildx/working-with-buildx/">documentation</a> and several blog posts about it. We will walk through it now.</p><h1 id="b30b">Use buildx</h1><p id="df4c">Buildx comes with a default builder that you can observe by typing <code>docker buildx ls</code> into your terminal. However, we want to make and use a builder ourselves.</p><h2 id="7fe3">Make a builder</h2><p id="f34c">You will need a new builder, so make one with <code>docker buildx create --name m1_builder</code>. Now you should see the new builder when running <code>docker buildx ls</code>.</p><h2 id="ff2b">Use and bootstrap the builder</h2><p id="04b3">The next steps are to “use” the new builder and bootstrap it. Start with <code>docker buildx use m1_builder</code> and then <code>docker buildx inspect --bootstrap</code>, which will inspect and bootstrap the builder instance you just started using. You should see something like this:</p><div id="96ee"><pre>computer@computer-m1 ~ <span class="hljs-comment">% docker buildx inspect — bootstrap</span></pre></div><div id="f029"><pre><span class="hljs-selector-attr">[+]</span> Building <span class="hljs-number">5.3s</span> (<span class="hljs-number">1</span>/<span class="hljs-number">1</span>) FINISHED</pre></div><div id="d9ab"><pre>=> [internal] booting buildkit <span class="hljs-number">5.3</span>s</pre></div><div id="11a2"><pre>=> => pulling image moby/buildk<span class="hljs-symbol">it:bu</span>ildx-stable-<span class="hljs-number">1</span> <span class="hljs-number">3.1</span>s</pre></div><div id="23a0"><pre>=> => creating container buildx_buildkit_m1_builder0 <span class="hljs-number">2.3</span>s</pre></div><div id="37b8"><pre><span class="hljs-symbol">Name:</span> m1_builder</pre></div><div id="b2cc"><pre><span class="hljs-symbol">Driver:</span> docker-container</pre></div><div id="e0d4"><pre><span class="hljs-symbol">Nodes:</span></pre></div><div id="03f9"><pre><span class="hljs-symbol">Name:</span> m1_builder0</pre></div><div id="3fc5"><pre>Endpoint: unix:<span class="hljs-regexp">//</span><span class="hljs-regexp

Options

">/var/</span>run/docker.sock</pre></div><div id="02ab"><pre>Status: <span class="hljs-built_in">running</span></pre></div><div id="7538"><pre>Platforms: linux/arm64, linux/amd64, linux/riscv64, linux/ppc64le, linux/s390x, linux/arm/v7, linux/arm/v6</pre></div><p id="d657">You can see that this builder has a whole host of platforms it will build for!</p><h2 id="6d70">Build with the builder</h2><p id="1a42">Now, <code>cd</code> your terminal into a place where you want to build and push an image so you can run this pseudo-command:</p><div id="ec3e"><pre><span class="hljs-symbol">docker</span> buildx —-platform linux/amd64,linux/arm64,linux/<span class="hljs-meta">arm</span>/<span class="hljs-built_in">v7</span> -t <remote image repository> --<span class="hljs-keyword">push</span> .</pre></div><p id="b5e3">You should see the “in use” builder go crazy and build the architectures you specified.</p><p id="1227">If you wan’t the skinniest possible build you will need to know the architecture you are deploying to. In my case my AWS ECS tasks required <code>linux/amd64</code> which is the only option I use after the <code>--platform</code> flag.</p><h2 id="c1df">Manifest</h2><p id="9df9">Once your image has been built and pushed, you can inspect the manifest with:</p><div id="f567"><pre>docker <span class="hljs-keyword">buildx </span>imagetools <span class="hljs-keyword">inspect </span><remote image repository></pre></div><p id="1ef3">You should see a manifest printout with all your different architectures. Most services that pull an image are smart enough to know which architecture to go get.</p><h2 id="136b">Clean up</h2><p id="ca0f">Finally, as you might have experienced, Docker can start to take up a bit of disk space. If you did not use <code>buildx</code>, you probably ran <code>docker system prune --all</code>, the equivalent for <code>buildx</code> is luckily semantically similar.</p><div id="21a4"><pre>docker buildx prune <span class="hljs-comment">--all</span></pre></div><p id="8c27">That’s it! Happy container development!</p></article></body>

How to Actually Deploy Docker Images Built on M1 Macs With Apple Silicon

A guide to help you deploy cross-platform builds from your M1 Mac

Apple Silicon M1 and Docker. Photo by the author.

While using an early “Tech Preview” Docker Desktop build for Apple Silicon I quickly ran into a learning curve related to different architectures and deployment. I can build and run images on my M1 Mac just fine now but this was the error I saw when pushing an image built on a Mac with Apple Silicon to an ECS instance on AWS:

standard_init_linux.go:219: exec user process caused: exec format error

Hopefully, this guide will help you start deploying images built from your amazing new machine faster!

Install a Compatible Docker Version

Kudos to the Docker team for moving very fast on a build for the M1 chip. You can get the latest “Tech Preview” from their website. Note that they do not recommend using this version in production.

While you can run Docker containers built on your Mac just fine now, you need to make a build you can run somewhere else on a different architecture. Fortunately, Docker has a tool called buildx that has you covered.

Once installed, the first thing you have to do to start building for other architectures is to enable the experimental features:

This will make the Docker buildx program available. Docker has documentation and several blog posts about it. We will walk through it now.

Use buildx

Buildx comes with a default builder that you can observe by typing docker buildx ls into your terminal. However, we want to make and use a builder ourselves.

Make a builder

You will need a new builder, so make one with docker buildx create --name m1_builder. Now you should see the new builder when running docker buildx ls.

Use and bootstrap the builder

The next steps are to “use” the new builder and bootstrap it. Start with docker buildx use m1_builder and then docker buildx inspect --bootstrap, which will inspect and bootstrap the builder instance you just started using. You should see something like this:

computer@computer-m1 ~ % docker buildx inspect — bootstrap

[+] Building 5.3s (1/1) FINISHED

=> [internal] booting buildkit 5.3s

=> => pulling image moby/buildkit:buildx-stable-1 3.1s

=> => creating container buildx_buildkit_m1_builder0 2.3s

Name: m1_builder

Driver: docker-container

Nodes:

Name: m1_builder0

Endpoint: unix:///var/run/docker.sock

Status: running

Platforms: linux/arm64, linux/amd64, linux/riscv64, linux/ppc64le, linux/s390x, linux/arm/v7, linux/arm/v6

You can see that this builder has a whole host of platforms it will build for!

Build with the builder

Now, cd your terminal into a place where you want to build and push an image so you can run this pseudo-command:

docker buildx —-platform linux/amd64,linux/arm64,linux/arm/v7 -t <remote image repository> --push .

You should see the “in use” builder go crazy and build the architectures you specified.

If you wan’t the skinniest possible build you will need to know the architecture you are deploying to. In my case my AWS ECS tasks required linux/amd64 which is the only option I use after the --platform flag.

Manifest

Once your image has been built and pushed, you can inspect the manifest with:

docker buildx imagetools inspect <remote image repository>

You should see a manifest printout with all your different architectures. Most services that pull an image are smart enough to know which architecture to go get.

Clean up

Finally, as you might have experienced, Docker can start to take up a bit of disk space. If you did not use buildx, you probably ran docker system prune --all, the equivalent for buildx is luckily semantically similar.

docker buildx prune --all

That’s it! Happy container development!