Thursday, 13 July 2017

oVirt Documentation: Starting from Square One

Two days ago, I had to start from scratch. Not because my machine crashed or some libraries simply refused cooperate, giving each other that special form of evil eyes that means everything changed but it just has to remain the same. I started from scratch because I discovered that my initial budget of 30GB worth of space was just not going to cut it for what I wanted to do. I had stumbled upon two facts regarding Docker containers: one, disk space should not be a problem for you, and two, bandwidth should not be a problem for you. The second I was prepared for, the first I had not anticipated. 

You see, one of the first Docker images I had pulled was PostgreSQL. Hardly large, less than 300MB. So that had more or less set the tone for what I thought I was to expect from Docker images. Alas, that has not proved to be the case. As part of my work, I was to get images for Ceph (ceph/daemon), Gluster (gluster/glusterfs), FreeIPA (freeipa-server/freeipa-container), and ManageIQ (manageiq/manageiq). 

Why were the images much larger? Well the idea is that a Docker container be self-sufficient. So in your Dockerfile (the file that specifies what your image and thus what your container will have) you need to specify everything that the container will need to run the application as comfortably as possible, without anyone, anywhere worrying about things going wrong. Of course the images from which we derive the containers do not have graphical environments; what makes them large is how much software is required. And if you need libraries upon libraries of stuff, then... You get the idea. 

It wasn't such a bad thing to start afresh though; I got to install the correct version of Docker for CentOS. One of the challenges of using Linux distributions that are made for use on servers (Debian, Ubuntu, CentOS and the rest of the Enterprise Linux family) is that frequently when you just type in `apt install <package>` or `yum install <package>`, you end up with a legacy package rather than the new version. So on CentOS, the package `docker` refers to Docker from back in the day. Its re-branded self is now split up into two versions: Docker CE `docker-ce` (community edition) and Docker EE `docker-ee` (enterprise editon). Something I figured out in a rather roundabout way the first time around. 

So far, I've pulled all my images and updated all my stuff. What comes next? Fitting it all together. My plan is to start with PostgreSQL. As I go along, I hope to explain how each of the containers I'll be running fits with oVirt. 

Cheers and thanks for stopping by!

Saturday, 1 July 2017

Working with Open Source Projects: oVirt Documentation

So from now until the end of August I'll be working on documentation for oVirt. In particular I'll be documenting how to use containers with oVirt. Here we go...

What are containers?
 
Indeed, what are containers? One analogy I could use is food and how we carry it. When eating food, we use utensils to eat, namely forks, knives, and plates. When we're at home, we have access to these very easily. It is when we decide to pack food for a journey that we have to decide what to carry on the basis of ease and comfort. So we get a bag that will carry the disk containing the food as well as the tools we will use to eat (forks, knives, and/or spoons). A container in tech terms, is a lot like the bag; it carries the application (food) and the environment it needs (the forks, knives and/or spoons). 
Containers are used most commonly with Docker and that's what I'll be using as I work on the documentation. Docker is available for Linux, MacOS and Windows. Depending on your version of MacOS or Windows, you may use boot2docker or you shall be able to run Docker natively, without any intermediaries. As far as I know, Docker from its initial stages has always been run natively on Linux, so your installation should relatively painless on this platform. A note regarding running Docker (and by extension containers) on Linux: you need elevated privileges. So either you run Docker using sudo or you add your normal user to the docker group. Docker containers are setup by running docker pull <image-name> and docker run <container-name>.

What is Docker?

I’ve mentioned images in the last paragraph without saying how it all fits together. The idea about containers is that they are self-sufficient, like our food container with utensils in my-not-so-very-good example above. Containers in Docker are formed by utilizing a Docker image, which in turn uses a Dockerfile (yes, apparently convention dictates that I spell that as one word. Not my fault :D).

A Dockerfile is saved as `Dockerfile` and basically contains instructions on how to build a Docker image. A Docker image contains whatever the Dockerfile specifies it should have. Usually this includes an operating system, some software libraries necessary for the application inside the image to run and the application itself. The container I was talking about earlier is an instance of the image. Now I didn’t have to actually make a Docker image myself because my use case is covered by the images at Docker Hub (link here). A Google search for ‘<application-name> + container’ should point you in the direction of where you can find Dockerfiles and images to build a container of your choosing. Docker has some excellent documentation on how to build your own Docker image using a Dockerfile and they have an example using PostgreSQL that is well worth looking at. 

What is oVirt?

oVirt is an open source project started by Red Hat. Red Hat is well known as being behind Red Hat Enterprise Linux, a distribution of Linux that is used in organizations that want to use Linux and have professional support doing it. It also supports Fedora, which is another Linux distribution on which Red Hat Enterprise Linux (RHEL for short) is based. Fedora is more bleeding-edge; RHEL is stable and has well tested features. 

What will I be doing exactly?

PostgreSQL, Gluster, Ceph, OpenStack, Glance/Cinder/Neutron, ManageIQ, and FreeIPA. These are all software that can used alongside oVirt or are actually dependencies of oVirt (PostgreSQL and Gluster fall into this category). The challenge here is that when developers create applications, these applications have conflicts that aren’t easily resolved. Deploying them on separate machines and then linking them is one option, but we would want a solution where they can all be deployed on one machine. Which is where containers come in. A container frees us from dependency hell (a situation where different software applications require libraries that are incompatible with each other and thus cannot co-exist on the same operating system) since containers are isolated from one another as separate processes and are only linked to access a service provided by that container e.g. PostgreSQL’s database.

My job will be to document how this can be done without too much head scratching and hair pulling.

My next post shall be about getting the PostgreSQL container to work with oVirt.

Cheers!