ArangoDB on Mesosphere Using Marathon and Docker
1–10 of 19 posts
Re: ArangoDB on Mesosphere Using Marathon and Docker
#2Clear evidence that I am getting old and being left behind: of the four technologies named in that title I only have heard of one and have never actually used it.
Re: ArangoDB on Mesosphere Using Marathon and Docker
#3Clear evidence that I am getting old and being left behind: of the four technologies named in that title I only have heard of one and have never actually used it.
Maybe, but this article hits the super deluxe jackpot for most buzzwords in a headline.
Re: ArangoDB on Mesosphere Using Marathon and Docker
#4Clear evidence that I am getting old and being left behind: of the four technologies named in that title I only have heard of one and have never actually used it.
Maybe, but this article hits the super deluxe jackpot for most buzzwords in a headline.
Considering that it is a hyperspecific instruction manual and not a blog article, that's probably a good thing. It mentions all the topics.
Re: ArangoDB on Mesosphere Using Marathon and Docker
#5This is rather cool, but data in ArangoDB will not survive docker container restart, so, sadly, this setup is still just a toy.
Re: ArangoDB on Mesosphere Using Marathon and Docker
#6This is rather cool, but data in ArangoDB will not survive docker container restart, so, sadly, this setup is still just a toy.
It's possible to use volumes functionality to keep db data persistent.
Re: ArangoDB on Mesosphere Using Marathon and Docker
#7Clear evidence that I am getting old and being left behind: of the four technologies named in that title I only have heard of one and have never actually used it.
You're still better than I am. I've heard of the latter three, I've never used a single one, and I still find it very difficult to understand what the core of the second one (Mesos) actually is because it's so shrouded in buzzwords and vague descriptions.
All I got was that it's some sort of userspace microkernel geared around abstracting the computing resources of machines (nodes) in categories like CPU/RAM/disk and expose them programmatically through a cluster-wide API. The master daemon makes resource offers to a slave daemon, which in turn runs ported applications (be it Hadoop, Jenkins, ElasticSearch or whatever) called Mesos frameworks that have to be ported to this Scheduler/Executor paradigm (sort of like a cluster resource-level MapReduce, I presume?) in order to perform Tasks.
Mesosphere is the whole stack as an integrated OS. Marathon is pretty easy to understand - it's an init system/framework supervisor that operates on a higher level of abstraction than simple OS processes.
But yeah, it's a pretty tangled mess.
Re: ArangoDB on Mesosphere Using Marathon and Docker
#8Re: ArangoDB on Mesosphere Using Marathon and Docker
#9This is rather cool, but data in ArangoDB will not survive docker container restart, so, sadly, this setup is still just a toy.
It's possible to use volumes functionality to keep db data persistent.
But, it wont be persisted across restarts in Mesos-land, because Mesos doesn't have the idea of data volumes. The way that Google (Omega) gets around this is having GFS deal with replication, and persisting all of their databases into the shared file system.
Re: ArangoDB on Mesosphere Using Marathon and Docker
#10This is rather cool, but data in ArangoDB will not survive docker container restart, so, sadly, this setup is still just a toy.
It's possible to use volumes functionality to keep db data persistent.
In order to use docker volume you have to stick your ArangoDB docker instance to exact same mesos worker. Otherwise database instance may be started by marathon on any random chosen worker, without saved volume. IMHO, sticking database instance to exact cluster node renders whole idea of using mesos and marathon completely useless.