Я настраиваю сервер GitLab в своей компании и теперь добавляю к нему GitLab CI.
Перед тем как приступить к выполнению этой задачи, я хотел бы понять, есть ли какие-либо недостатки в работе моих бегунов на одном сервере, используемом GitLab и GitLab CI.
Я читал, что есть проблемы с безопасностью, но мы используем его только внутри, поэтому я не думаю, что это может быть проблемой.
Внутренний разработчик хочет навредить компании (потому что считает, что ему недоплачивают, потому что его начальник спит с женой; причина не имеет значения). Он запускает модульный тест, который при запуске вместо тестирования приложения ищет репозиторий GitLab и стирает это. Удивительно, что при следующем коммите весь исходный код проекта потерян (но вы делаете резервные копии и проверяли их, верно?)
Или тот же разработчик замечает, что резервные копии репозитория настроены на той же машине. Он изменяет эту конфигурацию с помощью модульного теста, так что резервная копия теперь содержит другой репозиторий и ждет месяц - время хранения резервных копий. Теперь, когда все резервные копии повреждены, он может зафиксировать свой модульный тест, который стирает исходный код с сервера.
Или стажер хочет продать исходный код для конкурса. Вы тщательно настроили доступ, ограничив его только тем, что ему нужно для его работы. В то же время он имеет неограниченный доступ к самому хранилищу через модульные тесты, будучи в состоянии сделать полный дамп.
Если модульные тесты не запускаются в контексте ограниченных разрешений и не могут получить доступ ни к чему, кроме каталогов и файлов, необходимых для тестов, смешивание CI-сервера с сервером, на котором хранится ваше хранилище, действительно опасно.
Другая проблема заключается в том, что сервер контроля версий должен быть быстрым. Сервер CI, установленный на той же машине, может замедлить фиксацию.
Мы - 3 разработчика ... если кто-то из нас хочет навредить компании, он может сделать это тысячами способов = (... Таким образом, единственная проблема - это медленная работа, но если я использую хорошую машину, у меня не должно быть большой проблемы, верно? Спасибо!
Фес Враста
PS: как насчет chroot? Не может быть использован, чтобы сделать процесс безопасным?
Фес Враста
4
@FezVrasta: если безопасность не является проблемой в вашем случае, как и производительность, единственное преимущество, которое я вижу на отдельных машинах, - это будущая масштабируемость. Но, честно говоря, внесение изменений до появления проблем с масштабируемостью похоже на преждевременную оптимизацию.
Арсений Мурзенко
@FezVrasta: «Как насчет chroot? Не может быть использован, чтобы сделать процесс безопасным?» - У меня недостаточно навыков в безопасности Unix, чтобы ответить на этот вопрос.
Арсений Мурзенко
0
Учитывая, что для git нет центрального «всезнающего» сервера, это неплохо, как и в случае некоторых других систем контроля исходного кода.
При условии, что есть автоматический syk сервера git вне сайта для другого сервера git (который тестируется), я не буду беспокоиться об этой установке в небольшой компании.
В идеале я хотел бы, чтобы разработчики отправляли свои изменения на git-сервер офсетного сервера, а затем на CI-сервер, чтобы получать начисления с офсетного сервера - таким образом, внешний сервер проверяется после каждой регистрации.
Если разработчики всегда старались извлечь выгоду из локального сервера, чтобы сэкономить время, это не проблема.
если мне нужно 2 сервера ... почему бы мне не запустить бегунов на 2-м сервере?
Фес Враста
@FezVrasta, то « выездной сервер» может быть любым, кто будет продавать вам GIT хостинг, он не должен быть сервером вы владеете. Также, поскольку это по Интернету, вытащить это будет медленно.
Ян
1
Я настраиваю это для своей компании, мы используем наши собственные серверы ...
Учитывая, что для git нет центрального «всезнающего» сервера, это неплохо, как и в случае некоторых других систем контроля исходного кода.
При условии, что есть автоматический syk сервера git вне сайта для другого сервера git (который тестируется), я не буду беспокоиться об этой установке в небольшой компании.
В идеале я хотел бы, чтобы разработчики отправляли свои изменения на git-сервер офсетного сервера, а затем на CI-сервер, чтобы получать начисления с офсетного сервера - таким образом, внешний сервер проверяется после каждой регистрации.
Если разработчики всегда старались извлечь выгоду из локального сервера, чтобы сэкономить время, это не проблема.
источник