cross-posted from: https://programming.dev/post/1429257
It has an ‘App store’ that’s been growing a lot lately. Writing new docker-compose.yaml files is easy (see: https://www.runtipi.io/docs/contributing/adding-a-new-app ), and exposing them behind NAT, e.g. from home it’s easy too (see: https://www.runtipi.io/docs/guides/expose-apps-with-cloudflare-tunnels )… But my favorite perk is the folder structure (see: https://www.runtipi.io/docs/reference/folder-structure ), and the fact that ‘media’ is shared between apps.
Fair enough, I have learned to live with curl first, then execute. Or going through the trustworthiness of the repository author (e.g. number of stars, contributors, etc.) More or less the same safeguard I take for packages I install from Arch User Repositories. I’m curious, tho, How do you feel about “docker pull”? Containerization has limits…
I am truly no fan of containerization. I only will containerize an app once I understand what it is doing fully. Otherwise, I think containerization is merely an abstraction layer for someone who wants to get up and running quickly which is I think is not advisable. That’s my 0.02 anyways.
I’m intrigued. How do you deploy apps in your homelab, presumably with some needing access externally, and still maintain privilege separation for each of them?
I use containerization as the new chroot jail, as well as for rapid (re)deployment capability. I can easily spin up or tear down services I might want to test or play with, and having separate containers for everything means I can create very specific rules and routes for each service as required.
In fact, a lot (not all) of my services are docker stacks running in their own LXCs on Proxmox. Containerception.