MariaDB
 sql >> डेटाबेस >  >> RDS >> MariaDB

Kubernetes पर एक सहायक कंटेनर के रूप में ProxySQL चलाना

ProxySQL आमतौर पर तथाकथित रिवर्स-प्रॉक्सी टियर में एप्लिकेशन और डेटाबेस टियर के बीच बैठता है। जब आपके एप्लिकेशन कंटेनर कुबेरनेट्स द्वारा व्यवस्थित और प्रबंधित किए जाते हैं, तो हो सकता है कि आप अपने डेटाबेस सर्वर के सामने ProxySQL का उपयोग करना चाहें।

इस पोस्ट में, हम आपको दिखाएंगे कि कुबेरनेट्स पर ProxySQL को पॉड में एक सहायक कंटेनर के रूप में कैसे चलाया जाए। हम Wordpress को एक उदाहरण एप्लिकेशन के रूप में उपयोग करने जा रहे हैं। डेटा सेवा हमारे दो-नोड MySQL प्रतिकृति द्वारा प्रदान की जाती है, जिसे क्लस्टरकंट्रोल का उपयोग करके तैनात किया गया है और कुबेरनेट्स नेटवर्क के बाहर एक नंगे धातु के बुनियादी ढांचे पर बैठे हैं, जैसा कि निम्नलिखित आरेख में दिखाया गया है:

ProxySQL डॉकर इमेज

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

मूल रूप से, ProxySQL कंटेनर चलाने के लिए, बस निम्न कमांड निष्पादित करें:

$ docker run -d -v /path/to/proxysql.cnf:/etc/proxysql.cnf severalnines/proxysql

यह छवि आपको एक ProxySQL कॉन्फ़िगरेशन फ़ाइल को आरोह बिंदु, /etc/proxysql.cnf से बाँधने की सलाह देती है, यद्यपि आप इसे छोड़ सकते हैं और बाद में ProxySQL Admin console का उपयोग करके इसे कॉन्फ़िगर कर सकते हैं। उदाहरण कॉन्फ़िगरेशन डॉकर हब पेज या जीथब पेज में दिए गए हैं।

कुबेरनेट्स पर प्रॉक्सीएसक्यूएल

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

आदर्श रूप से, हम ProxySQL को कुबेरनेट्स द्वारा प्रबंधित करने के लिए दो कॉन्फ़िगरेशन के साथ कॉन्फ़िगर कर सकते हैं:

  1. ProxySQL एक Kubernetes सेवा के रूप में (केंद्रीकृत परिनियोजन)।
  2. ProxySQL एक पॉड (वितरित परिनियोजन) में एक सहायक कंटेनर के रूप में।

पहला विकल्प बहुत सीधा है, जहाँ हम एक ProxySQL पॉड बनाते हैं और उसमें एक Kubernetes सेवा संलग्न करते हैं। तब अनुप्रयोग कॉन्फ़िगर किए गए पोर्ट पर नेटवर्किंग के माध्यम से ProxySQL सेवा से जुड़ेंगे। MySQL लोड-संतुलित पोर्ट के लिए डिफ़ॉल्ट 6033 और ProxySQL व्यवस्थापन पोर्ट के लिए 6032। यह परिनियोजन आगामी ब्लॉग पोस्ट में शामिल किया जाएगा।

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

निम्नलिखित आरेख को देखकर दोनों परिनियोजनों को आसानी से पहचाना जा सकता है:

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

यह ब्लॉग पोस्ट दूसरे कॉन्फ़िगरेशन को कवर करेगा - ProxySQL को एक पॉड में एक सहायक कंटेनर के रूप में चला रहा है।

ProxySQL पॉड में हेल्पर के रूप में

इस सेटअप में, हम अपने Wordpress कंटेनर में एक सहायक कंटेनर के रूप में ProxySQL चलाते हैं। निम्न आरेख हमारे उच्च-स्तरीय आर्किटेक्चर को दर्शाता है:

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

ProxySQL की भूमिका एप्लिकेशन कंटेनर को डेटाबेस एब्स्ट्रैक्शन लेयर प्रदान करना है। चूंकि हम बैकएंड डेटाबेस सेवा के रूप में दो-नोड MySQL प्रतिकृति चला रहे हैं, इसलिए दोनों MySQL सर्वर पर संसाधन खपत को अधिकतम करने के लिए रीड-राइट विभाजन महत्वपूर्ण है। ProxySQL इस पर उत्कृष्टता प्राप्त करता है और एप्लिकेशन में न्यूनतम या बिना किसी बदलाव की आवश्यकता होती है।

इस सेटअप में ProxySQL चलाने के कई अन्य लाभ हैं:

  • क्वेरी कैशिंग क्षमता को Kubernetes में चल रहे एप्लिकेशन लेयर के सबसे करीब लाएं।
  • ProxySQL UNIX सॉकेट फ़ाइल के माध्यम से कनेक्ट करके सुरक्षित कार्यान्वयन। यह एक पाइप की तरह है जिसे सर्वर और क्लाइंट अनुरोध और डेटा को जोड़ने और एक्सचेंज करने के लिए उपयोग कर सकते हैं।
  • साझा नथिंग आर्किटेक्चर के साथ वितरित रिवर्स प्रॉक्सी टियर।
  • "स्किप-नेटवर्किंग" कार्यान्वयन के कारण कम नेटवर्क ओवरहेड।
  • कुबेरनेट्स कॉन्फिगमैप्स का उपयोग करके स्टेटलेस परिनियोजन दृष्टिकोण।

डेटाबेस तैयार करना

मास्टर पर वर्डप्रेस डेटाबेस और उपयोगकर्ता बनाएं और सही विशेषाधिकार के साथ असाइन करें:

mysql-master> CREATE DATABASE wordpress;
mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'passw0rd';
mysql-master> GRANT ALL PRIVILEGES ON wordpress.* TO [email protected]'%';

साथ ही, ProxySQL मॉनिटरिंग यूजर बनाएं:

mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'proxysqlpassw0rd';

फिर, अनुदान तालिका पुनः लोड करें:

mysql-master> FLUSH PRIVILEGES;

पॉड तैयार करना

अब, निम्न पंक्तियों को blog-deployment.yml . नामक फ़ाइल में कॉपी पेस्ट करें होस्ट पर जहां कुबेक्टल कॉन्फ़िगर किया गया है:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: blog
  labels:
    app: blog
spec:
  replicas: 1
  selector:
    matchLabels:
      app: blog
      tier: frontend
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: blog
        tier: frontend
    spec:

      restartPolicy: Always

      containers:
      - image: wordpress:4.9-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: localhost:/tmp/proxysql.sock
        - name: WORDPRESS_DB_USER
          value: wordpress
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
        - name: shared-data
          mountPath: /tmp

      - image: severalnines/proxysql
        name: proxysql
        volumeMounts:
        - name: proxysql-config
          mountPath: /etc/proxysql.cnf
          subPath: proxysql.cnf
        - name: shared-data
          mountPath: /tmp

      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim
      - name: proxysql-config
        configMap:
          name: proxysql-configmap
      - name: shared-data
        emptyDir: {}

YAML फ़ाइल में कई पंक्तियाँ हैं और आइए केवल दिलचस्प भाग देखें। पहला खंड:

apiVersion: apps/v1
kind: Deployment

पहली पंक्ति apiVersion है। हमारा Kubernetes क्लस्टर v1.12 पर चल रहा है, इसलिए हमें Kubernetes v1.12 API दस्तावेज़ों का संदर्भ लेना चाहिए और इस API के अनुसार संसाधन घोषणा का पालन करना चाहिए। अगला प्रकार है, जो बताता है कि हम किस प्रकार के संसाधन को तैनात करना चाहते हैं। डिप्लॉयमेंट, सर्विस, रेप्लिकासेट, डेमनसेट, पर्सिस्टेंटवॉल्यूम इसके कुछ उदाहरण हैं।

अगला महत्वपूर्ण खंड "कंटेनर" खंड है। यहां हम उन सभी कंटेनरों को परिभाषित करते हैं जिन्हें हम इस पॉड में एक साथ चलाना चाहते हैं। पहला भाग Wordpress कंटेनर है:

      - image: wordpress:4.9-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: localhost:/tmp/proxysql.sock
        - name: WORDPRESS_DB_USER
          value: wordpress
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
        - name: shared-data
          mountPath: /tmp

इस खंड में, हम कुबेरनेट्स को अपाचे वेब सर्वर का उपयोग करके वर्डप्रेस 4.9 को तैनात करने के लिए कह रहे हैं और हमने कंटेनर को "वर्डप्रेस" नाम दिया है। हम यह भी चाहते हैं कि कुबेरनेट्स कई पर्यावरण चर पारित करें:

  • WORDPRESS_DB_HOST - डेटाबेस होस्ट। चूंकि हमारा ProxySQL कंटेनर उसी पॉड में Wordpress कंटेनर के साथ रहता है, इसलिए इसके बजाय ProxySQL सॉकेट फ़ाइल का उपयोग करना अधिक सुरक्षित है। Wordpress में सॉकेट फ़ाइल का उपयोग करने का प्रारूप "लोकलहोस्ट:{सॉकेट फ़ाइल का पथ}" है। डिफ़ॉल्ट रूप से, यह ProxySQL कंटेनर की /tmp निर्देशिका के अंतर्गत स्थित है। यह /tmp पथ "साझा-डेटा" वॉल्यूम माउंट का उपयोग करके Wordpress और ProxySQL कंटेनरों के बीच साझा किया गया है जैसा कि नीचे दिखाया गया है। /tmp निर्देशिका के अंतर्गत समान सामग्री साझा करने के लिए दोनों कंटेनरों को इस वॉल्यूम को माउंट करना होगा।
  • WORDPRESS_DB_USER - वर्डप्रेस डेटाबेस उपयोगकर्ता निर्दिष्ट करें।
  • WORDPRESS_DB_PASSWORD - WORDPRESS_DB_USER . के लिए पासवर्ड . चूंकि हम इस फाइल में पासवर्ड को उजागर नहीं करना चाहते हैं, हम इसे कुबेरनेट्स सीक्रेट्स का उपयोग करके छिपा सकते हैं। यहां हम कुबेरनेट्स को इसके बजाय "mysql-pass" गुप्त संसाधन पढ़ने का निर्देश देते हैं। पॉड परिनियोजन से पहले उन्नत में रहस्य बनाना पड़ता है, जैसा कि आगे बताया गया है।

हम अंतिम उपयोगकर्ता के लिए कंटेनर के पोर्ट 80 को भी प्रकाशित करना चाहते हैं। कंटेनर में /var/www/html के अंदर संग्रहीत Wordpress सामग्री NFS पर चल रहे हमारे सतत भंडारण में आरोहित की जाएगी।

इसके बाद, हम ProxySQL कंटेनर को परिभाषित करते हैं:

      - image: severalnines/proxysql:1.4.12
        name: proxysql
        volumeMounts:
        - name: proxysql-config
          mountPath: /etc/proxysql.cnf
          subPath: proxysql.cnf
        - name: shared-data
          mountPath: /tmp
        ports:
        - containerPort: 6033
          name: proxysql

उपरोक्त खंड में, हम Kubernetes को कई/proxysql का उपयोग करके एक ProxySQL परिनियोजित करने के लिए कह रहे हैं छवि संस्करण 1.4.12. हम यह भी चाहते हैं कि कुबेरनेट्स हमारी कस्टम, पूर्व-कॉन्फ़िगर कॉन्फ़िगरेशन फ़ाइल को माउंट करें और इसे कंटेनर के अंदर /etc/proxysql.cnf पर मैप करें। "साझा-डेटा" नामक एक वॉल्यूम होगा जो वर्डप्रेस छवि के साथ साझा करने के लिए /tmp निर्देशिका में मैप करता है - एक अस्थायी निर्देशिका जो पॉड के जीवनकाल को साझा करती है। यह प्रॉक्सीएसक्यूएल सॉकेट फ़ाइल (/tmp/proxysql.sock) को टीसीपी/आईपी नेटवर्किंग को दरकिनार करते हुए डेटाबेस से कनेक्ट करते समय वर्डप्रेस कंटेनर द्वारा उपयोग करने की अनुमति देता है।

अंतिम भाग "वॉल्यूम" अनुभाग है:

      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim
      - name: proxysql-config
        configMap:
          name: proxysql-configmap
      - name: shared-data
        emptyDir: {}

कुबेरनेट्स को इस पॉड के लिए तीन खंड बनाने होंगे:

  • वर्डप्रेस-पर्सिस्टेंट-स्टोरेज - PersistentVolumeClaim का उपयोग करें Wordpress सामग्री के लिए निरंतर डेटा संग्रहण के लिए कंटेनर में NFS निर्यात को मैप करने के लिए संसाधन।
  • proxysql-config - ConfigMap का उपयोग करें ProxySQL कॉन्फ़िगरेशन फ़ाइल को मैप करने के लिए संसाधन।
  • साझा-डेटा - खाली डीआईआर . का उपयोग करें पॉड के अंदर हमारे कंटेनरों के लिए एक साझा निर्देशिका माउंट करने के लिए संसाधन। खाली डीआईआर संसाधन एक अस्थायी निर्देशिका है जो पॉड के जीवनकाल को साझा करती है।

इसलिए, ऊपर हमारी YAML परिभाषा के आधार पर, हमें "ब्लॉग" पॉड को परिनियोजित करने से पहले कई कुबेरनेट्स संसाधन तैयार करने होंगे:

  1. PersistentVolume और PersistentVolumeClaim - हमारे Wordpress एप्लिकेशन की वेब सामग्री को संग्रहीत करने के लिए, इसलिए जब पॉड को अन्य वर्कर नोड में पुनर्निर्धारित किया जा रहा है, तो हम अंतिम परिवर्तन नहीं खोएंगे।
  2. रहस्य - YAML फ़ाइल के अंदर Wordpress डेटाबेस उपयोगकर्ता पासवर्ड को छिपाने के लिए।
  3. कॉन्फ़िगरेशन मैप - कॉन्फ़िगरेशन फ़ाइल को ProxySQL कंटेनर में मैप करने के लिए, ताकि जब इसे अन्य नोड में पुनर्निर्धारित किया जा रहा हो, तो Kubernetes इसे स्वचालित रूप से फिर से माउंट कर सकता है।
डॉकर पर कईनाईन माइएसक्यूएल:अपने डेटाबेस को कंटेनरीकृत कैसे करेंडॉकर कंटेनर वर्चुअलाइजेशन के शीर्ष पर एक MySQL सेवा चलाने पर विचार करते समय आपको जो कुछ समझने की आवश्यकता है उसे खोजें।

PersistentVolume and PersistentVolumeClaim

कुबेरनेट्स के लिए एक अच्छा स्थायी भंडारण क्लस्टर में सभी कुबेरनेट्स नोड्स द्वारा सुलभ होना चाहिए। इस ब्लॉग पोस्ट के लिए, हमने NFS को PersistentVolume (PV) प्रदाता के रूप में उपयोग किया क्योंकि यह आसान और समर्थित आउट-ऑफ-द-बॉक्स है। NFS सर्वर हमारे Kubernetes नेटवर्क के बाहर कहीं स्थित है और हमने इसे /etc/exports के अंदर निम्नलिखित लाइन के साथ सभी Kubernetes नोड्स को अनुमति देने के लिए कॉन्फ़िगर किया है:

/nfs    192.168.55.*(rw,sync,no_root_squash,no_all_squash)

ध्यान दें कि सभी कुबेरनेट्स नोड्स पर एनएफएस क्लाइंट पैकेज स्थापित होना चाहिए। अन्यथा, Kubernetes NFS को सही ढंग से माउंट करने में सक्षम नहीं होगा। सभी नोड्स पर:

$ sudo apt-install nfs-common #Ubuntu/Debian
$ yum install nfs-utils #RHEL/CentOS

साथ ही, सुनिश्चित करें कि NFS सर्वर पर लक्ष्य निर्देशिका मौजूद है:

(nfs-server)$ mkdir /nfs/kubernetes/wordpress

फिर, वर्डप्रेस-pv-pvc.yml नाम की एक फाइल बनाएं और निम्नलिखित पंक्तियाँ जोड़ें:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: wp-pv
  labels:
    app: blog
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 3Gi
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /nfs/kubernetes/wordpress
    server: 192.168.55.200
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: wp-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi
  selector:
    matchLabels:
      app: blog
      tier: frontend

उपरोक्त परिभाषा में, हम चाहते हैं कि कुबेरनेट्स हमारे Wordpress कंटेनर के लिए NFS सर्वर पर 3GB वॉल्यूम स्पेस आवंटित करे। उत्पादन के उपयोग के लिए ध्यान दें, NFS को स्वचालित प्रोविजनर और स्टोरेज क्लास के साथ कॉन्फ़िगर किया जाना चाहिए।

PV और PVC संसाधन बनाएँ:

$ kubectl create -f wordpress-pv-pvc.yml

सत्यापित करें कि क्या वे संसाधन बनाए गए हैं और स्थिति "बाध्य" होनी चाहिए:

$ kubectl get pv,pvc
NAME                     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
persistentvolume/wp-pv   3Gi        RWO            Recycle          Bound    default/wp-pvc                           22h

NAME                           STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/wp-pvc   Bound    wp-pv    3Gi        RWO                           22h

रहस्य

पहला है WORDPRESS_DB_PASSWORD के लिए Wordpress कंटेनर द्वारा उपयोग किए जाने के लिए एक रहस्य बनाना पर्यावरणपरिवर्ती तारक। इसका कारण यह है कि हम पासवर्ड को YAML फ़ाइल के अंदर स्पष्ट टेक्स्ट में नहीं दिखाना चाहते हैं।

mysql-pass नामक एक गुप्त संसाधन बनाएं और उसके अनुसार पासवर्ड पास करें:

$ kubectl create secret generic mysql-pass --from-literal=password=passw0rd

सत्यापित करें कि हमारा रहस्य बनाया गया है:

$ kubectl get secrets mysql-pass
NAME         TYPE     DATA   AGE
mysql-pass   Opaque   1      7h12m

कॉन्फ़िगरेशन मैप

हमें अपने ProxySQL कंटेनर के लिए ConfigMap संसाधन बनाने की भी आवश्यकता है। Kubernetes ConfigMap फ़ाइल में कॉन्फ़िगरेशन डेटा के कुंजी-मूल्य जोड़े होते हैं जिन्हें पॉड्स में उपभोग किया जा सकता है या कॉन्फ़िगरेशन डेटा को स्टोर करने के लिए उपयोग किया जा सकता है। ConfigMaps आपको कंटेनरीकृत अनुप्रयोगों को पोर्टेबल रखने के लिए छवि सामग्री से कॉन्फ़िगरेशन कलाकृतियों को अलग करने की अनुमति देता है।

चूंकि हमारा डेटाबेस सर्वर पहले से ही एक स्थिर होस्टनाम और आईपी पते के साथ-साथ स्थिर निगरानी उपयोगकर्ता नाम और पासवर्ड के साथ नंगे-धातु सर्वर पर चल रहा है, इस उपयोग के मामले में ConfigMap फ़ाइल ProxySQL सेवा के बारे में पूर्व-कॉन्फ़िगर कॉन्फ़िगरेशन जानकारी संग्रहीत करेगी जिसका हम उपयोग करना चाहते हैं।

सबसे पहले proxysql.cnf नामक एक टेक्स्ट फ़ाइल बनाएं और निम्न पंक्तियां जोड़ें:

datadir="/var/lib/proxysql"
admin_variables=
{
        admin_credentials="admin:adminpassw0rd"
        mysql_ifaces="0.0.0.0:6032"
        refresh_interval=2000
}
mysql_variables=
{
        threads=4
        max_connections=2048
        default_query_delay=0
        default_query_timeout=36000000
        have_compress=true
        poll_timeout=2000
        interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
        default_schema="information_schema"
        stacksize=1048576
        server_version="5.1.30"
        connect_timeout_server=10000
        monitor_history=60000
        monitor_connect_interval=200000
        monitor_ping_interval=200000
        ping_interval_server_msec=10000
        ping_timeout_server=200
        commands_stats=true
        sessions_sort=true
        monitor_username="proxysql"
        monitor_password="proxysqlpassw0rd"
}
mysql_servers =
(
        { address="192.168.55.171" , port=3306 , hostgroup=10, max_connections=100 },
        { address="192.168.55.172" , port=3306 , hostgroup=10, max_connections=100 },
        { address="192.168.55.171" , port=3306 , hostgroup=20, max_connections=100 },
        { address="192.168.55.172" , port=3306 , hostgroup=20, max_connections=100 }
)
mysql_users =
(
        { username = "wordpress" , password = "passw0rd" , default_hostgroup = 10 , active = 1 }
)
mysql_query_rules =
(
        {
                rule_id=100
                active=1
                match_pattern="^SELECT .* FOR UPDATE"
                destination_hostgroup=10
                apply=1
        },
        {
                rule_id=200
                active=1
                match_pattern="^SELECT .*"
                destination_hostgroup=20
                apply=1
        },
        {
                rule_id=300
                active=1
                match_pattern=".*"
                destination_hostgroup=10
                apply=1
        }
)
mysql_replication_hostgroups =
(
        { writer_hostgroup=10, reader_hostgroup=20, comment="MySQL Replication 5.7" }
)

"mysql_servers" और "mysql_users" अनुभागों पर अतिरिक्त ध्यान दें, जहां आपको अपने डेटाबेस क्लस्टर सेटअप के अनुरूप मानों को संशोधित करने की आवश्यकता हो सकती है। इस मामले में, हमारे पास दो डेटाबेस सर्वर हैं जो MySQL प्रतिकृति में चल रहे हैं, जैसा कि क्लस्टरकंट्रोल से लिए गए निम्नलिखित टोपोलॉजी स्क्रीनशॉट में संक्षेप में दिया गया है:

"mysql_query_rules" खंड के तहत परिभाषित अनुसार, सभी लेखन को मास्टर नोड में जाना चाहिए, जबकि रीड्स को होस्टग्रुप 20 में अग्रेषित किया जाता है। यह पढ़ने/लिखने के बंटवारे का मूल है और हम उनका पूरी तरह से उपयोग करना चाहते हैं।

फिर, कॉन्फ़िगरेशन फ़ाइल को ConfigMap में आयात करें:

$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnf
configmap/proxysql-configmap created

सत्यापित करें कि ConfigMap Kubernetes में लोड किया गया है:

$ kubectl get configmap
NAME                 DATA   AGE
proxysql-configmap   1      45s

पॉड परिनियोजित करना

अब हमें ब्लॉग पॉड को परिनियोजित करने के लिए अच्छा होना चाहिए। कुबेरनेट्स को परिनियोजन कार्य भेजें:

$ kubectl create -f blog-deployment.yml

पॉड स्थिति सत्यापित करें:

$ kubectl get pods
NAME                           READY   STATUS              RESTARTS   AGE
blog-54755cbcb5-t4cb7          2/2     Running             0          100s

इसे तैयार कॉलम के तहत 2/2 दिखाना चाहिए, यह दर्शाता है कि पॉड के अंदर दो कंटेनर चल रहे हैं। ब्लॉग पॉड के अंदर Wordpress और ProxySQL कंटेनरों की जाँच करने के लिए -c विकल्प फ़्लैग का उपयोग करें:

$ kubectl logs blog-54755cbcb5-t4cb7 -c wordpress
$ kubectl logs blog-54755cbcb5-t4cb7 -c proxysql

ProxySQL कंटेनर लॉग से, आपको निम्न पंक्तियाँ देखनी चाहिए:

2018-10-20 08:57:14 [INFO] Dumping current MySQL Servers structures for hostgroup ALL
HID: 10 , address: 192.168.55.171 , port: 3306 , weight: 1 , status: ONLINE , max_connections: 100 , max_replication_lag: 0 , use_ssl: 0 , max_latency_ms: 0 , comment:
HID: 10 , address: 192.168.55.172 , port: 3306 , weight: 1 , status: OFFLINE_HARD , max_connections: 100 , max_replication_lag: 0 , use_ssl: 0 , max_latency_ms: 0 , comment:
HID: 20 , address: 192.168.55.171 , port: 3306 , weight: 1 , status: ONLINE , max_connections: 100 , max_replication_lag: 0 , use_ssl: 0 , max_latency_ms: 0 , comment:
HID: 20 , address: 192.168.55.172 , port: 3306 , weight: 1 , status: ONLINE , max_connections: 100 , max_replication_lag: 0 , use_ssl: 0 , max_latency_ms: 0 , comment:

HID 10 (लेखक होस्टग्रुप) में केवल एक ऑनलाइन नोड (एकल मास्टर को इंगित करने वाला) होना चाहिए और दूसरा होस्ट कम से कम OFFLINE_HARD स्थिति में होना चाहिए। HID 20 के लिए, यह सभी नोड्स के लिए ऑनलाइन होने की उम्मीद है (एकाधिक पढ़ी गई प्रतिकृतियों को दर्शाता है)।

परिनियोजन का सारांश प्राप्त करने के लिए, वर्णन ध्वज का उपयोग करें:

$ kubectl describe deployments blog

हमारा ब्लॉग अब चल रहा है, हालांकि हम सेवा को कॉन्फ़िगर किए बिना कुबेरनेट्स नेटवर्क के बाहर से उस तक नहीं पहुंच सकते, जैसा कि अगले भाग में बताया गया है।

ब्लॉग सेवा बनाना

अंतिम चरण हमारे पॉड के लिए एक सेवा संलग्न करना है। यह सुनिश्चित करने के लिए कि हमारा Wordpress ब्लॉग पॉड बाहरी दुनिया से सुलभ है। blog-svc.yml . नामक फ़ाइल बनाएं और निम्न पंक्ति चिपकाएँ:

apiVersion: v1
kind: Service
metadata:
  name: blog
  labels:
    app: blog
    tier: frontend
spec:
  type: NodePort
  ports:
  - name: blog
    nodePort: 30080
    port: 80
  selector:
    app: blog
    tier: frontend

सेवा बनाएं:

$ kubectl create -f blog-svc.yml

सत्यापित करें कि क्या सेवा सही तरीके से बनाई गई है:

[email protected]:~/proxysql-blog# kubectl get svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
blog         NodePort    10.96.140.37   <none>        80:30080/TCP   26s
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP        43h

ब्लॉग पॉड द्वारा प्रकाशित पोर्ट 80 अब पोर्ट 30080 के माध्यम से बाहरी दुनिया में मैप किया गया है। हम http://{any_kubernetes_host}:30080/ पर अपने ब्लॉग पोस्ट तक पहुंच सकते हैं और इसे वर्डप्रेस इंस्टॉलेशन पेज पर रीडायरेक्ट किया जाना चाहिए। अगर हम इंस्टॉलेशन के साथ आगे बढ़ते हैं, तो यह डेटाबेस कनेक्शन वाले हिस्से को छोड़ देगा और सीधे इस पेज को दिखाएगा:

यह इंगित करता है कि हमारा MySQL और ProxySQL कॉन्फ़िगरेशन wp-config.php फ़ाइल के अंदर सही ढंग से कॉन्फ़िगर किया गया है। अन्यथा, आपको डेटाबेस कॉन्फ़िगरेशन पृष्ठ पर पुनः निर्देशित किया जाएगा।

हमारी तैनाती अब पूरी हो गई है।

पॉड के अंदर ProxySQL कंटेनर को मैनेज करना

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

कुबेरनेट्स के भीतर चलते समय कुछ सामान्य प्रबंधन कार्यों के भिन्न होने की उम्मीद है, जैसा कि अगले अनुभागों में दिखाया गया है।

ऊपर और नीचे स्केलिंग

उपरोक्त विन्यास में, हम अपने परिनियोजन में एक प्रतिकृति तैनात कर रहे थे। बढ़ाने के लिए, बस spec.replicas . बदलें कुबेक्टल एडिट कमांड का उपयोग करके तदनुसार मूल्य:

$ kubectl edit deployment blog

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

$ kubectl rollout status deployment blog
Waiting for deployment "blog" rollout to finish: 1 of 3 updated replicas are available...
Waiting for deployment "blog" rollout to finish: 2 of 3 updated replicas are available...
deployment "blog" successfully rolled out

इस समय, हमारे पास कुबेरनेट्स में तीन ब्लॉग पॉड (वर्डप्रेस + प्रॉक्सीएसक्यूएल) एक साथ चल रहे हैं:

$ kubectl get pods
NAME                             READY   STATUS              RESTARTS   AGE
blog-54755cbcb5-6fnqn            2/2     Running             0          11m
blog-54755cbcb5-cwpdj            2/2     Running             0          11m
blog-54755cbcb5-jxtvc            2/2     Running             0          22m

इस समय, हमारी वास्तुकला कुछ इस तरह दिख रही है:

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

स्केलिंग डाउन प्रक्रियाएं समान हैं।

कॉन्फ़िगरेशन प्रबंधन

ProxySQL में कॉन्फ़िगरेशन प्रबंधन महत्वपूर्ण है। यह वह जगह है जहां जादू होता है जहां आप क्वेरी कैशिंग, फ़ायरवॉलिंग और पुनर्लेखन करने के लिए क्वेरी नियमों के अपने सेट को परिभाषित कर सकते हैं। सामान्य अभ्यास के विपरीत, जहां ProxySQL को Admin console के माध्यम से कॉन्फ़िगर किया जाएगा और "SAVE .. TO DISK" का उपयोग करके दृढ़ता में धकेल दिया जाएगा, हम केवल Kubernetes में चीजों को अधिक पोर्टेबल बनाने के लिए कॉन्फ़िगरेशन फ़ाइलों के साथ रहेंगे। यही कारण है कि हम ConfigMaps का उपयोग कर रहे हैं।

चूंकि हम Kubernetes ConfigMaps द्वारा संग्रहीत हमारे केंद्रीकृत कॉन्फ़िगरेशन पर भरोसा कर रहे हैं, इसलिए कॉन्फ़िगरेशन परिवर्तन करने के कई तरीके हैं। सबसे पहले, Kubectl एडिट कमांड का उपयोग करके:

$ kubectl edit configmap proxysql-configmap

यह एक डिफ़ॉल्ट टेक्स्ट एडिटर में कॉन्फ़िगरेशन को खोलेगा और आप इसमें सीधे बदलाव कर सकते हैं और एक बार हो जाने पर टेक्स्ट फ़ाइल को सहेज सकते हैं। अन्यथा, configmaps को फिर से बनाना चाहिए:

$ vi proxysql.cnf # edit the configuration first
$ kubectl delete configmap proxysql-configmap
$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnf

कॉन्फ़िगरेशन को ConfigMap में धकेलने के बाद, सेवा नियंत्रण अनुभाग में दिखाए गए अनुसार पॉड या कंटेनर को पुनरारंभ करें। ProxySQL व्यवस्थापक इंटरफ़ेस (पोर्ट 6032) के माध्यम से कंटेनर को कॉन्फ़िगर करना कुबेरनेट्स द्वारा पॉड पुनर्निर्धारण के बाद इसे स्थायी नहीं बनाएगा।

सेवा नियंत्रण

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

$ kubectl get pods
NAME                             READY   STATUS              RESTARTS   AGE
blog-54755cbcb5-6fnqn            2/2     Running             0          31m
blog-54755cbcb5-cwpdj            2/2     Running             0          31m
blog-54755cbcb5-jxtvc            2/2     Running             1          22m

एक बार में एक पॉड को बदलने के लिए निम्न कमांड का उपयोग करें:

$ kubectl get pod blog-54755cbcb5-6fnqn -n default -o yaml | kubectl replace --force -f -
pod "blog-54755cbcb5-6fnqn" deleted
pod/blog-54755cbcb5-6fnqn

फिर, निम्न के साथ सत्यापित करें:

$ kubectl get pods
NAME                             READY   STATUS              RESTARTS   AGE
blog-54755cbcb5-6fnqn            2/2     Running             0          31m
blog-54755cbcb5-cwpdj            2/2     Running             0          31m
blog-54755cbcb5-qs6jm            2/2     Running             1          2m26s

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

(kube-worker)$ docker kill $(docker ps | grep -i proxysql_blog | awk {'print $1'})

Kubernetes तब मारे गए ProxySQL कंटेनर को एक नए कंटेनर से बदल देगा।

निगरानी

mysql क्लाइंट के माध्यम से SQL स्टेटमेंट को निष्पादित करने के लिए kubectl exec कमांड का उपयोग करें। उदाहरण के लिए, क्वेरी पाचन की निगरानी के लिए:

$ kubectl exec -it blog-54755cbcb5-29hqt -c proxysql -- mysql -uadmin -p -h127.0.0.1 -P6032
mysql> SELECT * FROM stats_mysql_query_digest;

या वन-लाइनर के साथ:

$ kubectl exec -it blog-54755cbcb5-29hqt -c proxysql -- mysql -uadmin -p -h127.0.0.1 -P6032 -e 'SELECT * FROM stats_mysql_query_digest'

SQL कथन को बदलकर, आप अन्य ProxySQL घटकों की निगरानी कर सकते हैं या इस Admin console के माध्यम से कोई भी व्यवस्थापन कार्य कर सकते हैं। फिर से, यह केवल ProxySQL कंटेनर के जीवनकाल के दौरान ही बना रहेगा और यदि पॉड को फिर से शेड्यूल किया जाता है तो यह जारी नहीं रहेगा।

अंतिम विचार

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

एक आगामी ब्लॉग पोस्ट में, हम देखेंगे कि कैसे ProxySQL को कुबेरनेट्स सेवा के रूप में उपयोग करके एक केंद्रीकृत दृष्टिकोण में चलाया जाए।


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. मारियाडीबी में DATE_FORMAT () कैसे काम करता है

  2. एडब्ल्यूएस पर एक MySQL गैलेरा क्लस्टर को तैनात करने का आसान तरीका

  3. मारियाडीबी डेटाबेस को एन्क्रिप्टेड और अनएन्क्रिप्टेड राज्यों में ले जाना

  4. एक हाइब्रिड क्लाउड में तैनात गैलेरा क्लस्टर के लिए आपदा वसूली

  5. मैजिकब्रिक्स अपने हाई वॉल्यूम ट्रैफिक को सपोर्ट करने के लिए मारियाडीबी में माइग्रेट करता है