James Read's Code, Containers & Cloud blog

I really like YouTube, and I first remember using it back in 2008 or so. It’s a fantastic platform for getting to new content, even though it’s run in a way that goes against a lot of my personal preferences (lots of tracking, lots of advertising, some questionable policies). For non-paying users, Free YouTube is absolutely invested with ads. It’s basically unusable. Unfortunately I was forced to switch to YouTube premium a while ago because there are several content creators I really like, where their content isn’t posted elsewhere.

This evening finally marks the completion of the migration of https://docs.olivetin.app to a new build system, called Antora. OliveTin’s documentation consists currently of 126 AsciiDoc files, 50 images, and many example config files, code examples, and similar. I would not say it is a very large documentation site, like OpenShift or any of the Red Hat documentation that I spend a lot of time reading (also written in AsciiDoc), but it’s a decent size that has been built up over the last 3 years.

So many interactions with friends, family and coworkers now happen via our chat apps, and so many of the best bits of these chats just scroll by and are forgotten. Faridoon is a simple app that lets you save and publish your favourite chat quotes for you to save, for your community, or for the world to see. I was inspired to write Faridoon a long time ago, when I was chatting with friends mostly on Mumble chat.

The bluey-grey color that you see in nearly all of my projects has the HTML color code #dee3e7. It came from the very first “real” web project I worked on when I was about 16 years old, and I knew nothing! That website has had so many versions over the years, but it’s first version was built with PHP4.3, XHTML 1.0/HTML4.01 and CSS2.1 - and it was a mess! But I loved it, it taught me so much about web development, and it was my gateway into the world of web programming.

In my very first job interview out of University, I was asked a question that I have never forgotten. The interviewer asked me “What skills do you think you have, that other people don’t?”. Context is important, I was 21, I’d never had a professional job in IT before, and I was applying for a job as a Systems Engineer. What came to mind quite quickly, was that I’ve been programming since I was about 11 or 12 years old, and it’s given me an appreciation for why software fails.

This post is written simply for myself to mark the date when I fully decided to ditch Ansible’s containers.podman.podman_containers, and Podman’s nasty port of docker-compose, in favour of Quadlet. Hopefully this page can serve as a useful reference for others considering the same move. Problems with containers.podman.podman_containers Ansible is great, but it’s a pain if you ssh on to a server, to find a container is down. You then have to jump on to another server to run the playbook to start the container.

I aggressively use Prometheus in my day-to-day life, not just for regular technical and application metrics, but for everything I can get an exporter for. I have a Prometheus exporter for my Gmail inbox (personal and work), for my Google calendar (mostly work), all my websites I’ve written export prometheus metrics, I monitor my servers CPU and Memory usage with Prometheus metrics, but also their Hard Drive SMART status. I even have a Prometheus exporter for my fledgling weight loss program.

Sometimes you need to write a HTML webpage that is based on some sort of data file, like YAML files. Rather than having a server-side script generate the HTML, you can generate the HTML page statically, making it easier to host and cache. I thought about writing a tool myself to do this, but thankfully, I found Gomplate. It is a powerful Go-based template renderer that allows you to generate dynamic content from various data sources, including YAML files.

This week was totally normal and routine for me, I’m sitting here on a Friday thinking that it’s been the same as many other weeks I’ve had in my life as a Tech Seller at Red Hat. Enjoyable, busy, varied, etc. However, I am noticing a change in how I go about my week - that change is that more and more of my colleagues are using AI. On the one hand this is fantastic, the democratisation of AI, led by services like ChatGPT mean that anyone without any technical background or grounding in the principles of AI doesn’t have to worry about HOW any of those services work, they use use them.

I’ve been working at Red Hat for for 13 years, so people will often come to me ask for guidance of where to get started with their Red Hat certification journey. So many people have heard of the RHCE - the Red Hat Certified Engineer exam, which remains one of the most respected IT certifications in the industry, let alone just Linux certifications. Many of these same people have years of Linux experience, but maybe haven’t taken a Red Hat certification before, or in a long time, and are looking for recommended next steps.

This is a blog post written as a summary of notes, following my learnings from an AI course I completed back in 2019 that I feel is still incredibly relevant in 2024]({{ rel ‘../how-useful-way-my-ai-short-course-from-2019/’ }}). AI is a huge field with an expansive history extending over the last century, it might be easy to be fooled into thinking thay AI was just something we found in the last 5 years. However, the recent surge of interest cannot be ignored - popularized by easy and cheap access to incredibly sophisticated models like ChatGPT.

In 2019 I could see that AI was a technology gaining increasing interest and relevance, and I was keen to get ahead of the hype and start learning more. At the time I was feeling like my day to day routine was getting a bit boring, and too familiar, and I wanted to make sure I had a solid grasp of what I thought would become a fundamental building block of technology for the future, and I decided to take a course on the topic of AI.

I am so sick and tried of changing task management systems, I will just be using plain .txt files from now on. In the last 10 years, I have tried so many different systems for organising my work and my personal life and yet I’ve not been able to keep using one of them after a few weeks or months. After all this time I think I’ve finally come to the realisation that they all suffer from the same inadequacies.

It can be a real effort to bring yourself to write articles to maintain a healthy blog, and sometimes the simple articles are best. Therefore, I just want to take a quick few moments to talk about a tool that I just cannot live without now-a-days, when writing Go code, I am always live-reloading with Air in the background. It’s really valuable for developers to be able to get fast feedback on the code that they are writing.

A fault domain (or failure domain) is essentially a set of resources, or components that share a common point of failure. One example of this is an Azure Availability Zone, or your own single Data Center. Typical points of failure for a fault domain are power (with no backup generator), or cooling, or a datacenter is served by a single network connection. The term “fault domain” could theoretically be applied to smaller areas of an application architecture, like a single network, or a rack of servers, but this article considers a fault domain more from a cloud architecture definition.

Google Photos, the free, easy to use, on-for-many-android-users service has been the single Photo backup strategy for many of those who have used it, since it was released in 2015. I, for one, was amazed to discover that I have uploaded photos dating as far back as 2005, totalling over 80Gb. Initially, Google photos seemed like that ultimate, hassle-free, cloud backup service that would never be replaced…. However, as time went on, I found myself growing increasingly concern about cloud services that “own” my personal data.

I love Ansible, and I love doing certifications - so this was a no-brainer. In this blog I’ll talk about how I prepared, how the exam felt, was it worth it, and at the end I’ll even explain why I used a cow image as the cover for this blog post! ¹

It’s been interesting to witness the meteoric rise of “Docker” over the years, and it is undoubted that the technology that was pioneered and popularized by Docker (more correctly called “Linux Containers”), is here to stay for the long run. The rise of the technology was partially due to the ease of publishing containers, enabled by free DockerHub service. However, in this article, I propose that DockerHub as a single repository of container images is becoming less and less important than it once was, and in it’s place, GitHub is a strong contender to take over as the 1 repository for containers — as it has its sights on being everything a developer needs.

Chat that is always compatible, updated, and integrates with browser extensions. Too many chat apps — can’t change that. The amount of chat applications and protocols out there now-a-days is getting absolutely crazy. It’s like in the 1990s, when we had ICQ, AIM, IRC, and others. For a little while, I felt like things were getting better — I got down to just 2 chat apps!… Fast-forward to today — the chat apps I need are unfortunately even more than in the 90s.

The TURTLES model. How many times have you seen projects abandoned on GitHub, or internal Wikis, with no explanation, no “next steps”, no follow-up or notes? How many hundreds of hours were lost to that project, and what was learned? This article proposes a model (“TURTLES”), or more simply, a checklist, of how to properly archive a project. Is now the right time to archive this project? T — Technologists: Do enough people contribute to maintaining this project?

This helps you use Go to power the next generation of APIs+PWAs. Prerequisites; This article assumes you know what protobuf and gRPC are, and have set up the grpc-gateway for REST already for your app. The context gRPC has become the default standard for modern Cloud Native RPC in Go. And gRPC is fine for backend service-to-service communication that can speak gRPC. To support older services, and the web, REST still reigns supreme.

Reading the source code is a pathway to many abilities that some consider… unnatural. Luke’s original strategy was to attack the death star via SQL injection, but in the end he went for an X-Wing based buffer overflow. I want to encourage you to actually read through the open source code for the software that you’re using. Doing so has many potential benefits, and skills like this can give you a real edge and advantage in your team.

Photo by Pixabay from Pexels There are a lot of cool Linux commands and tools you COULD learn, but what’s the point in investing a bunch of time if you just use them once a week, or once a month? A good example I like to give is Vim — it takes a long time to learn and master, but I use it over 10 times a day so it’s worth it.

I want to explain how I use this setup, and how I got here. Perhaps I will encourage you, to experiment with your desk and workflow. Taken in approx Mar 2021 Pictured above, is my desk. It does indeed have 6 monitors. It also has 4 computers with 3 operating systems (2x Linux, 1x Windows — for gaming, 1x Mac — for iOS development). I don’t intend to brag, or show off, or try and say that this set-up is absolutely essential for me and that nothing else would work.

My desktop after the story; i3, st, and some other stuff. It was worth it, but I need to explain how I got here. It’s about 2pm on a Friday afternoon, my week of meetings is finally drying up. I have a few hours in my calendar the rest of the day — and I’m not going to spend it catching up on more emails. I want to fill these last couple of hours with something a bit more fun, so I pick up the Ansible collection I was hacking code on and get to work.

This post is about how, and why, I use Git Annex to implement my 3-2-1 backup strategy backup strategy. In summary, that is; At least 3 copies of the data In at least 2 different storage mediums With at least 1 copy offsite In practicality, I’ve used Git Annex to implement more like a 9-5-3 backup strategy and track everything nicely. This strategy should mean that I should not ever lose files that I care about ever again.

This article explains how I solved a couple of challenges of getting my initial environment and configs into Git — the first steps to GitOps. I’ve been wanting to embrace GitOps for quite some time, but it’s always tricky to know where to start. Do I use Jenkins Jobs — I know Jenkins well? It’s a bit old school though, maybe I should be using Ansible Tower. I’ve heard things about ArgoCD, and lots of others.

Speed up your command line navigation Photo by Kevin Ku from Pexels Knowing a few key shortcuts can have a surprising impact. As someone who sits frequently with others over a command line to help debug code and navigate servers, it’s easy to become frustrated on their behalf at how cumbersome things can be when you may not know time-saving shortcuts. Here are some essential shortcuts and key tips to help you speed up your command line usage.

This article was written after 24 hours with a Mac Mini, i5 CPU, 8GB RAM, 1TB HDD. Mac OS Catalina. My own Monitor, Mouse, Keyboard. What am I used to? Been using Linux (Fedora, KDE) as my “daily desktop” for a longgg time now and 200% happy with it. It’s just perfect for me. Windows. Have used everything Windows 95 up until Windows Vista as a “daily desktop”, then I switched to Linux.

We’ve all been there, you just want to hack up a quick Ansible playbook to do a quick task, and then you find yourself fighting with syntax, chopping and changing things around, wondering why this simple Ansible playbook isn’t working. Let me give you a few hints to make your life easier. This is especially useful if you’re on a new machine that doesn’t come with all your personal configuration, dotfiles and preferred editors!