#Why does WithUnixSocket invalidate earlier container image layers?

1 messages · Page 1 of 1 (latest)

grim stone
#

I was working with building a module which mounts an SSH socket into a container image. I noticed that calling WithUnixSocket at any point when building the container causes earlier layers to be invalidated. For example, the following module always reevaluates the apt-get install wget:

package main

import (
    "context"
    "dagger/apt-install-cache/internal/dagger"
)

type AptInstallCache struct{}

func (m *AptInstallCache) Container(ctx context.Context, sock *dagger.Socket) *dagger.Container {
    return dag.
        Container(dagger.ContainerOpts{Platform: dagger.Platform("linux/amd64")}).
        From("ubuntu:24.04").
        WithExec([]string{"sh", "-c", "apt-get update && apt-get install --yes wget && apt-get clean && rm -rf /var/lib/apt/lists/*"}).
        WithUnixSocket("/tmp/ssh.socket", sock)
}

This seems strange to me. I'm wondering if there's something I'm missing or not understanding about how unix sockets are mounted into a container? Is there a way to build this container without invalidating the cached layers?

#

Update: I'm really not sure what is happening here. It seems that this should cache the single WithExec, but it doesn't appear to happen consistently. If someone could help me understand why this layer appears to be invalidated sometimes?

alpine hound
alpine hound
grim stone
#

That's what I was beginning to suspect. Thanks for checking @alpine hound! Is there a way to check if/when a layer is GC'd?

alpine hound
#

I've tied in both v0.18.14 and v0.18.16 and I observe the same consistent behavior

grim stone
#

Maybe there is a way to correlate entries returned from dagger core engine local-cache entry-set entries with a dagger call?

alpine hound
alpine hound
grim stone
#

Sounds good. I'll take a look at the engine logs and see what I can find