There's a common Prometheus alert called "NodeMemoryMajorPagesFaults". It's part of the Node Exporter's node-mixin project and also included in the kube-prometheus-stack default alert rules.
But what does this alert mean, and what do you do about it? This article helps you form a good mental model and provides practical guidance.
Run a container with a host directory mount, and it either leaves root-owned files behind or it runs into "permission denied" errors. Welcome to the dreadful container host filesystem owner matching problem. These issues confuse and irritate people, and they happen because apps in the container run as a different user than the host user.
There are various strategies to solve this issue, but they are all non-trivial (requiring complex logic) and/or have significant caveats (e.g., requiring privileged containers). Here's where my new tool MatchHostFsOwner comes in.
Ubuntu 22.04 was released a couple of days ago. Fullstaq Ruby now provides packages for this distribution!
I previously designed a robust distributed locking algorithm based on Google Cloud. Now I'm releasing a Ruby implementation of this algorithm: distributed-lock-google-cloud-storage-ruby.
To use this, add to your Gemfile:
gem 'distributed-lock-google-cloud-storage'
Many workloads nowadays involve many systems that operate concurrently. This ranges from microservice fleets to workflow orchestration to CI/CD pipelines. Sometimes it's important to coordinate these systems so that concurrent operations don't step on each other. One way to do that is by using distributed locks that work across multiple systems.
Distributed locks used to require complex algorithms or complex-to-operate infrastructure, making them expensive both in terms of costs as well as in upkeep. With the emergence of fully managed and serverless cloud systems, this reality has changed.
In this post I'll look into a distributed locking algorithm based on Google Cloud. I'll discuss several existing implementations and suggest algorithmic improvements in terms of performance and robustness.
Containers are no longer only used on servers. They are increasingly used on the desktop: as CLI apps or as development environments. I call this the "container-as-OS-app" use case. Within this use case, containerized apps often generate files that are not owned by your local machine's user account. Sometimes they can't access files on the host machine at all. This is the host filesystem owner matching problem.
Solutions are available, but they have major caveats. As a result it's easy to implement a solution that only works for some, but not everyone. "It works on my machine" is kind of embarrassing when you distribute a development environment to a coworker, who then runs into issues.
This post describes what causes the host filesystem owner matching problem, and analyzes various solutions and their caveats.
Traveling Ruby allows you to easily ship Ruby apps to end users. It lets you create self-contained Ruby app packages that run on multiple versions of Windows, Linux and macOS.
Today I’ve released version 20210206. This release supports Ruby 2.4, bumps all the gem versions, bumps the minimum supported macOS and Linux versions, and fixes some bugs.
It has been a long time since the last release. So this post also adresses an elephant in the room: is Traveling Ruby back?
In my last blog post about Traveling Ruby's future, I said that it's hard to democratize the development of Traveling Ruby because of System Integrity Protection (SIP). Traveling Ruby's build process relies on DYLD_LIBRARY_PATH, which is blocked by SIP. This means that:
After some research and experimentation, I've found an alternative to DYLD_LIBRARY_PATH, meaning that it's no longer necessary to disable SIP. This significantly changes the ability to democratize Traveling Ruby's development.
A couple of years ago, I had a dream: to make it dead-easy to distribute Ruby CLI apps to end users, without requiring those users to install Ruby or muck about with gems and Bundler. And thus Traveling Ruby was born.
Traveling Ruby hasn't seen updates for quite a while now. Recently I tried making a new bugfix release, but I found it to be more challenging than I had hoped. In this article I reflect on those challenges, as well as on the future of Traveling Ruby.
Debian packaging can be quite mysterious and hard to figure out. In this guide I'll provide a simple introduction into the Debian packaging process and its most important concepts.
This is not a full guide into all aspects of packaging. Instead, I'll cover just enough of the basics to help you develop a mental model of what Debian packaging is about, and to be able to produce useful results.
I'll cover:
