Proposal to reduce buildpack sizes
flavorjones opened this issue · 5 comments
Buildpack Sizes
Where we are today
Many of you have seen, and possibly been challenged by, the enormous sizes of some of the buildpacks that are currently shipping with cf-release.
Here's the state of the world right now, as of v205:
php-buildpack: 1.1G
ruby-buildpack: 922M
go-buildpack: 675M
python-buildpack: 654M
nodejs-buildpack: 403M
----------------------
total: 3.7G
These enormous sizes are the result of the current policy of packaging every-version-of-everything-ever-supported ("EVOEES") within the buildpack.
Most recently, this problem was exacerbated by the fact that buildpacks now contain binaries for two rootfses.
Why this is a problem
If continued, buildpacks will only continue to increase in size, leading to longer and longer build and deploy times, longer test times, slacker feedback loops, and therefore less frequent buildpack releases.
Additionally, this also means that we're shipping versions of interpreters, web servers, and libraries that are deprecated, insecure, or both. Feedback from CF users has made it clear that many companies view this as an unnecessary security risk.
This policy is clearly unsustainable.
What we can do about it
There are many things being discussed to ameliorate the impact that buildpack size is having on the operations of CF.
Notably, Onsi has proposed a change to buildpack caching, to improve Diego staging times (link to proposal).
However, there is an immediate solution available, which addresses both the size concerns as well as the security concern: packaging fewer binary dependencies within the buildpack.
The proposal
I'm proposing that we reduce the binary dependencies in each buildpack in a very specific way.
Aside on terms I'll use below:
- Versions of the form "1.2.3" are broken down as: MAJOR.MINOR.TEENY. Many language ecosystems refer to the "TEENY" as "PATCH" interchangeably, but we're going to use "TEENY" in this proposal.
- We'll assume that TEENY gets bumped for API/ABI compatible changes.
- We'll assume that MINOR and MAJOR get bumped when there are API/ABI incompatible changes.
I'd like to move forward soon with the following changes:
- For language interpreters/compilers, we'll package the two most-recent TEENY versions on each MAJOR.MINOR release.
- For all other dependencies, we'll package only the most-recent TEENY version on each MAJOR.MINOR release.
- We will discontinue packaging versions of dependencies that have been deprecated.
- We will no longer provide "EVOEES" buildpack releases.
- We will no longer provide "online" buildpack releases, which download dependencies from the public internet.
- We will document the process, and provide tooling, for CF operators to build their own buildpacks, choosing the dependencies that their organization wants to support or creating "online" buildpacks at operators' discretion.
An example for #1 is that we'll go from packaging 34 versions of node v0.10.x to only packaging two: 0.10.37 and 0.10.38.
An example for #2 is that we'll go from packaging 3 versions of nginx 1.5 in the PHP buildpack to only packaging one: 1.5.12.
An example for #3 is that we'll discontinue packaging ruby 1.9.3 in the ruby-buildpack, which reached end-of-life in February 2015.
Outcomes
With these changes, the total buildpack size will be reduced greatly. As an example, we expect the ruby-buildpack size to go from 922M to 338M.
We also want to set the expectation that, as new interpreter versions are released, either for new features or (more urgently) for security fixes, we'll release new buildpacks much more quickly than we do today. My hope is that we'll be able to do it within 24 hours of a new release.
Planning
These changes will be relatively easy to make, now that all the buildpacks are using a manifest.yml file to declare what's being packaged. We expect to be able to complete this work within the next two weeks.
Stories are in our Tracker backlog under the Epic named "skinny-buildpacks", which you can see here:
Two things that I noticed --
- The link to Onsi's proposal is broken for anyone who can't access the pivotal-cf-experimental org.
- How will discontinuing support for "online" buildpacks affect people who are using
cf push -b https://github.com/cloudfoundry/some-buildpack? I imagine it won't immediately break, but that eventually, it'll break because we'd abandon testing that scenario.
Otherwise, it all looks good to me. Bravo, buildpacks team :)
Lovely!
+1
Why would you propose to use different terminology than the currently very well known standard that lives at semver.org?
Summary
Skinny buildpacks have been cut for go, nodejs, php, python and ruby buildpacks.
| | current | previous |
|--------+---------+----------|
| go | 442MB | 633MB |
| nodejs | 69MB | 417MB |
| php | 804MB | 1.1GB |
| python | 454MB | 654MB |
| ruby | 365MB | 1.3GB |
|--------+---------+----------|
| total | 2.1GB | 4.1GB |
for an aggregate 51% reduction in size. Details follow.
go-buildpack v1.3.0
Release notes are here.
Size reduced 30% from 633MB to 442MB.
Supports (full manifest here):
- golang 1.4.{1,2}
- golang 1.3.{2,3}
- golang 1.2.{1,2}
- golang 1.1.{1,2}
nodejs-buildpack v1.3.0
Full release notes are here.
Size reduced 83% from 417MB to 69MB.
Supports (full manifest here):
- 0.8.{27,28}
- 0.9.{11,12}
- 0.10.{37,38}
- 0.11.{15,16}
- 0.12.{1,2}
php-buildpack v3.2.0
Full release notes are here.
Size reduced 27% from 1.1GB to 803MB.
Supports: (full manifest here)
PHP:
- 5.6.{6,7}
- 5.5.{22,23}
- 5.4.{38,39}
HHVM (lucid64 stack):
- 3.2.0
HHVM (cflinuxfs2 stack):
- 3.5.{0,1}
- 3.6.{0,1}
Apache HTTPD:
- 2.4.12
nginx:
- 1.7.10
- 1.6.2
- 1.5.13
python-buildpack v1.3.0
Full release notes are here.
Size reduced 30% from 654MB to 454MB.
Supports: (full manifest here)
- 2.7.{8,9}
- 3.2.{4,5}
- 3.3.{5,6}
- 3.4.{2,3}
ruby-buildpack v1.4.0
Release notes are here.
Size reduced 71% from 1.3GB to 365MB.
Supports: (full manifest here)
MRI:
- 2.2.{1,2}
- 2.1.{5,6}
- 2.0.0p645
JRuby:
- ruby-1.9.3-jruby-1.7.19
- ruby-2.0.0-jruby-1.7.19
- ruby-2.2.0-jruby-9.0.0.0.pre1
Skinny buildpacks have made it into cf-release. You can view the PRs with this search:
https://github.com/cloudfoundry/cf-release/pulls?utf8=%E2%9C%93&q=is%3Apr+buildpack+skinny+