Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defence Against the Docker Arts

blog.heroku.com

Post reply on HN
Print view View original

51–60 of 103 posts

Re: Defence Against the Docker Arts

#51

Post by jacques_chester »

wmf wrote: post #40

I just saw a submission on the "demise" of Cloud Foundry (a Heroku-like PaaS) that's relevant to this discussion: https://medium.com/@krishnan/lessons-from-the-demise-of-clou... Opinionated Platforms Are Risky: The CloudFoundry platform was more opinionated than some competing platforms in the market. In fact, the biggest debate between CloudFoundry and its direct competitors was about whether customers need opiniona…

> But there's no buildpack for something like a database and there probably never will be

That's why Cloud Foundry pioneered the Open Service Broker API.

For what it's worth, that article's recounting of history has substantial variations from my own recollection of history.

Re: Defence Against the Docker Arts

#52

Post by jacques_chester »

justinsaccount wrote: post #41
benbristow wrote: post #8

I love the fact Heroku have open-sourced their buildpacks. Dokku takes great use of these and provides a very similar platform to themselves that you can host yourself (DigitalOcean even provide a base-image that will pre-configure Dokku for you). Great for personal websites and the like. If you want to scale in a pinch then it's a case of making some tiny tweaks and pushing to Heroku instead.

I run some things at home using dokku and I switched them all to use Dockerfiles since the buildpacks are crazy slow. Not 100% sure if that is the fault of the dokku implementation or buildpacks in general though. It's all IO related, so I might not even have noticed it had I had faster disks.

Cloud Native Buildpacks are substantially faster in a number of scenarios. Some of the preliminary Java buildpack changes on the Cloud Foundry side have updates dropping from minutes to milliseconds.

Re: Defence Against the Docker Arts

#53

Post by jacques_chester »

caust1c wrote: post #9

It's not a case of buildpacks vs dockerfiles. They both solve different problems with different solutions. Buildpacks fit nicely into the heroku way of doing things. But at any medium to large sized engineering organization, there's no way they could satisfy the requirements for even a simple majority of services that using a Dockerfile provides.

Could you give an example of such requirements?

Disclosure: I've worked on Cloud Foundry Buildpacks twice and worked on this latest effort until recently.

Re: Defence Against the Docker Arts

#54

Post by jacques_chester »

kevinsimper wrote: post #24

I like they way they highlight that combining Ruby and nodejs makes for a complicated Dockerfile, while their example after only includes Ruby and not nodejs. And do they propose a buildpack called ruby-nodejs, because in many cases you don't need nodejs in your Ruby app. OMG now buildpack's are a leaky abstraction!

The CNB design allows buildpacks to opt in or out as a group. So the same nodejs buildpack can work in multiple usecases. With ruby, java, whatever's necessary.

Re: Defence Against the Docker Arts

#55

Post by jacques_chester »

m463 wrote: post #45

I'm a novice docker user, but I found Dockerfiles to be probably the most direct, graspable, important part of docker. It's one readable text file used to recreate an entire environment. It's sort of a picture worth a thousand command lines. That said, I wish there was a way to get rid of all the && stuff, which is used to avoild writing a layer of the filesytem. Why not have something like: RUN foo RUN bar RUN bletc…

When I first encountered Cloud Foundry, here's the arduous journey I had to first undertake to learn how to use buildpacks:

    cf push
Whereas with Dockerfiles I had to learn several commands and a lot of exciting gotchas.

Re: Defence Against the Docker Arts

#56

Post by jacques_chester »

sytse wrote: post #37
yRetsyM wrote: post #19

Gitlab would benefit from this in the context of their autodevops featureset

For sure! I was wondering about the same question and asked the team in https://www.dropbox.com/s/lcdlpz2l46e1uu1/Screenshot%202019-...

Please come visit us! We'd love to help. https://buildpacks.slack.com

Re: Defence Against the Docker Arts

#57

Post by jacques_chester »

imhoguy wrote: post #26
jtwaleson wrote: post #4

I've always felt that buildpacks in Heroku / Cloud Foundry are the way to go as they offer a higher level of abstraction than Docker files. The resulting containers are often production ready with good default settings. In docker you are re-inventing the wheel more often than not.

With Dockerfiles you can achieve high level abstractions by using proven images and composing multi-stage build assets. And then you can customize them with some lower level abstraction by in-line bash or independent scripts. E.g. look at phusion/baseimage or phusion/passenger - they are production ready and with good defaults. But you also have an easy way to augument them with latest ffmepg compiled from sources to…

I don't think I'd argue that you can't do what buildpacks do with Dockerfiles.

Basically, why do the work yourself? Especially if someone else will solve the weird problems and keep everything up to date with no effort on your part.

I know from personal experience that buildpacks maintainers have seen stuff you people wouldn't believe. Attack ships on fire off the shoulder of -02. gcc beams glittering in the dark near the Nokogiri gate.

Re: Defence Against the Docker Arts

#59

Post by zapita »

sclevine wrote: post #47
zapita wrote: post #10

Here’s a little known fact: “docker build” can trivially be extended to build buildpacks or CNB. Now that the buildkit refactoring is complete, Dockerfiles are just the default frontend. There’s already a buildpack frontend in the community repo, and it works great. Writing your own frontend is real straightforward. Honestly after years of stagnation, the most exciting work on container building is now coming out of…

While I really appreciate the work tonistiigi did to create the Cloud Foundry buildpack frontend for buildkit, it uses a compatibility layer[1] (which I wrote myself and no longer maintain) that only works with deprecated Cloud Foundry buildpacks that depend on Ubuntu Trusty. It doesn't work with the new, modular Cloud Native Buildpacks, and the buildpacks that ship with it are outdated (and vulnerable to various CVE…

Your answer makes sense, but it actually makes me less excited about CNB.

It sounds like CNB will break compatibility with the massive Dockerfile ecosystem, in exchange for... sometimes not downloading a layer? That is not appealing to me at all, because Dockerfiles are too embedded in my workflow, losing support for them is simply not an option.

As for unprivileged builds, I don’t see any reason buildkit can’t support it since it’s based on containerd.

I think it’s a mistake not to jump on the buildkit/docker-build bandwagon. You would get a 10x larger ecosystem overnight, basically for free. Instead it seems like you’re betting on CNB as a way to “kill” Dockerfiles. But users don’t actually want to kill anything, they want their stuff to continue working. Without a good interop story, you’re pretty much guaranteeing that CNB will not get traction outside of the Pivotal ecosystem. Seems like a shame to me.

Re: Defence Against the Docker Arts

#60

Post by nhumrich »

m463 wrote: post #45

I'm a novice docker user, but I found Dockerfiles to be probably the most direct, graspable, important part of docker. It's one readable text file used to recreate an entire environment. It's sort of a picture worth a thousand command lines. That said, I wish there was a way to get rid of all the && stuff, which is used to avoild writing a layer of the filesytem. Why not have something like: RUN foo RUN bar RUN bletc…

The && is just layer squashing and not really needed. You can just use run on every line. Docker even supports squashing images now, so the && doesn't matter if you squash.
Post reply on HN