community
macondo
community | macondo | |
---|---|---|
2 | 1 | |
42 | 3 | |
- | - | |
6.5 | 1.8 | |
17 days ago | over 3 years ago | |
Rust | ||
Creative Commons Attribution 4.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.]
macondo
-
Run More Stuff in Docker
This reminded me of a proof of concept thing that facilitates this kind of work.
https://github.com/casidiablo/macondo
I don't even know what it is I built, but it has been useful in some contexts.
It basically allows you to easily wrap and distribute scripts (or more complex apps) that have specific dependencies that might not always be installed in the host. It does so by wrapping the script in a docker image.
It also automates the annoying part of docker: mounting local paths for apps that need to interact with the host's file system.
I need to write a blog post on this if anything to gather feedback. I'm still not 100% sold on the idea and there are some edge cases. Still, a fun experiment.
What are some alternatives?
rules_docker - Rules for building and handling Docker images with Bazel
whalebrew - Homebrew, but with Docker images
nodejs - A Cloud Native Buildpack for Node.JS
packages.redbeardlab.com
cutlass - Write CNB integration tests for Pack in Ruby with cutlass
podman - Podman: A tool for managing OCI containers and pods.
go - A Cloud Native Buildpack for Go
bocker - Docker implemented in around 100 lines of bash
Diun - Receive notifications when an image is updated on a Docker registry
feed-test
hadolint - Dockerfile linter, validate inline bash, written in Haskell