I think it just didn't fit my mental model of an application environment. I was used to virtual machines. Having to link containers together never really clicked. With LXD I get to treat it like a virtual machine. Install what I want, update it, etc but have next to no overhead. I have something like 15 "servers" running on a NUC in my hame rack. Git server, irc client, Unifi Controller, Samba Server, postgres, Minetest, etc.. it doesn't break a sweat.
I know docker gives many of the same benefits and more besides for flexible deployment. But I guess I just want to ssh in and pretend it is just a Linux machine.
My goal is to build a website that runs on my machine locally and know that when it comes time to deploy it on digital ocean, AWS, vercel, or wherever, I won’t have to spend hours debugging and potentially regretting some of the decisions I made earlier in the process. Docker ought to be the right tool for that purpose, if I understand correctly: docker being a container for applications (like a website), LXD being a container for systems.
Nostrudel uses docker — some other nostr clients do too, I think.
My goal right now is to learn how to build from scratch a Hello Nostr client with a responsive admin/dashboard-like template. Right now, doing that locally is easy for me; getting it to deploy is my present hurdle.
Once I figure that out, I’ll be able to rebuild my old Concept Graph app called Plex, which is a desktop app built on top of IPFS. Plan is to rebuild on the web using nostr.
Docker is definitely the right solution. I just struggled with it.
Big fan of bare metal deployment AND container deployment. Bare metal does require quite a bit more documentation, but having the freedom to do whatever tf I want with an app is a yuge plus. I will happily put effort into "bare metal" docs to support my users' freedom!
Yup —I’ve played around with docker a little bit and so far I’m undecided which route I’d prefer.
If it helps:
I build full stack, mostly polyglot applications (usually C and C#) frameworks w/web-apps and I just take my Linux bundles and package them inside a container as part of a CI. The requires user's users to build containers locally, but it does ensure that builds are consistent with bare-metal and containerized, plus it makes CI easy. I then give users a Taskfile.dev script for cross-platform bootstrapping. It's not a complete solution, but I think it's a good middle ground.
That being said, it now cost's me very little, aside from testing time, to target both containers and bare-metal.
CI = continuous integration? I’m learning new words 😅
Lol, yessir! There are so many different things. Again personally, I built my own tools for CI because there are so many big tools that can get you stuck in their way of building things IMO, or stuck working inside docker containers making your repo all messy. I opted for using https://taskfile.dev and my custom orchestration tool.
Oddbean new post about login | logout