मैं इसके साथ शुरुआत करना चाहता हूं कि मैं कुछ दिनों के लिए अब डॉकर की खोज कर रहा हूं। मैंने अपने स्थानीय मशीन पर विकास के लिए चलने वाले स्टैक के साथ docker-compose.yml सेटअप किया है। मेरे docker-compose.yml में मैंने वॉल्यूम के साथ एक mysql-container भी बनाया है जो मेरे प्रोजेक्ट में एक फ़ोल्डर को कंटेनर में रहने वाले mysql फ़ोल्डर से जोड़ता है।

परियोजना संरचना:

Project
|-- project folder 1
|-- project folder 2
|-- project folder 3
|-- docker
|   `-- mysql
|-- file1
|-- file2
`-- docker-compose.yml

कंटेनर:

  mysql:
        image: mysql:5.7
        ports:
          - "3306:3306"
        restart: always
        environment:
          MYSQL_DATABASE: xxx
          MYSQL_USER: xxx
          MYSQL_PASSWORD: xxx
          MYSQL_ROOT_PASSWORD: xxx
        networks:
          - network-woo
        volumes:
          - ./docker/mysql:/var/lib/mysql

मैं इस परियोजना को गिट में धकेलता हूं। मेरे कंधे पर "नौसिखिया" नामक एक शैतान मुझसे कहता है "महान! इस तरह आप हर बार धक्का देने पर गिट रेपो में डेटाबेस को सहेज रहे हैं"। जबकि "गुटफीलिंग" नामक एक देवदूत है जो मुझसे कहता है कि सावधान रहो! यह बहुत गलत हो सकता है, लेकिन मुझे अभी तक पता नहीं है कि क्या।

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

अग्रिम में धन्यवाद,

ब्रैम

3
Bram Janssen 19 अक्टूबर 2019, 09:13
मैं ठीक वही बात सोच रहा था। जाहिरा तौर पर सबसे अच्छा फ़ोल्डर संरचना को छोड़ना है लेकिन डेटा को नहीं छोड़ना है
 – 
arcos.lwm
30 पद 2020, 23:54

3 जवाब

पहला और अनुशंसित तरीका docker/mysql को gitignore में डालना है। ऐसा करने से आपको लाइव की चिंता नहीं होगी और लोकल दोनों ही लोकल बैकअप पर मेंटेन करेंगे।

फ़ाइलों को अनदेखा करना

समय-समय पर, ऐसी फाइलें होती हैं जिन्हें आप नहीं चाहते कि गिट गिटहब में चेक इन करे। गिट को यह बताने के कुछ तरीके हैं कि कौन सी फाइलों को अनदेखा करना है।

एक स्थानीय बनाएं .gitignore

यदि आप .gitignore नामक अपने रिपॉजिटरी में एक फ़ाइल बनाते हैं, तो Git इसका उपयोग यह निर्धारित करने के लिए करता है कि आपके द्वारा प्रतिबद्ध होने से पहले किन फ़ाइलों और निर्देशिकाओं को अनदेखा करना है।

एक .gitignore फ़ाइल को आपके रिपॉजिटरी में प्रतिबद्ध किया जाना चाहिए, ताकि रिपोजिटरी को क्लोन करने वाले किसी अन्य उपयोगकर्ता के साथ अनदेखा नियमों को साझा किया जा सके।

दूसरी चीज़ जो आप ./docker/mysql के अलावा किसी अन्य पथ को माउंट करने का प्रयास कर सकते हैं। उदाहरण के लिए

/home/dev/docker/myslq/ देव मशीन में या आपके लाइव /home/live/docker/mysql में।

पहले दृष्टिकोण के साथ जाना बेहतर है और निर्देशिका नामों के साथ खिलवाड़ न करें।

0
Adiii 19 अक्टूबर 2019, 09:26

वास्तव में समस्या यह है कि अपने git रेपो को लाइव सर्वर पर निर्यात करने से डेटाबेस मिट जाएगा जो बहुत अच्छा नहीं है।

मैं डीबी को गिट में नहीं डालूंगा। लेकिन बस संरचना। तालिका निर्माण / संस्करण (जिसे अक्सर माइग्रेशन कहा जाता है)।

Django एक पायथन वेब ढांचा है और इसे बहुत अच्छी तरह से संभालता है। और गिट में सही चीजों को संस्करणित करने में मदद करता है:

  • डेटाबेस संरचना और परिवर्तन (माइग्रेशन)
  • कुछ कच्चे डेटा जो हमेशा (फिक्स्चर) होने चाहिए।

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

https://docs.djangoproject.com/hi/2.2/topics/migrations/

https://docs.djangoproject.com/hi/2.2/howto/initial-data/

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

डेटाबेस निर्माण के लिए v0.1 की तरह, v0.2 एक sql स्क्रिप्ट जो कुछ क्षेत्रों को बदल देगी, आदि ...

और आरंभिक डेटा को सम्मिलित करने के लिए प्रति तालिका एक स्क्रिप्ट, ताकि यदि आप किसी कारण से अपना सर्वर खो देते हैं, तो आप उस प्रारंभिक डेटा को अपने नए सर्वर पर आयात कर सकते हैं।

0
Loïc 19 अक्टूबर 2019, 09:26

मुझे लगता है कि यह आपकी परियोजना पर निर्भर करता है। मैं वर्डप्रेस की दुनिया में हूं, इसलिए मैं इसे एक उदाहरण के रूप में उपयोग करूंगा।

यदि आप एक थीम या प्लगइन विकसित कर रहे हैं जिसका उपयोग एक से अधिक लोगों द्वारा किया जाएगा, तो यह केवल थीम या प्लगइन को वर्जनिंग में रखने के लिए समझ में आता है।

इस मामले में मैं wp-env (एक स्क्रिप्ट जो डॉकटर कंटेनरों के एक जोड़े को स्पिन करती है, और मेरे लिए मानक एक वर्डप्रेस वातावरण स्थापित करती है) का उपयोग करूंगा, और केवल थीम और/या प्लगइन फ़ोल्डर डालूंगा जो संस्करण में कंटेनर से जुड़ा हुआ है। . वास्तव में यहाँ WP स्रोत या DB फ़ाइलों को उत्पन्न करने का कोई मतलब नहीं है, क्योंकि उन्हें बस wp-env कमांड के साथ फिर से पुनर्जीवित किया जा सकता है।

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

- docker-compose.yml (एक wp कंटेनर और एक mysql कंटेनर को स्पिन करता है) - डेटा (mysql कंटेनर में मैप की गई कच्ची डेटाबेस फाइलें) - वर्डप्रेस (वर्डप्रेस प्रोजेक्ट के लिए वेब रूट, wp कंटेनर में मैप किया गया) -- .git

कारण मुझे लगता है कि यह समझ में आता है, यह है कि मैं बस दूसरे कंप्यूटर पर जा सकता हूं, भंडार खींच सकता हूं, डॉकर-कंपोज़ अप चला सकता हूं, और मेरे पास सब कुछ ठीक उसी स्थिति में है जब मैंने आखिरी बार अपने दूसरे कंप्यूटर पर प्रोजेक्ट को धक्का दिया था .

बेशक, यदि आप अन्य लोगों के साथ काम कर रहे हैं, तो इसके लिए कुछ अतिरिक्त समन्वय की आवश्यकता हो सकती है।

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

0
Jules Colle 16 मई 2020, 13:00