Post has attachment
RHEL Atomic Host Ansible Playbook

A quick peak into the main configuration that goes into our RHEL Atomic host Ansible playbooks at $WORK. We try to keep it very minimal, setting up keys for Ansible using cloud-init, and then running the basic configuration with Ansible itself. Because the hosts are designed for running containers, there's very little configuration that goes into them.
Add a comment...

Post has attachment

Three Docker Build Strategies (that we use at $WORK)

Last week I was refactoring some of our CI build jobs for Docker images we use at work, and I realized that 90% or more of what we are doing fall into one of three types of build strategy. I wrote a post describing each type of build, and the pros and cons of each. I don't know what the "Official" names for these are, if in fact they are named at all, but it's a good representation of the majority of our image building in a production environment.

We might be unusual, having many, many small services rather than a company that has, say, a dozen services but runs them at massive scale. This means we are maintaining MANY MANY images - necessitating generic parent images and means to either automate specialized image creation, or configuration within containers created from generic images.

Add a comment...

Post has attachment
"No Handler for <some> Authentication" errors on Fedora/RHEL with Docker 1.12

Just getting around to setting up my new laptop and using Fedora for the first time, and it looks like there's a bug (being addressed) in Red Hat's version of Docker that tosses up an error trying to pull an image from a private registry:

No handler for Negotiate authentication on Fedora with private repository

(or BASIC authentication - depends on your auth scheme)

The work-around while Red Hat addresses the issue is to disable signing verification for now by adding "--signature-verification=false" to the OPTIONS value in /etc/sysconfig/docker.

Discussion here:
Add a comment...

Post has attachment

Something has apparently changed in either the centos:centos7 image, or the tar RPM. Up until this morning, I could:

RUN yum install -y tar \
&& <untar some things> \
&& yum remove -y tar

...and things worked fine.

This morning, though, `yum remove -y tar` flags the dracut package for removal, which flags the kmod package for removal, which flags systemd for removal...

...which is protected and errors out.

The quick workaround is to leave tar installed, but that's a shame. Why ship extra bits around if they're not needed?

Any suggestions from the brilliant Docker or RPM minds out there?
Add a comment...

I feel dirty

This might be the ugliest work-around I've ever written. There's a binary I have no control over, and it cannot be run in the foreground, but it needs to be in a Docker container.

Our chosen container init system is Runit. Like Docker, and Systemd, and Supervisord, and on and on), requires the program to be in the foreground to verify that it's running. But despite this, "Company X" produces a binary they want you to just kick off, and then walk away from. ARG

So, back to the dirty:

if [ -f "$PID_FILE" ]
while kill -0 $(cat $PID_FILE)
sleep 15

exit 1

Suggestions welcome, please.
Add a comment...

Post has attachment
Focusing on Container Standards

A well-represented community would be able to provide an excellent set of open standards around which to develop, and help to bring Docker et al to a whole new level.

#Docker #Containers
Add a comment...

Post has attachment
This has definitely been brewing

Other companies are starting to slowly layer open container standards and their own orchestration tools and processes under the "Docker Experience", as they realize that Docker is not addressing all of their concerns. It has always felt to me that Docker focused on the fast and agile and startup sphere, despite Enterprise customers having SO much to gain from container tech, and SO much money/time/talent to put into the project.

That's not to say Docker is failing them - surely it's difficult to focus on all needs while trying to maintain your product as an open project. (I cannot take credit for that thought - stolen directly from Kelsey Hightower on Twitter).

I would not agree that a fork is needed, but perhaps Docker, the company, can move toward being a part of a larger container culture. It's hard I'm sure to give up full control, but a community driven standard will benefit everyone, and hopefully Docker can continue to profit from their other products and tools.

#Docker #Containers
Add a comment...

Post has attachment
Took a little longer than I'd care to admit to figure out a #Docker Registry v2 with Apache & mod_auth_kerb for authentication, but it's working for me now in testing.

The whole thing is containerized, of course.

Now to get a #Swift object store working for the storage. With that piece, I think we'll be able to effectively load-balance the whole thing!
Add a comment...

Post has attachment
Hey, since +Google+ announced their new Collections feature, I figured this was the natural first step to take in using them.  *Docker post collection!*

Weird thing I've found going back into old posts to add to the collection.  Some of them don't have that option.  It's not that they're too far in the past to be added - those further down can still be added.  I wonder what restrictions, if any, exist on what can be in a collection.
Add a comment...

Post has attachment
This is certainly the right move for CoreOS.  They always said they were dedicated to a more "standard" container format that what Docker was evolving into, and the only way to evolve that really was to turn over the standard to a multi-group foundation charged with it's oversight.

(Via +Erich Huang; thanks!)
Add a comment...
Wait while more posts are being loaded