Comments 7
С техническим материалам в тренды не пробиться и много плюсов не заработать. Там всегда статьи о блокировках, о том что Claude до конца недели автоматизирует человечество и прочее. Поэтому не стесняйтесь плюсовать если материал изложен понятным языком и оказался полезен.
Эммм, вы бы хоть объяснили зачем эти пляски с podman<->docker если есть более простые (на вид) решения уровня:
воткнуть раннер напрямую на хост (или в специально выделенную VM) с executor = "docker"
использование did (docker in docker)
воткнуть раннер напрямую на хост
Ну ведь в том и смысл docker, мы все что угодно может воткнуть напрямую на хотс, а docker позволяет воткнуть готовый контейнер внутри которого конткретная версия раннера и настроеное окружение. В случае если мы решим обновить версию нашего раннера мы просто гасим старый контейнер с раннером и запускаем новый более свежий. А конфигурации всех наши переиспользуются за счет волума.
А касательно dind — мы как раз и не лишаемся возможности его использовать, за счет того что выносим в волум docker socket. Ну если быть более точным, то не dind, а его более легковесную альтеративу (через docker.sock)
Но вы правы, если такой вопрос все еще остается, то наверное имеет смысл добавить пояснение об этом.
контейнер внутри которого конткретная версия раннера...если мы решим обновить версию ... гасим старый контейнер с раннером и запускаем новый более свежий
Ну как бы все еще не очевидно. Обновление раннера на хосте еще проще apt-get update && apt-get uprgade (ну или для пугливых unattended-upgrade, или dnf update --security --bug-fix)это выглядит сильно проще чем cd <dir_with_compose> && docker compose down && docker compose pull && docker compose up - и то это сработает если у вас :latest в compose-файле. А у вас версия прибита руками, т.е. каждый секюрити\баг-фикс иди правь руками... ну такое себе, с учетом того как часто гитлаб обновляет все. Там за год такое количество минорных обновлений набегает что просто жуть.
А касательно dind — мы как раз и не лишаемся возможности его использовать, за счет того что выносим в волум docker socket.
Вы немного не поняли... вопроса... у нас есть три сценария.
(просто) развернуть раннер на хосте
(чуть сложнее) развернуть раннер на хосте в режиме did
(сложно)запариться с podman
Возникает вопрос - а собственно зачем все эти пляски с подманом? я так тонко намекну, что а нафига давать контейнеру подмана рут права, если фишка подмана (основная) что контейнеры как раз таки не имеют рутовых прав в отличии от докера. Может быть тогда имело смысл сразу ставить докер использовать did
Доходчиво и понятно пишете, спасибо у вас талант
Спасибо
Ну пожалуйста, хватит писать старое название конфига, раз вы решили обучать новичков то учите сразу писать актуальное compose.yaml
Настройка self-hosted gitlab runner (CI/CD)