We don’t normally include how-tos in Changelog News, but I’m making an exception for this post because a) it goes deep on how Docker works on macOS, and b) this is a problem that plagues so many of us that I thought it worth pointing to a solution.

There’s also a nice bit about Development Containers at the end, which are quite promising, indeed.

Setting up Rails for the first time with all the dependencies necessary can be daunting for beginners. Docked Rails attempts to flatten the onboarding curve by only requiring a working Docker installation in order to get started making a new Rails application, working with that application during development, and running a basic server. All based on pre-configured commands and dependencies living in a Docker image.

Getting started is as easy as:

docker volume create ruby-bundle-cache
alias rails='docker run --rm -it -v ${PWD}:/rails -v ruby-bundle-cache:/bundle dhh37/rails'
alias rails-server='docker run --rm -it -v ${PWD}:/rails -v ruby-bundle-cache:/bundle -p 3000:3000 dhh37/rails server -b 0.0.0.0'

One of the more interesting discussions that attracted some attention during KubeCon + CloudNativeCon was how, due to its design, WebAssembly (also known as Wasm) can replace Docker in many circumstances.

We were just discussing this with Swyx on JS Party. What an unexpected turn of events!

It’s packed full of useful features, to help you build your perfect dashboard. Including status checks, keyboard shortcuts, dynamic widgets, auto-fetched favicon icons and font-awesome support, built-in authentication, tons of themes, an interactive config editor, many display layouts plus loads more.

Check out the live demo to see Dashy in action.

Florin Lipan managed to squeeze a fully-functional static web server into a Docker image that has a 186KB footprint! Here I was thinking FROM alpine was a skinny starting point…

This episode was requested by Tyler Smith who feels that he may not need Kubernetes just yet. Tyler has a few questions about Docker & Docker Swarm, so Andrea Luzzardi, former Docker Swarm Lead, joins us today to answer them.

We talk about Docker Swarm beginnings, some of the challenges that it faced, and what Andrea’s recommendation is for Tyler’s journey with Docker Swarm.

After dedicating four years of his professional career to Docker Swarm, Andrea is the best person that Gerhard knows to talk about this subject. And guess what, the same thing happened now as it did at KubeCon 2015: Sam pointed to Andrea. It will all make sense in the first five minutes. This one is going to be fun!

I’ve avoided using Docker Desktop on my Mac like you avoid those 16-seeds in your March Madness bracket. Why? Because it’s dog slow. But not anymore?

The 4.6 release of Docker Desktop for Mac contains a number of changes that drastically improve file sharing performance for macOS users. Firstly, developers now have the option of using a new experimental file sharing implementation called virtiofs (the current default is gRPC-FUSE). Secondly, improvements have been made to the way that files are synced between the macOS host and Docker VM. During testing with our amazing macOS community of users, we have observed that these changes have reduced the time taken to complete filesystem operations by up to 98%.

virtiofs is an experimental feature, so you need to enable it to realize these gains.

In this week’s episode Cameron Dutro, a software engineer at GitHub, Ship It listener and someone with an extraordinary attention to detail, joins us to talk about Kuby, a convention-over-configuration approach to deploying Rails apps.

The question that we will be trying to answer is what happened to Rails Active Deployment. The path to that promise land is paved with good intentions, but it’s complicated.

They brand CasaOS as an operating system, but it’s really a layer on top of Linux that provides a nice UI and easy app (docker container) installation. It’s early days for the project, but we definitely need some open source options in this space, so here’s hoping they continue to progress!

Back in the olden days, I would just put a mysqldump > dump.sql in a crontab and called it a day. When I started to host more and more stuff with docker, I first just migrated that approach to docker and put it all in a container. That still required me to mess around with config files. Once I started to host postgres containers it all got even more complicated. Thus, I needed a new solution.

I built this tool to make backups easy: Simply point it to a host running docker containers and it will automatically inspect and find all mysql/mariadb and postgres containers and do backups of them on a schedule. No configuration required, it “just works”.

This question could be dismissed by saying that Nix and Docker are different tools that solve different problems. One is a toolkit for building and deploying containers and the other is a package and configuration manager. However, these tools do have some overlap: they can both be used to create reproducible environments.

While both tools aim to solve this problem, they take different approaches.

A solid rundown of the different approaches these two tools take, and how you might think about picking which one to use. Maybe you can have the best of both worlds?

Here’s their pitch:

Do you have a home server you want to run a few apps on, but don’t want everything to
break every time you upgrade the OS? Do you want automatic updates but don’t want to buy
an extra 4 servers so you can run Kubernetes?

Do you have a work server that you want to run a few small services on, but don’t want
to have to manually manage it? Do you find that having every deployment action be in
a git repo more tidy?

Harbormaster is for you.

You create a YAML config file with all the git repos you want it to include and it’ll watch them for changes (on a timer) and do the necessary cloning/pulling, service restarting, etc. that needs doing to make it all run. Simple. Neat!

Nick Janetakis shares a few patterns he’s picked up based on using Docker since 2014 for many freelance projects. He also posted a timestamped video version on YouTube if you’d prefer to watch over reading.

Docker images can leak runtime secrets, build secrets, and even just some secret files you have lying around. Learn how to leak them, and (probably more usefully) how to avoid leaks.

WireGuard Easy uses Docker to set up WireGuard VPN along with a web UI for easy management. While this may be the easiest way to get up and running, I’d still advise checking out Algo VPN as well since it’s also pretty easy and has been designed/configured with maximum security in mind. Still, this looks cool and the web admin UI makes it quite approachable as well.

Thomas Ptacek writing on Fly’s blog:

Even though most of our users deliver software to us as Docker containers, we don’t use Docker to run them. Docker is great, but we’re high-density multitenant, and despite strides, Docker’s isolation isn’t strong enough for that. So, instead, we transmogrify container images into Firecracker micro-VMs.

This is a fun, technical read about how they’re converting Docker’s OCI images (turns out they’re just a stack of tarballs) into Firecracker VMs. It’s much simpler to accomplish than I would’ve thought! Money quote:

You’re likely of one of two mindsets about this: (1) that it’s extremely Unixy and thus excellent, or (2) that it’s extremely Unixy and thus horrifying.

Local network monitoring stack (forked from this project) that’s tailored to run on your Raspberry Pi.

Here’s a quick start to stand-up a Docker Prometheus stack containing Prometheus, Grafana with blackbox-exporter and speedtest-exporter to collect and graph home network connections and speed.

Samanta de Barros:

If, like me, configuring GitHub Actions is not your thing and you find yourself wanting to try something before actually pushing it to GitHub (and having to see the effects on real-life), follow this step by step of how to run your GitHub Actions on your own computer.

Working with Docker CLI is very straightforward - you just build, run, inspect, pull and push containers and images, but have you ever wondered how do the internals behind this Docker interface actually work?

Behind this simple interface hides a lot of cool technologies and in this article you can learn about one of them - the union filesystem - the underlying filesystem behind all the container and image layers.

In other jobs, we’ve used docker and it’s worked out just fine (for the most part… there was that time the RedHat filesystem on our prod server got mysteriously hosed – maybe it wasn’t docker’s fault.) But no, the reason we don’t use docker is because we don’t need it. Literally. Writing golang web services and static html embedded with with golang 1.16’s new //embed directive, we end up with a single deployable binary.

As a self-sustaining startup, we have limited resources to devote to tasks. We chose golang exactly for this reason. It sure would be nice if we could spend a couple weeks building the perfect CI/CD pipeline, an elegant deployment process, along with pretty dashboards. But we have software we need to ship in order to get users in order to drive subscriptions. Anything that doesn’t directly serve that goal is a complication. So at best, docker is a complication. A 9 million LoC complication that brings its own bugs and its own idiosyncrasies.

I’m not here to tell you whether or not you should use Docker. I don’t know what you should do. What I do know, is that you (all) need to make your own decisions based on your needs.

That’s why I like this piece by the team behind MeeZee Workout‪s. They share their decision and why they made it. Add this to your knowledge base for your next big decision.

If you’ve ever been alarmed by how many security vulnerabilities your Docker image has, even after you’ve installed security updates, here’s what’s going on—your image may actually be fine!

Vadim Bauer:

BuildKit CLI is a plugin for kubectl (the Kubernetes command-line tool). The plugin extends the functionality of kubectl, allowing to build container images without a local Docker installation.

This article tells you how to use BuildKit CLI and how it will improve your inner-loop productivity flow.

At this point probably everybody has heard about Docker and most developers are familiar with it, use it, and therefore know the basics such as how to build a Docker image. It is as easy as running docker built -t name:tag ., yet there is much more to it, especially when it comes to optimizing both the build process and the final image that is created.

The article goes on to cover caching, slimming, and securing your images so they’ll run faster and be less prone to abuse.

Container security is often overlooked topic, as people assume that containers are secure by default - which is not true. One of the ways to secure container workloads in Docker and Kubernetes is to leverage seccomp profiles and this advanced feature of container runtimes is explained and shown in this article.

Vladimir Dementyev:

I only installed Git, Docker, and Dip on my new computer to see how productive I can be with a barebones system setup.

I hadn’t heard of Dip prior to reading this. It definitely looks like it’ll clean up your setup. 👌