Support for XO in docker container

olivierlambert

But to run it where? Not in the dom0 I hope? (remember: dom0 is already a VM)

For isolation, a VM is better than a container. And no, we don't provide XOA in a container. Because we'll depend on people having their own VM in the end, which defeats the purpose on using just a container.

d1rtym0nk3y

I think you misunderstood my meaning, who would run docker on Dom0!
No, we run kubernetes on VM's. So XO would be deployed as a workload inside kubernetes

I don't agree that it defeats the purpose. XO is managing hosts & guest VM's but it doesn't need to be in a VM.. it can be deployed on bare metal, or my laptop... its just an application.

However it seems like you're not really open to it as a possibility which is a shame.

olivierlambert

I think you misunderstood my meaning, who would run docker on Dom0!

More people than you can imagine

Anyway, I get your point, it could make sense. I'm not entirely closed to the possibility, it's just it will be harder to make support on that if we don't know where it runs.

Distribute it as XCP-ng VM is a good thing to avoid bad surprises on where it runs. So it's a matter to see the cost of supporting that (more than the cost of doing it, which isn't high itself).

mlustosa

I vote in favor of maintaining a docker version of Xen Orchestra. The advantage of using container instead of VM is the ease of migration and scalability of the microservice. You can also upload several services in a single VM (and securely isolate them all). It will save processing and you can even easily replicate these containers via Docker Swarm or Kubernetes.

I'm using my own image where I work and uploading modifications to the original repository, cited by the @d1rtym0nk3y.
I am managing two pools, totaling 50 VMs. My total processing with the containers:

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
de7b8a1e6979        xo_server           0.00%               170.5MiB / 9.754GiB   1.71%               11.4GB / 2.95GB     0B / 0B             21
535a11147093        xo_redis            0.33%               11.46MiB / 9.754GiB   0.11%               63.8MB / 224MB      0B / 0B             6

The VM is consuming only 400MB of RAM.

I also experimented with Xen Ochestra installations using an entire Debian VM and the initial installation alone consumed much more than that.

I also already commit to sending updates and contributing with what I've already done in my repository if the XCP-ng team (@olivierlambert and others...) creates a folder in the official repository or a new Xen Orchestra repository as a container.

thisisbenwoo

Check this git repo out: https://github.com/ronivay/XenOrchestraInstallerUpdater

This person has created a Dockerized CE version. I am not associated with this person, nor have I tested it. However, I did use his installation script, and it worked like a charm.

Good luck

olivierlambert

The most popular container is https://hub.docker.com/r/ezka77/xen-orchestra-ce

(2.4M downloads)

But it's not officially supported and you don't have an updater and all XOA features

mlustosa

@olivierlambert Aren't we talking about XO? If so, a docker image compiled from sources will never have all the features of the XOA (paid appliance), correct?

olivierlambert

That's correct. For now, you have no way to do exactly an XOA like we do but in Docker.

To be fair, this is the first time someone asked for it…

mlustosa

@olivierlambert said in Support for XO in docker container:

The most popular container is https://hub.docker.com/r/ezka77/xen-orchestra-ce

(2.4M downloads)

But it's not officially supported and you don't have an updater and all XOA features

Just to clarify the issue of updates. The good practice of working with Docker recommends that you maintain an "immutable infrastructure" when uploading a container (with docker-compose.yaml or sudo docker run ...). This means that after the images are created, it does not make sense to keep changing the container, write inside it, or replace processes at the time of its execution. Containers are designed to be ephemeral microservices and must be treated as such (and not as a VM). Briefly, the steps to create and update a microservice are:

Build a local image;
Run the container (replacing environment variables at the time of execution, such as passwords and volume locations)
(an update has been made to the official xen ochestra repository here)
Recreate the previously generated image (step 1) keeping tags or not;
Run the container again from the new image;

That is, it is not interesting to keep altering or making major modifications to a container, because if the image is not updated with these modifications, if the container is deleted or lost, everything you will have done will be lost.

olivierlambert

Yeah so it will require even more work to have a different updater for this specific use case

XO community isn't the same as XOA users. XOA users just want something that works, period (and something that's tested in a controlled environment, also a way for us to access remotely the app, and other feature that makes sense in a VM but probably not in a micro architecture world). XOA users are people that make possible the project because they are paying for it (and support).

In conclusion, I think you might convinced me to NOT do that: it won't be cheap and it will require some work where there's 0 traction currently. I insist: there's 0 XOA customer who asked for that. Nor suggested that. We are always adapting our offer to the customer needs. It's just that doesn't exist for now.

If the situation changes (or there's valid argument to make XOA working as a microservice) I'm all ears

edit: have you already used XOA and tested release channels, support tunnel etc? that sounds a bit difficult to do it for "on premise" customers with microservices. Remember, we aren't a SaaS editor: we need something that just works for everyone the easiest way. If we build a complete new/extra process (microservice) just for one person, it will be clearly a waste of time/money/efforts.

Thanks for pointing more in details the differences with our current process The gap is even bigger that I have imagined

mlustosa

I am quite surprised by your comment.

I thought I was in a forum where we discussed since the implementation of XOA as well as XO (compiled from the sources). You may even want to differentiate the community from paying and non-paying, but it certainly hurts the collaboration principle of the project that I got involved in and I still try to contribute (XCP-ng and XO), as ex and still xenserver user.

I didn't talk about XOA users here, I just reported my experience with docker containers and how this option would work very well in as step-to-step in install from sources and not to replace the installation and easy management of XOA as a whole.

I know that everyone needs money and that enabling new features, fixing bugs and maintaining the tool is expensive in men/hour, but disregarding a community user who believes in this project (like me) for the simple fact of not paying brings the idea that you don't care and not listen to the community.

Again, is this forum only for XOA users? Where i can improvement proposals be suggests? Here on the forum or on the official git respository?

This recalled the end that XenServer (opensource) had...

olivierlambert

No, this forum is for everyone, I don't understand why are you surprised? I'm not against any Docker initiative (hence the number of projects you might find).

On my side, I was just talking about XOA, which is the commercial turnkey product. I never held up anyone to do whatever they want with Xen Orchestra, so I don't know where is the problem for you?

XOA is distributed by Vates and it's the only officially supported way to get pro support from the main software editor.

So I care about the community (and all the feature we worked hard for years we are giving for free prove that) and as I said, I never held up people to do whatever they want to Xen Orchestra, but we aren't talking about Xen Orchestra here. We are talking about the final enterprise product, XOA. XOA is not a community project itself, sorry if it's not clear, but nobody ever contributed to XOA itself and nobody asked to do that so far.

Again, I don't see the issue?

And I don't really get your point in the end. What do you want to achieve that you can't with the source version?

edit: also I don't really like the way you are suggesting we don't care about the community despite the immense work we did for everyone, paid or not.

So please be clear about your point

edit 2: my point is simple. I don't see the why I would develop another way to distribute XOA than using a VM. It's simple, works well and the process is streamlined. If tomorrow, I have multiple XOA users asking for XO distributed in a container, then I'll probably start to put some devs on it. On your side, if you want to create your own XO turnkey "distro" working in Docker, go ahead, it's fine

mlustosa

@d1rtym0nk3y said in Support for XO in docker container:

Is there likely to be any official support for running XO in a containerised environment in the near future?

So, from there I made my contribution to the benefits of using XO as a container.

After that you came to talk about XOA and that it would be a feature that wouldn't be worth it (financially) to implement. My surprise was when I did that.

One question: Can I, as a community user, open a Pull Request in the official git repository containing Docker files (dockerfiles and docker-compose and scripts) to be used as a complementary installation to the traditional method via VM?

olivierlambert

Feedback is always welcome
We don't want to have any special way to distribute XO from the sources. You can always pull it from your own Docker (or whatever technology! there's plenty! Containers with LXD, K8S, Mesos, or with automation with Ansible, Terraform or whatever automation tool), or anything else (a physical host, a VM, inside VMware, HyperV, CentOS, Raspbian on a Raspberry Pi)

In short, we want to stay agnostic on XO sources. You can build whatever you want around it.

Also, maybe you missed it, but in our doc on install XO from the sources, we never talk at all about using it in a VM (see https://xen-orchestra.com/docs/installation.html#from-the-sources ).

So there's absolutely no reason to push people to use it with a specific solution. XO is an app that you can run anywhere as long you have Node and Redis available.

I still don't get what do you want to do that you can't already.

mlustosa

@olivierlambert said in Support for XO in docker container:

Feedback is always welcome

In short, we want to stay agnostic on XO sources. You can build whatever you want around it.

It was all I needed to know right after my initial suggestion.

I already use XO from sources with Docker, I have no difficulty in that and i'm grateful for this fantastic tool to exist. As I said, everything I said earlier are suggestions for new users.

But I understand your point now.

stormi

@mlustosa said in Support for XO in docker container:

After that you came to talk about XOA and that it would be a feature that wouldn't be worth it (financially) to implement. My surprise was when I did that.

The original poster in this thread was talking about official support for containers for paid users. It is the main topic of this thread, so it's logical that Olivier discussed container support for the commercial product.

neoweb

With the rise of DevOps, and microservices, has there been an increased asked of admins for 'vendor supported' microservice solutions?

olivierlambert

We are investigating an elegant solution called RunX. Basically, it might be able to transparently any standard "container stack" (Docker and/or k8s).

See https://www.youtube.com/watch?v=9m95hojMtsU

There's some work to adapt that to XAPI, but it might be doable. This means XCP-ng could be "container" native while having very good level of isolation with very small VMs (only few MiB overhead).