community
php-dist
community | php-dist | |
---|---|---|
2 | 1 | |
42 | 9 | |
- | - | |
6.5 | 8.4 | |
17 days ago | 4 days ago | |
Ruby | ||
Creative Commons Attribution 4.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
community
-
Buildpacks vs. Dockerfiles
A list of adopters (many of which are hosting providers) is here: https://github.com/buildpacks/community/blob/main/ADOPTERS.m...
-
Run More Stuff in Docker
Many comments here point out how difficult it is to manage a separate dependency stack for each container when you use Dockerfiles to build them. This problem is just as difficult, time-intensive, and security-critical for microservice apps running on K8s as it is for CLI tools and graphical apps.
Worth pointing out that there is an incubating CNCF project that tries to solve this problem by forgoing Dockerfiles entirely: Cloud Native Buildpacks (https://buildpacks.io)
CNB defines safe seams between OCI image layers so that can be replaced out of order, directly on any Docker registry (only JSON requests), and en-mass. This means you can, e.g., instantly update all of your OS packages for your 1000+ containers without running any builds, as long as you use an LTS distribution with strong ABI promises (e.g., Ubuntu 20.04). Most major cloud vendors have quietly adopted it, especially for function builds: https://github.com/buildpacks/community/blob/main/ADOPTERS.m...
You might recognize "buildpacks" from Heroku, and in fact the project was started several years ago in the CNCF by the folks who maintained the Heroku and Cloud Foundry buildpacks in the pre-Dockerfile era.
[Disclaimer: I'm one of the founders of the project, on the VMware (formerly Cloud Foundry) side.]
php-dist
-
Buildpacks vs. Dockerfiles
Relying on something like paketo may or may not be a great idea. I decided to give it a go on a little PHP 8 project. I get an error saying PHP 8 isn't supported as it's using 0.1.0 of the PHP buildpack. Then I go to file an issue (especially since PHP 8 has been available for several months), only to discover it was released 4 days ago[1]. This kind of turns me off to relying on it. What if there was a vulnerability in PHP 8? Would I want my software to wait at least 4 days before I could update my dependencies?
You give up a lot of control for "simplicity" but I'm not sure simple is always better. Sometimes it is, but often it's deceptive.
[1]https://github.com/paketo-buildpacks/php-dist/releases/tag/v...
What are some alternatives?
rules_docker - Rules for building and handling Docker images with Bazel
bellsoft-liberica - A Cloud Native Buildpack that provides the Bellsoft Liberica implementations of JREs and JDKs
nodejs - A Cloud Native Buildpack for Node.JS
cutlass - Write CNB integration tests for Pack in Ruby with cutlass
go - A Cloud Native Buildpack for Go
rust-dist - A Cloud Native Buildpack for Rust
whalebrew - Homebrew, but with Docker images
feed-test
podman - Podman: A tool for managing OCI containers and pods.
packages.redbeardlab.com