Комментарии 2
У данной реализации есть два серьёзных недостатка:
1) любой разработчик может обрушить всю CI инфраструктуру, добавив в .gitlab-ci.yml команду на удаление всех контейнеров.
2) возможные трудности при параллельном запуске нескольких одинаковых пайпов например, возможен конфликт имён контейнеров и артефактов в расшаренных volumes.
Вариант с docker-in-docker отлично работает, даже при условии запуска раннера и самого гитлаба в контейнерах.
Могут быть трудности, например с пробросом перемётных среды и сертификатов для private registry в dind контейнер (gitlab-CI пока что этого не умеет), но они обходятся созданием кастомного образа dind с зашитыми сертификатами.
Спасибо за замечания.
1. Точно так же ее можно обрушить, если GitLab стоит на хосте. Возможности защититься от этого одинаковые, независимо от того, где стоит GitLab.
2. Да. Но снова же, эта проблема равным образом касается и работы CI вне контейнера. Возможно, вы немножко не так поняли смысл статьи. Я не рассказывал о том, как создать отдельные виртуальные машины GitLab с помощью Docker для каждого разработчика, с отдельным доступом, с уверенностью в изолированости, и т.д. Я даже написал предостережение о проблеме разшаривания Docker тем контейнерам, в которых вы не уверенные. Эта статья для тех, кто сам вынес GitLab в контейнер, и ему на своей реальной или виртуальной машине нужно тестировать проект в контейнерах с помощью CI в контейнере. Он сам себе злобный буратино, и решения ваших замечаний это тоже его забота.
Я запускал Docker-in-docker в контейнере, и он отлично работал, но для простого проекта, в котором docker-compose.yml спокойно переносится в .gitlab-ci.yml, и не нуждается в более глубокой настройке, он избыточен. У меня была идея переписать на основе dind сам образ GitLab, таким образом он со старта будет готов работать в контейнере с другими контейнерами, но к проверке решения руки не дошли.
1. Точно так же ее можно обрушить, если GitLab стоит на хосте. Возможности защититься от этого одинаковые, независимо от того, где стоит GitLab.
2. Да. Но снова же, эта проблема равным образом касается и работы CI вне контейнера. Возможно, вы немножко не так поняли смысл статьи. Я не рассказывал о том, как создать отдельные виртуальные машины GitLab с помощью Docker для каждого разработчика, с отдельным доступом, с уверенностью в изолированости, и т.д. Я даже написал предостережение о проблеме разшаривания Docker тем контейнерам, в которых вы не уверенные. Эта статья для тех, кто сам вынес GitLab в контейнер, и ему на своей реальной или виртуальной машине нужно тестировать проект в контейнерах с помощью CI в контейнере. Он сам себе злобный буратино, и решения ваших замечаний это тоже его забота.
Я запускал Docker-in-docker в контейнере, и он отлично работал, но для простого проекта, в котором docker-compose.yml спокойно переносится в .gitlab-ci.yml, и не нуждается в более глубокой настройке, он избыточен. У меня была идея переписать на основе dind сам образ GitLab, таким образом он со старта будет готов работать в контейнере с другими контейнерами, но к проверке решения руки не дошли.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как тестировать контейнеры RoR с GitLab CI в контейнере