-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
-
The blog post links to Jessie Frazelle's GitHub repo [0]. Note that Jessie also has a blog post detailing her setup [1] from back in 2015.
[0] https://github.com/jessfraz/dockerfiles
[1] https://blog.jessfraz.com/post/docker-containers-on-the-desk...
I appreciate the sentiment, but I wouldn't be able to put up with the slow container boot time for regular use. The author mentions this at the bottom. He claims 1sec delay. Last month I benchmarked it on new-ish hardware at 560ms, or 290ms if you disable namespaces (and so disable isolation).
I wanted to also benchmark bocker[1] (docker written in bash) for a baseline comparison, but it no longer runs and I threw in the towel after ~30 mins of tinkering.
Anyways, if you run something like `curl | jq | grep | less` you could be waiting a fair bit for all those containers to start. Package managers are pretty good these days. I think I can trust it to install `jq` properly.
[1]: https://github.com/p8952/bocker
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.]
I'm running a similar setup, whereby I run most applications (even the browser I'm using to type this reply) in docker or podman containers, opportunely created.
Judging from the Git repo containing my dockerfiles, I've been doing so since ~mid June 2018.
I've since automated:
* checking new versions of Git repos, alpine versions, and short crawlers for tools (i.e. I run "perl latest.pl" and a bunch of stuff happens and eventually some dockerfiles might get updated)
* auto-committing any change made from the above step (i.e. ./autocommit.sh) with a meaningful message based on the directory the dockerfile resides, as well as which environment variable containing the version changed
* I use https://github.com/crazy-max/diun/ running on my dokku server to keep up with base images updates (i.e. I get an email in the morning stating alpine:3.12 has been updated or debian:buster-slim or whatever); when a base image changes I have to manually "dp alpine:3.12" to "docker pull" and "podman pull" it; after that, I "make base-images" and my local base images (each coming with a short line to enable a local apt-cache-ng proxy) to also get updated; then a simple "make" makes all of them (docker build -t .... and podman build -t ...)
* Quite a lot of (mostly small) bash scripts to run those images.
As an example, the Dockerfile I use to build hadolint:
FROM local/mfontani/base:latest AS fetcher
RUN curl -sSL "https://github.com/hadolint/hadolint/releases/download/$HADO..." -o /usr/bin/hadolint
Just want link to Whalebrew, which achieves a lot of what this article mentions but IMO is more user-friendly. https://github.com/whalebrew/whalebrew
In many cases you don't need 500mb of base image.
Minimal "distrofull" images are in the 50mb range. But often you don't really need a real distribution inside your docker image.
See https://github.com/GoogleContainerTools/distroless. But distroless is not about one specific tool or base image, it's a paradigm that addresses precisely what you say (without throwing away the whale with the bathwater)
http://packages.redbeardlab.com
On the GitHub repo where you can ask for more packages to be installed:
https://github.com/RedBeardLab/packages.redbeardlab.com/
And in this pair or articles for specific languages
Golang:
- https://github.com/containers/podman#rootless
It’s not clear to me what your requirements are, but take a look at Sandboxie for Windows. [1]
[1]: https://github.com/sandboxie-plus/Sandboxie
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.