Docker / Kubernetes for HA applications

[Derek den Haas]

This might be way off the concept of RavenDB, though I might be wrong, but I'm exploring the possibility to run our app to be released inside docker, using kubernetes (which might run on GCE, AWS (EC2) or on a bunch of VPS providers). Exploring this I saw great ways to (auto)replicate things like MySQL, Redis etc and scale using kubernetes.

Now the first step to me is getting dotnet running using an alpine based image (currently running inside a 200mb ubuntu docker image), which the dotnet core team is exploring and trying to get it to work:
https://github.com/dotnet/dotnet-docker/issues/22

Second thing is to get RavenDB running on Alpine, since it does have some extra dependencies (might be wrong, may also be due to dotnet, but saw some errors on some distro's (Debian I thought)).

Third thing might be configuring RavenDB 3.5 it's new feature clustering, or replication between two or more replicas (instances) or creating a master and slave setup (like Redis(master/slave) or MySQL/Galera)

Though some things to overcome might be the way RavenDB creates it's source "etag" (don't know if this is generated and stored inside the system db, or is generated by hardware, mac address or whatever), RavenDB licensing might also be a thing (since it could be activated on another host without any warning).

Having said this, is the RavenDB exploring this at all, or should I just leave it running on a stand alone machine (or fast SSD VPS, not running inside Azure (thought I saw some comments about a low IO), running Windows Server 201x / Linux or should I stop here, and never look at docker/kubernetes again because you already investigated it and found it not suitable to run a database on.

[Oren Eini (Ayende Rahien)]

If .NET core runs, we should also run.

Might need to compile to that target, thought. 

About clustering, see: http://issues.hibernatingrhinos.com/issue/RavenDB-6054

I'm not following the etag question ?

Licensing is a consideration that we still haven't fully worked out through, but that is certainly something that we want to get.

We're going to have official docker images for sure: http://issues.hibernatingrhinos.com/issue/RavenDB-5644

It is just that we haven't gotten around to handling it all.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Derek den Haas]

Let me put it this way:

- Kubernetes doesn't use static IP addresses (nor static DNS names, hostnames are: <application_name>-<randomness>

-- Since replication currently uses hostnames or IP addresses, you must be able to change it dynamically

- Docker will run in changing environments

-- Don't know how this plays with RavenDB 4, with licensing (might use a machineid)

-- Don't know how this plays with replication, since it's using a SourceId inside it's document. If this is stored in the <system> db there should be no problem, else you will get "Replication disabled due to SourceId mismatch" (or something), which I've seen a few times moving data around to other servers

Op dinsdag 17 januari 2017 09:15:22 UTC+1 schreef Oren Eini:

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.

[Oren Eini (Ayende Rahien)]

Let us start from the basic question, given such a cluster, how would you find what machine the other side is on?

What sort of stable name does it has?

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.

[Derek den Haas]

Found some nice resources, since your question almost matches:

Using a service registry like etcd, you will be able to query it and know where your dockers live:

Source: https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/

The implementation of mongoDB is (as far as I can read) a bit worse

https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes

looks like they still enforce static IP addresses to find one another, using a service type "LoadBalancer" to enforce outside static IP addresses instead of discovering services.

P.s. I was wrong about the DNS name, (the instance name is like I described: <name of service>-<random string>) internally you can also use DNS or Environment Variables:

https://kubernetes.io/docs/user-guide/services/#discovering-services

Op dinsdag 17 januari 2017 19:47:31 UTC+1 schreef Oren Eini:

[Oren Eini (Ayende Rahien)]

From there, the best option seems to be:

Kubernetes DNS service to provide a hostname

And that should just do it? Or am I missing something?

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.