Devops

In my previous post, I took a container image apart with curl. One thing from it stayed with me: a tag is just a name for a manifest digest, and anyone who can push can move it to another image. Think about what this means for a deployment. It pulls shop:1.0 and runs whatever the tag points to right now. If someone with a push token builds their own shop:1.0 and pushes it over ours, nothing looks different. The same name, the same tag, the same log line on start-up. ...

I often commit things that I don’t want to keep: debug settings, a hard-coded value, a quick test. The plan is always to drop them before the review. To do that, I open git rebase -i, find the line, change pick to drop and save. It works, but only for the branch that I have checked out. When I work with stacked pull requests, the second one built on top of the first, the branch below keeps the commit, unless I remember --update-refs. ...

🎬 Prefer to watch? This walkthrough is also a video on YouTube. I like git bisect a lot. Something is broken, nobody knows since when, and bisect finds the commit in a few steps: you give it a good commit, a bad one, and a script that tells them apart. But when the search is over, it doesn’t clean up. You stay on a detached HEAD, often not even on the culprit. git status keeps saying that you are bisecting, and your branch is locked until you remember to run git bisect reset. I forget it almost every time. ...

🎬 Prefer to watch? This walkthrough is also a video on YouTube. Every few months I run git branch in a repository I work with every day and see a long list: fix-..., add-..., try-.... Most of these branches are pull requests that were merged weeks ago. Git doesn’t delete them by itself, so they just stay there. Until now, I cleaned them up with a one-liner like this: git branch --merged origin/main | grep -vE '^\*|^ *main$' | xargs git branch -d It works, but it’s easy to get wrong. If you forget the grep, main is in the list too. Every branch is compared with the one ref you typed. And there is no way to say “please keep this one”. ...

We push and pull container images every day. docker push shows a few progress bars, and the image is in the registry. docker pull brings it back. For most of us, it’s a black box, and it works fine until something goes wrong. Have you ever compared the IDs? podman build prints one ID. The registry knows the image by a different digest. And the push log shows two more digests, but the registry has no blobs with these names. Which one is “the image”? Or a push fails with DIGEST_INVALID or MANIFEST_INVALID, and it’s not clear what the registry didn’t like. ...

🎬 Prefer to watch? This walkthrough is also a video on YouTube. Every merge conflict ends the same way. You fix the files, and then you have to stage them. And this is exactly the moment when a small accident happens: most of us type git add -u or git add . out of habit. Both commands stage everything that is modified, not only the files you have just resolved. I’ve been bitten by this more than once. A set -x or a debug print in some unrelated file quietly goes into the merge commit together with the resolution. Nobody notices it, because nobody reads merge commits line by line. A few weeks later someone asks why the start script suddenly prints every command. ...

Platform Engineering focuses on velocity and Developer Experience by building golden paths, while SRE ensures stability and production health. Both must work together for success.

Kaniko, NGINX Unit, Ingress-NGINX… The more operator tools you use, the more time you will spend replacing them.

Recently, I was caught off guard by a question: why should the steps of a build script in a pipeline be idempotent? Why can’t we build and push the container every time? Why is idempotence so important? Idempotence in pipeline build steps is important for many reasons. Predictability and Stability: When a step in a pipeline is idempotent, it means that running it multiple times will always give the same result. This is very important for CI/CD pipelines because the same build might be triggered more than once. For example, if there is a small error, or someone makes changes to the code, or during testing, you might need to run the pipeline again. If the steps are idempotent, you don’t have to worry about unexpected results. Everything will work the same way every time. ...

Use versioning in remote states Everyone makes mistakes. Some of them may break a Terraform state, and in such situations, availability of a previous state version can help you to avoid completely reimporting the whole infrastructure. You simply roll back the state to the previous version and resolve all problems in the code or in the infrastructure manually. Often, those issues will be resolved after applying the previous state of the code to this version of state. Moreover, it can help you avoid situations where the state is updated not because of changes but due to the major version update of Terraform, and your pipelines or providers aren’t ready yet, or there’s a bug, leading you to roll back the state instead of editing it directly. You might have noticed this if you have gone through the process of updating the Terraform version from 0.12.x to 1.2.x ...