Complaints about this Docker thing

Hello community,

Sorry for the temperature of this post but I wish to doescribe some frustrations related to this mandatory transition to Docker.

It was so easy and quick to upgrade Xibo cms in the past. Now it’s a real pain in the ass.

First of all, it’s very disapointing that “The CMS can be run without Docker, but this is not a supported configuration.” The correct way would have been to keep supporting both platforms, dockerized and manual in parrallel for a while, to keep transition smooth.

Second, the manual, transition steps are unclear and cluttery.
For example I took a fresh Ubuntu 16.04 and installed docker according to the instructions (let me point that the link to the instructions in the manual points to a generic page, one has to spend extra time finding his/her way to the proper distro-specific page selection).

Third, the deployment instructions assume an ideal world, where all things match perfect. No description on what to do on failure. docker-compose fails with a strange error, googling it turns out wrong version. Why? While all the instructions were completed step by step according to the documentation provided? Found a link to hack some binary from a website, replace it straight in the /usr/local/bin and pray it works… Command fails again because port 80 is in use by the previous installation, omg. Installation has a quick point on how to change port in the config, but turns out reading it again, that the launch command is different in that case. Replacing, running the command no success. Google againg - Oh I had to destroy some container first, re-run - still no luck. Oh, turns out again I have to first delete the shared folder, then all the way back…

And so on…

No documentation found how to set this thing to run at startup. What happens if the server has to reboot? How to recover from a power failure situation?

Also I see that adding this extra docker layer in between increases resources dramatically. Previously running a small apache+mysql+php was as easy as 1-2-3 and enough to deploy on small Atom-based thin client devices to server for a couple of player clients, now I need a full blown up server for anything. And using manual install is discouraged and not supported.

Where’s the tgz file for the manual installation of the CMS? I don’t see the usual directory structure as before. Are there any clear instructions to upgrade manually from 1.7.9 to 1.8.1, whithout this overcomplicated and useless dockerization?

Please keep the manual installation method as a supported deployment in the future.

Thank you and sorry again if I offended anyone.

It is not a mandatory transition. It is our recommendation, because, as most who have attempted it have found, the pre-requisites required to install the environment we need now are at the point where it is arduous to configure. As such, there’s a very high chance that people going down that route will hit issues with slight variations in their configuration. This has been 100% born out over the past few weeks.

I’m sorry you find it confusing. Lets look at it step by step. The instructions take you to the Install Docker page of the CMS manual (, which links you directly to this page:
Install Docker Engine | Docker Docs

The top table on that page links to detailed instructions for each distribution of Linux. It’s about 1 screen-full down.

Likely you’re using an old version of Docker Compose. Our install guide above links to you the releases page for the latest version, which explains in detail how to install it (and yes, that is as simple as downloading it to /usr/local/bin - no hoping required).

The Docker daemon starts automatically at boot, and the containers we provide start automatically unless you specifically modify them to prevent that.

Simply untrue. Docker containers have virtually zero overhead (when we’re talking about running on a Linux host). They run natively, on the same kernel as the host, simply utilizing the cgroups functionality in the kernel to ensure isolation, with no virtualization overhead.

Here’s a link to an excellent research paper from IBM on container overhead, in which their finding is that ‘Docker is nearly identical to Native performance’. Given the added security benefits (if the CMS were somehow compromised, then an attackers access is limited to the container only and not to your host machine) then I think it’s worthwhile.

Same place every single previous release we’ve put out on Github can be found:

The structure differs for very good reason. 1.8 CMS uses the Slim framework and adheres to various coding standards to improve security. Those include not putting third party library files in web-servable locations.

We do offer a basic overview in the manual. It’s broadly the same as it was before - with the exception that you’ll need to get the ZMQ PHP libraries installed, and change your webserver root to point to the web directory, rather than the root above.

We’re not going to prevent anyone doing that. All we’ve said is that if you hit issues with a custom installation, that because we don’t know the environment you’re using, we may not be able to offer you free support for it. I don’t think that’s unreasonable or unfair.

You’ve not offended me, but it has taken me some time to go through your message and address your points - most of which have already been discussed in the past few weeks. We’ve tried very hard to make the transition to Docker simple for people, because in the long run, a manual install will become increasingly difficult to maintain. I produced a step by step guide for Ubuntu 16.04 which again is linked from the manual. You could have followed that and not had any Googling to do!

Thanks Alex for your answers.
I think there should be a warning in the installation instructions to check for docker-compose version before attempting to run it. Also there should be some very basic tips on how to handle common errors which occur when changing port numbers in the config file (trasitioning to docker assumes that one is installing it on the same server as previous versions, so running into conflicting port 80 is guaranteed to happen. Think it with the mind of people who never used docker before!)
Also please add to the documentation your mention about containers starting at boot.

The manual is open for contributions just the same as the rest of the project. We’re happy to accept contributions in that respect.

Other issues I see:

  • how to install this completely offline? I have several CMS installs where there’s no internet access at all, I used to bring update files to the server via an USB stick before. How will this be handled in the dockerized world?
  • we purchased offline license-checking for Android clients, how’s the dockerized CMS handling those? How do I update such an install to a docked system?

As it stands, you’ll need to drop the offline licence pack in to the CMS container, and I’ll happy explain in a support ticket how to do that. Going forward, we are going to rework the offline licencing for 1.8 CMS so that it can just be dropped in the “custom” folder inside the CMS install (whether in Docker or not) and it will work. That will be available from the 1.8.2 release onwards.

Good that we’re talking about this, I’ll keep my systems back at 1.7.9 until this is done. Hope upgrading directly from 1.7.9 to 1.8.x will still be an option in the future.

As I’ve already explained, we have absolutely no intent of preventing people doing a custom install/upgrade if they wish.

I’d be happy to contribute to the manual, but unfortunately the knowledge is what I lack most.

This thread is an example of why I love Xibo. No customer, of any experience level, goes uncared-for. Thanks, Ale, for going the extra mile(s) and helping Robreg! Not only are you making him a loyal customer, you’re exemplifying the spirit of Xibo and impressing - I’m sure - many people.

1 Like

I had the same frustration when I started to work with 1.8.0 => LOL what’s this s**** ?
Then I did a lot of tests in a virtualized environment and the Docker installation shows its powerful features, now I dont’ want go back to previous installation method at all.
The problem is not of xibo itself, it’s of Docker…if Docker environment is installed correctly, Xibo installation will be performed literally flawless (I had only to replace the standard port with 8080 one).



I felt a little bit strange when, to use Xibo, I had to set up my first Docker environment. Then I followed the manual (with the additional one on a link at the end of the page in the manual), and it worked quite well.

I googled stuff, worked on it a bit…
And now I don’t do anything outside a docker container and have transitioned almost everything I use to docker containers.

It makes keeping stuff separate, up to date, transferable… so much easier.
And for reverse proxy, have a look at traefik!

So yep it is a bit demanding at first but way worth it. It’s the end of config and log files flying all over the place! Of binaries that end up god-knows-where-and-for-what-reason ! Of conflicts between versions of PHP and MySQL! With a single line you go from MariaDB to SQLite to MySQL… From PHP5 to PHP7… A crashed server goes back online and rebuilt in one command line!

My only cons are:

  • Docker-Compose YML syntax is a b**** . Put one space where it shouldn’t and everything breaks with unclear error messages.
  • Docker messes up with UFW, unless you go tell it not to touch iptables, which then creates other problems… So firewalling docker is no fun.

If load increases, ask docker to scale your package… put traefik in front of it and everything is automated from round robin to Let’s Encrypt certificates management.
And with swarm, clusters seem way more easily achievable than ever before.

So I’d actually thank Xibo for making me discover Docker!

1 Like