Kubernetes: сборка образов Docker в кластере

[shurup]

нужно что-то вроде Docker внутри Docker.

Это название конкретного решения — странно переводить его по всему тексту.

Оригинальная статья от августа, и с тех пор у kaniko случилось много релизов (0.3.0 → 0.7.0). Впрочем, несмотря на это:

Только учтите, что kaniko пока находится в разработке и поддерживает не все команды Dockerfile, например --chownflag для команды COPY.

… проблема (только --chown, а не --chownflag) и ныне здесь, хотя давно есть github.com/GoogleContainerTools/kaniko/pull/250

[nAbdullin]

За уточнение спасибо, исправили.

[gecube]

Интересно увидеть сравнение kaniko vs buildah и пояснение почему одно лучше другого

[delfer]

Большое спасибо за перевод, на kaniko и buildah обязательно стоит посмотреть.

Но при этом возникают проблемы с безопасностью: например, приходится работать с разными файловыми системами (хоста и контейнера) или использовать кэш сборки из хост-системы. Вот почему мы и не хотели трогать Docker-in-Docker.

Странная аргументация. Разные файловые системы и кэш сборки слабо связаны с безопасностью.

Уже больше года используем цепочку CI/CD на Kubernetes, Drone.io, Docker-In-Docker. За это время ломалось все: Drone, СУБД, оборудование, сеть, файловые системы, Docker Registry, сам k8s, но вот сбоя Docker-In-Docker не было ни одного. Работает как часы. Хотя официально разработчики рекомендуют использовать его только для тестов.

К слову, описание деплоя: https://gist.github.com/delfer/03a4aab83f73305888593287e9735895

То есть, если хотим запустить Docker-демон в контейнере, нужно использовать вложенную виртуализацию.

Сильное заявление. Что там виртуального? Файловая система — изолированный слой. Оборудование — нет. Ядро — используется хостовое. Пространство процессов — тоже хостовое.

[gecube]

Сильное заявление. Что там виртуального? Файловая система — изолированный слой. Оборудование — нет. Ядро — используется хостовое. Пространство процессов — тоже хостовое.

соглашусь — это проблемы терминологии. Т.е. если мы говорим, что docker — контейнеризация, а не виртуализация, то лучше это делать везде. А виртуализацией называть гипервизоры полноценные (хотя даже они умеют работать друг внутри друга, но ес-но, что с гигантской потерей производительности).
И для докера-в-докере я не вижу никаких технических ограничений. Тем более, что вроде даже вложенные namespaces/cgroups завезли в последние ядра linux…

[mapcuk]

Есть ещё альтернатива img которую хочется попробовать. Одно из достоинств — это API которое совместимо с docker командами, просто надо использовать img build, img push…
Пока у нас в CI используется D-In-D в GitLab, вопрос кеширование пока не решили.