Docker support in Proxmox

The value is having a single GUI/Management tool to control all your virtualization stack. Openstack is kind of doing this...

It would be, except as described Proxmox doesnt actually do this. You cannot task, track, or control docker instances through the GUI or the Proxmox API.

It would completely dominate the market as it can manage all 3 type of platforms.
Not so fast. Proxmox does KVM VERY well, but its LXC support has a huge hole in it- namely lack of failover capability. Having a working container is kind of important regardless of a pretty gui and uniform api access.

Container virtualization will never replace a hypervisor since a container is dependent of the host kernel therefore you will never be able to run a container which is independent of the host platform.
That would be true as long as customers run applications dependent on kernel version. While SOME applications will retain the need for this, many (and growing) applications are already being designed to be operating in a fairly generic container environment. Perhaps it would be more accurate to say that hypervisors will always have applications that containers cant replace- the key difference being that hypervisors will solve edge cases and not the other way around.[/quote]
 
That would be true as long as customers run applications dependent on kernel version. While SOME applications will retain the need for this, many (and growing) applications are already being designed to be operating in a fairly generic container environment. Perhaps it would be more accurate to say that hypervisors will always have applications that containers cant replace- the key difference being that hypervisors will solve edge cases and not the other way around.
You missed my point. Docker is para virtualization which means the docker instance uses the host's kernel therefore cross platform is not supported.

Another side note to the difference between LXC and docker. LXC is PAAS while docker is SAAS. Two completely different usecases.
 
  • Like
Reactions: xr09
I thought I understood what you meant, but maybe I dont. From my point of view, there is no (or very little) value to cross platform support; can you describe a scenario where this is a problem?
Lets say you want to run a Windows Exchange Server in your company. How would that be possible within a docker instance on a Linux server?
 
Alexskysilk:

we are looking for an easy to use learn and use docker administration tool to test.

Could you suggest some to consider? I look at that software as a stand alone system to run in a KVM. Here freepbx/asterisk with 10,000+ phone calls a week using automatic call distribution [zcd] do great in a kvm running on proxmox. we use kvm as the high availability system we use is not yet tested with lxc . lxc and kvm are hosts for docker not proxmox.

We intend to use docker running in kvm using napp-it/omnios iscsi storage with the KVM made highly available using proxmox , and could use the info.
 
Lets say you want to run a Windows Exchange Server in your company. How would that be possible within a docker instance on a Linux server?
Docker isnt a solution to EVERY problem. it cant be, and it isnt designed to be. It is a very efficient method to solve specific problems. It is also not mutually exclusive to heterogeneous applications; there's nothing stopping you from running exchange on your windows based metal or vm(s) and run docker instances in the same data center. I had taken your point to be that your docker instances should be portable to a different ISAs. My point is that more and more applications are being solved with docker then by "traditional" means, and enjoying the benefit of more efficient use of resources, super easy deployment, etc- not that it solves all problems.

Rob Fantini said:
we are looking for an easy to use learn and use docker administration tool to test.
That is too much of an open ended question. kubernetes is the de-facto orchestration tool for Docker, but depending on what you're trying to accomplish you should be looking at building your own tools using ansible or chef (or salt or puppet or your preferred platform) As for learning- hell if I know, I just read and hope I'm doing it right ;)
 
The nice thing about having a forum conversation is that anything we write is available for all to peruse and refer to at will. if you want to quote me, feel free to do so, you dont need to invent quotes for me. I hope that if you read what I wrote and not what you imagine I did, any perceived conflict in my point may be resolved.
 
What made ProxMox the best choice for virtualization historically was comparing containerization and full virtualization on the same platform. Now there is a new form of a virtualization
 
  • Like
Reactions: dlasher and pipapo
Completely agree with @mir, Proxmox doesn't need native Docker support, this is PaaS not SaaS. If the team decided to chase the Docker whale there would be no time for KVM/LXC based development, Docker evolves really fast these days and it seems is replacing every other project based on it.

What do you gain from using Docker on top of Proxmox?

The same you gain from running anything on Proxmox, another layer of indirection (a great one btw), backups, snapshots, migrations, you name it.
 
Just want to say that this is a great conversation and taught me a lot about why i'm having issues with Docker within Proxmox. I'm just looking to learn more about Docker, since as you all say it is becoming a HUGE technology.

Since i'm running this in a homelab the overhead of a VM isn't that big of a deal to me, but it WOULD be awesome if we could get docker support in CTs. I'm not extremely knowledgeable regarding proxmox, but that seems like it shouldn't be a huge leap forward or take a lot of time to implement.
 
support has a huge hole in it- namely lack of failover capability

That is simply not true! Our HA manager is quite capable of managing LXC containers and thus failover IS available.
If a node fails the containers managed by HA will be recover it to another node.

You probably meant live migration of container, which is a completely other thing (not failover).

Further docker has no advantage over LXC in its functionality, on contrary LXC can do a super set of the functions docker can (i.e. full system virtualization). Both have another purpose, as other have said in this thread already.
And full system virtualization is what Proxmox VE is made for, adding docker and wanting to control them is like trying to eat a soup with a fork, you certainly can try it, if it makes sense is another question.

Oh, and with our appliance builders for Debian and Arch Linux (and I made a hacky one for Alpine Linux, needs cleanup) you can build and prepare appliance images which can easily be configured to run just a specialized task
(doing "SaaS" similar stuff). E.g. I made some lightweight (few MB big) images which spin up and execute some load test or serve a page through nginx which help me testing in development.
Just my personal opinion and perception on this (saw this thread just now).
 
Oh, and with our appliance builders for Debian and Arch Linux (and I made a hacky one for Alpine Linux, needs cleanup) you can build and prepare appliance images which can easily be configured to run just a specialized task
(doing "SaaS" similar stuff). E.g. I made some lightweight (few MB big) images which spin up and execute some load test or serve a page through nginx which help me testing in development.

Anymore info on how you did this? Would be awesome if we could spin up NGINX, LDAP, etc systems that have been custom made. Is there documentation on that?
 
Anymore info on how you did this? Would be awesome if we could spin up NGINX, LDAP, etc systems that have been custom made. Is there documentation on that?

Please create a new thread for this new topic!
 
Anymore info on how you did this? Would be awesome if we could spin up NGINX, LDAP, etc systems that have been custom made. Is there documentation on that?

Just that not others reply this thread just for asking docu: https://pve.proxmox.com/wiki/Debian_Appliance_Builder
The concept is rather really easy, but the wiki page lets it seem more complicated then it is (I'll try to find some time changing that).
Install dab (Debian) or aab (Arch Linux), there available in the proxmox repo and also installable on a normal Debian/Ubuntu, but as they are mostly perl/Makefile scripts they are quite independent of Distro.
Basically you need a simple config file telling the appliance builder which version, architecture and "flavor" (e.g. ubuntu or debian) of the distro to use for your speciic template.

Then
Code:
dab init
dab bootstrap
now a basic quite minimal container is setup

You can now install packages in the container, and then enter it to make configurations from inside of the container.
Code:
dab install packages..
# for example for nginx
dab install nginx

# now enter and change some stuff there:
dab enter
$ ....
$ exit # to exit the container again

You can do a lot changes also from thh outside, the root mount point of the CT is in the rootfs directory.

And the end you do:
Code:
dab finalize

This produces then a compressed image file which you may use as a container template in Proxmox VE (or as a chroot target, or for using it with plain LXC).
(Note you can use the aab just like the dab, accepts the same commands)

Sorry for the off topic post, just wanted to sum up our appliance builders which are not that known, as it seems.
 
  • Like
Reactions: lastb0isct
So just want to add my opinion on this. I work for a large consultancy that mostly is full of developers where I'm from an ops background.

As I see it a lot of development as others have said is starting to go along the docker route. Especially for certain tasks. As an example take a front end / back end web site. The back end is likely still traditional SQL of some sort but the front end could be throw away containers that scale up and down as demand requires. The lack of HA / live migration is a mute point because those containers don't contain any data you require. You say have 4 hosts to run this and if one of the hosts fails the other 3 just fire up 1/3 more containers each to cover the current load. Assuming you've specified the hardware to the normal N+1 you've no issues here at all.

At the minute I don't see it as a one size fits all but you cannot ignore docker. I do accept that adding this is likely not a small task for the Proxmox developers and they are focused on the solution they have which is excellent. I do still hope they consider adding it even in a basic form for throw away docker containers. After all VMware and Microsoft are adding this functionality to their platforms, Openstack is also branching out into containers. Sooner or later it might be not having this functionality in Proxmox will hurt.

DAB's great by the way. Developers though are writing dockerfiles so it's kind of becoming a industry standard.
 
So just want to add my opinion on this. I work for a large consultancy that mostly is full of developers where I'm from an ops background.

As I see it a lot of development as others have said is starting to go along the docker route. Especially for certain tasks. As an example take a front end / back end web site. The back end is likely still traditional SQL of some sort but the front end could be throw away containers that scale up and down as demand requires.

I don't see that really as an pro docker argument or as PVE *needs* Docker as you can do this exactly also with LXC?
I can generate my template, start 10 of those, add another few, stop a few... Let them provide services at the current need. The thing really missing for your case is a orchestration tool, which handles that automatically (or as automatically as possible).
Just adding the function to start stop docker container wont bring such a tool to PVE, and if adding one I would prefer to do it with LXC (and VMs) as a) those are a super set of docker (AFAIK) as there the functionality is there and b) this is our CT technology, managing and updating two of them does not makes sense, causes more work and IMO its better to ensure that one works good and the problems with it gets fixed.

The lack of HA / live migration is a mute point because those containers don't contain any data you require. You say have 4 hosts to run this and if one of the hosts fails the other 3 just fire up 1/3 more containers each to cover the current load. Assuming you've specified the hardware to the normal N+1 you've no issues here at all.

Your describing exactly HA fail over here (or at least one way to do it, there are more), If a node fails this is exactly what our manager does, restart the Services distributed on all other nodes, so it seems we can do this already :)
You (in you as someone who wants to provide any service, which then should be reliable to be taken seroius) want HA, its not a mute point IMO. :)

At the minute I don't see it as a one size fits all but you cannot ignore docker. I do accept that adding this is likely not a small task for the Proxmox developers and they are focused on the solution they have which is excellent. I do still hope they consider adding it even in a basic form for throw away docker containers. After all VMware and Microsoft are adding this functionality to their platforms, Openstack is also branching out into containers. Sooner or later it might be not having this functionality in Proxmox will hurt.

Proxmox VE have since ever "branched out in containers", as it contained an ecosystem for container tools since the start of the project.
If you forget the (current) hype about Docker itself and reduce it to its functionality I do not think people really miss out using LXC for containerization, with the technology itself.

DAB's great by the way. Developers though are writing dockerfiles so it's kind of becoming a industry standard.

But a service provider always will have to generate its own images, or configure them, and thus using a tool and they have such a short training period that it shouldn't quite matter.
DAB produces also technology independent image files (i.e. a rootfs), you can run them with LXC, chroot in them, put them on a bare metal machine (install a kernel for that though), ...

So I, personally, would say the container technology LXC can do the stuff, adding another one does not bring value by itself. We should rather think of doing something with the ecosystem, e.g. in the direction of orchestration as this is where the "docker universe" shines more at the moment and this could actually bring real value towards PVE more easily then trying to fit all of the Docker ecosystem in it by puttings a lot of man hours in that and the result in the end that you do not really can do more now. This is my opinion on the topic.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!