Defence Against the Docker Arts • Hacker News Board

Re: Defence Against the Docker Arts

#31

Post by corndoge » Wed, Apr 03, 2019, 9:06 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.

Why learn how to do it right when you can just ship a filesystem in a box instead? sbuild manpage is too long!

Re: Defence Against the Docker Arts

#32

Post by molszanski » Wed, Apr 03, 2019, 9:19 PM UTC

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!

If only we lived in a universe where there was an easy to find and ready to use dockerpack ruby-node. Oh wait.

Re: Defence Against the Docker Arts

#33

Post by molszanski » Wed, Apr 03, 2019, 9:22 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…

Thank you for sharing this!

Re: Defence Against the Docker Arts

#34

Post by 420codebro » Wed, Apr 03, 2019, 9:23 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.

I'm confused - what is the alternative you are advocating?

Said micro-service is coded in X, requiring Y libraries, etc.

Docker satisfies packaging all of that together, removing host-OS dependency hell (who the fuck wants to go back to that stupid shit?)

Re: Defence Against the Docker Arts

#35

Post by bshipp » Wed, Apr 03, 2019, 9:34 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…

What the heck, how is it that I haven't seen these yet? Maybe one of the downfalls of becoming comfortable enough with the syntax that I'm not having to look up documentation on the docker website anymore is that I'm more and more out of the loop on this stuff.

Thanks for posting that!

Re: Defence Against the Docker Arts

#36

Post by codefinger » Wed, Apr 03, 2019, 10:02 PM UTC

Perceptes wrote: post #27

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…

There's some more detail here: https://buildpacks.io/docs/

Re: Defence Against the Docker Arts

#37

Post by sytse » Wed, Apr 03, 2019, 10:16 PM UTC

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-...

Re: Defence Against the Docker Arts

#38

Post by meowface » Wed, Apr 03, 2019, 10:32 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…

My favorite Docker BuildKit feature is SSH agent forwarding. Add "--mount=type=ssh" after RUN commands in Dockerfiles and the command will use your host machine's SSH agent. I've been able to greatly simplify a lot of Dockerfiles and CI build processes using it.

There's a good introduction here: https://medium.com/@tonistiigi/build-secrets-and-ssh-forward...

Re: Defence Against the Docker Arts

#39

Post by theptip » Wed, Apr 03, 2019, 10:55 PM UTC

meowface wrote: post #38

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…

My favorite Docker BuildKit feature is SSH agent forwarding. Add "--mount=type=ssh" after RUN commands in Dockerfiles and the command will use your host machine's SSH agent. I've been able to greatly simplify a lot of Dockerfiles and CI build processes using it. There's a good introduction here: https://medium.com/@tonistiigi/build-secrets-and-ssh-forward...

Oh, that's nice -- that's been a pain point for a long time, and it seemed like there was a philosophical argument against making the Dockerfile's behaviour context-dependent like this.

Re: Defence Against the Docker Arts

#40

Post by wmf » Wed, Apr 03, 2019, 10:56 PM UTC

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 opinionated platforms or not. CloudFoundry only supported 12 factor applications whereas platforms built on top of Kubernetes could support both stateful and stateless (12 factor) applications.

If you're building a stateless 12-factor app and there's a buildpack that does what you want, buildpacks are clearly better than lower-level Dockerfiles. But there's no buildpack for something like a database and there probably never will be, so the flexibility of directly building containers needs to exist.