4 ms·

If you're locked into containers as the solution, the answer to your problem is docker-compose. But verify that assumption first. Why containers and not VMs? VM

by sh34r 3y ago

If you're locked into containers as the solution, the answer to your problem is docker-compose. But verify that assumption first. Why containers and not VMs? VMs solved this particular problem years before anyone had ever heard of Docker. You don't need containers if you're just splitting up a single-server monolith. I don't know if I'd call them "friendly," but basically every VMM has a GUI. Docker's the easiest way to solve the runs-on-my-machine problem, but Vagrant isn't much harder. k8s is a non-starter for this use case. So incredibly overcomplicated, and what did you think you were getting for that complexity? It's for large-scale deployments. You have one server. Resume driven development is getting out of control... If you don't have a dedicated devops team, or you're not using a managed k8s service like AKS, just don't. Please don't. Stop spreading the madness to these beautifully simple environments. KISS: keep it simple, stupid. Running k8s because Docker CLI is too hard, is like learning to fly a F-16 because riding a bike is too hard.

sseagull 3y ago
Docker compose is what we are going with (for now), but with one complication: how can I allow co-workers access without giving them root access to the server? I generally trust them (we're a tight knit group), but mistakes happen. Now I could (and did) add them to the 'docker' group so they can run docker(-compose), but the issue ends up being permissions on any bind mounts. They end up not being able to read logs, view some config, etc. It's not necessarily a single-server monolith, but a server that is meant to handle a multitude of (possibly unrelated) web-apps at once. I might have to think about VMs more. I really do like docker, and traefik is a god-send (making routing and certificates a heck of a lot easier).
- sh34r 3y ago
  Security is generally considerably more challenging with containers than VMs. https://docs.docker.com/engine/security/#docker-daemon-attack-surface https://docs.docker.com/engine/security/#docker-daemon-attac... "Running containers (and applications) with Docker implies running the Docker daemon. This daemon requires root privileges unless you opt-in to Rootless mode..." If they can log into the server and run docker containers themselves, you've probably inadvertently granted permissions that could be escalated to gain root access, if they were a sufficiently skilled adversary (or their user account is compromised by one). You typically avoid this particular problem by having a CI/CD pipeline build, deploy, and run the containers. No one has permission to do this except the pipeline. Grant devs ssh access to the containers, using appropriate network rules to limit access to trusted IPs, and ideally behind a jump box in a VPC. VMs give you a lot of OS-level protections for free. For one thing, getting root access to a VM shouldn't compromise the host or other VMs (in the absence of a 0-day, anyway). Unfortunately, it sounds like you're pretty far down the Docker rabbit hole already. It's probably much more trouble to switch now than it's worth.

by sh34r 3y ago

sseagull 3y ago

Docker compose is what we are going with (for now), but with one complication: how can I allow co-workers access without giving them root access to the server? I generally trust them (we're a tight knit group), but mistakes happen. Now I could (and did) add them to the 'docker' group so they can run docker(-compose), but the issue ends up being permissions on any bind mounts. They end up not being able to read logs, view some config, etc. It's not necessarily a single-server monolith, but a server that is meant to handle a multitude of (possibly unrelated) web-apps at once. I might have to think about VMs more. I really do like docker, and traefik is a god-send (making routing and certificates a heck of a lot easier).

sh34r 3y ago
Security is generally considerably more challenging with containers than VMs. https://docs.docker.com/engine/security/#docker-daemon-attack-surface https://docs.docker.com/engine/security/#docker-daemon-attac... "Running containers (and applications) with Docker implies running the Docker daemon. This daemon requires root privileges unless you opt-in to Rootless mode..." If they can log into the server and run docker containers themselves, you've probably inadvertently granted permissions that could be escalated to gain root access, if they were a sufficiently skilled adversary (or their user account is compromised by one). You typically avoid this particular problem by having a CI/CD pipeline build, deploy, and run the containers. No one has permission to do this except the pipeline. Grant devs ssh access to the containers, using appropriate network rules to limit access to trusted IPs, and ideally behind a jump box in a VPC. VMs give you a lot of OS-level protections for free. For one thing, getting root access to a VM shouldn't compromise the host or other VMs (in the absence of a 0-day, anyway). Unfortunately, it sounds like you're pretty far down the Docker rabbit hole already. It's probably much more trouble to switch now than it's worth.