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.

ESPHome is a very interesting project. I’d not heard of it until this week and am surprised that it isn’t more newsworthy.

I’m always tinkering with IoT stuff, have a couple of Wemos D1 ESP8266s. They are brought out occasionally for learning. I’ve been using them this week with ESPHome. I’m looking to buy some Xiaomi BLE temperature sensors and thinking I could read the temperatures from these using the ESPs (thanks to ESPHome) and publish the data to MQTT. I tried (unsuccessfully) to publish to Google Cloud IoT (not Google’s fault but a limitation in the current ESPHome, I think) but have been successful publishing to a Mosquitto broker and rendering the metric data in Prometheus.

Recently, I wrote about some initial adventures with OriginStamp

Using OriginStamp’s UI or API, submitting a hash results in transactions being submitted to Bitcoin, Ethereum and a German newspaper.

Using the API, it’s possible to query OriginStamp’s service for a proof. This post explains how to verify such a proof.

The diligent reader among you (Hey Mom!) will recall that I submitted a hash for the message:

Frederik Jack is a bubbly Border Collie

The SHA-256 hash of this message is:

I wrote recently about some exploration of Timestamping with OriginStamp. Since writing that post, I had some supportive feedback from the helpful folks at OriginStamp and plan to continue exploring that solution.

Meanwhile, OriginStamp exposed me to timestamping and trusted timestamping and I discovered freeTSA.org.

What’s the point? These services provide authoritative proof of the existence of a digital asset before some point in time; OriginStamp provides a richer service and uses multiple timestamp authorities including Bitcoin, Ethereum and rather interestingly a German Newspaper’s Trusted Timestamp.

A friend mentioned OriginStamp to me.

NB There are 2 sites: originstamp.com and originstamp.org.

It’s an interesting project.

It’s a solution for providing auditable proof that you had a(ccess to) some digital thing before a certain date. OriginStamp provides user-|developer-friendly means to submit files|hashes (of your content) and have these bundled into transactions that are submitted to e.g. bitcoin.

I won’t attempt to duplicate the narrative here, review OriginStamp’s site and some of its content.

Until today, I’d not accessed a Google Container Registry repo from a non-GKE Kubernetes deployment.

It turns out that it’s pretty well-documented (link) but, here’s an end-end example.

Assuming:

BILLING=[[YOUR-BILLING]]
PROJECT=[[YOUR-PROJECT]]
SERVER="us.gcr.io"

If not already:

gcloud projects create {$PROJECT}

gcloud beta billing projects link ${PROJECT} \
--billing-account=${BILLING}

gcloud services enable containerregistry.googleapis.com \
--project=${PROJECT}

Container Registry

IMAGE="busybox" # Or ...

docker pull ${IMAGE}

docker tag \
  ${IMAGE} \
  ${SERVER}/${PROJECT}/${IMAGE}

docker push ${SERVER}/${PROJECT}/${IMAGE}

gcloud container images list-tags ${SERVER}/${PROJECT}/${IMAGE}

Service Account

Create a service account that’s permitted to download (read-only) images from this project’s registry

I think it would be valuable if Google were to provide volumes in Cloud Build of package registries (e.g. Go Modules; PyPi; Maven; NPM etc.).

Google provides a mirror of a subset of Docker Hub. This confers several benefits: Google’s imprimatur; speed (latency); bandwidth; and convenience.

The same benefits would apply to package registries.

In the meantime, there’s a hacky way to gain some of the benefits of these when using Cloud Build.

In the following example, I’ll show an approach using Golang Modules and Google’s module proxy aka proxy.golang.org.

The prolific Alex Ellis has a new project, Inlets.

Here’s a quick tutorial using Google Compute Platform’s (GCP) Compute Engine (GCE).

NB I’m using one of Google’s “Always free” f1-micro instances but you may still pay for network *gress and storage

Assumptions

I’m assuming you’ve a Google account, have used GCP and have a billing account established, i.e. the following returns at least one billing account:

gcloud beta billing accounts list

If you’ve only one billing account and it’s the one you wish to use, then you can: