Introduction

In Part 4 of this series we learned about package layering and experimental features of atomic host OSTree mutations. This included installing packages from external repositories as well as removing and replacing components of the base OSTree that was delivered with Atomic Host. We also converted our localweb service to be hosted by a local docker container running the httpd software rather than Python 3.

In this section of the lab we’ll talk a litte bit more about Containerized and Non-Containerized Applications and the role Atomic Host plays.

Introduction

In Part 3 of this series we learned about rebasing, upgrading, and performing rollbacks on Atomic Host. We also learned how files are restored during a rollback operation and how to inspect the differences in RPM content between each commit in the OSTree history of an Atomic Host using the rpm-ostree command line tool. In this section we will cover the following topics from the outline in Part 0.

• Package Layering
• Experimental Features (livefs, remove, replace)

Adding Packages to Atomic Host via Package Layering

When Atomic Host was first released we could not change much about the the delivered software on the system. Over time we developed a system for layering packages on top of what was provided by the base OSTree to allow the flexibility needed for those few packages that, for whatever reason, we may not want to put into a container.

Introduction

In Part 2 of this series we learned about configuring container storage on Atomic Host. In this section we will cover the following topics from the outline in Part 0.

• Atomic Host Rebasing
• Atomic Host Upgrades and Rollbacks
• Browsing OS History

Rebasing

One of the more fascinating aspects of Atomic Host techology is that you can rebase to completely different operating system trees. Let’s take this to an extreme and go from the newer technology in Fedora to the older (more stable) technology in CentOS. We’ll achieve by rebasing to an OSTree commit that was built from CentOS 7 RPMs:

Introduction

In Part 1 of this series we learned a little about the technology behind Atomic Host and how to interact with a deployed system. In this section we will cover the Configuring Storage for Containers topic from the outline in Part 0.

History of Container Storage

One of the early goals of Atomic Host was to be a good platform for running containerized workloads. This is still a fundamental goal of Atomic Host and certainly includes making sure that the container runtime (currently the docker daemon) has proper storage configuration such that it can get a balance of good performance and stability.

Introduction

In Part 0 of this series we helped get a Fedora 26 Atomic Host system set up for the rest of this lab. In this section we will cover the following topics from the outline:

• Getting Familiar With Atomic Host
• Viewing Changes To A Deployed System

Getting Familiar

Atomic Host is built on top of underlying technology known as OSTree and leveraged by an RPM aware higher level technology known as rpm-ostree. rpm-ostree is able to build and deliver OSTrees built out of RPMs. Once built, an OSTree commit can be installed to a server just like a traditional OS. New OSTree commits are created by a build system and a server can pull down and apply updates, similar to a git pull.

Introduction

While Atomic Host has been around since 2014 there are still a lot of people that aren’t as familiar with the technology. The Atomic team within Red Hat, along with numerous other upstream contributors, have brought the OSTree and RPM-OSTree technology a long way. At the Fedora user and contributor conference (known as Flock) this week we will be giving a lab on Atomic Host designed to let new users learn about Atomic Host. The audience for this lab is anyone familiar with Linux and interested in learning a new technology.

cross posted with this Project Atomic blog post

A new Fedora Atomic Host update is available via an OSTree commit:

Commit: f6331bcd14577e0ee43db3ba5a44e0f63f74a86e3955604c20542df0b7ad8ad6
Version: 26.101

In this release we have fixed an issue with our qcow and vagrant images from the 20170723 release. If you used the qcow or vagrant images from that release then please make sure you are following the fedora/26/x86_64/atomic-host ref. See this Atomic Working Group issue for more details.

The diff between this and the previous released version is:

a more permanent version of this content lives here

Introduction

NOTE: For background on OSTree check out the docs.

When you want to create a new OSTree using rpm-ostree you usually define a few yum repos, and then a json file that says what rpms you want to be composed in the tree. You then run an rpm-ostree compose tree command to create the commit in the ostree repo. Once the ostree commit has been created you can then create installer images (ISOs) and cloud/VM images (qcow, etc) from that ostree.

cross posted with this Project Atomic blog post and this Fedora Magazine post

Introduction

In July we put out the first and second releases of Fedora 26 Atomic Host. In this blog post we’ll cover updating an existing Fedora 25 Atomic Host system to Fedora 26. We’ll cover preparing the system for upgrade and performing the upgrade.

NOTE: If you really don’t want to upgrade to Fedora 26 see the later section: Appendix B: Fedora 25 Atomic Host Life Support.