Lmctfy – Let Me Contain That for You | Hacker News Reader

Lmctfy – Let Me Contain That for You

github.com

52 pointstvvocold23 comments

As a former Google SRE, I'm pretty annoyed with the number of abstractions, indirections, and arbitrary features being pumped into docker. The core concept of Containers is supposed to be that you write to the unix process model, and the process model alone; Not create new systems from whole cloth in overly abstract ways.

This doesn't work for a lot of legacy systems, but rather than port or write new systems to do those functions, the Docker model seems to have absorbed all the hacks without documenting any of the best practices, allowing anyone who's going about creating new systems to wander off into the weeds of subfeatures and hacks.

Unfortunately, the LMCTFY project seems to be dead; They're porting features into the already bloated libcontainer, though I'm certain the borglet it is based on stays fairly pristine. LMCTFY and the google stack are a very different style of systems administration than is currently in vogue; but together they create a beautiful and pristine ecosystem with very few rough edges.

Anyway: If you want to know what you should be building with Docker, figure out how you would build it with just what LMCTFY provides. Some of it is non-obvious (Service discovery is a core service that exists in many forms, but few that are analogous/replacements for what the google stack needs), but by paring down what you work with, you ultimately create much tighter, more reliable systems.

My problem with Docker is not the abstractions - you need to learn to live with them as they're not going anywhere. I would [probably] be willing to make the [required] security trade offs and maybe even the complexities and workarounds.

My biggest problem is still the amount of noise despite project being alive for over 2 years now. Therefore what you said in:

> "the Docker model seems to have absorbed all the hacks without documenting any of the best practices,"

resonates a lot with me.

From the community point of view the ecosystem, despite having some really smart people involved, is swarming with vendors. This is probably good for Docker as a technology company which must be striving to be omnipresent/ubiquitous, but can be [and often is] detrimental for the end users: developers and operators.

Saying that Docker is still young, writing good software of Docker scale is tough and takes time, especially given the circumstances I've mentioned above. So let's see where Docker leadership will drive the project.

> I'm pretty annoyed with the number of abstractions, indirections, and arbitrary features being pumped into docker

You have to keep adding features in order do get funding. I call it Funding Driven Programming (FDP)

> You have to keep adding hype in order do get funding. I call it Hype Driven Funding (HDF).

Fixed that for you.

Glad to see I am the only one that seems to think there is a lot of hype about Docker. Sure I can see it being useful in a few cases, but we have had virtualenv in Python for ages, and virtual machines as well. What can Docker do that I can't in these two?

Give developers a sense that they somehow dont need sysadmins/ops staff?

To me Docker seems to provide a visualization at a level between virtualenv (which provides it at the Python environment level) and a virtual machine (which is at the machine level). I am sure there are cases where that is useful, but for me, I can't see many cases where its superior to the other two options.

In my workplace, I have control over the virtualenv and generally the sysadmins have control of virtual machines. I can ask nicely and they sometimes they will give me root access. Even if they don't, I know how to install packages without root access (if it is something I think is worth the effort). Sometimes (most of the time) its easier to let sysadmins do that stuff for me. Docker isn't going to improve much on that.

You're probably exactly right. Being everything to everyone is a great way to get investors; It's no way to write an infrastructure service, however.

That's an awfully unfair assumption.

Docker core is still not as secure nor as humane as I would hope for from a 1.0 release, but they're investing all their time into compose, swarm, machine, most of which are barely more mature than a hackathon project. The libcontainer partnerships are great, but yeah, I think you're exactly right, all the funding has tainted their core mission.

Hi, having started Docker I am of course biased, but I thought I'd bring some data to this conversation.

Last 30 days on Docker Compose: 45 PRs merged from 26 people

Full time Docker employees on Compose: 1

Last 30 days on Docker Machine: 39 PRs merged from 33 people

Full time Docker employees on Machine: 1

Last 30 days on Docker Swarm: 50 PRs merged from 21 people

Full time employees on Swarm: 3

Last 30 days on Docker core: 265 PRs merged from 161 people

Full time employees on core: 8

The lmctfy authors are now core maintainers of runC (and its underlying libcontainer) which they built together with Docker core maintainers. Together they built something robust and operationally sound, based on their combined experience running containers in production.

Overall, lots of great tools being developed, at different levels of maturity, some focused on low-level operations and some focused on helping developers. I don't understand the negativity.

Edit: the lmctfy authors, unlike the grand-parent in this thread, have been super pragmatic about the pros and cons of the Google stack vs others. They realize that it's a big and complex world out there, and that not every computer system can make the same simplifying assumptions as Google. Only a relatively unexperienced SRE would assume that you can build any system on top of their employer's custom tools, unmodified. To take an obvious example: nested cgrouls and performance profiles are really sweet, but last I checked, net namespace support was not a priority because "we don't need it at Google". Welcome to the real world, GauntletWizard.

I'm sorry if I sounded condescending to you, but it's pretty clear that organizations with a strong engineering focus need a strong and clear vision of how components integrate - and the current state of docker actively discourages that. The ability to shove tools together willy-nilly, hacking around their incompatibilities, does not a solid platform create. Some of your biggest features, like the various networking modes, are complete misfeatures; The only reason you need bridge mode is bad network layout, the only reason for container is because you've screwed it up and you're using bridge mode.

Both the dockerfile reference and run reference are incredibly long and filled with references to strange interactions with other features. The fact that features don't interact in ways that can be simply reasoned about but instead clarification is required is a huge red flag in core infrastructure.

Docker has done wonderful things in terms of getting people to think about their services rather than their hosts. But each new feature reduces that advantage, as it allows people to take lazier approaches to integrate their systems, and those approaches flat-out don't work.

As a side note, is there any way to view a graph of open PRs over time? It could be a good test of the health of a repo.

I just look at the "pulse" section on github. We also have an internal tool which we query for more complex queries (contributor retention across projects, things like that).

https://docs.docker.com/articles/security/

That's great and all, but that article is over a year old, a time when there were still several methods of shelling out to the host OS.

> without documenting any of the best practices

What kind of best practices are you thinking about? Any pointers?

When I heard John Wilkes speak recently it sounded as if Google was actually intentioned on moving to libcontainer (but not full fledged Docker).

Sounds at least superficially like libvirt-sandbox. Libvirt-sandbox has the possible advantage that with a single switch you can use either a container or a full virt (qemu) process to contain the task.

> lmctfy (pronounced l-m-c-t-fi, IPA: /ɛlɛmsitifаɪ/)

I always read this as "lamictify", having worked with patients on 'lamictal' for a few years.

I've heard it pronounced lim-cut-fee, so if I ever said the word out loud, that's probably how I'd pronounce it too...

A lot of googlers even pronounce it differently. Glad the repo finally takes a stand!

Google knows how not to use GPL AIDS licenses, thanks!

Reply on news.ycombinator.com