GAలోని Amazon EKS విండోస్‌లో బగ్‌లు ఉన్నాయి, కానీ వేగవంతమైనది

శుభ మధ్యాహ్నం, విండోస్ కంటైనర్‌ల కోసం AWS EKS (ఎలాస్టిక్ కుబెర్నెట్స్ సర్వీస్) సర్వీస్‌ని సెటప్ చేయడంలో మరియు ఉపయోగించడంలో నా అనుభవాన్ని లేదా దాన్ని ఉపయోగించడం అసంభవం గురించి మరియు AWS సిస్టమ్ కంటైనర్‌లో ఉన్న బగ్ గురించి మీతో పంచుకోవాలనుకుంటున్నాను. Windows కంటైనర్‌ల కోసం ఈ సేవపై ఆసక్తి ఉన్నవారు, దయచేసి పిల్లి కింద.

విండోస్ కంటైనర్‌లు జనాదరణ పొందిన అంశం కాదని నాకు తెలుసు, మరియు కొంతమంది వాటిని ఉపయోగిస్తున్నారు, అయితే నేను ఇప్పటికీ ఈ కథనాన్ని వ్రాయాలని నిర్ణయించుకున్నాను, ఎందుకంటే కుబెర్నెట్స్ మరియు విండోస్‌లో హబ్రేపై రెండు కథనాలు ఉన్నాయి మరియు అలాంటి వ్యక్తులు ఇంకా ఉన్నారు.

Начало

మా కంపెనీలోని సేవలను 70% Windows మరియు 30% Linux ఉన్న kubernetesకి తరలించాలని నిర్ణయించినప్పుడు ఇదంతా ప్రారంభమైంది. ఈ ప్రయోజనం కోసం, AWS EKS క్లౌడ్ సేవ సాధ్యమయ్యే ఎంపికలలో ఒకటిగా పరిగణించబడింది. అక్టోబర్ 8, 2019 వరకు, AWS EKS విండోస్ పబ్లిక్ ప్రివ్యూలో ఉంది, నేను దానితో ప్రారంభించాను, పాత 1.11 kubernetes వెర్షన్ ఉపయోగించబడింది, అయితే దాన్ని ఎలాగైనా తనిఖీ చేసి, ఈ క్లౌడ్ సేవ ఏ దశలో పని చేస్తుందో చూడాలని నిర్ణయించుకున్నాను. అస్సలు, అది ముగిసినట్లుగా, కాదు, పాడ్‌లను తీసివేయడంతో పాటు ఒక బగ్ ఉంది, అయితే పాతవి విండోస్ వర్కర్ నోడ్ వలె అదే సబ్‌నెట్ నుండి అంతర్గత ip ద్వారా ప్రతిస్పందించడం ఆపివేసాయి.

అందువల్ల, అదే EC2లోని కుబెర్నెట్‌లలో మా స్వంత క్లస్టర్‌కు అనుకూలంగా AWS EKS వినియోగాన్ని వదిలివేయాలని నిర్ణయించబడింది, మేము మాత్రమే క్లౌడ్‌ఫార్మేషన్ ద్వారా అన్ని బ్యాలెన్సింగ్ మరియు HA గురించి వివరించాలి.

Amazon EKS విండోస్ కంటైనర్ సపోర్ట్ ఇప్పుడు సాధారణంగా అందుబాటులో ఉంది

మార్టిన్ బీబీ ద్వారా | 08 OCT 2019న

నా స్వంత క్లస్టర్ కోసం క్లౌడ్‌ఫార్మేషన్‌కి టెంప్లేట్‌ని జోడించడానికి సమయం లభించకముందే, నేను ఈ వార్తను చూశాను Amazon EKS విండోస్ కంటైనర్ సపోర్ట్ ఇప్పుడు సాధారణంగా అందుబాటులో ఉంది

అయితే, నేను నా పనులన్నింటినీ పక్కన పెట్టాను మరియు వారు GA కోసం ఏమి చేశారో మరియు పబ్లిక్ ప్రివ్యూతో ప్రతిదీ ఎలా మారిపోయింది అని అధ్యయనం చేయడం ప్రారంభించాను. అవును, AWS, బాగా చేసారు, విండోస్ వర్కర్ నోడ్ కోసం ఇమేజ్‌లను వెర్షన్ 1.14కి అప్‌డేట్ చేసింది, అలాగే క్లస్టర్ కూడా, EKSలో వెర్షన్ 1.14, ఇప్పుడు విండోస్ నోడ్‌లకు మద్దతు ఇస్తుంది. పబ్లిక్ ప్రివ్యూ ద్వారా ప్రాజెక్ట్ గితుబ్ వారు దానిని కప్పిపుచ్చారు మరియు ఇప్పుడు ఇక్కడ అధికారిక డాక్యుమెంటేషన్‌ను ఉపయోగించండి: EKS విండోస్ మద్దతు

ప్రస్తుత VPC మరియు సబ్‌నెట్‌లకు EKS క్లస్టర్‌ను అనుసంధానించడం

అన్ని మూలాధారాలలో, ప్రకటనపై మరియు డాక్యుమెంటేషన్‌లో పై లింక్‌లో, క్లస్టర్‌ను ప్రొప్రైటరీ eksctl యుటిలిటీ ద్వారా లేదా క్లౌడ్‌ఫార్మేషన్ + kubectl ద్వారా అమలు చేయాలని ప్రతిపాదించబడింది, అమెజాన్‌లో పబ్లిక్ సబ్‌నెట్‌లను మాత్రమే ఉపయోగించి, అలాగే ఒక కొత్త క్లస్టర్ కోసం ప్రత్యేక VPC.

ఈ ఎంపిక చాలా మందికి తగినది కాదు; ముందుగా, ప్రత్యేక VPC అంటే దాని ఖర్చు కోసం అదనపు ఖర్చులు + మీ ప్రస్తుత VPCకి పీరింగ్ ట్రాఫిక్. వారి స్వంత బహుళ AWS ఖాతాలు, VPC, సబ్‌నెట్‌లు, రూట్ టేబుల్‌లు, ట్రాన్సిట్ గేట్‌వే మొదలైనవాటితో ఇప్పటికే AWSలో రెడీమేడ్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ను కలిగి ఉన్నవారు ఏమి చేయాలి? వాస్తవానికి, మీరు వీటన్నింటినీ విచ్ఛిన్నం చేయడం లేదా మళ్లీ చేయడం ఇష్టం లేదు మరియు మీరు ఇప్పటికే ఉన్న VPCని ఉపయోగించి ప్రస్తుత నెట్‌వర్క్ ఇన్‌ఫ్రాస్ట్రక్చర్‌లో కొత్త EKS క్లస్టర్‌ను ఏకీకృతం చేయాలి మరియు వేరు చేయడానికి, క్లస్టర్ కోసం కొత్త సబ్‌నెట్‌లను సృష్టించాలి.

నా విషయంలో, ఈ మార్గం ఎంపిక చేయబడింది, నేను ఇప్పటికే ఉన్న VPCని ఉపయోగించాను, కొత్త క్లస్టర్ కోసం 2 పబ్లిక్ సబ్‌నెట్‌లు మరియు 2 ప్రైవేట్ సబ్‌నెట్‌లను మాత్రమే జోడించాను, వాస్తవానికి, డాక్యుమెంటేషన్ ప్రకారం అన్ని నియమాలు పరిగణనలోకి తీసుకోబడ్డాయి మీ Amazon EKS క్లస్టర్ VPCని సృష్టించండి.

ఒక షరతు కూడా ఉంది: EIPని ఉపయోగించే పబ్లిక్ సబ్‌నెట్‌లలో వర్కర్ నోడ్‌లు లేవు.

eksctl vs క్లౌడ్ ఫార్మేషన్

నేను క్లస్టర్‌ని అమలు చేయడానికి రెండు పద్ధతులను ప్రయత్నించానని వెంటనే రిజర్వేషన్ చేస్తాను, రెండు సందర్భాల్లోనూ చిత్రం ఒకేలా ఉంది.

ఇక్కడ కోడ్ తక్కువగా ఉంటుంది కాబట్టి నేను eksctlని ఉపయోగించి మాత్రమే ఉదాహరణ చూపిస్తాను. eksctl ఉపయోగించి, క్లస్టర్‌ను 3 దశల్లో అమలు చేయండి:

1. మేము క్లస్టర్ + Linux వర్కర్ నోడ్‌ను సృష్టిస్తాము, ఇది తరువాత సిస్టమ్ కంటైనర్‌లను మరియు అదే దురదృష్టకరమైన vpc-కంట్రోలర్‌ను హోస్ట్ చేస్తుంది.

eksctl create cluster 
--name yyy 
--region www 
--version 1.14 
--vpc-private-subnets=subnet-xxxxx,subnet-xxxxx 
--vpc-public-subnets=subnet-xxxxx,subnet-xxxxx 
--asg-access 
--nodegroup-name linux-workers 
--node-type t3.small 
--node-volume-size 20 
--ssh-public-key wwwwwwww 
--nodes 1 
--nodes-min 1 
--nodes-max 2 
--node-ami auto 
--node-private-networking

ఇప్పటికే ఉన్న VPCకి అమలు చేయడానికి, మీ సబ్‌నెట్‌ల ఐడిని పేర్కొనండి మరియు eksctl VPCని స్వయంగా నిర్ణయిస్తుంది.

మీ వర్కర్ నోడ్‌లు ప్రైవేట్ సబ్‌నెట్‌కు మాత్రమే అమర్చబడిందని నిర్ధారించుకోవడానికి, మీరు nodegroup కోసం --node-private-networkingని పేర్కొనాలి.

2. మేము మా క్లస్టర్‌లో vpc-కంట్రోలర్‌ను ఇన్‌స్టాల్ చేస్తాము, అది మా వర్కర్ నోడ్‌లను ప్రాసెస్ చేస్తుంది, ఉచిత IP చిరునామాల సంఖ్యను అలాగే ENIల సంఖ్యను లెక్కించి, వాటిని జోడించడం మరియు తీసివేస్తుంది.

eksctl utils install-vpc-controllers --name yyy --approve

3. vpc-కంట్రోలర్‌తో సహా మీ Linux వర్కర్ నోడ్‌లో మీ సిస్టమ్ కంటైనర్‌లు విజయవంతంగా ప్రారంభించబడిన తర్వాత, విండోస్ వర్కర్లతో మరొక నోడ్‌గ్రూప్‌ని సృష్టించడం మాత్రమే మిగిలి ఉంది.

eksctl create nodegroup 
--region www 
--cluster yyy 
--version 1.14 
--name windows-workers 
--node-type t3.small 
--ssh-public-key wwwwwwwwww 
--nodes 1 
--nodes-min 1 
--nodes-max 2 
--node-ami-family WindowsServer2019CoreContainer 
--node-ami ami-0573336fc96252d05 
--node-private-networking

మీ నోడ్ మీ క్లస్టర్‌కి విజయవంతంగా కనెక్ట్ చేయబడిన తర్వాత మరియు ప్రతిదీ సరిగ్గా ఉన్నట్లు అనిపించిన తర్వాత, అది సిద్ధంగా ఉన్న స్థితిలో ఉంది, కానీ లేదు.

vpc-కంట్రోలర్‌లో లోపం

మేము విండోస్ వర్కర్ నోడ్‌లో పాడ్‌లను అమలు చేయడానికి ప్రయత్నిస్తే, మనకు ఎర్రర్ వస్తుంది:

NetworkPlugin cni failed to teardown pod "windows-server-iis-7dcfc7c79b-4z4v7_default" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address]

మేము లోతుగా చూస్తే, AWSలో మా ఉదాహరణ ఇలా కనిపిస్తుంది:

మరియు ఇది ఇలా ఉండాలి:

దీని నుండి vpc-కంట్రోలర్ కొన్ని కారణాల వల్ల దాని భాగాన్ని పూర్తి చేయలేదని మరియు పాడ్‌లు వాటిని ఉపయోగించగలిగేలా కొత్త IP చిరునామాలను జోడించలేకపోయిందని స్పష్టమవుతుంది.

vpc-కంట్రోలర్ పాడ్ యొక్క లాగ్‌లను చూద్దాం మరియు ఇది మనకు కనిపిస్తుంది:

kubectl లాగ్ -n kube-system

I1011 06:32:03.910140       1 watcher.go:178] Node watcher processing node ip-10-xxx.ap-xxx.compute.internal.
I1011 06:32:03.910162       1 manager.go:109] Node manager adding node ip-10-xxx.ap-xxx.compute.internal with instanceID i-088xxxxx.
I1011 06:32:03.915238       1 watcher.go:238] Node watcher processing update on node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.200423       1 manager.go:126] Node manager failed to get resource vpc.amazonaws.com/CIDRBlock  pool on node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxxx
E1011 06:32:08.201211       1 watcher.go:183] Node watcher failed to add node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxx
I1011 06:32:08.201229       1 watcher.go:259] Node watcher adding key ip-10-xxx.ap-xxx.compute.internal (0): failed to find the route table for subnet subnet-0xxxx
I1011 06:32:08.201302       1 manager.go:173] Node manager updating node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.201313       1 watcher.go:242] Node watcher failed to update node ip-10-xxx.ap-xxx.compute.internal: node manager: failed to find node ip-10-xxx.ap-xxx.compute.internal.

Googleలో శోధనలు దేనికీ దారితీయలేదు, స్పష్టంగా ఎవరూ అలాంటి బగ్‌ను ఇంకా పట్టుకోలేదు లేదా దానిపై సమస్యను పోస్ట్ చేయలేదు, నేను ముందుగా ఎంపికల గురించి ఆలోచించవలసి వచ్చింది. గుర్తుకు వచ్చిన మొదటి విషయం ఏమిటంటే, బహుశా vpc-కంట్రోలర్ ip-10-xxx.ap-xxx.compute.internalని పరిష్కరించలేకపోవచ్చు మరియు దానిని చేరుకోవచ్చు మరియు అందువల్ల లోపాలు సంభవిస్తాయి.

అవును, నిజానికి, మేము VPCలో అనుకూల DNS సర్వర్‌లను ఉపయోగిస్తాము మరియు సూత్రప్రాయంగా, మేము Amazon వాటిని ఉపయోగించము, కాబట్టి ఫార్వార్డింగ్ కూడా ఈ ap-xxx.compute.internal డొమైన్ కోసం కాన్ఫిగర్ చేయబడలేదు. నేను ఈ ఎంపికను పరీక్షించాను మరియు అది ఫలితాలను తీసుకురాలేదు, బహుశా పరీక్ష శుభ్రంగా లేదు, అందువల్ల, సాంకేతిక మద్దతుతో కమ్యూనికేట్ చేస్తున్నప్పుడు, నేను వారి ఆలోచనకు లొంగిపోయాను.

నిజంగా ఎలాంటి ఆలోచనలు లేనందున, అన్ని భద్రతా సమూహాలు eksctl ద్వారానే సృష్టించబడ్డాయి, కాబట్టి వాటి సేవల గురించి ఎటువంటి సందేహం లేదు, రూట్ టేబుల్‌లు కూడా సరైనవి, nat, dns, వర్కర్ నోడ్‌లతో ఇంటర్నెట్ యాక్సెస్ కూడా ఉంది.

అంతేకాకుండా, మీరు —node-private-networkingని ఉపయోగించకుండా పబ్లిక్ సబ్‌నెట్‌కు వర్కర్ నోడ్‌ను అమలు చేస్తే, ఈ నోడ్ వెంటనే vpc-కంట్రోలర్ ద్వారా నవీకరించబడుతుంది మరియు ప్రతిదీ క్లాక్‌వర్క్ లాగా పని చేస్తుంది.

రెండు ఎంపికలు ఉన్నాయి:

1. దానిని వదులుకోండి మరియు ఎవరైనా AWSలో ఈ బగ్‌ని వివరించే వరకు వేచి ఉండండి మరియు వారు దాన్ని పరిష్కరించే వరకు వేచి ఉండండి, ఆపై మీరు సురక్షితంగా AWS EKS విండోస్‌ని ఉపయోగించవచ్చు, ఎందుకంటే వారు ఇప్పుడే GAలో విడుదల చేసారు (ఈ కథనాన్ని వ్రాసే సమయానికి 8 రోజులు గడిచాయి), చాలా మంది ఉండవచ్చు నా మార్గాన్నే అనుసరించండి.
2. AWS సపోర్ట్‌కి వ్రాసి, ప్రతిచోటా ఉన్న మొత్తం లాగ్‌లతో సమస్య యొక్క సారాంశాన్ని వారికి చెప్పండి మరియు మీ VPC మరియు సబ్‌నెట్‌లను ఉపయోగిస్తున్నప్పుడు వారి సేవ పని చేయదని వారికి నిరూపించండి, ఇది మాకు వ్యాపార మద్దతును కలిగి ఉంది, మీరు ఉపయోగించాలి కనీసం ఒక్కసారైనా :)

AWS ఇంజనీర్లతో కమ్యూనికేషన్

పోర్టల్‌లో టిక్కెట్‌ని సృష్టించిన తర్వాత, నేను పొరపాటున వెబ్ - ఇమెయిల్ లేదా సపోర్ట్ సెంటర్ ద్వారా నాకు ప్రతిస్పందించడానికి ఎంచుకున్నాను, ఈ ఎంపిక ద్వారా వారు కొన్ని రోజుల తర్వాత మీకు సమాధానం చెప్పగలరు, నా టిక్కెట్‌లో తీవ్రత - సిస్టమ్ బలహీనంగా ఉన్నప్పటికీ, ఇది <12 గంటలలోపు ప్రతిస్పందనను సూచిస్తుంది మరియు వ్యాపార మద్దతు ప్లాన్‌కు 24/7 మద్దతు ఉన్నందున, నేను ఉత్తమమైనదానిని ఆశించాను, కానీ ఇది ఎప్పటిలాగే జరిగింది.

నా టిక్కెట్టు శుక్రవారం నుండి సోమవారం వరకు కేటాయించబడలేదు, ఆపై నేను వారికి మళ్లీ వ్రాయాలని నిర్ణయించుకున్నాను మరియు చాట్ ప్రతిస్పందన ఎంపికను ఎంచుకున్నాను. కొద్దిసేపు వేచి ఉన్న తర్వాత, హర్షద్ మాధవ్ నన్ను చూడటానికి నియమించబడ్డాడు, ఆపై అది ప్రారంభమైంది...

మేము దానితో వరుసగా 3 గంటల పాటు ఆన్‌లైన్‌లో డీబగ్ చేసాము, లాగ్‌లను బదిలీ చేయడం, సమస్యను అనుకరించడానికి అదే క్లస్టర్‌ను AWS లేబొరేటరీలో అమర్చడం, నా వంతుగా క్లస్టర్‌ను మళ్లీ సృష్టించడం మరియు మొదలైన వాటితో మేము వచ్చిన ఏకైక విషయం ఏమిటంటే. లాగ్‌లలో నేను పైన వ్రాసిన AWS అంతర్గత డొమైన్ పేర్లతో రెసోల్ పని చేయడం లేదని స్పష్టమైంది మరియు హర్షద్ మాధవ్ ఫార్వార్డింగ్‌ని సృష్టించమని నన్ను అడిగారు, మేము అనుకూల DNSని ఉపయోగిస్తాము మరియు ఇది సమస్య కావచ్చు.

ఫార్వార్డింగ్

ap-xxx.compute.internal  -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)

అది జరిగింది, రోజు ముగిసింది. హర్షద్ మాధవ్ దాన్ని తనిఖీ చేయమని తిరిగి వ్రాసాడు మరియు అది పని చేయాలి, కానీ లేదు, తీర్మానం అస్సలు సహాయం చేయలేదు.

అప్పుడు మరో 2 ఇంజనీర్లతో కమ్యూనికేషన్ ఉంది, ఒకరు చాట్ నుండి తప్పుకున్నారు, స్పష్టంగా అతను సంక్లిష్టమైన కేసు గురించి భయపడ్డాడు, రెండవది డీబగ్గింగ్, లాగ్‌లను పంపడం, రెండు వైపులా క్లస్టర్‌లను సృష్టించడం వంటి పూర్తి చక్రంలో నా రోజును గడిపాడు. ముగింపు అతను బాగా చెప్పాడు, ఇది నాకు పని చేస్తుంది, ఇక్కడ నేను అధికారిక డాక్యుమెంటేషన్‌లో దశలవారీగా ప్రతిదీ చేస్తాను మరియు మీరు మరియు మీరు విజయం సాధిస్తారు.

దానికి నేను మర్యాదపూర్వకంగా అతనిని విడిచిపెట్టి, సమస్య కోసం ఎక్కడ వెతకాలో మీకు తెలియకపోతే నా టిక్కెట్‌కి మరొకరిని కేటాయించమని అడిగాను.

ముగింపు

మూడవ రోజు, ఒక కొత్త ఇంజనీర్ అరుణ్ బి. నాకు కేటాయించబడింది మరియు అతనితో కమ్యూనికేషన్ ప్రారంభం నుండి ఇది 3 మునుపటి ఇంజనీర్లు కాదని వెంటనే స్పష్టమైంది. అతను మొత్తం చరిత్రను చదివాడు మరియు వెంటనే తన గితుబ్‌లో ఉన్న ps1లో తన స్వంత స్క్రిప్ట్‌ను ఉపయోగించి లాగ్‌లను సేకరించమని అడిగాడు. దీని తర్వాత మళ్లీ క్లస్టర్‌లను సృష్టించడం, కమాండ్ ఫలితాలను అవుట్‌పుట్ చేయడం, లాగ్‌లను సేకరించడం వంటి అన్ని పునరావృత్తులు జరిగాయి, అయితే అరుణ్ బి. నన్ను అడిగిన ప్రశ్నలను బట్టి సరైన దిశలో కదులుతున్నారు.

మేము వారి vpc-కంట్రోలర్‌లో -stderrthreshold=డీబగ్‌ని ఎనేబుల్ చేసే స్థితికి ఎప్పుడు చేరుకున్నాము మరియు తర్వాత ఏమి జరిగింది? అయితే ఇది పని చేయదు) పాడ్ ఈ ఎంపికతో ప్రారంభం కాదు, -stderrthreshold=info మాత్రమే పనిచేస్తుంది.

మేము ఇక్కడ పూర్తి చేసాము మరియు అదే లోపం పొందడానికి నా దశలను పునరుత్పత్తి చేయడానికి ప్రయత్నిస్తానని అరుణ్ బి. మరుసటి రోజు నేను అరుణ్ బి నుండి ప్రతిస్పందనను అందుకుంటాను. అతను ఈ కేసును విడిచిపెట్టలేదు, కానీ వారి vpc-కంట్రోలర్ యొక్క సమీక్ష కోడ్‌ని తీసుకున్నాడు మరియు అది ఉన్న స్థలాన్ని మరియు అది ఎందుకు పని చేయదు:

కాబట్టి, మీరు మీ VPCలో ప్రధాన రూట్ టేబుల్‌ని ఉపయోగిస్తే, డిఫాల్ట్‌గా దానికి అవసరమైన సబ్‌నెట్‌లతో అనుబంధాలు లేవు, ఇవి vpc-కంట్రోలర్‌కి చాలా అవసరం, పబ్లిక్ సబ్‌నెట్ విషయంలో, దీనికి అనుకూల రూట్ టేబుల్ ఉంటుంది దానికి అనుబంధం ఉంది.

అవసరమైన సబ్‌నెట్‌లతో ప్రధాన రూట్ టేబుల్‌కు మాన్యువల్‌గా అసోసియేషన్‌లను జోడించడం ద్వారా మరియు నోడ్‌గ్రూప్‌ను మళ్లీ సృష్టించడం ద్వారా, ప్రతిదీ ఖచ్చితంగా పని చేస్తుంది.

అరుణ్ బి. నిజంగా ఈ బగ్‌ని EKS డెవలపర్‌లకు నివేదిస్తారని నేను ఆశిస్తున్నాను మరియు మేము vpc-కంట్రోలర్ యొక్క కొత్త వెర్షన్‌ను చూస్తాము, ఇక్కడ ప్రతిదీ బాక్స్ వెలుపల పని చేస్తుంది. ప్రస్తుతం తాజా వెర్షన్: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ఈ సమస్య ఉంది.

చివరి వరకు చదివిన ప్రతి ఒక్కరికీ ధన్యవాదాలు, అమలు చేయడానికి ముందు మీరు ఉత్పత్తిలో ఉపయోగించబోయే ప్రతిదాన్ని పరీక్షించండి.

మూలం: www.habr.com