Decentralizing Docker: How to Use Serf with Docker(blog.ctl-c.io)
blog.ctl-c.io
Decentralizing Docker: How to Use Serf with Docker
http://blog.ctl-c.io/?p=43
4 comments
Nginx will use all of the cores if you configure it so I dont see creating a bunch of containers in the same machine as a great way to scale WordPress. I don't see why you don't just include mysql in the container/image. As far as I can tell people don't want to do that because it just makes things too simple. Anything that is easy can't possibly be a "Best Practice".
I think you're jumping to conclusions about nginx.
The author clearly means to have one nginx container in front of a bunch of wordpress containers, which can be hosted on a number of different machines, if needed.
The problem he's trying to solve is how to hook all the bricks together, e.g. how to let the nginx component know that there is a new backend (wordpress component) running and where.
This problem is orthogonal to the way you deploy the component, whether as classical applications running on a bare machine, a VM, or a lightweight container.
The advantage of using docker is that the exact same configuration can be used in a wide range of set-ups ... well assuming you can run docker :-p
The author clearly means to have one nginx container in front of a bunch of wordpress containers, which can be hosted on a number of different machines, if needed.
The problem he's trying to solve is how to hook all the bricks together, e.g. how to let the nginx component know that there is a new backend (wordpress component) running and where.
This problem is orthogonal to the way you deploy the component, whether as classical applications running on a bare machine, a VM, or a lightweight container.
The advantage of using docker is that the exact same configuration can be used in a wide range of set-ups ... well assuming you can run docker :-p
OK I didn't see a way for his system to work across machines. Nice username by the way.
i was trying out serf, but one issue that killed it for orchestration is behavior around network partitions or transient net issues, namely messages get dropped on the floor. which would need a layer on top to query out distributed eventually consistent state for a node rejoin to replay orchestration. using etcd (or even zk) is considerably simpler to reason about failure recovery for transient issues.
OT: @cesar your account is [dead] and looks like it has been for some time.