Does the OCF spec mean that Docker is no longer Linux centric?

When I first heard that Microsoft was working to run docker containers it didn’t make sense.

For a while it seemed that Docker was Linux-centric, with its dependency on Linux Containers.

  • Installing and using Gradle in a docker image/container
  • Using Docker for HPC with Sun Grid Engine
  • Recompile Symfony container manually
  • Previously working docker now having errors
  • Dockerized Riak cluster - dynamic container IP
  • Setup & scale titan/cassandra on AWS EC2 using docker
  • Now it seems Docker has switched from LXC to an implementation of the Open Containers Format (OCF) spec in runc.

    My question is: Does the OCF spec mean that Docker is no longer Linux centric? (ie is that how this will work? Does that mean there exists the theoretical capability to do this on OSX as well?)

  • Docker read Host Env Variable
  • Failed connections between docker containers
  • Error: EACCES: permission denied using docker-compose
  • getting “cannot find package” trying to build my application in a docker container
  • How to connect to remote Spark cluster from python in docker
  • Meaning of docker-compose exit code?
  • 3 Solutions collect form web for “Does the OCF spec mean that Docker is no longer Linux centric?”

    There are a few points of interest here.

    1. Containers can only be supported natively on platforms that have support for OS virtualization. OSX (so far) does not have such a capability. So it cannot support containers natively. You have to use a VM.
    2. A standardized container format does not mean that the same container will be able to run on different platforms. The container and the host necessarily have to run on the same kernel. So a particular container can only run on a compatible platform.
    3. What the standardized container format specification does is to enable richer container ecosystem technology from varied sources, all able to interwork because of the standard container format. This technology still has to be implemented for each different host platform.
    4. Docker’s adoption of OCF does not necessarily mean that it will automatically start targeting platforms other than Linux. It just means that the container format it will use on Linux will be the OCF instead of it’s own proprietary format.

    +1 to Ziffusion. You might want to reword Item 1), but basically you are correct on all four points.

    To answer the OP’s question: I do not believe OCF “deprecates” Linux. On the contrary, I believe it better supports Linux AND, AT THE SAME TIME, opens Docker functionality to better support other OS’s, too.


    In the past two years, there has been rapid growth in both interest in
    and usage of container-based solutions. Almost all major IT vendors
    and cloud providers have announced container-based solutions, and
    there has been a proliferation of start-ups founded in this area as
    well. While the proliferation of ideas in this space is welcome, the
    promise of containers as a source of application portability requires
    the establishment of certain standards around format and runtime.
    While the rapid growth of the Docker project has served to make the
    Docker image format a de facto standard for many purposes, there is
    widespread interest in a single, open container specification, which

    a) not bound to higher level constructs such as a particular client or
    orchestration stack,

    b) not tightly associated with any particular commercial vendor or
    project, and

    c) portable across a wide variety of operating systems, hardware, CPU
    architectures, public clouds, etc.

    The FAQ further states:

    What are the values guiding the specification?

    • Composable. All tools for downloading, installing, and running containers should be well integrated, but independent and composable.
      Container formats and runtime should not be bound to clients, to
      higher level frameworks, etc.

    • Portable: The runtime standard should be usable across different hardware, operating systems, and cloud environments.

    • Open. The format and runtime should be well-specified and developed by a community. We want independent implementations of tools to be
      able to run the same container consistently. …

    The Open Container Initiative is a working towards making a container format and a runtime that can run on many platforms, although a lot of the concepts and requirements will be based on the linux foundation they have been built from. An OCF container still specifies a platform so don’t expect to be able to execute a Windows container on a Linux host. But expect to be able to manage Linux and Windows and “Y” containers in the same manner and ecosystem.

    Docker moved away from LXC a while ago, to using libcontainer which is still linux centric. runC is the next runtime that is already able to run current docker containers on Linux, but aims to support the Open Container Format spec on many platforms.

    The goal of runC is to make standard containers available everywhere

    Linux, obviously, has been building up the OS features to support containers over the last 10 years. Microsoft has included a lot of the OS components in Windows 10 to run containers natively and has thrown support behind docker. So expect runC to be running on Windows soon.

    BSD does support a lot of the functionality via it’s Jails setup but never matured as much as the Linux space so I believe additional OS support will be required for it, or OSX to be able to run an OCF container natively. Although recent FreeBSD 11 does allow you to run Docker via it’s 64bit Linux compatibility layer so I’m guessing runC would be close to doing the same, at some possible performance cost.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.