👲🏽 👎🏿 📅 CI के माध्यम से AWS पर सिम्फनी + रिएक्ट एप्लिकेशन तैनात करें ⬅️ 🚐 🧑🏾‍🤝‍🧑🏽

शुभ दोपहर, इस लेख में मैं यह दिखाऊंगा कि एडब्ल्यूएस पर सिम्फनी 4 एप्लिकेशन को कैसे तैनात किया जाए। आधिकारिक दस्तावेज में इस तरह की प्रक्रिया का एक उदाहरण है, लेकिन मेरा संस्करण एक आवेदन के साथ ज़िप संग्रह डाउनलोड करने के रूप में तुच्छ नहीं है। 2019 के यार्ड में, डॉक मोड में, माइक्रोसॉफ़्ट आर्किटेक्चर और सीआई / सीडी प्रथाओं को अंततः न केवल DevOps इंजीनियरों के उपकरण में शामिल किया जाना शुरू हो रहा है, बल्कि सामान्य ~~नश्वर~~ डेवलपर्स भी। लेख को और अधिक दिलचस्प बनाने के लिए, मैंने एक बड़ा द्रव्यमान लोगों की जरूरतों को पूरा करने के लिए React.JS के सामने एक मोर्चा जोड़ा, यदि आपका आवेदन दोहराना का उपयोग नहीं करता है - यह कोई फर्क नहीं पड़ता, मैं इंगित करूंगा कि आपके लिए डॉकर फ़ाइल कैसे बदलें, प्रतिक्रिया के लिए समर्थन। JS केवल इसे प्रभावित करता है । इस ट्यूटोरियल में किसे रुचि होगी? सबसे पहले, यह पीएचपी डेवलपर्स के उद्देश्य से है जो अपनी तैनाती के अभ्यास को बदलना चाहते हैं - सामान्य कैनन से दूर जाने के लिए और अपने एप्लिकेशन को पैक करने और छवि को बाहर करने के लिए डॉकटर का उपयोग करें। लेकिन आप थोड़ा और गहराई में जा सकते हैं, और आगे का कथन स्वचालित रूप से CI / CD प्लेटफ़ॉर्म के माध्यम से Git से एप्लिकेशन को तैनात करने के उद्देश्य से होगा (CircleCI का उपयोग किया जाएगा, लेकिन अगर आप Gitlab config में रुचि रखते हैं, तो टिप्पणियों में लिखें, मैं इसे संलग्न करूंगा)। वास्तव में, यह React / PHP के लिए बिल्कुल महत्वपूर्ण नहीं है कि क्या आपके पास कोई एप्लिकेशन है या कहें, .NET कोर, यह हिस्सा डेवलपर्स के लिए सामान्य रूप से तैनाती स्वचालन कौशल हासिल करने के लिए दिलचस्प होगा। स्रोत कोड जीथब रिपॉजिटरी में उपलब्ध है, लेख के अंत में लिंक। अच्छा, चलिए!

मुझे लगता है कि आपके पास अपना स्वयं का सिम्फनी एप्लिकेशन है, लेकिन प्रदर्शन प्रयोजनों के लिए मैंने "हैलो, दुनिया!" को स्केच किया: जिसमें निम्नलिखित पैकेज शामिल हैं:

`symfony/webpack-encore-bundle symfony/form symfony/orm-pack symfony/profiler-pack symfony/security-bundle symfony/twig-bundle symfony/validator symfony/phpunit-bridge`

एक न्यूनतम सज्जन सेट है। फिलहाल, फ़ोल्डर संरचना निम्नानुसार होनी चाहिए:

अब आपको अपने क्लाउड इन्फ्रास्ट्रक्चर को कॉन्फ़िगर करने की आवश्यकता है। मैं एडब्ल्यूएस की परीक्षण अवधि को पंजीकृत करने और सक्रिय करने पर ध्यान केंद्रित नहीं करूंगा, इस स्तर पर हमें 2 डीबी उदाहरण बनाने की आवश्यकता है - मैं नए "सुविधाओं" और पीआरडी (उत्पादन) के रूप में सीधे "मुकाबला" के कार्यान्वयन का परीक्षण करने के लिए 2 प्रकार के पर्यावरण का उपयोग करूंगा। सर्वर। प्रबंधित सेवा डेटाबेस के लाभों के बारे में बहुत सारे लेख लिखे गए हैं, इसके अलावा, हम मुख्य रूप से इस गाइड में डेवलपर के लिए सुविधा का पीछा करते हैं, इसलिए हम आरडीएस का उपयोग करते हैं, और अपने स्वयं के अलग डेटाबेस सर्वर को नहीं बढ़ाते हैं। मैंने इस उदाहरण के लिए DBMS के रूप में PostgreSQL का उपयोग किया, आप किसी भी एक का चयन करने के लिए स्वतंत्र हैं जो आपको सूट करता है, आरडीएस सेवा पर जाएं और आपको आवश्यक क्षमता और मात्रा के 2 उदाहरण बनाएं। चूंकि .env फाइल हमारे लिए "आउट ऑफ द बॉक्स" सिम्फनी में उपलब्ध है, इसलिए हम इसका उपयोग करेंगे, उदाहरण के लिए, PROD के लिए, और STG के लिए हम .env.stg की एक प्रति .env.stg और APP_ENV=dev APP_ENV=stg में .env.stg और APP_ENV=dev APP_ENV=prod पर APP_ENV=dev APP_ENV=prod , और निर्मित उदाहरणों में से प्रत्येक के लिए .env कनेक्शन पैरामीटर भी दर्ज करें।

महान, एक शुरुआत की गई है! जैसा कि आप जानते हैं, संगीतकार के माध्यम से सिम्फनी निर्भरताएं स्थापित की जाती हैं, इसे स्थापित करने के लिए, कंपोजर.श फ़ाइल का उपयोग करें, जिसे हम परियोजना की जड़ में रखते हैं:

composer.sh

 #!/bin/sh EXPECTED_SIGNATURE="$(wget -q -O - https://composer.imtqy.com/installer.sig)" php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" ACTUAL_SIGNATURE="$(php -r "echo hash_file('sha384', 'composer-setup.php');")" if [ "$EXPECTED_SIGNATURE" != "$ACTUAL_SIGNATURE" ] then >&2 echo 'ERROR: Invalid installer signature' rm composer-setup.php exit 1 fi php composer-setup.php --quiet RESULT=$? rm composer-setup.php exit $RESULT

यह संगीतकार से एक सॉफ्टवेयर इंस्टॉलेशन गाइड है ।

अब, प्रत्येक वातावरण के लिए, प्रोजेक्ट की जड़ में अपना खुद का डॉकराइल बनाएं:

Dockerfile.stg (मंचन)

 FROM php:7.2.19-apache EXPOSE 80 RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini" && a2enmod rewrite RUN sed -ri -e 's!memory_limit = 128M!memory_limit = 256M!g' "$PHP_INI_DIR/php.ini" RUN apt-get update && apt-get install -y \ wget \ curl \ libfreetype6-dev \ libjpeg62-turbo-dev \ libpng-dev \ libzip-dev \ zip \ libpq-dev \ && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \ && docker-php-ext-configure zip --with-libzip \ && docker-php-ext-configure pgsql -with-pgsql=/usr/local/pgsql \ && docker-php-ext-install -j$(nproc) gd \ && docker-php-ext-install zip \ && docker-php-ext-install pdo pdo_pgsql pgsql WORKDIR /var/www ENV APACHE_DOCUMENT_ROOT /var/www/public RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/sites-available/*.conf RUN sed -ri -e 's!/var/www/!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/apache2.conf /etc/apache2/conf-available/*.conf RUN echo "ServerName localhost" >> /etc/apache2/apache2.conf COPY ./composer.sh ./ RUN chmod +x ./composer.sh && ./composer.sh && mv composer.phar /usr/local/bin/composer RUN curl -sL https://deb.nodesource.com/setup_10.x | bash - \ && apt-get install -y nodejs RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list \ && apt-get update -qq \ && apt-get install -y yarn COPY ./ ./ COPY ./.env.stg ./.env RUN composer install && yarn && yarn run build

और

Dockerfile (उत्पादन)

 FROM php:7.2.19-apache EXPOSE 80 RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini" && a2enmod rewrite RUN sed -ri -e 's!memory_limit = 128M!memory_limit = 256M!g' "$PHP_INI_DIR/php.ini" RUN apt-get update && apt-get install -y \ wget \ curl \ libfreetype6-dev \ libjpeg62-turbo-dev \ libpng-dev \ libzip-dev \ zip \ libpq-dev \ && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \ && docker-php-ext-configure zip --with-libzip \ && docker-php-ext-configure pgsql -with-pgsql=/usr/local/pgsql \ && docker-php-ext-install -j$(nproc) gd \ && docker-php-ext-install zip \ && docker-php-ext-install pdo pdo_pgsql pgsql WORKDIR /var/www ENV APACHE_DOCUMENT_ROOT /var/www/public RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/sites-available/*.conf RUN sed -ri -e 's!/var/www/!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/apache2.conf /etc/apache2/conf-available/*.conf RUN echo "ServerName localhost" >> /etc/apache2/apache2.conf COPY ./composer.sh ./ RUN chmod +x ./composer.sh && ./composer.sh && mv composer.phar /usr/local/bin/composer RUN curl -sL https://deb.nodesource.com/setup_10.x | bash - \ && apt-get install -y nodejs RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list \ && apt-get update -qq \ && apt-get install -y yarn COPY ./ ./ RUN composer install && yarn && yarn run build

फ़ाइलें "जैसा है" का उपयोग किया जा सकता है, कोई मैक्रोज़ परिवर्तन के लिए उपयोग नहीं किया जाता है। चलो "मैजिक" टच को दूर करने के लिए डॉकरफाइल की सामग्री के माध्यम से चलते हैं। "नींव" के रूप में, हम एकीकृत Apache वेब सर्वर के साथ आधिकारिक PHP 7.2.19 छवि का उपयोग करते हैं (आप अपनी पसंद के किसी भी उपयोग के लिए स्वतंत्र हैं, Nginx के साथ एक बंडल कॉन्फ़िगर करें और इसी तरह, इस उदाहरण में मैं अपनी राय में सबसे अधिक उपयोग करता हूं, मेरी राय में) सुविधाजनक)। एक्सपोज़ लाइन इस समय हमारे लिए महत्वपूर्ण नहीं है, अपने आप में यह कुछ भी नहीं करता है, लेकिन भविष्य में इसका उपयोग ElasticBeanstalk द्वारा किया जाएगा, जिसे इसे सही ढंग से तैनात करने की आवश्यकता है। निम्नलिखित निर्माण निर्माता द्वारा अनुशंसित PHP- अनुकूलित उत्पादन सेटिंग्स का उपयोग करते हैं, Apache के लिए mod_rewrite को सक्रिय करते हैं और PHP स्क्रिप्ट के लिए अधिकतम मेमोरी को 128 से 256 mb तक बढ़ाते हैं, जो संगीतकार के लिए सही ढंग से काम करने के लिए आवश्यक है। अगला, हम आवश्यक एप्लिकेशन, PHP निर्भरता और एक्सटेंशन स्थापित करते हैं, और तुरंत उन्हें कॉन्फ़िगर करते हैं। हम अपने आवेदन की कार्यशील निर्देशिका में फ़ोल्डर / var / www असाइन करते हैं - हमारे आवेदन के स्रोत कोड को वहां कॉपी किया जाएगा। अपाचे के बाद से, डिफ़ॉल्ट रूप से, अपने मेजबान के लिए एक प्रवेश बिंदु के रूप में / var / www का उपयोग करता है, और सिम्फनी इंडेक्स फ़ाइल / var / www / सार्वजनिक में स्थित है, हम अपाचे दस्तावेज़ रूट को निम्नलिखित निर्माण के साथ बदलते हैं। फिर हम संगीतकार, नोडज और यार्न को क्रमिक रूप से स्थापित करते हैं (यदि आप अपने आवेदन में एनकोर / रिएक्ट.जेएस का उपयोग नहीं करते हैं, तो आपको अंतिम दो बिंदुओं की आवश्यकता नहीं है)। अंत में, हम अपने स्रोत कोड की प्रतिलिपि बनाते हैं और प्रतिक्रिया के लिए सिम्फनी और यार्न के लिए संगीतकार के माध्यम से निर्भरता की स्थापना शुरू करते हैं। STG के लिए एक अलग डॉकरीफाइल का अर्थ डॉकटर के लिए दंडात्मक निर्देश में निहित है - .env.stg .env कॉपी करना, इसलिए STG छवि में .env फ़ाइल में इस वातावरण के लिए प्रासंगिक पैरामीटर होंगे। आप स्थानीय रूप से (बेशक डूकर स्थापित के साथ) छवि एकत्र कर सकते हैं, इसे चला सकते हैं और सुनिश्चित कर सकते हैं कि एप्लिकेशन काम कर रहा है और इस काम के लिए किसी और चीज की आवश्यकता नहीं है:

 docker build -t tmp:stg -f Dockerfile.stg . docker run -p 80:80 tmp:stg

STG और के लिए

 docker build -t tmp:prod . docker run -p 80:80 tmp:prod

PROD के लिए।
हम EC2 का उपयोग कर सकते हैं, ELB / ASG, आदि कॉन्फ़िगर कर सकते हैं या ElasticBeanstalk का उपयोग कर सकते हैं, जो सुविधा के लिहाज से हमारे लिए एक उपहार है। ElasticBeanstalk अनुभाग पर जाएं और इसके नाम और विवरण के साथ एक नया एप्लिकेशन बनाएं। फिर पहले से बताए गए 2 वातावरण बनाएँ: STG और PROD, दोनों वातावरण को एक वेब सर्वर वातावरण के रूप में बनाएँ, "Docker" को प्लेटफ़ॉर्म के रूप में निर्दिष्ट करें, और अनुप्रयोग कोड के रूप में नमूना एप्लिकेशन को छोड़ दें। ElasticBeanstalk की तैनाती परियोजना फाइलों या निर्देशों को अपलोड करके की जाती है, आमतौर पर एक ज़िप संग्रह में। हमारे मामले में, प्रवाह इस तरह होगा: हम अपने आवेदन की डॉकटर छवि को इकट्ठा करते हैं, इसे रिपॉजिटरी में लोड करते हैं और स्रोत संग्रह या डॉकर छवि के बजाय निर्देश को लोड करते हैं, जो एलिस्टैबिनस्टॉक को दूरस्थ सर्वर से छवि लेने और इसे तैनात करने के लिए कहता है। और यह सब स्वचालित है।

आइए डॉकटर छवियों को संग्रहीत करने के लिए एक भंडार बनाकर शुरू करें। 2 विकल्प हैं:

1 - आपकी परियोजना निजी है, उसका कोड बंद है और रिपॉजिटरी क्रमशः बंद होनी चाहिए। इस स्थिति में, आप या तो छवियों का अपना रजिस्टर कहीं रखते हैं या एक निजी क्लाउड का उपयोग करते हैं। इन उद्देश्यों के लिए AWS के पास ECR है, आप वहां एक रिपॉजिटरी बना सकते हैं, लेकिन कोई भी आपको ऐसा करने के लिए मजबूर नहीं करता है।

2 - आपके पास एक ओपन सोर्स प्रोजेक्ट है और आप डॉकहब का उपयोग कर सकते हैं।

हमारे उदाहरण में, कोड खुला है, लेकिन मैं दिखाऊंगा कि बंद रिपोजिटरी का उपयोग कैसे किया जाए, इस प्रक्रिया को समझने के बाद, डॉकहॉब से एक छवि को जोड़ना मुश्किल नहीं होगा। पहली चीज जो हमें चाहिए वह है रिपॉजिटरी खुद बनाना, इसके बाद आपको इसका यूआरआई मिलेगा। आगे का कथन थर्ड-पार्टी (AWS ECR रिपॉजिटरी और उनके एकीकरण नहीं) के लिए जाएगा, ECR के लिए मैं उसके बाद लिखूंगा।

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

 docker login -u LOGIN -p PASSWORD REGISTRY

सफल प्रमाणीकरण के बाद, निम्नलिखित निर्माण ~ / .docker / config.json कॉन्फ़िगरेशन फ़ाइल में दिखाई देगा:

 "REGISTRY" : { "auth" : "BASE64_ENCODED_TOKEN" }

यदि यह दिखाई नहीं देता है, तो ऊपर वर्णित डॉक कॉन्फ़िगरेशन को फिर से जांचें।

अब सब कुछ ElasticBeanstalk - Dockerrun.aws.json के लिए निर्देश फ़ाइल तैयार करने के लिए तैयार है, इसका कोड इस प्रकार होगा:

Dockerrun.aws.json

 { "AWSEBDockerrunVersion": "1", "Authentication": { "Bucket": "BUCKET_ID", "Key": "KEY_PATH" }, "Image": { "Name": "IMAGE_URL", "Update": "true" }, "Ports": [ { "ContainerPort": "80" } ] }

सामान्य तौर पर, निर्देश इस तरह दिखता है: S3 स्टोरेज BUCKET_ID में KEY_PATH द्वारा कुंजी का उपयोग करके लॉग इन किया गया है, छवि को IMAGE_URL द्वारा सहेजे गए को अधिलेखित करके लोड करें, इसे पोर्ट पर पोर्ट 80 के समान पोर्ट पर अग्रेषित करके प्रारंभ करें। अब प्रयुक्त स्थिरांक के बारे में:

BUCKET_ID आपके लिए S3 सेवा में स्वचालित रूप से "बैकपैक" बनाया गया है, जिसमें इलास्टिकबैंकॉक-रेजियन-एचएएसएच का रूप है, जहाँ सिस्टम आपके ElasticBeanstalk के लिए सेवा फाइलों को ढूँढता है, जिसमें "अपलोड और तैनाती" बटन का उपयोग करके डाउनलोड किया जाता है।

KEY_PATH - छवि रिपॉजिटरी में प्राधिकरण फ़ाइल के लिए पथ, मैं अपने आवेदन के नाम के तहत BUCKET_ID के अंदर फ़ोल्डर में APP_NAME / cr.json प्रारूप का उपयोग करता हूं (यदि मैं अभी तक बना हूं, तो मैं cr.json फ़ाइल को कोड के साथ प्राप्त कोड में प्राधिकरण के बाद प्राप्त कोड रखता हूं। स्थानीय स्तर पर छवियां:

BUCKET_ID / APP_NAME / cr.json

 { "REGISTRY" : { "auth" : "BASE64_ENCODED_TOKEN" } }

IMAGE_URL आपकी छवि रजिस्टर का अद्वितीय यूआरआई है + छवि का टैग ही, यहां सब कुछ स्पष्ट होना चाहिए।

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

यह इस प्रक्रिया को स्वचालित करने के लिए बनी हुई है। और पूरी तरह से दिलचस्प होने के लिए, मैं अगले प्रवाह के लिए चरणों के अनुक्रम को लागू करूंगा: सभी के लिए नहीं मास्टर शाखा में, छवि एकत्र की जाएगी और एसटीजी वातावरण में तैनात की जाएगी, और अगर हम मास्टर में धक्का देते हैं, या बेहतर, इसे बंद करें और इसे मर्ज अनुरोध के साथ भरें तब कोड को PROD पर तैनात किया जाएगा। इस प्रकार, हम PROD में अप-टू-डेट विज़ार्ड प्राप्त करते हैं, जिसमें सब कुछ ठीक होना चाहिए, और एसटीजी में नए कोड के विकास और परीक्षण के लिए शाखाएं। इस कार्यान्वयन के लिए, हमें गैर-नवीनतम चित्रों को अपलोड करने के लिए निर्देश चाहिए, Dockerrun.aws.json को Dockerrun.aws.stg.json पर कॉपी करें, और Dockerrun.aws.prod.json (सिर्फ सुविधा के लिए) के लिए Dockerrun.aws.json का नाम बदलें।

Dockerrun.aws.stg.json को Dockerrun.aws.prod.json के अलावा सेट करने वाली एकमात्र चीज़ IMAGE_URL है:

Dockerrun.aws.stg.json

 { "AWSEBDockerrunVersion": "1", "Authentication": { "Bucket": "BUCKET_ID", "Key": "KEY_PATH" }, "Image": { "Name": "IMAGE_URL:dev", "Update": "true" }, "Ports": [ { "ContainerPort": "80" } ] }

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

.circleci / config.yml

 version: 2 jobs: build: machine: true steps: - checkout - run: echo "$CI_REGISTRY_PASSWORD" | docker login -u $CI_REGISTRY_USER --password-stdin $CI_REGISTRY - run: docker build -t $CI_REGISTRY/$CI_REGISTRY_ID:dev -f Dockerfile.stg . - run: docker push $CI_REGISTRY/$CI_REGISTRY_ID:dev build-master: machine: true steps: - checkout - run: echo "$CI_REGISTRY_PASSWORD" | docker login -u $CI_REGISTRY_USER --password-stdin $CI_REGISTRY - run: docker build -t $CI_REGISTRY/$CI_REGISTRY_ID:latest . - run: docker push $CI_REGISTRY/$CI_REGISTRY_ID:latest deploy-stg: docker: - image: circleci/python:latest steps: - checkout - run: sudo pip install awsebcli --upgrade - run: | mkdir ~/.aws touch ~/.aws/config chmod 600 ~/.aws/config echo "[profile eb-cli]" > ~/.aws/config echo "aws_access_key_id=$AWS_ACCESS_KEY_ID" >> ~/.aws/config echo "aws_secret_access_key=$AWS_SECRET_ACCESS_KEY" >> ~/.aws/config - run: eb init --region EB_REGION --platform Docker EB_APP - run: cp Dockerrun.aws.stg.json Dockerrun.aws.json - run: eb use EB_ENV_STG --region EB_REGION - run: eb deploy -v --staged --profile eb-cli deploy-prod: docker: - image: circleci/python:latest steps: - checkout - run: sudo pip install awsebcli --upgrade - run: | mkdir ~/.aws touch ~/.aws/config chmod 600 ~/.aws/config echo "[profile eb-cli]" > ~/.aws/config echo "aws_access_key_id=$AWS_ACCESS_KEY_ID" >> ~/.aws/config echo "aws_secret_access_key=$AWS_SECRET_ACCESS_KEY" >> ~/.aws/config - run: eb init --region EB_REGION --platform Docker EB_APP - run: cp Dockerrun.aws.prod.json Dockerrun.aws.json - run: eb use EB_ENV_STG --region EB_REGION - run: eb deploy -v --staged --profile eb-cli workflows: version: 2 build: jobs: - build: filters: branches: ignore: - master - deploy-stg: requires: - build filters: branches: ignore: - master build-deploy: jobs: - build-master: filters: branches: only: - master - deploy-prod: requires: - build-master filters: branches: only: - master

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

CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD को डॉक इमेज स्टोरेज एक्सेस करने की आवश्यकता है - वही चीज जो हम cr.json में डालते हैं, केवल base64 के बिना

CI_REGISTRY / CI_REGISTRY_ID एक टैग के बिना एक अद्वितीय छवि URL बनाते हैं

AWS_ACCESS_KEY_ID और AWS_SECRET_ACCESS_KEY - नाम स्वयं के लिए बोलते हैं, ये उपयोगकर्ता के लिए AWS क्रेडिट हैं, जिनकी ओर से CircleCI तैनात करेगा। AWS IAM पर जाएं और एक उपयोगकर्ता बनाएं, उसे प्रशासकों के समूह में जोड़ें और केवल प्रोग्रामेटिक एक्सेस प्रदान करें। याद रखें कि AWS_SECRET_ACCESS_KEY केवल एक बार देखने / कॉपी करने के लिए उपलब्ध है, शो लिंक पर क्लिक करने के बाद, आप इसे फिर से नहीं देखेंगे।

CircleCI कॉन्फ़िगरेशन चरणों पर वापस जाएं। जादू क्या है? चेकआउट, वर्तमान कार्य निर्देशिका में गिट शाखा से स्रोत कोड को लोड करता है, यह प्रक्रिया हर काम में दोहराई जाती है। निर्माण प्रक्रिया में, हम क्रमिक रूप से रिपॉजिटरी में लॉग इन करते हैं, XXX: देव के टैग के तहत Dockerfile.stg पर आधारित कोड एकत्र करते हैं और इसे रिपॉजिटरी को भेजते हैं। बिल्ड-मास्टर वही करता है, केवल उस निर्माण के लिए जो XXX: नवीनतम टैग के तहत "सामान्य" डॉकफाइल का उपयोग करता है।

तैनाती-एसटीजी एडब्ल्यूएस ईबी सीएलआई स्थापित करता है और ~ / .aws / config फ़ाइल में एक प्राधिकरण प्रोफाइल बनाता है, जो सीएलआई के लिए सही ढंग से काम करने के लिए आवश्यक है, फिर सीएलआई के लिए चर को आरंभीकृत करता है - आपको उस क्षेत्र को निर्दिष्ट करने की आवश्यकता होगी जिसे आप चुनते हैं, मंच - हमेशा डॉकटर और आपके आवेदन का नाम। इसके बाद, हम Dockerrun.aws.stg.json की सामग्री को नई Dockerrun.aws.json फ़ाइल में कॉपी करते हैं और, विशिष्ट वातावरण और क्षेत्र का उपयोग करके, बनाए गए प्राधिकरण प्रोफ़ाइल का उपयोग करके हमारे एप्लिकेशन को तैनात करने के लिए कमांड देते हैं। डिफ़ॉल्ट रूप से, इस आदेश के परिणामस्वरूप, मॉनिटर की गई शाखा का सभी कोड एक ज़िप आर्काइव में समाप्त हो जाएगा, जिसे ElasticBeanstalk पर डाउनलोड किया जाएगा और वहां अनपैक किया जाएगा, लेकिन यह ऑपरेशन अपेक्षाकृत महंगा है, इसीलिए हमने एक नई Dockerrun.aws.json फ़ाइल बनाई है, जो हमारे द्वारा बनाए गए के लिए पर्याप्त है। दूरस्थ छवि, और हमें केवल इसे अपलोड करना होगा, वास्तव में। ऐसा करने के लिए, प्रोजेक्ट रूट में .ebignore फ़ाइल बनाएँ:

.ebignore

 * !Dockerrun.aws.json

यह फ़ाइल .itignore सिंटैक्स का उपयोग करती है और यह .itignore है, लेकिन Git CLI के लिए नहीं, बल्कि AWS EB CLI के लिए है। इस फाइल में, मैं सीएलआई से कहता हूं कि डॉकेरुन.वेसजसन को छोड़कर सभी फाइलें छोड़ दें। यही है, अब जब आप ElasticBeanstalk में तैनाती-एसटीजी नौकरी चलाते हैं, तो केवल हमारे द्वारा बनाई गई फ़ाइल भेजी जाएगी। तैनाती-ठेस एक ही काम करता है, केवल Dockerrun.aws.prod.json फ़ाइल की सामग्री को Dockerrun.aws.json को कॉपी करता है, और अंतिम सर्किल प्रारूप में कार्य के अनुक्रम का एक संकेत है (निर्माण के बाद निर्माण और तैनाती के बाद ठेस -मास्टर), और किन शाखाओं पर डेटा की तलाश है (अनदेखा करें: - मास्टर और केवल: - मास्टर)।

थोड़ा अलग मामला एडब्ल्यूएस ईसीआर के साथ है, जैसा कि मैंने वादा किया था, हम इसे वापस करेंगे। आपको ECR में दूरस्थ रूप से लॉग इन करने और cr.json फ़ाइल बनाने की आवश्यकता नहीं है, क्योंकि ElasticBeanstalk "व्यक्ति में एक भाई को जानता है"। तदनुसार, Dockerrun.aws.json अलग दिखाई देगा - बस कोई प्रमाणीकरण ब्लॉक नहीं होगा:

Dockerrun.aws.json (AWS ECR)

 { "AWSEBDockerrunVersion": "1", "Image": { "Name": "IMAGE_URL", "Update": "true" }, "Ports": [ { "ContainerPort": "80" } ] }

लेकिन फिर प्रमाणीकरण कैसे होगा? तथ्य यह है कि ईसीआर तक पहुंचने वाली सेवा के पास अधिकारों का एक निश्चित सेट है, जो बदले में कुछ सुरक्षा नीतियों पर आधारित हैं। हमारे मामले में, जब एक तीसरे पक्ष के सर्वर (सीआई) से AWS CLI के माध्यम से तैनाती शुरू की जाती है, तो "aws-flexbeanstalk-ec2-role" भूमिका का उपयोग किया जाता है, इसे AWS IAM में भूमिका अनुभाग में ढूंढें और अतिरिक्त नीति "AmazonEC2ContainerRegistryReadOnly" को इसमें संलग्न करें। अब एक निजी रिपॉजिटरी से अपने "पड़ोसी" तक डाउनलोड करने में त्रुटियों के बिना सफल होगा।

लेकिन यह बिल्कुल उसी VPC से लोड हो रहा है, CLI के माध्यम से docker लॉगिन कमांड "ट्रिक्स के बिना" भी नहीं है: आपको AWS CLI के माध्यम से डॉकर्स को (सुनिश्चित रूप से) प्राप्त करना चाहिए, इसके लिए एक कमांड है

aws ecr get-login --region REGION --no-include-email

यह कमांड आपको फॉर्म डॉक लॉगिन की एक पंक्ति लौटा देगा ..., बस, कंसोल में आपको निष्पादित करने की आवश्यकता है

eval $(aws ecr get-login --region EB_REGION --no-include-email)

कमांड को पहले प्रमाणीकरण के लिए एक स्ट्रिंग प्राप्त होगी, और फिर संबंधित प्रक्रिया शुरू होगी। AWS ECR के लिए इन नियमों को ध्यान में रखते हुए, CircleCI के लिए निर्देश फ़ाइल इस तरह दिखाई देगी:

.circleci / config.yml (एडब्ल्यूसी ईसीआर के लिए)

 version: 2 jobs: build: docker: - image: circleci/python:latest steps: - checkout - run: sudo pip install awscli --upgrade - run: | mkdir ~/.aws touch ~/.aws/config chmod 600 ~/.aws/config echo "[profile eb-cli]" > ~/.aws/config echo "aws_access_key_id=$AWS_ACCESS_KEY_ID" >> ~/.aws/config echo "aws_secret_access_key=$AWS_SECRET_ACCESS_KEY" >> ~/.aws/config - setup_remote_docker - run: eval $(aws ecr get-login --region EB_REGION --no-include-email) - run: docker build -t $CI_REGISTRY/$CI_REGISTRY_ID:dev -f Dockerfile.stg . - run: docker push $CI_REGISTRY/$CI_REGISTRY_ID:dev build-master: docker: - image: circleci/python:latest steps: - checkout - run: sudo pip install awscli --upgrade - run: | mkdir ~/.aws touch ~/.aws/config chmod 600 ~/.aws/config echo "[profile eb-cli]" > ~/.aws/config echo "aws_access_key_id=$AWS_ACCESS_KEY_ID" >> ~/.aws/config echo "aws_secret_access_key=$AWS_SECRET_ACCESS_KEY" >> ~/.aws/config - setup_remote_docker - run: eval $(aws ecr get-login --region EB_REGION --no-include-email) - run: docker build -t $CI_REGISTRY/$CI_REGISTRY_ID:latest . - run: docker push $CI_REGISTRY/$CI_REGISTRY_ID:latest deploy-stg: docker: - image: circleci/python:latest steps: - checkout - run: sudo pip install awsebcli --upgrade - run: | mkdir ~/.aws touch ~/.aws/config chmod 600 ~/.aws/config echo "[profile eb-cli]" > ~/.aws/config echo "aws_access_key_id=$AWS_ACCESS_KEY_ID" >> ~/.aws/config echo "aws_secret_access_key=$AWS_SECRET_ACCESS_KEY" >> ~/.aws/config - run: eb init --region EB_REGION --platform Docker EB_APP - run: cp Dockerrun.aws.stg.json Dockerrun.aws.json - run: eb use EB_ENV_STG --region EB_REGION - run: eb deploy -v --staged --profile eb-cli deploy-prod: docker: - image: circleci/python:latest steps: - checkout - run: sudo pip install awsebcli --upgrade - run: | mkdir ~/.aws touch ~/.aws/config chmod 600 ~/.aws/config echo "[profile eb-cli]" > ~/.aws/config echo "aws_access_key_id=$AWS_ACCESS_KEY_ID" >> ~/.aws/config echo "aws_secret_access_key=$AWS_SECRET_ACCESS_KEY" >> ~/.aws/config - run: eb init --region EB_REGION --platform Docker EB_APP - run: cp Dockerrun.aws.prod.json Dockerrun.aws.json - run: eb use EB_ENV_STG --region EB_REGION - run: eb deploy -v --staged --profile eb-cli workflows: version: 2 build: jobs: - build: filters: branches: ignore: - master - deploy-stg: requires: - build filters: branches: ignore: - master build-deploy: jobs: - build-master: filters: branches: only: - master - deploy-prod: requires: - build-master filters: branches: only: - master

docker-in-docker setup_remote_docker , . , :

, , () . «» . ( - ) , , , .

GitHub: tutorial-aws-symfony-ci

CI के माध्यम से AWS पर सिम्फनी + रिएक्ट एप्लिकेशन तैनात करें

More articles: