The new kernel features -- 'namespaces' and 'control groups' -- can meet our human need for a virtual machine, without the overhead of simulated machines or additional copies of an operating system.
A 'container' is a single process, which is apparently running on its own hardware. We used to do this with a 'jail' or 'sandbox', which you could access with chroot, improved by later tools and kernel patches. The term container arose with the new, better, standardized isolation, and software that easily moves these environments around.
The premier open-source management system for containers is Docker:
If you manage or build applications and services on Linux, and you want to save your work, you need Docker. Once you see what it does, you'll want it.
Let's look at using Docker for one application.
MediaWiki is produced by WikiMedia. You use MediaWiki everyday, because it's the free software behaind wikipedia.org.
The good people at Wikimedia created an experimental install script for a complete, running mediawiki docker deployment. It installs four interacting docker containers onto one machine -- with one line.
On a Ubuntu 15.10 server, you can type:
curl https://raw.githubusercontent.com/wikimedia/mediawiki-containers/master/mediawiki-containers | sudo bash
This is a bash script, with both install and stop/start services, within the github project wikimedia/mediawiki-containers. If you look at the file, which is called mediawiki-containers, you'll see it pulls four docker projects from the docker hub:
- tonistiigi/dnsdock
- mariadb
- wikimedia/mediawiki
- wikimedia/mediawiki-node-services
And then it builds 'images'. What are they?
An image is a docker project that can be built, so it can then be run, as a container.
The centerpiece of a docker project is the Dockerfile. It directs the construction of the image. It downloads resources to build the image. The images can be run as containers extremely quickly, because they are already built. If you try to 'docker run' a project that has not been built, docker will download the project and build it into an image for you.
If you want to modify a docker project, you might want to pull your changes forward, to the Dockerfile, as much as possible, or, in this case, perhaps to the mediawiki-containers service file (which gets installed in /srv/mediawiki-containers on your machine). Saving them in an image tends to get lost. It's nice to destroy containers when you stop them, and then run from a fresh image.
As an example: I needed LDAP in my docker mediawiki container. One way to do this is to modify PHP on the running image (adding php5-ldap).
# docker exec -it mediawiki bash
# docker commit -m "with my modification"
But that leaves you with unnecessarily large images to keep track of.
Why not pull the change forward to the Dockerfile? mediawiki-containers 'pulls' the docker project for mediawiki, whose github source can be found here:
https://github.com/wikimedia/mediawiki-docker
Download it (with git, or in a zip, whatever) and add to the docker file.
# cd
# wget https://github.com/wikimedia/mediawiki-docker/archive/master.zip
# apt-get update
# apt-get install unzip
# unzip master
# mv mediawiki-docker-master mediawiki
# cd mediawiki
# emacs Dockerfile
Added php5-ldap to the appropriate spot
# docker build -t greg/mediawiki .
# docker images
# cd /srv/mediawiki-containers/
# emacs mediawiki-containers
Changed run to greg/mediawiki
# service mediawiki-containers restart
# journalctl -f -u mediawiki-containers -n 0 | sed '/: Done in /q'
If you add phpinfo(); to your /srv/mediawiki-containers/data/mediawiki/LocalSettings.php file, for a moment, you'll notice that LDAP is enabled.
You now just need to configure the LocalSettings.php file to require the mediawiki LDAP extension and set wg values for your network.
