Я строю свой конвейер Jenkins внутри док-контейнера с помощью агента докера, чтобы изолировать модульные тесты. Jenkins должен работать от имени пользователя root, чтобы он мог использовать докер-сокет верхнего уровня. Я передаю сокет-док-станцию Jenkins Slave с -v и запускаю как root с -u.
Проблема возникает, когда сборка завершена. Дженкинс не может очистить рабочую область с помощью deleteDirs () на шаге post, потому что все это принадлежит root после запуска.
Запуск агента докера в качестве пользователя root изменяет разрешения для рабочего пространства, поэтому jenkins больше не может запускать следующий запуск или удалять рабочее пространство в конце. После одного запуска, если я не уйду вручную, удалите рабочее пространство из подчиненного узла, на котором он работает, просто произойдет сбой, потому что при втором запуске теперь невозможно изменить какие-либо файлы. Таким образом, я ничего не могу почистить, и Дженкинс теряет к нему доступ. Кроме того, сокет докера, который я передаю, не использует группы пользователей подчиненного узла jenkins, потому что пользователь ubuntu имеет доступ к запуску docker, однако даже после добавления его в группу докеров внутри образа докера, с которого работает мой агент все еще дает мне проблемы с разрешением, когда я не запускаю агент докера как root.
Это не удалось, поскольку пользователь Ubuntu из базы данных образа докера не имеет доступа к сокету докера.
агент {
докер {
изображение 'neb-base: 1.0.10'
args '-u ubuntu -v /var/run/docker.sock:/var/run/docker.sock'
// - корень
}
}
Когда я запускаю его как root:
агент {
докер {
изображение 'neb-base: 1.0.10'
args '-u root -v /var/run/docker.sock:/var/run/docker.sock'
// - корень
}
}
Это не удастся, потому что узел Jenkins не может очистить рабочее пространство в конце, и при следующем запуске он не будет иметь доступа к файлам, потому что владелец изменился бы.
Есть идеи, как разрешить этот конфликт?