Talk on IPv6 at IIT Delhi and redirection service on cloud run

25-03-2023

Last few weeks went extremely busy. Feb + the first few days of Mar were spent in the Philippines for APRICOT 2023. This was the first time I spent close to 15 days at an APRICOT event due to involvement in workshops. Anyways, I enjoyed it. So far I have done this workshop on network automation twice (at SANOG 38 and APRICOT 2023) and both times I get attendees with a different sets of skillset. In SANOG 38 I assumed I will see network admins but the majority of attendees were sys admins. In APRICOT 2023 I assumed there will be sys admins but the majority of attendees were network admins. 😄

As soon as I came back from the Philippines, I caught up with typhoid which felt like a harsh viral. Going through fever cycles for a few days until the effect of anti-biotics kicked in besides regular usage of fever medicine to keep body temperature in control. I am now fully recovered and back online!

INNOG 6

Earlier this week was INNOG 6 at IIT Delhi. I have already expressed my frustrations with (non) working of INNOG here and there’s not much to add beyond that. I gave a talk on IPv6 and internet infrastructure. This talk was with the assumption that attendees would be a considerable number of local students (though that didn’t hold).

Self-hosted URL shortener and high availability

For a long time, I used Google’s URL shorter which was part of Google Apps/Gsuite and that worked until Google decided to shut it down. While listening to Corey Quinn’s podcast Screaming in the cloud I found a better offering. I occasionally listen to this podcast wherever it’s about these interesting tools. Corey mentioned that he uses a Cloud run-based URL shortener which uses Google Spreadsheets as a frontend to put shortcodes. The project is called sheets-url-shortener and to make deployment super easy it even has a “Run on Google Cloud”. I played with it and ended up using it for a couple of months until I had to give up because of latency issues. Here’s the podcast if interested in cloud run and that tool.

About Google Cloud run

Google Cloud run is a serverless container hosting service. It was originally designed to run workloads of web/API traffic but now with Cloud run jobs can also do batch jobs like running scripts to process data, format data etc. What makes it more attractive than a typical virtual machine/server is that Google charges for CPU and memory on a per 100ms basis besides a fair amount of free monthly quote on the service. While the pricing in per second can be hard to read, I usually convert it into $ per hour to get a realistic idea. E.g $0.00002400/vCPU per second simply means one can have a 1 CPU for 11.5 hrs for $1. Many applications fit this use case where the app itself is running for barely a few hours or less in a month. And that too with a feature of serverless, auto-scaling, redundancy etc. To build something similar one can do in Kubernetes with a couple of servers and a load balancer but that is way more expensive for lower compute loads.

While the tool Corey suggested had latency but that seems to be from the fact that the tool running on Cloud run was contacting Google spreadsheet API to read sheets. I honestly don’t know where these API endpoints are hosted. Google typically terminates TCP sessions to the nearest proxy server and hence ICMP latency is mostly sub-10ms but the actual application might be hosted far away in California or Ashburn. I can in theory self-host similar tools but self-hosted with high availability along with low latency is tricky. Thus I decided to stick with cloud run but put something simpler.

Cloud run can deploy any stateless docker image and open source web server Caddy seems to be gaining significant popularity over time. It has simper config syntax, is fast and has many key features built-in (like certbot for SSL). Since cloud-run containers are stateless, I decided to simply pack Caddy with Caddyfile (which is the config file it reads) in the docker image and Caddyfile would have the redirection configs I need.

Caddyfile config:

http://:{$PORT} {
    redir / https://anuragbhatia.com permanent
    redir /india_cdn_summary https://docs.google.com/spreadsheets/d/16T4FFPigQoFGafwBgjUlwTXkk0nh-LTUoYiUodRt2Cc/edit?usp=sharing permanent # Used in https://anuragbhatia.com/post/2022/12/mapping_cdn_across_india/
    redir /india_cdn_raw_sheet https://docs.google.com/spreadsheets/d/e/2PACX-1vRaIS37r3ct9A9fSgOTAcChzjAGr3tbvOzXG2qjvmeDj_fmdEiLv6E2PPuh-gw-YuvGsaTCwLgbJSvW/pubhtml?gid=2029815842&single=true permanent # Used in https://anuragbhatia.com/post/2022/12/mapping_cdn_across_india/
    redir /india_cdn_raw_text https://cdn.anuragbhatia.com/web/post/2022/12/mapping_cdn_across_india/cdns_in_lookup.txt permanent 
    redir /pgp https://anuragbhatia.com/page/anurag-pgp-pub.txt permanent #My PGP key
    redir /fna_22nov https://docs.google.com/spreadsheets/d/e/2PACX-1vSMJeGoKI3UE17YcBjztGH_ijRfAPoithmbALsrAVTV4sq0lg2yWX2d5cXNOGpgxp2GeL_I6PvW4zIB/pubhtml?gid=1816241942&single=true permanent #Used in https://anuragbhatia.com/2019/11/networking/isp-column/facebook-fna-node-update/
    redir /innog6 https://docs.google.com/presentation/d/1e680GMhfkIy_x9Uj-e1QAY12F9NhoXZn2oB_X3H0kFA/edit?usp=sharing permanent # Used in INNOG 6
}

I am using the $PORT variable here because that is what Google Cloud run expects our app to be listening on. I read somewhere that it’s mostly port 8080 but anyways why hard bind it unless the documentation says so? It is documented here in the container runtime contract.

Here’s the Dockerfile to build a container with this image while using Caddy’s official image as the base image:

FROM caddy:alpine
ADD Caddyfile /etc/caddy/Caddyfile

This service is now running on https://link.anuragbhatia.com and gives me a virtually free, highly available URL redirection service. I have it configured with cloud repositories for now where cloud build rebuilds the container whenever a change is detected in this file. I will eventually migrate the cloud build setup to Gitlab CI/CD pipeline because then the build can happen on my servers instead of some free few mins usage trial on the Google cloud.

A sample of how it works:

anurag@desktop ~> time curl -s -I https://link.anuragbhatia.com/innog6
HTTP/2 301 
location: https://docs.google.com/presentation/d/1e680GMhfkIy_x9Uj-e1QAY12F9NhoXZn2oB_X3H0kFA/edit?usp=sharing
x-cloud-trace-context: a9e6dbae8aa675c4f59a679f0a1e257b;o=1
date: Sat, 25 Mar 2023 15:40:30 GMT
content-type: text/html
server: Google Frontend


________________________________________________________
Executed in  199.98 millis    fish           external
   usr time   32.93 millis  236.00 micros   32.70 millis
   sys time    0.07 millis   75.00 micros    0.00 millis

anurag@desktop ~>

And you landed on this blog via this redirection service since I put different shortcodes for each blog post based on each platform.