I’m debugging an issue with Akri Zeroconf protocol in which Instance environment variables are no longer (!) being surfaced within the Broker pods. In my adventures, it seemed useful to better understand how Akri works and specifically, how Akri uses Kubernetes Device Plugins. IIUC plugins register with the Kubelet (!) via a gRPC service (Registration) that the Kubelet exposes on a UNIX socket at /var/lib/kubelet/device-plugins/kubelet.sock Then (!) if successful, devices should be reported by the Node’s metadata (spec) and available to be bound to Pods.

Let’s see if this works!? I’ve added the following link to this site’s baseof.html so that it is now rendered for each page: <link href="https://us-central1-webmention.cloudfunctions.net/webmention" rel="webmention" /> I discovered indieweb yesterday reading about webmention. Who knows what got me to webmention!? The principles of both are sound. Instead of relying on come-go behemoths to run our digital world, indieweb seeks to provide technologies that enable us to achieve things without them.

A Microsoft engineer introduced me to pest as a way to introduce service filtering in a ZeroConf plugin that I’m prototyping for Akri. It’s been fun to learn but I worry that, because I won’t use it frequently, I’m going to quickly forget what I’ve done. So, here are my notes. Here’s the problem, I’d like to be able to provide users of the ZeroConf plugin with a string-based filter that permits them to filter the services discovered when the Akri agent browses a network.

For the past couple of weeks, I’ve been playing around with Akri, a Microsoft (DeisLabs) project for building a connected edge with Kubernetes. Kubernetes, IoT, Rust (and Golang) make this all compelling to me. Initially, I deployed an Akri End-to-End to MicroK8s on Google Compute Engine (link) and Digital Ocean (link). But I was interested to create me own example and so have proposed a very (!) simple HTTP-based protocol.

You know when you start something and then regret it!? I think I’ll be sticking with Google Cloud Build; GitHub Actions appears functional and useful but I found the documentation to be confusing and limited and struggled to get a simple container image build|push working. I’ve long used Docker Hub but am planning to use it less as a result of the planned changes. I want to see Docker succeed and to do so it needs to find a way to make money but, there are free alternatives including the new GitHub Container Registry and the very very cheap Google Container Registry.

I was very interested to read about Microsoft’s DeisLab’s latest (rust-based) Kubernetes project: akri. If I understand it correctly, it provides a mechanism to make any (IoT) device accessible to containers running within a cluster. I need to spend more time playing around with it so that I can fully understand it. I had some problems getting the End-to-End demo running on Google Compute Engine (and then I tried DigitalOcean droplet) instances.

DigitalOcean launched an App Platform with many Supported Languages and Frameworks. I used Golang first, then wondered how to use non-natively-supported languages, i.e. Rust. The good news is that Docker is a supported framework and so, you can run pretty much anything. Repo: https://github.com/DazWilkin/do-apps-rust Rust I’m a Rust noob. I’m always receptive to feedback on improvements to the code. I looked to mirror the Golang example. I’m using rocket and rocket-prometheus for the first time:

I’m using Hugo as a static site generator for this blog. I’m using Firebase (for free) to host lefsilver. I have other domains that I want to promote and decided to use Google Cloud Storage buckets for these sites. Using Google Cloud Storage for Hosting a static website and using Hugo to deploy sites to Google Cloud Storage (GCS) are documented but, I didn’t find a location where this is combined into a single tutorial and I wanted to add an explanation for ensuring your sites are included in Google’s and Bing’s search indexes.

Google Cloud Build is described by Google as a “CI/CD platform” but it’s fundamentally a service that permits a series of containers to be chained together in a pipeline, optionally leveraging shared data. As a CI/CD platform, it can be used to lint, test, compile and build software but, if you were looking for a way to explain its basic awesomeness, you could… I don’t know… build a Rube Goldberg style machine that solves Quadratic equations using it 😄

Update: 2020-09-24 Three updates since I wrote the post: gcloud alpha cloud-shell get-mount-command ${DIR} It’s possible to use sshfs to mount the Cloud Shell home directory locally: DIR=/path/to/dir gcloud alpha cloud-shell get-mount-command ${DIR} Which generates something of the form: sshfs [[USERNAME]]@[[HOST]]: ${DIR} \ -p [[PORT]] \ -oIdentityFile=~/.ssh/google_compute_engine \ -oStrictHostKeyChecking=no You may then code --new-window ${DIR} curl command may lack .sshHost curl’ing the cloudshell.googleapis.com endpoint will result in a null value for .