traches

joined 2 years ago
[–] traches 1 points 2 days ago

I definitely see your point, but the difference is that it’s one thing to learn. Once you know docker, you can deploy and manage anything.

[–] traches 10 points 3 days ago (2 children)

Cons of containers are slightly worse disk and memory consumption.

Pros:

  • ease of installation
  • declarative configuration
  • security
  • dependency management is solved

Stick with the containers

[–] traches 4 points 3 days ago (1 children)

Oh nice! I’m stoked about the background sidecar operations, that will speed things up considerably

[–] traches 3 points 3 days ago

Sqlite compiles to wasm, you can run it in the browser

[–] traches 5 points 4 days ago

Thanks! I’m perfectly capable of both. They say cringing at your former self is a sign of growth

[–] traches 34 points 4 days ago (5 children)

Honest answer? When trump said “Take the guns away first, due process later.” I was a pretty big gun nut at the time and it felt like a slap in the face. Shortly afterwards I encountered a YouTube video that actually explained the science behind climate change in a way that made it obviously true and that I hadn’t encountered before. The conservative worldview is a house of cards, once you take out a couple the whole thing falls apart pretty quickly.

Now I’m a very progressive atheist and more than a little ashamed of my former self. Still like guns, but I keep that to myself

[–] traches 15 points 5 days ago

Yeah, I wish he’d go back to being the greenhouse on mars guy

[–] traches 66 points 5 days ago (8 children)

i used to be a republican so

[–] traches 1 points 6 days ago (1 children)

but there is a reason i just explained it to you

[–] traches 1 points 1 week ago (3 children)

Ok but is there room for the idea that your intuitions are incorrect? Plenty of things in the world are counter-intuitive. ‘docker-compose up -d’ works the same whether it’s one container or fifty.

Computer resources are measured in bits and clock cycles, not the number of containers and volumes. It’s entirely possible (even likely) that an all-in-one container will be more resource-heavy than the same services split across multiple containers. Logging from an all-in-one will be a jumbled mess, troubleshooting issues or making changes will be annoying, it’s worse in every way except the length of output from ‘docker ps’

[–] traches 1 points 1 week ago (5 children)

I can see why editing config files is annoying, but why exactly are two services and volumes in a docker-compose file any more difficult to manage than one?

[–] traches 8 points 1 week ago

I disagree with pretty much all of this, you are trading maintainability and security for easy setup. Providing a docker-compose file accomplishes the same thing without the sacrifice

  • separate volumes for configuration, data, and cache because I might want to put them in different places and use different backup strategies. Config and db on SSD, large data on spinning rust, for example.
  • separate container for the database because the official database images are guaranteed to be better maintained than whatever every random project includes in their image
  • separate networks because putting your reverse proxy on a different network from your database is just prudent
 

I have a load-bearing raspberry pi on my network - it runs a DNS server, zigbee2mqtt, unifi controller, and a restic rest server. This raspberry pi, as is tradition, boots from a microSD card. As we all know, microSD cards suck a little bit and die pretty often; I've personally had this happen not all that long ago.

I'd like to keep a reasonably up-to-date hot spare ready, so when it does give up the ghost I can just swap them out and move on with my life. I can think of a few ways to accomplish this, but I'm not really sure what's the best:

  • The simplest is probably cron + dd, but I'm worried about filesystem corruption from imaging a running system and could this also wear out the spare card?
  • recreate partition structure, create an fstab with new UUIDs, rsync everything else. Backups are incremental and we won't get filesystem corruption, but we still aren't taking a point-in-time backup which means data files could be inconsistent with each other. (honestly unlikely with the services I'm running.)
  • Migrate to BTRFS or ZFS, send/receive snapshots. This would be annoying to set up because I'd need to switch the rpi's filesystem, but once done I think this might be the best option? We get incremental updates, point-in-time backups, and even rollback on the original card if I want it.

I'm thinking out loud a little bit here, but do y'all have any thoughts? I think I'm leaning towards ZFS or BTRFS.

 

Not sure about the artist, sorry

 
view more: next ›