Руководства, Инструкции, Бланки

гитлаб руководство img-1

гитлаб руководство

Категория: Руководства

Описание

Использование gitlab continuous integration для деплоя

Использование gitlab continuous integration для деплоя 03.11.2015 09:33

Совсем недавно гитлаб героически выкатил версию 8.0 своего конкурента гитхабу. Из интересного — движок continuous integration теперь встроен в платформу, а значит доступен в качестве бесплатного сервиса для всех желающих на gitlab.com. Совместно с бесплатными приватными репозиториями это делает облачный сервис гитлаб не только удобным местом для хранения кода, но также тестирования и деплоя. О последнем я и расскажу под катом.

Continuous integration — это не только запуск юнит тестов при пуше нового кода в репозиторий. Это еще и возможность делать сборки продуктов, публиковать их в сторы, на сайты и в другие каналы распространения. Облачная телефония voximplant использует javascript сценарии, которые размещаются в нашем облаке и выполняются по команде “снаружи” или при поступлении входящего звонка. Многие клиенты для работы со сценариями используют встроенный в админку текстовый редактор, что вполне подходит для простых случаев. Но при разработке и поддержке сложных облачных систем, к примеру телефонии Bitrix24, нужно что-то более серьезное.

Создавая voximplant мы решили не делать push-to-deploy как у heroku. У многих наших клиентов основной бизнес не связан с разработкой софта, и оставлять их один на один с git’ом не очень хорошо. Зато есть HTTP API с функцией “задеплоить сценарий”, который намекает понимающим людям что сценарии можно хранить на gitlab и деплоить с помощью shell скрипта и curl. Большинство клиентов так и делает, но у подхода есть серьезный недостаток: скрипт нужно не забыть вызвать. Более того, вызывать его надо только если код был запушен в production ветку. И только после того, как прошли тесты. Вообще много способов ошибиться.

По умолчанию continuous integration в гитлабе выключено и необходимо его включить в настройках:

После включения в левом меню настроек проекта появляется несколько новых пунктов, самый интересный для нас — это «runners». Continuous integration в гитлабе работает следующим образом:

  1. Вы делаете push в репозиторий
  2. Если в корне проекта есть файл .gitlab-ci.yml. то гитлаб понимает что для этого проекта будет использоваться continuous integration.
  3. Гитлаб ищет запущенный runner, подключенный для этого или для любого проекта. Runner — это приложение, которое обычно запускают на отдельном компьютере и которое будет собственно осуществлять continuous integration: прогонять тесты, собирать исполняемые файлы, осущестлять деплой. Можно запустить свой runner, к примеру на маке чтобы собрать приложение для iOS. Можно использовать “gitlab public runner”, но они не то чтобы очень безопасны и входящие очереди задач у них обычно многочасовые.
  4. Гитлаб передает yaml файл runner’у, который обновляет исходники в своем репозитории и выполняет команды, описанные в этом файле. Команды могут быть как простые, к примеру сделать деплой сценария в облако voximplant. Так и сложные: запуск docker контейнера, сборка в нем проекта, запуск тестов и так далее.
  5. После выполнения скриптов runner рапортует обратно гитлабу резулттаты, которые можно посмотреть рядом с соответствующим коммитом.

Для нашего примера мы запустим runner на машине разработчика. Инструкции по установки для windows/linux/osx доступна на официальном сайте, после установки мы получаем в свое распоряжение command line утилиту gitlab-ci-multi-runner. Запущенный runner подключается к гитлабу и ждет задачи на сборку. Но как гитлаб узнает, какие задачи какому runner’у давать? Чтобы “привязать” runner к своему аккаунту и проекту (или нескольким проектам) необходимо вызвать gitlab-ci-multi-runner с ключем register и ввести параметры подключение: url гитлаб (так как гитлаб может быть развернут локально в вашей сети) и токен регистрации, который, собственно, и определяет аккаунт/проекты:

Зарегистрированный runner запускается командой gitlab-ci-multi-runner run и ждет задачу от гитлаба. С помощью ключей командной строки install и start runner можно зарегистрировать в системе как сервис, чтобы он автоматически стартовал после перезагрузки операционной системы.

Как я уже писал, задачи continuous integration описываются в файле .gitlab-ci.yml который необходимо разместить в корне проекта. Редкоземельный синтаксис YAML является как-бы-человекочитаемой альтернативой JSON’у, документация доступна на официальном сайте. Конфигурационный файл для деплоя проекта в voximplant будет максимально простым, все что нам нужно — это сделать один вызов HTTP API как описано в нашей документации. Если исходить из предположения, что runner выполняется на компьютере где установлен curl, а код сценария находится в файле scenario.js. то конфигурационный файл для деплоя будет выглядеть следующим образом:

В curl используется синтаксический сахар нашего API, которое может принимать аргументы как в компоненте query передаваемого url, так и в body http запроса.

Чтобы continuous integration заработал достаточно сделать push в репозиторий: гитлаб обнаружит файл .gitlab-ci.yml. найдет подключенный runner, передаст ему содержимое этого файла, runner обновит свою копию репозитория и запустит скрипт деплоя, который отгрузит исходный код в наше облако.

Вопросы, уточнения, комментарии? Gitlab vs Jenkins vs Bamboo vs Teamcity?

Другие статьи

Gitlab (Форум)

Задача: найти через GitLab API milestones для всех проектов, группы проектов, а также для выбранного проекта.

Т.е. нужно частично имплементировать в своем десктопном приложении то, что у них реализовано в веб гуи.

- Пытался задать в чатике - молчок.

- Где найти русскоговорящих контрибуторов, которые бы реагировали в гиттер чатике?

Зы есть ли вообще готовые десктопные клиенты для Gitlab?

Здравствуйте! Решил настроить себе GitLab и объединить его работу с Jenkins (уже был, и долго служил верой и правдой). Сделал всё по статье http://doc.gitlab.com/ee/integration/jenkins.html. и Jenkins стал прекрасно запускать job'ы при push'ах в GitLab.

Столкнулся с проблемой при настройке «Jenkins CI» в GitLab, его там нет и откуда его взять непонятно.

Может кто-то сталкивался с такой проблемой?

gitlab + doxygen не дружат

На работе стоит гитлаб, где есть куча проектов. Большая часть из них содержит подробную документацию внутри кода с использованием doc-блоков. На локальном компьютере документация отлично генерируется через doxygen.

Есть задача централизовано генерировать по всем этим проектам документацию на самом сервере gitlab и иметь доступ к ней. Причем, для оперативности процесса, хочется после каждого «git push» на gitlab-сервер, чтобы документация генерировалась заново.

То есть алгоритм такой: На сервер приходят новые коммиты, обновляется git-репозиторий, запускается doxygen по текущему git-репозиторию, doxygen складывает результат своей деятельности в определенную папку в которую смотрит веб-сервер и отдает оттуда результат.

Сейчас я написал post-recieve hook для git'a. Можно посмотреть тут - http://pastebin.com/MecjMUfs

Работает он так: Если в папке с проектом есть doxygen/Doxyfile.cfg, он генерирует имя проекта исходя из его пути и запускает doxygen.

Громадный недостаток в том, что этот скрипт нужно класть вручную в каждый проект на gitlab. Более того, в свежесозданные проекты его тоже нужно будет класть.

Как Вы решаете задачу генерации документации по своему коду?

Может я неправ и мне не нужно чтобы документация генерировалась автоматически? Может быть достаточно скрипта который будет по крону раз в день ходить по всем папкам gitlab-овских репозиториев и генерировать документацию раз в день?

Настройка gitlab - Stack Overflow на русском

Развернул гитлаб примерно следующим образом:

Морда и sidekiq работают нормально, но я ничего не могу сделать с репой. При попытке подключения по ssh мне предлагается ввести пароль от gitlab@host, хотя я создал отдельный ключ для своего логина, записал его через морду в гитлабе и убедился, что он попал в authorized_keys и что authorized_keys читается от пользователя gitlab, однако подключение все равно хочет, чтобы я ввел пароль от пользователя gitlab (http://pastebin.com/TmQDdxb0 ). Когда я добавил http remote (git remote add origin-http http://gitlab.domain.com/user/playground.git), у меня были запрошены логин-пароль, после чего мне было сообщено, что ремоута не существует (проект при этом вообще создан как public):

wtf и что делать?

задан 24 фев '14 в 5:00

Как всегда это бывает, проблема оказалась в поставленных на папку разрешениях. SSH отказывался работать, пока к папке ключей имела доступ группа владельца, ответ нашелся в /var/log/auth.log. Первое время пробиться по SSH все равно не получалось, я на всякий случай принудительно сменил шелл юзеру gitlab на /bin/bash (по идее никакого другого и быть не могло), и внезапно все запустилось.
Параллельно с этим в первый раз не создался сам репозиторий, поэтому не работал http-доступ. При успешном создании репозиторий должен появиться в виде git-файла в %repos_path%/%username%/%reponame%.git (например, /srv/gitlab/repositories/fike/playground.git ).

ответ дан 5 мар '14 в 5:45

SkyCase - Руководство по установке GitLab

Всем привет! В этой статье мы поделимся нашим непростым опытом установки замечательного open source решения GitLab. GitLab — это система управления исходным кодом для git. достойная альтернатива известным проектам GitHub, BitBucket и прочим онлайн git-хостингам. Но давайте обо всем по-порядку.

Что такое GitLab


GitLab сделает вам все то, что сделает GitHub. Вот так вот. Веб-интерфейс для доступа к исходникам проектов, визуальное администрирование git, красивые диффы, wiki, issue tracking и еще куча всего.

А еще у этих ребят отличный логотип!

Кому и зачем нужен GitLab
  1. Тем, кто не хочет открыть код своих проектов всему миру и не готов платить за чужой private хостинг.
    Например, на широко известном GitHub самый дешевый тариф с закрытыми репозитариями составляет сейчас 7$ в месяц. На менее известном Bitbucket приватные репозитарии бесплатны. до тех пор, пока к этим репозитариям имеют доступ максимум 5 человек, а дальше — от 10 $ в месяц.
  2. Тем, кто не может открыть код проектов всему миру.
    Тут тоже все ясно, в коммерческой разработке нередко нужно подписать NDA и другие страшные клятвы, согласно которым код должен находиться в наглухо-замурованном сервере. Можно возразить, что в таком случае достаточно просто поднять git-сервер внутри компании. Но кто будет его администрировать? Кто будет создавать новые проекты, регистрировать пользователей и устанавливать права доступа? Верно, это должен быть человек с основательным знанием Linux-систем вообще, и git в частности. А проделать с репозитарием все вышеупомянутые операции с помощью GitLab сможет любой айтишник.

Не скрываем, SkyCase попал в первую категорию. Облачные сервисы хороши тем, что «не надо париться». Но за это надо платить. Мы решили, что «мы сами умные», и, один раз напрягшись, создадим систему на века. Тем более, что арендовать виртуальный сервер нынче «непозволительно» дешево.

Системные требования GitLab
  • Минимум 1 Gb оперативной памяти
  • Такого же размера swap space
  • Операционная система Ubuntu / Debian
Установка GitLab

Преамбула: ниже описывается, как мы установили GitLab v. 6.2.0 на Ubuntu Server Edition v. 13.04.
Официальное руководство не страдает избыточной информацией, так что нам пришлось изрядно постараться самим. Теперь — закатайте рукава!

  • Разбираемся со swap space
    Сначала проверяем, включен ли swap

Если на вашем сервере обнаружен swap раздел достаточно объема, то смело переходите к следующему пункту. На нашем виртуальном сервере swap был отключен. И мы включили.

  • Устанавливаем Python. Внимание, версия Python должна быть 2.5 и старше, но ниже чем 3.x!

    Если последняя команда выдает ошибку (не найдена команда python2), тогда

  • Ставим git, нужна версия 1.7.10+
  • Ставим почтовый сервер Postfix, нужна версия 1.7.10+
  • Устанавливаем Ruby
  • Ставим Redis server
  • Создаем системного пользователя для git
  • Устанавливаем GitLab shell
  • MySQL. Устанавливаем и создаем базу и пользователя.
  • Наконец пришел черед самого GitLab
  • Глобальная настройка git
  • Ставим нужные Ruby gems
  • Инициализируем базу данных. На вопрос команды ниже отвечаем yes.
  • Делаем GitLab сервис и настраиваем logrotate
  • Проверяем корректность конфигурации GitLab. Если вы (и мы :)) нигде ранее не ошиблись, то все проверки тестов должны пройти.
  • Устанавливаем и настраиваем Nginx
  • Все! Теперь вы можете зайти в GitLab по веб-интерфейсу, логин: admin@local.host, пароль: 5iveL!fe
  • Увы, процедура установки GitLab не очень-то проста. Но цель, в данном случае, полностью оправдывает средства! Остается только пожелать терпения и немного усердия вам и вашему системному администратору!

    Webhook IDOL Wiki

    IDOL Wiki WebHook - инструкция по установке

    Элемент нумерованного спискаСоздаём репозиторий на гитлабе

    Создаём репозиторий на локалке

    Кидаем хук Webhook в папку protected/components и в том же файле настраиваем repository name

    Подключаем его в Контролере(см. ниже «Подключение в контроллере») и необходимо убедится что он доступен без авторизации, как для гостя

    Делаем комит с локалки на гитлаб

    Создаём аккаунт cpanel и подключаемся по ssh в него

    В этом ssh клонируем репозиторий с гитлаба(предварительно настроив ключи)

    Настраиваем ссылку для хука в гитлабе Project » Settings » Web Hooks (пример ссылки http://gevma.idol-it.com/site/webhook )

    Всё готово. Дальше делаем как обычно git push и git pull

    Существующий проект

    Элемент нумерованного спискаСоздаём репозиторий на гитлабе

    Кидаем хук Webhook в папку protected/components и в том же файле настраиваем repository name

    Подключаем его в Контролере(см. ниже) и необходимо убедится что он доступен без авторизации, как для гостя

    Делаем комит с локалки на гитлаб

    Подключаемся по ssh к cpanel аккаунту

    Удаляем старый репозиторий, клонируем репозиторий с гитлаба(настроив ключи)

    Настраиваем ссылку для хука в гитлабе Project » Settings » Web Hooks (пример http://gevma.idol-it.com/site/webhook )

    Всё готово. Дальше делаем как обычно git push и git pull

    Подключение в контроллере

    webhook.txt · Последние изменения: 2015/08/27 04:46 — monkeymafia