dave/site
1
0
Fork 0
mirror of https://github.com/davegallant/davegallant.github.io.git synced 2025-08-07 00:58:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

deploy: 54de6a38c8

Browse Source
This commit is contained in:
davegallant
2024-03-19 00:38:18 +00:00
parent 8ec67f7041
commit f44399cb08
72 changed files with 73 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
js/flexsearch.c984731b5ba976a521bd5d267268c2a14033a8ebe8ae7c2664eb4b3e4aa6c5aacc7a1df2f2392982b502101cff4584e6f529fb00409fa9368b3c9ea788239547.js → js/flexsearch.ee06a8e49d94747c5bfb179b1ed9a799ceaad7c3c4ef35ada056f3ae5c57187f92991fe43f3332dc3796786ce5991d57b62e12976099bae0149c21b60f58532c.js
View File

@@ -27,6 +27,7 @@ You may be wondering how the gitea runner is allowed to connect to the other hos
Areas for improvement# One enhancement that I would like to see is the ability to send notifications on workflow failures. Currently, this doesn’t seem possible without adding logic to each workflow.
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.
Go Public?# Should the database be migrated to public subnets? Ideally not, since it is good practice to host internal infrastructure in restricted subnets.