কিভাবে আপনার Apache APISIX কনফিগারেশান ড্রাই করবেন

নিজেকে পুনরাবৃত্তি করবেন না বা DRY সফ্টওয়্যার বিকাশের একটি গুরুত্বপূর্ণ নীতি। এই পোস্টটি আপনাকে দেখাবে কিভাবে এটি Apache APISIX কনফিগারেশনে প্রয়োগ করতে হয়।

DRY নীতি

"নিজেকে পুনরাবৃত্তি করবেন না" (DRY) হল সফ্টওয়্যার বিকাশের একটি নীতি যার লক্ষ্য পরিবর্তনের সম্ভাবনা রয়েছে এমন তথ্যের পুনরাবৃত্তি হ্রাস করা, এটিকে পরিবর্তনের সম্ভাবনা কম এমন বিমূর্ততা দিয়ে প্রতিস্থাপন করা, বা ডেটা স্বাভাবিককরণ ব্যবহার করা যা প্রথম স্থানে অপ্রয়োজনীয়তা এড়ায়। .

-- উইকিপিডিয়া - নিজেকে পুনরাবৃত্তি করবেন না

ড্রাইয়ের পিছনে মূল ধারণাটি হল যে আপনি যদি নিজেকে পুনরাবৃত্তি করেন এবং তথ্য পরিবর্তন করেন, তবে আপনাকে একাধিক জায়গায় পরিবর্তিত তথ্য আপডেট করতে হবে। এটা শুধু অতিরিক্ত প্রচেষ্টা নয়; একটি সুযোগ আছে যে আপনি এটি সম্পর্কে ভুলে যাবেন এবং বিভিন্ন জায়গায় বিভিন্ন তথ্য পাবেন৷ DRY বাগ ফিক্সিং-এ জ্বলজ্বল করে।

একটি বাগ ধারণকারী একটি কোড স্নিপেট কল্পনা করুন. এখন কল্পনা করুন যে আপনি দুটি ভিন্ন জায়গায় স্নিপেটটি নকল করেছেন। এখন, আপনাকে অবশ্যই এই দুটি জায়গায় বাগটি ঠিক করতে হবে, এবং এটিই সহজ অংশ; প্রথম স্থানে নকল সম্পর্কে জানা কঠিন।

নকল করা ব্যক্তি এবং ঠিক করা ব্যক্তি আলাদা হওয়ার একটি উচ্চ সম্ভাবনা রয়েছে। যদি স্নিপেটটি ভাগ করার জন্য রিফ্যাক্টর করা হয় এবং পরিবর্তে দুটি জায়গা থেকে কল করা হয় তবে আপনাকে শুধুমাত্র এই একটি জায়গায় বাগটি ঠিক করতে হবে।

বেশিরভাগ মানুষ কোডের সাথে DRY যুক্ত করে। যাইহোক, এটি আরও সীমাবদ্ধ এবং মূল ধারণার বিপরীত হতে পারে।

নীতিটি তৈরি করেছেন অ্যান্ডি হান্ট এবং ডেভ থমাস তাদের বই The Pragmatic Programmer-এ। তারা ডাটাবেস স্কিমা, পরীক্ষা পরিকল্পনা, বিল্ড সিস্টেম, এমনকি ডকুমেন্টেশন অন্তর্ভুক্ত করার জন্য এটি বেশ বিস্তৃতভাবে প্রয়োগ করে।

-- উইকিপিডিয়া - নিজেকে পুনরাবৃত্তি করবেন না

সাউন্ড কনফিগারেশন সিস্টেমগুলি ড্রাইকে অনুমতি দেয় বা এমনকি এটিকে উত্সাহিত করে।

Apache APISIX-এ DRY

Apache APISIX দুটি জায়গায় DRY কনফিগারেশন অফার করে।

ড্রাই আপস্ট্রিম

একটি ই-কমার্স প্রসঙ্গে, Apache APISIX-এ একটি রুট সংজ্ঞায়িত করার জন্য আপনার শিক্ষানবিস যাত্রা সম্ভবত নিম্নলিখিতগুলির মতো শুরু হয়:

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

আপনি যদি APISIX-এর সাথে পরিচিত হন, আমরা /products URI-এর অধীনে ক্যাটালগের একটি রুট সংজ্ঞায়িত করেছি। যাইহোক, একটি সমস্যা আছে: আপনি সম্ভবত চান যে গ্রাহকরা ক্যাটালগটি ব্রাউজ করুক কিন্তু লোকেদের পণ্য তৈরি, মুছে বা আপডেট করা থেকে আটকাতে চান। তবুও, রুটটি ডিফল্টরূপে প্রতিটি 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 নীতিকে পরাজিত করে।

বাস্তব-বিশ্বের পরিস্থিতিতে, বিশেষ করে যখন তারা কন্টেইনারগুলিকে জড়িত করে, আপনি nodes তালিকাভুক্ত করে upstream বাস্তবায়ন করবেন না। আপনার পরিবর্তে টপোলজি পরিবর্তনগুলি মিটমাট করার জন্য একটি গতিশীল পরিষেবা আবিষ্কার বাস্তবায়ন করা উচিত। যাইহোক, যখন আপনাকে পরিষেবা আবিষ্কারের কনফিগারেশন বা বাস্তবায়ন পরিবর্তন করতে হবে তখনও পয়েন্টটি দাঁড়িয়েছে। অতএব, আমার পয়েন্ট নোড এবং পরিষেবা আবিষ্কারের ক্ষেত্রে সমানভাবে প্রযোজ্য।

রুট বিমূর্তকরণের পাশাপাশি, APISIX 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. ID 1 দিয়ে একটি আপস্ট্রিম সংজ্ঞায়িত করুন
2. রুট এটি রেফারেন্স

টপোলজিতে কিছু ঘটলে, আমাদের শুধুমাত্র একক আপস্ট্রিমে পরিবর্তন আপডেট করতে হবে।

মনে রাখবেন যে 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_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

সংক্ষেপে, একটি route plugin কনফিগারেশন plugin_config_id এর কনফিগারেশনকে অগ্রাহ্য করে। এটি আমাদেরকে একটি consumer key-auth প্লাগইনের জন্য apikey ভেরিয়েবল প্রদান করতে এবং এটি শুধুমাত্র একটি রুটে সেট করার অনুমতি দেয়। APISIX প্রতিটি consumer জন্য কী খুঁজে পাবে এবং ব্যবহার করবে!

উপসংহার

DRY শুধুমাত্র কোড সম্পর্কে নয়; এটি সাধারণভাবে ডেটা ম্যানেজমেন্ট সম্পর্কে। কনফিগারেশন হল ডেটা এবং এইভাবে এই সাধারণ ছাতার অধীনে পড়ে।

APISIX দুটি DRY বিকল্প অফার করে: একটি upstream - upstream_id এর জন্য এবং একটি plugin - plugin_config_id এর জন্য। আপস্ট্রিমগুলি একচেটিয়া; প্লাগইনগুলি ওভাররুলিংয়ের অনুমতি দেয়।

উভয় প্রক্রিয়াই আপনাকে আপনার কনফিগারেশন শুকানোর দিকে সাহায্য করবে এবং দীর্ঘমেয়াদে এটিকে আরও রক্ষণাবেক্ষণযোগ্য করে তুলবে।

আরও যেতে:

• নিজেকে পুনরাবৃত্তি করবেন না নীতি
• কনফিগারেশন মার্জ অগ্রাধিকার

মূলত 1লা সেপ্টেম্বর, 2024-এ A Java Geek এ প্রকাশিত