Integrate that with kubernetes and I'm sold.
Readit NewsmrAssHat commented on My VM is lighter (and safer) than your container (2017) dl.acm.org/doi/10.1145/31... · Posted by u/fanf2
mrAssHat commented on Can You Grok It – Hacking together my own dev tunnel service 0xda.de/blog/2024/04/can-... · Posted by u/0xdade
I hacked together nginx, ssh, and a little bit of bash to make a simple dev tunnel service on my own domain. I thought HN readers could appreciate (and probably roast) it.
Hacking all those things together feels empowering, like a complex construct that can be built from simple things we are already used to. This article has a very "hacky" spirit, love it!
Thanks for the great question! I think the main issue for me is I don't want to install and maintain multiple different services (contacts, calendar, tasks, files, notes, photos, though arguably those could all "fit" in 2 services -- which is why I have two Nextcloud instances), and having a single service/server with those becomes easier to maintain.
They all use open standards (CardDav, CalDav, WebDav), and that's why I can use DavX5 on Android and Gnome on Linux and Apple's default accounts/apps too.
bewCloud has and will have a simple UI for each of those just because I think there's value to having an easy web access that's not sync-dependent.
I hope that makes sense!
Why not have both? A single server/service AND easy-to-install modules providing atomic functionality? Just make the install/uninstall process easy (like just downloading and optionally unpacking a modules archive into installed_modules Dir)?
Second this.
Setting up syncthing was incredibly easy and it is a beast. Has no problems syncing all my huge video media files
All it did is beg the question for me: why has nobody created a file sync UI where you can essentially use syncthing like you might Google Drive but with a slick effortless interface that non-technical folks wouldn't mind using?
On the contrary, I didn't find Syncthing setup very easy, as I don't want to be dependent on external resources when doing a sync over LAN and thus I had to setup a coordinator myself and it's a bit confusing with all these long tokens that I needed for some reason.
Dead Comment
I always put
set -euxo pipefail
at the top of my bash scripts. It makes some conditional testing more difficult but it has paid for itself many times over just because of pipefail
That reasoning seems more like one from policy/cargo cult rather than reasoning specific to your org. For something short lived and meant to be isolated I wouldn't want to subject them to even more infrastructural dependencies outside their control.
Better resources utilization definitely sounds like cargo cult, riiight.
Why'd you run them in kubernetes? Seems like extreme overkill for launching a short lived container for an integration test. What could kubernetes possibly add to that?
Because we are a big company and would like to utilize resources better.
We also want homogeneity in tech when possible (we already heavily use kubernetes, we don't want to keep docker hosts anymore).
Teams of testers need to be accounted in terms of resource quotas and RBAC.
What exactly do you see as an overkill in wanting to run short-lived containers in kubernetes rather than in docker (if we already have kubernetes and "cook" it ourselves)?
Testcontainers aren't even compatible with kubernetes, that's a tool from the past.
Another one? Why?