Наша компания постепенно расширяется, у нас работает всё больше инженеров. А когда их много, надо как-то распределять права и доступы. Почему это важно? Попробую объяснить на примере.
У нас есть большое количество скриптов по мониторингу, обслуживанию и т.п., которые обслуживаются просто по крону. Но всегда присутствует необходимость писать новые скрипты, актуализировать уже работающие при изменениях конфигурации, а так же дебажить какие-то проблемы. Поэтому технической команде нужно выбрать инженера, который будет заниматься данным вопросом в конкретный момент времени.
Но иногда бывает так, что написать новый скрипт или чинить уже существующий отправляют человека, у которого нет права на доступ в эту область инфраструктуры. Например, потому что он новичок.
Получается, что когда мы назначаем ответственного для решения проблемы со скриптом, то он получает доступ туда, куда ему ещё рано залезать. А это неправильно. Тут может возникнуть резонный вопрос, а зачем давать скрипт человеку, у которого нет доступа в обслуживаемую этим скриптом часть инфраструктуры. Ответ лежит на поверхности.
Так как мы являемся корпоративным облачным провайдером, работающим в том числе и с чувствительной информацией, то обязаны соответствовать большому количеству жестких требований со стороны ФСБ, ФСТЭК и других организаций. Поэтому вопрос доступов и прав чётко регламентирован. Доступы к системам со скриптами у нас имеют самые надёжные технические специалисты. Но не лишать же из-за этого возможности работать со скриптами всех остальных! Тем более что такая необходимость иногда возникает.
Этот вопрос мы решили простым и логичным путём: перевели все скрипты в Gitlab, и через include добавляем логин и пароль из файла, который лежит в каталоге с доступом только по root. Скрипты запускает cron с правами суперпользователя. У обычного пользователя есть доступ только на чтение скрипта, он не может выполнять и редактировать его.
Схема выглядит примерно так:
Скрипт переделываем на include учётных данных из файла.
Папку со скриптом пушим в Gitlab (чтобы не копировать ручками в GItLab).
Далее, используя стандартные средства CI\CD, деплоим наши изменения куда надо.
Теперь, если пользователю нужно отредактировать скрипт, он действует следующим образом:
Делает клон репозитория с dev ветки (оно у нас смотрит на тест) в свою тестовую среду или в дополнительную ветку.
Производит отладку с использованием своих учетных данных.
Выполняет тестирование, убеждаясь в корректной работе скрипта.
Далее вливает изменения из своей ветки в основную dev. Если всё хорошо и всё работает как надо, отправляется merge-request для master ветки.
А дальше code-review, и, в случае успеха, заливка в master ветку, деплой на сервер.
При следующем запуске по крону исполняться будет уже изменённый скрипт. В результате мы получаем версионность скрипта и автоматический деплой, что не только стильно/модно/молодёжно, но и банально удобно. Да, по сути мы внедрили CI/CD для более разумного подхода к работе со скриптами.
Немного кода
Если вам интересно, как это реализовано на практике, то ниже — небольшая инструкция. Рассчитываем, что читатель более-менее понимает, о чём идёт речь.
Ставим клиент git на сервер (в нашем случае это CentOS):
yum -y install https://packages.endpoint.com/rhel/7/os/x86_64/endpoint-repo-1.7-1.x86_64.rpm
yum install git
В gitlab создаём пользователя gitlab_scripts, добавляем ssh-ключ пользователя, который будет заливать в git (root). Создаём репозиторий в git и делаем в него push папки с текущим скриптом от пользователя root:
git init
remote add origin ssh://git@gl.mysite.ru/gitlab_scripts/test.git
git add .
git commit -m "Initial commit"
git push -u origin master Ставим на сервер GitLabRunner
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash
export GITLAB_RUNNER_DISABLE_SKEL=true; sudo -E yum install gitlab-runner
В GitLab переходим во вкладу Admin Area — Runner, и оттуда копируем token shared runner’a (либо можно создать отдельный runner и добавлять его на каждый проект).
Регистрируем раннер, выполняем:
gitlab-runner registerВводим token и адрес сервера, добавляем понятное имя, тег и выбираем excecutor (в нашем случае shell). Командой gitlab-runner list проверяем, что runner добавился.
Генерируем ключ ssh для пользователя, из-под которого работает gitlab-runner, чтобы он мог делать pull с репозитория на сервер без ввода пароля.
Добавляем группу gitlab-runner владельцем папки:
chown -R :gitlab-runner test2Добавляем права:
chmod 775 -R test2Создаем пайплайн:
.gitlab-ci.yml
build:
script:
- rsync -avh --delete --exclude=.git ./ /test2/Заливаем в git:
git add .
git commit -m "add ci"
git push -u origin master
Вот и всё. По такой схеме будет работать автоматический деплой на сервер при любом коммите в репозиторий. Есть идеи, как можно было сделать это иначе? Давайте обсудим.
