Istio এর সাথে মাইক্রোসার্ভিসে ফিরে যান। অংশ 3

বিঃদ্রঃ. অনুবাদ: প্রথম অংশ এই সিরিজটি Istio-এর ক্ষমতা সম্পর্কে জানার জন্য এবং তাদের কর্মে প্রদর্শনের জন্য নিবেদিত ছিল, দ্বিতীয় - সূক্ষ্মভাবে সুর করা রাউটিং এবং নেটওয়ার্ক ট্রাফিক ব্যবস্থাপনা। এখন আমরা নিরাপত্তা সম্পর্কে কথা বলব: এটির সাথে সম্পর্কিত মৌলিক ফাংশনগুলি প্রদর্শন করতে, লেখক Auth0 পরিচয় পরিষেবা ব্যবহার করেন, তবে অন্যান্য প্রদানকারী একইভাবে কনফিগার করা যেতে পারে।

আমরা একটি Kubernetes ক্লাস্টার সেট আপ করেছি যেখানে আমরা Istio স্থাপন করেছি এবং একটি উদাহরণ মাইক্রোসার্ভিস অ্যাপ্লিকেশন, সেন্টিমেন্ট অ্যানালাইসিস, Istio এর ক্ষমতা প্রদর্শনের জন্য।

Istio এর সাথে, আমরা আমাদের পরিষেবাগুলিকে ছোট রাখতে সক্ষম হয়েছি কারণ তাদের পুনরায় চেষ্টা, টাইমআউট, সার্কিট ব্রেকার, ট্রেসিং, মনিটরিং এর মতো স্তরগুলি প্রয়োগ করার প্রয়োজন নেই৷ উপরন্তু, আমরা উন্নত পরীক্ষা এবং স্থাপনার কৌশল ব্যবহার করেছি: A/B টেস্টিং, মিররিং এবং ক্যানারি রোলআউট।

নতুন উপাদানে, আমরা ব্যবসায়িক মূল্যের পথে চূড়ান্ত স্তরগুলির সাথে মোকাবিলা করব: প্রমাণীকরণ এবং অনুমোদন - এবং ইস্টিওতে এটি একটি সত্যিকারের আনন্দ!

Istio মধ্যে প্রমাণীকরণ এবং অনুমোদন

আমি কখনই বিশ্বাস করতাম না যে আমি প্রমাণীকরণ এবং অনুমোদন দ্বারা অনুপ্রাণিত হব। এই বিষয়গুলিকে মজাদার করতে এবং আরও বেশি করে, আপনার জন্য অনুপ্রেরণামূলক করতে প্রযুক্তির দৃষ্টিকোণ থেকে Istio কী অফার করতে পারে?

উত্তরটি সহজ: Istio এই ক্ষমতাগুলির জন্য আপনার পরিষেবাগুলি থেকে দূত প্রক্সির কাছে দায়িত্ব স্থানান্তর করে৷ অনুরোধগুলি পরিষেবাগুলিতে পৌঁছানোর সময়, সেগুলি ইতিমধ্যেই প্রমাণীকৃত এবং অনুমোদিত হয়েছে, তাই আপনাকে যা করতে হবে তা হল ব্যবসা-উপযোগী কোড লিখতে৷

ভাল শোনাচ্ছে? এর ভিতরে একবার দেখে নেওয়া যাক!

Auth0 এর সাথে প্রমাণীকরণ

পরিচয় এবং অ্যাক্সেস পরিচালনার জন্য একটি সার্ভার হিসাবে, আমরা Auth0 ব্যবহার করব, যার একটি ট্রায়াল সংস্করণ রয়েছে, এটি ব্যবহার করার জন্য স্বজ্ঞাত এবং আমি এটি পছন্দ করি। যাইহোক, একই নীতিগুলি অন্য যে কোনও ক্ষেত্রে প্রয়োগ করা যেতে পারে OpenID কানেক্ট বাস্তবায়ন: কীক্লোক, আইডেন্টিটি সার্ভার এবং আরও অনেক কিছু।

প্রথম, যান Auth0 পোর্টাল আপনার অ্যাকাউন্ট দিয়ে, একটি ভাড়াটে তৈরি করুন (ভাড়াটিয়া - "ভাড়াটে", বিচ্ছিন্নতার যৌক্তিক ইউনিট, আরও বিশদ বিবরণের জন্য দেখুন ডকুমেন্টেশন - প্রায়. অনুবাদ।) এবং যান অ্যাপ্লিকেশন > ডিফল্ট অ্যাপপছন্দ ডোমেইন, নীচের স্ক্রিনশটে দেখানো হয়েছে:

ফাইলটিতে এই ডোমেনটি উল্লেখ করুন resource-manifests/istio/security/auth-policy.yaml (সূত্র):

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: auth-policy
spec:
  targets:
  - name: sa-web-app
  - name: sa-feedback
  origins:
  - jwt:
      issuer: "https://{YOUR_DOMAIN}/"
      jwksUri: "https://{YOUR_DOMAIN}/.well-known/jwks.json"
  principalBinding: USE_ORIGIN

যেমন একটি সম্পদ সঙ্গে, পাইলট (Istio-এর তিনটি মৌলিক কন্ট্রোল প্লেন উপাদানগুলির মধ্যে একটি - প্রায় অনুবাদ।) অনুরোধগুলিকে পরিষেবাগুলিতে ফরোয়ার্ড করার আগে প্রমাণীকরণের জন্য দূতকে কনফিগার করে: sa-web-app и sa-feedback. একই সময়ে, কনফিগারেশন পরিষেবা দূতদের ক্ষেত্রে প্রয়োগ করা হয় না sa-frontend, আমাদের অপ্রমাণিত ফ্রন্টএন্ড ছেড়ে যেতে অনুমতি দেয়. নীতি প্রয়োগ করতে, কমান্ডটি চালান:

$ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml
policy.authentication.istio.io “auth-policy” created

পৃষ্ঠায় ফিরে যান এবং একটি অনুরোধ করুন - আপনি দেখতে পাবেন যে এটি স্ট্যাটাসের সাথে শেষ হয়েছে 401 অননুমোদিত. এখন Auth0 এর সাথে প্রমাণীকরণের জন্য ফ্রন্টএন্ড ব্যবহারকারীদের পুনর্নির্দেশ করা যাক।

Auth0 এর সাথে অনুরোধ প্রমাণীকরণ করা হচ্ছে

শেষ ব্যবহারকারীর অনুরোধগুলিকে প্রমাণীকরণ করতে, আপনাকে Auth0-এ একটি API তৈরি করতে হবে যা প্রমাণীকৃত পরিষেবাগুলি (রিভিউ, বিশদ বিবরণ এবং রেটিং) প্রতিনিধিত্ব করবে৷ একটি API তৈরি করতে, যান Auth0 পোর্টাল > APIs > API তৈরি করুন এবং ফর্মটি পূরণ করুন:

এখানে গুরুত্বপূর্ণ তথ্য সনাক্ত করা, যা আমরা পরে স্ক্রিপ্টে ব্যবহার করব। আসুন এটি এভাবে লিখি:

• পাঠকবর্গ: {Your_AUDIENCE}

আমাদের প্রয়োজনীয় অবশিষ্ট বিবরণ বিভাগটির Auth0 পোর্টালে অবস্থিত অ্যাপ্লিকেশন - নির্বাচন করুন পরীক্ষার আবেদন (এপিআই সহ স্বয়ংক্রিয়ভাবে তৈরি)।

এখানে আমরা লিখব:

• ডোমেইন: {YOUR_DOMAIN}
• ক্লায়েন্ট আইডি: {YOUR_CLIENT_ID}

স্ক্রোল করুন পরীক্ষার আবেদন টেক্সট ফিল্ডে অনুমোদিত কলব্যাক ইউআরএল (কলব্যাকের জন্য সমাধান করা ইউআরএল), যেখানে আমরা ইউআরএল নির্দিষ্ট করি যেখানে প্রমাণীকরণ সম্পূর্ণ হওয়ার পরে কল পাঠানো হবে। আমাদের ক্ষেত্রে এটি হল:

http://{EXTERNAL_IP}/callback

এবং জন্য অনুমোদিত লগআউট URLs (লগ আউট করার জন্য অনুমোদিত URL) যোগ করুন:

http://{EXTERNAL_IP}/logout

এর ফ্রন্টএন্ড এগিয়ে চলুন.

ফ্রন্টএন্ড আপডেট

শাখায় স্যুইচ করুন auth0 ভান্ডার [istio-mastery]. এই শাখায়, প্রমাণীকরণের জন্য ব্যবহারকারীদের Auth0 এ পুনঃনির্দেশিত করতে এবং অন্যান্য পরিষেবার অনুরোধে JWT টোকেন ব্যবহার করতে ফ্রন্টএন্ড কোড পরিবর্তন করা হয়। পরবর্তীটি নিম্নরূপ প্রয়োগ করা হয় (App.js):

analyzeSentence() {
    fetch('/sentiment', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Authorization': `Bearer ${auth.getAccessToken()}` // Access Token
        },
        body: JSON.stringify({ sentence: this.textField.getValue() })
    })
        .then(response => response.json())
        .then(data => this.setState(data));
}

Auth0 এ টেন্যান্ট ডেটা ব্যবহার করতে ফ্রন্টএন্ড পরিবর্তন করতে, খুলুন sa-frontend/src/services/Auth.js এবং এটিতে আমরা উপরে যে মানগুলি লিখেছি তা প্রতিস্থাপন করুন (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Используется для редиректа после аутентификации
}

আবেদন প্রস্তুত. পরিবর্তনগুলি তৈরি এবং স্থাপন করার সময় নীচের কমান্ডগুলিতে আপনার ডকার আইডি নির্দিষ্ট করুন:

$ docker build -f sa-frontend/Dockerfile 
 -t $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 
 sa-frontend

$ docker push $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

$ kubectl set image deployment/sa-frontend 
 sa-frontend=$DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

অ্যাপটি ব্যবহার করে দেখুন! আপনাকে Auth0 এ পুনঃনির্দেশিত করা হবে, যেখানে আপনাকে লগ ইন করতে হবে (বা নিবন্ধন করতে হবে), এর পরে আপনাকে সেই পৃষ্ঠায় ফেরত পাঠানো হবে যেখান থেকে ইতিমধ্যেই প্রমাণীকৃত অনুরোধ করা হবে। আপনি যদি কার্ল দিয়ে নিবন্ধের প্রথম অংশে উল্লিখিত কমান্ডগুলি চেষ্টা করেন তবে আপনি কোডটি পাবেন 401 স্ট্যাটাস কোড, সংকেত যে অনুরোধ অনুমোদিত নয়.

এর পরবর্তী পদক্ষেপ নেওয়া যাক - অনুরোধগুলি অনুমোদন করুন৷

Auth0 এর সাথে অনুমোদন

প্রমাণীকরণ আমাদের বুঝতে দেয় যে একজন ব্যবহারকারী কে, কিন্তু তাদের কী অ্যাক্সেস আছে তা জানার জন্য অনুমোদনের প্রয়োজন। Istio এর জন্যও টুল অফার করে।

একটি উদাহরণ হিসাবে, আসুন দুটি ব্যবহারকারী গ্রুপ তৈরি করি (নীচের চিত্রটি দেখুন):

• ব্যবহারকারীদের (ব্যবহারকারী) — শুধুমাত্র SA-WebApp এবং SA-Frontend পরিষেবাগুলিতে অ্যাক্সেস সহ;
• মডারেটর (মডারেটর) - তিনটি পরিষেবার অ্যাক্সেস সহ।

অনুমোদনের ধারণা

এই গোষ্ঠীগুলি তৈরি করতে, আমরা Auth0 অনুমোদন এক্সটেনশন ব্যবহার করব এবং তাদের বিভিন্ন স্তরের অ্যাক্সেস প্রদান করতে Istio ব্যবহার করব।

Auth0 অনুমোদনের ইনস্টলেশন এবং কনফিগারেশন

Auth0 পোর্টালে, এক্সটেনশনে যান (এক্সটেনশানগুলি) এবং ইনস্টল করুন Auth0 অনুমোদন. ইনস্টলেশনের পরে, যান অনুমোদন এক্সটেনশন, এবং সেখানে - উপরের ডানদিকে ক্লিক করে এবং উপযুক্ত মেনু বিকল্পটি নির্বাচন করে ভাড়াটেদের কনফিগারেশনে (কনফিগারেশন). গ্রুপ সক্রিয় করুন (গোষ্ঠী) এবং প্রকাশ নিয়ম বোতামে ক্লিক করুন (নিয়ম প্রকাশ করুন).

গ্রুপ তৈরি করা

অনুমোদন এক্সটেনশনে যান গ্রুপ এবং একটি গ্রুপ তৈরি করুন মডারেটর. যেহেতু আমরা সমস্ত প্রমাণীকৃত ব্যবহারকারীকে নিয়মিত ব্যবহারকারী হিসাবে বিবেচনা করব, তাদের জন্য একটি অতিরিক্ত গ্রুপ তৈরি করার প্রয়োজন নেই।

একটি গ্রুপ চয়ন করুন মডারেটর, প্রেস সদস্যদের যোগ করুন, আপনার প্রধান অ্যাকাউন্ট যোগ করুন। কিছু ব্যবহারকারীদের অ্যাক্সেস অস্বীকার করা হয়েছে তা নিশ্চিত করতে কোনো গোষ্ঠী ছাড়াই ছেড়ে দিন। (এর মাধ্যমে ম্যানুয়ালি নতুন ব্যবহারকারী তৈরি করা যেতে পারে Auth0 পোর্টাল > ব্যবহারকারী > ব্যবহারকারী তৈরি করুন.)

অ্যাক্সেস টোকেনে গ্রুপ দাবি যোগ করুন

ব্যবহারকারীদের গ্রুপে যোগ করা হয়েছে, তবে এই তথ্যটি অবশ্যই অ্যাক্সেস টোকেনগুলিতে প্রতিফলিত হতে হবে। OpenID কানেক্ট মেনে চলার জন্য এবং একই সাথে আমাদের প্রয়োজনীয় গোষ্ঠীগুলিকে ফেরত দিতে, টোকেনটিকে তার নিজস্ব যোগ করতে হবে কাস্টম দাবি. Auth0 নিয়মের মাধ্যমে প্রয়োগ করা হয়েছে।

একটি নিয়ম তৈরি করতে, Auth0 পোর্টালে যান বিধি, প্রেস নিয়ম তৈরি করুন এবং টেমপ্লেট থেকে একটি খালি নিয়ম নির্বাচন করুন।

নীচের কোডটি অনুলিপি করুন এবং এটি একটি নতুন নিয়ম হিসাবে সংরক্ষণ করুন গ্রুপ দাবি যোগ করুন (namespacedGroup.js):

function (user, context, callback) {
    context.accessToken['https://sa.io/group'] = user.groups[0];
    return callback(null, user, context);
}

মন্তব্য: এই কোডটি অনুমোদন এক্সটেনশনে সংজ্ঞায়িত প্রথম ব্যবহারকারী গোষ্ঠীটি নেয় এবং এটিকে একটি কাস্টম দাবি হিসাবে অ্যাক্সেস টোকেনে যুক্ত করে (এর নামস্থানের অধীনে, Auth0 দ্বারা প্রয়োজনীয়)।

পৃষ্ঠায় ফিরে যান বিধি এবং নিম্নলিখিত ক্রমে আপনার দুটি নিয়ম লেখা আছে কিনা তা পরীক্ষা করুন:

• auth0-অথোরাইজেশন-এক্সটেনশন
• গ্রুপ দাবি যোগ করুন

অর্ডারটি গুরুত্বপূর্ণ কারণ গ্রুপ ফিল্ড অ্যাসিঙ্ক্রোনাসভাবে নিয়মটি গ্রহণ করে auth0-অথোরাইজেশন-এক্সটেনশন এবং তার পরে এটি দ্বিতীয় নিয়ম দ্বারা একটি দাবি হিসাবে যোগ করা হয়। ফলাফল এই মত একটি অ্যাক্সেস টোকেন:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [сокращено для наглядности]
}

এখন আপনাকে ব্যবহারকারীর অ্যাক্সেস চেক করতে এনভয় প্রক্সি কনফিগার করতে হবে, যার জন্য গ্রুপটি দাবি থেকে টেনে নেওয়া হবে (https://sa.io/group) ফিরে আসা অ্যাক্সেস টোকেনে। এই নিবন্ধের পরবর্তী অধ্যায় জন্য বিষয়.

ইস্টিওতে অনুমোদন কনফিগারেশন

কাজ করার অনুমোদনের জন্য, আপনাকে অবশ্যই Istio-এর জন্য RBAC সক্ষম করতে হবে। এটি করার জন্য, আমরা নিম্নলিখিত কনফিগারেশন ব্যবহার করব:

apiVersion: "rbac.istio.io/v1alpha1"
kind: RbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'                     # 1
  inclusion:
    services:                                   # 2
    - "sa-frontend.default.svc.cluster.local"
    - "sa-web-app.default.svc.cluster.local"
    - "sa-feedback.default.svc.cluster.local" 

ব্যাখ্যা:

• 1 — ক্ষেত্রে তালিকাভুক্ত পরিষেবা এবং নামস্থানগুলির জন্য শুধুমাত্র RBAC সক্ষম করুন৷ Inclusion;
• 2 — আমরা আমাদের পরিষেবাগুলির একটি তালিকা তালিকাভুক্ত করি।

আসুন নিম্নলিখিত কমান্ডের সাথে কনফিগারেশন প্রয়োগ করি:

$ kubectl apply -f resource-manifests/istio/security/enable-rbac.yaml
rbacconfig.rbac.istio.io/default created

সমস্ত পরিষেবার জন্য এখন ভূমিকা-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ প্রয়োজন৷ অন্য কথায়, সমস্ত পরিষেবাগুলিতে অ্যাক্সেস নিষিদ্ধ এবং এর ফলে প্রতিক্রিয়া হবে৷ RBAC: access denied. এখন আসুন অনুমোদিত ব্যবহারকারীদের অ্যাক্সেসের অনুমতি দিন।

নিয়মিত ব্যবহারকারীদের জন্য অ্যাক্সেস কনফিগারেশন

সমস্ত ব্যবহারকারীদের অবশ্যই SA-Frontend এবং SA-WebApp পরিষেবাগুলিতে অ্যাক্সেস থাকতে হবে৷ নিম্নলিখিত Istio সম্পদ ব্যবহার করে বাস্তবায়িত:

• সার্ভিস রোল - ব্যবহারকারীর অধিকার নির্ধারণ করে;
• ServiceRoleBinding — এই ServiceRole কার অন্তর্গত তা নির্ধারণ করে৷

সাধারণ ব্যবহারকারীদের জন্য আমরা নির্দিষ্ট পরিষেবাগুলিতে অ্যাক্সেসের অনুমতি দেব (servicerole.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: regular-user
  namespace: default
spec:
  rules:
  - services: 
    - "sa-frontend.default.svc.cluster.local" 
    - "sa-web-app.default.svc.cluster.local"
    paths: ["*"]
    methods: ["*"]

এবং মাধ্যমে regular-user-binding সমস্ত পৃষ্ঠা দর্শকদের জন্য ServiceRole প্রয়োগ করুন (নিয়মিত-ব্যবহারকারী-সার্ভিস-রোল-বাইন্ডিং.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: regular-user-binding
  namespace: default
spec:
  subjects:
  - user: "*"
  roleRef:
    kind: ServiceRole
    name: "regular-user"

"সমস্ত ব্যবহারকারী" মানে কি অননুমোদিত ব্যবহারকারীদেরও SA WebApp-এ অ্যাক্সেস থাকবে? না, নীতি JWT টোকেনের বৈধতা পরীক্ষা করবে।

কনফিগারেশন প্রয়োগ করা যাক:

$ kubectl apply -f resource-manifests/istio/security/user-role.yaml
servicerole.rbac.istio.io/regular-user created
servicerolebinding.rbac.istio.io/regular-user-binding created

মডারেটরদের জন্য অ্যাক্সেস কনফিগারেশন

মডারেটরদের জন্য, আমরা সমস্ত পরিষেবাগুলিতে অ্যাক্সেস সক্ষম করতে চাই (mod-service-role.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: mod-user
  namespace: default
spec:
  rules:
  - services: ["*"]
    paths: ["*"]
    methods: ["*"]

কিন্তু আমরা এই ধরনের অধিকার চাই শুধুমাত্র সেই ব্যবহারকারীদের জন্য যাদের অ্যাক্সেস টোকেনে দাবি রয়েছে https://sa.io/group অর্থ সহ Moderators (mod-service-role-binding.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: mod-user-binding
  namespace: default
spec:
  subjects:
  - properties:
      request.auth.claims[https://sa.io/group]: "Moderators"
  roleRef:
    kind: ServiceRole
name: "mod-user" 

কনফিগারেশন প্রয়োগ করা যাক:

$ kubectl apply -f resource-manifests/istio/security/mod-role.yaml
servicerole.rbac.istio.io/mod-user created
servicerolebinding.rbac.istio.io/mod-user-binding created

দূতদের ক্যাশে করার কারণে, অনুমোদনের নিয়ম কার্যকর হতে কয়েক মিনিট সময় লাগতে পারে। তারপর আপনি নিশ্চিত করতে পারেন যে ব্যবহারকারী এবং মডারেটরদের অ্যাক্সেসের বিভিন্ন স্তর রয়েছে৷

এই অংশে উপসংহার

সিরিয়াসলি যদিও, আপনি কি কখনও প্রমাণীকরণ এবং অনুমোদনের জন্য একটি সহজ, অনায়াস, মাপযোগ্য এবং নিরাপদ পদ্ধতি দেখেছেন?

শুধুমাত্র তিনটি ইস্টিও রিসোর্স (RbacConfig, ServiceRole, এবং ServiceRoleBinding) পরিষেবাগুলিতে শেষ ব্যবহারকারীর অ্যাক্সেসের প্রমাণীকরণ এবং অনুমোদনের উপর সূক্ষ্ম নিয়ন্ত্রণ অর্জনের জন্য প্রয়োজন ছিল।

উপরন্তু, আমরা আমাদের দূত পরিষেবাগুলির মধ্যে এই বিষয়গুলির যত্ন নিয়েছি, অর্জন করেছি:

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

উপসংহার

Istio টিমগুলিকে পরিষেবাগুলিতে ওভারহেড যোগ না করে, তাদের মাইক্রো স্ট্যাটাসে ফিরিয়ে না দিয়ে ব্যবসায়িক-গুরুত্বপূর্ণ কাজগুলিতে তাদের সংস্থানগুলিকে ফোকাস করার অনুমতি দেয়।

নিবন্ধটি (তিনটি অংশে) বাস্তব প্রকল্পগুলিতে ইস্টিওর সাথে শুরু করার জন্য প্রাথমিক জ্ঞান এবং প্রস্তুত ব্যবহারিক নির্দেশাবলী প্রদান করেছে।

অনুবাদক থেকে PS

আমাদের ব্লগেও পড়ুন:

• "ইসটিও সহ মাইক্রোসার্ভিসে ফিরে যান": অংশ 1 (প্রধান বৈশিষ্ট্যের ভূমিকা), পার্ট 2 (রাউটিং, ট্রাফিক নিয়ন্ত্রণ);
• «নালী - Kubernetes জন্য হালকা পরিষেবা জাল";
• «একটি পরিষেবা জাল কি এবং কেন আমার এটি প্রয়োজন [মাইক্রোসার্ভিস সহ একটি ক্লাউড অ্যাপ্লিকেশনের জন্য]?».

উত্স: www.habr.com