Forem: Josh Kasuboski

One API to Rule Them All: Building an OpenAI Gateway

Josh Kasuboski — Thu, 01 May 2025 23:23:59 +0000

I only speak OpenAI API now. Plus with logging.

Why I Needed This

I’ve been using different AI providers’ APIs for various projects, but I faced two main challenges:

Each provider has their own SDK and API format, requiring different code paths in my applications
I wanted better visibility into what was happening with my requests across all providers

Cloudflare’s AI Gateway provides great logging out of the box, but I still had the problem of juggling multiple SDKs and API formats. I wanted a single, consistent interface that would work with any AI provider while giving me all the logging benefits.

That’s why I created openai-gateway - a service that exposes an OpenAI-compatible API but can route to different AI providers behind the scenes.

How It Works

The concept is straightforward:

Your application sends requests to my gateway using the OpenAI API format
The gateway authenticates your request with a simple API key
It translates the request if needed and forwards it through Cloudflare AI Gateway to the appropriate provider (currently supporting Gemini)
The response comes back, gets converted to OpenAI format if necessary, and returns to your application
Cloudflare logs everything along the way

The whole thing runs as a Cloudflare Worker using Hono, making it lightweight and globally distributed.

Getting Started

Using it is as simple as changing your base URL. If you’re using the OpenAI SDK, it’s just:

const openai = new OpenAI({
 apiKey: "your-api-key",
 baseURL: "https://your-gateway-url/v1"
});

Or with curl:

curl https://your-gateway-url/v1/chat/completions \
 -H "Content-Type: application/json" \
 -H "Authorization: Bearer your-api-key" \
 -d '{
 "model": "gemini/gemini-pro",
 "messages": [{ "role": "user", "content": "Hello!" }]
 }'

Notice that even though we’re using Gemini as the provider, we’re still using the OpenAI SDK and API format. The model name gemini/gemini-pro tells the gateway which provider and model to use.

What You See in Cloudflare

This is where the magic happens. The Cloudflare dashboard gives you:

Complete request and response logging
Token counts for each request
Cost estimates based on your usage (I was using a free tier key in the screenshot)
Response times and error rates

All without changing how your application works or adding any custom logging code.

Lessons Learned

Building this was surprisingly simple. The entire project is just a few hundred lines of code, but it solves a real problem I was having.

I’ve liked making these small “glue” projects. They don’t need to be complex to be useful. Many small tools also makes it easier for the AI coders to work on them.

What’s Next

I’ve already implemented Gemini as the first provider, and I’m planning to expand support to include:

More AI providers like Anthropic
Enable more of the Cloudflare AI Gateway features like caching
Add request fallbacks, try another model if the first fails

Eventually it could become something more like OpenRouter.

But for now, it does exactly what I need - gives me visibility without complexity.

Try It Yourself

If you want to set up your own gateway try it out on cloudflare:

git clone https://github.com/kasuboski/openai-gateway.git
npm install
npm run dev

Or just star the repo and follow along as I add more features!

Building a Python Docker Image with Distroless and Uv

Josh Kasuboski — Sat, 08 Mar 2025 19:03:13 +0000

The images are too damn big! 📈 Let’s use a sane project manager and build an image with minimal dependences.

Tooling

This will assume you use uv to manage your python project. It’s really made me actually consider using python now… Uv has a pretty nice docker tutorial on GitHub that we’re going to base off. You can find that here.

It’s an example fastapi project that returns hello world.

What’s different?

Their example includes a standalone multi-stage build that is pretty good. The standalone aspect comes from allowing uv to install their version of python that will match your project. The multi-stage build ensures you end up with a base debian image with just python and your app.

I wanted to not include the source code of the app separately since it’ll be in the virtualenv anyway as well as get rid of debian.

So we’ll base on a google distroless image.

Breaking down the Dockerfile

If you’re impatient you can just read the Dockerfile. The first new thing is the builder is installing its own version of python. There are two environment variables that tell uv to only use the version of python that is managed by uv.

UV_PYTHON_INSTALL_DIR is the directory where the python version will be installed and UV_PYTHON_PREFERENCE tells uv to only use the version of python that is managed by uv.

It then actually installs python. After we get python, we can install the project dependencies. Uv can install only the dependencies with --no-install-project. It only needs the lock file and pyproject.toml for this. Installing the dependencies separately ensures better caching since you probably don’t change dependencies as much as the code.

After dependencies, we can copy the app and install the rest. Using --no-editable tells uv to not install the project with any dependency on the source code. Then our final image can be created from just the virtualenv.

The final runtime image is gcr.io/distroless/cc. This is a google distroless image that’s a little smaller than debian:slim. Some of your python dependencies might still expect glibc at runtime so we use cc vs a static option.

The only thing we need then is to copy the python we installed with uv and the virtualenv. Adding the virtualenv path lets us reference any of the tools like fastapi.

FROM ghcr.io/astral-sh/uv:bookworm-slim AS builder
ENV UV_COMPILE_BYTECODE=1 UV_LINK_MODE=copy

# Configure the Python directory so it is consistent
ENV UV_PYTHON_INSTALL_DIR=/python

# Only use the managed Python version
ENV UV_PYTHON_PREFERENCE=only-managed

# Install Python before the project for caching
RUN uv python install 3.12

WORKDIR /app
RUN --mount=type=cache,target=/root/.cache/uv \
 --mount=type=bind,source=uv.lock,target=uv.lock \
 --mount=type=bind,source=pyproject.toml,target=pyproject.toml \
 uv sync --frozen --no-install-project --no-dev --no-editable
COPY . /app
RUN --mount=type=cache,target=/root/.cache/uv \
 uv sync --frozen --no-dev --no-editable

# Then, use a final image without uv
FROM gcr.io/distroless/cc

# Copy the Python version
COPY --from=builder --chown=python:python /python /python

WORKDIR /app
# Copy the application from the builder
COPY --from=builder --chown=app:app /app/.venv /app/.venv

# Place executables in the environment at the front of the path
ENV PATH="/app/.venv/bin:$PATH"

# Run the FastAPI application by default
CMD ["fastapi", "run", "--host", "0.0.0.0", "/app/.venv/lib/python3.12/site-packages/uv_docker_example"]

But why?

Making the smallest image can help with startup time as you need to download and load less before you get to your app. For me, the biggest reason to go for a smaller image though is to reduce the vulnerability surface. You can’t have vulnerabilities if there’s nothing to be vulnerable.

Python isn’t super conducive to an ultra minimal image. The python interpreter is around 75MB with our virtualenv being around 55MB. The smallest image we could hope for is then 130MB. The distroless base is 23.5 MB so it’s quite a fraction of overall size.

The debian:bookworm-slim image is around 75MB. It also includes things like bash which can be nice for debugging, but also for vulnerabilities.

It is worth noting, when I was doing this, debian:bookworm-slim had no vulnerabilities reported by trivy. The base images are generally kept up to date to patch vulnerabilities, but more vulnerabilities are found because of their nature. If you are rebasing your images often it may not matter to you.

I previously explored continously scanning using trivy in a separate post using github actions.

Talos Cluster

Josh Kasuboski — Wed, 30 Oct 2024 19:46:23 +0000

Switching to a Kubernetes OS… Make the machine manage itself 🤖.

You what

I’ve now migrated just about everything from my old k3s cluster to a cluster run by Talos. From the Talos website, “Talos Linux is Linux designed for Kubernetes – secure, immutable, and minimal.” It has only what is needed for kubernetes and nothing else. Talos also claims to manage kubernetes operations for you (or at least expose commands for you to do it).

There is no ssh only a gRPC API. You get to install a new *ctl to your compute as talosctl. It applies declarative config files that manage the system. Most of my setup is checked in to my existing repo kasuboski/k8s-gitops. Depending when you’re reading this it might still be on its own branch feature/talos.

The migration

Just changing the kubernetes distribution surely wasn’t enough to keep me interested. I also needed to drastically change the nodes, ingress, and templating /s.

My previous k3s cluster had problems running a cloudflare tunnel consistently. I had ended up moving it out of the cluster until I figured out what was going on. While I was looking for a project to do it automatically I found the cloudflare-kubernetes-gateway project. It implements the Gateway API instead of Ingress and will setup and manage cloudflare tunnel for you. I was surprised how much this just worked after giving it a Cloudflare API key.

I also moved my local ingress from an nginx ingress controller to the envoy gateway. It implements the Gateway API by spinning up Envoy pods. I had MetalLB deployed in my old cluster, but never really used it for anything. Now my Envoy Gateway gets an IP address on my home network.

This let me run split dns where if you’re on my network my domain routes to the envoy gateway, but from outside you are routed to the cloudflare tunnel. I had generally been too chicken to mess with that before as DNS is always the problem. Indeed I’m still not sure I have the correct setup on my Macbook where Tailscale MagicDNS likes to overwrite my settings.

My home network DNS points to k8s_gateway running in the cluster that sets the records for the domain to be the MetalLB IP of the Envoy Gateway.

Hardware Changes

I had stopped running my Raspberry PIs awhile ago as I didn’t really have a use for them. Everything I needed to run was fine on just the mini PC or my NAS. Talos promises to make an HA control plane easier to manage though so I figured now’s the time.

I now have 3 Raspberry Pi 4 4GB running the kubernetes control plane with etcd running on a USB thumb drive. There is another Raspbery Pi 4 8Gb that is a worker. The HP mini pc is another worker and it has a bigger drive in it to store the sqlite databases for the various media apps.

The Raspberry Pi worker is nice for various apps that don’t need storage. For example, ArgoCD and the cluster gateway controllers can run there. I would like to set up replicated storage so more things can move around, but that’s more for fun than actual need.

My free Oracle VM is still outside the cluster as I didn’t want to deal with indirect connectivity while also learning about Talos. I may try and add it back in now. Talos has a KubeSpan feature that seems like it should make it fine. I am running the Tailscale extension on all of the nodes so far anyway so they should have connectivity.

Templating Changes

I switched the repo to use Cuelang.

Previously, I was already handcrafting most of the yaml and then using kustomize to tie it together. There were a few upstreams that had kustomizations I could pull in and then some helm charts I would manually run helm template on.

Now I made a wrapper that reads in a vendor.cue file and will download a yaml file from a URL or will run kustomize with a path. It then imports the yaml into Cue and I can use it in my configuration from there. The rest of my repo is structured to match how ArgoCD apps work. Resources are assigned to an app that is then tied to a namespace.

If you look in the repo you’ll see a manifests/ folder than is the output of the Cue files as JSON. ArgoCD is then setup to watch this folder. I’d like to eventually get rid of this setup and use store the manifests in an OCI registry. In the short time this has been setup, I still constantly forget to regenerate that manifests folder. I don’t know if I’ll modify ArgoCD to work with that setup or do something else. I could perhaps gasp generate helm charts that are stored in OCI.

I’ve liked working with Cue so far. I wish the autocomplete setup in VSCode was better, but I also usually only need to look up a field once since everything else can inherit from a base.

Moving Forward

I like the setup so far. I’m still worried about etcd burning through those usb drives so I should probably be setting up backups… My other planned changes I’ve already alluded to. I want to get the free Oracle VM added to the cluster. I also want to get rid of the manifests folder that I need to remember to update.

Maybe further down the line I’ll try out kubevirt to mess with development VMs. I’ve also been looking at running Piraeus since it seems like I could have replicated storage with only 2 nodes and have it be region and zone aware.

Running a Buildkit ARM Builder

Josh Kasuboski — Sun, 08 May 2022 20:34:19 +0000

I was sick of my hour long ARM docker builds. A 15x speedup using existing infrastructure isn't bad.

The Problem

I build my feedreader for ARM in Github Actions. The workflow builds a multi-arch docker image on push. The x86 build was pretty quick, but the ARM build was using qemu which made it take around an hour. QEMU certainly didn't help, but the Github Actions runners aren't exactly the biggest machines at 2 vcpu and 7GB ram.

My build was using the docker buildx action. This makes the build use the newish buildkit backend for docker, but it's still running on the actions runner. I wanted to see if I could run my own buildkit backend. There was the option to connect it with a remote docker endpoint or a kubernetes cluster. Neither of which are really that appealing to me, although exposing the docker daemon over Tailscale could be fun.

The Solution

Right as I was looking to run my own buildkitd, buildx had a PR merged that would enable a remote builder driver. This lets you run buildkitd somewhere and expose it over tcp. My kubernetes cluster has a free ARM node from Oracle that is pretty big (4 x 24GB). It's usually nowhere near fully utilized.

Running a builder on it seemed like a great way to use the excess resources. Combined with tailscale and the recommended mTLS auth I could have a rather secure build runner on my existing infrastructure.

Setting it up

The buildkit repo has instructions for running it over TCP. There is also an example that shows how to run it in kubernetes with a deployment. I chose the deployment and service option vs a statefulset with consistent hashing because I was planning to use registry caching anyway and don't have immediate plans for many different builds to use this.

I decided to expose it with Tailscale using the same process I had previously used for my feedreader. This means connecting to it requires you be on my tailnet (authenticated with Tailscale).

In addition to requiring you be authenticated with Tailscale, the doc still recommends you use mTLS because the steps being built in the builder could potentially access the daemon as well. The example has a script to set up the certs for you, but I wanted to use the step cli from Smallstep. It's still very simple, but I could control exactly what is set up.

Creating Certificates

The first step to run buildkitd was to create the certificates it wants. I decided to make a Root CA for this along with an Intermediate CA and then server and client certificates. I didn't spend too long debating this and just followed a Smallstep guide…

Creating the CA

step certificate create --profile root-ca "Buildkit Root CA" root_ca.crt root_ca.key

Creating the Intermediate CA

step certificate create "Buildkit Intermediate CA 1" \
 intermediate_ca.crt intermediate_ca.key \
 --profile intermediate-ca --ca ./root_ca.crt --ca-key ./root_ca.key

Creating the server cert

step certificate create buildkitd --san buildkitd --san localhost --san 127.0.0.1 buildkitd.crt buildkitd.key \
 --profile leaf --not-after=8760h \
 --ca ./intermediate_ca.crt --ca-key ./intermediate_ca.key --bundle --no-password --insecure

Creating the client cert

step certificate create client client.crt client.key \
 --profile leaf --not-after=8760h \
 --ca ./intermediate_ca.crt --ca-key ./intermediate_ca.key --bundle --no-password --insecure

You'll notice the server has a buildkitd san, which is how I'll access it over Tailscale. The local ones were for testing while port forwarding to the cluster.

Running the Server

You can find the example kubernetes yaml here. It expects a kubernetes secret with ca.pem and key.pem keys. You can generate that from below.

kubectl create secret generic buildkit-daemon-certs --from-file=key.pem=buildkitd.key --from-file=ca.pem=root_ca.crt --dry-run=client -oyaml

My actual deployment can be found in kasuboski/k8s-gitops. It includes the tailscale-proxy as well as a nodeSelector to make sure it schedules on the ARM node. It requests 1cpu and 512Mi with the limit set to 3.5cpu and 3Gi. It ends up having more cpu than Github Actions and isn't emulated. The memory is less, but hasn't been an issue.

Once the server is running, it will be available in tailscale at buildkitd since the proxy uses the deployment name.

Connecting as a Client

The client needs to have access over tailscale and a client cert. The easiest way is to use buildctl.

buildctl --addr 'tcp://buildkitd:1234' \
 --tlscacert root_ca.crt \
 --tlscert client.crt \
 --tlskey client.key \
 build --frontend dockerfile.v0 --local context=. --local dockerfile=.

Building on multiple platforms with different builders requires docker buildx. The remote driver is on master, but isn't in a release yet. You can build buildx yourself to get access to that feature, but I only used it from Github Actions.

The setup buildx action has the option to build buildx from a specific commit.

Running in Github Actions

If you want to skip to the workflow it's at kasuboski/feedreader.

The workflow will need secrets for Tailscale and the certificates. I use Doppler referral link to manage the secrets. It synced super fast and has a nicer interface than doing it per repo in Github imo.

Tailscale has a Github Action that will install and set it up given an auth key. They support ephemeral auth keys so you won't have a bunch of leftover machines in their system. Once installed, your workflow will have access to your tailnet and can reach buildkitd. It's worth noting DNS magically works thanks to Magic DNS. Connecting to a kubernetes pod with a nice name and no other network setup is life changing.

I had problems using the remote buildx driver with a different builder type. I ended up just running another buildkitd on the actions runner. In the future, I'd like to run an x86 builder on one of my nodes.

That's setup following inspiration from the buildx tests. This builder doesn't have mTLS setup, but I guess I'm fine for now since it's an ephemeral runner on Github's infrastructure 🤷‍♂️.

docker run -d --name buildkitd --privileged -p 1234:1234 moby/buildkit:buildx-stable-1 --addr tcp://0.0.0.0:1234
docker buildx create --name gh-builder --driver remote --use tcp://0.0.0.0:1234
docker buildx inspect --bootstrap

Adding my arm runner is done after as below. The certs have already been written to disk from the Github secrets.

docker buildx create --append --name gh-builder \
 --node arm \
 --driver remote \
 --driver-opt key="$GITHUB_WORKSPACE/key.pem" \
 --driver-opt cert="$GITHUB_WORKSPACE/client_cert.pem" \
 --driver-opt cacert="$GITHUB_WORKSPACE/ca_cert.pem" \
 tcp://buildkitd:1234
docker buildx ls

The docker buildx ls output should then show a gh-builder with two nodes, one supporting amd64 and the other arm.

After setting up the builder, the workflow went from an hour to under four minutes.

Next Steps

Building on my excess capacity has been great and I want to add an x86 node as well. I could have run my own Github Runners, but that seems much more intense. All of my repos are public as well, so I figure I might as well use the free actions minutes.

I do want to potentially make a service that will just give you a remote buildkit builder on demand. It's particularly helpful for ARM builds since those can be slow in emulation.

I also looked into the cross compilation options, but just getting a native builder seemed easier and more flexible. Your Dockerfile still has to not download a specific architecture explicitly, but otherwise most should be able to build multi-arch with this setup.

Connect to Kubernetes Pods with Tailscale

Josh Kasuboski — Sun, 03 Apr 2022 18:52:19 +0000

I wasn't ready to add auth to my new feedreader. So I built a moat with Tailscale.

What does that mean?

I added a kubernetes pod to my tailnet so it's accessible from anywhere that can route to Tailscale nodes. It also gets a nice domain name so http://feedreader works.

Tailscale actually has a blog post and example for how to set this up. I wanted it to be mildly different so modified their run script. They also don't publish their example image so I needed to build one.

You can see my version at kasuboski/tailscale-proxy. The main differences are it takes a HOSTNAME and DEST_PORT parameters.

The HOSTNAME is so you can set the name the node will show up as. This was important for kubernetes because I don't want the generated name of the pod to be how I access it. DEST_PORT is so you can have it forward to a different port. This allows you to run your app on 8080, but the tailscale-proxy will route any port to 8080 meaning you can hit it on 80 in your browser. This is required to not have :8080 ugliness after your URL.

But Why?

I've been making a feedreader to replace my running miniflux. It's my first real rust project and I wanted an even more minimal feedreader.

I haven't gotten around to figuring out users or authentication in the feedreader though. Despite this, it finally reached the point where I can use it as my main feedreader. However, I didn't exactly want an unauthenticated app hanging out on the internet for someone to ruin my day.

If you don't want to make authentication, just make it inaccessible. This is where Tailscale comes in. I already run Tailscale on all the nodes, which is how I'm able to have a multi-region k3s cluster. That doesn't make my pods routable though.

Tailscale has an option for a subnet router that is actually highlighted as how to access all things k8s in the examples. This probably would have been nice (and I might still add it), but I wouldn't automatically get dns routing I believe.

You can see how it's all put together in my k8s-gitops repo. The gist is that you add a sidecar container that starts tailscale and in my case adds an iptables rule which forwards all traffic to the app port. You can see my poor Doppler secret naming in there too where everything is using miniflux-secret.

So, no more auth?

I still want to add users to the feedreader so that you can have multiple users on one instance. It remains to be seen whether I'll just add basic auth or something more complicated. Tailscale let me focus on getting something usable quickly though.

After seeing how convenient it was to expose a pod with a dns name, I also want to make a debugging tool injecting tailscale to pods. I could then finely be rid of the finicky kubectl port-forward.

Multi-Region K3s

Josh Kasuboski — Thu, 11 Nov 2021 21:56:57 +0000

I had stood up a cluster in the cloud before moving. Now, I've added some nodes at home to round it out.

Why not just the cloud?

As previously mentioned in moving my cluster to the cloud, I run a VM for the control plane and then a free Oracle ARM 4x24 VM as a worker. You might think this is more than enough (and you'd probably be right), but there are some things that make more sense to run at home.

I currently run media services and backups at home. I also hope to mess around with more home automation things in the future. The media consumption is nice to be local, but it also saves on cloud network transfer costs. Overall, the cloud worker VM is going to be much more reliable than the small form factor PCs that make up my home region.

How's it actually work?

I install Tailscale on all of the machines. This lets them easily connect to each other as if they were on the same local network. The kubernetes API server only binds to the Tailscale interface so all of the workers are able to reach it. After setting this up, it mostly just works™️.

The nodes are separated into a cloud and home region. Each region is broken down into zones for the cloud provider or location. That ends up cloud-oracle, cloud-racknerd, home-austin, home-wisconsin region-zone pairs. I'm then able to use those labels for scheduling decisions.

So far I'm only using the zones for austin and wisconsin to pin my media options to the respective machines. Other things, including my RSS reader, are able to float between regions.

The Setup

The cluster is still managed with GitOps from the repo kasuboski/k8s-gitops. I'm using ArgoCD to apply the manifests, but might mess with other options.

I recently changed the secrets management from SealedSecrets to Doppler. There wasn't anything wrong with SealedSecrets, but it felt less magic since I had to make sure to manage the keys and reencrypt on changes. I have a script under hack/ in the repo that manages importing the correct Doppler project token. After creating their DopplerSecret CRD, the secrets then just show up.

Previously, I had run a separate VM to act as the entrypoint to the cluster. Now I use a loadbalancer from Oracle that points to the free ARM VM there. The DNS then points to this loadbalancer. I still want to add a separate ingress locally so I can avoid always going out and back in, but haven't gotten around to it.

I also still have 4 Raspberry Pis that I haven't setup yet since moving. The general layout is as below.

Further Improvements

I have a lot of the setup documented in kasuboski/home-infra, but realized as I was setting up the machine in Austin that it leaves a lot to be desired. In particular, the setup for storage had me looking back through the command history of the wisconsin machine to figure out what I had done.

I'm thinking to make a tool that will set this up or at least walk me through it. The home-infra repo needs to be cleaned up a little as well. It still contains instructions for multiple past iterations of my homelab.

Add Multi-Arch Dependencies Easily

Josh Kasuboski — Thu, 19 Nov 2020 17:02:45 +0000

I wanted to build a multi-arch docker image for media transcoding. Time to get the dependencies from someone who already did it.

The Goal

I wanted a multi-arch image to run mdhiggins/sickbeard_mp4_automator. I just needed the manual.py script not the radarr integration. The images published by mdhiggins are based on images like the linuxserver/radarr image and aren't multi-arch.

You can skip ahead to just see the Dockerfile at kasuboski/manual-sma.

The main issue for making the image multi-arch is ffmpeg. In the mdhiggins/radarr-sma Dockerfile, it is always downloading the amd64 version of ffmpeg. This obviously won't go well for other architectures.

There are ffmpeg builds published for other architectures. You would just need to make sure to download the correct one.

The Lazy Solution

It wouldn't be too bad to figure out which architecture is being built and then download the correct version of ffmpeg. It is one more script to maintain though.

I noticed the linuxserver repo has a multi-arch ffmpeg container already. They include a statically compiled ffmpeg so getting it into my image is as easy as copying the binary.

Dockerfiles have a COPY --from=<image> option. This lets you copy files from another image. That image will automatically be the correct one for your architecture (as long as the image supports it).

So instead of figuring out the correct architecture and downloading the corresponding ffmpeg. You can just add FROM linuxserver/ffmpeg as ffmpeg and then COPY --from=ffmpeg /usr/local/bin/ff* /usr/local/bin/.

This will copy both ffmpeg and ffprobe to the built container.

To build the image, I used the same method as my building multiarch images post. Basically, setting up docker buildx in GitHub Actions. You can see the workflow at kasuboski/manual-sma.

Leaving Feedly for Miniflux

Josh Kasuboski — Fri, 13 Nov 2020 19:57:42 +0000

I've wanted to move away from Feedly for awhile and finally found my alternative in Miniflux.

Why the move

I had been having issues with the Feedly app where it would suddenly sign me out and take a while to log back in. Apparently that's all it takes for me to drop a service… I also wanted to run something myself and possibly build on top of it.

I had contemplated moving to microsub as outlined in my replacing Feedly post. I tried out ekster and I think it's still running 🤷‍♂️. I didn't like the readers I tried and wasn't a fan of how ekster doesn't seem to store data persistently.

Moving to Miniflux

I recently found miniflux. It bills itself as “a minimalist and opinionated feed reader”. Minimalist and opinionated is all I can hope to be. Thankfully the opinions aligned pretty well with mine.

It's just a go binary and PostgreSQL. I run the binary on my kubernetes cluster and PostgreSQL on a Lenovo Thinkcentre I recently bought. I'm still not super happy in my openEBS storage so am running the database using podman with a volume mount directly from the node.

Running containers as a non-root account is pretty easy with podman and can be managed by systemd. I did the below to set it up.

podman create --name postgres -v /home/postgres/postgres:/bitnami/postgresql -e POSTGRESQL_PASSWORD=<root password> -p 5432:5432 bitnami/postgresql:13
podman generate systemd postgres -n

You'll notice I'm using the bitnami postgresql image. This image doesn't run as root 👍. The output of the podman generate systemd can then be copied to $HOME/.config/systemd/user. More info can be found on the podman site.

I like the minimal UI and it works pretty well on mobile as well. The delay in fetching feeds took a little getting used to. I did lower the thresholds, which was just an environment variable config. You can see my kubernetes config in kasuboski/k8s-gitops

Moving Forward 🐱‍🏍

With Feedly I had a limited set of feed categories because that was a limitation of the free plan. I want to decide what I actually want now that I have no limits with miniflux.

There is also an API that I want to build some things around. My first thought would be to make a way for others to follow what I follow as well.

Copy files to and from Kubernetes Pods with kubectl

Josh Kasuboski — Fri, 06 Nov 2020 02:46:06 +0000

I wanted a simple backup of some OpenEBS volumes. Why not just copy them out.

Why bother

I run a number of things on my Raspberry Pi kubernetes cluster that require storage. The main one I actually care about is my fathom instance.

It has the website analytics for my site joshkasuboski.com. It's certainly not the end of the world to lose this information, but I'd really rather not. Previously, I had tried to get velero setup.

I tried to use both the OpenEBS specific plugin and the generic restic. The OpenEBS one failed because my setup couldn't take snapshots. My USB drives are pretty slow so I just chalk it up to that. The restic option seemed to work, but it didn't actually restore data in my test. In addition, it kept exceeding my backblaze s3 api limits.

Anyway, I just wanted something simple before I upgraded OpenEBS. Then I found the kubectl cp command.

Backing up the volumes

I manually backed up all of my persistent volumes. This is only five items for me, but could get out of hand quickly. It was really as simple as running the command for each and storing the files locally.

Copying files from a pod to your machinekubectl cp <namespace>/<podname>:/mount/path /local/path

I did this for all paths I cared about. If something goes wrong you can always copy the files back to the pod. It's the same command just swapping source and destination.

Copying files to a pod from your machinekubectl cp /local/path <namespace>/<podname>:/mount/path

I still hope to get OpenEBS snapshots working in the future, but this worked great for now.

Client Side Shopping Cart

Josh Kasuboski — Thu, 29 Oct 2020 19:15:57 +0000

I have my beer can working as a buy button, but what if you want to add products to a cart first.

But Why

If you're trying to sell things easily (and cheaply) you can connect Stripe directly to a product page. You can see an example of this from the stripe beer money article.

The main downside is that a customer would have to buy one thing at a time. We can add a cart, but still don't want to require a server.

Creating a Cart

For a cart, we just need to keep track of items added and how many of each. We can store this information in localstorage. This means if a user comes back to the page, their cart will still be there.

I tested this out with a sample store page. You can see the code at kasuboski/client-side-cart-example.

It's basically a single index.html with javascript. It looks for products by finding buttons with data attributes. These attributes specify the product id, description and price.

When a user clicks the button, the item is added to the cart. This just loads the cart from localstorage updates the item quantity and saves it back.

  function addToCart(data) {
    var cart = getCart()
    var prevQuantity = cart[data.id] ? cart[data.id].quantity : 0;
    cart[data.id] = {
      quantity: prevQuantity + 1,
      data,
    }

    localStorage.setItem('cart', JSON.stringify(cart));

    populateCart();
  }

The populateCart function sets up the cart area every time. There isn't anything fancy here… it just deletes all of the cart elements and recreates based on what's in localstorage.

Next Steps 🦶

This works as a generic cart… but you can't buy anything. I'm going to make an example store to show buying items using Stripe.

Each item will need a Stripe Price and then when you Checkout it will call the Stripe redirect. Eventually, I want to make it easier to integrate as well. Maybe making this an actual library.

Scan Images in my GitOps Repo

Josh Kasuboski — Thu, 22 Oct 2020 19:41:31 +0000

Scanning the container images deployed to my cluster used to be manual. Now it happens automatically every night. 🐱‍🏍

How to Scan

I use Trivy to scan container images. I wrote about scanning my GitOps repo for images earlier here. Basically, there's a fancy grep that matches image: (<name>) and that name is sent to Trivy.

My GitOps repo is on GitHub at kasuboski/k8s-gitops. It seemed natural to run the scan periodically using GitHub Actions. The scan will happen on every push and every night.

I needed a way to exclude an image that wasn't able to scan on an x86 host. The one liner from my previous post needed a grep -v to exclude certain patterns.

Making the GitHub Actions Workflow

I had a lot of trouble getting ack configured in a runner. I ended up making a docker image that downloads trivy, finds the images, and scans them.

This image has its own repo kasuboski/trivy-scan-dir. If you just want to scan a repo you can run docker run -it --rm -v /path/to/yaml:/gitops -e EXCLUDED='no/scan also/noscan' kasuboski/trivy-scan-dir.

To run this in a workflow, add the below step.

- name: Scan Images
uses: docker://kasuboski/trivy-scan-dir:latest
env:
EXCLUDED: 'no/scan also/noscan'

My full workflow can be found in kasuboski/k8s-gitops. It triggers on workflow_dispatch, cron, and push to yaml files.

Workflow Dispatch lets you run the workflow manually from the GitHub Actions UI. This was really convenient for testing. The cron schedule runs every morning at 4:03am.

Results

This workflow has alerted me to multiple vulnerabilities. If the workflow fails, I get an email and then can look into updating the image.

The results even look pretty decent in the GitHub app so I can tell which images I need to be worried about. An example failing run is shown below.

I still want to add something in cluster to enforce only the images I want are running. Finding the images to scan also needs to be more robust. For instance, some images only show up once manifests are rendered.

Accept Beer Money with Stripe - Sans Server

Josh Kasuboski — Thu, 15 Oct 2020 15:51:52 +0000

I wanted to explore Stripe Payments, but didn't want to mess with a server. You can see the result as the little beer can in the footer of my site 😉.

How It Works

Stripe has a Checkout option where you redirect to their page and it has your product and a payment form. This means you don't have to deal with PCI anything and basically just have to redirect correctly. They have a library to handle the redirect as well, so it's fairly easy.

You need to place a button that when clicked calls the Stripe Javascript library. Since I'm “selling” beer money, I put a little beer can in my site footer.

Adding to Your Site

I followed this guide from Stripe. It was a little difficult to find navigating the Stripe Docs, but searching Stripe Checkout without server brought me there.

I won't reiterate the guide, but basically you use the Stripe Dashboard to make a Product that has a Price. That price will then have an ID that you need. The dashboard will also generate the code snippet with the price ID and your API ID filled in. My edited snipped is below.

You'll notice it also expects a success and cancel URL. I added two pages that just say success, and uh oh respectively.

<script src="https://js.stripe.com/v3"></script>
<script>
  (function () {
    var DOMAIN = 'https://www.joshkasuboski.com/';
    var key = '<pk_livekey>';
    var price = '<price_key>';
    var stripe = Stripe(key);

    var checkoutButton = document.getElementById('checkout-button-beermoney');
    checkoutButton.addEventListener('click', function () {
      // When the customer clicks on the button, redirect
      // them to Checkout.
      stripe.redirectToCheckout({
        lineItems: [{ price: price, quantity: 1 }],
        mode: 'payment',
        // Do not rely on the redirect to the successUrl for fulfilling
        // purchases, customers may not always reach the success_url after
        // a successful payment.
        // Instead use one of the strategies described in
        // https://stripe.com/docs/payments/checkout/fulfillment
        successUrl: DOMAIN + 'success',
        cancelUrl: DOMAIN + 'canceled',
      })
        .then(function (result) {
          if (result.error) {
            // If `redirectToCheckout` fails due to a browser or network
            // error, display the localized error message to your customer.
            var displayError = document.getElementById('error-message');
            displayError.textContent = result.error.message;
          }
        });
    });
  })();
</script>

That snippet and the button were all that I needed. Stripe will also provide testing keys for both price and API. So you can test with that first to make sure it is working.

After I set that up, I can click my beer can and end up at a page like below.

💰💰💰 Profit 💰💰💰

Other Cases

This works pretty well if someone would only buy one item at a time. You could probably make a cart entirely on the frontend, keeping track of items a user wants and then when a user clicks checkout, you would send multiple lineItems in the Stripe Redirect.

This may not be good enough for a real store, but it's pretty convenient to have a fully client-side storefront.