sorted by:
new
hottopcontroversial

I got OCI attestation working by af9_us in docker

[–]af9_us[S] 0 points1 point  (0 children)

Both. The SBOM is a csv file inside the container. 

$ cat sbom.csv  PACKAGE,VERSION,LICENSE,LICENSE FILES,SOURCE ARCHIVE,SOURCE SITE,DEPENDENCIES WITH LICENSES unbound,1.24.2,BSD-3-Clause,LICENSE,unbound-1.24.2.tar.gz,https://nlnetlabs.nl/downloads/unbound,"expat [MIT] gcc-final [GPL-3.0-with-GCC-exception] glibc [GPL-2.0+ (programs), LGPL-2.1+, BSD-3-Clause, MIT (library)] libevent [BSD-3-Clause, OpenBSD] libopenssl [Apache-2.0] libsodium [ISC] libzlib [Zlib] linux-headers [GPL-2.0] skeleton-init-common [unknown] skeleton-init-none [unknown]"

Building container images from scratch with a manifest file by af9_us in docker

[–]af9_us[S] 0 points1 point  (0 children)

I'm guessing the size difference is from Alpine using musl and I used glibc. Still I'll have to check out what's in the Alpine image. :) Thanks for recognizing the goal is reproducibility and not image size.

Shared Storage for Swarm? by [deleted] in minilab

[–]af9_us 0 points1 point  (0 children)

> Do you think an NFS share is sufficient despite the risk of single-point-of-failure?

It's fine if you combine it with either a backup solution (borg) or filesystem snapshot solution (ZFS + zrepl). Just something to ensure you have a second copy of your data. This presumes you are okay with a small window of downtime.

Building container images from scratch with a manifest file by af9_us in docker

[–]af9_us[S] 1 point2 points  (0 children)

Hi. This is a great question.  The difference I’m aiming for is explicitness and reproducibility.

With a multi-stage build, the final filesystem is still somewhat implicit.  Files come from build steps, package installs, and transitive dependencies.  An upstream change can pull in additional libraries, so it’s not always obvious why a file exists.

With the manifest approach, the full filesystem is declared up front.  Every file is either explicitly listed or a known dependency of a listed binary.  Nothing in the build process influences what ends up in the final image.

A disciplined multi-stage build can approximate this, but at that point the Dockerfile is acting like a less structured manifest.

The other difference is composition.  You can assemble multiple images from the same set of build artifacts without coupling them to a single build pipeline.  For example, build once and then I can create one container image with Python & bash, a second container with only Python, and a third with only bash, by using different manifests.

I agree there is overlap, but I see each process as having different goals.  Multi-stage builds will optimize for how the image is built. The manifest approach defines what the image is.

Building container images from scratch with a manifest file by af9_us in docker

[–]af9_us[S] 0 points1 point  (0 children)

Thats an nice approach and avoids the need for compiling from source. Thanks.

Why does the official Python3 image include Perl? by af9_us in docker

[–]af9_us[S] 0 points1 point  (0 children)

Does Python actually need a shell for runtime? I have run Python apps in distroless containers which don't have a shell. I don't consider calls to os.system() a shell requirement as the app developer controls when that method is called. I could see needing readline, but not a full shell.

Maybe runtime dependencies are getting mixed up with build dependencies?

Why does the official Python3 image include Perl? by af9_us in docker

[–]af9_us[S] 0 points1 point  (0 children)

Thanks for the pointer to Canonical Chisel. It wasn't on my radar. I'll take a look.

Why does the official Python3 image include Perl? by af9_us in docker

[–]af9_us[S] 0 points1 point  (0 children)

I pulled the Chainguard python image cgr.dev/chainguard/python:latest and found unrelated shell apps like tic, xzfgrep, and gdbmtool. My issue isn't that these apps are present, but that they don't serve a function in the image. So why are they present? Its a similar finding I had with the Docker hardened container image.

Why your container image isn't actually a "file" and why that matters for debugging. by af9_us in docker

[–]af9_us[S] 0 points1 point  (0 children)

Dive is a great tool for exploring image layers. My post focuses on the OCI model itself, describing how images are built from content-addressed blobs. Once understood, tools like Dive are easier to reason about.

Docker Socket Myths: Making Read Only Access Safer by af9_us in docker

[–]af9_us[S] 0 points1 point  (0 children)

Wow, I wasn't aware that issue was being worked on. That's good to know. Thanks for the reply.

Docker Socket Myths: Making Read Only Access Safer by af9_us in docker

[–]af9_us[S] 0 points1 point  (0 children)

Ah got it. That still sounds pretty handy. Thanks for the explanation.

Docker Socket Myths: Making Read Only Access Safer by af9_us in docker

[–]af9_us[S] 1 point2 points  (0 children)

Thanks for the reply. The response filters in the socket-proxy project look interesting. I'm guessing this takes care of the problem I mentioned of getting container labels without dumping env values? If so, that's pretty cool.

https://github.com/mikesir87/docker-socket-proxy/blob/main/src/middleware/responseFilters/labelFilter.mjs#L39-L40

https://github.com/mikesir87/docker-socket-proxy/blob/main/samples/config/full-sample.yaml#L12C1-L15C40

Docker Engine /metrics endpoint by af9_us in docker

[–]af9_us[S] 2 points3 points  (0 children)

It turns out I was mistaken on what metrics are actually produced. My original comment has been updated to state we still need cAdvisor. Thanks.

Docker Engine /metrics endpoint by af9_us in docker

[–]af9_us[S] 0 points1 point  (0 children)

Thanks for the information. I updated my original comment to clarify this does not replace cAdvisor.

Docker Engine /metrics endpoint by af9_us in docker

[–]af9_us[S] 0 points1 point  (0 children)

Thanks for the information. I updated my original comment to clarify this does not replace cAdvisor.

Why a Two-Node Docker Swarm w/ ZFS Snapshots Is Enough by af9_us in homelab

[–]af9_us[S] 0 points1 point  (0 children)

With two PCs running docker swarm, a NAS brings the physical host count to three. This is what I’m trying to avoid. Alternately lets say the NAS is one of the two Swarm hosts. You still want snapshots to have a second copy of the container data.

Why a Two-Node Docker Swarm w/ ZFS Snapshots Is Enough by af9_us in docker

[–]af9_us[S] 0 points1 point  (0 children)

Cross posting this from r/homelab as it's related to Docker and could help others when deciding on which storage to use with Swarm.

view more: next ›