I understand that that would be possible, however the Docker reference implementation in the documentation doesn’t do that (plan a production install). And from my point of view that’s a good choice (seperation of concerns). However given the current licensing model for the CS Engine that’s an expensive solution for us.
I should first elaborate a bit on what were doing. Sorry for the long read, I hope your still willing to look into it. Also I have to tell you we are in contact with Docker Inc. already from the Netherlands (through Amazic).
We as a team deliver several PaaS services for a customer, based on their own VMWare ESX based private cloud. It maybe unique, but it is certainly a very succesfull private cloud implementation. These services have been a big enabler for change within the customer in that they changed to several DevOps teams that are indeed responsible for their own application in production (you build it, you run it). Within the organization we have a kind of multi-tenancy in that every DevOps team is a seperate customer and they have their own clusters of VM’s running the PaaS types to host their application (landscape). We have been delivering these services since early 2012 starting first with a Java platform bit added other types since then. You could probably say we are a kind of Managed Service Provider.
So the important point being that a customer operates his own infrastructure.
Since early 2014 we started delivering Docker as a Platform (we call this YODA - Your Own Docker Application). It’s still based on a single virtual machine, containing a recent version of the Docker Engine and Docker Compose. But now we want to make the jump to Docker Swarm (JEDI - Just Enough Docker Infrastructure). However still based on a customer being responsible for his own Swarm and guaranteeing that there is no possibility for workloads influencing each other when they are from different customers.
That’s the main reason for keeping the virtual machine model. Since we completely automated this, the provisioning and lifecyclemanagement relating to the VM’s is no problem for us.
Currently we deliver about 1500 VM’s to our customer (biggest part is still Java). We very much favor small VM’s with specific isolated workloads as opposed to big machines with consolidated (possibly unrelated) workloads.
Back to Docker Datacenter (DDC).
We decided to implement Docker Datacenter (at least for production workloads) to get the extra support and to use the current extra tools (the UCP and the DTR). However we have to decide what the scope of a DDC installation will be.
The idea is still to create e Docker Swarm per customer where the Customer is able to manage the scale of the swarm (both horizontal and vertical). Again since the license is CS Docker related and not based on something like (Virtual)CPU’s this is possibly expensive and I don’t like to mix technical choices with licensing choices (licensing choices are commercial and changed without taking technology in account).
The reference design form Docker for UCP looks to me like it’s more based on a traditional (enterprise) IT model. A large central cluster for Docker workloads managed by a central Ops team. Dev delivers containers and specifications and Ops is responsible for security, management etc.
As far as I can tell there is no real multi-tenancy built into UCP (as there is in Docker Cloud). Furthermore I don’t think UCP is able to support more than one swarm?
From a technical point of view we could provision a Docker Swarm with UCP installed and running on the same nodes as where the customer will run it’s own container workload, but the question is if that is a good reliable solution?
We really need this ability in the product. And I also think licensing should be more flexible than just based on CS Docker engines without taking size into account.
Currently I see two models for us:
- A very large DDC installation with one UCP, sliced among customers, whereby multi-tenancy within UCP is currently not enough.
- A UCP and swarm per customer, maybe combining UCP on the UCP nodes, but this model is ‘expensive’ from a licensing point of view.