-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal] Deploying truly distributed Druid clusters with docker #21
Comments
👍 I am totally on board with this. |
@xiaoyao1991 Any updates on this? Looks awesome! |
@saidimu I have one more thing to confirm before I organize something up. In our experiment settings, we were using a simple NFS as deep storage instead of HDFS. I'm confirming if the nodes in the swarm overlay network can properly talk to HDFS. |
@xiaoyao1991 it's great, any update? |
@martin-liu Thanks. I've opened a preliminary PR(#23). I haven't yet had the time to address the comments there that relates to documentation. |
I have a setup made for docker-compose and for kubernetes if you would be interested to maintain those. |
@sjtoik Is it possible to share a link to your setup? |
@sjtoik +1 for Kubernetes setup |
1 similar comment
@sjtoik +1 for Kubernetes setup |
@stingerpk I'm still testing different aspects of the deployment and features. If it is not too much of an hassle to upkeep our environment specific one and public counterpart, I'll publish it. |
Hey guys,
I see that the image created from this repo is running every node together in one single container. While it's helpful for users to test and try out Druid, it isn't particularly useful when it comes to deploying a production cluster.
I've been working on using docker to deploy a truly distributed Druid cluster lately. I have had something working and I'd like to share it and contribute back. I'm wondering if it will be valuable though. Take a look at this fork to see what I've done so far. While the settings in that fork are set specifically for my team's research purpose, they can be generalized and made extendable. I'm still in an exploration stage on docker deployments, so I may have made stupid mistakes.
Due to its lightweight, Docker philosophy encourages running only one service in a container and having containers talk to each other, rather than running all dependencies and services in one container. Therefore, I defined separate images for each type of Druid node(
druid-broker
,druid-coordinator
, etc.) as well as dependencies(druid-zookeeper
,druid-mysql
,druid-kafka
, etc.) I also packed the jvm and runtime configurations into a separate image(druid-conf
).I had a discussion earlier with @cheddar on deployment stuff. He made it clear that deployment in general should only have 3 steps:
I followed this guideline: when running a specific druid node, say broker, all you need to do is:
druid-broker
imagedruid-conf
imagedruid-conf
in a container, and then link it as a volume provider(using--volumes-from
) for thedruid-broker
container.Containers on different nodes can freely communicate with each others as long as they are within a same overlay network. I leverages
docker-machine
to manage/provision remote nodes, and dockerswarm
for container orchestration. Running a broker node for example is just as simple as:docker run -itd --volumes-from=node-1-conf --name=broker --network=p-my-net --env="constraint:node==p-node-5" druid-broker:latest
The text was updated successfully, but these errors were encountered: