სამხრეთ ხიდი ჩელიაბინსკში და ბიტრიქსი კუბერნეტესში

Sysadminka-ს სისტემის ადმინისტრატორის შეხვედრები მიმდინარეობს ჩელიაბინსკში და ბოლოს მე მივეცი მოხსენება კუბერნეტში 1C-Bitrix-ზე აპლიკაციების გაშვების ჩვენი გადაწყვეტის შესახებ.

Bitrix, Kubernetes, Ceph - შესანიშნავი ნარევი?

მე გეტყვით, როგორ შევკრიბეთ სამუშაო გამოსავალი ამ ყველაფრისგან.

მოდით წავიდეთ!

შეხვედრა 18 აპრილს ჩელიაბინსკში გაიმართა. ჩვენი შეხვედრების შესახებ შეგიძლიათ წაიკითხოთ აქ დროის პანელი და დააკვირდი YouTube.

თუ გსურთ მობრძანდეთ ჩვენთან რეპორტაჟით ან მსმენელად - მოგესალმებით, მოგვწერეთ [ელ.ფოსტით დაცულია] და Telegram-ზე t.me/vadimisakanov.

ჩემი ანგარიში

სლაიდები

გადაწყვეტა "Bitrix in Kubernetes, ვერსია Southbridge 1.0"

მე ვისაუბრებ ჩვენს გადაწყვეტაზე „კუბერნეტის დუმებისთვის“ ფორმატში, როგორც ეს გაკეთდა შეხვედრაზე. მაგრამ ვვარაუდობ, რომ თქვენ იცით სიტყვები Bitrix, Docker, Kubernetes, Ceph, ყოველ შემთხვევაში, ვიკიპედიის სტატიების დონეზე.

რა არის მზა Bitrix-ის შესახებ Kubernetes-ში?

მთელ ინტერნეტში ძალიან ცოტა ინფორმაციაა Kubernetes-ში Bitrix აპლიკაციების მუშაობის შესახებ.
მე მხოლოდ ეს მასალები ვიპოვე:

ალექსანდრე სერბულის, 1C-Bitrix-ის და ანტონ ტუზლუკოვის მოხსენება Qsoft-დან:

გირჩევთ მოუსმინოთ.

მომხმარებლისგან საკუთარი გადაწყვეტის შემუშავება სერკიონი ჰაბრეზე.
იპოვა მეტი ასეთი გადაწყვეტილება.

ააა და... სინამდვილეში სულ ესაა.

გაფრთხილებთ, ჩვენ არ შევამოწმეთ გადაწყვეტილებების ხარისხი ზემოთ მოცემულ ბმულებზე :)
სხვათა შორის, ჩვენი გადაწყვეტის მომზადებისას, მე ვესაუბრე ალექსანდრე სერბულს, მაშინ მისი მოხსენება ჯერ არ გამოჩნდა, ამიტომ ჩემს სლაიდებში არის პუნქტი "Bitrix არ იყენებს Kubernetes".

მაგრამ უკვე არსებობს უამრავი მზა Docker სურათი Docker-ში Bitrix-ის გასაშვებად: https://hub.docker.com/search?q=bitrix&type=image

არის ეს საკმარისი იმისათვის, რომ შეიქმნას სრული გადაწყვეტა Bitrix-ისთვის Kubernetes-ში?
არა. არის უამრავი პრობლემა, რომელიც უნდა გადაიჭრას.

რა პრობლემები აქვს Bitrix-ს Kubernetes-ში?

ჯერ ერთი, Dockerhub-ის მზა სურათები არ არის შესაფერისი Kubernetes-ისთვის

თუ გვინდა ავაშენოთ მიკროსერვისების არქიტექტურა (და Kubernetes-ში ჩვენ ჩვეულებრივ ვაკეთებთ), ჩვენ უნდა გამოვყოთ ჩვენი Kubernetes აპლიკაცია კონტეინერებად და თითოეულმა კონტეინერმა შეასრულოს ერთი პატარა ფუნქცია (და კარგად გააკეთოს). რატომ მხოლოდ ერთი? მოკლედ, რაც უფრო მარტივია მით უფრო საიმედო.
უფრო კონკრეტულად რომ ვთქვათ, უყურეთ ამ სტატიას და ვიდეოს, გთხოვთ: https://habr.com/ru/company/southbridge/blog/426637/

Docker-ის სურათები Dockerhub-ში ძირითადად აგებულია All-in-one პრინციპზე, ამიტომ მაინც მოგვიწია საკუთარი ველოსიპედის დამზადება და სურათების შექმნაც კი ნულიდან.

მეორე - საიტის კოდი რედაქტირდება ადმინისტრატორის პანელიდან

საიტზე შევქმენით ახალი განყოფილება - განახლდა კოდი (დამატებულია დირექტორია ახალი განყოფილების სახელწოდებით).

თუ თქვენ შეცვალეთ კომპონენტის თვისებები ადმინისტრატორის პანელიდან, კოდი შეიცვალა.

Kubernetes "ნაგულისხმევად" ვერ მუშაობს ამით; კონტეინერები უნდა იყოს მოქალაქეობის არმქონე.

მიზეზი: კლასტერში თითოეული კონტეინერი (პოდი) ამუშავებს ტრაფიკის მხოლოდ ნაწილს. თუ თქვენ შეცვლით კოდს მხოლოდ ერთ კონტეინერში (pod), მაშინ კოდი განსხვავებული იქნება სხვადასხვა პოდებში, საიტი განსხვავებულად იმუშავებს და საიტის სხვადასხვა ვერსია გამოჩნდება სხვადასხვა მომხმარებლისთვის. ასე ცხოვრება არ შეიძლება.

მესამე - თქვენ უნდა მოაგვაროთ საკითხი განლაგებით

თუ ჩვენ გვაქვს მონოლითური და ერთი "კლასიკური" სერვერი, ყველაფერი საკმაოდ მარტივია: ჩვენ ვაყენებთ ახალ კოდის ბაზას, გადავიტანთ მონაცემთა ბაზას, გადავრთავთ ტრაფიკს კოდის ახალ ვერსიაზე. გადართვა ხდება მყისიერად.
თუ ჩვენ გვაქვს საიტი Kubernetes-ში, მოჭრილი მიკროსერვისებში, უამრავი კონტეინერია კოდით - ოჰ. თქვენ უნდა შეაგროვოთ კონტეინერები კოდის ახალი ვერსიით, გააფართოვოთ ისინი ძველის ნაცვლად, სწორად გადაიტანოთ მონაცემთა ბაზა და იდეალურად გააკეთოთ ეს ვიზიტორებისთვის შეუმჩნეველი. საბედნიეროდ, Kubernetes გვეხმარება ამაში, რომელიც მხარს უჭერს სხვადასხვა ტიპის განლაგების მთელ ჯგუფს.

მეოთხე - თქვენ უნდა მოაგვაროთ სტატიკის შენახვის საკითხი

თუ თქვენი საიტი არის "მხოლოდ" 10 გიგაბაიტი და თქვენ განათავსებთ მას მთლიანად კონტეინერებში, თქვენ მიიღებთ 10 გიგაბაიტიან კონტეინერებს, რომელთა განლაგება სამუდამოდ დაგჭირდებათ.
თქვენ უნდა შეინახოთ საიტის "უმძიმესი" ნაწილები კონტეინერების გარეთ და ჩნდება კითხვა, თუ როგორ უნდა გააკეთოთ ეს სწორად

რა აკლია ჩვენს გადაწყვეტას?

მთელი Bitrix კოდი არ იყოფა მიკროფუნქციებად/მიკროსერვისებად (ისე რომ რეგისტრაცია ცალკე იყოს, ონლაინ მაღაზიის მოდული ცალკე და ა.შ.). ჩვენ ვინახავთ კოდის მთელ ბაზას თითოეულ კონტეინერში.

ჩვენ ასევე არ ვინახავთ მონაცემთა ბაზას Kubernetes-ში (მე მაინც განვახორციელე გადაწყვეტილებები მონაცემთა ბაზებით Kubernetes-ში განვითარების გარემოებისთვის, მაგრამ არა წარმოებისთვის).

საიტის ადმინისტრატორებისთვის მაინც შესამჩნევი იქნება, რომ საიტი მუშაობს Kubernetes-ზე. "სისტემის შემოწმების" ფუნქცია არ მუშაობს სწორად; საიტის კოდის ადმინისტრაციული პანელიდან შესაცვლელად, ჯერ უნდა დააჭიროთ ღილაკს "მე მინდა კოდის რედაქტირება".

იდენტიფიცირებულია პრობლემები, დადგინდა მიკროსერვისების დანერგვის აუცილებლობა, მიზანი ნათელია - მივიღოთ კუბერნეტში Bitrix-ზე აპლიკაციების გაშვების სამუშაო სისტემა, შენარჩუნებული როგორც Bitrix-ის შესაძლებლობები, ასევე Kubernetes-ის უპირატესობები. დავიწყოთ განხორციელება.

არქიტექტურა

ვებ სერვერთან (მუშაკებით) არის ბევრი „მუშა“ პოდი.
ერთი ქვეშ cron ამოცანებით (საჭიროა მხოლოდ ერთი).
ერთი განახლება საიტის კოდის ადმინისტრატორის პანელიდან რედაქტირებისთვის (ასევე საჭიროა მხოლოდ ერთი).

ჩვენ ვხსნით კითხვებს:

• სად შეინახოთ სესიები?
• სად შევინახოთ ქეში?
• სად შევინახოთ სტატიკა, არ მოვათავსოთ გიგაბაიტი სტატიკა კონტეინერების თაიგულში?
• როგორ იმუშავებს მონაცემთა ბაზა?

დოკერის სურათი

ჩვენ ვიწყებთ Docker სურათის შექმნით.

იდეალური ვარიანტია, რომ ჩვენ გვქონდეს ერთი უნივერსალური გამოსახულება, მის საფუძველზე ვიღებთ მუშა პოდებს, პოდებს Crontasks-ით და განახლებულ პოდებს.

სწორედ ასეთი სურათი გავაკეთეთ.

მასში შედის nginx, apache/php-fpm (შეიძლება შეირჩეს აშენების დროს), msmtp ფოსტის გასაგზავნად და cron.

სურათის აწყობისას საიტის მთელი კოდის ბაზა კოპირდება /app დირექტორიაში (იმ ნაწილების გამოკლებით, რომლებსაც გადავიტანთ ცალკე საზიარო საცავში).

მიკროსერვისები, სერვისები

მუშათა ბოთლები:

• კონტეინერი nginx + კონტეინერი apache/php-fpm + msmtp
• არ გამოვიდა msmtp-ის ცალკე მიკროსერვისში გადატანა, Bitrix იწყებს აღშფოთებას, რომ მას არ შეუძლია პირდაპირ ფოსტის გაგზავნა
• თითოეულ კონტეინერს აქვს სრული კოდის ბაზა.
• კონტეინერებში კოდის შეცვლის აკრძალვა.

cron ქვეშ:

• კონტეინერი apache, php, cron
• კოდის სრული ბაზა შედის
• კონტეინერებში კოდის შეცვლის აკრძალვა

განახლება ქვეშ:

• nginx კონტეინერი + apache/php-fpm კონტეინერი + msmtp
• კონტეინერებში კოდის შეცვლა არ არის აკრძალული

სესიის შენახვა

Bitrix ქეში შენახვა

კიდევ ერთი მნიშვნელოვანი რამ: ჩვენ ვინახავთ პაროლებს ყველაფერთან დასაკავშირებლად, მონაცემთა ბაზიდან ფოსტამდე, კუბერნეტის საიდუმლოებებში. ჩვენ ვიღებთ ბონუსს: პაროლები ხილულია მხოლოდ მათთვის, ვისაც ჩვენ ვაძლევთ წვდომას საიდუმლოებაზე და არა ყველას, ვისაც აქვს წვდომა პროექტის კოდის ბაზაზე.

შენახვა სტატიკისთვის

თქვენ შეგიძლიათ გამოიყენოთ ყველაფერი: ceph, nfs (მაგრამ ჩვენ არ გირჩევთ nfs-ს წარმოებისთვის), ქსელის შენახვა ღრუბლის პროვაიდერებისგან და ა.შ.

საცავი უნდა იყოს დაკავშირებული კონტეინერებში საიტის /upload/ დირექტორიასთან და სტატიკური შინაარსის სხვა დირექტორიებთან.

Მონაცემთა ბაზა

სიმარტივისთვის, ჩვენ გირჩევთ მონაცემთა ბაზის გადატანას Kubernetes-ის გარეთ. კუბერნეტის ბაზა ცალკე რთული ამოცანაა; ეს სქემას მასშტაბების რიგით უფრო რთულს გახდის.

სესიის შენახვა

ჩვენ ვიყენებთ memcached-ს :)

ის კარგად ამუშავებს სესიების შენახვას, არის კლასტერირებული და მხარდაჭერილია „ძირითადად“ როგორც session.save_path php-ში. ასეთი სისტემა არაერთხელ იქნა გამოცდილი კლასიკურ მონოლითურ არქიტექტურაში, როდესაც ჩვენ ვაშენეთ კლასტერები დიდი რაოდენობით ვებ სერვერებით. განლაგებისთვის ჩვენ ვიყენებთ საჭეს.

$ helm install stable/memcached --name session

php.ini - აქ სურათი შეიცავს პარამეტრებს memcached-ში სესიების შესანახად

ჩვენ გამოვიყენეთ Environment Variables ჰოსტების შესახებ მონაცემების გადასაცემად memcached-ით https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
ეს გაძლევთ საშუალებას გამოიყენოთ იგივე კოდი dev, stage, test, prod გარემოში (მათში მემქეშირებული ჰოსტის სახელები განსხვავებული იქნება, ამიტომ თითოეულ გარემოს სესიებისთვის უნიკალური ჰოსტის სახელი უნდა გადავცეთ).
Bitrix ქეში შენახვა

ჩვენ გვჭირდება შეცდომის ტოლერანტული საცავი, რომელზედაც ყველა პოდს შეუძლია ჩაწეროს და წაიკითხოს.

ჩვენ ასევე ვიყენებთ memcached-ს.
ეს გამოსავალი რეკომენდირებულია თავად ბიტრიქსის მიერ.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php - აქ Bitrix-ში მითითებულია სად ინახება ქეში

ჩვენ ასევე ვიყენებთ გარემოს ცვლადებს.

კრონტასკი

კუბერნეტში Crontasks-ის გაშვების სხვადასხვა მიდგომა არსებობს.

• ცალკე განლაგება პოდთან ერთად Crontasks-ის გასაშვებად
• cronjob crontasks-ის შესასრულებლად (თუ ეს არის ვებ აპლიკაცია - wget-ით https://$host$cronjobname, ან kubectl exec ერთ-ერთი მუშა პოდში და ა.შ.)
• ა.შ.

თქვენ შეგიძლიათ იკამათოთ ყველაზე სწორზე, მაგრამ ამ შემთხვევაში ჩვენ ავირჩიეთ ვარიანტი "ცალკე განლაგება კრონტასკებისთვის პოდებით"

როგორ გავაკეთოთ ეს:

• დაამატეთ cron ამოცანები ConfigMap-ის ან config/addcron ფაილის მეშვეობით
• ერთ შემთხვევაში ჩვენ გავუშვით კონტეინერი, რომელიც იდენტურია მუშა პოდზე + საშუალებას გაძლევთ შეასრულოთ მასში გვირგვინის ამოცანები
• გამოიყენება იგივე კოდის ბაზა, გაერთიანების წყალობით, კონტეინერის შეკრება მარტივია

რა კარგს მივიღებთ:

• ჩვენ გვაქვს სამუშაო Crontasks დეველოპერების გარემოს იდენტურ გარემოში (დოკერი)
• Crontasks-ს არ სჭირდება Kubernetes-ისთვის „გადაწერა“, ისინი მუშაობენ იმავე ფორმით და კოდის იმავე ბაზაში, როგორც ადრე.
• cron ამოცანები შეიძლება დაემატოს გუნდის ყველა წევრს, რომლებსაც აქვთ უფლებამოსილება წარმოების ფილიალში, და არა მხოლოდ ადმინისტრატორები

Southbridge K8SDeploy მოდული და კოდის რედაქტირება ადმინისტრატორის პანელიდან

განახლებაზე ვსაუბრობდით?
როგორ მივმართოთ მოძრაობა იქ?
რა, ჩვენ დავწერეთ მოდული ამისათვის PHP-ში :) ეს არის პატარა კლასიკური მოდული Bitrix-ისთვის. ის ჯერ არ არის საჯაროდ ხელმისაწვდომი, მაგრამ ჩვენ ვგეგმავთ მის გახსნას.
მოდული დაინსტალირებულია Bitrix-ში ჩვეულებრივი მოდულის მსგავსად:

და ასე გამოიყურება:

ის საშუალებას გაძლევთ დააყენოთ ქუქი-ფაილი, რომელიც განსაზღვრავს საიტის ადმინისტრატორს და საშუალებას აძლევს Kubernetes-ს გააგზავნოს ტრაფიკი განახლების პოდში.

ცვლილებების დასრულების შემდეგ, თქვენ უნდა დააჭიროთ git push-ს, კოდის ცვლილებები გაიგზავნება git-ზე, შემდეგ სისტემა ააშენებს სურათს კოდის ახალი ვერსიით და „გააფართოვებს“ მას კლასტერში, ჩაანაცვლებს ძველ პოდებს. .

დიახ, ეს ცოტა ყავარჯენია, მაგრამ ამავდროულად ჩვენ ვინარჩუნებთ მიკროსერვისის არქიტექტურას და არ ვკარგავთ Bitrix-ის მომხმარებლებს საყვარელ შესაძლებლობას, შეასწორონ კოდი ადმინისტრაციული პანელიდან. საბოლოო ჯამში, ეს არის ვარიანტი; თქვენ შეგიძლიათ გადაჭრათ კოდის რედაქტირების პრობლემა სხვა გზით.

ჩაფხუტის სქემა

Kubernetes-ზე აპლიკაციების შესაქმნელად, ჩვენ ჩვეულებრივ ვიყენებთ Helm პაკეტის მენეჯერს.
ჩვენი Bitrix გადაწყვეტისთვის Kubernetes-ში, სერგეი ბონდარევმა, ჩვენმა წამყვანმა სისტემის ადმინისტრატორმა, დაწერა სპეციალური Helm სქემა.

ის აშენებს worker, ugrade, cron pods, აკონფიგურირებს ingresses, სერვისებს და გადასცემს ცვლადებს Kubernetes საიდუმლოებიდან pods-ში.

ჩვენ ვინახავთ კოდს Gitlab-ში და ასევე ვმართავთ Helm build-ს Gitlab-დან.

მოკლედ, ასე გამოიყურება

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

Helm ასევე საშუალებას გაძლევთ გააკეთოთ "უწყვეტი" უკან დაბრუნება, თუ მოულოდნელად რაიმე არასწორია განლაგების დროს. კარგია, როცა პანიკაში არ ხარ „კოდის შესწორება ftp-ის საშუალებით, რადგან პროდი დაეცა“, მაგრამ Kubernetes აკეთებს ამას ავტომატურად და შეფერხების გარეშე.

განლაგება

დიახ, ჩვენ ვართ Gitlab & Gitlab CI-ის თაყვანისმცემლები, ვიყენებთ მას :)
Gitlab-ში პროექტის საცავში ჩართვისას, Gitlab უშვებს მილსადენს, რომელიც განათავსებს გარემოს ახალ ვერსიას.

ეტაპები:

• build (ახალი Docker სურათის შექმნა)
• ტესტი (ტესტირება)
• გასუფთავება (სატესტო გარემოს ამოღება)
• Push (ჩვენ მას Docker-ის რეესტრში ვუგზავნით)
• განათავსეთ (აპლიკაციას კუბერნეტსში ვაყენებთ Helm-ის საშუალებით).

ჰური, მზადაა, განვახორციელოთ!
კარგად, ან დასვით კითხვები, თუ არსებობს.

მერე რა გავაკეთეთ

ტექნიკური თვალსაზრისით:

• Dockerized Bitrix;
• "დაჭერით" Bitrix კონტეინერებში, რომელთაგან თითოეული ასრულებს მინიმალურ ფუნქციებს;
• მიღწეული კონტეინერების მოქალაქეობის არმქონე მდგომარეობა;
• გადაჭრა პრობლემა Bitrix-ის განახლებით Kubernetes-ში;
• Bitrix-ის ყველა ფუნქცია განაგრძობდა მუშაობას (თითქმის ყველა);
• ჩვენ ვიმუშავეთ Kubernetes-ზე განლაგებაზე და ვერსიებს შორის დაბრუნებაზე.

ბიზნესის თვალსაზრისით:

• შეცდომის ტოლერანტობა;
• Kubernetes ინსტრუმენტები (მარტივი ინტეგრაცია Gitlab CI-თან, უწყვეტი განლაგება და ა.შ.);
• საიდუმლო პაროლები (ხილული მხოლოდ მათთვის, ვისაც უშუალოდ აქვს წვდომა პაროლებზე);
• მოსახერხებელია დამატებითი გარემოს შექმნა (განვითარებისთვის, ტესტებისთვის და ა.შ.) ერთი ინფრასტრუქტურის ფარგლებში.

წყარო: www.habr.com