I’m hacking around with a solution that combines WASM and Google Trillian.

Ultimately, I’d like to be able to ship WASM (binaries) to a Trillian personality and then invoke (exported) functions on them. Some this was borne from the interesting exploration of Krustlet and its application of wascc.

I’m still booting into WASM but it’s a very interesting technology that has most interesting potential outside the browser. Some folks have been trailblazing the technology and I have been reading Kevin Hoffman’s medium and wascc (nee waxosuit) work. From this, I stumbled upon Kevin’s waPC and I’m using waPC in this prototyping as a way to exchange data between clients and servers running WASM binaries.

I’ve been spending some time this week with Krustlet.

I’m working on documenting how to run Krustlet(s) alongside GKE. I’ve been running a Krustlet with MicroK8s.

The Krustlet demos reference WASM assemblines stored in Azure Container Registry as OCI containers. Google Container Registry supports OCI format and so I tried (successfully) using GCR instead of AZR.

There may be an easier approach but this is how I got this working.

Krustlet uses wasm-to-oci. I was challenged by wasm-to-oci authentication. wasm-to-oci uses ORAS. It turns out that, after authenticating using ORAS, I’m able to use wasm-to-oci to authenticate to a GCR registry!

I’ve been hacking on a Rust-based transparent application for Google Trillian. As appears to be my fixation, this personality is for another package manager. This time, Rust’s Crates often found in crates.io which is Rust’s Package Registry. I discussed this project earlier this month Rust Crate Transparency && Rust SDK for Google Trillian and and earlier approach for Python’s packages with pypi-transparency.

This time, of course, I’m using Rust. And, by way of a first for me, for the gRPC server implementation (aka “personality”). I’ve been lazy thanks to the excellent gRPCurl and have been using it way of a client. Because I’m more familiar with Golang and because I’ve written (most) other Trillian personalities in Golang, I resorted to quickly implementing Crate Transparency in Golang too in order to uncover bugs with the Rust implementation. I’ll write a follow-up post on the complexity I seem to struggle with when using protobufs and gRPC [in Golang].

Well, this became more of an adventure that I’d originally wanted but, after learning some BLE and, with the help of others (Thanks Jonatha, JsBergbau), I’ve sample code that connects to 4 Xiaomi 2nd gen. Thermometers, subscribes to readings and publishes the data to MQTT. From there, I’m scraping it using Inuits MQTTGateway into Prometheus.

Repo: https://github.com/DazWilkin/gomijia2

Thanks|Credit:

• Jonathan McDowell for gomijia and help
• JsBergbau for help

Background

I’ve been playing around with ESPHome and blogged around my very positive experience ESPHome, MQTT, Prometheus and almost Cloud IoT. I’ve ordered a couple of ESP32-DevKitC and hope this will enable me to connect to Google Cloud IoT.

I’m noodling the utility of a Transparency solution for Rust Crates. When developers push crates to Cargo, a bunch of metadata is associated with the crate. E.g. protobuf. As with Golang Modules, Python packages on PyPi etc., there appears to be utility in making tamperproof recordings of these publications. Then, other developers may confirm that a crate pulled from cates.io is highly unlikely to have been changed.

On Linux, Cargo stores downloaded crates under ${HOME}/.crates/registry. In the case of the latest version (2.12.0) of protobuf, on my machine, I have:

I’ve written previously (Google Trillian for Noobs) about Google’s interesting project Trillian and about some of the “personalities” (e.g. PyPi Transparency) that I’ve build using it.

Having gone slight cra-cra on Cloud Run and gRPC this week with Golang gRPC Cloud Run and gRPC, Cloud Run & Endpoints, I thought it’d be fun to deploy Trillian and a personality to Cloud Run.

It mostly (!) works :-)

At the end of the post, I’ve summarized creating a Cloud SQL instance to host the Trillian data(base).

<3 Google but there’s quite often an assumption that we’re all sitting around the engineering table and, of course, we’re not.

Cloud Endpoints is a powerful offering but – IMO – it’s super confusing to understand and complex to deploy.

If you’re familiar with the motivations behind service meshes (e.g. Istio), Cloud Endpoints fits in a similar niche (“neesh” or “nitch”?). The underlying ambition is that, developers can take existing code and by adding a proxy (or sidecar), general-purpose abstractions, security, logging etc. may be added.

Update: 2020-03-24: Since writing this post, I’ve contributed Golang and Rust samples to Google’s project. I recommend you start there.

Google explained how to run gRPC servers with Cloud Run. The examples are good but only Python and Node.JS:

• gRPC comes to Cloud Run
• gRPC in Google Cloud Run

Missing Golang…. until now ;-)

I had problems with 1.14 and so I’m using 1.13.

Project structure

I’ll tidy up my repo but the code may be found:

I wrote recently describing Python and Golang clients for OriginStamp based on OriginStamp’s API’s swagger spec. As a way to pursue learning rust, I’ve been forcing myself to write examples using rust. I’m honestly finding learning rust tough going and think I’m probably better to revert to the “Learning Rust” tutorials.

That said, herewith an explanation of building a rust client using an OpenAPI (!) generated SDK from OriginStamp’s swagger spec.

Google has released a new Golang SDK for protobuf. In the [announcement], a useful tool to redact properties is described. If like me, this is somewhat novel to you, here’s a mashup using Google’s Protocol Buffer Basics w/ redaction.

To be very clear, as it’s an important distinction:

Project

Here’s my project structure:

.
├── protoc-3.11.4-linux-x86_64
│   ├── bin
│   │   └── protoc
│   ├── include
│   │   └── google
│   └── readme.txt
└── src
    ├── go.mod
    ├── go.sum
    ├── main.go
    ├── protos
    │   ├── addressbook.pb.go
    │   └── addressbook.proto
    └── README.md

You may structure as you wish.