Istio સાથે માઇક્રોસર્વિસિસ પર પાછા જાઓ. ભાગ 3

નૉૅધ. અનુવાદ: પ્રથમ ભાગ આ શ્રેણી Istio ની ક્ષમતાઓ જાણવા અને તેમને ક્રિયામાં દર્શાવવા માટે સમર્પિત હતી, બીજું - બારીક ટ્યુન કરેલ રૂટીંગ અને નેટવર્ક ટ્રાફિક મેનેજમેન્ટ. હવે આપણે સુરક્ષા વિશે વાત કરીશું: તેનાથી સંબંધિત મૂળભૂત કાર્યોને દર્શાવવા માટે, લેખક Auth0 ઓળખ સેવાનો ઉપયોગ કરે છે, પરંતુ અન્ય પ્રદાતાઓ સમાન રીતે ગોઠવી શકાય છે.

અમે કુબરનેટ્સ ક્લસ્ટર સેટ કર્યું જેમાં અમે 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 પોર્ટલ > API > API બનાવો અને ફોર્મ ભરો:

અહીં મહત્વની માહિતી છે ઓળખકર્તા, જેનો આપણે પછીથી સ્ક્રિપ્ટમાં ઉપયોગ કરીશું. ચાલો તેને આ રીતે લખીએ:

• પ્રેક્ષક: {YOUR_AUDIENCE}

અમને જોઈતી બાકીની વિગતો વિભાગમાં Auth0 પોર્ટલ પર સ્થિત છે કાર્યક્રમો - પસંદ કરો ટેસ્ટ એપ્લિકેશન (API ની સાથે આપમેળે બનાવેલ).

અહીં આપણે લખીશું:

• ડોમેન: {YOUR_DOMAIN}
• ક્લાયન્ટ આઈડી: {YOUR_CLIENT_ID}

સુધી સ્ક્રોલ કરો ટેસ્ટ એપ્લિકેશન ટેક્સ્ટ ફીલ્ડમાં મંજૂર કૉલબેક URL (કૉલબેક માટે ઉકેલાયેલ URL), જેમાં અમે તે URL નો ઉલ્લેખ કરીએ છીએ જ્યાં પ્રમાણીકરણ પૂર્ણ થયા પછી કૉલ મોકલવો જોઈએ. અમારા કિસ્સામાં તે છે:

http://{EXTERNAL_IP}/callback

અને માટે મંજૂર લૉગઆઉટ URL (લોગ આઉટ કરવા માટે માન્ય 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}' // Используется для редиректа после аутентификации
}

એપ્લિકેશન તૈયાર છે. કરેલા ફેરફારોનું નિર્માણ અને ઉપયોગ કરતી વખતે નીચેના આદેશોમાં તમારું ડોકર ID સ્પષ્ટ કરો:

$ 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-ફ્રન્ટેન્ડ સેવાઓની ઍક્સેસ સાથે;
• મધ્યસ્થીઓ (મધ્યસ્થ) - ત્રણેય સેવાઓની ઍક્સેસ સાથે.

અધિકૃતતા ખ્યાલ

આ જૂથો બનાવવા માટે, અમે 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 માં અધિકૃતતા રૂપરેખાંકન

કામ કરવા માટે અધિકૃતતા માટે, તમારે 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.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 બધા પૃષ્ઠ મુલાકાતીઓને સર્વિસરોલ લાગુ કરો (રેગ્યુલર-યુઝર-સર્વિસ-રોલ-બાઈન્ડિંગ.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

દૂતોમાં કેશિંગને કારણે, અધિકૃતતાના નિયમો અમલમાં આવવામાં થોડી મિનિટો લાગી શકે છે. પછી તમે ખાતરી કરી શકો છો કે વપરાશકર્તાઓ અને મધ્યસ્થીઓ પાસે વિવિધ સ્તરોની ઍક્સેસ છે.

આ ભાગ પર નિષ્કર્ષ

ગંભીરતાપૂર્વક, શું તમે ક્યારેય પ્રમાણીકરણ અને અધિકૃતતા માટે સરળ, સરળ, માપી શકાય તેવું અને સુરક્ષિત અભિગમ જોયો છે?

માત્ર ત્રણ Istio સંસાધનો (RbacConfig, ServiceRole, અને ServiceRoleBinding)ની સેવાઓ માટે અંતિમ વપરાશકર્તાની ઍક્સેસની સત્તાધિકરણ અને અધિકૃતતા પર સુઘડ નિયંત્રણ હાંસલ કરવા માટે જરૂરી હતા.

વધુમાં, અમે અમારી દૂત સેવાઓમાંથી આ મુદ્દાઓનું ધ્યાન રાખ્યું છે, જે હાંસલ કર્યું છે:

• જેનરિક કોડની માત્રામાં ઘટાડો કે જેમાં સુરક્ષા સમસ્યાઓ અને ભૂલો હોઈ શકે છે;
• મૂર્ખ પરિસ્થિતિઓની સંખ્યા ઘટાડવી જેમાં એક અંતિમ બિંદુ બહારથી સુલભ હોવાનું બહાર આવ્યું અને તેની જાણ કરવાનું ભૂલી ગયા;
• દર વખતે નવી ભૂમિકા અથવા અધિકાર ઉમેરવામાં આવે ત્યારે બધી સેવાઓને અપડેટ કરવાની જરૂરિયાતને દૂર કરવી;
• કે નવી સેવાઓ સરળ, સુરક્ષિત અને ઝડપી રહે.

નિષ્કર્ષ

Istio ટીમોને તેમના સંસાધનોને સેવાઓમાં ઓવરહેડ ઉમેર્યા વિના, તેમને માઇક્રો સ્ટેટસ પર પાછા ફર્યા વિના વ્યવસાય-નિર્ણાયક કાર્યો પર ધ્યાન કેન્દ્રિત કરવાની મંજૂરી આપે છે.

લેખ (ત્રણ ભાગોમાં) વાસ્તવિક પ્રોજેક્ટ્સમાં Istio સાથે પ્રારંભ કરવા માટે મૂળભૂત જ્ઞાન અને તૈયાર વ્યવહારુ સૂચનાઓ પ્રદાન કરે છે.

અનુવાદક તરફથી પીએસ

અમારા બ્લોગ પર પણ વાંચો:

• "ઇસ્ટિઓ સાથે માઇક્રોસર્વિસિસ પર પાછા": ભાગ 1 (મુખ્ય લક્ષણોનો પરિચય), ભાગ 2 (રાઉટીંગ, ટ્રાફિક કંટ્રોલ);
• «નળી - કુબરનેટ્સ માટે હલકો સેવા મેશ»;
• «સર્વિસ મેશ શું છે અને મને તેની [માઈક્રોસર્વિસ સાથે ક્લાઉડ એપ્લિકેશન માટે] શા માટે જરૂર છે?».

સોર્સ: www.habr.com