Команда docker image prune -a -f удаляет все изображения, включая изображения с тегами, а не только висячие (это вариант -a). Скорее всего, в этом процессе существует состояние гонки, в зависимости от того, где находится сборка в то время, когда команда prune выполняет поиск используемых образов. Если сборка в настоящее время находится внутри шага RUN и использует изображение, тогда при обрезке должны пропустить все слои, используемые этим изображением.
Если вы находитесь между RUN шагами, когда команда обрезки выглядит для изображений, которые нужно удалить, он может попытаться удалить изображение, используемое в качестве родительского в вашей сборке. Это, скорее всего, приведет к ошибке при обрезке, если во время удаления это изображение снова будет использоваться. Однако это также может вызвать ошибку в сборке, если эта обрезка удалит родительский образ, который, как ожидается, будет расширен.
Обычно я бы рекомендовал не выполнять обрезку, если вы ожидаете, что очищенные образы будут включать в себя те, которые активно используется в сборках. Это приведет к тому, что сборки будут выполняться дольше, поскольку будут загружены удаленные образы, и вы можете привести к тому, что в реестре и других узлах будет использоваться больше места для извлечения образов, если слои будут воссозданы заново, а не повторно использовать кэшированные слои из предыдущих сборок.
Для активного сервера сборки гораздо лучше использовать buildkit со встроенной сборкой мусора. Сборка мусора проверяет, когда слой использовался, а не изначально был создан, и основан на размере слоев, поэтому вы можете выделить определенный c объем диска для ваших сборок изображений. А поскольку buildkit работает на containerd, а не непосредственно на движке docker, сам кеш не смешивается с изображениями docker, и вы можете обрезать изображения, не влияя на кеш сборки. Пример этих параметров сборки мусора есть в моей презентации DockerCon .