cPanel & WHM Version 94 has been released, and brings a slew of great updates. Take a look at what is included, and then upgrade today!

Application Container Support

Shahrooz Bhopti shared this idea 7 years ago
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.

Best Answer
photo

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.

Comments (29)

photo
1

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.

photo
2

Docker is on the roadmap for RedHat + OpenStack as well: https://wiki.openstack.org/wiki/HypervisorSupportMatrix


Hope CPanel finds a way to play :)

photo
3

Check these benchmark's between KVM and Docker LXC:

http://bodenr.blogspot.com/2014/05/kvm-and-docker-lxc-benchmarking-with.html

Forward

  1. Linux

    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.

  2. 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.

  3. Before going any further, let me reiterate some of the major benefits of Linux Containers from a docker perspective:

  4. Fast
    1. Runtime performance at near bare metal speeds (typically 97+ percent or bare metal -- a few ticks shaven off for bean counters).
    2. Management operations (boot, stop, start, reboot, etc.) in seconds or milliseconds.

  5. Agile
    1. VM-like agility -- it's still "virtualization".
    2. Seamlessly

      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).

  6. Flexible
    1. Containerize a "system" (OS less the kernel).
    2. Containerize "application(s)".

  7. Lightweight
    1. Just enough Operating System (JeOS); include only what you need reducing image and container bloat.
    2. Minimal

      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.

  8. Inexpensive
    1. Open source -- free -- lower TCO.
    2. Supported with out-of-the-box modern Linux kernels.

  9. Ecosystem
    1. Growing in popularity -- just checkout the google trends for docker or LXC.
    2. Vibrant community and numerous 3rd party applications (1000s of prebuilt images on docker index and 100s of open source apps on github or other public sources).

  10. Cloudy
    1. Various Cloud management frameworks provide support for creating and managing Linux Containers -- including OpenStack my personal favorite.


Also, from http://stackoverflow.com/questions/16047306/how-is-docker-io-different-from-a-normal-virtual-machine


  1. Docker currently uses LinuX Containers

    (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.

  2. AuFS is a layered file system, so you can have a read only part, and a

    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.

  3. So let's say you have a container image that is 1GB in size. If you

    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.

  4. A full virtualized system gets its own set of resources allocated to

    it, and does minimal sharing. You get more isolation, but it is much

    heavier (requires more resources).

  5. With LXC you get less isolation, but they are more lightweight and

    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.

  6. A full virtualized system usually takes minutes to start, LXC containers take seconds, and sometimes even less than a second.
  7. There are pros and cons for each type of virtualized system. If you

    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.

  8. For more information, check out this set of blog posts which do a good job of explaining how LXC works.
  9. 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?

  10. Deploying a consistent production environment is easier said than

    done. Even if you use tools like chef and puppet, there are always OS

    updates and other things that change between hosts and environments.

  11. What docker does is it gives you the ability to snapshot the OS into a

    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.

  12. This is great for unit testing, lets say you have 1000 tests and they

    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.

  13. Edit: From comments...
  14. 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?

  15. Well, let's see if I can explain. You start with a base image, and

    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.

photo
2

Responding to Brian's comment above:

  1. 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.

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.

photo
2

    They have a note on their own site indicating:
  1. * 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/
  • photo
    1

    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.)

    photo
    3

    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..

    photo
    2

    richardh68 wrote:

    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..

    Your enthusiasm is noted :)


    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.

    photo
    2

    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.

    photo
    1

    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.

    photo
    1

    When CentOS 7 is taking a major stake of the installed base we might see some more exposure to docker.

    photo
    1

    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?

    photo
    1

    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

    photo
    1

    Docker is now in production!

    photo
    1

    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.

    photo
    1

    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.

    photo
    1

    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

    photo
    1

    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.

    photo
    1

    No it's just taking them longer than planed. CloudLinux have launched their website (.com) and I have been in contact with Igor and a member of their staff about this. They are not sure when they will be able to launch a public beta yet, there is a small chance that they will launch a non production ready alpha/beta version next month but no guarantees about an official launch date yet.

    photo
    photo
    1

    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 ?

    photo
    1

    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/

    photo
    2

    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.

    photo
    1

    From the security perspective, a first step could be to only use containers that don't services with root user. This would mean that the host would need to vet allowed containers instead of allowing customers to install their own containers.


    Doing this would make it useless for developement companies who want to keep their dévelopement stack and production stack identical. I believe CloudLinux used SELinux to make it more secure.


    Can SELinux solve all of the security concerns ?

    photo
    photo
    1

    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

    photo
    1

    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.

    photo
    1

    This may be of interest to everyone: https://github.com/cloudlinux/kuberdock-platform

    photo
    1

    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.

    photo
    1

    We're moving towards developing applications and even simple sites using Docker containers for 2 reasons:

    • dev/prod parity
    • not having to worry if the host can run it

    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!

    photo
    2

    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.

    Leave a Comment
     
    Attach a file