[–] 3 points 1 month ago (1 child)

You say you run your containers rootless with systemd quadlets. Are you publishing the containerized apps' ports to the host and reverse proxying your applications like that or have you somehow managed to attach your (presumably also containerized rootless reverse proxy) and your containers to the same network?

The latter is what I'm struggling with, so currently all my applications are in their own network that the reverse proxy is also connected to. But from what I've gathered, that means the proxy and each application need to share a network namespace which apparently isn't possible in rootless mode unless all applications share the same network namespace.

  • source
  • parent
  • context
  • [–] 20 points 3 months ago (4 children)

    I think there are (at least) two things wrong with the argument:

    1. it assumes that there can be no source of absolute morality aside from religion, ignoring centuries if not millennia of moral philosophy/ethics (which at least tries to answer the question seriously).
    2. even if nonreligious sources of morality don't exist, the argument assumes that religion is a source of absolute morality. since conflicting religions exist, the religionness-property alone is not enough to validate religion as a source of absolute morality.
  • source
  • parent
  • context
  • [–] 2 points 6 months ago

    All my services run in podman containers managed by systemd (using quadlets). They usually point to the :latest tag and I've configured the units to pull on start when there is a new version in my repository. Since I'm using opensuse microos, my server (and thus all services) restart regularly.

    For the units that are configured differently, I update the versions in their respective ansible playbooks and redeploy (though I guess I could optimize this a bit, I've only scratched the surface of ansible).

  • source
  • [–] 6 points 1 year ago

    I've finally pinned down my backup automaton:

    • All my services are in podman containers/pods managed by systemd.
    • All services are PartOf= a custom containers.target.
    • All data is stored on btrfs sub volumes
    • I created a systemd service that Conflicts=containers.target for creating read only snapshots of the relevant subvolumes.
    • That service Wants=borgmatic.service wich creates a borg backup of the snapshots on a removable drive. It also starts containers.target on success or failure since the containers are not required to be stopped anymore.
    • After borg backup is done, the repository gets rclone synced to an S3 compatible storage.
    • This happens daily, though I might put the sync to S3 on a different schedule, depending how much bandwidth subsequent syncs will consume.

    What I'm not super happy about is the starting of containers.target via the systemd unit's OnSuccess= mechanism but I couldn't find an elegant way of stopping the target while the snapshots were being created and then restarting the target through the other dependency mechanisms.

    I also realize it's a bit fragile, since subsequent backup steps are started even if previous steps fail. But in the worst case that should just lead to either no data being written (if the mount is missing) or backing up the same data twice (not a problem due to deduplication).

  • source
  • [–] 3 points 1 year ago (1 child)

    What I'm reading is that you want site-to-site connectivity. Wireguard + possibly dynamic DNS makes this pretty easy (assuming you can open ports and configure NAT at your sites). Or you could set up some other VPN solution like OpenVPN.

    There's also tailscale (a paid service) for facilitating the wireguard setup, NAT traversal and relaying. headscale is a self hosted solution that aims to provide something similar (but more limited in scope).

  • source
  • parent
  • context
  • view more: next ›