We now have official docker images for mageia !!

After some weeks working with the docker team we managed to get mageia as an official docker image (the ones that have the blue whale icon). You can find them at the docker hub, and if you want to contribute to them you can go to mageia’s docker brew project.

There are three images available:

  • Mageia 3
  • Mageia 4 (latest)
  • cauldron

Currently the cauldron image is outdated (probably more than a month), but I plan to automate the docker image update process so we can have an updated version at least once a week.

How to use these images

You can pull them on the command line (as root):
          # docker pull mageia:latest
          Pulling repository mageia
          147b6e8a8cbd: Download complete 
          511136ea3c5a: Download complete 
          e65cc271e617: Download complete 
          
          # docker start -ti –name mymageia_4 mageia:latest

Or create a Dockerfile file to build your own custom mageia-based image:

FROM mageia:4
MAINTAINER  “Foo Bar” 
CMD [ “bash” ]

All mageia docker images install the following packages:

  • basesystem-minimal
  • urpmi
  • locales
  • locales-en

Please test these images, and if you find any issues or have suggestions don’t forget to report them here. Also I’m thinking of adding some other custom images for specific applications and uses, like:

Ready to run server application-oriented containers

We could have several application oriented containers: mariaDB, nginx, wordpress, Apache+php/{cakephp,zend,codeigniter}, Apache+python/{django,codegears,flask}, tomcat preconfigured to use an apache container as front end, etc, the possibilities are endless. All these containers could be linked, packaged and orchestrated using fig for an easier application control and management.

Another example could be FPS game servers (Urban Terror,  OpenArena, Warsow, World of Padman, Smokin’ Guns), with their server package, some license-redistributable maps, a web admin panel, mumblebigbrotherbot (already working on a package) and anything else needed to have a kinda of “one click” game server setup. This could be very useful for example, to quickly launch game servers at a LAN party, or to provision game servers at a game hosting company.

Docker for distribution development

At the very least I see a couple of uses for docker within mageia development. First, as a quick and easy way to use iurt for local package building. We could have a custom docker image for package development that comes with a preconfigured iurt binary, package build tools like bm, rpmbuild, rpmlint, mgarepo, etc, all preinstalled, this could be a build/packaging environment with one command:

          # docker pull mageia:devenv
          Pulling image…
          # docker run –rm -ti –name mageia_dev -v /home/juancho/iurt:/opt/iurt/ mageia:devenv iurt SRPMS/foo-1.0-1mga5.src.rpm

That command would launch a docker container using our custom development image, launch iurt to build a source package, leave the binary packages in /home/juancho/iurt/RPMS/{i586,x86_64,noarch} and delete it self when it finishes. This is a clean way to locally build packages in a fresh environment. Remove the –rm parameter if you want to use the container later, for example to work on package version updates:

          # docker run -ti –name mageia_dev -v /home/juancho/.ssh:/home/juancho/.ssh -v /home/juancho/iurt:/opt/iurt/ mageia:devenv bash
       
Also by mapping your .ssh directory to a docker volume, mgarepo can be used within the container.

The other important use for docker within mageia could be to help with QA testing. The reproducible nature of docker makes it very interesting from a QA point of view, the repeatability of tests could be of great help for application testing and bug triaging.

We could teach bug reporters how to create their own images or write their own Dockerfiles with the needed packages and configuration changes to reproduce a bug. The reporter would point QA back to an image that they can download and test (for example, from our own docker repository). The creation of those containers could ease and speed the testing process. As these custom images would be based on our official images, there wouldn’t be the need for QA to setup the same test case to reproduce the bug in another environment, the reporter image should be enough for them to test and validate it. In some way, we could be making the bug reporters also contribute the test case.

Docker application containers

What about preconfigured docker containers for software development environments, like images that have Netbeans/Eclipse for python/java/php, git/mercurial/svn/bazaar, any development libs and tools needed depending on the platform, etc, all preinstalled and preconfigured. This could be a good idea as sometimes these tools are difficult to install and update, having these ready to use containers could be cool. Probably it also could be used to package nonfree applications or 32bits applications on x86_64.

I don’t know, there are many ideas that come to my mind about stuff that can be done with docker in different areas, like these ones on linux distribution development and such.