Rancher vs Zookeeper: What are the differences?
Developers describe Rancher as "Open Source Platform for Running a Private Container Service". Rancher is an open source container management platform that includes full distributions of Kubernetes, Apache Mesos and Docker Swarm, and makes it simple to operate container clusters on any cloud or infrastructure platform. On the other hand, Zookeeper is detailed as "Because coordinating distributed systems is a Zoo". A centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications.
Rancher and Zookeeper are primarily classified as "Container" and "Open Source Service Discovery" tools respectively.
"Easy to use" is the top reason why over 89 developers like Rancher, while over 9 developers mention "High performance ,easy to generate node specific config" as the leading cause for choosing Zookeeper.
Rancher is an open source tool with 11.8K GitHub stars and 1.31K GitHub forks. Here's a link to Rancher's open source repository on GitHub.
Uber Technologies, Pinterest, and Coursera are some of the popular companies that use Zookeeper, whereas Rancher is used by Packet, Redox Engine, and VCCloud. Zookeeper has a broader approval, being mentioned in 116 company stacks & 48 developers stacks; compared to Rancher, which is listed in 88 company stacks and 35 developer stacks.
What is Rancher?
What is Zookeeper?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Zookeeper?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
- Consume too much unnecessary resource by just running rancher agent alone;
- Hard to recover from system failure
- Bad performance of load balancing (compare to dokcer swarm built-in LB or others).
Initially, Stitch only supported real-time updates and addressed this problem with a MapReduce job named The Restorator that performed the following actions:
- Calculated the expected totals
- Queried Cassandra to get the values it had for each counter
- Calculated the increments needed to apply to fix the counters
- Applied the increments
Meanwhile, to stop the sand shifting under its feet, The Restorator needed to coordinate a locking system between itself and the real-time processors, so that the processors did not try to simultaneously apply increments to the same counter, resulting in a race-condition. It used ZooKeeper for this.
Like many large scale web sites, Pinterest’s infrastructure consists of servers that communicate with backend services composed of a number of individual servers for managing load and fault tolerance. Ideally, we’d like the configuration to reflect only the active hosts, so clients don’t need to deal with bad hosts as often. ZooKeeper provides a well known pattern to solve this problem.
The whole infrastructure is managed through Rancher. It provides a simple interface to all the underlying tools - Docker, HAProxy (automatically configures load balancer from the containers).
Zookeeper manages our state, and tells each node what version of code it should be running.
Currently looking to move to Swarm or Kubernetes due to a few issues I have with Rancher.
We use Rancher for container orchestration and automated deployment pipelines.
Used Zookeeper as the resource management system for Mesos/Marathon services.