Defence Against the Docker Arts • Hacker News Board

Re: Defence Against the Docker Arts

#21

Post by ImJasonH » Wed, Apr 03, 2019, 7:58 PM UTC

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…

Link to the buildpack frontend for docker: https://github.com/tonistiigi/buildkit-pack

Re: Defence Against the Docker Arts

#22

Post by Polyisoprene » Wed, Apr 03, 2019, 7:58 PM UTC

”Mixing operational concerns with application concerns like this results in a poor tool for developers who just want to write code and ship it as painlessly as possible.”

Yeah, throw that code over to the ops team. Let them figure stuff out themselves.

Re: Defence Against the Docker Arts

#23

Post by choeger » Wed, Apr 03, 2019, 7:59 PM UTC

You are setting up an entire operating system to install a single Microservice and just now noticed that you have redundancies?

You could have the same issue by simply trying to rpmbuild your app. No really, you are just doing packaging. If you want more comfort, look into how redhat or Debian maintain their packages. They have similar problems and most likely they have mature solutions.

Re: Defence Against the Docker Arts

#24

Post by kevinsimper » Wed, Apr 03, 2019, 8:01 PM UTC

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!

Re: Defence Against the Docker Arts

#25

Post by sushisushisushi » Wed, Apr 03, 2019, 8:04 PM UTC

Polyisoprene wrote: post #22

”Mixing operational concerns with application concerns like this results in a poor tool for developers who just want to write code and ship it as painlessly as possible.” Yeah, throw that code over to the ops team. Let them figure stuff out themselves.

I really don't get this, and I'm a very lazy developer. You can't ship code painlessly if you don't consider any of the operational concerns. Operational concerns are application concerns. It doesn't matter how wonderful and ingenious your code is if it can't run anywhere.

Re: Defence Against the Docker Arts

#26

Post by imhoguy » Wed, Apr 03, 2019, 8:06 PM UTC

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 support some exotic format for video conversion worker.

Re: Defence Against the Docker Arts

#27

Post by Perceptes » Wed, Apr 03, 2019, 8:10 PM UTC

I wish this had gone into some more technical detail about what "CNB" does that is actually better. Most of the article was just rehashing some problems with Dockerfiles, but the conclusion is just "CNB fixes it!" The one specific improvement they mention is being able to "rebase" an image without rebuilding the whole thing, which certainly sounds interesting, but is not explained. How does it work? What else is CNB other than a wrapper around `docker build`?

Re: Defence Against the Docker Arts

#28

Post by rhizome » Wed, Apr 03, 2019, 8:31 PM UTC

krainboltgreene wrote: post #16

chusk3 wrote: post #7

Earlier quoted context omitted.

You don't have to have separate dockerfiles. If you use multistage builds, you can name the specific terminal stages and then invoke them with 'docker build -t stagename', which will reuse the build cache as you'd expect. I've done this to export multiple app containers from a monorepo.

Yo, their example has multiple stages.

I think they're talking about intermediates, which wouldn't have to be rebuilt every time.

Re: Defence Against the Docker Arts

#29

Post by rhizome » Wed, Apr 03, 2019, 8:35 PM UTC

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 mean, I'm essentially a beginner (with lots of system experience), and I'm noticing a lack of intermediates in these comments.

Re: Defence Against the Docker Arts

#30

Post by viraptor » Wed, Apr 03, 2019, 8:39 PM UTC

choeger wrote: post #23

You are setting up an entire operating system to install a single Microservice and just now noticed that you have redundancies? You could have the same issue by simply trying to rpmbuild your app. No really, you are just doing packaging. If you want more comfort, look into how redhat or Debian maintain their packages. They have similar problems and most likely they have mature solutions.

If you have a single service and will never want more - sure. Once you have multiple, you actually get benefits if you depend on a lot of native libraries and external binaries. If you're in that situation, not having to upgrade every service at the same time when moving to a new base os release is really convenient.