Модулі Golang
Проєкт 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.
Операції
Всі модулі 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Випущені модулі повинні бути позначені відповідно до правил https://golang.org/ref/mod#vcs-version, тобто кожен модуль повинен отримати свій власний теґ.Позначення можна виконати за допомогою:
% DRY_RUN=false REMOTE_REPO="origin" ./scripts/release_mod.sh push_mod_tagsВсі модулі etcd повинні залежати від одних і тих же версій основних залежностей. Це можна перевірити за допомогою:
% PASSES="dep" ./test.shФайли go.mod не повинні містити невикористовуваних залежностей і повинні відповідати формату
go mod tidy. Це перевіряється за допомогою:% PASSES="mod_tidy" ./test.shЩоб запустити дії у всіх модулях (наприклад, автоматичне форматування всіх файлів), будь ласка, використовуйте/розширюйте наступний скрипт:
% ./scripts/fix.sh
Майбутнє
Як дороговказ, ми хотіли б оцінити модулі etcd на відповідність моделі:
Це передбачає:
- Відокремлення etcdmigrate/etcdadm від двійкового файлу etcdctl. Завдяки цьому etcdctl стане чітко командним рядком навколо мережевого клієнтського API, тоді як etcdmigrate/etcdadm підтримуватимуть прямі фізичні операції з файлами зберігання etcd.
- Відокремлення etcd-proxy від двійкового файлу ./etcd, оскільки він містить більш експериментальний код і несе додатковий ризик та залежності.
- Відмова від підтримки протоколу v2.
Відгук
Чи це було корисним?
Раді чути! Будь ласка, повідомте нам, як ми можемо зробити краще.
Дуже шкода це чути. Будь ласка, повідомте нам, як ми можемо зробити краще.