Наша компания постепенно расширяется, у нас работает всё больше инженеров. А когда их много, надо как-то распределять права и доступы. Почему это важно? Попробую объяснить на примере. У нас есть большое количество скриптов по мониторингу, обслуживанию и т.п., которые обслуживаются просто по крону. Но всегда присутствует необходимость писать новые скрипты, актуализировать уже работающие при изменениях конфигурации, а так же дебажить какие-то проблемы. Поэтому технической команде нужно выбрать инженера, который будет заниматься данным вопросом в конкретный момент времени.  Но иногда бывает так, что написать новый скрипт или чинить уже существующий отправляют человека, у которого нет права на доступ в эту область инфраструктуры. Например, потому что он новичок. Получается, что когда мы назначаем ответственного для решения проблемы со скриптом, то он получает доступ туда, куда ему ещё рано залезать. А это неправильно. Тут может возникнуть резонный вопрос, а зачем давать скрипт человеку, у которого нет доступа в обслуживаемую этим скриптом часть инфраструктуры. Ответ лежит на  поверхности.  Так как мы являемся корпоративным облачным провайдером, работающим в том числе и с чувствительной информацией, то обязаны соответствовать большому количеству жестких требований со стороны ФСБ, ФСТЭК и других организаций. Поэтому вопрос доступов и прав чётко регламентирован. Доступы к системам со скриптами у нас имеют самые надёжные технические специалисты. Но не лишать же из-за этого возможности работать со скриптами всех остальных! Тем более что такая необходимость иногда возникает. Этот вопрос мы решили простым и логичным путём: перевели все скрипты в Gitlab, и через include добавляем логин и пароль из файла, который лежит в каталоге с доступом только по root. Скрипты запускает cron с правами суперпользователя. У обычного пользователя есть доступ только на чтение скрипта, он не может выполнять и редактировать его. Схема выглядит примерно так: Скрипт переделываем на include учётных данных из файла. Папку со скриптом пушим в Gitlab (чтобы не копировать ручками в GItLab). Далее, используя стандартные средства CI\CD, деплоим наши изменения куда надо. Теперь, если пользователю нужно отредактировать скрипт, он действует следующим образом: Делает клон репозитория с dev ветки (оно у нас смотрит на тест) в свою тестовую среду или в дополнительную ветку. Производит отладку с использованием своих учетных данных. Выполняет тестирование, убеждаясь в корректной работе скрипта. Далее вливает изменения из своей ветки в основную dev. Если всё хорошо и всё работает как надо, отправляется merge-request для master ветки.  А дальше code-review, и, в случае успеха, заливка в master ветку, деплой на сервер. При следующем запуске по крону исполняться будет уже изменённый скрипт. В результате мы получаем версионность скрипта и автоматический деплой, что не только стильно/модно/молодёжно, но и банально удобно. Да, по сути мы внедрили CI/CD для более разумного подхода к работе со скриптами. Если вам интересно, как это реализовано на практике, то ниже — небольшая инструкция. Рассчитываем, что читатель более-менее понимает, о чём идёт речь. Ставим клиент git на сервер (в нашем случае это CentOS): В gitlab создаём пользователя gitlab_scripts, добавляем ssh-ключ пользователя, который будет заливать в git (root). Создаём репозиторий в git и делаем в него push папки с текущим скриптом от пользователя root: Ставим на сервер GitLabRunner     В GitLab переходим во вкладу Admin Area — Runner, и оттуда копируем token shared runner’a (либо можно создать отдельный runner и добавлять его на каждый проект). Регистрируем раннер, выполняем: Вводим token и адрес сервера, добавляем понятное имя, тег и выбираем excecutor (в нашем случае shell). Командой gitlab-runner list проверяем, что runner добавился. Генерируем ключ ssh для пользователя, из-под которого работает gitlab-runner, чтобы он мог делать pull с репозитория на сервер без ввода пароля.  Добавляем группу gitlab-runner владельцем папки: Добавляем права: Создаем пайплайн: Заливаем в git: Вот и всё. По такой схеме будет работать автоматический деплой на сервер при любом коммите в репозиторий. Есть идеи, как можно было сделать это иначе? Давайте обсудим. Корпоративный облачный провайдер