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

41–50 of 103 posts

Re: Defence Against the Docker Arts

#41

Post by justinsaccount »

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.

Re: Defence Against the Docker Arts

#43

Post by meowface »

theptip wrote: post #39
meowface wrote: post #38

Earlier quoted context omitted.

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.

You do have to pass an extra "--ssh default" argument to "docker build", so it's not totally automagical or anything.

Re: Defence Against the Docker Arts

#44

Post by ekcasey »

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…

Now that Cloud Native Buildpacks build OCI images instead of platform specific artifacts (slugs or droplets), developers can choose the best build solution for their problem (buildpacks for 12-factor apps, Dockerfiles for a data store)and deploy them to the same container orchestrator.

Re: Defence Against the Docker Arts

#45

Post by m463 »

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 bletch
    LAYER

Re: Defence Against the Docker Arts

#47

Post by sclevine »

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 CVEs). It will stop working with new buildpack versions entirely when Cloud Foundry drops support for Trusty.

Implementing CNBs as a buildkit frontend would break key security and performance features. For instance, CNBs can build images in unprivileged containers without any extra capabilities, which buildkit cannot do. CNBs can also patch images by manipulating their manifests directly on a remote Docker registry. This means that image rebuilds in a fresh VM or container can reuse layers from a previous build without downloading them (just metadata about them), and base images can be patched for many images simultaneously with near-zero data transfer (as long as a copy of the new base image is available on the registry). As far as I know, buildkit can't do any of that yet.

That said, we do plan on using buildkit (once it ships with Docker by default) to optimize the CNB pack CLI when you build images without publishing them to a Docker registry. It's a huge improvement over the current Docker daemon implementation for sure!

[1] https://github.com/buildpack/packs

Re: Defence Against the Docker Arts

#48

Post by jacques_chester »

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…

When we started, buildkit was still experimental. Personally I'd like for `pack` to be able to jettison all the code that has to deal with the Docker daemon, it's a bit of a PITA, and buildkit looks to have significant improvements in at least that area.

I'd note that the frontend there is for "v2b" buildpacks -- the previous generation of Cloud Foundry buildpacks. The CNB lifecycle has changed a fair amount from the v2a (Heroku) and v2b designs.

Re: Defence Against the Docker Arts

#49

Post by sclevine »

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…

The presentation to the CNCF TOC covers some of the technical details: https://www.youtube.com/watch?v=uDLa5cc-B0E&feature=youtu.be

Some key points:

- CNBs can manipulate images directly on Docker registries without re-downloading layers from previous builds. The CNB tooling does this by remotely re-writing image manifests and re-uploading only layers that need to change (regardless of their order).

- CNB doesn't require a Docker daemon or `docker build` if it runs on a container platform like k8s or k8s+knative. The local-workstation CLI (pack) just uses Docker because it needs local Linux containers on macos/windows.

Re: Defence Against the Docker Arts

#50

Post by jacques_chester »

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…

> How does it work?

The OCI image format expresses layer order as an array of digests. Essentially, "read the blobs with these SHAs in this order, please".

Cloud Native Buildpacks have predictable layouts and layering. A buildpack can know that layer `sha256:abcdef123` contains (say) a .node_modules directory. It can decide to update only that layer, without invalidating any other layer.

And the operation can be very fast, because you can do it directly against the registry. GET a small JSON file, make an edit, POST it back.

This is a big deal because under the classic Dockerfile model, changes in a lower layer invalidate the higher layers. But this means your image can be invalidated by OS layer changes, dependency changes and so on. It's the right policy for Docker to have -- a conservative policy -- but Buildpacks have the advantage of additional context that lets them rely on other guarantees. Most noticeably ABI guarantees.

Post reply on HN