Project News

This post will describe how to set up remote command-line access for the Docker daemon running on an Atomic host. This will let you run docker ps, docker run and other commands from your desktop and manage a server.

We are also going to secure the Docker daemon with TLS (transport layer security) since we are connecting remotely. Before you carry on with the following steps, keep in mind that any process on the client that can access the TLS certs now has full control of the Docker daemon on the server and can do anything it wants to do. So, only copy those certificates to client hosts completely under your control.

Read More »

TL;DR: If you are a production user of Kubernetes on Fedora Atomic Host, you can now upgrade to Fedora Atomic Host 25. Kubernetes 1.4 is part of the base image now.

Per our previous announcement, we wanted to make a change to Fedora Atomic Host, and in concert with the Kubernetes community move to an entirely containerized install of Kubernetes, which would make it easier for users to choose their Kubernetes version or distribution. However, some of the upstream technical issues with that change will take longer than we expected to resolve. As such, we have added Kubernetes and Flannel back into the base image for Fedora Atomic 25, as of today’s OStree.

If you are a production user of Fedora Atomic 24 with Kubernetes, you may now rebase and upgrade. Please make sure to go directly to the 2016-12-21 or later OSTree image, skipping any earlier ones for version 25.

Do note that the version of Kubernetes which ships with version 25 is Kubernetes 1.4.6. As such, you should test to make sure no incompatibilities have been introduced by the Kubernetes upgrade before rebasing production servers. While the goal of the Kubernetes project it to maintain complete backwards compatibility, there may be minor exceptions, especially for specific addons.

At this point, we plan to transition to containerized Kubernetes for Fedora Atomic Host 26, in mid-2017. At that point, we expect the bugs to be worked out, and will be providing a migration guide. If you can help with testing and feedback, please do so through our online community.

Users of Fedora Atomic Host who do not use Kubernetes or Flannel will be largely unaffected by these changes.

A number of folks have asked for my thoughts on the Docker containerd announcement last week. While containerd itself is not new, having been announced over a year ago, we were happy to see that Docker Inc. is now spinning this out as an independent project. This is aligned with Red Hat’s overall goal to drive open industry standards for Linux containers and the work that we’ve helped drive as a leading contributor to the Docker project, a founding member of the Open Containers Initiative, and a leading contributor to related projects like OCI runC and CRI-O (previously OCID). Splitting containerd from Docker Engine and contributing it to a neutral foundation, as Docker Inc. has committed to do, is another positive step in that direction.

When we launched CRI-O as a Kubernetes incubator project and implementation of the Kubernetes Container Runtime Interface, we discussed the importance of having a comprehensive open container runtime standard that “follows the time-tested UNIX philosophy of modular programming.” This led us to create key modules for image distribution and storage, that built on runC and delivered stable container runtime functionality platform builders could rely on. We are happy that Docker Inc. has followed the lead of CRI-O in breaking apart the upstream Docker Engine into a series of more modular components, starting with containerd. We hope that the containerd project will be able to use some of the work we’ve done and also continue to get broken down into sub-components. This is critical for delivering on the promise of “boring infrastructure” at the container runtime level that platform builders in the container ecosystem, whether they are customers or vendors, can rely on.

As we’ve done in the past, we would love to work together with the open source community on the components needed to support running containers locally or by orchestration tools, as customers move towards running containers at scale in production environments.

We have every intention of contributing to the containerd effort while continuing to engaging with the broader container ecosystem. In this spirit, we have offered github.com/containers/storage and github.com/containers/image as sub packages to containerd, just in the past few days. (issue 376, issue 379)

These libraries could be shared between containerd, CRI-O and other lower level command line tools like skopeo for the pulling/pushing and storage of images. We want to see these components used by many different open source projects, and to be able to evolve at their own pace. The goal is to build a set of tools around them so people can experiment with building and running Linux containers in a myriad of different ways.

Red Hat also plans to continue contributing to CRI-O, as we feel this can be a great way to run Kubernetes workloads in the OpenShift platform, in addition to the docker container runtime default. Meanwhile, the Kubernetes Container Runtime Interface (CRI), recently released in Kubernetes 1.5, allows users to plug in different container runtimes to suit their needs. I believe a dedicated daemon for serving the Kubernetes CRI protocol, not servicing all different orchestration tools, is the great way to go. “One daemon to service them all” has the potential to get bloated over time. Conflicts between orchestration tools may occur, which could lead to compromises that could affect performance of one orchestrator over another.

Finally, I am happy to announce we are planning to ship the first alpha release of CRI-O inside of Fedora Rawhide (Fedora 26), so that people can start to play with it. We have integrated CRI-O and Kubernetes and successfully run a basic pod. We are thrilled with the contributors who have joined us from many of the top Linux, open source and container companies, and are contributing to getting this first package out the door.

It is with great pleasure that the Fedora Project Announces the availability of the Fedora Docker Layered Image Build Service to the Fedora Contributor Community! The new service will provide trustworthy, consistent application images for Fedora Atomic and CentOS Atomic as well as other platforms.

Read More »

Introduction

In part 1 of this series, we used the OpenShift Ansible Installer to install Openshift Origin on three servers that were running Fedora 25 Atomic Host. The three machines we’ll be using have the following roles and IP address configurations:

|    Role     |  Public IPv4   | Private IPv4 |
|-------------|----------------|--------------|
| master,etcd | 54.175.0.44    | 10.0.173.101 |
| worker      | 52.91.115.81   | 10.0.156.20  |
| worker      | 54.204.208.138 | 10.0.251.101 |

In this blog, we’ll explore the installed Origin cluster and then launch an application to see if everything works.

Read More »