Can one use Kaniko with a RAMdisk to improve snapshotting performance?

[jae-63]

Hi,

We use Kaniko within Gitlab (using our own GItlab environment and GItlab runner, all within AWS/EKS) to build some fairly complex Docker images. We've recently observed that the "snapshotting" which Kaniko performs makes it impractical to build our most complex Docker image, because it takes too long to run. Within Gitlab, we run Kaniko by invoking '/kaniko/executor' and we're currently using gcr.io/kaniko-project/executor:debug

That Gitlab runner is already using an SSD for /var/lib/docker but we wonder if we could obtain better performance if we used a RAMdisk for the portions of the filesystem which Kaniko is snapshotting.

Our initial analysis suggests that Kaniko might be snapshotting '/' but hopefully that's incorrect.

Can you advise us which filesystems we should use RAMdisks for? Perhaps there's a way to configure this in our /kaniko/.docker/config.json file ? And perhaps we can mount a RAMdisk volume from the Gitlab runner.

Thanks.

[tejal29]

@jae-63 Kaniko does snapshot "". Kaniko reads the mount info and ignores mounted filesystems.
I recently created an optimized images with 2 strategies,

1. Using a fast snapshotting strategy. - does not involving hashing the contents.
2. Use another implementation run command which does not rely on snapshotting.

Please see the details here #1305

Irrespective of these, Kaniko would walk the filesystem "/" to determine file changes.

[mitar]

I am interested in this as well. I can configure GitLab CI to use a ramdisk for the build directory where it clones the project and I can then set that as context. But I am not sure where does kaniko then write files during the build process?