91–100 of 103 posts
So instead of a Dockerfile we now need a builder.toml file. In addition you need a detect and build script: https://buildpacks.io/docs/create-buildpack/building-blocks-... Is this really a simplification?
Yes, because for end-user developers, you don't need any files. The files you mentioned are used by buildpack authors.
Earlier quoted context omitted.
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.
I just like the philosophy of docker, although I am recognizing here the implementation has some warts. also, if you're just a user of docker you might not care about dockerfiles. (like most people building software don't care about the Makefiles and prefer not to look at them)
Earlier quoted context omitted.
Layers?
But aren't they just an implementation detail, albeit a useful one? You'd find copy-on-write deltas in modern snapshotting filesystems too.
Part of what we do in Cloud Native Buildpacks is to use the layer abstraction more aggressively to make image updating more efficient. That requires taking care with the ordering and contents of each layer, so that they can be replaced individually.
Putting it another way: we don't see the image as the unit of work and distribution. We're focused on layers as the central concept.
Earlier quoted context omitted.
Image rebasing and layer reuse really matter at scale. Patching base images for many images simultaneously in a registry is a huge win if you are an organization running thousands of containers and there is a CVE in one of the OS packages in your base image. Optimizing data transfer similarly matters when you add up the gains across many containers. And devs like fast builds too :) I also don't really see how this pr…
The incompatibility I mentioned is with Dockerfiles. You’re right that more flexible patching and optimizing transfers are valuable. But those problems are independent of build frontends: you could solve them once for both buildpacks and Dockerfiles. In fact buildkit is well on its way to doing exactly that. Basically I would prefer if buildpacks and Dockerfiles could all be built with the same tooling. CNB seems lik…
You can build an image with both technologies, but that's not the key to the argument. The key here is every Dockerfile is unique and potentially quite different from any other Dockerfile. Small differences in layer order and layer contents multiply to very large inefficiencies at scale.
The way you tackle this problem is to make the ordering and contents of layers predictable for any given software that is being built. You can achieve this with Dockerfiles with golden images, strict control of access to Dockerhub, complicated `FROM` hierarchies, the whole shebang.
But at that point you are reinventing buildpacks, at your own expense.
Note that this doesn't change with or without buildkit.
> a new build format, and a new build implementation. Docker is going in the opposite direction by unbundling the format (Dockerfile) from the implementation (buildkit).
Is your understanding that we invented a new image format or that we rewrote most of Docker? Or that the way we've written it prevents, for all times and all purposes, adopting buildkit as part of the system in future?
Because both of those are misapprehensions. We have extensively reused code and APIs from Docker, especially the registry API.
This seems written from an outdated perspective of Dockerfiles -- multi-stage builds landed in Docker 17.05 which are almost a year old and address most of the concerns in the article...
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...
This feature currently does not work with the OS X ssh agent: https://github.com/docker/for-mac/issues/410
https://medium.com/@tonistiigi/build-secrets-and-ssh-forward...
the link you've supplied regards ssh access when running docker images, not when building them.
... i did notice that for lots of downloads, it is somewhat slower, or perhaps more prone to lag, than authentication from inside the running image.
”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.
Generally speaking I don’t know of many dev teams that enjoy OS and middleware patching or the nuances of Linux security. Some do of course, but many just want to code.
Buildpacks’ vision is that the ops team already knows how to install run production systems and that knowledge is encoded and tweaked in a buildpack.
It took me a while to get the pun, it doesn't show up in the article anywhere from what I could fine and I don't actually see how you're defending against anything here so I wonder - Did you just have this pun sitting around and were itching to use it somewhere, anywhere?
Personally, I still don't get it; would you please care to explain? I'm really confused with what does the title really try to convey... :/ edit: Also, clicking to the article, the actual title seems (now?) to be: "Turn Your Code into Docker Images with Cloud Native Buildpacks" , so I'm even more confused now... o_O
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.
Earlier quoted context omitted.
The incompatibility I mentioned is with Dockerfiles. You’re right that more flexible patching and optimizing transfers are valuable. But those problems are independent of build frontends: you could solve them once for both buildpacks and Dockerfiles. In fact buildkit is well on its way to doing exactly that. Basically I would prefer if buildpacks and Dockerfiles could all be built with the same tooling. CNB seems lik…
> But those problems are independent of build frontends: you could solve them once for both buildpacks and Dockerfiles. You can build an image with both technologies, but that's not the key to the argument. The key here is every Dockerfile is unique and potentially quite different from any other Dockerfile. Small differences in layer order and layer contents multiply to very large inefficiencies at scale. The way you…
Can you provide an example of how layer order can cause an issue?