Kubernetes को उचित तुलना लागू गर्नुहोस्, बदल्नुहोस् र प्याच गर्नुहोस्

Kubernetes सँग स्रोतहरू अद्यावधिक गर्न धेरै विकल्पहरू छन्: लागू गर्नुहोस्, सम्पादन गर्नुहोस्, प्याच गर्नुहोस् र बदल्नुहोस्। प्रत्येकले के गर्छ र कहिले प्रयोग गर्ने भन्नेमा अन्योल छ। यसलाई बाहिर निकालौं।

यदि Google मा खोज्नुहोस् वाक्यांश "kubernetes लागू बनाम बदल्नुहोस्" स्थित छ StackOverflow लाई जवाफ दिनुहोस्, जुन सही होइन । खोज्दा "kubernetes लागू बनाम प्याच" को लागि पहिलो लिङ्क कागजात हो kubectl patch, जसमा तुलना समावेश छैन apply и patch। यस लेखले विभिन्न विकल्पहरू, साथै प्रत्येकको उचित प्रयोगलाई हेर्नेछ।

Kubernetes संसाधन (सेवा, डिप्लोइमेन्ट, इन्ग्रेस, आदि) को जीवनचक्रको समयमा, कहिलेकाहीँ तपाईले यस स्रोतको केहि गुणहरू परिवर्तन गर्न, थप्न वा हटाउन आवश्यक पर्दछ। उदाहरणका लागि, नोट थप्नुहोस्, प्रतिकृतिहरूको संख्या बढाउनुहोस् वा घटाउनुहोस्।

Kubernetes CLI

यदि तपाइँ पहिले नै CLI मार्फत Kubernetes क्लस्टरहरूसँग काम गर्दै हुनुहुन्छ भने, तपाइँ पहिले नै परिचित हुनुहुन्छ apply и edit। टोली apply फाइलबाट स्रोत विनिर्देश पढ्छ र Kubernetes क्लस्टरमा "upsert" बनाउँछ, अर्थात्। यदि यो अवस्थित छैन भने संसाधन सिर्जना गर्दछ र यदि यो अवस्थित छ भने अद्यावधिक गर्दछ। टोली edit API मार्फत स्रोत पढ्छ, त्यसपछि स्थानीय फाइलमा स्रोत विनिर्देश लेख्छ, जुन त्यसपछि पाठ सम्पादकमा खोलिन्छ। तपाईंले फाइल सम्पादन र बचत गरेपछि, kubectl API मार्फत गरिएका परिवर्तनहरूलाई फिर्ता पठाउनेछ, जसले यी परिवर्तनहरूलाई संसाधनमा सावधानीपूर्वक लागू गर्नेछ।

सबैलाई आदेशहरू थाहा छैन patch и replace। टोली patch कमाण्ड लाइनमा परिवर्तन गरिएको भाग मात्र उपलब्ध गराउँदै संसाधन विशिष्टताको अंश परिवर्तन गर्न अनुमति दिन्छ। टोली replace जस्तै काम गर्दछ edit, तर सबै कुरा म्यानुअल रूपमा गर्न आवश्यक छ: तपाईंले संसाधन विशिष्टताको हालको संस्करण डाउनलोड गर्न आवश्यक छ, उदाहरणका लागि, प्रयोग गरेर kubectl get -o yaml, यसलाई सम्पादन गर्नुहोस्, त्यसपछि प्रयोग गर्नुहोस् replace एक परिवर्तन विनिर्देश अनुसार एक संसाधन अद्यावधिक गर्न। टोली replace यदि स्रोत पढ्ने र प्रतिस्थापन गर्ने बीचमा कुनै परिवर्तन भयो भने काम गर्दैन।

Kubernetes API

तपाईं शायद विधिहरूसँग परिचित हुनुहुन्छ CoreV1().Pods().Update(), replaceNamespacedService वा patch_namespaced_deployment, यदि तपाइँ क्लस्टरहरू मार्फत काम गर्नुहुन्छ भने Kubernetes API को लागि ग्राहक पुस्तकालय केही प्रोग्रामिङ भाषा प्रयोग गर्दै। पुस्तकालयले विधिहरू प्रयोग गरेर HTTP अनुरोधहरू मार्फत यी विधिहरू ह्यान्डल गर्दछ PUT и PATCH... जसमा update и replace प्रयोग गर्नुहोस् PUTर patch, यो जतिसुकै तुच्छ किन नहोस्, प्रयोग गर्दछ PATCH.

यो उल्लेख गर्न लायक छ kubectl API मार्फत क्लस्टरहरूसँग पनि काम गर्दछ। अर्को शब्दमा, kubectlGo भाषाको लागि क्लाइन्ट लाइब्रेरीको शीर्षमा एउटा र्यापर हो, जसले मानक API क्षमताहरू बाहेक थप कम्प्याक्ट र पढ्न योग्य फारममा उपकमान्डहरू प्रदान गर्ने क्षमता प्रदान गर्दछ। उदाहरणका लागि, तपाईंले पहिले नै याद गरेको हुन सक्छ, विधि apply अघिल्लो अनुच्छेदमा माथि उल्लेख गरिएको थिएन। हाल (मे २०२०, लगभग। अनुवादक) सबै तर्क kubectl apply, अर्थात् अवस्थित नभएका स्रोतहरू सिर्जना गर्ने र अवस्थितहरूलाई अद्यावधिक गर्ने, पूर्ण रूपमा कोड साइडमा काम गर्दछ kubectl। प्रयास भइरहेका छन् तर्क स्थानान्तरण मा apply API साइडमा, तर यो अझै बिटामा छ। म तल थप विवरणमा लेख्नेछु।

पूर्वनिर्धारित रूपमा प्याच

सबै भन्दा राम्रो प्रयोग patch, यदि तपाइँ संसाधन अद्यावधिक गर्न चाहनुहुन्छ भने। यसरी दुबै ग्राहक पुस्तकालयहरूले Kubernetes API को शीर्षमा काम गर्दछ र kubectl (आश्चर्यजनक छैन, किनकि यो ग्राहक पुस्तकालयको लागि र्यापर हो, लगभग। अनुवादक).

रणनीतिक रूपमा काम गर्नुहोस्

सबै टोलीहरू kubectl apply, edit и patch विधि प्रयोग गर्नुहोस् PATCH अवस्थित स्रोत अपडेट गर्न HTTP अनुरोधहरूमा। यदि तपाइँ कमाण्डहरूको कार्यान्वयनमा थप विस्तारमा खोज्नुहुन्छ भने, ती सबैले दृष्टिकोण प्रयोग गर्छन् रणनीतिक-मर्ज प्याचिङ स्रोतहरू अद्यावधिक गर्न, यद्यपि आदेश patch अन्य दृष्टिकोणहरू प्रयोग गर्न सक्छ (तल यस बारे थप)। रणनीतिक-मर्ज प्याचिङ दृष्टिकोणले अवस्थित स्पेसिफिकेशनसँग आपूर्ति गरिएको स्पेसिफिकेशन मर्ज गरेर "यसलाई सही गर्न" प्रयास गर्दछ। थप विशेष रूपमा, यसले वस्तुहरू र arrays दुवै संयोजन गर्ने प्रयास गर्दछ, जसको अर्थ परिवर्तनहरू additive हुन जान्छ। उदाहरणका लागि, आदेश चलाउनुहोस् patch पोड कन्टेनर स्पेसिफिकेशनमा नयाँ वातावरण चरको साथ, ती वातावरण चरलाई विद्यमान वातावरण चरहरूमा अधिलेखन गर्नुको सट्टा थपिने कारण बनाउँछ। यो दृष्टिकोण प्रयोग गरेर हटाउनको लागि, तपाईंले प्रदान गरिएको स्पेसिफिकेशनमा प्यारामिटर मान शून्य गर्न बाध्य पार्नु पर्छ। कुन कुन टोलीमा kubectl यो अद्यावधिक गर्न को लागी प्रयोग गर्न राम्रो छ?

यदि तपाइँ प्रयोग गरेर तपाइँको स्रोतहरू सिर्जना र व्यवस्थापन गर्नुहुन्छ kubectl apply, अद्यावधिक गर्दा यो सधैं प्रयोग गर्न राम्रो छ kubectl applyतेसैले kubectl कन्फिगरेसन व्यवस्थापन गर्न र अनुप्रयोगबाट अनुप्रयोगमा अनुरोध गरिएका परिवर्तनहरू ठीकसँग ट्र्याक गर्न सक्छ। फाइदा सधैं प्रयोग गर्नुहोस् apply यो हो कि यसले पहिले लागू गरिएको स्पेसिफिकेशनको ट्रयाक राख्छ, यसलाई स्पेसिफिकेशन गुणहरू र एरे तत्वहरू स्पष्ट रूपमा हटाउँदा थाहा पाउन अनुमति दिन्छ। यसले तपाईंलाई प्रयोग गर्न अनुमति दिन्छ apply गुण र एरे तत्वहरू हटाउन, जबकि सामान्य रणनीतिक मर्जले काम गर्दैन। टोलीहरू edit и patch नोटहरू अद्यावधिक नगर्नुहोस् kubectl apply यसको परिवर्तनहरू ट्र्याक गर्न प्रयोग गर्दछ, त्यसैले Kubernetes API मार्फत ट्र्याक गरिएका र गरिएका कुनै पनि परिवर्तनहरू, तर आदेशहरू मार्फत बनाइएका छन्। edit и patch, पछिका आदेशहरूमा अदृश्य apply, त्यो हो apply तिनीहरूको लागि इनपुट विशिष्टतामा देखा पर्दैन भने पनि तिनीहरूलाई हटाउँदैन apply (कागजातले भन्छ edit и patch प्रयोग गरिएका नोटहरूमा अद्यावधिक गर्नुहोस् apply, तर व्यवहारमा - होइन)।

यदि तपाइँ आदेश प्रयोग गर्नुहुन्न भने applyको रूपमा प्रयोग गर्न सकिन्छ edit, र patch, गरिएको परिवर्तनको लागि उत्तम सुहाउने आदेश छनोट गर्दै। BOM गुणहरू थप्दा र परिवर्तन गर्दा, दुवै दृष्टिकोणहरू लगभग समान छन्। विनिर्देश गुणहरू वा एरे तत्वहरू मेटाउँदा edit एक पटक प्रक्षेपण जस्तै व्यवहार गर्दछ apply, सम्पादन गर्नु अघि र पछि स्पेसिफिकेशन कस्तो थियो भनेर ट्र्याक राख्ने सहित, ताकि तपाईं स्रोतबाट गुण र एरे तत्वहरू स्पष्ट रूपमा हटाउन सक्नुहुन्छ। तपाईंले स्पष्ट रूपमा स्पेसिफिकेशनमा शून्यमा सम्पत्ति मान सेट गर्न आवश्यक छ patchयसलाई स्रोतबाट हटाउन। रणनीतिक-मर्ज प्याचिङ प्रयोग गरेर एर्रे तत्व हटाउन थप जटिल छ किनभने यसलाई मर्ज निर्देशनहरूको प्रयोग आवश्यक छ। थप व्यवहार्य विकल्पहरूको लागि तलका अन्य अपग्रेड दृष्टिकोणहरू हेर्नुहोस्।

माथिका आदेशहरू जस्तै व्यवहार गर्ने ग्राहक लाइब्रेरीमा अद्यावधिक विधिहरू लागू गर्न kubectl, अनुरोध मा सेट गर्नुपर्छ content-type в application/strategic-merge-patch+json। यदि तपाइँ स्पेसिफिकेशनमा गुणहरू हटाउन चाहनुहुन्छ भने, तपाइँले स्पष्ट रूपमा तिनीहरूको मानहरूलाई समान रूपमा शून्यमा सेट गर्न आवश्यक छ। kubectl patch। यदि तपाइँ एरे तत्वहरू हटाउन आवश्यक छ भने, तपाइँले अद्यावधिक विशिष्टतामा मर्ज निर्देशनहरू समावेश गर्नुपर्छ वा अपडेटहरूको लागि फरक दृष्टिकोण प्रयोग गर्नुपर्छ।

अपडेट गर्न अन्य दृष्टिकोणहरू

Kubernetes दुई अन्य अपडेट दृष्टिकोण समर्थन गर्दछ: JSON मर्ज प्याच и JSON प्याच। JSON मर्ज प्याच दृष्टिकोणले इनपुटको रूपमा आंशिक Kubernetes स्पेसिफिकेशन लिन्छ र रणनीतिक-मर्ज प्याचिङ दृष्टिकोण जस्तै मर्ज वस्तुहरूलाई समर्थन गर्दछ। दुई बीचको भिन्नता यो हो कि यसले पोड विशिष्टतामा कन्टेनर एरे सहित एरे प्रतिस्थापनलाई मात्र समर्थन गर्दछ। यसको मतलब यो हो कि JSON मर्ज प्याच प्रयोग गर्दा, तपाईंले कुनै पनि कन्टेनरको कुनै पनि गुण परिवर्तन भएमा सबै कन्टेनरहरूको लागि पूर्ण विनिर्देशहरू प्रदान गर्न आवश्यक छ। त्यसैले यो दृष्टिकोण BOM मा एरेबाट तत्वहरू हटाउनको लागि उपयोगी छ। कमाण्ड लाइनमा तपाईले JSON मर्ज प्याच प्रयोग गरेर चयन गर्न सक्नुहुन्छ kubectl patch --type=merge। Kubernetes API सँग काम गर्दा, तपाईंले अनुरोध विधि प्रयोग गर्नुपर्छ PATCH र स्थापना content-type в application/merge-patch+json.

JSON प्याच दृष्टिकोण, स्रोतको आंशिक विवरण प्रदान गर्नुको सट्टा, तपाईंले एरेको रूपमा स्रोतमा गर्न चाहनुभएको परिवर्तनहरू प्रदान गर्ने प्रयोग गर्दछ, जसमा एरेको प्रत्येक तत्वले स्रोतमा गरिएको परिवर्तनको विवरण प्रतिनिधित्व गर्दछ। यो दृष्टिकोण परिवर्तनहरू अभिव्यक्त गर्न थप लचिलो र शक्तिशाली तरिका हो, तर आंशिक स्रोत निर्दिष्टीकरण पठाउनुको सट्टा छुट्टै, गैर-कुबरनेट ढाँचामा गरिएका परिवर्तनहरूलाई सूचीबद्ध गर्ने लागतमा। IN kubectl तपाईं प्रयोग गरेर JSON प्याच चयन गर्न सक्नुहुन्छ kubectl patch --type=json। Kubernetes API प्रयोग गर्दा, यो दृष्टिकोण अनुरोध विधि प्रयोग गरेर काम गर्दछ PATCH र स्थापना content-type в application/json-patch+json.

हामीलाई आत्मविश्वास चाहिन्छ - प्रतिस्थापन प्रयोग गर्नुहोस्

कतिपय अवस्थामा, तपाईंले यो सुनिश्चित गर्न आवश्यक छ कि स्रोत पढ्ने समय र यसलाई अद्यावधिक गरिएको बीचमा कुनै पनि परिवर्तन गरिएको छैन। अर्को शब्दमा, तपाईंले सबै परिवर्तनहरू हुनेछन् भनेर सुनिश्चित गर्नुपर्छ परमाणु। यस अवस्थामा, तपाईंले स्रोतहरू अद्यावधिक गर्न प्रयोग गर्नुपर्छ replace। उदाहरणका लागि, यदि तपाइँसँग एक काउन्टरसँग कन्फिगम्याप छ जुन धेरै स्रोतहरूद्वारा अद्यावधिक गरिएको छ, तपाइँ निश्चित हुनुपर्दछ कि दुई स्रोतहरूले एकै समयमा काउन्टर अद्यावधिक गर्दैनन्, जसले गर्दा अद्यावधिक हराएको छ। प्रदर्शन गर्न, दृष्टिकोण प्रयोग गरेर घटनाहरूको अनुक्रम कल्पना गर्नुहोस् patch:

• A र B ले API बाट स्रोतको हालको अवस्था प्राप्त गर्दछ
• प्रत्येकले स्थानीय रूपमा काउन्टरलाई एक एक गरी बढाएर र "अद्यावधिक-द्वारा" नोटमा क्रमशः "A" वा "B" थपेर विनिर्देश अद्यावधिक गर्दछ।
• र यसले संसाधन अलि छिटो अपडेट गर्दछ
• B स्रोत अद्यावधिक गर्दछ

नतिजाको रूपमा, अद्यावधिक A हराएको छ। पछिल्लो अपरेशन patch जीत हुन्छ, काउन्टरलाई दुईको सट्टा एकले बढाइन्छ, र "अपडेट-द्वारा" नोटको मान "B" सँग समाप्त हुन्छ र "A" समावेश गर्दैन। माथिको तुलना गरौं के हुन्छ जब अपडेटहरू दृष्टिकोण प्रयोग गरेर गरिन्छ replace:

• A र B ले API बाट स्रोतको हालको अवस्था प्राप्त गर्दछ
• प्रत्येकले स्थानीय रूपमा काउन्टरलाई एक एक गरी बढाएर र "अद्यावधिक-द्वारा" नोटमा क्रमशः "A" वा "B" थपेर विनिर्देश अद्यावधिक गर्दछ।
• र यसले संसाधन अलि छिटो अपडेट गर्दछ
• B ले संसाधन अद्यावधिक गर्ने प्रयास गर्दछ, तर अद्यावधिकलाई API द्वारा अस्वीकार गरिएको छ किनभने स्रोत संस्करण निर्दिष्टीकरणमा छ। replace Kubernetes मा संसाधनको हालको संस्करणसँग मेल खाँदैन किनभने स्रोतको संस्करण A को प्रतिस्थापन सञ्चालनद्वारा बढाइएको थियो।

माथिको अवस्थामा, B ले संसाधन पुन: प्राप्त गर्न, नयाँ स्थितिमा परिवर्तन गर्न र पुन: प्रयास गर्नुपर्नेछ replace। यसले काउन्टरलाई दुई र "अद्यावधिक-द्वारा" नोटको अन्त्यमा "AB" समावेश गर्नको लागि बढाउँछ।

माथिको उदाहरणले कार्यान्वयन गर्दा बुझाउँछ replace सम्पूर्ण स्रोत पूर्ण रूपमा प्रतिस्थापन गरिएको छ। को लागि प्रयोग गरिएको विशिष्टता replace, आंशिक, वा भागहरूमा जस्तै हुनु हुँदैन apply, तर थप सहित पूरा resourceVersion विनिर्देशन मेटाडेटा मा। यदि तपाईंले सक्षम गर्नुभएको छैन भने resourceVersion वा तपाईंले प्रदान गर्नुभएको संस्करण हालको छैन, प्रतिस्थापन अस्वीकार गरिनेछ। त्यसैले प्रयोग गर्न सबै भन्दा राम्रो तरिका हो replace - स्रोत पढ्नुहोस्, यसलाई अपडेट गर्नुहोस् र तुरुन्तै बदल्नुहोस्। प्रयोग गर्दै kubectl, यो यस्तो देखिन सक्छ:

$ kubectl get deployment my-deployment -o json 
    | jq '.spec.template.spec.containers[0].env[1].value = "new value"' 
    | kubectl replace -f -

यो ध्यान दिन लायक छ कि निम्न दुई आदेशहरू, क्रमशः निष्पादित, सफलतापूर्वक कार्यान्वयन हुनेछ, किनकि deployment.yaml सम्पत्ति समावेश गर्दैन .metadata.resourceVersion

$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yaml

यो माथि भनिएको विरोधाभास जस्तो देखिन्छ, अर्थात्। "थप्दै resourceVersion विनिर्देशन मेटाडेटामा।" के यो भन्न गलत छ? होइन, यो होइन, किनभने यदि kubectl तपाईंले निर्दिष्ट नगरेको सूचनाहरू resourceVersion, यसले यसलाई स्रोतबाट पढ्छ र तपाइँले निर्दिष्ट गरेको स्पेसिफिकेशनमा थप्नेछ, र त्यसपछि मात्र यसलाई कार्यान्वयन गर्नुहोस्। replace। किनभने यो सम्भावित रूपमा खतरनाक छ यदि तपाईं परमाणुमा भरोसा गर्नुहुन्छ भने, जादू पूर्ण रूपमा पक्षमा काम गर्दछ kubectl, API सँग काम गर्ने क्लाइन्ट लाइब्रेरीहरू प्रयोग गर्दा तपाईंले यसमा भर पर्नु हुँदैन। यस अवस्थामा तपाईंले हालको स्रोत विवरण पढ्नुपर्नेछ, यसलाई अद्यावधिक गर्नुहोस् र त्यसपछि कार्यान्वयन गर्नुहोस् PUT अनुरोध।

तपाईं प्याच गर्न सक्नुहुन्न - हामी प्रतिस्थापन गर्छौं

कहिलेकाहीँ तपाईले केहि परिवर्तनहरू गर्न आवश्यक छ जुन API द्वारा ह्यान्डल गर्न सकिँदैन। यी अवस्थाहरूमा, तपाइँ यसलाई मेटाएर र पुन: सिर्जना गरेर स्रोतको प्रतिस्थापन गर्न सक्नुहुन्छ। यो प्रयोग गरी गरिन्छ kubectl replace --force। आदेश चलाउँदा तुरुन्तै स्रोतहरू हटाउँछ र त्यसपछि तिनीहरूलाई आपूर्ति विशिष्टताबाट पुन: सिर्जना गर्दछ। API मा कुनै "बल प्रतिस्थापन" ह्यान्डलर छैन, र API मार्फत त्यसो गर्नको लागि, तपाईंले दुईवटा अपरेशनहरू गर्न आवश्यक छ। पहिले तपाईंले यसको लागि सेटिङ गरेर संसाधन मेटाउन आवश्यक छ gracePeriodSeconds शून्य (०) र propagationPolicy "पृष्ठभूमि" मा र त्यसपछि इच्छित विशिष्टता संग यो संसाधन पुन: सिर्जना गर्नुहोस्।

चेतावनी: यो दृष्टिकोण सम्भावित खतरनाक छ र एक अपरिभाषित राज्य को नेतृत्व गर्न सक्छ।

सर्भर साइडमा आवेदन दिनुहोस्

माथि उल्लेख गरिए अनुसार, Kubernetes विकासकर्ताहरूले तर्क लागू गर्न काम गरिरहेका छन् apply बाट kubectl Kubernetes API मा। तर्क apply Kubernetes 1.18 मार्फत उपलब्ध छ kubectl apply --server-side वा विधि प्रयोग गरेर API मार्फत PATCH с content-type application/apply-patch+YAML.

नोट: JSON पनि मान्य YAML हो, त्यसैले तपाईंले JSON को रूपमा विनिर्देश पठाउन सक्नुहुन्छ भने पनि content-type हुनेछ application/apply-patch+yaml.

त्यो तर्क बाहेक kubectl API मार्फत सबैका लागि उपलब्ध हुन्छ, apply सर्भर साइडमा, स्पेसिफिकेशनमा फिल्डहरूको लागि को जिम्मेवार छ भनेर ट्र्याक राख्छ, यसरी यसको विवाद-रहित सम्पादनको लागि सुरक्षित बहु पहुँच अनुमति दिन्छ। अर्को शब्दमा, यदि apply सर्भर साइडमा अझ व्यापक हुनेछ, एक विश्वव्यापी सुरक्षित स्रोत व्यवस्थापन इन्टरफेस विभिन्न ग्राहकहरूको लागि देखा पर्नेछ, उदाहरणका लागि, kubectl, Pulumi वा Terraform, GitOps, साथै ग्राहक पुस्तकालयहरू प्रयोग गरेर स्व-लिखित स्क्रिप्टहरू।

परिणामहरू

मलाई आशा छ कि क्लस्टरहरूमा स्रोतहरू अद्यावधिक गर्ने विभिन्न तरिकाहरूको यो छोटो सिंहावलोकन तपाईंको लागि उपयोगी थियो। यो जान्न राम्रो छ कि यो केवल लागू बनाम प्रतिस्थापन मात्र होइन; लागू, सम्पादन, प्याच, वा प्रतिस्थापन प्रयोग गरेर स्रोत अद्यावधिक गर्न सम्भव छ। आखिर, सिद्धान्त मा, प्रत्येक दृष्टिकोण आवेदन को आफ्नै क्षेत्र छ। आणविक परिवर्तनहरूको लागि, प्रतिस्थापन उपयुक्त छ; अन्यथा, तपाईंले लागू मार्फत रणनीतिक-मर्ज प्याच प्रयोग गर्नुपर्छ। कम्तिमा, म तपाइँले "kubernetes लागू बनाम प्रतिस्थापन" खोज्दा Google वा StackOerflow लाई विश्वास गर्न सक्नुहुन्न भन्ने कुरा बुझ्नु भएको आशा गर्दछु। कम्तिमा यस लेखले हालको जवाफलाई प्रतिस्थापन नगरेसम्म।

स्रोत: www.habr.com