4 ms·

IIUC, you say Docker is a step backward from both Chef/Puppet and Heroku buildpacks. Why do you think it's a step backward from Heroku buildpacks? Because a Doc

IIUC, you say Docker is a step backward from both Chef/Puppet and Heroku buildpacks. Why do you think it's a step backward from Heroku buildpacks? Because a Docker image is the whole userland, whereas Heroku buildpacks deliver application slugs that run on a base maintained by the platform? I see a couple of problems with the Heroku buildpack approach: 1. Because buildpacks don't run as root, they can't take advantage of apt and the whole universe of Debian/Ubuntu packages. So it's common to see buildpacks pulling binary tarballs from S3 and dropping them into the slug. That is a step backward to me. 2. The set of packages in the base platform, at least for the Heroku Cedar stack, is very ad-hoc. I get the impression that it was largely based on what was needed to get Ruby and common gems to work.

jacques_chester 11y ago
I worked on the Cloud Foundry buildpacks team for a while, so I have seen the good and the bad of the buildpacks approach. But actually using Docker in anger has made me appreciate buildpacks more than I used to. Docker is step back in some respects, analogous to how lower-level languages are step back in some respects from higher-level languages. As for your questions: 1. A buildpack is meant by design to be an opinionated builder for a particular stack, not a totally pluripotent environment. If you need total control, you can have it by using Docker and sending those images to run on CF. The binaries you see being pulled in are either specifically built by Heroku for Heroku or by Cloud Foundry for Cloud Foundry. They're not random links plucked out of a Google search. It's not as though the Debian team aren't building binaries too. 2. The set of packages for Cloud Foundry in the "stack"[1] or rootfs is set by the buildpacks team, based on balancing the needs of various buildpacks consumers. Heroku do something similar. It's ad hoc insofar as any extremely consumed library is ad hoc. The concept of buildpacks is that you, the developer, don't have to care about what is installed. You throw code over the wall and it launches. For operators, the attraction is that there is a single known base environment and that it can be upgraded easily when CVEs are announced. In theory a Docker container can be whittled down to the minimum dependencies needed to run the software, but it requires tedious and often difficult-to-understand effort, so very few people do it. And indeed the whole reason to go through that effort is to make smaller images. When you have a single reference image, that argument is largely moot. [1] https://github.com/cloudfoundry/stacks https://github.com/cloudfoundry/stacks

jacques_chester 11y ago

I worked on the Cloud Foundry buildpacks team for a while, so I have seen the good and the bad of the buildpacks approach. But actually using Docker in anger has made me appreciate buildpacks more than I used to. Docker is step back in some respects, analogous to how lower-level languages are step back in some respects from higher-level languages. As for your questions: 1. A buildpack is meant by design to be an opinionated builder for a particular stack, not a totally pluripotent environment. If you need total control, you can have it by using Docker and sending those images to run on CF. The binaries you see being pulled in are either specifically built by Heroku for Heroku or by Cloud Foundry for Cloud Foundry. They're not random links plucked out of a Google search. It's not as though the Debian team aren't building binaries too. 2. The set of packages for Cloud Foundry in the "stack"[1] or rootfs is set by the buildpacks team, based on balancing the needs of various buildpacks consumers. Heroku do something similar. It's ad hoc insofar as any extremely consumed library is ad hoc. The concept of buildpacks is that you, the developer, don't have to care about what is installed. You throw code over the wall and it launches. For operators, the attraction is that there is a single known base environment and that it can be upgraded easily when CVEs are announced. In theory a Docker container can be whittled down to the minimum dependencies needed to run the software, but it requires tedious and often difficult-to-understand effort, so very few people do it. And indeed the whole reason to go through that effort is to make smaller images. When you have a single reference image, that argument is largely moot. [1] https://github.com/cloudfoundry/stacks https://github.com/cloudfoundry/stacks