
Docker 1.11: The first OCI-compliant runtime, built on containerd - ah3rz
https://blog.docker.com/2016/04/docker-engine-1-11-runc/
======
falcolas
You know, standardization is a great thing. But, fuck, another major release
with huge changes... What ever happened to stable architectures with hardening
burn in periods? What new bugs are going to creep in due to these huge
changes? How is this going to break our work arounds for previous versions?

It's a great time to be in operations, containers are a huge step forward, but
how are we supposed to be confident in a technology with so many major changes
every other month? Even Node.js has LTS releases.

And yes. Get off my lawn, too.

~~~
tveita
If you want something stable I'd stay away from containers and use well-tested
technologies like VMs and configuration management.

In my experience many of the tools in the container ecosystem are in the early
adopter phase, promising a lot of convenience for some use cases, but too
buggy and feature incomplete to really deliver yet. Not to mention the
breaking changes and occasional migration to a new tool.

~~~
vacri
We were using docker up to about a year ago, and ripped it out for just this
reason - we didn't have the time available to keep coding the workarounds.
Great if you have the time, not so great if you don't.

~~~
endymi0n
We were too deep in already unfortunately, but 1.10 introduced a whole new
barrage of bugs and regressions, wasting hours and days working around it. If
they don't devote some time getting the basics right and getting the core
stable, we need to really consider alternatives. I'm already scared what 1.11
will break.

~~~
cpuguy83
Please make sure to report any issues so they can be fixed.

------
sams99
This is a huge upgrade that is super welcome.

Recently (on 1.9) we have seen quite a few cases where we had "zombie"
containers, these are container that can no longer be started or stopped due
to cgroup misconfiguration or something along those lines.

The new architecture means that for weird cases like this all we need to do is
kill off runc without forcing every container on the box to restart (by
restarting the docker service which is what we do now).

It is also really nice that you can now launch apps on runc direct without
needing a docker intermediary.

~~~
cpuguy83
Sounds likely to be
[https://github.com/docker/docker/issues/18180](https://github.com/docker/docker/issues/18180)

If so, it's a bug with a particular (newer) version of AUFS that has been
fixed in most distros.

~~~
rodionos
We hit 18180 in all our images with Java applications. Workaround was to
upgrade the kernel.

------
esseti
> DNS round robin load balancing: It’s now possible to load balance between
> containers with Docker’s networking. If you give multiple containers the
> same alias, Docker’s service discovery will return the addresses of all of
> the containers for round-robin DNS.

wait wait wait. I'm kind of new into docker world. And so far i've been
struggling in understanding how to replicate a container in order to scale.
For example i want to run the same Django project 3 time as web1, web2, web3.
If i do so now i've to expose 3 different ports, one for each. Plus, to make
it working, I need to have a load balancing, thus i've to use HAProxy and do a
load balancing to point to each of the container. Anytime I add a new machine
(e.g., web4) i've to change the conf of HAProxy and restart it. This brings
down the system for a moment. (is this the right approach btw?)

Going back to the cite paragraph. Now i can create many containers and dockers
automatically does the routing for me? Am I right? or I misunderstood the
meaning of the cited point?

I just need to create all of them with a --alias web ?

~~~
m_mueller
> (is this the right approach btw?)

This is why I use hipache for load balancing / routing - it is the only
solution I've found where you can change the routing or add new backends in a
live system without any downtime. Here is the main problem though: Its load
balancing isn't exactly smart, for example it won't keep the same client IP on
the same replica, thus creating problems when a client writes something on one
replica, then gets switched to another that didn't get the update yet.

I'd love a better solution for this btw. Is noone working on Hipache anymore?
Other than this problem I find it very elegant.

~~~
code_research
you might want to take a look at fabio:

[https://github.com/eBay/fabio](https://github.com/eBay/fabio)

~~~
doublerebel
I love Fabio. The Consul stack in general is fantastic.

Been watching #consul IRC for a while now though, and the vast majority of the
setup problems are due to Docker's weird networking and security. Fabio/Consul
run like a charm but Docker throws a wrench in the machine.

------
codehusker
The Open Container Initiative is an important step towards some form of
standardization for the future of containers, and I think the Linux Foundation
will steward the project well.

------
sengork
Standardisation at the format level will help with portability across
different platform implementations.

~~~
wmf
This "standardization" is pretty kludgey if you have to docker pull then
docker export.

~~~
alex1
I think that's because OCI currently only has a specification for the runtime,
not the distributable image. But it seems like as of a few weeks ago, work is
underway to standardize the distributable image as well:
[https://github.com/opencontainers/image-
spec](https://github.com/opencontainers/image-spec)

~~~
kalmar
I was almost excited! From the FAQ on the project you linked [0]:

> Q: Why doesn't this project mention distribution?

> A: Distribution, for example using HTTP as both Docker v2.2 and AppC do
> today, is currently out of scope on the OCI Scope Table. There has been some
> discussion on the TOB mailing list to make distribution an optional layer
> but this topic is a work in progress.

I really hope CoreOS manage to get distribution into the scope for OCI. We
need to move beyond Docker images. Standardizing on-disk layout in OCI is only
mildly useful in my opinion.

[0] [https://github.com/opencontainers/image-
spec#faq](https://github.com/opencontainers/image-spec#faq)

------
ageofwant
"As an example, 1.11 is a huge step toward allowing Engine restarts/upgrades
without restarting the containers, improving the availability of containers."

This is great.

------
emdd
ELI5 the OCI & why it's important? I follow Docker from a distance and find it
fascinating.

~~~
shykes
Disclaimer: I work at Docker.

Docker has become a de facto standard for executing programs in a portable
sandbox (aka "container"). There were increasing demands for making it a
"proper" standard, so last year we donated a spec and reference implementation
for a universal intermediary format - a "PDF of containers" if you will, and
partnered with the Linux Foundation to manage it. The majority of the industry
followed.

Now that the Docker container engine supports this intermediary format, and
other providers will soon follow suit, it reduces the risk of depending on one
provider. If you want to switch away from Docker, you can run your containers
elsewhere.

Now everyone can focus on building better tools, instead of trying to make
"their" format win. The result is better tools.

~~~
ysh7
Disclaimer didn't say you are the CEO.

I hope this guy does this again here,
[https://news.ycombinator.com/item?id=11379475](https://news.ycombinator.com/item?id=11379475)

~~~
tlrobinson
Solomon's comment and disclaimer seemed perfectly reasonable to me. Why does
it matter if he's the CTO or random employee?

------
HeadlessChild
Garbage collecting for the registry is a long overdue feature that is quite
critical. I'm glad to see that it's now possible.

------
amouat
I'm pretty happy about being able to add labels to `docker build` - now it
should be possible to easily associate a git hash of the code that was used to
build the container.

------
Perceptes
> A few months ago we added the ability to sign images with hardware Yubikeys
> in the experimental channel of Docker. This is now available in the stable
> release.

I understand that you used to have to install a separate version of Docker to
access this feature, but does the change in 1.11 also mean you no longer have
to set the DOCKER_CONTENT_TRUST environment variable, or will that be made
default at a later time?

~~~
cpuguy83
Still need to either set the envvar or pass the equivalent flag.

------
rodionos
Correct link to v11.0 change log:
[https://github.com/docker/docker/blob/bump_v1.11.0/CHANGELOG...](https://github.com/docker/docker/blob/bump_v1.11.0/CHANGELOG.md).
The article links to master changelog which is 1.10.

------
SloopJon
Somewhat off topic, but docker-compose finally works on the old iMac I use at
work:

[https://github.com/docker/compose/issues/271](https://github.com/docker/compose/issues/271)

------
mhd
As someone who spent too much time with Oracle, this headline is quite
confusing (OCI => Oracle Call Interface). Computing has a serious TLA issue.

~~~
unexistance
ha, googling gives me OCI Open Catalog Interface, some SAP standard for SRP
software, which makes no sense in docker context, at all :D

------
DanielDent
Does this mean we are now at a point where LXD/LXC & docker will play nicely
with each other?

~~~
tyingq
I don't see any movement towards the OCI spec by the LXC/LXD team. Canonical
isn't shown on the list of members
([https://www.opencontainers.org/about/members](https://www.opencontainers.org/about/members)).

This answer from Mark Shuttleworth seems to sum up their position:
[https://answers.launchpad.net/ubuntu/+question/268502](https://answers.launchpad.net/ubuntu/+question/268502)

