🧓🏻 🌮 🤟🏼 विकास दल के लिए टेस्ट सर्वर ♍️ 👩‍👦 🧑🏽‍🤝‍🧑🏽

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

पृष्ठभूमि

क्या था:

एक परीक्षण सर्वर
एक अन्य सर्वर पर Gitlab और redmine
किसी समस्या को हल करने की इच्छा

सभी सर्वर हमारे स्थानीय नेटवर्क में हैं, परीक्षण सर्वर बाहर से दुर्गम है।

क्या आवश्यक था:

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

निर्णय के विकल्प

1. एक सर्वर, कई होस्ट

सबसे आसान विकल्प। हम एक ही परीक्षण सर्वर का उपयोग करते हैं, केवल डेवलपर को प्रत्येक शाखा / परियोजना के लिए एक मेजबान बनाने और इसे nginx / ap22 कॉन्फ़िगरेशन में जोड़ने की आवश्यकता है।

पेशेवरों:

जल्दी और सब लोग समझते हैं
स्वचालित कर सकते हैं

विपक्ष:

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

2. सर्वर पर प्रत्येक डेवलपर के लिए!

प्रत्येक सर्वर को आवंटित करें और डेवलपर अपनी अर्थव्यवस्था के लिए जिम्मेदार है।

पेशेवरों:

डेवलपर आपके प्रोजेक्ट के लिए सर्वर को पूरी तरह से कस्टमाइज़ कर सकता है

विपक्ष:

आवश्यकताओं का खंड 2 पूरा नहीं हुआ है
महंगाई और संसाधन बस बेकार खड़े रह सकते हैं जबकि विकास चल रहा है, परीक्षण नहीं
अलग-अलग सर्वरों के कारण स्वचालन बिंदु 1 की तुलना में अधिक जटिल है

3. कंटेनरीकरण - डॉकटर, कुबेरनेट्स

यह तकनीक हमारे जीवन में तेजी से प्रवेश कर रही है। घर पर, मैं लंबे समय से अपनी परियोजनाओं के लिए docker का उपयोग कर रहा हूं।

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

पेशेवरों:

एक सर्वर का उपयोग किया जाता है
सभी आवश्यकताओं को पूरा किया जाता है।

विपक्ष:

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

डॉकर कार्यान्वयन

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

चूँकि मेरे पास kubernetes 0 के साथ अनुभव है, इसलिए सब कुछ मैनुअल के अनुसार यह समझने की कोशिश के साथ किया गया था कि ये सभी क्लस्टर कैसे काम करते हैं। कुछ समय बाद, मैं क्लस्टर को बढ़ाने में कामयाब रहा, लेकिन तब प्रमाणपत्र, चाबियाँ और वास्तव में तैनाती की कठिनाई के साथ समस्याएं थीं। मुझे अपने सहयोगियों को यह सिखाने के लिए एक सरल समाधान की आवश्यकता थी कि इसके साथ कैसे काम करें (उदाहरण के लिए, मैं स्काइप पर एक ही छुट्टी बिताना और सेटअप के साथ मदद करना नहीं चाहता)। इसलिए कुबेरनेट्स को अकेला छोड़ दिया गया था। डॉकटर स्वयं बने रहे और कंटेनर मार्ग के लिए एक समाधान खोजना आवश्यक था। चूंकि उन्हें विभिन्न बंदरगाहों पर उठाया जा सकता था, इसलिए आंतरिक पुनर्प्रेषण के लिए एक ही नगनेक्स का इस्तेमाल किया जा सकता था। इसे रिवर्स प्रॉक्सी सर्वर कहा जाता है।

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

प्रॉक्सी को उलट दें

पहिया को सुदृढ़ नहीं करने के लिए, मैंने तैयार समाधानों की तलाश शुरू कर दी। और यह पाया गया - यह ट्रैफिक है ।

Trfik एक आधुनिक HTTP रिवर्स प्रॉक्सी और लोड बैलेंसर है जो कि माइक्रोसॉफ़्टर्स की तैनाती को सरल बनाता है। Trfik मौजूदा बुनियादी ढांचे के घटकों (डॉकर, स्वार्म मोड, कुबेरनेट्स, मैराथन, कौंसुल, Etcd, Rancher, अमेज़ॅन ECS, ...) के साथ एकीकृत करता है और स्वचालित रूप से और गतिशील रूप से कॉन्फ़िगर किया गया है। डॉकटर के साथ काम करने के लिए, आपको बस इसके सॉकेट को निर्दिष्ट करने की आवश्यकता है और यही है, फिर ट्रोफिक खुद सभी कंटेनरों को ढूंढता है और उन्हें रूट करता है (अधिक विवरण के लिए, "डॉकटर में एप्लिकेशन पैकिंग करें" देखें)।

Trfik कंटेनर कॉन्फ़िगरेशन

मैं इसे docker-compose.yml के माध्यम से लॉन्च करता हूं

version: '3' services: traefik: image: traefik:latest # The official Traefik docker image command: --api --docker # Enables the web UI and tells Træfik to listen to docker ports: - 443:443 - 80:80 # The HTTP port - 8080:8080 # The Web UI (enabled by --api) volumes: - /var/run/docker.sock:/var/run/docker.sock # So that Traefik can listen to the Docker events - /opt/traefik/traefik.toml:/traefik.toml - /opt/traefik/certs/:/certs/ networks: - proxy container_name: traefik restart: always networks: proxy: external: true

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

सर्टिफिकेट जनरेशन

 openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout domain.key -out domain.crt

शुरू करने से पहले, आपको डॉकटर में एक प्रॉक्सी नेटवर्क बनाने की आवश्यकता है (आप इसे अपना नाम दे सकते हैं)।

 docker network create proxy

यह php साइटों के कंटेनरों के साथ ट्रैफिक को जोड़ने के लिए नेटवर्क होगा। इसलिए, हम इसे सेवा के नेटवर्क पैरामीटर में और पूरी फाइल के नेटवर्क में पैरामीटर बाहरी में निर्दिष्ट करके निर्दिष्ट करते हैं: सच।

Traefik.toml फ़ाइल

 debug = false logLevel = "DEBUG" defaultEntryPoints = ["https","http"] #  insecureSkipVerify = true #   [entryPoints] [entryPoints.http] address = ":80" [entryPoints.https] address = ":443" [entryPoints.https.tls] [docker] endpoint = "unix:///var/run/docker.sock" domain = "docker.localhost" watch = true exposedbydefault = false

यहां सब कुछ काफी सरल है - हम http और https ट्रैफ़िक के प्रवेश बिंदु निर्दिष्ट करते हैं, यदि प्रमाणपत्र स्थानीय हैं तो insecureSkipVerify = true सेट करना न भूलें। EntryPoints.https.tls अनुभाग में, आप प्रमाणपत्र निर्दिष्ट नहीं कर सकते हैं, फिर ट्रैफ़िक इसके प्रमाण पत्र को प्रतिस्थापित करेगा।

आप सेवा शुरू कर सकते हैं

 docker-compose up -d

यदि आप site.test पर जाते हैं , तो आपको 404 त्रुटि मिलेगी, क्योंकि यह डोमेन किसी भी कंटेनर से बंधा नहीं है।

हम एप्लिकेशन को डॉकटर में पैक करते हैं

अब आपको कंटेनर को एप्लिकेशन के साथ कॉन्फ़िगर करने की आवश्यकता है, अर्थात्:

1. नेटवर्क में एक प्रॉक्सी नेटवर्क निर्दिष्ट करें
2. ट्रैफ़िक कॉन्फ़िगरेशन के साथ लेबल जोड़ें

नीचे एक अनुप्रयोग का कॉन्फ़िगरेशन है

docker-compose.yml एप्लीकेशन

 version: '3' services: app: build: data/docker/php #   restart: always working_dir: /var/www/html/public volumes: - ./:/var/www/html #    - /home/develop/site-files/f:/var/www/html/public/f #       links: - mailcatcher - memcached - mysql labels: - traefik.enabled=true - traefik.frontend.rule=Host:TEST_DOMAIN,crm.TEST_DOMAIN,bonus.TEST_DOMAIN - traefik.docker.network=proxy - traefik.port=443 - traefik.protocol=https networks: - proxy - default mailcatcher: image: schickling/mailcatcher:latest restart: always memcached: image: memcached restart: always mysql: image: mysql:5.7 restart: always command: --max_allowed_packet=902505856 --sql-mode="" environment: MYSQL_ROOT_PASSWORD: 12345 MYSQL_DATABASE: site volumes: - ./data/cache/mysql-db:/var/lib/mysql #      phpmyadmin: image: phpmyadmin/phpmyadmin restart: always links: - mysql environment: MYSQL_USERNAME: root MYSQL_ROOT_PASSWORD: 12345 PMA_ARBITRARY: 1 PMA_HOST: mysql_1 labels: - traefik.enabled=true - traefik.frontend.rule=Host:pma.TEST_DOMAIN - traefik.docker.network=proxy - traefik.port=80 - traefik.default.protocol=http networks: - proxy - default networks: proxy: external: true

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

अगला, लेबल कॉन्फ़िगर करें

  - traefik.enabled=true # traefik    - traefik.frontend.rule=Host:TEST_DOMAIN,crm.TEST_DOMAIN,bonus.TEST_DOMAIN #    traefik     - traefik.docker.network=proxy #   - traefik.port=443 #,     ssl   80   http - traefik.protocol=https #  #  phpmyadmin   http

सामान्य नेटवर्क अनुभाग में, बाह्य निर्दिष्ट करें: सत्य

TEST_DOMAIN स्थिरांक को डोमेन के साथ प्रतिस्थापित किया जाना चाहिए, उदाहरण के लिए, site.test

एप्लिकेशन लॉन्च करें

 docker-compose up -d

अब यदि आप डोमेन site.test, crm.site.test, Bonus.site.test पर जाते हैं, तो आप कार्य स्थल देख सकते हैं। और डोमेन pma.site.test पर डेटाबेस के साथ सुविधाजनक काम के लिए phpmyadmin होगा।

GitLab कॉन्फ़िगर करें

हम एक टास्क हैंडलर बनाते हैं, इसके लिए हम दौड़ते हैं

 gitlab-runner register

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

रनर को एक या एक से अधिक प्रोजेक्ट से जोड़ा जा सकता है। चूँकि मेरा कार्य तर्क हर जगह समान है, एक साझा धावक बनाया गया था (सभी परियोजनाओं के लिए आम)।
और अंतिम स्पर्श एक CI कॉन्फ़िगरेशन फ़ाइल बनाना है

.gitlab-ci.yml

 stages: - build - clear #  develop build_develop: stage: build #   build tags: #     - ssh-develop environment: # ,       -   name: review/$CI_BUILD_REF_NAME #  url: https://site$CI_PIPELINE_ID.test #url     on_stop: clear when: manual script: - cd ../ && cp -r $CI_PROJECT_NAME $CI_PIPELINE_ID && cd $CI_PIPELINE_ID #     - cp -r /home/develop/site-files/.ssh data/docker/php/.ssh #  ssh - sed -i -e "s/TEST_DOMAIN/site$CI_PIPELINE_ID.test/g" docker-compose.yml #   - docker-compose down #   - docker-compose up -d --build #  - script -q -c "docker exec -it ${CI_PIPELINE_ID}_app_1 bash -c \"cd ../ && php composer.phar install --prefer-dist \"" #   - script -q -c "docker exec -it ${CI_PIPELINE_ID}_app_1 bash -c \"cd ../ && php composer.phar first-install $CI_PIPELINE_ID\"" #     #  production build_prod: stage: build tags: - ssh-develop environment: name: review/$CI_BUILD_REF_NAME url: https://site$CI_PIPELINE_ID.test on_stop: clear when: manual script: - cd ../ && cp -r $CI_PROJECT_NAME $CI_PIPELINE_ID && cd $CI_PIPELINE_ID - cp -r /home/develop/site-files/.ssh data/docker/php/.ssh #  ssh - docker-compose down - docker-compose up -d --build - script -q -c "docker exec -it ${CI_PIPELINE_ID}_app_1 bash -c \"cd ../ && php composer.phar install --prefer-dist --no-dev\"" - script -q -c "docker exec -it ${CI_PIPELINE_ID}_app_1 bash -c \"cd ../ && php composer.phar first-install $CI_PIPELINE_ID\"" clear: stage: clear tags: - ssh-develop environment: name: review/$CI_BUILD_REF_NAME action: stop script: - cd ../ && cd $CI_PIPELINE_ID && docker-compose down && cd ../ && echo password | sudo -S rm -rf $CI_PIPELINE_ID #       when: manual

इस कॉन्फ़िगरेशन में, 2 चरणों का वर्णन किया गया है - निर्माण और स्पष्ट। बिल्ड चरण के 2 विकल्प हैं - build_develop और build_prod

Gitlab एक समझने योग्य प्रक्रिया प्रवाह आरेख बनाता है। मेरे उदाहरण में, सभी प्रक्रियाएं मैन्युअल रूप से शुरू होती हैं (जब: मैनुअल पैरामीटर)। ऐसा इसलिए किया जाता है ताकि डेवलपर, परीक्षण स्थल को तैनात करने के बाद, पूरे कंटेनर के पुनर्निर्माण के बिना कंटेनर में अपने संपादन खींच सके। एक और कारण डोमेन नाम है - साइट $ CI_PIPELINE_ID.test, जहां CI_PIPELINE_ID असेंबली शुरू करने की प्रक्रिया की संख्या है। यही है, उन्होंने सत्यापन के लिए डोमेन site123.test के साथ साइट को प्रस्तुत किया, और गर्म संपादन करने के लिए, डेवलपर तुरंत कंटेनर में बदलाव डालता है।

Ssh निष्पादक की एक छोटी विशेषता। सर्वर से कनेक्ट होने पर, प्रपत्र का एक फ़ोल्डर बनाया जाता है।

 /home//builds/_runner/0/_/_

इसलिए, एक पंक्ति जोड़ी गई थी

 cd ../ && cp -r $CI_PROJECT_NAME $CI_PIPELINE_ID && cd $CI_PIPELINE_ID

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

स्पष्ट चरण कंटेनरों को रोकता है और फ़ोल्डर को हटा देता है, आपको रूट विशेषाधिकारों की आवश्यकता हो सकती है, इसलिए हम इको पासवर्ड का उपयोग करते हैं | sudo -S rm जहाँ पासवर्ड आपका पासवर्ड है।

कचरा संग्रह

समय-समय पर, आपको अप्रयुक्त कंटेनरों को हटाने की आवश्यकता होती है, ताकि जगह नहीं ली जा सके, इसके लिए मुकुट में ऐसी सामग्री के साथ एक स्क्रिप्ट लटकी हुई है।

 #!/bin/bash #   : docker ps --filter status=dead --filter status=exited -aq | xargs -r docker rm -v #   : yes | docker container prune #    : yes | docker image prune #    : yes | docker volume prune

दिन में एक बार प्रदर्शन किया।

निष्कर्ष

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

बोनस

हर बार डॉकफाइल से छवियां एकत्र न करने के लिए, आप उन्हें स्थानीय डॉकटर रजिस्ट्री में संग्रहीत कर सकते हैं।

फ़ाइल docker-compose.yml

 registry: restart: always image: registry:2 ports: - 5000:5000 volumes: - /opt/docker-registry/data:/var/lib/registry #

यह विकल्प प्रमाणीकरण का उपयोग नहीं करता है, यह एक सुरक्षित तरीका नहीं है (!!!), लेकिन यह गैर-महत्वपूर्ण छवियों को संग्रहीत करने के लिए उपयुक्त है।

आप देखने के लिए गिटलैब कॉन्फ़िगर कर सकते हैं

  gitlab_rails['registry_enabled'] = true gitlab_rails['registry_host'] = "registry.test" gitlab_rails['registry_port'] = "5000"

उसके बाद, गिटलैब में छवियों की एक सूची दिखाई देती है

विकास दल के लिए टेस्ट सर्वर

पृष्ठभूमि

निर्णय के विकल्प

1. एक सर्वर, कई होस्ट

2. सर्वर पर प्रत्येक डेवलपर के लिए!

3. कंटेनरीकरण - डॉकटर, कुबेरनेट्स

डॉकर कार्यान्वयन

प्रॉक्सी को उलट दें

हम एप्लिकेशन को डॉकटर में पैक करते हैं

GitLab कॉन्फ़िगर करें

कचरा संग्रह

निष्कर्ष

बोनस

More articles: