Application Container Support
Open Discussion
As a user I would like to be able to deploy my web application as a container on a cPanel & WHM system so that I can control the entire stack that my application runs in.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
We have been watching development of application containers for quite some time now. We clearly see value that application containers can deliver to the hosting industry. Between docker, rkt and the various other solutions that are in development currently there is quite a bit of movement in this field that should not be ignored.
The security problems associated with containers are concerning, allowing users access to root within an application container is a terrifying concept as that puts a user one kernel exploit away from pwning the entire server. Specialized Application Container hosts are tweaked in ways specificly for running application kernels, such as newer kernels and core utilities updated for support of things like sub uids.
One way to mitigate this that helps small companies/single site systems by making container management a root-only feature. This approach will require users who want the advantages of app containers but may not have the skill to properly administrate a server handling it.
Another option is to build our application containers in a way that the process within the container runs as the same uid as the one running the system. This would make our application containers incompatible with docker hub.
It's quite possible that our market will be willing to take on these risks considering a large chunk of VPS providers have the same issues if they're using certain virtualization methods. However I feel like we would be misleading to not discuss these issues while planning our roadmap.
We have been watching development of application containers for quite some time now. We clearly see value that application containers can deliver to the hosting industry. Between docker, rkt and the various other solutions that are in development currently there is quite a bit of movement in this field that should not be ignored.
The security problems associated with containers are concerning, allowing users access to root within an application container is a terrifying concept as that puts a user one kernel exploit away from pwning the entire server. Specialized Application Container hosts are tweaked in ways specificly for running application kernels, such as newer kernels and core utilities updated for support of things like sub uids.
One way to mitigate this that helps small companies/single site systems by making container management a root-only feature. This approach will require users who want the advantages of app containers but may not have the skill to properly administrate a server handling it.
Another option is to build our application containers in a way that the process within the container runs as the same uid as the one running the system. This would make our application containers incompatible with docker hub.
It's quite possible that our market will be willing to take on these risks considering a large chunk of VPS providers have the same issues if they're using certain virtualization methods. However I feel like we would be misleading to not discuss these issues while planning our roadmap.
With just some cursory review of docker.io's website, there are a few things I'd mention at this point in time (2014-04-23 as of this writing).
They have a note on their own site indicating:
* Please note Docker is currently under heavy development. It should not be used in production (yet).
Therefore it seems like, at the very least, we would want to wait until its developers feel comfortable enough with their product for production purposes.
Beyond that, whether we ourselves pursue anything with docker.io would have to deal greatly with the demonstrated demand for it on this feature site (votes/comments) as well as further explicit examples of the significant advantages of docker.io versus existing installation methods and other technologies.
Just from reading about it, docker.io does not seem built or intended for products like cPanel & WHM. It's more so designed at integrating together multiple products/daemons/services and multiple servers within a cloud infrastructure. cPanel & WHM is a single product single server solution. This would seem to almost complicate matters more so than simplify them as a result by adding a further layer of complexity.
I am not entirely convinced cPanel & WHM would be able to be deployed through docker.io given its expectation that you can "build once, deploy everywhere". There are many configs and other services purpose-built for the particular server installation. You would have to modify those configs and rebuild those services each and every time you re-deployed the install in this manner, which docker.io would be incapable of being aware of and seems to not support/expect.
Docker.io seems to (as a very loose, high level, crude analogy) mimic the intent of cPanel & WHM itself which is to unify and simplify the installation of multiple services. Therefore to function with Docker.io we'd have to tear down cPanel & WHM as a product and attempt to force it to fit the Docker.io model, which by design it is not intended to be installed as separate "parts". cPanel & WHM only works as a whole.
In short, I do not see how docker.io fits into the cPanel & WHM design. It seems to almost go against the design of cPanel & WHM where it wouldn't fit into any of the deployment/design of our product. It is not intended or designed for deploying one-product one-server entire solutions. It's intended for putting together a plethora of small one-off services and products to form a solution.
With just some cursory review of docker.io's website, there are a few things I'd mention at this point in time (2014-04-23 as of this writing).
They have a note on their own site indicating:
* Please note Docker is currently under heavy development. It should not be used in production (yet).
Therefore it seems like, at the very least, we would want to wait until its developers feel comfortable enough with their product for production purposes.
Beyond that, whether we ourselves pursue anything with docker.io would have to deal greatly with the demonstrated demand for it on this feature site (votes/comments) as well as further explicit examples of the significant advantages of docker.io versus existing installation methods and other technologies.
Just from reading about it, docker.io does not seem built or intended for products like cPanel & WHM. It's more so designed at integrating together multiple products/daemons/services and multiple servers within a cloud infrastructure. cPanel & WHM is a single product single server solution. This would seem to almost complicate matters more so than simplify them as a result by adding a further layer of complexity.
I am not entirely convinced cPanel & WHM would be able to be deployed through docker.io given its expectation that you can "build once, deploy everywhere". There are many configs and other services purpose-built for the particular server installation. You would have to modify those configs and rebuild those services each and every time you re-deployed the install in this manner, which docker.io would be incapable of being aware of and seems to not support/expect.
Docker.io seems to (as a very loose, high level, crude analogy) mimic the intent of cPanel & WHM itself which is to unify and simplify the installation of multiple services. Therefore to function with Docker.io we'd have to tear down cPanel & WHM as a product and attempt to force it to fit the Docker.io model, which by design it is not intended to be installed as separate "parts". cPanel & WHM only works as a whole.
In short, I do not see how docker.io fits into the cPanel & WHM design. It seems to almost go against the design of cPanel & WHM where it wouldn't fit into any of the deployment/design of our product. It is not intended or designed for deploying one-product one-server entire solutions. It's intended for putting together a plethora of small one-off services and products to form a solution.
Docker is on the roadmap for RedHat + OpenStack as well: https://wiki.openstack.org/wiki/HypervisorSupportMatrix
Hope CPanel finds a way to play :)
Docker is on the roadmap for RedHat + OpenStack as well: https://wiki.openstack.org/wiki/HypervisorSupportMatrix
Hope CPanel finds a way to play :)
Check these benchmark's between KVM and Docker LXC:
http://bodenr.blogspot.com/2014/05/kvm-and-docker-lxc-benchmarking-with.html
Forward
containers (LXCs) are rapidly becoming the new "unit of deployment"
changing how we develop, package, deploy and manage applications at all
scales (from test / dev to production service ready environments). This
application life cycle transformation also enables fluidity to once
frictional use cases in a traditional hypervisor Virtual Machine (VM)
environment. For example, developing applications in virtual
environments and seamlessly "migrating" to bare metal for production.
Not only do containers simplify the workflow and life cycle of
application development / deployment, but they also provide performance
and density benefits which cannot be overlooked.
At the forefront of Linux Container tooling we have docker
-- a LXC framework / runtime which abstracts out various aspects of the
underlying realization by providing a pluggable architecture supporting
various storage types, LXC engines / providers, etc.. In addition to
making LXC dead easy and fun, docker also brings a set of capabilities
to the table which make containers more productive including; automated
builds (make files for LXC images), versioning support, fully featured
REST API + CLI, the notion of image repositories and more.
Before going any further, let me reiterate some of the major benefits of Linux Containers from a docker perspective:
move between virtual and bare metal environments permitting new
development workflows which reduce costs (e.g. develop on VMs and move
to bare metal in the "click of a button" for production).
per container penalty which equates to greater density and hence
greater returns on existing assets -- imagine packing 100s or 1000s of
containers on a single host node.
Also, from http://stackoverflow.com/questions/16047306/how-is-docker-io-different-from-a-normal-virtual-machine
(LXC), which run in the same operating system as its host. This allows
it to share a lot of the host operating system resources. It also uses AuFS for the file system. It also manages the networking for you as well.
write part, and merge those together. So you could have the common
parts of the operating system as read only, which are shared amongst all
of your containers, and then give each container its own mount for
writing.
wanted to use a Full VM, you would need to have 1GB times x number of
VMs you want. With LXC and AuFS you can share the bulk of the 1GB and if
you have 1000 containers you still might only have a little over 1GB of
space for the containers OS, assuming they are all running the same OS
image.
it, and does minimal sharing. You get more isolation, but it is much
heavier (requires more resources).
require less resources. So you could easily run 1000's on a host, and it
doesn't even blink. Try doing that with Xen, and unless you have a
really big host, I don't think it is possible.
want full isolation with guaranteed resources, a full VM is the way to
go. If you just want to isolate processes from each other and want to
run a ton of them on a reasonably sized host, then LXC might be the way
to go.
I feel foolish for asking, but why is deploying software to a
docker image (if that's the right term) easier than simply deploying to a
consistent production environment?
done. Even if you use tools like chef and puppet, there are always OS
updates and other things that change between hosts and environments.
common image, and makes it easy to deploy on other docker hosts.
Locally, dev, qa, prod, etc, all the same image. Sure you can do this
with other tools, but not as easily or fast.
need to connect to a database, and in order to not break anything you
need to run serially so that the tests don't step on each other (run
each test in a transaction and roll back). With Docker you could create
an image of your database, and then run all the tests in parallel since
you know they will all be running against the same snapshot of the
database. Since they are running in parallel and in LXC containers they
could run all on the same box at the same time, and your tests will
finish much faster. Try doing that with a full VM.
Interesting! I suppose I'm still confused by the notion of
"snapshot[ting] the OS". How does one do that without, well, making an
image of the OS?
then make your changes, and commit those changes using docker, and it
creates an image. This image contains only the differences from the
base. When you want to run your image, you also need the base, and it
layers your image on top of the base using a layered file system, in
this case AUFS. AUFS merges the different layers together and you get
what you want, and you just need to run it. You can keep adding more and
more images (layers) and it will keep only saving the diffs.
Check these benchmark's between KVM and Docker LXC:
http://bodenr.blogspot.com/2014/05/kvm-and-docker-lxc-benchmarking-with.html
Forward
containers (LXCs) are rapidly becoming the new "unit of deployment"
changing how we develop, package, deploy and manage applications at all
scales (from test / dev to production service ready environments). This
application life cycle transformation also enables fluidity to once
frictional use cases in a traditional hypervisor Virtual Machine (VM)
environment. For example, developing applications in virtual
environments and seamlessly "migrating" to bare metal for production.
Not only do containers simplify the workflow and life cycle of
application development / deployment, but they also provide performance
and density benefits which cannot be overlooked.
At the forefront of Linux Container tooling we have docker
-- a LXC framework / runtime which abstracts out various aspects of the
underlying realization by providing a pluggable architecture supporting
various storage types, LXC engines / providers, etc.. In addition to
making LXC dead easy and fun, docker also brings a set of capabilities
to the table which make containers more productive including; automated
builds (make files for LXC images), versioning support, fully featured
REST API + CLI, the notion of image repositories and more.
Before going any further, let me reiterate some of the major benefits of Linux Containers from a docker perspective:
move between virtual and bare metal environments permitting new
development workflows which reduce costs (e.g. develop on VMs and move
to bare metal in the "click of a button" for production).
per container penalty which equates to greater density and hence
greater returns on existing assets -- imagine packing 100s or 1000s of
containers on a single host node.
Also, from http://stackoverflow.com/questions/16047306/how-is-docker-io-different-from-a-normal-virtual-machine
(LXC), which run in the same operating system as its host. This allows
it to share a lot of the host operating system resources. It also uses AuFS for the file system. It also manages the networking for you as well.
write part, and merge those together. So you could have the common
parts of the operating system as read only, which are shared amongst all
of your containers, and then give each container its own mount for
writing.
wanted to use a Full VM, you would need to have 1GB times x number of
VMs you want. With LXC and AuFS you can share the bulk of the 1GB and if
you have 1000 containers you still might only have a little over 1GB of
space for the containers OS, assuming they are all running the same OS
image.
it, and does minimal sharing. You get more isolation, but it is much
heavier (requires more resources).
require less resources. So you could easily run 1000's on a host, and it
doesn't even blink. Try doing that with Xen, and unless you have a
really big host, I don't think it is possible.
want full isolation with guaranteed resources, a full VM is the way to
go. If you just want to isolate processes from each other and want to
run a ton of them on a reasonably sized host, then LXC might be the way
to go.
I feel foolish for asking, but why is deploying software to a
docker image (if that's the right term) easier than simply deploying to a
consistent production environment?
done. Even if you use tools like chef and puppet, there are always OS
updates and other things that change between hosts and environments.
common image, and makes it easy to deploy on other docker hosts.
Locally, dev, qa, prod, etc, all the same image. Sure you can do this
with other tools, but not as easily or fast.
need to connect to a database, and in order to not break anything you
need to run serially so that the tests don't step on each other (run
each test in a transaction and roll back). With Docker you could create
an image of your database, and then run all the tests in parallel since
you know they will all be running against the same snapshot of the
database. Since they are running in parallel and in LXC containers they
could run all on the same box at the same time, and your tests will
finish much faster. Try doing that with a full VM.
Interesting! I suppose I'm still confused by the notion of
"snapshot[ting] the OS". How does one do that without, well, making an
image of the OS?
then make your changes, and commit those changes using docker, and it
creates an image. This image contains only the differences from the
base. When you want to run your image, you also need the base, and it
layers your image on top of the base using a layered file system, in
this case AUFS. AUFS merges the different layers together and you get
what you want, and you just need to run it. You can keep adding more and
more images (layers) and it will keep only saving the diffs.
Responding to Brian's comment above:
for products like cPanel & WHM. It's more so designed at
integrating together multiple products/daemons/services and multiple
servers within a cloud infrastructure. cPanel & WHM is a single
product single server solution.
Docker essentially consists of two components: it creates a Linux container and layers a 'template' onto that containing the specific Linux distribution, services and so on as you've described.
From cPanel's point of view, I think it's only necessary to support running cPanel inside such an OS container - I don't believe that cPanel would (or indeed should) have to support the actual creation of a Docker template to install cPanel.
This could be user-created, or maintained by Docker themselves.
I have created a separate feature request to support Linux namespace containers:
http://features.cpanel.net/responses/linux-namespace-container-lxc-docker-containers-support
This is *not* the same as only supporting Docker (it's not a duplicate request!) but, by supporting the container features in the mainstream Linux kernel, it would include support for the OS component of Docker.
I hope you'll pardon the shameless plug but I believe it's relevant to this request, and I'd encourage anybody who has voted for this to also consider voting for Linux container support as a whole.
Responding to Brian's comment above:
for products like cPanel & WHM. It's more so designed at
integrating together multiple products/daemons/services and multiple
servers within a cloud infrastructure. cPanel & WHM is a single
product single server solution.
Docker essentially consists of two components: it creates a Linux container and layers a 'template' onto that containing the specific Linux distribution, services and so on as you've described.
From cPanel's point of view, I think it's only necessary to support running cPanel inside such an OS container - I don't believe that cPanel would (or indeed should) have to support the actual creation of a Docker template to install cPanel.
This could be user-created, or maintained by Docker themselves.
I have created a separate feature request to support Linux namespace containers:
http://features.cpanel.net/responses/linux-namespace-container-lxc-docker-containers-support
This is *not* the same as only supporting Docker (it's not a duplicate request!) but, by supporting the container features in the mainstream Linux kernel, it would include support for the OS component of Docker.
I hope you'll pardon the shameless plug but I believe it's relevant to this request, and I'd encourage anybody who has voted for this to also consider voting for Linux container support as a whole.
They have a note on their own site indicating:- * Please note Docker is currently under heavy development. It should not be used in production (yet).
This has changed with the 1.0 release, and introduction of enterprise support:
http://blog.docker.com/2014/06/its-here-docker-1-0/
They have a note on their own site indicating:- * Please note Docker is currently under heavy development. It should not be used in production (yet).
This has changed with the 1.0 release, and introduction of enterprise support:
http://blog.docker.com/2014/06/its-here-docker-1-0/
Docker is a great tool for creating a production build that can be pushed to a server running Cpanel/Whm. The biggest issue is for Cpanel to be able to run the docker container AND maintain Cpanel templates. The latter is key (and really easy.)
Docker is a great tool for creating a production build that can be pushed to a server running Cpanel/Whm. The biggest issue is for Cpanel to be able to run the docker container AND maintain Cpanel templates. The latter is key (and really easy.)
I think that everyone is really missing the point and beauty of Docker in this thread.
Distributing Cpanel with Docker is what is being focused on. I think that is wrong headed.
The point of Docker is to isolate a piece of software and its dependencies from the rest of the system. This is something, that if embraced by Cpanel, could change the server management game and flip it on its head.
If Cpanel were to leverage Docker, it could open a huge realm of possibilities. Picture this. Multiple instances(and versions) of Apache and PHP running on a server being completely unaware of each other. You could easily have each cpanel user using a completely different stack, isolated from each other, all without the overheard of having multiple virtual machines.
Also, in theory the Cpanel staff should see a huge reduction in the number dependency issues . You can completely isolate each software. IE you can isolate Mysql and it dependencies from Bind, Apache, Exim and so on.
I encourage you to take another look and try to understand what is really possible here..
I think that everyone is really missing the point and beauty of Docker in this thread.
Distributing Cpanel with Docker is what is being focused on. I think that is wrong headed.
The point of Docker is to isolate a piece of software and its dependencies from the rest of the system. This is something, that if embraced by Cpanel, could change the server management game and flip it on its head.
If Cpanel were to leverage Docker, it could open a huge realm of possibilities. Picture this. Multiple instances(and versions) of Apache and PHP running on a server being completely unaware of each other. You could easily have each cpanel user using a completely different stack, isolated from each other, all without the overheard of having multiple virtual machines.
Also, in theory the Cpanel staff should see a huge reduction in the number dependency issues . You can completely isolate each software. IE you can isolate Mysql and it dependencies from Bind, Apache, Exim and so on.
I encourage you to take another look and try to understand what is really possible here..
It's fascinating to watch the enthusiasm behind what is essentially a chroot + nice tools. :)
You are correct that there are many possibilities the technology affords people, from a system administrative, developer, and end user perspective. Some of the things you mentioned are similar to things we've discussed internally as a use for containers.
We're definitely interested in the technology and hope to begin dabbling in it soon.
It's fascinating to watch the enthusiasm behind what is essentially a chroot + nice tools. :)
You are correct that there are many possibilities the technology affords people, from a system administrative, developer, and end user perspective. Some of the things you mentioned are similar to things we've discussed internally as a use for containers.
We're definitely interested in the technology and hope to begin dabbling in it soon.
Hello Docker is more than just chroot, you can set ressources limits and move docker containers from one OS to another without any need to reinstall them or manage dependencies you can run multiple docker instances on the same server, have one instance per user etc. The ressources isolation CloudLinux already does, and there is also hope that Cloudlinux soon adds support to have virtual networks per user. What we rearly like is how easy it is to move a container from one server to another. How you could run multiple cPanel versions on the same server etc.
I'm not an expert in docker yet, but I agree LXC containers with Docker seem to be the way things are going. Just imagine each user having their own memcached, nodejs, choice between apache and nginx, choice of mysql version, ssh server etc, all managed by cPanel…
We currently have cPanel hosting for customers who want to not have to manage any of the server configuration details, and VPS hosting for customers who have sysadmin knowledge and want vps specific software.
What about allowing users to have VPS specific software (nodjs, memcached, solr, their own varnish installation…) all managed inside cPanel from the cPanel control pannel…
Once the images are available, it's just a matter of running them with the correct network configuration and config files.
I don't know of any control pannels that do this type of thing yet but I'm sure it will come in the next coupe of years. It could make cPanel type shared hosting old hat so I beleive cPanel needs to look into this seriously.
I've just recieved my docker book http://www.dockerbook.com an am seriously looking into how we can use it for added service.
Hello Docker is more than just chroot, you can set ressources limits and move docker containers from one OS to another without any need to reinstall them or manage dependencies you can run multiple docker instances on the same server, have one instance per user etc. The ressources isolation CloudLinux already does, and there is also hope that Cloudlinux soon adds support to have virtual networks per user. What we rearly like is how easy it is to move a container from one server to another. How you could run multiple cPanel versions on the same server etc.
I'm not an expert in docker yet, but I agree LXC containers with Docker seem to be the way things are going. Just imagine each user having their own memcached, nodejs, choice between apache and nginx, choice of mysql version, ssh server etc, all managed by cPanel…
We currently have cPanel hosting for customers who want to not have to manage any of the server configuration details, and VPS hosting for customers who have sysadmin knowledge and want vps specific software.
What about allowing users to have VPS specific software (nodjs, memcached, solr, their own varnish installation…) all managed inside cPanel from the cPanel control pannel…
Once the images are available, it's just a matter of running them with the correct network configuration and config files.
I don't know of any control pannels that do this type of thing yet but I'm sure it will come in the next coupe of years. It could make cPanel type shared hosting old hat so I beleive cPanel needs to look into this seriously.
I've just recieved my docker book http://www.dockerbook.com an am seriously looking into how we can use it for added service.
This is absolutely sex-on-the-beach attractive from my perspective. I have been fighting with a large cPanel server for the past year and the #1 limitation has been that of flexibility. I have managed to coax it into running TorqueBox 3.x for Ruby and other Rails apps, but it was a major pain. Now I have some projects that are needing NodeJS and even another that is going to require some custom NoSQL DB work in Couch and such.
So far I've been running all of these along side of cPanel, but I dislike it as it creates additional headaches that I shouldn't have to futz with. If I could just run these in containers and then forward ports for each host appropriately and proxy them via Apache, I and many others would be exceptionally happier with cPanel.
I love that cPanel offers a solid base for hosting, but with so many technologies today available that are at or above the level of PHP (yes, I and my developers can run circles around PHP devs with Ruby and we have 6 Ruby (Sinatra and Rails) apps that we have deployed along side of cPanel now), we need these options DESPERATELY and NOW.
This is absolutely sex-on-the-beach attractive from my perspective. I have been fighting with a large cPanel server for the past year and the #1 limitation has been that of flexibility. I have managed to coax it into running TorqueBox 3.x for Ruby and other Rails apps, but it was a major pain. Now I have some projects that are needing NodeJS and even another that is going to require some custom NoSQL DB work in Couch and such.
So far I've been running all of these along side of cPanel, but I dislike it as it creates additional headaches that I shouldn't have to futz with. If I could just run these in containers and then forward ports for each host appropriately and proxy them via Apache, I and many others would be exceptionally happier with cPanel.
I love that cPanel offers a solid base for hosting, but with so many technologies today available that are at or above the level of PHP (yes, I and my developers can run circles around PHP devs with Ruby and we have 6 Ruby (Sinatra and Rails) apps that we have deployed along side of cPanel now), we need these options DESPERATELY and NOW.
When CentOS 7 is taking a major stake of the installed base we might see some more exposure to docker.
When CentOS 7 is taking a major stake of the installed base we might see some more exposure to docker.
Note that Docker is already in Production use by Mirantis OpenStack Cloud. Also, this month (October 2014) the competitor Open-Source product, Sentora, started distributing their Control Panel system via Docker Hub, albeit only for testing so far. Sometime next month, I'm going to try deploying CPanel on a CentOS Docker image anyway. Will the CPanel license prevent me from publishing my result?
Note that Docker is already in Production use by Mirantis OpenStack Cloud. Also, this month (October 2014) the competitor Open-Source product, Sentora, started distributing their Control Panel system via Docker Hub, albeit only for testing so far. Sometime next month, I'm going to try deploying CPanel on a CentOS Docker image anyway. Will the CPanel license prevent me from publishing my result?
I believe a full cpanel would fonction correctly inside a docker container but that would go agains't the way docker is designed. Each peace of software should be inside it's own container and companies who deploy docker for shared hosting have one container per user based on a php template, that allows them to limit cpu and ram for this user.
So the minimum would be to install cpanel in one docker instance, apache in another, mysql in another, ssh in another, php versions in their own containers etc.
This would make everything highly portable and compatible with different operating systems.
Even user data is supposed to be in a container.
From a security perspective being able to choose what each application can access is also great !
This would be quite complicated to achieve and would require reworking alot of things in cpanel, but in my point of view if cpanel does't evolve to something like this, other control pannels will come and take up the market for shared hosting with features you can only currently get on dedicated hosting
I believe a full cpanel would fonction correctly inside a docker container but that would go agains't the way docker is designed. Each peace of software should be inside it's own container and companies who deploy docker for shared hosting have one container per user based on a php template, that allows them to limit cpu and ram for this user.
So the minimum would be to install cpanel in one docker instance, apache in another, mysql in another, ssh in another, php versions in their own containers etc.
This would make everything highly portable and compatible with different operating systems.
Even user data is supposed to be in a container.
From a security perspective being able to choose what each application can access is also great !
This would be quite complicated to achieve and would require reworking alot of things in cpanel, but in my point of view if cpanel does't evolve to something like this, other control pannels will come and take up the market for shared hosting with features you can only currently get on dedicated hosting
Docker is now in production!
Docker is now in production!
I've been thinking about implementing docker recently and I have come to the conclusion that docker could be a great way to provide private applications to each user.
This is how I would manually configure docker, but before pushing to production would need a control panel… why not cpanel ? I rearly do belive this is the future for webhosting and that you should take this seriously. I also know this would be alot of work to add to cPanel may even imply creating a new control panel specificaly for this while keeping all existing features.
Step 1, move all functionality that would not benefit from a per user container approach to 1 container per application. I concider the following applications to be :
1 global container for Front end proxy webserver like nginx or litespeed
1 global container for E-mail software (exim, dovecot…)
1 global container for cPanel
1 global container for FTP software
1 container for cPanel specific databases
1 container for cPanel's own PHP
Then for each user :
1 PHP container
1 File storage container for websites
1 File storage container for emails
1 Mysql container (allows private query cache and complete security from brute force attacks on other compromised accounts).
1 Memcached container
1 Solr container
1 Nodejs container
1 Redis container
For this implementation each user could have their own IP and networking would need to be configured on a per IP basis. With IPv6 comming where numbers of IP's won't be a limit I think it's time to start working on something like this.
If you were to present a customer with a traditional hosting plan with everything shared and a hosting plan with everything private and both being completly managed thy would defenely choose the second.
Docker seems to make this possible without needing much more ressources than traditional hosting so all we are missing is the control panel to manage it.
Large companies have already started developing this some have already implemented this for things like PHP and are running it in productions with millions of containers.
Competition will come soon with this an we will start developing our in house solution if cPanel doesn't start showing signs of interest soon because we don't want to be left behind when this happens.
I've been thinking about implementing docker recently and I have come to the conclusion that docker could be a great way to provide private applications to each user.
This is how I would manually configure docker, but before pushing to production would need a control panel… why not cpanel ? I rearly do belive this is the future for webhosting and that you should take this seriously. I also know this would be alot of work to add to cPanel may even imply creating a new control panel specificaly for this while keeping all existing features.
Step 1, move all functionality that would not benefit from a per user container approach to 1 container per application. I concider the following applications to be :
1 global container for Front end proxy webserver like nginx or litespeed
1 global container for E-mail software (exim, dovecot…)
1 global container for cPanel
1 global container for FTP software
1 container for cPanel specific databases
1 container for cPanel's own PHP
Then for each user :
1 PHP container
1 File storage container for websites
1 File storage container for emails
1 Mysql container (allows private query cache and complete security from brute force attacks on other compromised accounts).
1 Memcached container
1 Solr container
1 Nodejs container
1 Redis container
For this implementation each user could have their own IP and networking would need to be configured on a per IP basis. With IPv6 comming where numbers of IP's won't be a limit I think it's time to start working on something like this.
If you were to present a customer with a traditional hosting plan with everything shared and a hosting plan with everything private and both being completly managed thy would defenely choose the second.
Docker seems to make this possible without needing much more ressources than traditional hosting so all we are missing is the control panel to manage it.
Large companies have already started developing this some have already implemented this for things like PHP and are running it in productions with millions of containers.
Competition will come soon with this an we will start developing our in house solution if cPanel doesn't start showing signs of interest soon because we don't want to be left behind when this happens.
I think cPanel could leverage Docker to put themselves way ahead of all the new controlpanels out there. I could make many customers happy they could run their docker container within their current cPanel account.
Monarobases list of possible uses is nice but huge and I think way overkill for 90% of the cPanel hosting companies. I (and I think most of the cPanel owners with me) only use cPanel for regular smaller clients. Those clients who want big DBs and huge mailinglists and stuff, they need more performance and will use a VPS.
So with this in mind I always try to look at it from different angles, not only mine but also cPanels. What could be the MVP (minimum viable product) in this? How could cPanel with minimal efforts leverage this technology in the first sprint. Well, makeing it possible to run a docker container per customer only for their webservices (LAMP parts). And even that only as an option, or cPanel should make a standard Docker container for those customers who don''t care about Docker.
And as a long time cPanel owner, I'm almost sure my cPanel customers don't care about Docker for email applications or other parts of the cPanel server.
I think cPanel could leverage Docker to put themselves way ahead of all the new controlpanels out there. I could make many customers happy they could run their docker container within their current cPanel account.
Monarobases list of possible uses is nice but huge and I think way overkill for 90% of the cPanel hosting companies. I (and I think most of the cPanel owners with me) only use cPanel for regular smaller clients. Those clients who want big DBs and huge mailinglists and stuff, they need more performance and will use a VPS.
So with this in mind I always try to look at it from different angles, not only mine but also cPanels. What could be the MVP (minimum viable product) in this? How could cPanel with minimal efforts leverage this technology in the first sprint. Well, makeing it possible to run a docker container per customer only for their webservices (LAMP parts). And even that only as an option, or cPanel should make a standard Docker container for those customers who don''t care about Docker.
And as a long time cPanel owner, I'm almost sure my cPanel customers don't care about Docker for email applications or other parts of the cPanel server.
The most important parts for us would be to allow customers to have private mysql, memcache, solr instances etc. Basisacly leverage docker containers ability to choose what containers can communicate together
The most important parts for us would be to allow customers to have private mysql, memcache, solr instances etc. Basisacly leverage docker containers ability to choose what containers can communicate together
Some other FRs which could be fixed without too much effort when docker support is delivered:
https://features.cpanel.net/topic/nodejs-hosting
https://features.cpanel.net/topic/allow-to-install-multiple-php-5x-versions
https://features.cpanel.net/topic/ruby-app-support-through-phusion-passenger
https://features.cpanel.net/topic/as-a-server-administrator-i-want-support-for-mongodb-or-couchdb-so-that-i-can-support-schema-free-databases
https://features.cpanel.net/topic/as-a-server-administrator-i-want-standalone-nginx-supported-as-an-alternative-to-apache-so-that-i-can-offer-faster-speed-and-lower-load-on-smallers-servers
And probably some more...
Some other FRs which could be fixed without too much effort when docker support is delivered:
https://features.cpanel.net/topic/nodejs-hosting
https://features.cpanel.net/topic/allow-to-install-multiple-php-5x-versions
https://features.cpanel.net/topic/ruby-app-support-through-phusion-passenger
https://features.cpanel.net/topic/as-a-server-administrator-i-want-support-for-mongodb-or-couchdb-so-that-i-can-support-schema-free-databases
https://features.cpanel.net/topic/as-a-server-administrator-i-want-standalone-nginx-supported-as-an-alternative-to-apache-so-that-i-can-offer-faster-speed-and-lower-load-on-smallers-servers
And probably some more...
See: https://www.cloudlinux.com/company/news/index.php?ELEMENT_ID=1821
See: https://www.cloudlinux.com/company/news/index.php?ELEMENT_ID=1821
I think that idea died a silent death... The Kuberdock repository has had just 11 commits since the beginning of March. Most of them before this press release.
AWS now has Docker container service. Hopefully we'll see some controlpanels build to support Docker next to other basic services soon.
I think that idea died a silent death... The Kuberdock repository has had just 11 commits since the beginning of March. Most of them before this press release.
AWS now has Docker container service. Hopefully we'll see some controlpanels build to support Docker next to other basic services soon.
cPanel should use Docker as a security feature as well as a way of providing secure private memcached, solr, mysql instances on a per user basis.
We don't want the whole of cPanel in a docker image, anyone can do that and it's against the whole docker approach. Docker should be used to add security and add features that are currently reserved to vps hosting without a control pannel.
How about cPanel 12 dockerized to replace cpanel 11 accelerated ?
cPanel should use Docker as a security feature as well as a way of providing secure private memcached, solr, mysql instances on a per user basis.
We don't want the whole of cPanel in a docker image, anyone can do that and it's against the whole docker approach. Docker should be used to add security and add features that are currently reserved to vps hosting without a control pannel.
How about cPanel 12 dockerized to replace cpanel 11 accelerated ?
Indeed security is a good point for container support. Which brings me to the reason the CoreOS team - which has been deeply involved in Docker - is now building it's own container application "Rkt". Docker needs a serious design adjustment to make it secure. Especially in a shared environments.
Rkt supports several container types such as Docker containers and has a focus shifted more toward security in shared environments.
So I would like to propose to rename this FR to "Container support".
Here is some more information on the (security) reasons for CoreOS to start on Rkt. https://coreos.com/blog/rocket/
Indeed security is a good point for container support. Which brings me to the reason the CoreOS team - which has been deeply involved in Docker - is now building it's own container application "Rkt". Docker needs a serious design adjustment to make it secure. Especially in a shared environments.
Rkt supports several container types such as Docker containers and has a focus shifted more toward security in shared environments.
So I would like to propose to rename this FR to "Container support".
Here is some more information on the (security) reasons for CoreOS to start on Rkt. https://coreos.com/blog/rocket/
We have been watching development of application containers for quite some time now. We clearly see value that application containers can deliver to the hosting industry. Between docker, rkt and the various other solutions that are in development currently there is quite a bit of movement in this field that should not be ignored.
The security problems associated with containers are concerning, allowing users access to root within an application container is a terrifying concept as that puts a user one kernel exploit away from pwning the entire server. Specialized Application Container hosts are tweaked in ways specificly for running application kernels, such as newer kernels and core utilities updated for support of things like sub uids.
One way to mitigate this that helps small companies/single site systems by making container management a root-only feature. This approach will require users who want the advantages of app containers but may not have the skill to properly administrate a server handling it.
Another option is to build our application containers in a way that the process within the container runs as the same uid as the one running the system. This would make our application containers incompatible with docker hub.
It's quite possible that our market will be willing to take on these risks considering a large chunk of VPS providers have the same issues if they're using certain virtualization methods. However I feel like we would be misleading to not discuss these issues while planning our roadmap.
We have been watching development of application containers for quite some time now. We clearly see value that application containers can deliver to the hosting industry. Between docker, rkt and the various other solutions that are in development currently there is quite a bit of movement in this field that should not be ignored.
The security problems associated with containers are concerning, allowing users access to root within an application container is a terrifying concept as that puts a user one kernel exploit away from pwning the entire server. Specialized Application Container hosts are tweaked in ways specificly for running application kernels, such as newer kernels and core utilities updated for support of things like sub uids.
One way to mitigate this that helps small companies/single site systems by making container management a root-only feature. This approach will require users who want the advantages of app containers but may not have the skill to properly administrate a server handling it.
Another option is to build our application containers in a way that the process within the container runs as the same uid as the one running the system. This would make our application containers incompatible with docker hub.
It's quite possible that our market will be willing to take on these risks considering a large chunk of VPS providers have the same issues if they're using certain virtualization methods. However I feel like we would be misleading to not discuss these issues while planning our roadmap.
Doctor allows portability and scalability as well as application isolation. Keep watching it as it dominates the cloud the structure world, but at least acknowledge many hosting providers using cp also want to use docker
Doctor allows portability and scalability as well as application isolation. Keep watching it as it dominates the cloud the structure world, but at least acknowledge many hosting providers using cp also want to use docker
What would be ideal in this case would be to directly support Dokku. This would facilitate the deployment of any kind of app platform (Ruby (Sinatra, Ruby on Rails), Python (Django), NodeJS, Racket, ad infinitum) via a Heroku-like experience right on the system.
Personally we're about to drop cPanel right now due to these limitations since we do such custom app development and hosting. If cPanel were to have this readily accessible, it would keep us on cPanel for sure.
What would be ideal in this case would be to directly support Dokku. This would facilitate the deployment of any kind of app platform (Ruby (Sinatra, Ruby on Rails), Python (Django), NodeJS, Racket, ad infinitum) via a Heroku-like experience right on the system.
Personally we're about to drop cPanel right now due to these limitations since we do such custom app development and hosting. If cPanel were to have this readily accessible, it would keep us on cPanel for sure.
This may be of interest to everyone: https://github.com/cloudlinux/kuberdock-platform
This may be of interest to everyone: https://github.com/cloudlinux/kuberdock-platform
I would love to see Docker supported, such that it's installable on the host WHM system and a dev/sysadmin can side load additional services such as onlyoffice document server. Then it can tie up nicely with say nextcloud or humhub that's being delivered through cpanel.
It seems a waste of server resources to have to push this out to another box simply to ensure it doesn't conflict with WHM. Docker and WHM playing nice with each other would be awesome.
I would love to see Docker supported, such that it's installable on the host WHM system and a dev/sysadmin can side load additional services such as onlyoffice document server. Then it can tie up nicely with say nextcloud or humhub that's being delivered through cpanel.
It seems a waste of server resources to have to push this out to another box simply to ensure it doesn't conflict with WHM. Docker and WHM playing nice with each other would be awesome.
We're moving towards developing applications and even simple sites using Docker containers for 2 reasons:
I think containerized apps/sites are the future. Cloud providers are doing it with their own blend of "container as a service" but the overall cost is still high for small operations. I think costs is where Cpanel can shine so I hope Cpanel finds a way to run containers in a secure way. How about a completely different edition of Cpanel (e.g., Cpanel for Containers)?
Including Git with Cpanel was a step in the right direction as it's now de facto standard in modern web dev't. Containerization is the next best thing in web dev't and so is for CPanel!
We're moving towards developing applications and even simple sites using Docker containers for 2 reasons:
I think containerized apps/sites are the future. Cloud providers are doing it with their own blend of "container as a service" but the overall cost is still high for small operations. I think costs is where Cpanel can shine so I hope Cpanel finds a way to run containers in a secure way. How about a completely different edition of Cpanel (e.g., Cpanel for Containers)?
Including Git with Cpanel was a step in the right direction as it's now de facto standard in modern web dev't. Containerization is the next best thing in web dev't and so is for CPanel!
The option to create, launch and backup docker containers from cPanel account will be awesome.
Obviously, there is a security risk, but I'm confident that it's possible to do the safe way.
Docker it's a must these days, and as a cPanel supporter, I'm forced by many companies to not use cPanel because they want Docker and no more.
The option to create, launch and backup docker containers from cPanel account will be awesome.
Obviously, there is a security risk, but I'm confident that it's possible to do the safe way.
Docker it's a must these days, and as a cPanel supporter, I'm forced by many companies to not use cPanel because they want Docker and no more.
Replies have been locked on this page!