deploy: 190e0b2835

js/flexsearch.84fad1d1396df61912fa589a19522118b5b3eb0806f4f7161f1034dc0672a3270863d0b236a15e1797d3a78930568729f80f15d66d73f2dc11044a5152de00b2.js

@@ -28,8 +28,8 @@ Areas for improvement# One enhancement that I would like to see is the ability t
 Conclusion# Gitea Actions are fast and the resource footprint is minimal. My gitea instance is currently using around 250mb of memory and a small fraction of a single cpu core (and the runner is using a similar amount of resources). This is impressive since many alternatives tend to require substantially more resources. It likely helps that the codebase is largely written in go.
 By combining gitea with the networking marvel that is tailscale, running workflows becomes simple and fun. Whether you are working on a team or working alone, this setup ensures that your workflows are securely accessible from anywhere with an internet connection.
 Check out my gitea instance exposed via Funnel here.
-`}).add({id:1,href:"/blog/using-aks-and-socks-to-connect-to-a-private-azure-db/",title:"Using AKS and SOCKS to connect to a private Azure DB",description:`I ran into a roadblock recently where I wanted to be able to conveniently connect to a managed postgres database within Azure that was not running on public subnets. And by conveniently, I mean that I’d rather not have to spin up an ephemeral virtual machine running in the same network and proxy the connection, and I’d like to use a local client (preferably with a GUI). After several web searches, it became evident that Azure does not readily provide much tooling to support this.
-`,content:`I ran into a roadblock recently where I wanted to be able to conveniently connect to a managed postgres database within Azure that was not running on public subnets. And by conveniently, I mean that I’d rather not have to spin up an ephemeral virtual machine running in the same network and proxy the connection, and I’d like to use a local client (preferably with a GUI). After several web searches, it became evident that Azure does not readily provide much tooling to support this.
+`}).add({id:1,href:"/blog/using-aks-and-socks-to-connect-to-a-private-azure-db/",title:"Using AKS and SOCKS to connect to a private Azure DB",description:`I ran into a roadblock recently where I wanted to conveniently connect to a managed postgres database within Azure that was not running on public subnets. And by conveniently, I mean that I’d rather not have to spin up an ephemeral virtual machine running in the same network and proxy the connection, and I’d like to use a local client (preferably with a GUI). After several web searches, it became evident that Azure does not readily provide much tooling to support this.
+`,content:`I ran into a roadblock recently where I wanted to conveniently connect to a managed postgres database within Azure that was not running on public subnets. And by conveniently, I mean that I’d rather not have to spin up an ephemeral virtual machine running in the same network and proxy the connection, and I’d like to use a local client (preferably with a GUI). After several web searches, it became evident that Azure does not readily provide much tooling to support this.
 Go Public?# Should the database be migrated to public subnets? Ideally not, since it is good practice to host internal infrastructure in restricted subnets.
 How do others handle this?# With GCP, connecting to a private db instance from any machine can be achieved with cloud-sql-proxy. This works by proxying requests from your machine to the SQL database instance in the cloud, while the authentication is handled by GCP’s IAM.
 So what about Azure? Is there any solution that is as elegant as cloud-sql-proxy?