चेल्याबिन्स्कमा साउथब्रिज र कुबेरनेटमा बिट्रिक्स

Sysadminka प्रणाली प्रशासक बैठकहरू चेल्याबिन्स्कमा भइरहेको छ, र अन्तिममा मैले Kubernetes मा 1C-Bitrix मा चलिरहेको अनुप्रयोगहरूको लागि हाम्रो समाधानको बारेमा रिपोर्ट दिएँ।

Bitrix, Kubernetes, Ceph - एक महान मिश्रण?

म तपाईलाई बताउनेछु कि हामी कसरी यी सबैबाट काम गर्ने समाधान सँगै राख्छौं।

चलो जानुहोस्!

भेटघाट अप्रिल १८ मा चेल्याबिन्स्कमा भएको थियो । तपाईले हाम्रो भेटघाटको बारेमा यहाँ पढ्न सक्नुहुन्छ टाइमप्याड र हेर्नुहोस् YouTube.

यदि तपाइँ हामीलाई रिपोर्ट वा श्रोताको रूपमा आउन चाहनुहुन्छ भने - स्वागत छ, लेख्नुहोस् [ईमेल सुरक्षित] र टेलिग्राम t.me/vadimisakanov मा।

मेरो रिपोर्ट

स्लाइड

समाधान "Bitrix in Kubernetes, संस्करण Southbridge 1.0"

म हाम्रो समाधानको बारेमा कुरा गर्नेछु "कुबर्नेट्समा डमीहरूका लागि" ढाँचामा, जसरी बैठकमा गरिएको थियो। तर म अनुमान गर्छु कि तपाईलाई Bitrix, Docker, Kubernetes, Ceph शब्दहरू कम्तिमा विकिपिडियामा लेखहरूको स्तरमा थाहा छ।

Kubernetes मा Bitrix को बारे मा के तयार छ?

Kubernetes मा Bitrix अनुप्रयोगहरूको सञ्चालनको बारेमा सम्पूर्ण इन्टरनेटमा धेरै कम जानकारी छ।
मैले यी सामग्रीहरू मात्र फेला पारे:

अलेक्जेन्डर सर्बुल, 1C-Bitrix, र Qsoft बाट एन्टोन Tuzlukov द्वारा रिपोर्ट:

म यसलाई सुन्न सिफारिस गर्दछु।

प्रयोगकर्ताबाट आफ्नै समाधान विकास गर्दै serkyron Habré मा.
थप भेटियो यस्तो निर्णय.

Aaand ... वास्तवमा, यो सबै हो।

म तपाईंलाई चेतावनी दिन्छु, हामीले माथिको लिङ्कहरूमा समाधानहरूको गुणस्तर जाँच गरेका छैनौं :)
खैर, हाम्रो समाधान तयार गर्दा, मैले अलेक्ज्याण्डर सर्बुलसँग कुरा गरें, त्यसपछि उनको रिपोर्ट अझै देखा परेको थिएन, त्यसैले मेरो स्लाइडमा एउटा वस्तु छ "Bitrix ले Kubernetes प्रयोग गर्दैन।"

तर डकरमा बिट्रिक्स चलाउनको लागि त्यहाँ पहिले नै धेरै तयार-निर्मित डकर छविहरू छन्: https://hub.docker.com/search?q=bitrix&type=image

के यो Kubernetes मा Bitrix को लागि पूर्ण समाधान सिर्जना गर्न पर्याप्त छ?
छैन। त्यहाँ धेरै समस्याहरू छन् जुन समाधान गर्न आवश्यक छ।

Kubernetes मा Bitrix संग समस्या के हो?

पहिलो, Dockerhub बाट तयार छविहरू Kubernetes को लागि उपयुक्त छैनन्

यदि हामी माइक्रोसर्भिसेस आर्किटेक्चर निर्माण गर्न चाहन्छौं (र Kubernetes मा हामी सामान्यतया गर्छौं), हामीले हाम्रो Kubernetes अनुप्रयोगलाई कन्टेनरहरूमा अलग गर्न आवश्यक छ र प्रत्येक कन्टेनरले एउटा सानो प्रकार्य प्रदर्शन गर्न आवश्यक छ (र यसलाई राम्रोसँग गर्नुहोस्)। एउटा मात्र किन ? छोटकरीमा, सरल र अधिक विश्वसनीय।
थप विशिष्ट हुनको लागि, यो लेख र भिडियो हेर्नुहोस्, कृपया: https://habr.com/ru/company/southbridge/blog/426637/

डकरहबमा डकर छविहरू मुख्यतया सबै-इन-वन सिद्धान्तमा बनाइएका छन्, त्यसैले हामीले अझै पनि आफ्नै बाइक बनाउनुपर्थ्यो र स्क्र्याचबाट छविहरू पनि सिर्जना गर्नुपर्‍यो।

दोस्रो - साइट कोड प्रशासक प्यानलबाट सम्पादन गरिएको छ

हामीले साइटमा नयाँ खण्ड सिर्जना गर्यौं - कोड अपडेट गरिएको थियो (नयाँ खण्डको नामको साथ डाइरेक्टरी थपिएको थियो)।

यदि तपाईंले प्रशासक प्यानलबाट कम्पोनेन्टको गुणहरू परिवर्तन गर्नुभयो भने, कोड परिवर्तन भयो।

Kubernetes "पूर्वनिर्धारित रूपमा" यससँग काम गर्न सक्दैन; कन्टेनरहरू राज्यविहीन हुनुपर्छ।

कारण: क्लस्टरमा प्रत्येक कन्टेनर (पोड) ले ट्राफिकको एक भाग मात्र प्रक्रिया गर्दछ। यदि तपाईंले एउटा मात्र कन्टेनर (पोड) मा कोड परिवर्तन गर्नुभयो भने, कोड फरक-फरक पोडहरूमा फरक हुनेछ, साइटले फरक तरिकाले काम गर्नेछ, र साइटको विभिन्न संस्करणहरू विभिन्न प्रयोगकर्ताहरूलाई देखाइनेछ। तिमी यसरी बाँच्न सक्दैनौ।

तेस्रो - तपाईले डिप्लोयमेन्टको साथ समस्या समाधान गर्न आवश्यक छ

यदि हामीसँग एक मोनोलिथ र एउटा "क्लासिक" सर्भर छ भने, सबै कुरा एकदम सरल छ: हामी नयाँ कोड आधार तैनाथ गर्छौं, डाटाबेस माइग्रेट गर्छौं, ट्राफिकलाई कोडको नयाँ संस्करणमा स्विच गर्छौं। स्विच तुरुन्तै हुन्छ।
यदि हामीसँग Kubernetes मा एक साइट छ, microservices मा काटियो, त्यहाँ कोड संग धेरै कन्टेनर छन् - ओह। तपाईंले कोडको नयाँ संस्करणको साथ कन्टेनरहरू सङ्कलन गर्न आवश्यक छ, पुरानोको सट्टा तिनीहरूलाई रोल आउट गर्नुहोस्, डाटाबेसलाई सही रूपमा माइग्रेट गर्नुहोस्, र आदर्श रूपमा यो आगन्तुकहरूद्वारा ध्यान नदिइयोस्। सौभाग्यवश, Kubernetes ले हामीलाई विभिन्न प्रकारका परिनियोजनहरूको सम्पूर्ण गुच्छालाई समर्थन गर्दै यसमा मद्दत गर्दछ।

चौथो - तपाईले स्ट्याटिक्स भण्डारण गर्ने समस्या समाधान गर्न आवश्यक छ

यदि तपाइँको साइट "केवल" 10 गीगाबाइट हो र तपाइँ यसलाई पूर्ण रूपमा कन्टेनरहरूमा डिप्लोय गर्नुहुन्छ भने, तपाइँ 10 गीगाबाइट कन्टेनरहरूको साथ समाप्त हुनुहुनेछ जुन सँधै डिप्लोय गर्न लिन्छ।
तपाईंले कन्टेनरहरू बाहिर साइटको "सबैभन्दा भारी" भागहरू भण्डारण गर्न आवश्यक छ, र यो कसरी सही तरिकाले गर्ने भन्ने प्रश्न उठ्छ।

हाम्रो समाधानबाट के छुटेको छ?

सम्पूर्ण Bitrix कोड microfunctions/microservices मा विभाजित छैन (ताकि दर्ता अलग छ, अनलाइन स्टोर मोड्युल अलग छ, आदि)। हामी प्रत्येक कन्टेनरमा सम्पूर्ण कोड आधार भण्डार गर्छौं।

हामी Kubernetes मा डाटाबेस पनि भण्डार गर्दैनौं (मैले अझै पनि विकास वातावरणको लागि Kubernetes मा डाटाबेसको साथ समाधानहरू कार्यान्वयन गरें, तर उत्पादनको लागि होइन)।

यो अझै पनि साइट प्रशासकहरूलाई ध्यान दिनेछ कि साइट Kubernetes मा चल्छ। "प्रणाली जाँच" प्रकार्यले सही रूपमा काम गर्दैन; प्रशासक प्यानलबाट साइट कोड सम्पादन गर्न, तपाईंले पहिले "म कोड सम्पादन गर्न चाहन्छु" बटन क्लिक गर्नुपर्छ।

समस्याहरू पहिचान गरिएको छ, माइक्रोसर्भिसेसहरू लागू गर्ने आवश्यकता निर्धारण गरिएको छ, लक्ष्य स्पष्ट छ - Kubernetes मा Bitrix मा अनुप्रयोगहरू चलाउनको लागि कार्य प्रणाली प्राप्त गर्न, Bitrix को क्षमताहरू र Kubernetes को फाइदाहरू दुवै संरक्षण गर्दै। कार्यान्वयन सुरु गरौं।

वास्तुकला

वेब सर्भर (कामदारहरू) सँग धेरै "काम गर्ने" पोडहरू छन्।
क्रोन कार्यहरूको साथमा एक (केवल एक आवश्यक छ)।
प्रशासक प्यानलबाट साइट कोड सम्पादन गर्नको लागि एक अपग्रेड (केवल एक मात्र आवश्यक छ)।

हामी प्रश्नहरू समाधान गर्छौं:

• सत्रहरू कहाँ भण्डार गर्ने?
• क्यास कहाँ भण्डारण गर्ने?
• स्ट्याटिक्स कहाँ भण्डार गर्ने, कन्टेनरको गुच्छामा गीगाबाइट स्टेटिक्स राख्नु हुँदैन?
• डाटाबेसले कसरी काम गर्नेछ?

डकर छवि

हामी डकर छवि निर्माण गरेर सुरु गर्छौं।

आदर्श विकल्प यो हो कि हामीसँग एउटा सार्वभौमिक छवि छ, यसको आधारमा हामीले कार्यकर्ता पोडहरू, क्रन्टास्कहरूका साथ पोडहरू, र पोडहरू अपग्रेड गर्छौं।

हामीले एउटा यस्तो छवि बनायौं.

यसमा nginx, apache/php-fpm (निर्माणको क्रममा चयन गर्न सकिन्छ), मेल पठाउनको लागि msmtp, र क्रोन समावेश छ।

छवि संयोजन गर्दा, साइटको सम्पूर्ण कोड आधार / एप डाइरेक्टरीमा प्रतिलिपि गरिन्छ (ती भागहरू बाहेक जुन हामी छुट्टै साझा भण्डारणमा जानेछौं)।

लघु सेवाहरू, सेवाहरू

कामदार पोड:

• nginx + कन्टेनर apache/php-fpm + msmtp भएको कन्टेनर
• यसले msmtp लाई छुट्टै माइक्रोसर्भिसमा सार्न काम गरेन, Bitrix ले सिधै मेल पठाउन सक्दैन भनेर क्रोधित हुन थालेको छ।
• प्रत्येक कन्टेनरमा पूर्ण कोडबेस हुन्छ।
• कन्टेनरहरूमा कोड परिवर्तन गर्न निषेध।

क्रोन अन्तर्गत:

• apache, php, cron संग कन्टेनर
• पूर्ण कोड आधार समावेश
• कन्टेनरहरूमा कोड परिवर्तन गर्न प्रतिबन्ध

अन्तर्गत अपग्रेड गर्नुहोस्:

• nginx कन्टेनर + apache/php-fpm कन्टेनर + msmtp
• कन्टेनरहरूमा कोड परिवर्तन गर्न कुनै निषेध छैन

सत्र भण्डारण

Bitrix क्यास भण्डारण

अर्को महत्त्वपूर्ण कुरा: हामी सबै कुरामा जडान गर्नको लागि पासवर्डहरू भण्डार गर्छौं, डाटाबेसदेखि मेलसम्म, kubernetes रहस्यहरूमा। हामीले एक बोनस पाउँछौं: पासवर्डहरू ती व्यक्तिहरूलाई मात्र देखिन्छन् जसलाई हामीले गोप्यहरूमा पहुँच दिन्छौं, र परियोजनाको कोड आधारमा पहुँच भएका सबैलाई होइन।

स्ट्याटिक्सको लागि भण्डारण

तपाईं केहि पनि प्रयोग गर्न सक्नुहुन्छ: ceph, nfs (तर हामी उत्पादनको लागि nfs सिफारिस गर्दैनौं), क्लाउड प्रदायकहरूबाट नेटवर्क भण्डारण, आदि।

भण्डारणलाई कन्टेनरहरूमा साइटको /upload/ डाइरेक्टरी र स्थिर सामग्री भएका अन्य निर्देशिकाहरूमा जडान गर्न आवश्यक हुनेछ।

डाटाबेस

सरलताको लागि, हामी डाटाबेसलाई Kubernetes बाहिर सार्न सिफारिस गर्छौं। Kubernetes मा आधार एक अलग जटिल कार्य हो; यसले योजनालाई परिमाणको अर्डर थप जटिल बनाउनेछ।

सत्र भण्डारण

हामी memcached प्रयोग गर्छौं :)

यसले सत्र भण्डारण राम्रोसँग ह्यान्डल गर्छ, क्लस्टर गरिएको छ, र php मा session.save_path को रूपमा "नेटिभ रूपमा" समर्थित छ। यस्तो प्रणाली क्लासिकल मोनोलिथिक वास्तुकलामा धेरै पटक परीक्षण गरिएको छ, जब हामीले ठूलो संख्यामा वेब सर्भरहरूसँग क्लस्टरहरू बनायौं। परिनियोजनको लागि हामी हेल्म प्रयोग गर्छौं।

$ helm install stable/memcached --name session

php.ini - यहाँ छविले memcached मा सत्रहरू भण्डारण गर्न सेटिङहरू समावेश गर्दछ

हामीले मेमक्याच भएका होस्टहरूको बारेमा डेटा पास गर्न वातावरणीय चरहरू प्रयोग गर्यौं https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
यसले तपाईंलाई डेभ, स्टेज, परीक्षण, प्रोड वातावरणमा एउटै कोड प्रयोग गर्न अनुमति दिन्छ (तिनीहरूमा मेमक्याच गरिएका होस्ट नामहरू फरक हुनेछन्, त्यसैले हामीले प्रत्येक वातावरणमा सत्रहरूको लागि एक अद्वितीय होस्ट नाम पास गर्नुपर्छ)।
Bitrix क्यास भण्डारण

हामीलाई दोष-सहिष्णु भण्डारण चाहिन्छ जुन सबै पोडहरूले लेख्न र पढ्न सक्छन्।

हामी memcached पनि प्रयोग गर्छौं।
यो समाधान Bitrix द्वारा सिफारिस गरिएको छ।

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php - यहाँ Bitrix मा यो निर्दिष्ट गरिएको छ जहाँ क्यास भण्डार गरिएको छ।

हामी वातावरणीय चरहरू पनि प्रयोग गर्छौं।

क्रन्टास्की

Kubernetes मा Crontasks चलाउन विभिन्न दृष्टिकोणहरू छन्।

• Crontasks चलाउनको लागि पोडको साथ छुट्टै डिप्लोइमेन्ट
• cronjob क्रोनटास्कहरू कार्यान्वयन गर्नका लागि (यदि यो वेब एप हो - wget सँग https://$host$cronjobname, वा kubectl exec कार्यकर्ता पोडहरू मध्ये एक भित्र, आदि)
• आदि

तपाईं सबैभन्दा सही बारे बहस गर्न सक्नुहुन्छ, तर यस अवस्थामा हामीले "Crontasks को लागि pods संग अलग तैनाती" विकल्प रोज्यौं।

यो कसरी गरिन्छ:

• ConfigMap मार्फत वा config/addcron फाइल मार्फत क्रोन कार्यहरू थप्नुहोस्
• एउटा उदाहरणमा हामी कार्यकर्ता पोडसँग मिल्दोजुल्दो कन्टेनर सुरु गर्छौं + यसमा क्राउन कार्यहरू कार्यान्वयन गर्न अनुमति दिन्छ।
• एउटै कोड आधार प्रयोग गरिन्छ, एकीकरण को लागी धन्यवाद, कन्टेनर विधानसभा सरल छ

हामीले के राम्रो पाउँछौं:

• हामीसँग विकासकर्ताहरूको वातावरण (डकर) सँग मिल्दोजुल्दो वातावरणमा क्रोनटास्कहरू काम गरिरहेका छौं।
• क्रोनटास्कहरू Kubernetes को लागि "पुनः लेख्न" आवश्यक छैन, तिनीहरू उही फारममा र पहिले जस्तै कोड आधारमा काम गर्छन्
• क्रोन कार्यहरू सबै टोली सदस्यहरूद्वारा उत्पादन शाखामा प्रतिबद्ध अधिकारहरू थप्न सकिन्छ, प्रशासकहरू मात्र होइन

साउथब्रिज K8SD डिप्लोय मोड्युल र प्रशासक प्यानलबाट कोड सम्पादन

हामी अन्तर्गत अपग्रेडको बारेमा कुरा गर्दै थियौं?
त्यहाँ ट्राफिक कसरी निर्देशित गर्ने?
हुर्रे, हामीले PHP मा यसको लागि एउटा मोड्युल लेख्यौं :) यो Bitrix को लागि सानो क्लासिक मोड्युल हो। यो अझै सार्वजनिक रूपमा उपलब्ध छैन, तर हामी यसलाई खोल्ने योजना बनाउँछौं।
मोड्युल Bitrix मा एक नियमित मोड्युल जस्तै स्थापित छ:

र यो यस्तो देखिन्छ:

यसले तपाइँलाई कुकी सेट गर्न अनुमति दिन्छ जसले साइट प्रशासकलाई पहिचान गर्दछ र Kubernetes लाई अपग्रेड पोडमा ट्राफिक पठाउन अनुमति दिन्छ।

परिवर्तनहरू पूरा भएपछि, तपाईंले git push मा क्लिक गर्न आवश्यक छ, कोड परिवर्तनहरू git मा पठाइनेछ, त्यसपछि प्रणालीले कोडको नयाँ संस्करणको साथ छवि निर्माण गर्नेछ र यसलाई क्लस्टरमा "रोल आउट" गर्नेछ, पुरानो पोडहरू बदलेर। ।

हो, यो एक क्रचको एक बिट हो, तर एकै समयमा हामी माइक्रोसर्भिस आर्किटेक्चर कायम राख्छौं र Bitrix प्रयोगकर्ताहरूबाट प्रशासक प्यानलबाट कोड सच्याउनको लागि मनपर्ने अवसरहरू हटाउँदैनौं। अन्तमा, यो एक विकल्प हो; तपाईं फरक तरिकामा कोड सम्पादन गर्ने समस्या समाधान गर्न सक्नुहुन्छ।

हेलम चार्ट

Kubernetes मा अनुप्रयोगहरू निर्माण गर्न, हामी सामान्यतया हेल्म प्याकेज प्रबन्धक प्रयोग गर्छौं।
Kubernetes मा हाम्रो Bitrix समाधान को लागी, Sergey Bondarev, हाम्रो अग्रणी प्रणाली प्रशासक, एक विशेष हेल्म चार्ट लेखे।

यसले कार्यकर्ता, अपग्रेड, क्रोन पोडहरू, कन्फिगरहरू, सेवाहरू, र कुबर्नेट्स रहस्यहरूबाट पोडहरूमा चरहरू स्थानान्तरण गर्दछ।

हामी कोड Gitlab मा भण्डारण गर्छौं, र हामी Gitlab बाट हेल्म बिल्ड पनि चलाउँछौं।

छोटकरीमा, यो यस्तो देखिन्छ

$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production

हेल्मले तपाईंलाई "सिमलेस" रोलब्याक गर्न अनुमति दिन्छ यदि डिप्लोइमेन्टको क्रममा अचानक केहि गलत भयो भने। यो राम्रो छ जब तपाईं आतंकमा हुनुहुन्न "एफटीपी मार्फत कोड फिक्स गर्नुहोस् किनभने प्रोड घट्यो," तर कुबर्नेट्सले स्वचालित रूपमा र डाउनटाइम बिना नै गर्छ।

तैनाथ गर्नुहोस्

हो, हामी Gitlab र Gitlab CI को प्रशंसक हौं, हामी यसलाई प्रयोग गर्छौं :)
Gitlab मा प्रोजेक्ट रिपोजिटरीमा कमिट गर्दा, Gitlab ले पाइपलाइन सुरु गर्छ जसले वातावरणको नयाँ संस्करण तैनाथ गर्दछ।

चरणहरू:

• निर्माण (नयाँ डकर छवि निर्माण गर्दै)
• परीक्षण (परीक्षण)
• सफा गर्नुहोस् (परीक्षण वातावरण हटाउँदै)
• पुश (हामी यसलाई डकर रजिस्ट्रीमा पठाउँछौं)
• deploy (हामी हेल्म मार्फत Kubernetes मा अनुप्रयोग तैनात गर्छौं)।

हुर्रे, यो तयार छ, यसलाई कार्यान्वयन गरौं!
ठीक छ, वा कुनै प्रश्नहरू सोध्नुहोस्।

त्यसोभए हामीले के गर्यौं

प्राविधिक दृष्टिकोणबाट:

• डकराइज्ड बिट्रिक्स;
• बिटिक्सलाई कन्टेनरहरूमा "कट" गर्नुहोस्, जसमध्ये प्रत्येकले न्यूनतम कार्यहरू गर्दछ;
• कन्टेनरहरूको राज्यविहीन अवस्था प्राप्त भयो;
• Kubernetes मा Bitrix अद्यावधिक संग समस्या समाधान;
• सबै Bitrix प्रकार्यहरूले काम गर्न जारी राख्यो (लगभग सबै);
• हामीले Kubernetes मा परिनियोजन र संस्करणहरू बीच रोलब्याकमा काम गर्यौं।

व्यापारिक दृष्टिकोणबाट:

• दोष सहिष्णुता;
• Kubernetes उपकरणहरू (Gitlab CI को साथ सजिलो एकीकरण, सिमलेस डिप्लोइमेन्ट, आदि);
• गोप्य पासवर्डहरू (पासवर्डहरूमा प्रत्यक्ष पहुँच प्रदान गर्नेहरूलाई मात्र दृश्यात्मक);
• यो एकल पूर्वाधार भित्र अतिरिक्त वातावरण (विकास, परीक्षण, आदि को लागी) सिर्जना गर्न सुविधाजनक छ।

स्रोत: www.habr.com