Over the past several weeks, teams within the CentOS and Fedora projects have been establishing the processes needed to produce “Atomic Host” variants of their respective distributions. If you haven’t already done so, you can check out the latest pre-release Fedora Atomic and CentOS Atomic images.
Now, consuming an OS that partakes in the hotness of atomic system and application management while consisting of pre-built packages from a distribution you already know and trust is the point of Project Atomic, but you still might want to take the reins and produce your own Atomic updates or add new RPMs of your choosing.
If so, you can, without too much trouble, compose and host your own updated or changed atomic updates right from your Atomic host, or from any other sort of Docker host. Here’s how that works:
Last week, version 3.5 of oVirt, the open source virtualization management system, hit FTP mirrors sporting a slate of fixes and enhancements, including a new-look user interface, and support for using CentOS 7 machines as virtualization hosts.
As with every new oVirt release, I’m here to suggest a path to getting up and running with the project on single server, with an option for expanding to additional machines in the future.
I’ve tried out a lot of different software applications in my time, so I’ve come to appreciate projects and products that make it easy to get up and running quickly and without the need for assembling a whole labful of equipment.
In this vein, the various components that comprise oVirt, the open source virtualization management project, can be piled onto a single piece of hardware in form that works well enough to credibly kick the project’s tires.
Well, mostly. In order to really get your oVirt on, you need to hook up a directory service of some sort. FreeIPA is an obvious choice to provide oVirt with directory services, but due to conflicts between their package sets, oVirt’s management engine can’t be installed on the same host as FreeIPA.
Sounds like a job for Docker, right?
Welcome to the inaugural edition of Boxes of Boxes, a bi-monthly virtualization, containerization, and turduckenization column. Given the title and subject matter of this column, and the fact that version 3.14 of GNOME desktop environment has recently shipped, I decided to take a look at the project’s built-in application for running virtual machines: GNOME Boxes. I took GNOME Boxes for a spin on Fedora 21 alpha, which also shipped recently, sporting GNOME 3.14 as its default desktop environment.
The GNOME 3.14 release notes point to support for Debian as a newly added “express installation” target for GNOME Boxes, so I started off by pointing the app at a Debian Wheezy installation ISO I’d downloaded. The express installation feature suggests a set of sane defaults for virtual disk size and for VM memory, asks for a password, and promptly chefs up a fresh VM instance, and the feature worked as expected with the installation I’d kicked off.
Dockermania has been running wild, and it seems as though there’s an advocate for swapping in the containerization technology wherever we once turned to virtual machines. While Docker won’t (yet) fit the bill in all of these cases, containers are great for trying out new or updated Web applications on your local machine.
When compared to dynamic sites based on WordPress or Drupal, staticly generated blog and Web sites (like this one) can go a long way toward simplifying deployment and maintenance. There’s no database or server-side code to maintain, and, when paired with a service like Github or Gitlab, you can accept posts or other contributions from anyone, via pull request.
However, while simplifying certain areas, static sites introduce a bit more complexity in other areas. Among the handful of Middleman-based static sites that our team at Red Hat help maintain, we’ve seen the specter of “it works on my laptop” arise.
When Project Atomic got off the ground in April, I wrote a blog post about how anyone could Build Your Own Atomic host, based on Fedora 20. Since that time, there have been some changes in the rpm-ostree tooling used to produce these images.
What’s more, there’s a new distro on the block, CentOS 7, that you may wish to build into an Atomic host. Part of what’s great about the Atomic model is the way it can apply to different distributions. Here’s our chance to play with that.
oVirt’s Hosted Engine feature, introduced in the project’s 3.4 release, enables the open source virtualization system to host its own management server, which means one fewer required machine, and more self-sufficiency for your oVirt installation.
While a self-sufficient oVirt installation has been achievable for some time using the project’s “All-in-One” method of running an oVirt virtualization host and management server together on one machine, the Hosted Engine feature allows multiple machines to partake in the hosting duties, eliminating any one host as a single point of failure.
The Hosted Engine feature relies on NFS storage to house the management VM. Running an NFS server on one of our virtualization hosts would make that host a new single point of failure, which means we need either to tap an external NFS filer (the approach I took in the walkthrough I posted here recently) or we need to figure out how to make our oVirt hosts serve up their own, replicated NFS storage.
In this post, I’m going to walk through that latter option – setting up a pair of CentOS 6 machines to serve as oVirt virtualization hosts that together provide the NFS storage required for the Hosted Engine feature, using Gluster for this replicated storage and for NFS and CTDB to provide a virtual IP address mount point for the storage.
The application as shipping container metaphor behind the Docker project’s name and logo paints an attractive picture for developers: spawn a container on your local machine, fill it with code, and then ship it off to your far-flung users.
While the app is where the action happens, I can’t help but wonder what sort of ships await our containers when they arrive at the dock. No matter how well you’ve crafted or carefully you’ve packed your cargo, your application will only make it as far as its ship can take it.
Maybe the best thing about Project Atomic is the way it addressess both the shipping container and the ship itself, the former with Docker, and the latter with an intriguing (if less catchily-named) project called rpm-ostree.
We can use rpm-ostree to take a set of packages from one of our friendly neighborhood RPM-based Linux distributions, assemble it into a “just-enough” OS image, and then deploy and manage hosts based on that image in a manner that more closely matches the container model than do traditional OSes.
Last week, the oVirt Project delivered a new version of its open source virtualization management system, complete with a feature I’ve eagerly awaited for the past two years. The feature, called Hosted Engine, enables oVirt admins to host the system’s management server (aka the engine) on one of the virtualization hosts it manages.
While oVirt was designed to run across separate management and virtualization hosts, it’s been possible from early on (version 3.0) to hack up a machine to serve both roles. In subsequent releases, the project approved and refined this installation option into an easy-to-use All-in-One (AIO) installation plugin.
The problem with AIO is that it leaves you with one of your most important workloads (the oVirt engine) stuck running on a single piece of hardware, where it can’t easily be moved around – a very un-virt scenario. Hosted Engine gives those of us interested in getting oVirt rolling on a single server a new deployment option, and one that promises to scale out more nicely than possible with the AIO plugin.
In this post, I’m going to walk through the installation and first steps of a basic oVirt install using the Hosted Engine feature.