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 »

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 »

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 »

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 »

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...

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 »

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 »

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 »