कुबेरनेट्स में स्टेटफ़ुल बैकअप

इसलिए, जैसा कि सभी को पता है, हाल ही में DevOpsConfRussia2018 1-2 अक्टूबर को मास्को में "इन्फ्रासस्पेस" में आयोजित किया गया था। जो लोग सहज नहीं हैं, उनके लिए DevOpsConf विकास, परीक्षण और संचालन प्रक्रियाओं के एकीकरण पर एक पेशेवर सम्मेलन है।

हमारी कंपनी ने भी इस सम्मेलन में भाग लिया। हम इसके भागीदार थे, हमारे बूथ पर कंपनी का प्रतिनिधित्व करते थे, और एक छोटी सी बैठक भी करते थे। वैसे, इस तरह की गतिविधि में यह हमारी पहली भागीदारी थी। पहला सम्मेलन, पहला मीतप, पहला अनुभव।

हम किस बारे में बात करते थे? मितप "कुबेरनेट्स में बैकअप" विषय पर थे।

सबसे अधिक संभावना यह नाम सुनकर, कई कहेंगे: "कुबेरनेट्स को वापस क्यों? इसे वापस करने की आवश्यकता नहीं है, यह स्टेटलेस है। ”

परिचय ...

थोड़ा पृष्ठभूमि के साथ शुरू करते हैं। इस विषय को कवर करना क्यों आवश्यक हो गया और इसकी आवश्यकता क्यों है।

2016 में, हम Kubernetes जैसी तकनीक से परिचित हो गए और इसे सक्रिय रूप से हमारी परियोजनाओं पर लागू करना शुरू कर दिया। बेशक, ये मुख्य रूप से microservice वास्तुकला के साथ परियोजनाएं हैं, और यह बदले में बड़ी संख्या में विविध सॉफ़्टवेयर के उपयोग को मजबूर करता है।

पहली परियोजना के साथ, जहां हमने कुबेरनेट्स का उपयोग किया था, हमारे सामने एक प्रश्न था कि वहां स्थित स्टेटफुल सेवाओं का बैकअप कैसे लिया जाए, जो कभी-कभी एक कारण या किसी अन्य के लिए k8 में आते हैं।

हमने इस समस्या को हल करने के लिए मौजूदा प्रथाओं का अध्ययन और खोज शुरू की। हमारे सहयोगियों और साथियों के साथ संवाद करें: "और यह प्रक्रिया कैसे और उनके द्वारा बनाई गई है?"

बात करने के बाद, हमने महसूस किया कि यह सब विभिन्न तरीकों, साधनों और बड़ी संख्या में बैसाखी के साथ होता है। हालाँकि, हमने किसी भी परियोजना के ढांचे के भीतर किसी भी एकीकृत दृष्टिकोण का पालन नहीं किया।

यह इतना महत्वपूर्ण क्यों है? चूँकि k8s पर आधारित हमारी कंपनी की परियोजनाएँ हैं, इसलिए हमें इस समस्या के समाधान के लिए एक संरचित कार्यप्रणाली विकसित करने की आवश्यकता है।

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

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

इस लेख के ढांचे में, हम बस इस टूल के बारे में बात करेंगे कि हम अपनी कंपनी के भीतर इस समस्या को हल करने के लिए किस उपकरण और किस अभ्यास का उपयोग करते हैं।

हम यह कैसे कर रहे हैं?

Nxs- बैकअप क्या है?

बैकअप के लिए, हम अपने स्वयं के ओपन सोर्स टूल - nxs-backup का उपयोग करते हैं। हम उसके ब्योरे में नहीं जाएंगे। अधिक विवरण निम्न लिंक पर पाया जा सकता है।

अब k8s में बैकअप के कार्यान्वयन के लिए आगे बढ़ते हैं। कैसे और क्या वास्तव में हमारे द्वारा किया गया था।

बैकअप क्या है?

आइए हमारे अपने रेडमाइन के एक उदाहरण बैकअप को देखें। इसमें, हम MySQL डेटाबेस और उपयोगकर्ता प्रोजेक्ट फ़ाइलों का बैकअप लेंगे।

हम यह कैसे करते हैं?

1 क्रोनजोब == 1 सेवा

हार्डवेयर पर साधारण सर्वर और क्लस्टर्स पर, लगभग सभी बैकअप उपकरण ज्यादातर नियमित क्रोन के माध्यम से लॉन्च किए जाते हैं। इस उद्देश्य के लिए k8s में हम CronJob's का उपयोग करते हैं, अर्थात हम 1 सेवा के लिए 1 CronJob बनाते हैं, जिसका हम बैकअप लेंगे। ये सभी क्रोनजॉब एस स्वयं सेवा के रूप में एक ही नाम स्थान पर स्थित हैं।

आइए MySQL डेटाबेस से शुरू करें। MySQL का बैकअप लेने के लिए, हमें 4 तत्वों की आवश्यकता है, लगभग किसी अन्य सेवा के लिए:

• कॉन्फिगरेशन (nxs-backup.conf)
• कॉन्फिगरेशन (mysql.conf for nxs-backup)
• गुप्त (सेवा तक पहुंच यहां संग्रहीत की जाती है, इस मामले में MySQL)। आमतौर पर, इस तत्व को सेवा के काम करने के लिए पहले से ही परिभाषित किया गया है और इसका पुन: उपयोग किया जा सकता है।
• क्रोनजॉब (प्रत्येक सेवा के लिए अपने स्वयं के)

क्रम में चलते हैं।

NXS-backup.conf

apiVersion: v1 kind: ConfigMap metadata: name: nxs-backup-conf data: nxs-backup.conf: |- main: server_name: Nixys k8s cluster admin_mail: admins@nixys.ru client_mail: - '' mail_from: backup@nixys.ru level_message: error block_io_read: '' block_io_write: '' blkio_weight: '' general_path_to_all_tmp_dir: /var/nxs-backup cpu_shares: '' log_file: /dev/stdout jobs: !include [conf.d/*.conf] 

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

कॉन्फ़िगरेशन को j2 प्रारूप में निर्दिष्ट किया जा सकता है, जो पर्यावरण चर का उपयोग करने की अनुमति देता है।

mysql.conf

 apiVersion: v1 kind: ConfigMap metadata: name: mysql-conf data: service.conf.j2: |- - job: mysql type: mysql tmp_dir: /var/nxs-backup/databases/mysql/dump_tmp sources: - connect: db_host: {{ db_host }} db_port: {{ db_port }} socket: '' db_user: {{ db_user }} db_password: {{ db_password }} target: - redmine_db gzip: yes is_slave: no extra_keys: '--opt --add-drop-database --routines --comments --create-options --quote-names --order-by-primary --hex-blob' storages: - storage: local enable: yes backup_dir: /var/nxs-backup/databases/mysql/dump store: days: 6 weeks: 4 month: 6 

यह फ़ाइल संबंधित सेवा के लिए बैकअप तर्क का वर्णन करती है, हमारे मामले में यह MySQL है।

यहाँ आप निर्दिष्ट कर सकते हैं:

• नौकरी का नाम क्या है (क्षेत्र: नौकरी)
• नौकरी का प्रकार (फ़ील्ड: प्रकार)
• बैकअप लेने के लिए आवश्यक अस्थायी निर्देशिका (फ़ील्ड: tmp_dir)
• MySQL कनेक्शन विकल्प (फ़ील्ड: कनेक्ट)
• डेटाबेस का बैकअप लिया जाएगा (फ़ील्ड: लक्ष्य)
• इकट्ठा करने से पहले दास को रोकने की जरूरत है (क्षेत्र: is_slave)
• Mysqldump के लिए अतिरिक्त कुंजियाँ (फ़ील्ड: extra_keys)
• स्टोरेज स्टोरेज, यानि किस स्टोरेज में हम एक कॉपी स्टोर करेंगे (फ़ील्ड: स्टोरेज)
• वह निर्देशिका जहां हम अपनी प्रतियां संग्रहीत करेंगे (फ़ील्ड: backup_dir)
• संग्रहण योजना (फ़ील्ड: स्टोर)

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

यहां, इस कॉन्फ़िगरेशन फ़ाइल के अनुरूप, आप Redis, PostgreSQL या किसी अन्य आवश्यक सेवा के लिए समान कॉन्फ़िगरेशन फ़ाइलों को निर्दिष्ट कर सकते हैं, यदि यह हमारे टूल द्वारा समर्थित है। तथ्य यह है कि यह समर्थन करता है पहले दिए गए लिंक पर पाया जा सकता है।

गुप्त mysql

 apiVersion: v1 kind: Secret metadata: name: app-config data: db_name: "" db_host: "" db_user: "" db_password: "" secret_token: "" smtp_address: "" smtp_domain: "" smtp_ssl: "" smtp_enable_starttls_auto: "" smtp_port: "" smtp_auth_type: "" smtp_login: "" smtp_password: "" 

हम स्वयं MySQL और मेल सर्वर से कनेक्ट करने के लिए गुप्त पहुंच रखते हैं। वे या तो एक अलग रहस्य में संग्रहीत किए जा सकते हैं, या मौजूदा एक का लाभ उठा सकते हैं, निश्चित रूप से, अगर वहाँ एक है। यहां कुछ भी दिलचस्प नहीं है। हमारा रहस्य secret_token भी रखता है, जो हमारे Redmine के संचालन के लिए आवश्यक है।

CronJob MySQL

 apiVersion: batch/v1beta1 kind: CronJob metadata: name: mysql spec: schedule: "00 00 * * *" jobTemplate: spec: template: spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - nxs-node5 containers: - name: mysql-backup image: nixyslab/nxs-backup:latest env: - name: DB_HOST valueFrom: secretKeyRef: name: app-config key: db_host - name: DB_PORT value: '3306' - name: DB_USER valueFrom: secretKeyRef: name: app-config key: db_user - name: DB_PASSWORD valueFrom: secretKeyRef: name: app-config key: db_password - name: SMTP_MAILHUB_ADDR valueFrom: secretKeyRef: name: app-config key: smtp_address - name: SMTP_MAILHUB_PORT valueFrom: secretKeyRef: name: app-config key: smtp_port - name: SMTP_USE_TLS value: 'YES' - name: SMTP_AUTH_USER valueFrom: secretKeyRef: name: app-config key: smtp_login - name: SMTP_AUTH_PASS valueFrom: secretKeyRef: name: app-config key: smtp_password - name: SMTP_FROM_LINE_OVERRIDE value: 'NO' volumeMounts: - name: mysql-conf mountPath: /usr/share/nxs-backup/service.conf.j2 subPath: service.conf.j2 - name: nxs-backup-conf mountPath: /etc/nxs-backup/nxs-backup.conf subPath: nxs-backup.conf - name: backup-dir mountPath: /var/nxs-backup imagePullPolicy: Always volumes: - name: mysql-conf configMap: name: mysql-conf items: - key: service.conf.j2 path: service.conf.j2 - name: nxs-backup-conf configMap: name: nxs-backup-conf items: - key: nxs-backup.conf path: nxs-backup.conf - name: backup-dir hostPath: path: /var/backups/k8s type: Directory restartPolicy: OnFailure 

शायद यह तत्व सबसे दिलचस्प है। सबसे पहले, सही क्रोनजॉब को संकलित करने के लिए, आपको यह निर्धारित करने की आवश्यकता है कि एकत्रित बैकअप कहां संग्रहीत किया जाएगा।

इसके लिए हमारे पास संसाधनों की आवश्यक संख्या के साथ एक अलग सर्वर है। उदाहरण में, बैकअप एकत्र करने के लिए एक अलग क्लस्टर नोड, nxs-node5 आवंटित किया गया है। हमारे द्वारा आवश्यक नोड्स पर क्रोनजॉब शुरू करने पर प्रतिबंध नोडएफ़िनिटी निर्देश द्वारा निर्धारित किया गया है।

जब क्रोनजॉब शुरू होता है, तो संबंधित निर्देशिका मेजबान सिस्टम से होस्टपैथ के माध्यम से इससे जुड़ी होती है, जिसका उपयोग बैकअप प्रतियों को संग्रहीत करने के लिए किया जाता है।

इसके बाद, कॉन्फ़िगैप्स विशिष्ट CronJob से जुड़े होते हैं, जिसमें nxs-backup, अर्थात्, nxs-backup.conf और mysql.conf फ़ाइलों के लिए कॉन्फ़िगरेशन होता है, जिनके बारे में हमने ऊपर बात की थी।

फिर, सभी आवश्यक पर्यावरण चर सेट किए जाते हैं, जो सीधे प्रकट में परिभाषित किए जाते हैं या सीक्रेटोव से खींचे जाते हैं।

इसलिए, चर को कंटेनर में स्थानांतरित किया जाता है और, docker-entrypoint.sh के माध्यम से, उन स्थानों में कॉन्फिगरमैप में प्रतिस्थापित किया जाता है, जहां हमें आवश्यक मानों की आवश्यकता होती है। MySQL के लिए, यह db_host, db_user, db_password है। इस मामले में, हम पोर्ट को क्रोनजॉब की उपस्थिति में एक मूल्य के रूप में पास करते हैं, क्योंकि यह कोई मूल्यवान जानकारी नहीं रखता है।

खैर, MySQL के साथ सब कुछ स्पष्ट प्रतीत होता है। अब देखते हैं कि Redmine एप्लिकेशन फ़ाइलों का बैकअप लेने के लिए क्या आवश्यक है।

desc_files.conf

 apiVersion: v1 kind: ConfigMap metadata: name: desc-files-conf data: service.conf.j2: |- - job: desc-files type: desc_files tmp_dir: /var/nxs-backup/files/desc/dump_tmp sources: - target: - /var/www/files gzip: yes storages: - storage: local enable: yes backup_dir: /var/nxs-backup/files/desc/dump store: days: 6 weeks: 4 month: 6 

यह एक कॉन्फ़िगरेशन फ़ाइल है जो फ़ाइलों के लिए बैकअप तर्क का वर्णन करती है। यहाँ कुछ भी असामान्य नहीं है, प्राधिकरण डेटा के अपवाद के साथ, सभी समान पैरामीटर MySQL के लिए सेट किए गए हैं, क्योंकि वे बस नहीं हैं। यद्यपि वे हो सकते हैं, यदि डेटा ट्रांसफर के लिए प्रोटोकॉल शामिल हैं: ssh, ftp, webdav, s3 और अन्य। हम इस विकल्प पर थोड़ा बाद में विचार करेंगे।

क्रोनजॉब desc_files

 apiVersion: batch/v1beta1 kind: CronJob metadata: name: desc-files spec: schedule: "00 00 * * *" jobTemplate: spec: template: spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - nxs-node5 containers: - name: desc-files-backup image: nixyslab/nxs-backup:latest env: - name: SMTP_MAILHUB_ADDR valueFrom: secretKeyRef: name: app-config key: smtp_address - name: SMTP_MAILHUB_PORT valueFrom: secretKeyRef: name: app-config key: smtp_port - name: SMTP_USE_TLS value: 'YES' - name: SMTP_AUTH_USER valueFrom: secretKeyRef: name: app-config key: smtp_login - name: SMTP_AUTH_PASS valueFrom: secretKeyRef: name: app-config key: smtp_password - name: SMTP_FROM_LINE_OVERRIDE value: 'NO' volumeMounts: - name: desc-files-conf mountPath: /usr/share/nxs-backup/service.conf.j2 subPath: service.conf.j2 - name: nxs-backup-conf mountPath: /etc/nxs-backup/nxs-backup.conf subPath: nxs-backup.conf - name: target-dir mountPath: /var/www/files - name: backup-dir mountPath: /var/nxs-backup imagePullPolicy: Always volumes: - name: desc-files-conf configMap: name: desc-files-conf items: - key: service.conf.j2 path: service.conf.j2 - name: nxs-backup-conf configMap: name: nxs-backup-conf items: - key: nxs-backup.conf path: nxs-backup.conf - name: backup-dir hostPath: path: /var/backups/k8s type: Directory - name: target-dir persistentVolumeClaim: claimName: redmine-app-files restartPolicy: OnFailure 

MySQL के बारे में या तो कुछ भी नया नहीं है। लेकिन यहां एक अतिरिक्त पीवी (लक्ष्य-डीआईआर) लगाया जाता है, जिसे हम बैकअप करेंगे - / var / www / files। अन्यथा, सब कुछ समान है, हम अपनी जरूरत के नोड पर स्थानीय रूप से प्रतियां संग्रहीत करते हैं, जिसके लिए क्रोनजॉब को सौंपा गया है।

परिणाम

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

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

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

हम इसे कहाँ संग्रहीत करते हैं?

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

mysql.conf + s3

निम्न MySQL बैकअप कॉन्फ़िगरेशन फ़ाइल का एक उदाहरण है, जहां प्रतियां नोड पर स्थानीय रूप से संग्रहीत की जाती हैं जहां CronJob चल रहा है, और s3 में भी सिंक्रनाइज़ है।

 apiVersion: v1 kind: ConfigMap metadata: name: mysql-conf data: service.conf.j2: |- - job: mysql type: mysql tmp_dir: /var/nxs-backup/databases/mysql/dump_tmp sources: - connect: db_host: {{ db_host }} db_port: {{ db_port }} socket: '' db_user: {{ db_user }} db_password: {{ db_password }} target: - redmine_db gzip: yes is_slave: no extra_keys: ' --opt --add-drop-database --routines --comments --create-options --quote-names --order-by-primary --hex-blob' storages: - storage: local enable: yes backup_dir: /var/nxs-backup/databases/mysql/dump store: days: 6 weeks: 4 month: 6 - storage: s3 enable: yes backup_dir: /nxs-backup/databases/mysql/dump bucket_name: {{ bucket_name }} access_key_id: {{ access_key_id }} secret_access_key: {{ secret_access_key }} s3fs_opts: {{ s3fs_opts }} store: days: 2 weeks: 1 month: 6 

यही है, अगर यह स्थानीय रूप से प्रतियों को संग्रहीत करने के लिए पर्याप्त नहीं है, तो आप उन्हें उपयुक्त प्रोटोकॉल का उपयोग करके किसी भी दूरस्थ संग्रहण में सिंक्रनाइज़ कर सकते हैं। स्टोरेज के लिए स्टोरेज की संख्या कोई भी हो सकती है।

लेकिन इस मामले में, आपको अभी भी कुछ अतिरिक्त परिवर्तन करने की आवश्यकता है, अर्थात्:

• J2 प्रारूप में AWS S3 के साथ प्राधिकरण के लिए आवश्यक सामग्री के साथ उपयुक्त कॉन्फिगरेशन को कनेक्ट करें
• प्राधिकरण पहुंच को संग्रहीत करने के लिए एक उपयुक्त गुप्त बनाएँ
• उपरोक्त सीक्रेट से आवश्यक पर्यावरण चर निर्धारित करें
• ConfigMap में इसी चर को बदलने के लिए docker-entrypoint.sh समायोजित करें
• AWS S3 के साथ काम करने के लिए उपयोगिताओं को जोड़ते हुए Docker छवि का पुनर्निर्माण करें

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

निष्कर्ष

शायद यही सब है।

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