Gatillos

For a while now I’ve been using Bottlerocket as the base OS for instances in the cloud (i.e. the AMI), instead of using Amazon Linux or Ubuntu etc. In our workload we don’t really have much use for local storage until recently so I finally invested some time in figuring out how to actually make use of the local SSDs where available (usually this type of storage is called instance-store in AWS).

I set up a local kubernetes cluster using microk8s just as a development/home cluster and as part of it I ended up connecting to the kubernetes dashboard application using a service account token, as recommended

$ microk8s kubectl create token default
(...token output...)

This process lead me to a few questions:

• What is that token?
• Where does it come from?
• Where is it stored?
• Does it expire?

Essentially, “wait how does the whole token authentication thing work?”

But why?

Whatever you think about Kubernetes, it is here to stay. At work it’s replaced all our custom orchestration and ECS usage. It solves infrastructure problems in a common way that most Cloud providers have agreed to, which is no small feat.

So why would you want to install it locally anyway? For work your company will most likely provide you access to a cluster and give you a set of credentials that somewhat limit what you can do. Depending on your interests that won’t be enough to properly learn about what is going on under the hood. Getting familiar with how Kubernetes stores containers, container logs, how networking is handled, DNS resolution, load balancing etc will help remove a huge barrier.

When transmitting complex information I find having some kind of diagram extremely helpful. Sometimes they are there just to have something to look at and point, sometimes they are key to following a complex flow.

Over the years of trying lots of different tools, still seems to me that what I would call ‘hand drawn’ diagrams are best - but I don’t mean actually hand drawn, I’m quite bad at whiteboard drawing but give me a tool like Omnigraffle and I’ll make the nicest diagrams. I’ll throw in some pastel colors even.

I’ve been a very big fan of small Wacom tablets as a replacement for a mouse. I’ll go through my current setup for Linux in case it can help anyone out there.

I started using a Wacom tablet for drawing but found it an excellent replacement for a mouse and moved to exclusive use when I started having symptons of RSI. The change from having the wrist on top of a mouse to having it gripping a pen made a big difference and my problems went away.

Until very recently you couldn’t really use a Wacom tablet on a Linux desktop that was using Wayland instead of Xorg. There is a major difference between X and Wayland in terms of tablets:

• Wayland supports tablet and other pointing devices as separate inputs

Previously we have been able to simply have the pencil move the main cursor whenever it gets close to the tablet. This worked fine but the Wayland way is actually better and allows for other functionality, unfortunately it means applications needed to be updated to be multiple cursor aware.

A bit late for an Inktober recap but here it goes. I participated in Inktober 2018 which is a loose initiative to encourage drawing aficionados to draw one ink drawing every day for a month. Originally I think part of the idea came from promoting actual ink and paper usage, but it’s quite open to digital solutions too. In my case I was interested in trying out an iPad Pro with an Apple Pencil that I had been given recently, and seeing what that could be used for.

Drawing using Adobe Draw on iPad Pro with Apple Pencil.

Will do some quick drawings for Inktober 2018, which is a loose movement that asks for 31 ink drawings during the 31 days of the month of October. They are flexible between digital and actual ink (actual ink was the original goal though). They give a word to be used as a ‘prompt’ for each day. This one is “Poisonous”. I used Procreate on an iPad Pro with the Apple pencil.

Github has worked great for me over the past many years, and I’ve been a paying customer for about 8 years. That’s not likely to change but I took the recent acquisition by Microsoft as a prompt to explore other options as I saw many comments praising gitlab, and specifically their continuous integration options.

I found that really interesting as I had found the plugin restrictions in Github very limiting - I want to be able to run preprocesses on my files so I don’t have to type or copy and paste so much.

This post explores how I migrated one of my sites there.

Outline of the process

1. Import old project (PRs, issues etc)
2. Create a .gitlab-ci.yml file (build pipeline) and build
3. Check that page is live under gitlab.io domain
4. Add a custom domain and SSL support using Let’s Encrypt (certbot)
5. …
6. PROFIT

Optionally: run your own runner to do the build (future post).