Модулі Golang

Організація golang модулів проєкту etcd

Проєкт etcd (з версії 3.5) організований у кілька golang модулів, розміщених в одному репозиторії.

схема модулів

Існують наступні модулі:

  • go.etcd.io/etcd/api/v3 — містить визначення API (наприклад, протоколи та бібліотеки, згенеровані протоколами), що визначають протокол звʼязку між клієнтами та сервером etcd.

  • go.etcd.io/etcd/pkg/v3 — колекція пакунків утиліт, що використовуються etcd без привʼязки до самого etcd. Пакунок є належним тут лише якщо його можна буде в майбутньому перемістити в окремий репозиторій. Будь ласка, уникайте додавання сюди коду, який має багато залежностей, оскільки вони автоматично стають залежностями клієнтської бібліотеки (яку ми хочемо зберегти легкою).

  • go.etcd.io/etcd/client/v3 — клієнтська бібліотека для звʼязку з etcd через мережу (grpc). Рекомендується для всіх нових використань etcd.

  • go.etcd.io/etcd/client/v2 — застаріла клієнтська бібліотека для звʼязку з etcd за допомогою HTTP протоколу. Застаріла. Всі нові використання повинні залежати від бібліотеки /v3.

  • go.etcd.io/etcd/raft/v3 — реалізація протоколу розподіленого консенсусу. Не повинна містити специфічного коду etcd.

  • go.etcd.io/etcd/server/v3 — реалізація etcd. Код у цьому пакунку є внутрішнім для etcd і не повинен використовуватися зовнішніми проєктами. Макет пакунка та API можуть змінюватися в межах мінорних версій.

  • go.etcd.io/etcd/etcdctl/v3 — командний рядок для доступу та управління etcd.

  • go.etcd.io/etcd/tests/v3 — модуль, що містить всі інтеграційні тести etcd. Зверніть увагу: Всі модульні тести (швидкі та не потребують міжмодульних залежностей) повинні залишатися в локальних модулях до коду під тестуванням.

  • go.etcd.io/bbolt — реалізація стійкого b-дерева. Розміщено в окремому репозиторії: https://github.com/etcd-io/bbolt.

Операції

  1. Всі модулі etcd повинні випускатися в одних і тих же версіях, наприклад, go.etcd.io/etcd/client/v3@v3.5.10 повинен залежати від go.etcd.io/etcd/api/v3@v3.5.10.

    Послідовне оновлення версій можна виконати за допомогою:

    % DRY_RUN=false TARGET_VERSION="v3.5.10" ./scripts/release_mod.sh update_versions
    
  2. Випущені модулі повинні бути позначені відповідно до правил https://golang.org/ref/mod#vcs-version, тобто кожен модуль повинен отримати свій власний теґ.Позначення можна виконати за допомогою:

    % DRY_RUN=false REMOTE_REPO="origin" ./scripts/release_mod.sh push_mod_tags
    
  3. Всі модулі etcd повинні залежати від одних і тих же версій основних залежностей. Це можна перевірити за допомогою:

    % PASSES="dep" ./test.sh
    
  4. Файли go.mod не повинні містити невикористовуваних залежностей і повинні відповідати формату go mod tidy. Це перевіряється за допомогою:

    % PASSES="mod_tidy" ./test.sh
    
  5. Щоб запустити дії у всіх модулях (наприклад, автоматичне форматування всіх файлів), будь ласка, використовуйте/розширюйте наступний скрипт:

    % ./scripts/fix.sh
    

Майбутнє

Як дороговказ, ми хотіли б оцінити модулі etcd на відповідність моделі:

графік модулів

Це передбачає:

  • Відокремлення etcdmigrate/etcdadm від двійкового файлу etcdctl. Завдяки цьому etcdctl стане чітко командним рядком навколо мережевого клієнтського API, тоді як etcdmigrate/etcdadm підтримуватимуть прямі фізичні операції з файлами зберігання etcd.
  • Відокремлення etcd-proxy від двійкового файлу ./etcd, оскільки він містить більш експериментальний код і несе додатковий ризик та залежності.
  • Відмова від підтримки протоколу v2.