Closed flavorjones closed 9 years ago
Two things that I noticed --
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?
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.
Release notes are here.
Size reduced 30% from 633MB to 442MB.
Supports (full manifest here):
Full release notes are here.
Size reduced 83% from 417MB to 69MB.
Supports (full manifest here):
Full release notes are here.
Size reduced 27% from 1.1GB to 803MB.
Supports: (full manifest here)
PHP:
HHVM (lucid64 stack):
HHVM (cflinuxfs2 stack):
Apache HTTPD:
nginx:
Full release notes are here.
Size reduced 30% from 654MB to 454MB.
Supports: (full manifest here)
Release notes are here.
Size reduced 71% from 1.3GB to 365MB.
Supports: (full manifest here)
MRI:
JRuby:
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+
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:
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:
I'd like to move forward soon with the following changes:
An example for
#1
is that we'll go from packaging 34 versions ofnode
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 ofnginx
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: