GitLab та віддалений репозиторій

GitLab є одним з найпопулярніших програмних рішень для DevOps інженерів з кількома перевагами порівняно з іншими рішеннями:

1. Єдиний інструмент для всього циклу розробки: GitLab надає широкий набір функцій, що охоплюють всі етапи розробки, включаючи управління кодом, CI/CD, контейнеризацію, моніторинг та багато іншого. Це дозволяє DevOps інженерам працювати з одним інструментом замість використання декількох рішень.

2. Інтеграція з іншими інструментами: GitLab має широку підтримку інтеграції з іншими популярними інструментами, такими як Jira, Jenkins, Kubernetes, Prometheus та багато інших. Це дозволяє легко і безперервно інтегрувати GitLab у наявну інфраструктуру.

3. Вбудована CI/CD платформа: GitLab має вбудовану CI/CD платформу, що дозволяє автоматизувати процеси збирання, тестування та розгортання програмного забезпечення. Це дозволяє DevOps інженерам швидко та надійно впроваджувати зміни в продуктивне середовище.

4. Управління версіями та співпраця: GitLab забезпечує потужні можливості управління версіями за допомогою Git, що дозволяє командам ефективно працювати з кодом. Крім того, GitLab надає зручні інструменти для співпраці, такі як pull requests, code reviews та інші, що полегшують командну роботу.

5. Відкритий код та гнучкість: GitLab є програмним рішенням з відкритим вихідним кодом, що дозволяє користувачам налаштовувати його під свої потреби. Крім того, GitLab надає можливість використовувати хмарну версію або розгортати його на власних серверах.

На мою думку, GitLab на сьогодні є кращим вибором для DevOps інженерів, які шукають повний набір інструментів для ефективної розробки та впровадження програмного забезпечення.

Він нам знадобиться для подальшого навчання та освоєння підходу GitOps.

Робота з віддаленим репозиторієм

На початку розділу ми визначили що Git є децентралізованою системою контролю версій. Отже завжди може бути декілька копій, які можливо між собою синхронізувати.

Цю синхронізацію можна виконати за допомогою:

• HTTP
• SSH
• просто вказавши шлях у файловій системі до каталогу з іншим репозиторієм. Таки практика дуже зручна якщо вам треба переносити код на зовншнеьому носії або не має доступу до мережі.

Аутентифікація на основі ключів у SSH

Наразі найбільш захищенним методом обміну змінами між репозиторіями через SSH. Для того щоб користуватися цим методом, давайте трохи розберемося з асиметричним шифруванням.

Для приватного ключа може бути безліч публічних ключів, оскільки ви можете додавати їх до різних віддалених серверів або облікових записів. Навпаки, для аутентифікації по SSH з одним публічним ключем може працювати лише один приватний ключ. Кожен приватний ключ відповідає лише одному публічному ключу і використовується для аутентифікації на віддаленому сервері.

Аутентифікація з використанням приватного та публічного ключа є безпечним методом обміну змінами між репозиторіями через SSH. Цей процес включає наступні кроки:

1. Генерація ключів: Спочатку генерується пара ключів - приватний та публічний. Приватний ключ залишається на локальному комп'ютері, а публічний ключ передається на віддалений сервер.

2. Надсилання публічного ключа: Публічний ключ додається до віддаленого сервера, зазвичай до файлу ~/.ssh/authorized_keys. Це дозволяє серверу перевірити, чи відповідає приватний ключ, який буде використовуватися для аутентифікації, публічному ключу.

3. Запит на аутентифікацію: Коли ви намагаєтесь з'єднатися з віддаленим сервером, ваш SSH-клієнт надсилає запит на аутентифікацію. У цьому запиті він надсилає свій публічний ключ.

4. Перевірка публічного ключа: Віддалений сервер перевіряє, чи є публічний ключ, надісланий SSH-клієнтом, у списку довірених ключів. Якщо ключ знайдено, сервер надсилає випадковий виклик до клієнта.

5. Підпис виклику: SSH-клієнт використовує свій приватний ключ для підпису виклику і надсилає його на сервер.

6. Перевірка підпису: Віддалений сервер перевіряє підпис, використовуючи публічний ключ, який він має. Якщо підпис вірний, сервер вважає, що аутентифікація пройшла успішно і дозволяє доступ до репозиторію.

Цей процес забезпечує безпеку під час обміну змінами між репозиторіями, оскільки приватний ключ залишається на локальному комп'ютері і не передається по мережі. Таким чином, лише власник приватного ключа може підписати виклик і пройти аутентифікацію на віддаленому сервері.

Більш детальну інформацію про аутентифікацію з використанням приватного та публічного ключа можна знайти у статті тут.

Типи ключів

Рекомендований тип ключа для використання залежить від конкретних потреб та обмежень. Однак, якщо безпека є пріоритетом, рекомендується використовувати ECDSA або Ed25519 ключі, оскільки вони забезпечують високий рівень безпеки при меншому розмірі ключа порівняно з RSA. RSA ключі також є прийнятним варіантом, особливо якщо підтримка старих SSH-клієнтів та серверів є важливою.

Створення SSH ключів та додавання їх у GitLab

Для створення SSH ключів локально та додавання їх у свій профіль на GitLab, слід виконати наступні кроки:

1. Відкрийте командний рядок або термінал на вашому локальному комп'ютері.

2. Введіть наступну команду, щоб створити нову пару SSH ключів:

    ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
   

   Замініть "your_email@example.com" на свою електронну адресу, пов'язану з вашим обліковим записом GitLab.

3. Після введення команди, вас буде запрошено вказати шлях та ім'я файлу для збереження ключів. За замовчуванням, ключі будуть збережені у вашому домашньому каталозі, у підкаталозі .ssh/. Ви також можете вказати пароль для захисту приватного ключа, але це необов'язково.

4. Після створення ключів, введіть наступну команду, щоб переглянути публічний ключ:

    cat ~/.ssh/id_rsa.pub
   

   З'явиться вміст вашого публічного ключа. Скопіюйте його.

5. Увійдіть до свого облікового запису GitLab та відкрийте свій профіль.

6. У розділі "Settings" виберіть "SSH Keys".

7. У полі "Key" вставте скопійований публічний ключ.

8. Надайте ключу опис та натисніть "Add key" для збереження.

Тепер ви створили SSH ключі локально та додали їх у свій профіль на GitLab. Ви можете використовувати ці ключі для аутентифікації при з'єднанні з віддаленим репозиторієм на GitLab за допомогою протоколу SSH.

Налаштування GitLab та клонування репозиторію

Щоб створити репозиторій у GitLab та склонувати його локально за допомогою командного рядка, слід виконати наступні кроки:

1. Увійдіть до свого облікового запису GitLab та створіть новий репозиторій.
2. Після створення репозиторію, скопіюйте URL-адресу репозиторію.
3. Відкрийте командний рядок або термінал на вашому локальному комп'ютері.
4. Змініть поточний робочий каталог на той, де ви хочете склонувати репозиторій.

5. Введіть наступну команду, замінивши $REPO_URL на скопійовану URL-адресу репозиторію:

    git clone $REPO_URL
   

   Ця команда створить локальну копію репозиторію на вашому комп'ютері.

6. Після успішного виконання команди, ви зможете працювати з репозиторієм локально та здійснювати зміни, які потім можна буде синхронізувати з віддаленим репозиторієм на GitLab.

Робота з віддаленим репозиторієм

У Git, origin - це стандартне ім'я, яке використовується для позначення віддаленого репозиторію, з яким ви співпрацюєте. Зазвичай, origin вказує на віддалений репозиторій, з якого ви склонували свій локальний репозиторій.

Щоб налаштувати віддалений репозиторій, ви можете використовувати команду git remote add. Наприклад, якщо ви хочете додати віддалений репозиторій з ім'ям origin та URL-адресою https://gitlab.com/username/repo.git, ви можете виконати наступну команду:

git remote add origin https://gitlab.com/username/repo.git

Ця команда додасть віддалений репозиторій з ім'ям origin до вашого локального репозиторію.

Щоб працювати з декількома віддаленими репозиторіями одночасно, ви можете використовувати різні імена для кожного віддаленого репозиторію. Наприклад, якщо у вас є два віддалених репозиторії з іменами origin та upstream, ви можете виконати наступні команди:

git remote add origin https://gitlab.com/username/repo.git
git remote add upstream https://gitlab.com/upstream/repo.git

Тепер ви можете використовувати імена origin та upstream для виконання різних операцій з віддаленими репозиторіями, наприклад, отримання змін з upstream або відправлення змін до origin.

Створюємо більш інформативні комміти

У більшості випадків ніхто не задумується нат тим, що писати у назву комміту - до того часу поки сам не спробуєш прочитати чужу історію і зрозуміти, що тут відбувається?

Тому далі наведено приклад шаблону для комміту, який можна взяти за основу під час опису власних коммітів.

# Title: Summary, imperative, start upper case, don't end with a period
# No more than 50 chars. #### 50 chars is here:  #

# Remember blank line between title and body.

# Body: Explain *what* and *why* (not *how*). Include task ID (Jira issue).
# Wrap at 72 chars. ################################## which is here:  #

# At the end: Include Co-authored-by for all contributors.
# Include at least one empty line before it. Format:
# Co-authored-by: name <user@users.noreply.github.com>
#
# How to Write a Git Commit Message:
# https://chris.beams.io/posts/git-commit/
#
# 1. Separate subject from body with a blank line
# 2. Limit the subject line to 50 characters
# 3. Capitalize the subject line
# 4. Do not end the subject line with a period
# 5. Use the imperative mood in the subject line
# 6. Wrap the body at 72 characters
# 7. Use the body to explain what and why vs. how

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Your branch is up to date with 'origin/main'.
#
# Changes to be committed:
#       new file:   installation.md
#

7 правил хорошого опису комміту

1. Відокремлюйте тему листа від тіла порожнім рядком
2. Пишіть коротку тему до 50 символів
3. Рядок теми починайте з великої літери
4. Не закінчуйте тему крапкою
5. Використовуйте наказовий відмінник у темі
6. Ширина тіла не повинна перевищувати 72 символами
7. Використовуйте тіло, щоб пояснити, що і чому, а не як

[!NOTE] Додатково до цього рекомендую ознайомитися з Політикою Комітів Яка описуэ додавання зручних для читання коміт-повідомлень для людей та роботів.