Hacker News new | comments | ask | show | jobs | submit login

I don't quite understand the swarm & compose workflow for production. I'd rather use a declarative language to specify what the systems look like, potentially with auto-scaling, health checks to replace containers if they go down, etc. I don't want to run one-off commands to launch containers based on local instead of centrally stored configuration, run one-off commands to launch the underlying hosts and to scale to more instances (which then isn't persisted anywhere), etc.

I feel like I'm just not understanding the "docker approved" approach. Which is surprising because docker itself is so great.

The networking stuff seems interesting though, I'm very curious how the rest of the ecosystem will evolve to take advantage of it or not.




This is very much Kubernetes's opinion, based on the production experience the engineers who built it.

Brian Grant has explained it recently here: https://github.com/kubernetes/kubernetes/blob/master/docs/wh...

"The technical definition of "orchestration" is execution of a defined workflow: do A, then B, then C. In contrast, Kubernetes is comprised of a set of control processes that continuously drive current state towards the provided desired state. It shouldn't matter how you get from A to C: make it so. This results in a system that is easier to use and more powerful, robust, and resilient."

Look into PaaSes that are built on top of K8s, like Red Hat's OpenShift v3 or Deis.


Swarm & compose are pretty low level and not sufficient for production deployments in my experience. In production, you usually need things like logging/monitoring, versioning/rollbacks, scaling, configuration/user management, load balancing, etc. which you either have to setup yourself or get through a PaaS. I personally recommend Deis because it's Docker/CoreOS based (lightweight) and its developers are very active and responsive. I have to admit though I haven't evaluated all alternatives. https://github.com/deis/deis


If you don't mind using AWS, check out Empire. Open source, 12-factor compatible PaaS built on top of amazons robust ECS container scheduler. Rollbacks/versioning/load balancing/scaling included.

https://github.com/remind101/empire


You're absolutely right about still needing logging, scaling, configuration management and load balancing.

Me and a team are working on another open-source project, Convox, that offers this on AWS.

One differentiator is that we use "pure" AWS for everything.

Load balancing comes from configuring ECS and an ELB the right way. Logging is based on Kinesis and Lambda. We're seeing great reliability and manageability with this approach.

http://convox.com/


+1 for deis its pretty nice and is actually "production ready"


Compose isn't great for deploying services but it really shines for command line utilities. At Pachyderm our entire build and test system is based on compose. It's nice because it means that all we need for dev is a working docker daemon and our tests can run in very production like conditions.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: