Project Atomic is now sunset

The Atomic Host platform is now replaced by CoreOS. Users of Atomic Host are encouraged to join the CoreOS community on the Fedora CoreOS communication channels.

The documentation contained below and throughout this site has been retained for historical purposes, but can no longer be guaranteed to be accurate.

Articles from Antonio Murdaca

atomic top, docker top, and ps

Looking to view running container information quickly? Check out the new atomic top command!

atomic top is a new atomic sub-command that will allow you to interactively display the top process information from all of your containers running on a host. It works like the standard top command, where it will continuously update the top processes. Under the hood, atomic top is using Docker’s top API to gather information about a particular container. When queried, the Docker daemon uses ps to give back results. The same thing happens with the Docker CLI.

Docker’s top command allows users to display the ps output for the main process of a given container ID or name. It’s handy because it returns information about containers running on remote daemons as well.

Read More »

skopeo: inspect remote images

The atomic verify command checks whether there is a newer image available remotely and scans through all layers to see if any of the layers, which are base images themselves, have a new version available. If the tool finds an out-of-date image, it will report as such. The command attempts to reach out the registry where the image has been downloaded from to understand if the local image is outdated.

Currently, atomic verify relies on a Docker patch that Red Hat is carrying called remote repository inspection. It adds a new REST route that basically returns docker inspect-like information about a given image as found in the remote registry the image is hosted. We need this feature because atomic verify uses LABEL(s)—and in particular the Version LABEL—to check whether the local image needs to be updated. For more information about labels, see the projectatomic/ContainerApplicationGenericLabels.

Read More »

Docker Credential Store

One security feature in the upcoming Docker 1.11 is the capability to use an external credential store for registry authentication. The new version will automatically detect a configured external store, if it is available, and use it instead of the JSON file. We’ll be talking more about this in a few paragraphs, but first, let’s see how Docker is currently storing credentials.

Read More »

Working with Containers' Images Made Easy Part 1: skopeo

This is the first part of a series of posts about containers’ images. In this first part we’re going to focus on skopeo.

Back in March, I published a post about skopeo, a new tiny binary to help people interact with Docker registries. Its job has been limited to inspect (skopeo is greek for looking for, observe) images on remote registries as opposed to docker inspect, which is working for locally pulled images.

Read More »

How container registries prevent information leakage

Recently people have been reporting unexpected errors when doing a skopeo copy versus a docker pull: 1347805, 235, and 27281.

Skopeo is a command-line tool that that does various operations with container images and container image registries, including pulling the images to the host. It is also used under the covers by the atomic command-line tool.

This post explains why those weird errors...

Read More »

CRI-O and Alternative Runtimes in Kubernetes

The introduction of the Container Runtime Interface in Kubernetes 1.5.0 as an alpha feature opens the door for plugging alternative container runtimes in the kubelet more easily, instead of relying on the default docker runtime. Those new runtimes may include virtual machines based ones, such as runv and Clear Containers, or standard Linux containers runtimes like rkt.

Read More »

6 Reasons why CRI-O is the best runtime for Kubernetes

CRI-O is a Kubernetes incubator project which is meant to provide an integration path between Open Containers Initiative (OCI) conformant runtimes and the kubelet. Specifically, it implements the Container Runtime Interface (CRI) using OCI conformant runtimes. CRI-O uses runc as its default runtime to run Kubernetes pods. For more information you can read a brief introduction here.

Let’s look at the advantages of the CRI-O project.

Read More »

Using kubeadm with CRI-O

CRI-O is a Kubernetes incubator project which is meant to provide an integration path between Open Containers Initiative (OCI) conformant runtimes and the kubelet. Specifically, it implements the Container Runtime Interface (CRI) using OCI conformant runtimes. CRI-O uses runc as its default runtime to run Kubernetes pods. For more information you can read a brief introduction here. If you’re interested into why you should use CRI-O instead of other container runtimes you can read more here.

Read More »