Як висушити вашу конфігурацію Apache APISIX

Не повторюйся або DRY є важливим принципом у розробці програмного забезпечення. Ця публікація покаже вам, як застосувати його до конфігурації Apache APISIX.

Принцип DRY

«Не повторюйся» (DRY) — це принцип розробки програмного забезпечення, спрямований на зменшення повторення інформації, яка, ймовірно, буде змінюватися, замінюючи її абстракціями, які менш імовірно змінюватимуться, або використовуючи нормалізацію даних, яка в першу чергу уникає надмірності. .

-- Вікіпедія – не повторюйтесь

Основна ідея DRY полягає в тому, що якщо ви повторюєте себе і інформація змінюється, ви повинні оновити змінену інформацію в кількох місцях. Це не лише додаткові зусилля; є шанс, що ви забудете про це і матимете різну інформацію в різних місцях. DRY блищить у виправленні помилок.

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

Існує висока ймовірність того, що особа, яка дублює, і особа, яка виправляє, різні. Якщо фрагмент було перероблено для спільного використання та викликано з двох місць, вам потрібно виправити помилку лише в цьому місці.

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

Принцип був сформульований Енді Хантом і Дейвом Томасом у їхній книзі «Прагматичний програміст». Вони застосовують його досить широко, включаючи схеми бази даних, плани тестування, систему збірки і навіть документацію.

-- Вікіпедія – не повторюйтесь

Системи конфігурації звуку дозволяють DRY або навіть заохочують його.

DRY в Apache APISIX

Apache APISIX пропонує конфігурацію DRY у двох місцях.

СУХИЙ Верхня течія

У контексті електронної комерції ваша подорож для початківців до визначення маршруту в Apache APISIX, ймовірно, починається так:

 routes: - id: 1 name: Catalog uri: /products* upstream: nodes: "catalog:8080": 1

Якщо ви знайомі з APISIX, ми визначили маршрут до каталогу за URI /products . Однак є проблема: ви, ймовірно, хочете, щоб потенційні клієнти переглядали каталог, але не хочете, щоб люди створювали, видаляли або оновлювали продукти. Тим не менш, маршрут відповідає кожному методу HTTP за замовчуванням.

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

 routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] #1 uri: /products* upstream: #2 nodes: "catalog:8080": 1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] #3 uri: /products* plugins: key-auth: ~ #4 upstream: #2 nodes: "catalog:8080": 1

1. Відповідність перегляду
2. Дубльовано вище за течією!
3. Ведення матчу
4. Тільки автентифіковані споживачі можуть використовувати цей маршрут; key-auth — найпростіший плагін для цього

Ми усунули проблему безпеки найпростішим можливим способом: шляхом копіювання та вставки. Зробивши це, ми продублювали upstream частину. Якщо нам потрібно змінити топологію, наприклад , шляхом додавання або видалення вузлів, ми повинні зробити це в двох місцях. Це порушує принцип DRY.

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

Разом з абстракцією Route APISIX пропонує абстракцію Upstream для реалізації DRY. Ми можемо переписати наведений вище фрагмент так:

 upstreams: - id: 1 #1 name: Catalog nodes: "catalog:8080": 1 routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /products* upstream_id: 1 #2 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /products* upstream_id: 1 #2 plugins: key-auth: ~

1. Визначте вгору з ідентифікатором 1
2. Посилання на це в маршруті

Якщо щось станеться в топології, ми повинні оновити зміни лише в єдиному Upstream .

Зверніть увагу, що визначення вбудованого upstream і посилання на нього за допомогою upstream_id є взаємовиключними .

Конфігурація плагіна DRY

Ще одна область, де APISIX може допомогти вам ВИСУШИТИ вашу конфігурацію за допомогою абстракції плагіна . APISIX реалізує більшість функцій, якщо не всі, за допомогою плагінів

Давайте запровадимо керування версіями на основі шляху в нашому API. Нам потрібно переписати URL-адресу, перш ніж пересилати її.

 routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] #1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] #1

1. Перед пересиланням видаліть префікс /v1

Як і у вищезазначеному upstream , розділ plugins дублюється. Ми також можемо внести конфігурацію плагіна в спеціальний об’єкт Plugin Config . Наступний фрагмент має той самий ефект, що й попередній:

 plugin_configs: - id: 1 #1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 #2 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 #2

1. Розташуйте конфігурацію плагіна у виділеному об’єкті
2. Посилання на це

Проникливі читачі могли помітити, що мені бракує частини конфігурації: auth-key таємничим чином зник! Дійсно, я видалив це для ясності.

На відміну від upstream і upstream_id , plugins та plugin_config_id не є взаємовиключними . Ми можемо вирішити проблему, просто додавши відсутній plugin :

 routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 plugins: key-auth: ~ #1

1. Виправте це!

Таким чином ви можете перемістити спільну конфігурацію до об’єкта plugin_config і зберегти певну конфігурацію в місці, до якого вона застосовується. Але що, якщо той самий плагін із різними конфігураціями використовується в plugin_config і безпосередньо в route ? Документація досить чітко про це:

Consumer > Consumer Group > Route > Plugin Config > Service

Коротше кажучи, конфігурація plugin в route скасовує конфігурацію в plugin_config_id . Це також дозволяє нам надати змінну apikey для плагіна key-auth в consumer та встановити її лише в маршруті. APISIX знайде та використає ключ для кожного consumer !

Висновок

DRY — це не лише код; мова йде про керування даними загалом. Конфігурація — це дані, тому вона підпадає під цю загальну парасольку.

APISIX пропонує два параметри DRY: один для upstream - upstream_id і один для plugin - plugin_config_id . Верхня течія є ексклюзивною; плагіни дозволяють скасовувати.

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

Щоб піти далі:

• Принцип «Не повторюйся».
• Пріоритет об’єднання конфігурації

Вперше опубліковано на сайті A Java Geek 1 вересня 2024 року