Obsessing on gRPC Firestore Listen somewhat but it’s also a good learning opportunity for me to write stuff in Rust. This doesn’t work against Google’s public endpoint (possibly for the same reason that gRPCurl doesn’t work either) but this does work against the Go server described in the other post.

I’m also documenting here because I always encounter challenges using TLS with Rust (and this documents 2 working ways to do this with gRPC) as well as references two interesting (rust) examples that use Google services.

After recently discovering FauxRPC, I was sufficiently impressed that I decided to use it to test Ackal’s gRPC services using rust.

FauxRPC provides multi-protocol support and so, after successfully implementing the faux gRPC client tests, I was compelled to try gRPC-Web too. For no immediate benefit other than, it’s there, it’s free and it’s interesting. As an aside, the faux REST client tests worked without issue using Reqwest.

Unfortunately, my optimism hit a wall with gRPC-Web and what follows is a summary of my unresolved issue.

Read FauxRPC + Testcontainers on Hacker News and was intrigued. I spent a little more time “evaluating” this than I’d planned because I’m forcing myself to use rust as much as possible and my ignorance (see below) caused me some challenges.

The technology is interesting and works well. The experience helped me explore Testcontainers too which I’d heard about but not explored until this week.

For my future self:

I started following along with FauxRPC’s Testcontainers example but, being unfamiliar with Connect, I wasn’t familiar with its Eliza service. The service is available on demo.connectrpc.com:443 and is described using eliza.proto as part of examples-go. Had I realized this sooner, I would have used this example rather than the Health Checking protocol.

A lazy Sunday afternoon and my interest was piqued by XML-RPC

Client

A very basic XML-RPC client wrapped in a Cloud Functions function:

main.py:

import functions_framework
import os
import xmlrpc.client


endpoint = os.get_env("ENDPOINT")

proxy = xmlrpc.client.ServerProxy(endpoint)

@functions_framework.http
def add(request):
    print(request)
    rqst = request.get_json(silent=True)

    resp = proxy.add(
        {"x":{
            "real":rqst["x"]["real"],
            "imag":rqst["x"]["imag"]
        },
        "y":{
            "real":rqst["y"]["real"],
            "imag":rqst["y"]["imag"]
        }
    })

    return resp

requirements.txt:

functions-framework==3.*

Run it:

python3 -m venv venv
source venv/bin/activate
python3 -m pip install --requirement requirements.txt

export ENDPOINT="..."

python3 main.py

Server

Forcing myself to go Rust first and there’s an (old) xml-rpc crate.

For the first time, I chose Rust to solve a problem. Until this, I’ve been trying to use Rust to learn the language and to rewrite existing code. But, this problem led me to Rust because my other tools wouldn’t cut it.

The question was how to represent oneof fields in Kubernetes Custom Resource Definitions (CRDs).

CRDs use OpenAPI schema and the YAML that results can be challenging to grok.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: deploymentconfigs.example.com
spec:
  group: example.com
  names:
    categories: []
    kind: DeploymentConfig
    plural: deploymentconfigs
    shortNames: []
    singular: deploymentconfig
  scope: Namespaced
  versions:
  - additionalPrinterColumns: []
    name: v1alpha1
    schema:
      openAPIV3Schema:
        description: An example schema
        properties:
          spec:
            properties:
              deployment_strategy:
                oneOf:
                - required:
                  - rolling_update
                - required:
                  - recreate
                properties:
                  recreate:
                    properties:
                      something:
                        format: uint16
                        minimum: 0.0
                        type: integer
                    required:
                    - something
                    type: object
                  rolling_update:
                    properties:
                      max_surge:
                        format: uint16
                        minimum: 0.0
                        type: integer
                      max_unavailable:
                        format: uint16
                        minimum: 0.0
                        type: integer
                    required:
                    - max_surge
                    - max_unavailable
                    type: object
                type: object
            required:
            - deployment_strategy
            type: object
        required:
        - spec
        title: DeploymentConfig
        type: object
    served: true
    storage: true
    subresources: {}

I’ve developed several Kubernetes Operators using the Operator SDK in Go (which builds upon Kubebuilder).

General

You’ll need a Google Cloud project with Cloud Translation (translate.googleapis.com) enabled and a Service Account (and key) with suitable permissions in order to run the following.

BILLING="..." # Your Billing ID (gcloud billing accounts list)
PROJECT="..." # Your Project ID
ACCOUNT="tester"

EMAIL="${ACCOUNT}@${PROJECT}.iam.gserviceaccount.com"

ROLES=(
    "roles/cloudtranslate.user"
    "roles/serviceusage.serviceUsageConsumer"
)

# Create Project
gcloud projects create ${PROJECT}

# Associate Project with your Billing Account
gcloud billing accounts link ${PROJECT} \
--billing-account=${BILLING}

# Enable Cloud Translation
gcloud services enable translate.googleapis.com \
--project=${PROJECT}

# Create Service Account
gcloud iam service-accounts create ${ACCOUNT} \
--project=${PROJECT}

# Create Service Account Key
gcloud iam service-accounts keys create ${PWD}/${ACCOUNT}.json \
--iam-account=${EMAIL} \
--project=${PROJECT}

# Update Project IAM permissions
for ROLE in "${ROLES[@]}"
do
  gcloud projects add-iam-policy-binding ${PROJECT} \
  --member=serviceAccount:${EMAIL} \
  --role=${ROLE}
done

For the code, you’ll need to install protoc and preferably have it in your path.

I’ve written before about Ackal’s use of Firestore and subscribing to Firestore document CRUD events:

• Routing Firestore events to GKE with Eventarc
• Cloud Firestore Triggers in Golang using Firestore triggers

I find Google’s Eventarc documentation to be confusing and, in typical Google fashion, even though open-sourced, you often need to do some legwork to find relevant sources, viz:

• Google’s Protobufs for Eventarc (using cloudevents) google-cloudevents1
• Convenience (since you can generate these using protoc) language-specific types generated from the above e.g. google-cloudevents-go; google-cloudevents-python etc.

1 – IIUC EventArc is the Google service. It carries Google Events that are CloudEvents. These are defined by protocol buffers schemas.

I naively (!) began exploring JSON marshaling of Protobufs in rust. Other protobuf language SDKs include JSON marshaling making the process straightforward. I was to learn that, in rust, it’s not so simple. Unfortunately, for me, this continues to discourage my further use of rust (rust is just hard).

My goal was to marshal an arbitrary protocol buffer message that included a oneof feature. I was unable to JSON marshal the rust generated by tonic for such a message.

I wrote about Navigating Koyeb’s Golang SDK. That client is generated using the OpenAPI Generator project using Koyeb’s Swagger (now OpenAPI) REST API spec.

This post shows how to generate a Rust SDK using the Generator and provides a very basic example of using the SDK.

The Generator will create a Rust library project:

VERS="v7.2.0"

PACKAGE_NAME="koyeb-api-client-rs"
PACKAGE_VERS="1.0.0"

podman run \
--interactive --tty --rm \
--volume=${PWD}:/local \
docker.io/openapitools/openapi-generator-cli:${VERS} \
generate \
-g=rust \
-i=https://developer.koyeb.com/public.swagger.json \
-o=/local/${PACKAGE_NAME} \
--additional-properties=\
packageName=${PACKAGE_NAME},\
packageVersion=${PACKAGE_VERS}

This will create the project in ${PWD}/${PACKAGE_NAME} including the documentation at:

Ackal uses a Kubernetes Operator to orchestrate the lifecycle of its health checks. Ackal’s Operator is written in Go using kubebuilder.

Yesterday, my interest was piqued by a MetalBear blog post Writing a Kubernetes Operator [in Rust]. I spent some time reimplementing one of Ackal’s CRDs (Check) using kube-rs and not only refreshed my Rust knowledge but learned a bunch more about Kubernetes and Operators.

While rummaging around the Kubernetes documentation, I discovered flant’s Shell-operator and spent some time today exploring its potential.

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.

This blog summarizes my thoughts about Akri and an explanation of the HTTP protocol implementation in the hope that this helps others.

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:

You will want to install rust nightly (as Rocket has a dependency that requires it) and then you can override the default toolchain for the current project using:

I’ve spent time recently playing around with WebAssembly (WASM) and waPC. Rust and WASM were born at Mozilla and there’s a natural affinity with writing WASM binaries in Rust. In the WASM examples I’ve been using for WASM Transparency, waPC and MsgPack and waPC and Protobufs.

I’ve created 3 WASM binaries: complex.wasm, simplex.wasm and fabcar.wasm and each is about 2.5MB when:

cargo build --target=wasm32-unknown-unknown --release

The Rust and WebAssembly book has an excellent section titled Shrinking .wasm. Code Size. So, let’s see what help that provides.

I’ve been playing around with a proof-of-concept combining WASM and Trillian. The hypothesis was to explore using WASM as a form of chaincode with Trillian. The project works but it’s far from being a chaincode-like solution.

Let’s start with a couple of (trivial) examples and then I’ll explain what’s going on and how it’s implemented.

2020/08/14 18:42:17 [main:loop:dynamic-invoke] Method: mul
2020/08/14 18:42:17 [random:New] Message
2020/08/14 18:42:17 [random:New] Float32
2020/08/14 18:42:17 [random:New] Float32
2020/08/14 18:42:17 [random:New] Message
2020/08/14 18:42:17 [random:New] Float32
2020/08/14 18:42:17 [random:New] Float32
2020/08/14 18:42:17 [Client:Invoke] Metadata: complex.wasm
2020/08/14 18:42:17 [main:loop:dynamic-invoke] Success: result:{real:0.036980484 imag:0.3898267}

After shipping a Rust-sourced WASM solution (complex.wasm) to the WASM transparency server, the client invokes a method mul that’s exposed by it using a dynamically generated request message and outputs the response. Woo hoo! Yes, an expensive way to multiple complex numbers.

As my reader will know (Hey Mom!), I’ve been noodling around with WASM and waPC. I’ve been exploring ways to pass structured messages across the host:guest boundary.

Protobufs was my first choice. @KevinHoffman created waPC and waSCC and he explained to me and that wSCC uses Message Pack.

It’s slightly surprising to me (still) that technologies like this exist with everyone else seemingly using them and I’ve not heard of them. I don’t expect to know everything but I’m surprised I’ve not stumbled upon msgpack until now.

A digression thanks to Sal Rashid who’s exploring WASM filters w/ Envoy.

The documentation is sparse but:

• How to write WASM filters for Envoy…

There is a Rust SDK but it’s not documented:

• proxy-wasm-rust-sdk

I found two useful posts by Rustaceans who were able to make use of it:

• Extending Envoy with WASM and Rust
• Extending Istio with Rust and WebAssembly

Here’s my simple use of the SDK’s examples.

wasme

curl -sL https://run.solo.io/wasme/install | sh
PATH=${PATH}:${HOME}/.wasme/bin
wasme --version

It may be possible to avoid creating an account on WebAssemblyHub if you’re staying local.

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].

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:

<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.

I’ve finally being able to hack my way through to a working Rust gRPC client (for PyPi Transparency).

It’s not very good: poorly structured, hacky etc. but it serves the purpose of giving me a foothold into Rust development so that I can evolve it as I learn the language and its practices.

There are several Rust crates (SDK) for gRPC. There’s no sanctioned SDK for Rust on grpc.io.

I chose stepancheg’s grpc-rust because it’s a pure Rust implementation (not built atop the C implementation).