We’re starting to think about how end users will install Xibo 1.8 CMS.
It’s a bit more involved to install than older versions of Xibo as it requires some additional libraries that aren’t part of the standard Windows or Ubuntu PHP distribution, and also requires some custom rewriting rules for Apache.
One possible route we’re considering is Docker. It’s a container virtualisation system which would allow us to distribute the CMS and optionally the new XMR relay pre-packaged to ease setup. Docker has gained popularity in recent years with some high profile projects using it to great effect - among them is Discourse, the software the Community site runs. Infact the very post you’re reading has been served from a Docker container.
So our question for discussion is how do people feel about that? Would people welcome a Docker image (so you could download and run a Xibo CMS with a simple command like docker run xibo/cms:1.8.0)? Do we have any Docker gurus amongst us who would like to be involved with this if it went ahead?
Let me start by saying I have never used Docker, so I tried to read up on it on their website.
I can see how using something like Docker would ease installation for users, however, it would mean that to do so would add several additional layers of software just to run Xibo, which is more layers of complexity and more to go wrong. I question how this would affect machines already running other web services, along with mapping ports in firewalls. In addition Docker cannot run natively on windows:
“Because the Docker daemon uses Linux-specific kernel features, you can’t run Docker natively in Windows. Instead, you must use docker-machine to create and attach to a Docker VM on your machine. This VM hosts Docker for you on your Windows system.”
So this leads to educating users on how to check for and enable visualization on machines, and additional tech support problems and issues. Some of this would be offsetting the troubles users may have with .htaccess files and some of the other prerequisites.
If you are running a linux based system, it looks a bit easier to manage and install. Windows 10 is not yet supported.
For the users whom have grown accustom to modifying the CMS to fit their needs, how would this affect them? Would a non-docker version be avalilable?
Updated Question: How would future updates be applied, and how would one go about updating from an existing version?
So to be clear Docker would be an option. You could still download and install the CMS manually once you’d sorted out all the dependencies. If we went down the Docker route though it would probably become our preferred installation method though.
Yes it doesn’t support Windows 10 right now but I’m sure it will in short order. If you’re running Windows then the VT processor flag isn’t required. It will run better if it’s there, but it’s not a necessity, and in any case I personally don’t think you should be running a production system on a Windows 7 or 8 PC. On Windows server, you can run Docker with Hyper-V. See the MSDN docs on that here.
In terms of how upgrades happen, your data is held outside the container. To upgrade, you’d pull down the later image, link it to your existing database and library files and then when you hit the web interface you’d get the upgrade screen waiting for you. You could also set it up to link in an extra web-servable directory for people who want to serve extra files/scripts.
The problem I foresee is that there’s a growing number of people trying to install Xibo on an old PC they have kicking about who really don’t understand how a webserver works (and arguably why should they need to or want to!). They need support to find the php.ini file, and then need to be hand-held through uncommenting something. I don’t see how we can reasonably support them to make the complicated changes required to install additional modules, add custom rewriting rules. This would give them a 100% reproducible and working container that they don’t need to touch or configure that will have the CMS and XMR ready and working for them to use.
I’m open to other suggestions about how we can provide that by another means?
I’m interested in anything that will make it easier for the project to distribute what will only become a more complex Xibo as more requested features are added. Go for it. (On a side note, for some internal Docker projects we have reviewed portus at http://suse.github.io/Portus/ and found it fills some of the gaps in the Docker container management project nicely. YMMV. )
Having a command line installer which takes all important parameters would ease the creation of automated and repeatable installations, like we need it for Docker.
The 1.7.5 installation routine only works automatedly after I dumped the sql scheme and the settings.php after having it first installed manually.
Having the installation routine web based is great to guide “unexperienced” users.
Yet I doubt that a lot of unexperienced users will succeed with the installation of Xibo, at least of version 1.7.5, because you already demanded a lot dependency-wise: LibGD, Curl, Mcrypt set up, the right PHP version and so on.
The future is Docker and automation anyway I’m not sure if every managed web host offers every dependency and setup prerequisits you’re requiring. This will hinder you from widely spreading your software.
In the future (already now for some professional providers) you’ll be able to just define your container origin (like chimeradev/xibo), and have that installed on a remote server in seconds. But I know you’re pretty aware of this
So 1.8 doesn’t really need much more than 1.7 does, but you can optionally have push communication from the CMS to the Players, and that does bring a few new dependencies. That’s what we’d like Docker to automate.
Installing the database is pretty easy command line. No need to dump out SQL. When we get to working on this I can explain how it’s done in a few sql commands.
All the extensions we require now are available in the standard xampp build and most web hosts run it those too so I don’t anticipate there being a big hurdle to people installing it.
If you are looking for easy support/installs for customers, another option used by other projects is Bitnami. People interested can vote for Bitnami to build/maintain an easily deployable stack for Xibo here.
I have nothing against Docker, LXD and the others, but is there merit in maker the installer smarter? Mac OS X calls these meta packages (MPKG’s) which are basically installers for other bundled installers.
I also think there could be large section of users who’d like to download a disk image, burn and install. Not for windows clearly.
The problem is that the installer deals with installing Xibo not the stack it runs on. That stack can look very different depending on your needs so I think designing something that can do that cross platform is way out of scope for us.
If someone wanted to take on building a Mac installer that worked nicely and then committed to maintaining it then we’d love to hear from you.
Other than that something like Docker would let us give a reproducible (and therefore readily supportable) environment across lots of platforms so I think that’s the way we’re going to go.
As I said before it will be possible to install Xibo the old way but it will become trickier as the number of dependencies increases to support the feature set we need.
Hi All,
sorry for the question… which is the right php.ini to handle for customization inside the docker(s)? I find several php.ini in Vagrant machine… (I don’t know how docker is organized… )
If you are using our vagrantfile to boot a dev environment, then you have a bare Ubuntu box as the vagrant guest, which provisions 3 docker containers - web, db and xmr.
You can see these containers by running
docker ps -a
You can get into the containers by running
docker exec -it <container name> bash
To restart the container after making your changes, you can:
docker restart <<container name>>
The correct way to permanently change the container is either to fork the xibo-docker repository, explain the reason for the change and submit a PR. Or to build your own docker container, modify the vagrantfile to run that container instead.
I have found a way to allow access to the MySQL instance inside the docker. If you add the -p 3306:3306 to this line in the launcher file then once docker builds the containers and you run it will expose 3306 in Ubuntu giving you a way to acces the tables outside the container.
Dan, maybe you guys can update the master docker config and add that.
That is good investigation and detective work, however I am not sure we want to do that
We do actually do exactly that in our development Vagrantfile so that we can access MySQL over SSH during development, which is really useful.
However in production, one of the massive benefits of using Docker is that you don’t pollute the host machine with bits and pieces of the application that aren’t required. Imagine you were running more than one xibo-docker on the same box, or more likely more than one Dockerised application on the same box - if they all exposed their DB ports, there would be a conflict and only 1 could start.
It also means that the host machine has to have a mysql client - which again goes against the idea that the host shouldn’t have all those dependencies.
I suppose it could be added as an option - but given how easy it is to bash into the container itself - I am not sure again whether it is a good idea.
To access MySQL from inside the cms-web container:
now it takes me as little at 15 minutes to get docker and xibo 1.8.11 running…including stetting up new ubuntu, nginx,php,mariadb, phpmyadmin…i have observed a lot of xibo docker instructions which are very misleading…as a result, i am going to simplify installing xibo with docker and docker compose for you who have difficulty in setting it up…i have tested my steps over 20 times and i get docker and xibo up right away…i will put my steps in few days and that will help you install it in 15 minutes!
.
I’m not sure if every managed web host offers every dependency and setup prerequisits you’re requiring. This will hinder you from widely spreading your software.
)