В данной статье, я решил описать свой опыт настройки gitlab CI и арендуемого VPS.
Предпосылки
На работе, ув. DevOps'ы настроили мне деплой проектов в kubernetes (
Исходные данные
- Аккаунт https://gitlab.com/
- VPS сервер с Ubuntu 18.04
Создание репозитория
Создаем репозиторий, который хотим автоматизировать.
Я решил для тестов, поднять docker с nginx и пробросом на html страницу.
Структура репозитория:
- Dockerfile
FROM nginx:latest COPY html /var/www/html COPY nginx.conf /etc/nginx/nginx.conf
- nginx.conf
events {} http { server { listen 80; location / { root /var/www/html; } } }
- html
- index.html
<html> <h1>Hello, Runner!</h1> </html>
- .gitlab-ci.yml
image: docker:19.03.8 before_script: - docker info build: stage: build script: - docker build -t hellorunner . deploy: stage: deploy script: - docker ps --filter name=hellorunner --quiet | xargs --no-run-if-empty docker stop | xargs --no-run-if-empty docker rm - docker run -d --restart=always --name hellorunner -p 8090:80 hellorunner after_script: - docker system prune -f
Настройка репозитория
Открываем settings -> CI
Затем у пункта Runners нажимаем expand
Первым делом выключаем предложенные runners — Disable shared runners
Затем, нас интересует — «Set up a specific Runner manually»
Копируем токен, в будущем он нам понадобится.
Подготовка VPS
Устанавливаем docker.
Устанавливаем gitlab-runner.
Регистрируем новый runner.
! В поле executor указываем docker версии, как и в Dockerfile!
В поле token указываем токен, который запомнили из gitlab
gitlab-runner register
Теперь, нужно внести небольшие правки в конфиг runner'а.
nano /etc/gitlab-runner/config.toml
поле
volumes = ["/cache"]
меняем на
volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
Выполняем рестарт демона
gitlab-runner restart
Снова возвращаемся к gitlab/settings/CI/Runners.
Должен появиться активный runner
Редактируем runner, нажатием
Разрешаем выполнять задачи без тэгов
Теперь выполняем push коммита и следим за job'ами
И напоследок открываем браузер
Ссылка на репозиторий
P.S.: Я встретил проблему — у меня собранный образ изнутри не имел доступа к внешней сети, решение — создать файл/etc/docker/daemon.json:
{
"dns": ["8.8.4.4", "8.8.8.8"]
}
service docker restart
TheGodfather
Что-то всех на Gitlab CI потянуло
- docker ps --filter name=hellorunner --quiet | xargs --no-run-if-empty docker stop | xargs --no-run-if-empty docker rm
- docker run -d --restart=always --name hellorunner -p 8090:80 hellorunner
Вы ведь понимаете, что здесь проблем больше, чем пользы?
1. Вообще в современном мире вроде как сборка образа и его запуск идеологически разделены, вплоть до физически разных машин. Тут все в куче.
2. Про Docker-compose вы явно не слышали, как иначе объяснить такой дикий хардкод портов в `docker run` и вообще в CI-конфигурации (а не в конфигурации проекта)? Ну и перед публикацией статьи вы бы хоть теоретически попробовали это примерить на реальный проект (у вас же должен быть хоть один реальный проект, так?). БД банальная?
3. Где код-то? Вы собираете статический файл :) А обычно у вас будет билд-окружение, билд-зависимости, рантайм-зависимости, это все разделено, код из репозитория билдится в билд-окружении и результат в виде тех или иных артефактов добавляется в продакшн-образ. А где у вас это все?
danil_e71 Автор
1. Пет — проект не требует разделения)
2. Проект запущен, там немного по-другому. Тут пытался упростить для юзеров-не-в-теме, чтобы не было лишних стадий
3. Это уже отдельная статья по разделению CI конфигурации на стадии. Тут только боль и проблемы при подключении runner'а)
Сама статья не для DevOps, которые «все знают», а для тех кто не в теме)
п.с. Пет — проект: online игра, и бд там postgres, и docker-compose, но это уже не для паблика)когда-нибудь меня устроит результат и выкачу ее)
TheGodfather
Ну в моем пет-прожекте «деплой» это docker-compose build && docker-compose up -d. Чувствуете разницу с вашими страшными строчками? :)
Это, конечно, мое имхо, но ваше «упростить для юзеров-не-в-теме» превратилось в рекламу антипаттернов, как НЕ стоит делать. Даже если пет-прожект, второе, что делаете (после Dockerfile) — docker-compose.yml. Пусть там хоть всего один сервис, это ж не важно.
Хз, где боль, не далее чем вчера по работе мигрировал раннер с одного сервера на другой — заняло не более 5 минут. Какая боль, где, это делается на раз, грабли если и появляются, то уж точно не во флоу для пет-прожекта, а там, где появляются контейнеры под Windows, где начинается попаболь с разными юзерами и permissions на линуксе, вот это вот все.
danil_e71 Автор
это не проблема, вставить compose)
главное с толку не сбить людей)
если кто еще считает, что переписать команду на compose, просьба оценить main-пост TheGodfather плюсом и я перепишу конечно)