3 ms·

Deis looks amazing! In my current project, I'm running stateful/backing services like Redis, PostgreSQL outside containers. Is that the way to go with Deis as w

Deis looks amazing! In my current project, I'm running stateful/backing services like Redis, PostgreSQL outside containers. Is that the way to go with Deis as well?

snuxoll 11y ago
Anything involving state doesn't belong in a container. Personally, I don't think containers are worth investing the mental overhead until the security story is resolved - but if you insist on using them don't use them to store your data.
- lobster_johnson 11y ago
  There's absolutely nothing special about containers and state. A container is just a namespaced process tree. What resources (CPU, memory, network, disk) is has access to is up to you; there's nothing in the Docker design that means state needs to die just because the process dies. All the major container technologies (Kubernetes, Marathon, Amazon's ECS etc.) support data persistence via mounted volumes. Docker's security concerns are mostly about multitenant systems where you're hosting other people's containers. If all your own apps are your own, then Docker is certainly a step up, securitywise, from running an app as a process running as its own Unix user. You just shouldn't assume that a container is perfectly isolated.
  - snuxoll 11y ago
    I'm not talking about isolation WRT to containers and security, keeping them up-to-date is the bigger issue. Docker doesn't have a good solution to this that doesn't involve constantly rebuilding your base containers and any child containers that depend on it.
    - lobster_johnson 11y ago
      That's not a "security story" I've heard before. Surely containers make this much _easier_ than traditional VMs, because containers are designed (or should be designed) to completely expendable. To do an "OS upgrade", just rebuild and redeploy. If you're using a system that has rolling, verified, graceful restarts built in (e.g., Marathon, and I believe Kubernetes does, too), you'll easily avoid any downtime, which is harder to accomplish with classical VMs. With a classical system (VM or otherwise) you'll still have to restart your apps whenever some library (glibc, ImageMagick or whatever) is patched. Docker doesn't change that. It does potentially minimize the surface area.
      - snuxoll 11y ago
        Major problem is there is a substantial lack of tooling to handle this. Meanwhile, managing updates for all of my servers is pretty painless with the plethora of system management tools out there - puppet keeps all my packages updated from my local yum repositories and restarts services as needed (aside from critical ones like postgresql that require manual intervention).
        Gigablah 11y ago
        One possible way to go about this is to use your configuration management tool to update your images. Ansible 2.0 offers a Docker connector which you can use to run a playbook on a container the same way you'd run it on a host. The playbook tasks would look like: * Start a new container from the image you want to update * Using the Docker connector, run your various roles * Commit the container to a new image Then you'd push to your registry and redeploy your containers from the updated image. I suppose there should be something similar for Puppet...

Deis looks amazing! In my current project, I'm running stateful/backing services like Redis, PostgreSQL outside containers. Is that the way to go with Deis as well?

snuxoll 11y ago

Anything involving state doesn't belong in a container. Personally, I don't think containers are worth investing the mental overhead until the security story is resolved - but if you insist on using them don't use them to store your data.

lobster_johnson 11y ago
There's absolutely nothing special about containers and state. A container is just a namespaced process tree. What resources (CPU, memory, network, disk) is has access to is up to you; there's nothing in the Docker design that means state needs to die just because the process dies. All the major container technologies (Kubernetes, Marathon, Amazon's ECS etc.) support data persistence via mounted volumes. Docker's security concerns are mostly about multitenant systems where you're hosting other people's containers. If all your own apps are your own, then Docker is certainly a step up, securitywise, from running an app as a process running as its own Unix user. You just shouldn't assume that a container is perfectly isolated.
- snuxoll 11y ago
  I'm not talking about isolation WRT to containers and security, keeping them up-to-date is the bigger issue. Docker doesn't have a good solution to this that doesn't involve constantly rebuilding your base containers and any child containers that depend on it.
  - lobster_johnson 11y ago
    That's not a "security story" I've heard before. Surely containers make this much _easier_ than traditional VMs, because containers are designed (or should be designed) to completely expendable. To do an "OS upgrade", just rebuild and redeploy. If you're using a system that has rolling, verified, graceful restarts built in (e.g., Marathon, and I believe Kubernetes does, too), you'll easily avoid any downtime, which is harder to accomplish with classical VMs. With a classical system (VM or otherwise) you'll still have to restart your apps whenever some library (glibc, ImageMagick or whatever) is patched. Docker doesn't change that. It does potentially minimize the surface area.
    - snuxoll 11y ago
      Major problem is there is a substantial lack of tooling to handle this. Meanwhile, managing updates for all of my servers is pretty painless with the plethora of system management tools out there - puppet keeps all my packages updated from my local yum repositories and restarts services as needed (aside from critical ones like postgresql that require manual intervention).
      - Gigablah 11y ago
        One possible way to go about this is to use your configuration management tool to update your images. Ansible 2.0 offers a Docker connector which you can use to run a playbook on a container the same way you'd run it on a host. The playbook tasks would look like: * Start a new container from the image you want to update * Using the Docker connector, run your various roles * Commit the container to a new image Then you'd push to your registry and redeploy your containers from the updated image. I suppose there should be something similar for Puppet...