Our great sponsors
-
-
-
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.
-
fpm
Effing package management! Build packages for multiple platforms (deb, rpm, etc) with great ease and sanity.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
The container, if it's `from SCRATCH` is basically just a gzip/zip archive.
https://github.com/opencontainers/image-spec/blob/master/ima...
One thing I'm wondering -- why are people obsessed with container size? A lot of enterprise is Java shops which deal with huge dependencies, huge distributions, and generally pretty software -- with internet speeds what they are today, it's not hard to throw 100-500MB around internal networks (building the code closer to the deployment area is also a solution). Even gigabyte size containers are not impossible to deploy these days with the right caching (lord help you if you invalidate a bunch of layers though).
In a world of xTB thumbdrives, why are we so worried about containers being <1MB? Security is one thing, minimalism is another, but I do sometimes wonder about this.
Anyway, if you want to build minimal containers and want to do it with a bit more backing than this one (pretty well written) blog post, probably also check out distroless:
https://github.com/GoogleContainerTools/distroless
I personally find most of the time alpine-based containers are more than small enough and good enough with nice ergonomics (sometimes you just want to shell in to the container), but maybe it makes sense to build containers with and without debugging/inspection tools (a `project:vx.x.x` and a `project:vx.x.x-debug`) and switch them out when problems arise.
Alpine is one of the unsung heroes of the container world. It's insane how much value Natanael Copa has shepherded over the years (decades?). Recently came upon an interview with him and it was the first time I saw the creator behind Alpine Linux[0].
Thank you for those links, I am about to gobble up those blog posts -- I recently went on a benchmarking kick[1] and diskless alpine instantly struck me as the perfect server setup. ECC memory + running from ram would give me full use (to put in RAID/whatever else) of the NVMe drives, it's something I'm going to try out as soon as I get a chance to.
I am so interested in the infrastructure space, I know exactly two hosting providers that will give me PXE level access (so I could use something like tinkerbell[2]):
- OVH [3][4]
- Vultr[5]
- LeaseWeb[6]
Unfortunately my personal favorite hosting provider, Hetzner[7] (I fell in love the moment I came across the robot marketplace) does not offer it yet, though I've automated going through their rescue system at this point so it's OK.
[0]: https://www.tfir.io/meet-the-creator-of-alpine-linux-natanae...
[1]: https://vadosware.io/post/k8s-storage-provider-benchmarks-ro...
[2]: https://docs.tinkerbell.org/
[3]: https://github.com/gmasse/ovh-ipxe-customer-script
[4]: https://geekgonecrazy.com/2020/09/07/tinkerbell-or-ipxe-boot...
[5]: https://www.vultr.com/docs/ipxe-boot-feature
[6]: https://kb.leaseweb.com/products/dedicated-server/installing...
[7]: https://www.hetzner.com
But there is a lot of work to be done before you can do the simple apt install. I (gladly) don't know how it is nowadays but before Dockerfiles/Docker creating your own packages according to the various standards was a pita. Most companies needed a 'packaging specialist/release engineer' role as most developers where not up to the task. Solutions like FPM[0] did help somewhat, but it was still hard when dealing with non-homogeneous environments. Containers solved that problem universally for all distributions.
[0] https://github.com/jordansissel/fpm
RUN git clone https://github.com/nemasu/asmttpd.git asmttpd
It depends which tooling layer you're using, really. If you're just saying "bundle up these files and put them on that part of the filesystem" it can be extremely simple. If you're trying to provide the full build-from-source chain... less so. Being able to ignore the Debian Packaging Guidelines is the path to sanity.
In a previous incarnation I wrote https://github.com/regularfry/au to take the grunt-work out of packaging up ruby apps, and pretty much all it does is generate the minimum set of files that `dpkg-deb` needs to spit out an archive.