gitlab поиск по коду

Как работать с GitLab

Сегодня поговорим об азах взаимодействия с одной из самых популярных git-систем.

Что такое GitLab

Сейчас почти никто не пишет код в одиночку. Команды инженеров и разработчиков растут, как на дрожжах. Работая в группах, программисты используют системы управления исходным кодом на базе git, специального инструмента, позволяющего хранить данные разрабатываемого проекта в сети и совместно редактировать его с учетом определенных правил и методик взаимодействия. Самый известный подобный сервис – GitHub. А GitLab – это его собрат, выполняющий те же функции, но устроенный несколько иначе.

GitLab позволяет управлять репозиториями с кодом, отслеживать ошибки в разрабатываемых программах, публиковать код и тестировать его. Это незаменимый инструмент для каждого, кто программирует не в одиночку.

Разница между GitLab и GitHub

Оба сервиса – системы управления репозиториями на базе git. Принципиальных отличий между ними нет. GitHub появился раньше и стал чуть ли не синонимом git, поэтому он популярнее и для многих является единственной системой для управления репозиториями.

Но GitLab есть что предложить с точки зрения функциональности, поэтому все чаще наблюдается переход пользователей с GitHub на GitLab. В частности, это касается разработчиков-новичков, которые пока еще не «приросли» к GitHub.

В связи с растущей популярностью GitLab я и решил познакомить вас с этим сервисом поближе.

Инструкция по использованию GitLab

Перед началом работы с сервисом, нужно создать учетную запись. Процедура эта весьма тривиальна:

Заходим на официальный сайт GitLab.

В верхнем левом углу находим кнопку Login и жмем по ней.

Через пару секунд перед вам откроется форма входа в систему, а под ней будет ссылка на форму регистрации (Register now). Переходим по ней.

Заполняем данные для регистрации (классические данные: адрес электронной почты, пароль, логин и т.п.). Жмем на кнопку Register.

В течение пары минут на указанную при регистрации почту «упадет» сообщение со ссылкой для подтверждения создания аккаунта. Переходим по ней.

Учетная запись готова. Теперь можно переходить непосредственно к знакомству с GitLab.

Как создать проект

Проектом в GitLab считается глобальное рабочее пространство, в котором будет размещен репозиторий с файлами ваших сайтов и приложений. А также в нем можно взаимодействовать с коллегами и использовать другие возможности сервиса.

Поэтому при первом входе под своей учетной записью GitLab попросит вас указать род деятельности, наличие или отсутствие команды, имя рабочей группы и название проекта.

После формирования проекта можно переходить непосредственно к созданию репозиториев, загрузке программ в GitLab и т.п.

Как создать репозиторий

Чтобы воспользоваться репозиторием, нужно создать новый проект:

Кликаем по иконке со значком + в панели управления.

Выбираем пункт New project/repository.

Затем кликаем по Create blank project.

Указываем его имя и другие запрашиваемые параметры (можно указать, публичным будет репо или приватным) и нажимаем на кнопку Create Project.

Вместе с проектом сформируется новый git-репозиторий. Теперь можно с ним взаимодействовать, то есть загружать файлы, делать коммиты, создавать различные ветки для разработки продукта и мерджить их при необходимости.

Как загрузить файлы сайта/приложения в GitLab

Первый – используем веб-интерфейс GitLab

На главной странице проекта ищем строку The repository for this project is empty, а под ней кнопку Upload File и нажимаем на нее.

GitLab предложит выбрать файлы проекта для загрузки и последующей работы с ними. Выбираем все файлы, что используем при разработке и выгружаем.

Также можно использовать WebIDE, встроенную в GitLab, чтобы прямо в браузере писать код и создавать файлы для своего приложения/сайта.

Второй – используем командную строку

Тут все сложнее, но на самом GitLab опубликована короткая и доходчивая инструкция по подключению к сервису через командную строку, используя классический git-клиент.

Третий – используем сторонний git-клиент

Существуют приложения в духе Tower и Sublime Merge, позволяющие управлять репозиториями, делать коммиты и пушить изменения в проекты при помощи удобного графического интерфейса. Можно подключиться к GitLab с помощью одной из таких программ.

Как добавить SSH-ключ для подключения к репозиторию

SSH-ключи можно использовать для авторизации в GitLab и для управления репозиториями по протоколу Secure Shell. Чтобы это сделать:

Генерируем ключ с помощью команды ssh-keygen (вводим ее в терминал).

Генератор предложит сохранить получившийся ключ. Менять директорию, куда сохраняется ключ, необязательно.

Затем утилита попросит ввести пароль. Его тоже можно не вводить. Просто жмем на Enter.

Возвращаемся на сайте GitLab. Открываем раздел SSH-keys, вставляем ключ в специально отведенное для этого поле и нажимаем на кнопку Add key.

Как работать с ветками

Ветки – это инструмент для создания дополнительных вариаций приложения/сайта, которые позволяют вести разработку новых функций, не затрагивая при этом основное приложение, доступное для пользователей.

По умолчанию в GitLab доступна только одна ветка – master. Но ее чаще используют не для разработки, а для публикации готовых сборок проекта, которые нестрашно превратить в релиз для масс.

Поэтому принято создавать новые ветки для разработки дополнительных функций, а уже потом объединять их с основной.

Как создавать ветки

Ветки – не уникальная для GitLab функция. Это часть git, поэтому, как и в случае с репозиториями, тут можно пойти тремя путями:

На сайте GitLab в окне управления репозиторием нажать на кнопку + справа от названия ветки, а потом выбрать пункт New branch в выпадающем меню.

Или воспользоваться аналогичной функций в используем графическом git-клиенте (Tower, Sublime Merge, GitFox и т.п.).

Любой из способов позволит создавать новую ветку, в которую после этого можно будет отправлять коммиты и делать пуши.

Мерджинг веток

Мерджинг (или объединение) веток – это механизм слияния двух наборов функций одной программы, позволяющий переносить функции из дополнительных веток в основную ветку разработки, где лежит приложение. Результат увидят еще и пользователи, а не только разработчики.

Запрос на объединение веток будет появляться на сайте GitLab каждый раз, когда вы будете вносить изменения в код одной или нескольких веток.

Выглядит это следующим образом:

На сайте появляется большая синяя кнопка Create merge request. Кликаем по ней.

Затем рассказываем о своем запросе (поясняем, для чего он делается).

Указываем автор запроса в поле Assignee.

Указываем человека, который будет проверять запрос в поле Reviewer.

Потом указываем Milestone (если используете их).

И нажимаем на Create merge request.

Если с запросом все ок, то проверяющий нажмет на кнопку Merge, и весь код перекочует в основную ветку проекта (ну или ту, которую указал автор запроса).

Как добавлять пользователей в проект

К разработке своего приложения/сайта всегда можно привлечь людей со стороны:

Для этого кликаем по кнопке Project information в боковой панели GitLab.

Выбираем пункт Members.

В графу GitLab member or Email address вписываем ник GitLab-пользователя или его email-адрес.

Выбираем для него роль (гость, наблюдатель, разработчик).

Также указываем время действия приглашения (в указанный день приглашенный будет исключен из проекта).

А потом кликаем на Invite.

Если выбранный человек согласится присоединиться, то ваша команда расширится.

Как создавать баг-репорты

В git-системах есть инструменты, помогающие оповещать разработчиков об ошибках и обсуждать их как с пользователями, так и с коллегами.

Речь идет о разделе Issues. Если возникла проблема, то нужно сообщить о ней тут. Для этого:

Открываем раздел Issues в боковой панели управления.

Затем нажимаем на кнопку New issue.

Даем имя обнаруженной проблеме, а затем подробно описываем ее в разделе Description.

Затем назначаем ответственного в пункте Assignee и срок, в течение которого нужно найти решение найденной проблемы.

А потом нажимаем на кнопку Create issue.

Как удалить проект

Открываем настройки проекта и переходим во вкладку General.

Листаем ее до пункта Advanced и справа от него ищем кнопку Expand, которая откроет доступ к дополнительным параметрам.

Вновь пролистываем появившееся меню до упора вниз, пока не наткнемся на кнопку Delete project.

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

Вместо заключения

На этом все. Я рассмотрел базовые возможности GitLab и намеренно не затрагивал аналитические инструменты, интеграцию с Kubernetes и дополнительные функции, пытаясь сконцентрироваться на важнейших концептах GitLab и git. Это то, что вам необходимо для старта, независимо от того, пользовались вы ранее другими системами управлениями репозиториями или нет.

Источник

Опыт миграции из Gitea в GitLab. Сложно, но успешно

В мире существует множество различных систем для хранения кода. Различаются они как протоколом работы: Git, Mercurial, Bazaar, — так и форматом работы (cloud, self-hosted). Но есть и другой важный параметр при их выборе: степень интеграции с сопутствующим инструментарием: issue tracker, CI/CD, wiki и т.д. Так сложилось, что мы в компании предпочитаем GitLab (вариант on-premise) и по умолчанию, если клиент не против, предлагаем ему это решение. В статье я расскажу про миграцию из Gitea c Jenkins в GitLab и о том, с какими сложностями пришлось столкнуться, а заодно поделюсь Python-скриптами, которые пригодились для успеха этого мероприятия.

Важно! В статье рассматривается Gitea 1.13.4 и GitLab 13.8. В новых версиях могут быть какие-то улучшения, которые облегчат перенос, но на момент миграции эти версии были актуальными.

Немного про Gitea и задачу

Gitea — легковесная Open Source-система для управления Git-репозиториями. Это форк другой легковесной системы — Gogs. Она интересна возможностью сочетать в одном инстансе несколько организаций с довольно широким спектром настроек прав доступа и GitHub-подобным API.

Проект популярен и имеет более 25 тысяч звёзд на GitHub. Среди спонсоров — DigitalOcean и Equinix, а также поддержать Gitea можно на Open Collective (и проследить, куда пойдут ваши средства).

Как вылядит веб-интерфейс Gitea

Из плюсов хочется отметить, что Gitea очень проста как в установке и настройке, так и в бэкапе. Систему можно запустить на любом относительно современном компьютере, и она предложит некоторые встроенные сервисы: wiki-страницы, задачи и проекты, т.е. todo-листы.

Но эта простота может иметь и обратную сторону. В приложении нет готового CI/CD, и для реализации этих механизмов приходится использовать стороннее решение. В нашем случае у клиента эту роль играл Jenkins, для которого существует специальный плагин. Однако данный выбор был скорее историческим наследием, чем технической необходимостью. CI/CD с ним был не очень удобен в работе. Для оптимизации процесса деплоя мы сошлись на переходе на GitLab, а это означало и замену самой Gitea, функции которой теряли смысл. Также в процессе работ были найдены мелкие проблемы, которые мешали миграции.

Что было на старте

Исходное состояние — Gitea 1.13.4 со 165 репозиториями и 94 пользователями. Всё это было разложено по 18 организациями, а некоторые репозитории были личными.

Кроме того, клиент не хотел терять историю pull requests, а их было достаточно много: в некоторых репозиториях — более 5 тысяч.

Статистика по инсталляции Gitea до переноса

Несмотря на то, что самих пользователей, а также организаций и групп было не так уж и много, «накликивать» такое (да ещё и без ошибок) — это очень долго.

Да и вообще, мы же инженеры! Поэтому пошли путем автоматизации и ниже расскажем о проблемах, которые пришлось преодолеть. Попутно мы научимся работе с REST API обоих решений: и Gitea, и GitLab. Посему этот опыт может оказаться полезным не только для непосредственной миграции, но и повседневных задач.

Реализация: импорт, экспорт, перенос

Итак, перейдем к самой миграции. Оба проекта имеют развитый API. Выберем клиенты для работы с API обеих систем:

Для Gitea я выбрал Python-вариант giteapy. К сожалению, он не так хорош, как аналогичный для GitLab. (В процессе повествования ещё встретятся соответствующие ремарки.)

Часть 1. Пользователи

Для подключения к GitLab используется единый класс:

И уже тут ожидал первый сюрприз:

Вы спросите: что же не так? Очень просто: в выводе API не видно, заблокирован пользователь или нет. Изучение всех возможных методов привело к необходимости запрашивать эту информацию из базы Gitea. Благо, это не такая уж и проблема — она решается простым запросом:

Заблокированных пользователей было немного (около 10), и мы перенесли их вручную.

SSH-ключи

Логично предположить, что если стоит задача миграции, нам требуется перенести еще и SSH-ключи пользователей. В библиотеке клиента API Gitea описан метод user_current_get_key. Однако он работает странным образом:

если у пользователя много ключей, он возвращает всего один ключ;

если ключей нет — он возвращает ошибку 404.

При первичном переносе мы это обстоятельство не учли и использовали вызов API как есть. В результате были получены неверные ключи — их не хватало. Поэтому настоятельно советую использовать метод user_list_keys. Однако и с ним нас ждал подвох: в базе отсутствует уникальный индекс по fingerprint.

Из-за этого в момент переноса пришлось решать конфликтные ситуации при импорте ключей в GitLab. К счастью, эти ключи были в основном у заблокированных пользователей. Поэтому мы приняли простое решение — удалить все ключи у заблокированных пользователей, которые были перенесены. В GitLab это делается вот так:

Права

Следующий шаг — выдача верных прав. Организации Gitea преобразуются в группы GitLab, а команды преобразуются в права доступов.

Получив все команды из API, мы согласовали с клиентом матрицу сопоставления прав:

Почтовые уведомления

Что произойдет после этих манипуляций? Перенос пользователей «породит» массу почтовых сообщений: о создании пользователя, о предоставлении доступа и т.п. Поэтому стоит заранее решить, оставлять эту корреспонденцию или же перенаправить в чёрную дыру.

Если вы не хотите рассылать почту и делать временные пароли, которые потом раздадите клиентам, создание пользователя будет выглядеть так:

Промежуточные итоги

Проблемы, выявленные в Gitea за время этих операций:

отсутствие важной информации о свойствах пользователя в API;

неочевидные методы API для работы с ключами;

С другой стороны, в GitLab есть проблема с подтверждением email. Итоговый скрипт миграции пользователей можно найти в нашем репозитории с примерами.

Часть 2. Репозитории

Теперь, когда готово дерево пользователей, можно произвести миграцию репозиториев. GitLab умеет импортировать проекты Gitea уже с версии 8.15. Однако всё не так просто, как хотелось бы.

Начнём с того, что надо добавить нашего пользователя, которого мы завели в Gitea для миграции, во все репозитории. В этом поможет такой скрипт.

Здесь опущено подключение к API, так как пример был уже выше. Можно заметить еще одну проблему клиента к Gitea: в разных местах попеременно используется либо User ID, либо User Login. Местами это неудобно, т.к. требует постоянно сверяться с документацией.

Теперь, когда все репозитории видны в API, можно попробовать начать импортировать их в GitLab. Казалось бы, процесс не будет сложным: зайти в создание нового проекта, нажать кнопку импорта… но так ничего не импортируется. В реальности проблемы будут встречаться на каждом шагу.

nginx как решение двух недостатков в API

Для начала стоит отметить, что GitLab знает, что API Gitea устроен аналогично API GitHub, и использует Octokit Gem. Однако имплементация API у нас не является полной. Поэтому импорт периодически спотыкается. Есть 2 основных момента:

Отсутствие rate_limit в API;

Путаница с путями, когда Octokit пытался добавить мусорный префикс в запросы.

К счастью, исходный инстанс Gitea был за реверсным прокси на основе nginx, так что удалось дописать его конфигурацию, чтобы обойти эти проблемы.

Первым делом разберемся с rate limit. Это встроенный метод, через который Octokit спрашивает, как часто он может отправлять запросы в API. При запросе к корневым методам Gitea отдаёт 404, что клиентом воспринимается как Unimplemented :

Однако запрос к RepoApi возвращает 401, из-за чего импорт останавливается:

Чтобы обойти это, сделаем такой location в nginx:

Все запросы вернут 404 — миграция пойдёт без проблем.

Вторая проблемы была интереснее: Octokit делал запросы с мусорным префиксом. Допустим, у нас есть org1 с project1 и есть пользователь i.ivanov с project2 в личном пространстве имён. В логе nginx появятся странные запросы:

В общем, пришлось написать rewrite, который исправлял неверные запросы:

После этого проблемные запросы были переписаны и, наконец-то, импорт прошел успешно!

Полный импорт

Останется последняя проблема: у нас 160 проектов, которые надо импортировать в верные namespaces. К сожалению, импорт через API не позволяет сделать полный импорт и поддерживает только импорт архива, который не даёт загрузить merge requests, issues и другие вспомогательные вещи. Пришлось сделать скрипт, который бы работал с GitLab WebUI и отправлял запросы на импорт.

Я предпочел сделать скрипт для Selenium:

Затем, используя полученную сессию, запросим страницу импорта:

А теперь начнём импорт всех репозиториев. Для этого инициализируем подключение к Gitea и начнём импортировать репозитории:

Казалось бы, вот и всё! Но это, к сожалению, не так.

Финальный штрих

После миграции мы временно подключили GitLab к Jenkins и получили ошибку:

Оказалось, что при переносе были потеряны Git references. Чтобы это исправить, мы решили во все ветки, которые имеют открытые merge requests, сделать пустые коммиты. Это действие пересоздаст references.

Вот реализация такого workaround:

После выполнения скрипта всё заработало корректно.

Полные листинги Python-скриптов, приведённых в статье, доступны в репозитории flant/examples.

Получившаяся инсталляция GitLab. В неё были добавлены новые пользователи, а некоторые старые проекты удалены

Выводы

Миграция из Gitea в GitLab, несмотря на кажущуюся простоту, оказалась непростой задачей. Чтобы добиться результата, пришлось написать ряд скриптов и пройти через множество неожиданных нюансов из-за неполноты в реализации и совместимости разных API. Тем не менее, это удалось, и надеюсь, что полученный опыт поможет кому-нибудь в миграции и облегчит жизнь.

Источник

Проверка образов с помощью Gitlab CI/CD

Всем привет, в преддверии старта курса «CI/CD на AWS, Azure и Gitlab» подготовили перевод интересного материала.

В этой статье мы поговорим о том, как проверять образы контейнеров на платформе Gitlab CI/CD с помощью Sysdig Secure.

Образы контейнеров, которые не соответствуют политикам безопасности, определенным в Sysdig Secure, не будут опубликованы в реестре контейнеров и остановят пайплайн.

Поиск уязвимостей с помощью Gitlab CI/CD

Gitlab CI/CD – это open source сервер непрерывной интеграции и доставки, встроенный в платформу разработки программного обеспечения и коллаборации Gitlab.

После того, как вы настроите для своего репозитория Gitlab CI/CD, каждый раз, когда разработчики будут коммитить в отслеживаемые ветви репозитория, сценарии пайплайна будут запускаться автоматически.

Такие пайплайны можно использовать для автоматизации многих процессов. Например, для QA-тестирования, создания артефактов распространения программного обеспечения (таких как Docker-образы или пакеты Linux) или, для того, о чем мы будем говорить в этой статье — для проверки конфигурации, поиска уязвимостей и проверки на соответствие требованиям.

Проверка образов на пайплайне Gitlab CI/CD: shift left security

Как и везде в IT, чем раньше вы обнаружите в контейнере уязвимость, тем быстрее и проще вы сможете ее исправить без последствий.

Внедрение проверки на уязвимости в ваш пайплайн сборки – это хорошая практика по нескольким причинам:

Требования для проверки безопасности на Gitlab

Чтобы выполнить следующие шаги, вам понадобится:

Настройка Gitlab CI/CD пайплайна для проверки образов с помощью Sysdig Secure

Мы посмотрим на практике как можно интегрировать эти две платформы. С помощью этого руководства вы научитесь работать с Sysdig Secure Image scanning в считанные минуты.

Настройка учетных данных доступа

Пайплайну Gitlab CI/CD понадобятся учетные данные доступа, чтобы установить связь с бэкендом Sysdig Secure. Для того, чтобы сделать все правильно, скопируйте access-токен из Sysdig UI Settings > User profile.

Затем настройте новую глобальную переменную для вашего проекта на Gitlab:

Определение пайплайна Gitlab

Для начала нам понадобится Docker-файл, определяющий образ, который вы будете собирать. Вы можете загрузить в свой проект любой Docker-файл, который захотите, или просто используйте следующий пример:

В нашем пайплайне сейчас 3 стадии:

Сборка образа контейнера

Проверка образа на наличие уязвимостей

Следующая стадия – это проверка контейнеров. Здесь мы будем проверять образ на наличие уязвимостей и проверять конфигурацию, сохраняя результаты на бэкенде Sysdig.

Одним из преимуществ локального сканирования Sysdig является то, что вы не теряете контроль над своими образами, поскольку образ не нужно перемещать в другой реестр или подвергать воздействию извне, чтобы провести проверку. Она происходит внутри runner’а, а в Sysdig Secure отправляются только результаты.

На этой стадии Sysdig Secure вернет код ошибки, если образ будет отвечать любому из условий остановки, указанных в вашей политике (например, критическую уязвимость). Остановка пайплайна предотвратит передачу уязвимых образов в реестр контейнеров.

В Sysdig Secure мы можем посмотреть дополнительную информацию и понять, почему не удалось завершить проверку на безопасность:

Как видно на скриншоте, контейнер оставляет открытым 22 порт, который находится в списке запрещенных портов, а также содержит некоторые серьезные уязвимости в библиотеке Python.

Перемещение образа в конечный репозиторий

После успешной проверки на уязвимости пайплайн выполнит docker push и образ будет опубликован в реестре контейнеров. Если вы не укажете никаких учетных данных или удаленного хранилища, Gitlab использует дефолтное.

Заключение

С помощью Sysdig Secure image scanning вы можете проверять образы в пайплайне Gitlab CI/CD, не отправляя их из инфраструктуры в публичный или промежуточный реестр, проверить конфигурацию и предотвратить просачивание уязвимостей на продакшен.

Найдите известные уязвимости и проверьте конфигурацию на соответствие рекомендациям по безопасности, включая инструкции Dockerfile, белый и черный списки пакетов или сторонних библиотек, установленных в базовый образ, таких как JAR/WAR-файлы в Java или языковые менеджеры пакетов, такие как npm для Javascript, pip для Python и gem для Ruby.

При сбое можно быстро сообщить об этом автору контейнера, чтобы оперативно решить проблему и создать secure-by-default политику безопасности контейнеров. Чтобы попробовать Sysdig Secure, вы можете запросить демо-версию уже сегодня!

На этом все. Узнать о курсе подробнее можно тут.

Источник