I’ve spent some of the last weeks working on a replacement for runC, the most used/known OCI runtime for running containers. It might not be very well known, but it is a key component for running containers. Every Docker container ultimately runs through runC. The OCI runtime is the thin layer between the container engine and the kernel: it reads a JSON configuration file, creates the necessary namespaces and cgroups, sets up mounts and capabilities, and finally execs the container process. Because it runs for such a short time and its workload is almost entirely syscalls, the implementation language matters for startup latency.

It is still an ongoing work not ready for production, but the upstream version of OpenShift origin has already an experimental support for running OpenShift Origin using system containers. The “latest” Docker image for origin, node and openvswitch, the 3 components we need, are automatically pushed to docker.io, so we can use these for our test. The rhel7/etcd system container image instead is pulled from the Red Hat registry.

This demo is based on these blog posts www.projectatomic.io/blog/2016/12/part1-install-origin-on-f25-atomic-host/ and www.projectatomic.io/blog/2016/12/part2-install-origin-on-f25-atomic-host/ with some differences for the provision of the VMs and obviously running system containers instead of Docker containers.

bubblewrap is a sandboxing tool that allows unprivileged users to run containers. I was recently working on a way to allow unprivileged users to take advantage of bubblewrap to run regular system images that use systemd. To do so, it was necessary to modify bubblewrap to retain a controlled set of Linux capabilities inside the sandbox. Without those capabilities, systemd cannot perform the privilege-separation steps it needs at startup, even when running as UID 0 inside a user namespace.

Every programmer at some point gets in touch with the Brainfuck programming language and how surprising is that very few instructions are needed to have a Turing complete language, 6 is the case of Brainfuck (plus other 2 for I/O operations). The language operates on a tape of memory cells using only increment, decrement, pointer movement, and conditional loop instructions. Writing a GCC frontend for it turns out to be a manageable project, and the result is a good template for understanding how language frontends hook into the GCC middle-end and optimization passes.

rpm-ostree, used together with OStree, is a powerful tool to generate immutable images for .rpm based systems, so why not use it for generating Docker images as well? rpm-ostree already has support for composing a container tree, but the steps to go from an OStree commit to a ready-to-run Docker image involve several manual operations. ostree-docker-builder is a small tool that automates this workflow, taking a JSON package description and producing a tagged Docker image with a minimal Dockerfile.

Coming as a surprise, this year we have got 4 students to work full-time during the summer on wget. More than all the students who have ever worked for wget before during a Summer of Code! The projects span a broad range of improvements: HSTS and FTPS security hardening, TCP Fast Open and conditional GET for performance, HTTP/2 support on top of nghttp2, and an expanded FTP test suite. Each student is expected to keep their work rebased on the current development branch to ease eventual integration.

This tutorial shows how to create a QCOW2 image that can be directly imported via virt-install to test out Fedora 22 Atomic starting from a custom OStree repo. The process involves composing an OStree repository from a Fedora Atomic tree definition, serving it over HTTP so the installer can reach it, then driving an unattended installation through a kickstart file. This gives you full control over the package set and tree composition rather than relying on a pre-built official image.

These are the steps to setup the current website in a Docker container. The setup uses docker-compose to declaratively describe a two-container application: a MySQL 5.5 database and a WordPress frontend. Docker links tie them together so that the web container can reach the database by hostname, without needing to hard-code any IP addresses or manage networking manually. A single docker-compose up command downloads the required images and starts both containers, with port 80 on the host forwarded into the WordPress container.