Managing Lets Encrypt certificates has been one of the hardest things to do in Kubernetes. To be fair, it wasn’t easy before Kubernetes either. For a while I was using Traefik, but then I ran into some issues related to scalability. Then I moved to nginx-ingress + cert-manager and things were good for a while.
A few weeks ago I received an automated email from Lets Encrypt informing me that one of my certs was going to expire soon.
I don’t consider myself a Git expert. I’ve basically memorized the commands I use 99% of the time:
git checkout main git pull git checkout -b new-branch git add . git commit git commit -m 'my comment text' git rebase main git rebase -i HEAD~4 git push git push -f However, I’ve recently “discovered” two new commands that I’m finding extremely useful:
Push to Branch Without Checking it Out I frequently want to push my main branch to my prod branch.
In case you’ve never come across it, LaTeX is a system for writing documents. Unlike Word or similar software, you write your document in the LaTeX markup language, and the software will format your text, tweak spacings, and usually produce a very good looking document. I used it a lot when I was in university and, while writing my masters thesis, decided it would be amazing if my resume were written in LaTeX as well.
A few days ago I wrote up some thoughts about my experience working from home for three years at Automattic. I’ve been thinking more about this, and there is one thing about remote work that I feel is not talked about much: It’s lonely.
I’ve heard people argue that your coworkers should not substitute real friendships and family. I agree with that, but still for many people the workplace is where they’ll have the majority of their human interaction.
Today I spent about an hour renaming the master branch to main on all my personal repositories. This included around 100 repos in GitHub, Bitbucket and Azure DevOps. To be clear, I don’t think this is going to be the thing that fixes racism in our society. I’ve heard people (mostly on Twitter) argue against this change, however:
If we’re going to argue over such small things, what hope is there to get anything big done?
A few days ago I received a request from someone who wanted to run k8s-ecr-login-renew on a Raspberry Pi Kubernetes cluster. Fortunately, I already had experience building Go apps for that architecture. But what I really had no clue about was the next step: putting that executable into a Docker image.
Looking around online, I found a few articles that recommended installing an experimental version of Docker, and then running the docker buildx.
The concept of remote work has been around for a while, but considered difficult or perhaps rare to achieve. With the COVID-19 pandemic, that dream has suddenly become a reality for many, at least temporarily. In this post I’ll discuss some of the pros and cons of distributed/remote work, based on my three years at Automattic (2015-2018).
Pro #1: Work Life Balance This is the most obvious advantage of remote work.
I’m pleased to announce the release of version 1.2 of the k8s-ecr-login-renew tool. Thanks to a great feature request pointing out that secrets can only be accessed by pods in the same namespace. This makes the tool difficult to use in clusters that have many namespaces. To resolve this limitation, the tool now has the ability to run once and deploy to multiple namespaces. This is achieved through comma-separated list of namespaces, as well as wildcard matching with the ?
My friend and ex-teammate Dwain recently wrote “PHP is just fine”, and when I read that article I initially had a strong reaction of disagreement. After thinking (and starting to write) about it a little more, I don’t disagree so strongly but I still disagree.
PHP is an OK language to use in cases such as maintaining legacy software, contributing to existing ecosystems like WordPress, and perhaps small projects or simple prototypes.
I was very pleased to see this pull request created against k8s-ecr-login-renew yesterday. I think this might be the first time I’ve ever had a contribution to one of my projects.
The change is very valid and useful: It allows you to specify a Kubernetes namespace using a TARGET_NAMESPACE environment variable. Before this change, the code assumes that everything is in the default namespace. The code continues to work as it did before if the environment variable isn’t provided, so this should not be a breaking change.