If you’ve been hoping for a bare-metal version of a Fedora Atomic host, there’s good news! I’ve finally gotten time to work on Fedora/Atomic more, and have created a functional installer ISO based on Fedora Rawhide.

You can grab the ISO from http://rpm-ostree.cloud.fedoraproject.org/project-atomic/install/rawhide/20140708.0/.

Unlike the other images we’ve produced for Atomic proof-of-concepts, this is designed to be installed on bare metal. None of the trees contain cloud-init, but this will install directly using Anacona to bare metal.

It contains a cache of the tree content inside it, similar to how the Fedora DVD includes many packages, and the Fedora LiveCD just copies itself.

To Receive Updates

To get updates after installation, you’ll need to run a few commands:

# ostree remote add fedora-atomic http://rpm-ostree.cloud.fedoraproject.org/repo
# atomic rebase fedora-atomic:

Let me explain those two commands a bit more. The first adds a new “remote” with the location of the current (hopefully temporary) OSTree repository. (For more information on the temporary part, see: https://lists.fedoraproject.org/pipermail/infrastructure/2014-June/014447.html.

Now the second command is effectively shorthand for:

atomic rebase fedora-atomic:fedora-atomic/rawhide/x86_64/server/docker-host

Basically that way you don’t have to retype the branch name. It’s shorthand, because you could also rebase to one of the other available trees (such as server/virt-host).

An important next step here is going to be integrating cloud init by default so that we can use the same tree on both baremetal and cloud. (Unlike mainline where cloud-init is a package only installed on the cloud images by default; we can’t do that without ~doubling the number of trees right now).

If you have feedback, questions, or ideas on improving the Atomic host, please join the atomic-devel mailing list, ask over on ask.projectatomic.io, or leave a comment here. This is still a work in progress, and we’re looking forward to your feedback!

Today we proposed a CentOS Atomic Host Special Interest Group (SIG) on the CentOS Devel mailing list. Since Project Atomic isn’t in the business of producing its own distribution, the idea is to work within the CentOS community to develop an Atomic Host based on CentOS.

If you’re interested in participating, the discussion about the SIG will take place on the CentOS devel mailing list. Work on the project will be coordinated on the Atomic devel mailing list.

The next step for the proposal is to have it reviewed by the CentOS Board. The next board meeting is on July 9th, so we hope to have the SIG accepted at that time and make headway towards getting the first CentOS Atomic Host release out the door.

The full proposal is below. If you have comments, please raise them on the CentOS devel or Atomic devel mailing lists.

As Project Atomic continues to lift off, a lot of attention has been focused on the container aspects of Atomic, and our consumption of the popular Docker container technology. Atomic, however, is not just about container technology, nor is it solely about the GearD container management that will also be a part of Project Atomic host. Nor just about about Cockpit. It’s about all of those technologies and more.

But what makes Atomic “atomic”? I’ve had some people come up to me and ask if we are making a word-play on the container/size thing and using the label Atomic to describe container technology. In actuality, the “atomic” in Atomic describes the one bit of technology that makes Project Atomic very unique: rpm-ostree.

With DockerCon wrapping up earlier this week, it’s little surprise that containers are getting a lot of attention in the Web-o-sphere these days.

One of the better articles I have seen in a while that covers container technology is Rami Rosen’s piece on Linux Journal. This is a great primer that gets into the guts of containers, explaining not only how they work but why they are beneficial:

“Due to the fact that containers are more lightweight than VMs, you can achieve higher densities with containers than with VMs on the same host (practically speaking, you can deploy more instances of containers than of VMs on the same host)… Another advantage of containers over VMs is that starting and shutting down a container is much faster than starting and shutting down a VM.”

It is easy to see the focus on containers as some sort of threat to virtual machines. Application-centric containers, after all sound like a much easier technology to manage than a whole VM. In some respects, that’s some truth to that. Developers, after all, would love nothing more than not having to deal with OS updates changing libraries out from under their applications.

The Place For Virtualization

But don’t count VMs out yet; just like operating systems, VMs will still have a place in IT. Running Project Atomic hosts can be done on bare metal to be sure, but running the Atomic hosts as VMs that can be orchestrated and managed on the virtualization level can give admins a huge amount of flexibility.

It’s not just applications that can benefit from containers, mind you, cloud infrastructure itself can be transformed by containers. There is a real push to package OpenStack services as containers, either on bare metal or atop multi-service KVM machines. Ideally, this would reduce the complexity found in OpenStack usage and packaging. It’s pretty cool to imagine some of the many scenarios: Atomic Host virtual machines running containers with RDO OpenStack services to deploy your applications in true cloud fashion. Manage those Host VMs with a data center manager like oVirt, and you’ve got superior flexibility for your IT configuration.

The day is coming, sooner than you can imagine.

Yesterday at DockerCon, the Docker folks announced the 1.0 release along with a number of other interesting announcements. To make sure that the Atomic community has the latest and greatest tools to work with, we’ve rolled up a new image based on Fedora 20 with Docker 1.0 and a number of other updates.

Note that some of the packages in this image come from updates-testing or Copr builds. A big thanks to Jason Brooks for managing the builds and the Copr packages!

What’s New

In addition to Docker 1.0 (see the official Docker post on that), the latest release of the Atomic proof-of-concept image includes:

• Cockpit 0.9
  • Cockpit no longer needs SELinux disabled
  • Cockpit runs mostly unprivileged now
  • Cockpit listens on port 1001
• Updated GearD
• Additional packages to make working with the image easier (e.g. GNU Screen)

See also Stef Walter’s post on Cockpit. A number of other packages have also been updated. If you’re already testing Atomic, you can update to the latest with rpm-ostree upgrade and then systemctl reboot.

If you haven’t tried it yet, you can grab the newest images for KVM 20140609.qcow2.xz or VirtualBox 20140609.vdi.bz2. Be sure to check out the Get Started with Atomic page as well.

Have questions? Come find us on Freenode in the #atomic channel, or ask questions on Ask.ProjectAtomic.io.

Cockpit 0.9 has been released and includes some major milestones for the project. With Cockpit 0.8, we’d moved beyond the prototype stage, and have closed a bunch of security and stability issues.

With Cockpit 0.9 we added continuous integration tests for running on SELinux. We want to be the first to know if Cockpit breaks due to SELinux and not find out about it because someone ran into a problem somewhere. At least that’s the goal!

One of the most notable changes is that Cockpit now respects the system access privileges and won’t provide a way to escalate privileges without going through the usual channels like polkit or sudo.

Because of this some features that used to work for accounts in the wheel group, now only work as root. We’re working on fixing this regression by fixing system default policies in the various services (like NetworkManager) that we access.

Still Evolving, Be Careful

Soon to come down the pipe are Docker image pull support in 0.10, and soon a redone Networking configuration page.

Cockpit has changed a bit in the jump to 0.8, and a lot of it runs unprivileged now. We’ve built our own quite restrictive SELinux policy, and will be running test suites against this policy and updating it to make changes.

Our goal is that having Cockpit 0.8 or later installed should pose no security risk. That said, Cockpit is still in rapid development, and you should still be careful when using it to manage your system.

Want to take a look at Cockpit, or provide feedback? Check it out on GitHub, and open an issue if you find any problems.

We hope to have a new Atomic Fedora 20-based image up soon that will include the latest Docker, Cockpit, and other updates.

A strange thing is going on in IT these days, an unintentional fake out that on the surface could lead people to wonder if operating systems are becoming more and more irrelevant–when actually the opposite is going on.

In 2011, I addressed this topic from the perspective of the desktop, arguing that while the software as a service (SaaS) way of doing things would seem to suggest that applications that run in the browser don’t really need to care about the desktop operating system, the then-rising app-store model of application deployment made the choice of operating system all the more important. Native apps installed on operating systems kept the notion of operating systems alive (even if those apps were merely tricked-up portals to the same web services to which a browser could link).

Project Atomic has been getting a great deal of attention since it was announced at Red Hat Summit this April. We saw a lot of enthusiasm at Summit for the concept of Atomic Hosts that are focused on running Docker containers, but still built from a well-known, well-tested distribution. 

One thing we’ve seen, though, is a little confusion about the separation between Project Atomic and Atomic Hosts. Project Atomic, itself, does not produce Linux OS releases. Instead, those will come from CentOS, Fedora, Red Hat, and potentially others.

The Value of Upstream First

Red Hat’s philosophy on driving technology innovation in upstream communities that then gets into the hand of customers in the form of robust products can be summarized as “upstream first.” 

Over the last decade this philosophy has spurred rapid technology innovation, fueled by user needs, that is ultimately delivered in supportable enterprise-grade products. This ensures that the best-suited technical solution is generated in the open source development community. 

Project Atomic is designed around this philosophy. Not only does it strive to be a community for the technology behind optimized container hosts, it is also designed to feed requirements back into the respective upstream communities. By leaving the downstream release of Atomic Hosts to the Fedora community, CentOS community and Red Hat, it can focus on driving technology innovation.

The Atomic Family

This is important to understand, because each of the offerings will differ in important ways, though they’ll also be very similar.

First, the release cycle will vary depending on where you’re getting your host. Release cycles are defined as a balance between the desire to deliver new features and enhancements and the ability of the target users to consume new releases. The release cycle for Red Hat Enterprise Linux Atomic Host (RHEL Atomic Host) will not match up with the release cycle for the Atomic offering from the Fedora Project. The RHEL Atomic Host release cycle will be suited for enterprise deployments, while the Fedora cycle will be more attuned to those doing leading edge development and testing newer technologies.

It also goes without saying that the actual content of the releases will also differ. Fedora’s offering will likely move faster, include newer and consequently less proven and robust technologies. These technologies may then work their way into future productized versions of RHEL Atomic Host, in the same way that Fedora feeds into future versions of Red Hat Enterprise Linux. 

How Fedora and CentOS Atomic offerings evolve is also up to the respective communities. The Fedora Cloud Special Interest Group (SIG) is still discussing exactly what packages will be included, how frequently releases will be generated, what type of images should be produced, and more. There’s plenty of room for the larger community to be involved in those projects, and we welcome participation. (See the Fedora wiki for more info, or join us on IRC (#fedora-cloud) on Freenode, or join the mailing list.)

Similar community discussion is happening in the CentOS community to land the optimal balance for their users.

The Role of Project Atomic

Project Atomic gives the larger community a place and tools to collaborate on related technologies that are vital to Atomic Hosts, such as SELinux (http://www.projectatomic.io/docs/docker-and-selinux/) to secure your containers, GearD (http://www.projectatomic.io/docs/geard/) for container wiring and systemd integration and Cockpit (http://www.projectatomic.io/docs/cockpit/) to help manage containers. It also gives users of the various releases a forum to solve problems on using the technologies, keep tabs on important developments, and to participate in developing the technologies. 

The project will also serve to disseminate news about Atomic Host distributions and important changes in the upstreams like Docker, rpm-ostree, SELinux, and others. So be sure to keep an eye on this site and @projectatomic.

As I’ve mentioned a number of times when I’ve spoken about Software Collections (SCLs), containers and SCLs are not mutually exclusive. In fact, SCLs promise to be really important for a lot of developers in building containers for production.

Langdon White has written up a great post on how to move an RHSCL app to Docker using an Atomic host:

Ok, now that Atomic is installed, I need to go make a container. After a few fits and starts, mostly related to pathing issues while using the “RUN” command, I got a decent Dockerfile working. You “run” this file by using the ‘docker build’ command. Later, you “make the app go” with the ‘docker run’ command.

Check out the rest of Langdon’s post on the Red Hat Developer Blog.

Ever wondered if you can get systemd running in a Docker container? Apparently Dan Walsh did, and spent some time getting it to work.

While working with Docker, I looked at the great work that Scott Collier was doing for getting services to run within a container. Scott provides the fedora-dockerfiles package in docker with lots of “Dockerfile” examples. You can build Docker images by running “docker build” on these examples.

It seemed a little difficult, and wondered if getting systemd to run within a docker container, as I did with virt-sandbox-service, might make this simpler.

The Docker Model suggests that it is better to run a single service within a container. If you wanted to build an application that required an Apache service and a MariaDB database, you should generate two different containers. Some people insist on running multiple services within a container, and for this Docker suggested using the supervisord tool. In RHEL we do not want to support supervisord, since it is written in Python, and do not want to pull a Python requirement into containers, and it is just a package used to monitor multiple services. We already have a tool for monitoring multiple services called systemd.

After a little trial and error, Dan got systemd working within a container on Fedora Rawhide, and expects it will work on Fedora 20 or RHEL 7 (when it’s released). Give it a spin and let Dan know how it works out for you.