4 ms·

Those are too low level for most users and you'll eventually end up (poorly) re-inventing a PaaS if you need things like configuration, authorisation, scaling,

Those are too low level for most users and you'll eventually end up (poorly) re-inventing a PaaS if you need things like configuration, authorisation, scaling, routing, rollbacks, etc. I've found Deis (https://github.com/deis/deis https://github.com/deis/deis) to hit the sweet spot between flexibility and convenience. It is built on top of docker and Kubernetes (CoreOS/fleet in v1), and lets you deploy docker containers natively and/or automatically builds those for you using Heroku buildpacks or Dockerfiles when doing git push deployments. You can also drop down to the Kubernetes level if you need to for things that don't really fit the 12-factor app model without breaking Deis. That being said, I'm totally biased as I wrote an Heroku-like UI for it (http://deisdash.com/about http://deisdash.com/about) and using it for our infrastructure at work. Other similar alternatives are http://pivotal.io/platform http://pivotal.io/platform, https://flynn.io/ https://flynn.io/, https://www.openshift.com/ https://www.openshift.com/, https://github.com/dokku/dokku https://github.com/dokku/dokku (for single server), etc.

pramodliv1 11y ago
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...
nzoschke 11y ago
I'd respectfully like to submit my project, Convox, into the discussion of not reinventing a PaaS: http://convox.com/ http://convox.com/ https://github.com/convox/rack https://github.com/convox/rack Convox is another open source PaaS, but we're building it entirely on top of AWS services like CloudFormation, ECS, ASG, etc. This means it's only suitable for teams that have 100% bought into AWS. If that's you, we make all the hard parts of operating a distributed deployment system Amazon's problem. There's another project in this same space, Empire: https://github.com/remind101/empire https://github.com/remind101/empire If 100% AWS is not you, Docker Datacenter / Swarm, CoreOS, Deis, CloudFoundry, etc. are doing incredible work. It's amazing how these sophisticated tools are available to all of us.
- dekz 11y ago
  I think Empire or Convox will be the right tool for us. Flynn and Deis etc all seem to be writing their own schedulers and routing layer, where Convox and Empire just reuse AWS components. This to me is a huge plus, since those problems are already solved and rock solid. But as a developer, I just want to push a docker image some where and scale it up later.
ossreality 11y ago
I'm amazed at how inaccurate this comment is. Every single thing you listed there is supported in Kubernetes 1.2.

pramodliv1 11y ago

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...

nzoschke 11y ago

I'd respectfully like to submit my project, Convox, into the discussion of not reinventing a PaaS: http://convox.com/ http://convox.com/ https://github.com/convox/rack https://github.com/convox/rack Convox is another open source PaaS, but we're building it entirely on top of AWS services like CloudFormation, ECS, ASG, etc. This means it's only suitable for teams that have 100% bought into AWS. If that's you, we make all the hard parts of operating a distributed deployment system Amazon's problem. There's another project in this same space, Empire: https://github.com/remind101/empire https://github.com/remind101/empire If 100% AWS is not you, Docker Datacenter / Swarm, CoreOS, Deis, CloudFoundry, etc. are doing incredible work. It's amazing how these sophisticated tools are available to all of us.

dekz 11y ago
I think Empire or Convox will be the right tool for us. Flynn and Deis etc all seem to be writing their own schedulers and routing layer, where Convox and Empire just reuse AWS components. This to me is a huge plus, since those problems are already solved and rock solid. But as a developer, I just want to push a docker image some where and scale it up later.

ossreality 11y ago

I'm amazed at how inaccurate this comment is. Every single thing you listed there is supported in Kubernetes 1.2.