You don’t want a custom tree, you want atomic-pkglayer

Atomic system updates are at least half of how “Atomic Hosts” earn their Fallout-flavored appellation. Where a standard Fedora, RHEL or CentOS host gets its updates from a sack of RPMs downloaded from various repositories and exploded out where appropriate, the Atomic editions of these distros consume this same software in pre-exploded-and-composed-into-an-image form.

One tricky element of consuming your RPMs in a single blob is choosing a package or two to add beyond what’s been composed into the image. I wanted to do this straightaway after learning about the atomic host concept, and I (semi)helpfully documented my progress with composing custom trees in a few different spots, most recently at: Compose Your Own Atomic Updates.

This works pretty well, but composing and rebasing to a tree of your own is sort of a heavy approach. Shouldn’t you be able to compose just part of a tree, and, like, overlay those packages on your atomic host?

OSTree mastermind Colin Walters has whipped up just such a utility, and today, I took it for a spin with CentOS Atomic Host.

I started with a CentOS Atomic Host vagrant box, which, as you’ll see, doesn’t include the fortune-mod package:

[laptop-host]$ vagrant init centos/atomic-host

[laptop-host]$ vagrant up

[laptop-host]$ vagrant ssh

[atomic-vm]$ fortune
bash: fortune: command not found

I need to grab Colin’s tool from git, which is also not included in the CentOS Atomic Host, but which is available in the friendly centos/tools container. For a bit of info about the Fedora flavor of this container, see here.

[atomic-vm]$ sudo atomic run centos/tools

[tools-container]$ cd /root

[tools-container]$ git clone https://github.com/cgwalters/atomic-pkglayer/

[tools-container]$ cd atomic-pkglayer

[tools-container]$ git checkout v2016.1

atomic-pkglayer requires ostree to function, and this package is missing from the centos/tools container, so I need to grab it from the repo below. Also, fortune-mod lives in EPEL, so I’ll install that repo as well.

[tools-container]$ curl -O https://raw.githubusercontent.com/CentOS/sig-atomic-buildscripts/downstream/rhel-atomic-rebuild.repo

[tools-container]$ mv rhel-atomic-rebuild.repo /etc/yum.repos.d/

[tools-container]$ yum install ostree epel-release -y

Now I need to grab all the rpms required for fortune-mod, and install them to a pkglayer, before exiting my tools container, rebooting my atomic VM, and logging back in to the rebooted atomic VM:

[tools-container]$ mkdir pkgs

[tools-container]$ yumdownloader --resolve --destdir=pkgs fortune-mod

[tools-container]$ /root/atomic-pkglayer/atomic-pkglayer pkgs/*rpm

[tools-container]$ exit

[atomic-vm]$ sudo reboot

[laptop-host]$ vagrant ssh

Now, for some fortune:

[atomic-vm]$ fortune
Rune's Rule:
    If you don't care where you are, you ain't lost.

You can see my local overlay:

[atomic-vm]$ sudo atomic host status
TIMESTAMP (UTC)         VERSION        ID             OSNAME                 REFSPEC                                                     
* 2016-01-29 00:30:06     local          0aa16a3e42     centos-atomic-host     <unknown origin type>                                       
  2015-10-01 09:32:09     7.20151001     1e9838ce88     centos-atomic-host     centos-atomic-host:centos-atomic-host/7/x86_64/standard     

The system is left in an un-upgradable state — I’ll need to rollback before I can grab updates again, so this overlay is temporary:

[atomic-vm]$ sudo atomic host upgrade
error: No origin/refspec in current deployment origin; cannot upgrade via ostree

[atomic-vm]$ sudo atomic host rollback
Moving '1e9838ce8879112c47c72503bbade0830e6f06dc20f5cabbf6da40a373550f69.0' to be first deployment
Transaction complete; bootconfig swap: no deployment count change: 0
Removed:
  fortune-mod-1.99.1-17.el7.x86_64
  recode-3.6-38.el7.x86_64
Successfully reset deployment order; run "systemctl reboot" to start a reboot

[atomic-vm]$ sudo systemctl reboot

[laptop-host]$ vagrant ssh

Post-rollback, the fortune command is missing once again, and my system is ready for upgrades again:

[atomic-vm]$ fortune
bash: fortune: command not found

[atomic-vm]$ sudo atomic host upgrade
Updating from: centos-atomic-host:centos-atomic-host/7/x86_64/standard

New Atomic Host verb: rpm-ostree deploy

This is cool. Also, I’m trying out reblog.

Colin Walters

TL;DR: We’ve improved the host version management in Fedora Atomic Host, and you can now use atomic host deploy $version to atomically switch to a well-known version.

Longer version:

The awesome Cockpit project has been working on a UI for managing Atomic Host/OSTree updates. See this page for some background on their design.

If you download the most recent Fedora Atomic Host release, then atomic host upgrade, you’ll get a new rpm-ostree release which in turn has a new “deploy” verb. This was created to help implement the above Cockpit design; it’s a command line talking to code equivalent to what the Cockpit UI pull request will use.

This is noteworthy for several reasons. First, it really unlocks the “server side history” aspect of OSTree for the host tree. This is similar to tagged builds in a Docker repository for a container.

In order to explain this, one…

View original post 419 more words

Cutting out the Middleman, with Wordpress

For the past few years, the only posts I’ve written in this blog have been about this blog, and this post is no different. I make up for it in lack of volume: I’m averaging about one post a year.

Two years ago, I wrote about how I’d finally (almost) gotten my static blog all set up the way I wanted it, complete with self-hosted, open-source commenting functionality. Yay!

One year ago, I dumped some quick notes about how I’d re-homed my blog to Github Pages and wired it up to Github’s Travis CI service such that pushing posts or updates to my blog’s git repo would trigger a build and refresh of my site. Yay!

Of course, I still had some things to figure out, and while I eventually figured out most of it, I wasn’t blogging — I’d think about my blog, and my thoughts would immediately turn to distraction over hosting and customization and maintenance. If I’m actually going to write here, I should try to make the experience as smooth as possible, with fewer non-writing avenues around to distract me.

Middleman Retrospective

A few weeks ago, I was reflecting on my too-static blog, and on my general blog desires, which haven’t really changed since I switched away from WordPress:

(listed in order)

  1. I don’t want to admin a dynamic web app
  2. I don’t want to write/edit post in HTML
  3. I want to use open source software
  4. I want to be able to customize my blog
  5. I want an easy editing/publishing experience
  6. I want to maintain commenting support

With my Middleman-based setup, I had point one nailed. Static HTML FTW. Point two, also nailed. I wrote in either AsciiDoc or Markdown. Point three, nailed.

Point four… not really nailed. Maybe… stapled? Basic customization chores, like figuring out how to add a simple sidebar, took a long time for me to figure out, and each question I answered led to other questions. As I Googled around for answers and fiddled endlessly with CSS, my thoughts often turned to a “retreat” back to WordPress, with all its point-and-clickitude.

Point five, the easy publishing experience, also nailed. The git repo to CI to github pages process I set up worked really well, and the middleman blog-writing UI that Garrett wrote is really awesome.

Point six I had working, using Juvia comments, which, being open source software, kept me in line with point three, but took me out of compliance with point one — I didn’t want to maintain some dynamic, mysql-backed web application just for my blog, and yet, my Juvia comments instance was just that. And, as a bonus, since I first deployed it, the Juvia project has been orphaned.

WordPress: A New Hope

I mentioned above that in dark moments, I felt tempted by a return/retreat to WordPress. I figured I could use the wordpress.com service, which would satisfy my nothing-to-admin, open source, commenting, and publishing ease requirements. A combination of the many nice-looking, built-in WordPress themes and widgets, along with the (paid) option of tweaking theme CSS and whatnot, promised to satisfy my customization needs, as well.

Still, I really didn’t want to write posts in HTML, or have to hand-edit the HTML of the WordPress WYSIWYG editor. I love how markdown can be pasted straight into a email, as plain text, and remain totally readable.

It turns out that about two weeks after I quit using WordPress, the project added a “write in markdown” option to the software. You check a box somewhere, and the write-in-HTML tab in the UI becomes a write-in-markdown tab. So, that’s point two, nailed.

I signed myself up for the $99 premium WordPress subscription, which seems like a lot of money, but comes out to less than my WWE Network and Marvel Unlimited subscriptions, and goes to a company that creates and supports open source software, so… I’ll give it a year.

Getting rolling again with WordPress was easy. I pointed my domain in the right direction, picked out a theme I liked, sucked in most of my old posts from WP backups, converted the very few new ones, and modified my static posts sitting on github pages to redirect permanently over here.

We’ll see how this return to WordPress, now with markdown support and full SaaSification, affects or does not affect my personal blogging. There’s a non-zero chance I’ll be back in November 2016 to tell you all about my new LiveJournal odyssey.

Link

A single Atomic Host is a fine place to run your containers, but these hosts are much more fun when bunched into clusters, a task that we can manage with the help of Kubernetes.

There are a lot of great guides for setting up a kubernetes cluster, but my favorite involves ansible and vagrant, and lives in the kubernetes contrib repository on Github.

This install method can be used with the libvirt, virtualbox or openstack vagrant providers. You can also use the ansible scripts on their own, if vagrant isn’t your thing.

Read more on the Project Atomic blog

Link

Fedora 22’s Atomic Host dropped most of packages for the web-based server UI, cockpit, from its system tree in favor of a containerized deployment approach. Matt Micene blogged about running cockpit-in-a-container with systemd, but people have expressed interest in learning how to start this container automatically, with cloud-init.

via Running a Containerized Cockpit UI from Cloud-init — Project Atomic.

Link

Kubernetes, the open source orchestration system for Docker containers, is a fast-moving project that can be somewhat complicated to install and configure, especially if you’re just getting started with it.

Fortunately, the project maintains some really well-done getting started guides, the simplest of which steps you through running Kubernetes, in Docker containers, on a single host.

via Deploy Kubernetes with a Single Command Using Atomicapp — Project Atomic.

Link

Recently, I blogged about docker-on-loopback-storage woes and workarounds – a topic that came up during several conversations I had at last month’s Dockercon. Another frequently-discussed item from the conference involved Docker on CentOS 6, and whether and for how long users can count on running this combination.

via Docker, CentOS 6, and You — Project Atomic.

Link

I’ve heard negative things about the Fedora|CentOS Docker storage configuration in the past, and while manning the Red Hat booth in San Francisco at DockerCon last week, I spoke to a number of people who’ve experienced these storage issues themselves.

Much of the trouble, I think, boils down to how Docker in Fedora and CentOS have shipped with a storage configuration that optimizes for a convenient getting started experience that can lead to inconvenience down the road.

via Friends Don't Let Friends Run Docker on Loopback in Production — Project Atomic.

Link

Just over a week ago, I headed to the outskirts of San Francisco’s Financial District to attend Container Camp, a one-day, single-track conference focused primarily on the Docker ecosystem.

The Container Camp lineup included a nice mix of project talks and real user stories that left me looking forward to attending the next time the crew comes to town, and thinking back on the key issues raised during the event.

via My Letter Home from Container Camp — Project Atomic.

Link

Next week in Los Angeles, I’ll be giving a talk at the SCALE 13x conference on oVirt’s new OptaPlanner-powered scheduling adviser.

Martin Sivák wrote a great post about the feature a couple of months ago, but didn’t cover its installation process, which still has a few rough edges.

Read on to learn how to install the optimizer, and start applying fancy probabilistic fu to your oVirt VM launches and migrations.

via Trying out oVirt's Probabilistic Optimizer — Red Hat Open Source Community.