Add another abstract layer between Clouder and Docker

[YannickB]

Hello everyone,

Like some of you suggested, we today have many great tools to manage Docker instances. The goal of Clouder is not to replace them, it's to be the place where the informations about application/containers/base are stored.

Since I want to keep the minimum command in Clouder, I believe we have a missing software on the process between Clouder and Docker, I mean Clouder shall give order to this software and this software will then manage the containers. As we do for the registry, this software shall also be in a container created by Clouder.

Some of you suggested docker-compose, other rancher, any other suggestions ? We will probably have to make a choice, we need to make the good one.

[YannickB]

Hello everyone,

I want to share with you some updates regarding this issue. First here is how I see hosting currently :

IaaS : Providing OS/VM/Container environment, provider take care of physical server and network PaaS : Providing infrastructure ready for production, provider take care of OS configuration, security and load balancing, ensuring scalability. Customer still maintain application code. SaaS : Providing access to application, customers directly access the application through his browser.

For example : OpenStack is a tool for managing an IaaS offer. Rancher, OpenShift, Heroku are PaaS And Clouder is according to me a SaaS builder, even if it can be considered a little like a PaaS platform I'd like to delegate most of this concept to an existing PaaS software. Note that I have yet to find an equivalent as SaaS builder, if there's none the potentiel of Clouder will be really tremendous.

As suggested by a partner I am working with, OpenShift looks like a great candidate and will probably become the reference for PaaS. I especially like the tight integration with Kubernetes (Kubernetes is a complete and unavoidable sublayer of OpenShift) which I think is becoming one of the most important software to manage containers in high availability hosting.

Here is my for/against integration OpenShift as a sublayer of Clouder :

For : -Another abstract layer between Clouder and the IaaS layer, this means we will become immediately fully compatible with openstack, aws etc... -Very interesting, important and complementary features in Kubernetes (ressources allocation, concept of pods which is I find very interesting for the package concept I want to implement in Clouder (ex : for odoo+magento+connector), application scalability with container cloning, virtual network) -By aligning the Clouder concepts to the ones in OpenShift/Kubernetes, we will quickly catch up with the current state of the art in hosting. This will be of great help to promote Clouder later.

Against : -Some of the functional scopes of OpenShift and Clouder are overlapping. -DNS/proxy/load balancer are hard-coded in OpenShift, while it's flexible in Clouder because in dedicated modules. But nothing force us to use theses specifics features in OpenShift. -Everything are made for redhat-based distributions, while everything I've done (and most work in docker ecosystem) is debian-based. Hope this will not cause too much incompatibilities. -In general, I fear OpenShift can be too much high-level and may lack some flexibility. I also hope we will not be locked by RedHat decisions, OpenShift seems at the heart of their strategy to regain some control in containers ecosystems. -And of course, this will represent a lot of work, but after this Clouder will probably be ready to handle any production case.

I believe the for win, here is how I think we will implement it, assuming we chose to go with OpenShift (not decided yet, waiting your feedback) : -We of course keep what's currently working, so you'll have choice, either you go with OpenShift or you continue with direct deployment of Docker. The current code related to Docker which is currently in the core clouder module will be moved in clouder_docker -The code and templates related to OpenShift will be implemented in a new clouder_openshift module.

Also, note that an alternative is to directly link Clouder with Kubernetes which will provide most of the for arguments while removing most of the against. Still some features in OpenShift may be useful and since the more can do the less, I think it's best to go with OpenShift.

This is really an important topic, I am waiting for your feedback. As you probably understood, a project is already on the way so you can expect some massive update of the code in the next weeks.

[pierreozoux]

+1 for clouder_kubernetes :)

[YannickB]

@pierreozoux Can you provide some arguments please? I find the documentation of kubernetes less clear than openshift, I feel like we should go for OpenShift but I still struggle to find a strong argument for or against.

[pierreozoux]

I don't know much about clouder. I know we already had this discussion.

My quick answer was saying, try to modularize at the maximum. And maybe clouder shouldn't take the decision, should the runner be openshift/docker/kubernetes. Maybe clouder should say run, and then you need a runner, and you can choose your runner.

I think the best bet today is kubernetes. Sincerly, my feeling on the "market" right now is everybody is trying to follow the team CoreOS/Google. So, now take your decision, follow the followers or the leaders :) That's why I'd go for kubernetes. But as a module. Meaning that if tomorrow, openshift was indeed a better choice, then people can develop a clouder_runner_openshift.

This is just a "feeling" I don't know much yet on clouder/odoo infra to tell if what I'm saying is reasonable.

But I think that personnaly/IndieHosters, we'll go on kubernetes. And I'd be happy to make our packages compatible with clouder :) (I'm using odoo to power our new site, and pretty happy so far :) thanks for your advice :) )

[YannickB]

62 j'ai fait les premiers developpement pour intégrer avec openshift

[collex100]

My opinion it should be Rancher. Hard for me substantiate own opinions. But in a few words, I try to give a description. Opensource. Written in Python. Developed as the best solution for container management, аnd each new update proves it. Sharing and managing users - I think it will not be superfluous.

[YannickB]

Thanks for your opinion collex, I shall check Rancher a little more. Anyway what I started with openshift (on next branch) is only to support the concept of a PaaS as a sublayer of Clouder, there isn't really were a lot of work specific to openshift yet so I can change my mind (or support both of them, we'll see)

[collex100]

Let me give an example from my experience with Rancher. As I has launched the Odoo, using Rancher: http://forums.rancher.com/t/help-me-please-deploy-odoo-with-rancher-ui/383/16?u=111

[YannickB]

119 The discussion will probably continue here. In the end, if we use another layer it'll probably be some kind of orchestrator to execute the command but Clouder will keep the high hand on the container deployment.

Regarding container deployment, in short, I'd like to use only Docker Inc tools (compose, swarm, etc...) at least in the code. Closing the ticket.