डॉकर सेवाओं के मानकीकरण का सिद्धांत और अभ्यास

Microservice एप्लिकेशन आर्किटेक्चर के विषय पर जानकारी, जो पहले से ही अपनी बढ़त को भरने में कामयाब रही है, आज यह तय करने के लिए पर्याप्त है कि यह आपके उत्पाद के अनुरूप है या नहीं। और यह एक रहस्य नहीं है कि जिन कंपनियों ने इस रास्ते को चुनने का फैसला किया है, उन्हें कई इंजीनियरिंग और सांस्कृतिक चुनौतियों का सामना करना पड़ता है। समस्याओं के स्रोतों में से एक ओवरहेड है जो हर जगह गुणा कर रहा है, और यह समान रूप से उत्पादन प्रक्रियाओं से जुड़ी दिनचर्या पर लागू होता है।

_{छवि स्रोत:}

जैसा कि आप अनुमान लगा सकते हैं कि एंटी-प्लेगिज्म सिर्फ एक ऐसी कंपनी है, जहां धीरे-धीरे यह समझ आई कि हम रास्ते में माइक्रोसेवा के साथ हैं। लेकिन कैक्टस खाना शुरू करने से पहले, हमने इसे साफ करने और पकाने का फैसला किया। और चूंकि सभी के लिए एकमात्र सही और सही समाधान अद्वितीय हैं, सुंदर तीरों के साथ सार्वभौमिक DevOps स्लाइड के बजाय, हमने बस अपने स्वयं के अनुभव को साझा करने का फैसला किया और बताया कि कैसे हमने पहले से ही अपने विशेष पथ का एक बड़ा हिस्सा कवर किया है, मुझे उम्मीद है, सफलता।

यदि आप वास्तव में अद्वितीय उत्पाद बना रहे हैं, तो दूर-दूर तक पता चलता है, इस विशेष पथ को चकमा देने का कोई मौका नहीं है, क्योंकि यह कई निजी लोगों से बना है: कंपनी में विकसित संस्कृति और ऐतिहासिक डेटा से शुरू होता है, जो अपनी विशिष्टता और तकनीकी स्टैक के साथ समाप्त होता है। ।

किसी भी कंपनी और टीम के लिए कार्यों में से एक है, फ्रीडम और नियमों के बीच इष्टतम संतुलन का पता लगाना, और माइक्रोसिस्टम्स इस समस्या को एक नए स्तर पर ले जाते हैं। ऐसा प्रतीत हो सकता है कि बहुत ही सूक्ष्मजीवियों के विचार का खंडन किया गया है, जो प्रौद्योगिकियों के चुनाव में व्यापक स्वतंत्रता का अर्थ है, लेकिन अगर आप सीधे वास्तु और तकनीकी मुद्दों पर ध्यान केंद्रित नहीं करते हैं, लेकिन उत्पादन की समस्याओं को समग्र रूप से देखें, तो "गार्डन ऑफ़ अर्थली डिलाइट्स" के कथानक में कहीं होने का जोखिम काफी हद तक मूर्त है। ।

हालांकि, "क्रिएटिंग माइक्रोसिस्टीव्स" पुस्तक में सैम न्यूमैन इस समस्या का समाधान प्रस्तुत करते हैं, जहां शाब्दिक रूप से पहले पृष्ठों से वे तकनीकी समझौतों के ढांचे के भीतर टीमों की रचनात्मकता को सीमित करने की आवश्यकता की बात करते हैं। तो सफलता की कुंजी में से एक, विशेष रूप से एक सीमित फ्री-हैंड संसाधन के संदर्भ में, सब कुछ का मानकीकरण है जिसे केवल बातचीत के जरिए किया जा सकता है और कोई भी वास्तव में हर समय नहीं करना चाहेगा। समझौतों पर काम करके, हम सिस्टम के घटकों के उत्पादन और संचालन में सभी प्रतिभागियों के लिए खेल के स्पष्ट नियम बनाते हैं। और खेल के नियमों को जानते हुए, आपको सहमत होना चाहिए, इसे खेलना आसान और अधिक सुखद होना चाहिए। हालांकि, इन नियमों का पालन करना स्वयं एक दिनचर्या बन सकता है और प्रतिभागियों को असुविधा का कारण बन सकता है, जो सीधे उनसे सभी प्रकार के विचलन की ओर जाता है और, परिणामस्वरूप, पूरे विचार की विफलता। और सबसे स्पष्ट तरीका यह है कि सभी समझौतों को कोड में रखा जाए, क्योंकि एक भी विनियमन ऐसा नहीं कर सकता है जो स्वचालन और सुविधाजनक उपकरण का उपयोग कर सकता है, जिसका उपयोग सहज और प्राकृतिक है।

इस दिशा में आगे बढ़ते हुए, हम अधिक से अधिक स्वचालित करने में सक्षम थे, और हमारी प्रक्रिया पुस्तकालयों और सूक्ष्म (या ऐसा नहीं) सेवाओं के उत्पादन के लिए एंड-टू-एंड कन्वेयर की तरह हो गई।

थोड़ी पृष्ठभूमि

2017 के वसंत में, माइक्रोसॉफ्ट ने दुनिया को .NET कोर 2.0 का पूर्वावलोकन पेश किया, और इस साल सी # ज्योतिषियों ने तुरंत लिनक्स वर्ष घोषित करने के लिए दौड़ लगाई, इसलिए ...

_{छवि स्रोत:}

कुछ समय के लिए, हमने विंडोज और लिनक्स दोनों पर जादू पर भरोसा नहीं किया, सब कुछ एकत्र किया और परीक्षण किया, कुछ SSH लिपियों के साथ प्रकाशित कलाकृतियों को स्विस चाकू मोड में पुराने CI / CD पाइपलाइनों को कॉन्फ़िगर करने का प्रयास किया। लेकिन कुछ समय बाद उन्हें महसूस हुआ कि हम कुछ गलत कर रहे हैं। इसके अलावा, माइक्रोसर्विस और कंटेनरों के संदर्भ में अधिक से अधिक बार ध्वनि होती है। इसलिए हमने प्रचार लहर की सवारी करने और इन दिशाओं का पता लगाने का फैसला किया।

पहले से ही हमारे संभावित microservice भविष्य पर प्रतिबिंब के चरण में, कई सवाल उठे, जिसे अनदेखा करते हुए, हमने भविष्य की इस नई समस्याओं में जोखिम लिया जो हमने स्वयं के लिए हल किए लोगों के लिए बनाए होंगे।

सबसे पहले, जब नियमों के बिना सैद्धांतिक microservice दुनिया के संचालन पक्ष को देखते हुए, हम सभी आगामी परिणामों के साथ अराजकता की संभावना से डर गए थे, जिसमें न केवल परिणाम की अप्रत्याशित गुणवत्ता शामिल थी, बल्कि टीमों या डेवलपर्स और इंजीनियरों के बीच संघर्ष भी था। और कुछ सिफारिशें देने की कोशिश कर रहा है, उनके अनुपालन सुनिश्चित करने में सक्षम नहीं, तुरंत एक खाली उपक्रम की तरह लग रहा था।

दूसरे, कोई भी वास्तव में यह नहीं जानता था कि कंटेनरों को कैसे ठीक से बनाया जाए और डॉकफाइल्स लिखा जाए, जो कि, पहले से ही हमारी रिपॉजिटरी में जीवंत चर्चा शुरू कर चुके हैं। इसके अलावा, बहुत से “कहीं पढ़े” कि वहाँ सब कुछ इतना सरल नहीं है। तो, किसी को गहराई से गोता लगाना था और यह पता लगाना था, फिर सबसे अच्छा कंटेनर विधानसभा प्रथाओं के साथ लौटना। लेकिन पूर्णकालिक पूर्णकालिक पैकर की भूमिका निभाने की संभावना, डॉक फाइलों के ढेर के साथ अकेला छोड़ दिया, किसी कारण से कंपनी में किसी को प्रेरित नहीं किया। इसके अलावा, जैसा कि यह निकला, एक बार डाइविंग स्पष्ट रूप से पर्याप्त नहीं है, और यहां तक ​​कि पहली नज़र में अच्छा और सही लग रहा है, यह गलत हो सकता है या बस बहुत अच्छा नहीं हो सकता है।

और तीसरा, मैं यह सुनिश्चित करना चाहता था कि सेवाओं के साथ प्राप्त छवियां न केवल कंटेनर प्रथाओं के दृष्टिकोण से सही होंगी, बल्कि उनके व्यवहार में भी अनुमान लगाने योग्य होंगी और लॉन्च किए गए कंटेनरों के नियंत्रण को सरल बनाने के लिए सभी आवश्यक गुण और विशेषताएं होंगी। दूसरे शब्दों में, मैं उन अनुप्रयोगों के साथ छवियां प्राप्त करना चाहता था जो समान रूप से कॉन्फ़िगर किए गए हैं और लॉग लिखते हैं, मेट्रिक्स प्राप्त करने के लिए एक एकल इंटरफ़ेस प्रदान करते हैं, लेबल का एक सुसंगत सेट है, और जैसे। यह भी महत्वपूर्ण था कि डेवलपर के कंप्यूटर पर असेंबली किसी भी CI सिस्टम में असेंबली के समान परिणाम देती है, जिसमें उत्तीर्ण परीक्षण और कलाकृतियों को शामिल करना शामिल है।

इस प्रकार, एक समझ का जन्म हुआ कि नए ज्ञान, प्रथाओं और मानकों को प्रबंधित करने और केंद्रीकृत करने के लिए कुछ प्रक्रिया की आवश्यकता होगी, और उत्पाद संरचना के लिए पूरी तरह से तैयार एक डॉक छवि के लिए मार्ग को एकीकृत किया जाना चाहिए और संभव के रूप में स्वचालित किया जाना चाहिए, शर्तों से परे नहीं। निरंतर शब्द के साथ।

सीएलआई बनाम जीयूआई

एक नए घटक के लिए शुरुआती बिंदु, यह एक सेवा या एक पुस्तकालय हो, एक भंडार बनाना है। इस चरण को दो भागों में विभाजित किया जा सकता है: संस्करण नियंत्रण प्रणाली (हमारे पास बिटबकेट है) की मेजबानी पर रिपॉजिटरी को बनाना और कॉन्फ़िगर करना और इसे एक फ़ाइल संरचना बनाने के साथ प्रारंभ करना है। सौभाग्य से, आवश्यकताओं की एक संख्या पहले से ही दोनों के लिए मौजूद थी। इसलिए, उन्हें कोड में औपचारिक रूप देना एक तार्किक कार्य था।

तो हमारा भंडार क्या होना चाहिए:

• परियोजनाओं में से एक में स्थित है, जिस पर नाम, पहुंच अधिकार, पुल अनुरोधों को स्वीकार करने के लिए नीतियां, आदि।
• आवश्यक फ़ाइलें और निर्देशिकाएं, जैसे:
  
  • SolutionInfo.props रिपॉजिटरी के बारे में कॉन्फ़िगरेशन और जानकारी के साथ फ़ाइल (उस पर और अधिक);
  • src डायरेक्टरी में प्रोजेक्ट सोर्स कोड;
  • README.md , README.md , आदि;
• आवश्यक गिट सबमॉडल्स को शामिल करें;
• परियोजना को किसी एक टेम्पलेट से लिया जाना चाहिए।

चूंकि Bitbucket REST API रिपॉजिटरी के कॉन्फ़िगरेशन पर पूर्ण नियंत्रण देता है, इसलिए इसके साथ बातचीत के लिए एक विशेष उपयोगिता बनाई गई थी - रिपॉजिटरी जनरेटर। सवाल-जवाब मोड में, वह उपयोगकर्ता से सभी आवश्यक डेटा प्राप्त करता है और एक रिपॉजिटरी बनाता है जो पूरी तरह से हमारी सभी आवश्यकताओं को पूरा करता है, अर्थात्:

• चुनने के लिए Bitbucket में एक परियोजना को परिभाषित करता है;
• हमारे समझौते के अनुसार नाम को मान्य करता है;
• सभी आवश्यक सेटिंग्स बनाता है जो परियोजना से विरासत में नहीं मिल सकता है;
• परियोजना के लिए कस्टम टेम्प्लेट (हम डॉट टेम्प्लेटिंग का उपयोग करते हैं) की सूची को अपडेट करते हैं और इससे चुनने का सुझाव देते हैं;
• कॉन्फ़िगरेशन फ़ाइल और *.md दस्तावेज़ों में भंडार के बारे में न्यूनतम आवश्यक जानकारी भरता है;
• यह सबमॉड्यूल्स को CI / CD पाइपलाइन कॉन्फ़िगरेशन (हमारे मामले में यह बम्बू स्पेक्स है ) और असेंबली स्क्रिप्ट के साथ जोड़ता है।

दूसरे शब्दों में, डेवलपर, एक नई परियोजना शुरू करने, उपयोगिता लॉन्च करता है, कई क्षेत्रों में भरता है, परियोजना के प्रकार का चयन करता है और प्राप्त करता है, उदाहरण के लिए, पूरी तरह से समाप्त "हैलो दुनिया!" एक सेवा जो पहले से ही सीआई सिस्टम से जुड़ी हुई है, जहां से सेवा को प्रकाशित भी किया जा सकता है यदि आप एक ऐसा प्रतिबद्ध बनाते हैं जो संस्करण को नॉनज़रो में बदलता है।

पहला कदम उठाया गया है। कोई मैनुअल श्रम और त्रुटियों, प्रलेखन, पंजीकरण और एसएमएस के लिए खोज। अब आइए वहां क्या उत्पन्न हुआ था, उस पर आगे बढ़ते हैं।

संरचना

रिपॉजिटरी संरचना के मानकीकरण ने लंबे समय से हमारे साथ जड़ें जमा ली हैं और विधानसभा को सरल बनाने, सीआई प्रणाली और विकास के वातावरण के साथ एकीकरण की आवश्यकता थी। प्रारंभ में, हम इस विचार से निर्देशित थे कि CI में पाइपलाइन यथासंभव सरल होनी चाहिए और, जैसा कि आप अनुमान लगा सकते हैं, मानक, जो विधानसभा की पोर्टेबिलिटी और पुनरुत्पादन सुनिश्चित करेगा। यही है, एक ही परिणाम किसी भी CI सिस्टम और डेवलपर के कार्यस्थल पर दोनों को आसानी से प्राप्त किया जा सकता है। इसलिए, सब कुछ जो एक विशिष्ट निरंतर एकीकरण वातावरण की सुविधाओं से संबंधित नहीं है, एक विशेष गिट सबमॉड्यूल को प्रस्तुत किया जाता है और एक आत्मनिर्भर बिल्ड सिस्टम है। अधिक सटीक रूप से, विधानसभा मानकीकरण प्रणाली। पाइप लाइन ही, एक न्यूनतम सन्निकटन के लिए, केवल build.sh स्क्रिप्ट को चलाना चाहिए, परीक्षणों पर एक रिपोर्ट चुनें और यदि आवश्यक हो, तो एक तैनाती शुरू करें। स्पष्टता के लिए, आइए देखें कि क्या होता है यदि आप किसी प्रोजेक्ट में सेम्प्सवर्क रिपॉजिटरी को बोल नाम सैंडबॉक्स के साथ उत्पन्न करते हैं।

 . ├── [bamboo-specs] ├── [devops.build] │ ├── build.sh │ └── ... ├── [docs] ├── [.scripts] ├── [src] │ ├── [CodeAnalysis] │ ├── [Sandbox.SampleService] │ ├── [Sandbox.SampleService.Bootstrap] │ ├── [Sandbox.SampleService.Client] │ ├── [Sandbox.SampleService.Tests] │ ├── Directory.Build.props │ ├── NLog.config │ ├── NuGet.Config │ └── Sandbox.SampleService.sln ├── .gitattributes ├── .gitignore ├── .gitmodules ├── CHANGELOG.md ├── README.md └── SolutionInfo.props 

पहली दो निर्देशिका Git सबमॉड्यूल हैं। एटलसियन बांस सीआई सिस्टम के लिए bamboo-specs "पाइपलाइन के रूप में कोड" है (इसके स्थान पर कुछ जेनकिंसफाइल हो सकता था), devops.build हमारी बिल्ड सिस्टम है, जिसके बारे में मैं नीचे विस्तार से चर्चा करूंगा। .scripts निर्देशिका भी इस .scripts । .NET प्रोजेक्ट स्वयं src में स्थित है: NuGet.Config में निजी NuGet रिपॉजिटरी का कॉन्फ़िगरेशन शामिल है, NLog.config देव-समय कॉन्फ़िगरेशन है। जैसा कि आप अनुमान लगा सकते हैं, एक कंपनी में NLog का उपयोग करना भी मानकों में से एक है। यहाँ दिलचस्प सामग्री में से लगभग मैजिक Directory.Build.props है। Directory.Build.props फ़ाइल। किसी कारण से, बहुत कम लोग .NET परियोजनाओं में ऐसी संभावना के बारे में जानते हैं, जैसे कि विधानसभा का अनुकूलन । संक्षेप में, Directory.Build.props और Directory.Build.targets नाम वाली फाइलें स्वचालित रूप से आपकी परियोजनाओं में आयात की जाती हैं और आपको एक ही स्थान पर सभी परियोजनाओं के लिए सामान्य गुणों को कॉन्फ़िगर करने की अनुमति देती हैं। उदाहरण के लिए, यह है कि कैसे हम CodeAnalysis विश्लेषक और इसके कॉन्फ़िगरेशन को CodeAnalysis निर्देशिका से सभी कोड-शैली परियोजनाओं से CodeAnalysis हैं, पुस्तकालयों और पैकेजों ( कंपनी , कॉपीराइट , आदि) के लिए कुछ सामान्य विशेषताएँ सेट करते हैं, और <Import> माध्यम से भी कनेक्ट करते हैं। <Import> फ़ाइल SolutionInfo.props , जो ठीक उसी रिपॉजिटरी कॉन्फ़िगरेशन फ़ाइल है, जिसकी चर्चा ऊपर की गई थी। इसमें पहले से ही वर्तमान संस्करण, लेखकों के बारे में जानकारी, रिपॉजिटरी URL और इसके विवरण, साथ ही कई गुण हैं जो बिल्ड सिस्टम के व्यवहार और परिणामी कलाकृतियों को प्रभावित करते हैं।

 <?xml version="1.0"?> <Project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="devops.build/SolutionInfo.xsd"> <PropertyGroup> <!-- Product name --> <Product>Sandbox.SampleService</Product> <!-- Product version. Version 0.0.0 wouldn't be published! --> <BaseVersion>0.0.0</BaseVersion> <!-- Project name which contains Main() --> <EntryProject>Sandbox.SampleService.Bootstrap</EntryProject> <!-- Exposed port --> <ExposedPort>4000/tcp</ExposedPort> <!-- DOTNET_SYSTEM_GLOBALIZATION_INVARIANT value. See https://github.com/dotnet/corefx/blob/master/Documentation/architecture/globalization-invariant-mode.md --> <GlobalizationInvariant>false</GlobalizationInvariant> <!-- Project URL --> <RepositoryUrl>https://bitbucket.contoso.com/projects/SND/repos/sandbox.sampleservice/</RepositoryUrl> <!-- Documentation URL --> <DocumentationUrl>https://bitbucket.contoso.com/projects/SND/repos/sandbox.sampleservice/browse/README.md</DocumentationUrl> <!-- Your name here --> <Authors>User Name &lt;username@contoso.com&gt;</Authors> <!-- Project description --> <Description>The sample service for demo purposes.</Description> <!-- Bamboo plan key (required for Bamboo Specs --> <BambooBlanKey>SMPL</BambooBlanKey> </PropertyGroup> </Project> 

 <Project> <Import Condition="Exists('..\SolutionInfo.props')" Project="..\SolutionInfo.props" /> <ItemGroup> <None Include="$(MSBuildThisFileDirectory)/CodeAnalysis/stylecop.json" Link="stylecop.json" CopyToOutputDirectory="Never"/> <PackageReference Include="StyleCop.Analyzers" Version="1.*" PrivateAssets="all" /> </ItemGroup> <PropertyGroup> <CodeAnalysisRuleSet>$(MSBuildThisFileDirectory)/CodeAnalysis/stylecop.ruleset</CodeAnalysisRuleSet> <!-- Enable XML docs generating--> <GenerateDocumentationFile>true</GenerateDocumentationFile> <!-- Enable C# 7.x features --> <LangVersion>latest</LangVersion> <!-- default base version --> <BaseVersion Condition="'$(BaseVersion)' == ''">0.0.0</BaseVersion> <!-- default build number and format --> <BuildNumber Condition="'$(BuildNumber)' == ''">0</BuildNumber> <BuildNumber>$([System.String]::Format('{0:0000}',$(BuildNumber)))</BuildNumber> <!-- default version suffix --> <VersionSuffix Condition="'$(VersionSuffix)' == ''">local</VersionSuffix> <!-- empty version suffix instead of 'prod' --> <VersionSuffix Condition="'$(VersionSuffix)' == 'prod'"></VersionSuffix> <!-- format version prefix --> <VersionPrefix>$(BaseVersion).$(BuildNumber)</VersionPrefix> <!-- disable IsPackable by default --> <IsPackable>false</IsPackable> <PackageProjectUrl>$(RepositoryUrl)</PackageProjectUrl> <Company>Contoso</Company> <Copyright>Copyright $([System.DateTime]::Now.Date.Year) Contoso Ltd</Copyright> </PropertyGroup> </Project> 

सभा

यह अभी ध्यान देने योग्य है कि मेरे और मेरे सहकर्मियों को पहले से ही विभिन्न बिल्ड सिस्टम का उपयोग करने में काफी सफल अनुभव था। और एक मौजूदा टूल को पूरी तरह से अप्राप्य कार्यक्षमता के साथ भारित करने के बजाय, यह एक और बनाने का फैसला किया गया था, हमारी नई प्रक्रिया के लिए विशेष, और विरासत परियोजनाओं के हिस्से के रूप में अपने कार्यों को पूरा करने के लिए पुराने को अकेला छोड़ दें। फिक्स विचार एक उपकरण प्राप्त करने की इच्छा थी जो कोड को एक डॉकटर छवि में बदल देगा जो एक एकल मानक प्रक्रिया में हमारी सभी आवश्यकताओं को पूरा करता है, जबकि डेवलपर्स को विधानसभा की पेचीदगियों में गोता लगाने की आवश्यकता से बचाता है, लेकिन कुछ अनुकूलन की संभावनाओं को संरक्षित करता है।

एक उपयुक्त रूपरेखा का चयन शुरू हो गया है। लिनक्स के साथ बिल्ड मशीनों और किसी भी डेवलपर की विंडोज मशीनों पर परिणाम की प्रतिलिपि प्रस्तुत करने योग्यता की आवश्यकताओं के आधार पर, वास्तविक क्रॉस-प्लेटफ़ॉर्म और न्यूनतम पूर्वनिर्धारित निर्भरताएं एक महत्वपूर्ण स्थिति बन गईं। अलग-अलग समय पर, मैं .NET डेवलपर्स के लिए कुछ असेंबली फ्रेमवर्क को अच्छी तरह से जानने में कामयाब रहा: MSBuild और इसके राक्षसी XML विन्यासों से, जिसे बाद में Psake (Powershell) में अनुवादित कर, विदेशी FAKE (F #) में बदल दिया गया। लेकिन इस बार मुझे कुछ नया और हल्का चाहिए था। इसके अलावा, यह पहले से ही तय किया गया था कि असेंबली और परीक्षण पूरी तरह से एक अलग कंटेनर वातावरण में किया जाना चाहिए, इसलिए मैंने डॉकर सीएलआई और गिट के आदेशों के अलावा किसी अन्य चीज के अंदर चलाने की योजना नहीं बनाई थी, अर्थात, इस प्रक्रिया का अधिकांश डॉकफाइल में वर्णित किया जाना चाहिए था।
उस समय, .NET कोर के लिए FAKE 5 और केक दोनों अभी भी तैयार नहीं थे, इसलिए एक क्रॉस-प्लेटफॉर्म के साथ, ये परियोजनाएं इतनी थीं। लेकिन मेरी प्यारी प्यारी पॉवरशेल 6 कोर पहले ही रिलीज़ हो चुकी है, और मैंने इसका पूरा उपयोग किया है। इसलिए, मैंने फिर से Psake की ओर रुख करने का फैसला किया, और जब मैं मुड़ा, तो मैंने एक दिलचस्प इनवोक-बिल्ड प्रोजेक्ट पर ठोकर खाई, जो कि Psake का पुनर्विचार है और जैसा कि लेखक खुद बताते हैं, वही, केवल बेहतर और आसान है। तो यह है। मैं इस लेख के ढांचे के बारे में विस्तार से नहीं बताऊंगा, मैं केवल इस बात पर ध्यान दूंगा कि यदि उत्पाद के इस वर्ग के सभी बुनियादी कार्य उपलब्ध हैं तो कॉम्पैक्टनेस मुझे इसमें घूस देती है:

• क्रियाओं के अनुक्रम को परस्पर संबंधित कार्यों (कार्यों) के एक सेट द्वारा वर्णित किया गया है, जिसे उनकी अन्योन्याश्रितताओं और अतिरिक्त स्थितियों का उपयोग करके नियंत्रित किया जा सकता है।
• कई उपयोगी हेल्पर्स हैं, उदाहरण के लिए, कंसोल एप्लिकेशन एक्ज़िट कोड को सही ढंग से संभालने के लिए {} निष्पादित करें।
• Ctrl + C का उपयोग करने वाले किसी भी अपवाद या स्टॉप को विशेष रूप से निर्मित एक्जिट-बिल्ड ब्लॉक में सही तरीके से संसाधित किया जाएगा। उदाहरण के लिए, वहां आप सभी अस्थायी फ़ाइलों, एक परीक्षण वातावरण को हटा सकते हैं या एक रिपोर्ट खींच सकते हैं जो आंख को भाती है।

जेनेरिक डॉकरफाइल

docker build और डॉक docker build का उपयोग करने वाली असेंबली काफी कमजोर पैरामीटर क्षमता प्रदान करती है, और इन उपकरणों का लचीलापन फावड़े के हैंडल की तुलना में थोड़ा अधिक है। इसके अलावा, "गलत" छवि बनाने के लिए बड़ी संख्या में तरीके हैं, बहुत बड़े, बहुत असुरक्षित, बहुत ही अनपेक्षित या बस अप्रत्याशित। सौभाग्य से, माइक्रोसॉफ्ट के प्रलेखन में पहले से ही डॉकरफाइल के कई उदाहरण हैं , जो आपको मूल अवधारणाओं को जल्दी से समझने और अपनी पहली डॉकफाइल बनाने की अनुमति देते हैं, बाद में धीरे-धीरे इसमें सुधार करते हैं। वह पहले से ही एक मल्टी-स्टेज पैटर्न का उपयोग करता है और परीक्षण चलाने के लिए एक विशेष " टेस्ट रनर " छवि बनाता है।

मल्टी-स्टेज पैटर्न और तर्क

पहला चरण विधानसभा चरणों को छोटे लोगों में विभाजित करना और नए लोगों को जोड़ना है। तो, यह एक अलग चरण के रूप में dotnet build के लॉन्च को उजागर करने के लायक है, क्योंकि केवल पुस्तकालयों वाली परियोजनाओं के लिए, यह dotnet publish को चलाने के लिए कोई मतलब नहीं है। अब, हमारे विवेक पर, हम केवल आवश्यक विधानसभा चरणों का उपयोग कर चला सकते हैं
dotnet build --target <name>
उदाहरण के लिए, यहां हम केवल पुस्तकालयों वाली एक परियोजना एकत्र कर रहे हैं। यहाँ की कलाकृतियाँ केवल NuGet पैकेज हैं, जिसका अर्थ है कि रनटाइम इमेज को इकट्ठा करने का कोई मतलब नहीं है।

या हम पहले से ही एक सेवा का निर्माण कर रहे हैं, लेकिन सुविधा शाखा से। हमें ऐसी विधानसभा की कलाकृतियों की बिल्कुल भी आवश्यकता नहीं है, केवल परीक्षणों और स्वास्थ्य परीक्षण को पास करना महत्वपूर्ण है।

अगली बात यह है कि बुनियादी छवियों के उपयोग को पैरामीटर बनाना है। अभी कुछ समय के लिए, डॉकरफाइल में, ARG निर्देश को बिल्ड चरणों के बाहर रखा जा सकता है , और स्थानांतरित मानों का उपयोग बेस इमेज के नाम पर किया जा सकता है।

 ARG DOTNETCORE_VERSION=2.2 ARG ALPINE_VERSION= ARG BUILD_BASE=mcr.microsoft.com/dotnet/core/sdk:${DOTNETCORE_VERSION}-alpine${ALPINE_VERSION} ARG RUNTIME_BASE=mcr.microsoft.com/dotnet/core/runtime:${DOTNETCORE_VERSION}-alpine${ALPINE_VERSION} FROM ${BUILD_BASE} AS restore ... FROM ${RUNTIME_BASE} AS runtime ... 

इसलिए हम नए और पहली नज़र में मिले, और स्पष्ट अवसर नहीं। सबसे पहले, यदि हम एक ASP.NET कोर एप्लिकेशन के साथ एक छवि बनाना चाहते हैं, तो रनटाइम छवि को एक अलग की आवश्यकता होगी: mcr.microsoft.com/dotnet/core/aspnet । गैर-मानक मूल छवि वाले पैरामीटर को SolutionInfo.props रिपॉजिटरी के कॉन्फ़िगरेशन में सहेजा जाना चाहिए और इसे असेंबली के दौरान एक तर्क के रूप में पारित किया गया। हमने डेवलपर के लिए .NET कोर छवियों के अन्य संस्करणों का उपयोग करना भी आसान बना दिया है: पूर्वावलोकन, उदाहरण के लिए, या यहां तक ​​कि कस्टम वाले (जिन्हें आप कभी नहीं जानते हैं!)।

दूसरे, डॉकरीफाइल को "विस्तार" करने की क्षमता और भी दिलचस्प है, एक और असेंबली में संचालन का हिस्सा बनाया गया है, जिसके परिणाम को रनटाइम छवि तैयार करते समय एक आधार के रूप में लिया जाएगा। उदाहरण के लिए, हमारी कुछ सेवाएं जावास्क्रिप्ट और Vue.js का उपयोग करती हैं, जिसका कोड हम एक अलग छवि में तैयार करेंगे, बस इस तरह के "विस्तार" डॉकरीफाइल को रिपॉजिटरी में जोड़ते हैं:

 ARG DOTNETCORE_VERSION=2.2 ARG ALPINE_VERSION= ARG RUNTIME_BASE=mcr.microsoft.com/dotnet/core/aspnet:${DOTNETCORE_VERSION}-alpine${ALPINE_VERSION} FROM node:alpine AS install WORKDIR /build COPY package.json . RUN npm install FROM install AS src COPY [".babelrc", ".eslintrc.js", ".stylelintrc", "./"] COPY ClientApp ./ClientApp FROM src AS publish RUN npm run build-prod FROM ${RUNTIME_BASE} AS appbase COPY --from=publish /build/wwwroot/ /app/wwwroot/ 

आइए इस छवि को टैग के साथ इकट्ठा करते हैं, जिसे हम RUNTIME_BASE के तर्क के रूप में ASP.NET सेवा की रनटाइम छवि को इकट्ठा करने के चरण में पास करेंगे। इसलिए आप असेंबली का जितना चाहें विस्तार कर सकते हैं, जिसमें आप शामिल हैं, आप यह निर्धारित कर सकते हैं कि आप क्या नहीं कर सकते हैं। वॉल्यूम के जोड़ को बड़ा करना चाहते हैं? आसान:

 ARG DOTNETCORE_VERSION=2.2 ARG ALPINE_VERSION= ARG RUNTIME_BASE=mcr.microsoft.com/dotnet/core/aspnet:${DOTNETCORE_VERSION}-alpine${ALPINE_VERSION} FROM ${RUNTIME_BASE} AS runtime ARG VOLUME VOLUME ${VOLUME} 

हम इस Dockerfile की असेंबली को कई बार शुरू करते हैं क्योंकि हम VOLUME निर्देश जोड़ना चाहते हैं। हम सेवा के लिए आधार के रूप में परिणामी छवि का उपयोग करते हैं।

परीक्षण चल रहा है

सीधे विधानसभा चरणों में परीक्षण चलाने के बजाय, यह विशेष "टेस्ट रनर" कंटेनर में ऐसा करने के लिए अधिक सही और अधिक सुविधाजनक है। संक्षेप में इस दृष्टिकोण का सार, मैं ध्यान दें कि यह आपको अनुमति देता है:

• सभी निर्धारित लॉन्च करें, भले ही उनमें से कोई भी दुर्घटनाग्रस्त हो;
• एक परीक्षण रिपोर्ट प्राप्त करने के लिए कंटेनर में होस्ट फ़ाइल सिस्टम निर्देशिका को माउंट करें, जो सीआई सिस्टम में निर्माण करते समय महत्वपूर्ण है;
• अपने नेटवर्क का नाम docker run --network <test_network_name> से पास करके अस्थायी वातावरण में परीक्षण चलाएं।

अंतिम पैराग्राफ का मतलब है कि अब हम न केवल इकाई परीक्षण चला सकते हैं, बल्कि एकीकरण परीक्षण भी कर सकते हैं। हम पर्यावरण का वर्णन करते हैं, उदाहरण के लिए, docker-compose.yaml , और इसे संपूर्ण बिल्ड के लिए चलाएं। अब आप डेटाबेस या हमारी अन्य सेवा के साथ बातचीत की जाँच कर सकते हैं, और यदि आप विश्लेषण के लिए आवश्यक हैं, तो उनसे लॉग को बचा सकते हैं।

हम हमेशा हेल्थचेक पास करने के लिए परिणामी रनटाइम छवि की जांच करते हैं, जो एक तरह का परीक्षण भी है। अस्थायी परीक्षण वातावरण यहाँ काम आ सकता है यदि परीक्षण की जा रही सेवा की अपने वातावरण पर निर्भरता है।

मैं यह भी ध्यान देता हूं कि dotnet build साथ स्टेज पर इकट्ठे हुए रनर कंटेनरों के साथ dotnet nuget push dotnet pack और dotnet nuget push लॉन्च करने के लिए ठीक है। यह हमें स्थानीय स्तर पर विधानसभा कलाकृतियों को बचाने की अनुमति देगा।

Healthcheck और OS निर्भरताएँ

बहुत जल्दी यह स्पष्ट हो गया कि हमारी मानकीकृत सेवाएं अभी भी अपने तरीके से अनूठी होंगी। छवि के अंदर ऑपरेटिंग सिस्टम के प्रीइंस्टॉल्ड पैकेजों के लिए उनकी अलग-अलग आवश्यकताएं हो सकती हैं और स्वास्थ्य जांच के विभिन्न तरीके। और अगर कर्ल वेब एप्लिकेशन की स्थिति की जांच करने के लिए उपयुक्त है, तो जीआरपीसी बैकएंड या इसके अलावा, एक हेडलेस सेवा के लिए, यह बेकार हो जाएगा, और यह कंटेनर में एक अतिरिक्त पैकेज भी होगा।

डेवलपर्स को छवि को अनुकूलित करने और इसके कॉन्फ़िगरेशन का विस्तार करने का अवसर देने के लिए, हम कई विशेष लिपियों पर समझौते का उपयोग करते हैं जिन्हें भंडार में फिर से परिभाषित किया जा सकता है:

 .scripts ├── healthcheck.sh ├── run.sh └── runtime-deps.sh 

healthcheck.sh स्क्रिप्ट में स्थिति की जांच करने के लिए आवश्यक कमांड हैं:

• वेब का उपयोग कर्ल के लिए:

  
  

   #!/bin/ash set –e curl -sIf -o /dev/null -w "%{http_code}\n" 127.0.0.1/health || exit 1 

  
  

• हमारी स्वयं की क्ली उपयोगिता का उपयोग करने वाली अन्य सेवाएं:

  
  

   #!/bin/ash set –e healthcheck || exit 1 

  
  

runtime-deps.sh का उपयोग करते runtime-deps.sh , निर्भरताएं स्थापित की जाती हैं और यदि आवश्यक हो, तो आधार ओएस पर किसी भी अन्य कार्यों को किया जाता है जो कंटेनर के अंदर आवेदन के सामान्य कामकाज के लिए आवश्यक हैं। विशिष्ट उदाहरण:

• वेब एप्लिकेशन के लिए:

  
  

   #!/bin/ash apk add --no-cache curl icu-libs 

  
  

• जीआरपीसी सेवा के लिए:

  
  

   #!/bin/ash apk add --no-cache libc6-compat 

  
  

इस प्रकार, निर्भरता को प्रबंधित करने और राज्य को जांचने का तरीका मानकीकृत है, लेकिन कुछ लचीलेपन के लिए जगह है। जैसा कि run.sh , तो आगे है।

एंट्रीपॉइंट स्क्रिप्ट

मुझे यकीन है कि हर कोई जो कम से कम एक बार अपने डॉकरफाइल को लिखता है वह सोचता है कि किस निर्देश का उपयोग करना है - CMD या ENTRYPOINT इसके अलावा, इन टीमों के पास दो वाक्यविन्यास विकल्प भी हैं, जो सबसे नाटकीय तरीके से परिणाम को प्रभावित करते हैं। मैं विस्तार से अंतर नहीं बताऊंगा, उन लोगों के बाद दोहरा रहा हूं जिन्होंने पहले ही सब कुछ स्पष्ट कर दिया है । मैं सिर्फ यह याद रखने की सलाह देता हूं कि 99% स्थितियों में ENTRYPOINT और निष्पादन सिंटैक्स का उपयोग करना सही है:

ENTRYPOINT ["/ पथ / से / निष्पादन योग्य"]

अन्यथा, लॉन्च किया गया एप्लिकेशन OS कमांड, जैसे कि SIGTERM, आदि को सही ढंग से संसाधित नहीं कर पाएगा, और आप ज़ोंबी प्रक्रियाओं और PID 1 समस्या से जुड़ी हर चीज के रूप में भी परेशानी में पड़ सकते हैं। लेकिन क्या होगा अगर आप एप्लिकेशन को लॉन्च किए बिना कंटेनर शुरू करना चाहते हैं? हां, आप प्रवेश बिंदु को ओवरराइड कर सकते हैं:
docker run --rm -it --entrypoint ash <image_name> <params>
यह बहुत आरामदायक और सहज ज्ञान युक्त नहीं दिखता है, है ना? लेकिन अच्छी खबर है: आप बेहतर कर सकते हैं! अर्थात्, एक प्रविष्टि बिंदु स्क्रिप्ट का उपयोग करें। इस तरह की स्क्रिप्ट आपको मनमाने ढंग से जटिल ( उदाहरण ) आरंभीकरण, मापदंडों के प्रसंस्करण और कुछ भी जो आप चाहते हैं बनाने की अनुमति देती है।

हमारे मामले में, डिफ़ॉल्ट रूप से, सबसे सरल, लेकिन एक ही समय में कार्यात्मक परिदृश्य का उपयोग किया जाता है:

 #!/bin/sh set -e if [ ! -z "$1" ] && $(command -v $1 >/dev/null 2>&1) then exec $@ else exec /usr/bin/dotnet /app/${ENTRY_PROJECT}.dll $@ fi 

यह आपको बहुत सहजता से कंटेनर के प्रक्षेपण को नियंत्रित करने की अनुमति देता है:
docker run <image> env - पर्यावरण चर दिखाते हुए, बस छवि में env निष्पादित करता है।
docker run <image> -param1 value1 - निर्दिष्ट तर्कों के साथ सेवा शुरू करें।

अलग-अलग, आपको exec कमांड पर ध्यान देने की आवश्यकता है: निष्पादन योग्य एप्लिकेशन को कॉल करने से पहले इसकी उपस्थिति आपके कंटेनर में प्रतिष्ठित पीआईडी ​​1 के साथ प्रदान करेगी।

और क्या

बेशक, उपयोग के डेढ़ साल से अधिक समय में, बिल्ड सिस्टम ने बहुत अधिक कार्यक्षमता जमा की है। विभिन्न चरणों की लॉन्च स्थितियों को प्रबंधित करने के अलावा, कलाकृतियों, संस्करण और अन्य विशेषताओं के भंडारण के साथ काम करते हुए, कंटेनर के हमारे "मानक" भी विकसित हुए। यह महत्वपूर्ण विशेषताओं से भरा था जो इसे अधिक पूर्वानुमान और प्रशासनिक रूप से सुविधाजनक बनाते हैं:

• सभी आवश्यक छवि लेबल स्थापित हैं: संस्करण, संशोधन संख्या, प्रलेखन के लिंक, लेखक और अन्य।
• रनटाइम कंटेनर में, NLog कॉन्फ़िगरेशन को पुनर्परिभाषित किया जाता है ताकि प्रकाशन के बाद सभी लॉग को तुरंत संरचित रूप में json का उपयोग करके प्रस्तुत किया जाए, जिसका संस्करण संस्करण है।
• स्थैतिक विश्लेषण नियम और किसी भी अन्य मानकों को स्वचालित रूप से बनाए रखा जाता है।

ऐसा उपकरण, निश्चित रूप से, हमेशा बेहतर और विकसित किया जा सकता है। यह सब जरूरतों और कल्पना पर निर्भर करता है। उदाहरण के लिए, सब कुछ के अलावा, एक छवि में अतिरिक्त क्लि उपयोगिताओं को पैकेज करना संभव था। डेवलपर उन्हें आसानी से छवि में डाल सकता है, कॉन्फ़िगरेशन फ़ाइल में केवल आवश्यक उपयोगिता नाम और .NET प्रोजेक्ट का नाम निर्दिष्ट कर सकता है जिसमें से इसे इकट्ठा किया जाना चाहिए (उदाहरण के लिए, हमारा healthcheck परीक्षण)।

निष्कर्ष

यहाँ वर्णित मानकीकरण के लिए एक एकीकृत दृष्टिकोण का केवल एक हिस्सा है। , , , , , . . , .

, Linux , - . , , . , , , Code Style, , .

, ! , « », , . , Docker .