🥇डॉकरसह सतत वितरणाचे सराव (पुनरावलोकन आणि व्हिडिओ)

आम्ही आमच्या तांत्रिक संचालकाच्या नवीनतम भाषणांवर आधारित प्रकाशनांसह आमचा ब्लॉग सुरू करू डिस्टॉल (दिमित्री स्टोल्यारोव्ह). ते सर्व 2016 मध्ये विविध व्यावसायिक कार्यक्रमांमध्ये झाले आणि ते DevOps आणि डॉकर या विषयाला समर्पित होते. Badoo कार्यालयात डॉकर मॉस्को बैठकीचा एक व्हिडिओ, आमच्याकडे आधीच आहे प्रकाशित ऑनलाइन. अहवालांचे सार सांगणाऱ्या लेखांसह नवीन लेख असतील. त्यामुळे…

परिषदेत 31 मे रूटकॉन्फ 2016, “रशियन इंटरनेट टेक्नॉलॉजीज” (RIT++ 2016) या महोत्सवाचा भाग म्हणून आयोजित, “सतत तैनाती आणि उपयोजन” हा विभाग “डॉकरसह सतत वितरणाच्या सर्वोत्तम पद्धती” या अहवालासह उघडला गेला. डॉकर आणि इतर मुक्त स्त्रोत उत्पादनांचा वापर करून सतत वितरण (CD) प्रक्रिया तयार करण्यासाठी सर्वोत्कृष्ट पद्धतींचा सारांश आणि पद्धतशीरपणे वर्णन केले आहे. आम्ही उत्पादनामध्ये या उपायांसह कार्य करतो, जे आम्हाला व्यावहारिक अनुभवावर अवलंबून राहू देते.

एक तास घालवण्याची संधी असल्यास अहवालाचा व्हिडिओ, आम्ही ते पूर्ण पाहण्याची शिफारस करतो. अन्यथा, खाली मजकूर स्वरूपात मुख्य सारांश आहे.

डॉकरसह सतत वितरण

अंतर्गत सतत वितरण आम्हाला इव्हेंटची साखळी समजते ज्याचा परिणाम म्हणून Git रेपॉजिटरीमधील ऍप्लिकेशन कोड प्रथम उत्पादनात येतो आणि नंतर संग्रहात समाप्त होतो. ती अशी दिसते: Git → बिल्ड → चाचणी → रिलीज → ऑपरेट.

बहुतेक अहवाल बिल्ड स्टेज (अॅप्लिकेशन असेंब्ली) ला समर्पित आहे आणि विषय सोडणे आणि ऑपरेट करणे या विषयांवर थोडक्यात स्पर्श केला आहे. आम्ही समस्या आणि नमुन्यांबद्दल बोलू जे आपल्याला त्यांचे निराकरण करण्याची परवानगी देतात आणि या नमुन्यांची विशिष्ट अंमलबजावणी भिन्न असू शकते.

इथे डॉकरची अजिबात गरज का आहे? आम्ही या मुक्त स्त्रोत साधनाच्या संदर्भात सतत वितरण पद्धतींबद्दल बोलण्याचा निर्णय घेतला हे काही कारण नाही. जरी संपूर्ण अहवाल त्याच्या वापरासाठी समर्पित आहे, परंतु अनुप्रयोग कोड रोलआउटच्या मुख्य पॅटर्नचा विचार करताना अनेक कारणे उघड होतात.

मुख्य रोलआउट नमुना

म्हणून, जेव्हा आम्ही अनुप्रयोगाच्या नवीन आवृत्त्या आणतो, तेव्हा आम्हाला नक्कीच सामना करावा लागतो डाउनटाइम समस्या, उत्पादन सर्व्हर स्विचिंग दरम्यान व्युत्पन्न. अॅप्लिकेशनच्या जुन्या आवृत्तीकडून नवीन आवृत्तीवर रहदारी त्वरित स्विच करू शकत नाही: प्रथम आम्ही हे सुनिश्चित केले पाहिजे की नवीन आवृत्ती केवळ यशस्वीरित्या डाउनलोड केली जात नाही तर "वॉर्म अप" (म्हणजे, विनंत्या पूर्ण करण्यासाठी तयार आहे).

अशा प्रकारे, काही काळ अनुप्रयोगाच्या दोन्ही आवृत्त्या (जुन्या आणि नवीन) एकाच वेळी कार्य करतील. जे आपोआप नेत असते सामायिक संसाधन संघर्ष: नेटवर्क, फाइल सिस्टम, IPC, इ. डॉकरसह, स्वतंत्र कंटेनरमध्ये अनुप्रयोगाच्या भिन्न आवृत्त्या चालवून ही समस्या सहजपणे सोडविली जाते, ज्यासाठी समान होस्ट (सर्व्हर/व्हर्च्युअल मशीन) मध्ये संसाधन अलगावची हमी दिली जाते. नक्कीच, आपण इन्सुलेशनशिवाय काही युक्त्या वापरून मिळवू शकता, परंतु जर तेथे तयार आणि सोयीस्कर साधन असेल तर उलट कारण आहे - त्याकडे दुर्लक्ष करू नका.

उपयोजित केल्यावर कंटेनरायझेशन इतर अनेक फायदे प्रदान करते. कोणताही अर्ज अवलंबून असतो विशिष्ट आवृत्ती (किंवा आवृत्ती श्रेणी) दुभाषी, मॉड्यूल्स/विस्तारांची उपलब्धता, इ. तसेच त्यांच्या आवृत्त्या. आणि हे केवळ तत्काळ कार्यान्वित करण्यायोग्य वातावरणावरच लागू होत नाही, तर संपूर्ण वातावरणास देखील लागू होते, यासह सिस्टम सॉफ्टवेअर आणि त्याची आवृत्ती (वापरलेल्या लिनक्स वितरणापर्यंत). कंटेनरमध्ये केवळ ऍप्लिकेशन कोडच नाही तर आवश्यक आवृत्त्यांचे प्री-इंस्टॉल केलेले सिस्टम आणि ऍप्लिकेशन सॉफ्टवेअर देखील असते या वस्तुस्थितीमुळे, आपण अवलंबित्वांसह समस्या विसरू शकता.

चला सारांश द्या मुख्य रोलआउट नमुना खालील घटक विचारात घेऊन नवीन आवृत्त्या:

प्रथम, अनुप्रयोगाची जुनी आवृत्ती पहिल्या कंटेनरमध्ये चालते.
नवीन आवृत्ती नंतर आणली जाते आणि दुसऱ्या कंटेनरमध्ये "वॉर्म अप" केली जाते. हे लक्षात घेण्यासारखे आहे की या नवीन आवृत्तीमध्ये केवळ अद्यतनित ऍप्लिकेशन कोडच नाही तर त्याचे कोणतेही अवलंबित्व तसेच सिस्टम घटक (उदाहरणार्थ, OpenSSL ची नवीन आवृत्ती किंवा संपूर्ण वितरण) देखील असू शकते.
जेव्हा नवीन आवृत्ती विनंत्या पूर्ण करण्यासाठी तयार असते, तेव्हा रहदारी पहिल्या कंटेनरवरून दुसऱ्या कंटेनरवर स्विच करते.
जुनी आवृत्ती आता थांबवली जाऊ शकते.

अनुप्रयोगाच्या वेगवेगळ्या आवृत्त्या वेगळ्या कंटेनरमध्ये तैनात करण्याचा हा दृष्टीकोन आणखी एक सोय प्रदान करतो - द्रुत रोलबॅक जुन्या आवृत्तीवर (तरीही, रहदारीला इच्छित कंटेनरवर स्विच करण्यासाठी पुरेसे आहे).

शेवटची पहिली शिफारस अशी वाटते की ज्यामध्ये कॅप्टनलाही दोष सापडला नाही: “[डॉकरसह सतत वितरण आयोजित करताना] डॉकर वापरा [आणि ते काय देते ते समजून घ्या]" लक्षात ठेवा, ही एक चांदीची बुलेट नाही जी प्रत्येक समस्या सोडवेल, परंतु एक साधन आहे जे एक अद्भुत पाया प्रदान करते.

पुनरुत्पादनक्षमता

"पुनरुत्पादकता" द्वारे आमचा अर्थ अनुप्रयोग चालवताना आलेल्या समस्यांचा एक सामान्यीकृत संच आहे. आम्ही अशा प्रकरणांबद्दल बोलत आहोत:

स्टेजिंगसाठी गुणवत्ता विभागाद्वारे तपासलेल्या स्क्रिप्ट्स उत्पादनामध्ये अचूकपणे पुनरुत्पादित केल्या पाहिजेत.
सर्व्हरवर अनुप्रयोग प्रकाशित केले जातात जे वेगवेगळ्या रिपॉझिटरी मिररमधून पॅकेजेस प्राप्त करू शकतात (कालांतराने ते अद्यतनित केले जातात आणि त्यांच्यासह स्थापित केलेल्या अनुप्रयोगांच्या आवृत्त्या).
"माझ्यासाठी स्थानिक पातळीवर सर्व काही कार्य करते!" (...आणि विकासकांना उत्पादनात परवानगी नाही.)
आपल्याला जुन्या (संग्रहित) आवृत्तीमध्ये काहीतरी तपासण्याची आवश्यकता आहे.
...

त्यांचे सामान्य सार या वस्तुस्थितीवर उकळते की वापरलेल्या वातावरणाचे पूर्ण पालन (तसेच मानवी घटकाची अनुपस्थिती) आवश्यक आहे. आम्ही पुनरुत्पादनक्षमतेची हमी कशी देऊ शकतो? डॉकर प्रतिमा बनवा Git च्या कोडवर आधारित, आणि नंतर ते कोणत्याही कार्यासाठी वापरा: चाचणी साइटवर, उत्पादनात, प्रोग्रामरच्या स्थानिक मशीनवर... त्याच वेळी, केल्या जाणार्‍या क्रिया कमी करणे महत्वाचे आहे после प्रतिमा एकत्र करणे: ते जितके सोपे असेल तितके त्रुटी असतील.

पायाभूत सुविधा म्हणजे कोड

जर पायाभूत सुविधांची आवश्यकता (सर्व्हर सॉफ्टवेअरची उपलब्धता, त्याची आवृत्ती, इ.) औपचारिक आणि "प्रोग्राम केलेले" नसेल, तर कोणत्याही ऍप्लिकेशन अपडेटच्या रोलआउटचे घातक परिणाम होऊ शकतात. उदाहरणार्थ, स्टेजिंगमध्ये तुम्ही आधीच PHP 7.0 वर स्विच केले आहे आणि त्यानुसार कोड पुन्हा लिहिला आहे - नंतर काही जुन्या PHP (5.5) सह उत्पादनात त्याचे स्वरूप नक्कीच एखाद्याला आश्चर्यचकित करेल. इंटरप्रिटर आवृत्तीमधील मोठ्या बदलाबद्दल आपण कदाचित विसरणार नाही, परंतु "सैतान तपशीलांमध्ये आहे": आश्चर्य हे कोणत्याही अवलंबित्वाच्या किरकोळ अद्यतनात असू शकते.

या समस्येचे निराकरण करण्याचा दृष्टीकोन म्हणून ओळखला जातो IaC (कोड म्हणून पायाभूत सुविधा, "कोड म्हणून पायाभूत सुविधा") आणि अनुप्रयोग कोडसह पायाभूत सुविधांच्या आवश्यकता संचयित करणे समाविष्ट आहे. त्याचा वापर करून, विकासक आणि DevOps विशेषज्ञ एकाच Git ऍप्लिकेशन रिपॉजिटरीसह कार्य करू शकतात, परंतु त्याच्या वेगवेगळ्या भागांवर. या कोडमधून, Git मध्ये एक डॉकर प्रतिमा तयार केली जाते, ज्यामध्ये पायाभूत सुविधांची सर्व वैशिष्ट्ये लक्षात घेऊन अनुप्रयोग तैनात केला जातो. सोप्या भाषेत सांगायचे तर, प्रतिमा एकत्र करण्यासाठी स्क्रिप्ट (नियम) स्त्रोत कोडसह समान भांडारात आणि एकत्र विलीन केल्या पाहिजेत.

मल्टी-लेयर अॅप्लिकेशन आर्किटेक्चरच्या बाबतीत - उदाहरणार्थ, nginx आहे, जो आधीपासून डॉकर कंटेनरमध्ये कार्यरत असलेल्या अॅप्लिकेशनच्या समोर उभा आहे - प्रत्येक लेयरसाठी Git मधील कोडमधून डॉकर प्रतिमा तयार केल्या पाहिजेत. नंतर पहिल्या प्रतिमेमध्ये दुभाषी आणि इतर "क्लोज" अवलंबनांसह एक अनुप्रयोग असेल आणि दुसर्‍या प्रतिमेमध्ये अपस्ट्रीम nginx असेल.

डॉकर प्रतिमा, Git सह संप्रेषण

आम्ही Git वरून संकलित केलेल्या सर्व डॉकर प्रतिमा दोन श्रेणींमध्ये विभागतो: तात्पुरते आणि प्रकाशन. तात्पुरत्या प्रतिमा Git मधील शाखेच्या नावाने टॅग केलेले, पुढील कमिटद्वारे अधिलिखित केले जाऊ शकते आणि केवळ पूर्वावलोकनासाठी (उत्पादनासाठी नाही) आणले जाऊ शकते. रिलीझ केलेल्यांपेक्षा हा त्यांचा मुख्य फरक आहे: त्यांच्यामध्ये कोणती विशिष्ट कमिट आहे हे तुम्हाला कधीच माहित नाही.

तात्पुरत्या प्रतिमा एकत्रित करणे अर्थपूर्ण आहे: मास्टर शाखा (मास्टरची वर्तमान आवृत्ती सतत पाहण्यासाठी तुम्ही स्वतंत्र साइटवर स्वयंचलितपणे रोल आउट करू शकता), प्रकाशनांसह शाखा, विशिष्ट नवकल्पनांच्या शाखा.

तात्पुरत्या प्रतिमांच्या पूर्वावलोकनानंतर उत्पादनात भाषांतराची आवश्यकता भासते, विकासक एक विशिष्ट टॅग लावतात. टॅगद्वारे स्वयंचलितपणे संकलित प्रतिमा सोडा (त्याचा टॅग Git मधील टॅगशी संबंधित आहे) आणि स्टेजिंगमध्ये आणला आहे. गुणवत्ता विभागाद्वारे त्याची यशस्वीरित्या पडताळणी झाल्यास, ते उत्पादनात जाते.

डॅप

वर्णन केलेली प्रत्येक गोष्ट (रोलआउट, प्रतिमा असेंब्ली, त्यानंतरची देखभाल) बॅश स्क्रिप्ट आणि इतर "सुधारित" साधनांचा वापर करून स्वतंत्रपणे अंमलात आणली जाऊ शकते. परंतु आपण असे केल्यास, नंतर काही क्षणी अंमलबजावणीमध्ये मोठी जटिलता आणि खराब नियंत्रणक्षमता निर्माण होईल. हे समजून घेऊन, आम्ही सीआय/सीडी बांधण्यासाठी आमची स्वतःची खास वर्कफ्लो युटिलिटी तयार करू - डॅप.

त्याचा सोर्स कोड रुबी, ओपन सोर्समध्ये लिहिलेला आहे आणि वर प्रकाशित केला आहे GitHub. दुर्दैवाने, दस्तऐवजीकरण सध्या साधनाचा सर्वात कमकुवत मुद्दा आहे, परंतु आम्ही त्यावर कार्य करत आहोत. आणि आम्ही डॅपबद्दल एकापेक्षा जास्त वेळा लिहू आणि बोलू, कारण... आम्ही संपूर्ण स्वारस्य असलेल्या समुदायासह त्याची क्षमता सामायिक करण्यासाठी प्रामाणिकपणे प्रतीक्षा करू शकत नाही, परंतु यादरम्यान, आपल्या समस्या पाठवा आणि विनंत्या पाठवा आणि/किंवा GitHub वर प्रकल्पाच्या विकासाचे अनुसरण करा.

13 ऑगस्ट 2019 रोजी अपडेट केले: सध्या एक प्रकल्प डॅप चे नाव बदलले werf, त्याचा कोड पूर्णपणे Go मध्ये पुन्हा लिहिला गेला आहे आणि त्याचे दस्तऐवजीकरण लक्षणीयरीत्या सुधारले गेले आहे.

कुबेरनेट्स

आणखी एक रेडीमेड ओपन सोर्स टूल ज्याला व्यावसायिक वातावरणात आधीच महत्त्वाची मान्यता मिळाली आहे कुबेरनेट्स, एक डॉकर व्यवस्थापन क्लस्टर. डॉकरवर तयार केलेल्या प्रकल्पांच्या ऑपरेशनमध्ये त्याचा वापर करण्याचा विषय अहवालाच्या व्याप्तीच्या पलीकडे आहे, म्हणून सादरीकरण काही मनोरंजक वैशिष्ट्यांच्या विहंगावलोकनपुरते मर्यादित आहे.

रोलआउटसाठी, Kubernetes ऑफर करते:

रेडिनेस प्रोब — ऍप्लिकेशनच्या नवीन आवृत्तीची तयारी तपासत आहे (त्यावर रहदारी स्विच करण्यासाठी);
रोलिंग अपडेट - कंटेनरच्या क्लस्टरमध्ये अनुक्रमिक प्रतिमा अद्यतन (शटडाउन, अपडेट, लॉन्चची तयारी, ट्रॅफिक स्विचिंग);
सिंक्रोनस अपडेट - क्लस्टरमध्ये भिन्न दृष्टिकोनासह प्रतिमा अद्यतनित करणे: प्रथम कंटेनरच्या अर्ध्या भागावर, नंतर उर्वरित;
कॅनरी रिलीझ - विसंगतींचे निरीक्षण करण्यासाठी मर्यादित (लहान) कंटेनरवर एक नवीन प्रतिमा लॉन्च करणे.

कंटिन्युअस डिलिव्हरी ही केवळ नवीन आवृत्तीचे प्रकाशन नसल्यामुळे, त्यानंतरच्या पायाभूत सुविधांच्या देखभालीसाठी कुबर्नेट्सकडे अनेक संधी आहेत: अंगभूत निरीक्षण आणि सर्व कंटेनरसाठी लॉगिंग, स्वयंचलित स्केलिंग इ. हे सर्व आधीच कार्यरत आहे आणि फक्त योग्यतेची वाट पाहत आहे. आपल्या प्रक्रियांमध्ये अंमलबजावणी.

अंतिम शिफारसी

डॉकर वापरा.
तुमच्या सर्व गरजांसाठी अॅप्लिकेशनच्या डॉकर प्रतिमा तयार करा.
"पायाभूत सुविधा हा कोड आहे" या तत्त्वाचे अनुसरण करा.
Git ला Docker ला लिंक करा.
रोलआउटच्या क्रमाचे नियमन करा.
तयार प्लॅटफॉर्म वापरा (कुबर्नेट्स किंवा दुसरा).

व्हिडिओ आणि स्लाइड्स

कामगिरीमधील व्हिडिओ (सुमारे एक तास) YouTube वर प्रकाशित (अहवाल स्वतःच 5 व्या मिनिटापासून सुरू होतो - या क्षणापासून प्ले करण्यासाठी दुव्याचे अनुसरण करा).

अहवालाचे सादरीकरण:

PS

आमच्या ब्लॉगवरील विषयावरील इतर अहवाल:

«werf - Kubernetes मधील CI/CD साठी आमचे साधन (विहंगावलोकन आणि व्हिडिओ अहवाल)» (दिमित्री स्टोल्यारोव्ह; 27 मे 2019 DevOpsConf येथे);
«डेटाबेस आणि कुबर्नेट्स» (दिमित्री स्टोल्यारोव्ह; 8 नोव्हेंबर, 2018 HighLoad++ वर);
«कुबर्नेट्स आणि गिटलॅबसह CI/CD सर्वोत्तम पद्धती» (दिमित्री स्टोल्यारोव्ह; 7 नोव्हेंबर, 2017 HighLoad++ वर);
«लहान प्रकल्पांमध्ये कुबर्नेट्ससोबतचा आमचा अनुभव» (दिमित्री स्टोल्यारोव्ह; रूटकॉन्फ येथे 6 जून 2017).

स्त्रोत: www.habr.com

डॉकरसह सतत वितरण पद्धती (पुनरावलोकन आणि व्हिडिओ)