Docker CMO, Tim Anglade:

For those of you catching up, we recently emailed accounts that are members of Free Team organizations, to let them know that they will lose features unless they move to one of our supported free or paid offerings. This impacted less than 2% of our users…

The Docker Free Team subscription was deprecated in part because it was poorly targeted. In particular, it didn’t serve the open source audience as well as our recently updated Docker-Sponsored Open Source program, the latter offering benefits that exceed those of the deprecated Free Team plan.

We’d also like to clarify that public images will only be removed from Docker Hub if their maintainer decides to delete them. We’re sorry that our initial communications failed to make this clear.

Just to be clear: their apology is not about the change, it’s about how they communicated the change. There’s more details in the post about deleting public images, squatting names, etc, but that’s the gist.

Alex Ellis:

Yesterday, Docker sent an email to any Docker Hub user who had created an “organisation”, telling them their account will be deleted including all images, if they do not upgrade to a paid team plan. The email contained a link to a tersely written PDF (since, silently edited) which was missing many important details which caused significant anxiety and additional work for open source maintainers.

He goes on to explain the problem in great details. Btw, Alex is no Docker hater. He has a long history of using and supporting the tech. He goes on to say:

Open Source has a funding problem, and Docker was born in Open Source. We the community were their king makers, and now that they’re turning over significant revenue, they are only too ready to forget their roots.

This decision seems myopic. There are other image hosting options, one of them even shares (inspired?) half of DockerHub’s name… Oh, and here’s our open invitation to the folks at Docker to come on the pod.

MRSK deploys web apps anywhere from bare metal to cloud VMs using Docker with zero downtime. It uses the dynamic reverse-proxy Traefik to hold requests while the new application container is started and the old one is stopped. It works seamlessly across multiple hosts, using SSHKit to execute commands. It was built for Rails applications, but works with any type of web app that can be containerized with Docker.

Watch the screencast or check out the code & docs.

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.