مساء الخير ، سأوضح في هذا المقال كيفية نشر تطبيق Symfony 4 على AWS. يوجد مثال على مثل هذه العملية في الوثائق الرسمية ، لكن روايتي ليست تافهة مثل تنزيل أرشيف مضغوط بتطبيق ما. في ساحة عام 2019 ، في وضع عامل الالتحام ، بدأت أخيرًا في تضمين هندسة خدمات micros و CI / CD في أدوات مهندسي DevOps ليس فقط ، ولكن أيضًا مطوري
البشر العاديين. لجعل المقالة أكثر إثارة للاهتمام ، أضفت واجهة إلى React.JS ، لتغطية احتياجات المزيد من الأشخاص ، إذا كان التطبيق الخاص بك لا يستخدم Encore - لا يهم ، سأشير إلى كيفية تغيير ملف Docker بالنسبة لك ، ودعم React.JS يؤثر فقط عليه . من سيكون مهتمًا بهذا البرنامج التعليمي؟ بادئ ذي بدء ، إنه موجه لمطوري PHP الذين يرغبون في تغيير ممارسة النشر الخاصة بهم - للابتعاد عن الشرائع المعتادة واستخدام عامل النقل لحزم تطبيقاتهم ووضع الصورة. لكن يمكنك أن تعمق أكثر قليلاً ، وسوف يهدف السرد الإضافي إلى نشر التطبيق تلقائيًا من Git عبر منصة CI / CD (سيتم استخدام CircleCI ، ولكن إذا كنت مهتمًا بتهيئة Gitlab ، فاكتب في التعليقات ، وسأرفقها). في الواقع ، ليس من المهم للغاية بالنسبة لـ React / PHP ما إذا كان لديك تطبيق أو ، على سبيل المثال ، .NET Core ، سيكون هذا الجزء مثيرًا للمطورين لاكتساب مهارات أتمتة النشر بشكل عام. شفرة المصدر متاحة في مستودع جيثب ، رابط في نهاية المقال. حسنا ، دعنا نذهب!
أفترض أن لديك تطبيق Symfony الخاص بك ، لكن لأغراض العرض التوضيحي ، رسمت "hello، world!" تحتوي على الحزم التالية:
`symfony/webpack-encore-bundle symfony/form symfony/orm-pack symfony/profiler-pack symfony/security-bundle symfony/twig-bundle symfony/validator symfony/phpunit-bridge` هو مجموعة بسيطة من الرجل المحترم. في الوقت الحالي ، يجب أن تكون بنية المجلد كما يلي:
أنت الآن بحاجة إلى تكوين البنية التحتية السحابية الخاصة بك. لن أركز على تسجيل وتفعيل الفترة التجريبية لـ AWS ، في هذه المرحلة نحتاج إلى إنشاء مثيلات DB 2 - سأستخدم نوعين من البيئة: STG (التدريج) لاختبار تنفيذ "ميزات" جديدة و PROD (إنتاج) على أنه "قتال" مباشر الخادم. تمت كتابة الكثير من المقالات حول فوائد قاعدة بيانات الخدمة المدارة ، علاوة على ذلك ، فإننا نتابع بشكل أساسي راحة المطور في هذا الدليل ، وبالتالي نستخدم RDS ، بدلاً من رفع خادم قاعدة البيانات المنفصل. لقد استخدمت PostgreSQL باعتباره DBMS لهذا المثال ، أنت حر في اختيار أي واحد يناسبك ، وانتقل إلى خدمة RDS وإنشاء مثيلين من السعة والحجم اللذين تحتاجهما. نظرًا لأن ملف
.env متاح لنا "خارج الصندوق" في Symfony ، فسنستخدمه ، على سبيل المثال ، في PROD ، وسنقوم STG بإنشاء نسخة من
.env.stg وتغيير
APP_ENV=dev إلى
APP_ENV=stg في
.env.stg و
APP_ENV=dev على
APP_ENV=prod in
.env ، وأدخل أيضًا معلمات اتصال
.env لكل من الحالات التي تم إنشاؤها.
عظيم ، وقد أحرز بداية! كما تعلم ، يتم تثبيت تبعيات symfony من خلال الملحن ، لتثبيته ، استخدم ملف composer.sh ، الذي نضعه في جذر المشروع:
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 الخاص بك في جذر المشروع:
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
يمكن استخدام الملفات "كما هي" ، لا يتم استخدام وحدات ماكرو للتغييرات. دعنا نسير عبر محتويات Dockerfile لتبديد لمسة "السحر". بصفتنا "الأساس" ، فإننا نستخدم صورة PHP 7.2.19 الرسمية مع خادم الويب Apache المدمج (أنت حر في استخدام أي من اختيارك ، وتكوين حزمة مع Nginx ، وهكذا ، في هذا المثال ، أستخدم ما ورد أعلاه باعتباره الأكثر ، في رأيي ، مريحة). ليس خط التعريض مهمًا في الوقت الحالي ، في حد ذاته لا يفعل شيئًا ، ولكن في المستقبل سيتم استخدامه بواسطة ElasticBeanstalk ، والذي يحتاج إلى نشره بشكل صحيح. تستخدم الإنشاءات التالية إعدادات الإنتاج المحسّنة لـ PHP التي أوصت بها الشركة المصنعة ، وقم بتنشيط mod_rewrite لـ Apache وزيادة الحد الأقصى لحجم الذاكرة لبرنامج نصي PHP من 128 إلى 256 ميغابايت ، وهو أمر ضروري لكي يعمل الملحن بشكل صحيح. بعد ذلك ، نقوم بتثبيت التطبيقات الضرورية ، تبعيات وإضافات PHP ، ونهيئها على الفور. نقوم بتعيين المجلد / var / www إلى دليل العمل الخاص بطلبنا - سيتم نسخ الكود المصدري لتطبيقنا هناك. نظرًا لأن apache ، افتراضيًا ، يستخدم / var / www كنقطة إدخال لمضيفه ، وملف فهرس symfony موجود في / var / www / public ، فإننا نقوم بتغيير جذر مستند apache بالبناء التالي. ثم نقوم بتثبيت الملحن والعقدة والغزل بالتتابع (إذا كنت لا تستخدم encore / react.js في تطبيقك ، فأنت لا تحتاج إلى آخر نقطتين). أخيرًا ، نقوم بنسخ شفرة المصدر الخاصة بنا وبدء تثبيت التبعيات من خلال الملحن لـ symfony والغزل من أجل react.js. يكمن معنى Dockerfile الخاص بـ STG في التعليمة ما قبل الأخيرة لرسو السفن - نسخ .env.stg إلى .env ، لذلك سيحتوي ملف .env في صورة STG على المعلمات ذات الصلة بهذه البيئة. يمكنك محليًا (بالطبع مع تثبيت عامل ميناء) جمع الصورة وتشغيلها والتأكد من أن التطبيق يعمل ولا يحتاج إلى أي شيء آخر لهذا العمل:
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 وقم بإنشاء تطبيق جديد باسمه ووصفه. ثم قم بإنشاء بيئتين تم ذكرهما مسبقًا: STG و PROD ، وإنشاء كلا البيئتين كبيئة خادم ويب ، وحدد "Docker" كنظام أساسي ، واترك نموذج التطبيق كرمز التطبيق. يتم النشر على ElasticBeanstalk عن طريق تحميل ملفات أو تعليمات المشروع ، وعادةً في أرشيف مضغوط. في حالتنا ، سيكون التدفق كالتالي: نقوم بتجميع صورة عامل النقل الخاصة بالتطبيق الخاص بنا ، ثم تحميلها في المستودع وتحميل التعليمات بدلاً من أرشيف المصدر أو صورة عامل النقل ، والتي تخبر شركة FlexBeanstalk بأخذ الصورة من الخادم البعيد ونشرها. وكل هذا تلقائي.
لنبدأ بإنشاء مستودع لتخزين صور عامل ميناء. هناك 2 خيارات:
1 - مشروعك خاص ورمزه مغلق ويجب تخزين المستودع على التوالي. في هذه الحالة ، يمكنك الاحتفاظ بسجل الصور الخاص بك في مكان ما أو استخدام سحابة خاصة. AWS لديه ECR لهذه الأغراض ، يمكنك إنشاء مستودع هناك ، ولكن لا أحد يفرض عليك القيام بذلك.
2 - لديك مشروع مفتوح المصدر ويمكنك استخدام dockerhub.
في مثالنا ، الشفرة مفتوحة ، لكنني سأوضح كيفية استخدام المستودعات المغلقة ، بعد فهم هذه العملية ، لن يكون توصيل صورة من dockerhub أمرًا صعبًا. أول ما نحتاج إليه هو إنشاء المستودع نفسه ، وبعد ذلك ستحصل على URI الفريد. سيتم طرح السرد الإضافي لطرف ثالث (وليس مستودعات AWS ECR وتكاملها) ، بالنسبة إلى ECR سأكتب بعد ذلك.
بعد إنشاء مستودع التخزين ، نحتاج إلى تسجيل الدخول إلى هذه الخدمة وهناك خدعة بسيطة ... انتقل إلى إعدادات عامل التثبيت المثبت محليًا وتأكد من أن لديك خيار حفظ كلمات المرور في وحدة التخزين الخارجية (لمستخدمي نظام التشغيل MacOS: "قم بتخزين تسجيلات دخول عامل ميناء آمن" في macOS Keychain ") ، وإلا فإن ملف التكوين الذي نحتاجه سيكون فارغًا. وهكذا ، نحن نسمح في الخدمة المحددة بتخزين سجلات صورك:
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" } ] }
بشكل عام ، تبدو التعليمة كما يلي: بعد تسجيل الدخول باستخدام المفتاح الموجود بواسطة KEY_PATH في ذاكرة التخزين S3 BUCKET_ID ، قم بتحميل الصورة عن طريق الكتابة فوق IMAGE_URL بالكتابة فوق الملف المحفوظ ، وابدأ تشغيله بإعادة توجيه المنفذ 80 إلى نفس المنفذ على الحاوية. الآن عن الثوابت المستخدمة:
BUCKET_ID هو "حقيبة الظهر" التي تم إنشاؤها تلقائيًا من أجلك في خدمة S3 ، والتي تحتوي على شكل elasticbeanstalk-REGION-HASH ، هذا هو المكان الذي يحدد فيه النظام موقع ملفات الخدمة لـ ElasticBeanstalk ، بما في ذلك ملفات التطبيقات التي تقوم بتنزيلها باستخدام زر "التحميل والنشر".
KEY_PATH - المسار إلى ملف التخويل إلى مستودع الصور ، يمكنني استخدام تنسيق APP_NAME / cr.json ، أي في المجلد داخل BUCKET_ID تحت اسم طلبي (أقوم بإنشائي ، إن لم يكن بعد) ، أضع ملف cr.json الذي يحتوي على الكود الذي تم استلامه بعد الترخيص في السجل الصور محليا:
BUCKET_ID / APP_NAME / cr.json { "REGISTRY" : { "auth" : "BASE64_ENCODED_TOKEN" } }
IMAGE_URL هو URI الفريد لسجل صورتك + علامة الصورة نفسها ، يجب أن يكون كل شيء واضحًا هنا.
هذا كل شيء ، الآن يمكننا تنزيل هذا الملف كإصدار من تطبيقنا في ElasticBeanstalk ، وسيقوم بسحب الصورة المحددة ونشرها.
يبقى لأتمتة هذه العملية. ولكي أكون ممتعًا تمامًا ، سأنفذ تسلسل الخطوات الخاصة بالتدفق التالي: بالنسبة لجميع التعهدات غير الموجودة في الفرع الرئيسي ، سيتم جمع الصورة ونشرها في بيئة STG ، وإذا دفعنا إلى المعلم ، أو أفضل من ذلك ، أغلقناه وملأناه بطلب دمج ، ثم سيتم نشر الرمز على PROD. وبالتالي ، نحصل على PROD معالجًا محدثًا ، يكون فيه كل شيء على ما يرام ، وفروعًا لتطوير واختبار رمز جديد في STG. لهذا التطبيق ، نحتاج إلى تعليمات لتحميل صور غير أحدث ، ونسخ Dockerrun.aws.json إلى Dockerrun.aws.stg.json ، وإعادة تسمية Dockerrun.aws.json إلى Dockerrun.aws.prod.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" } ] }
كما قلت في بداية المقال ، بصفتي CI / CD ، سوف أستخدم CircleCI ، والتي ، وفقًا لمشاعري الشخصية ، أسرع من GitlabCI ، إذا كنت أستخدم نسخة SaaS المجانية. ستعمل Free Travis ، ولكن نظرًا لأنها لا تعمل مع مستودعات git الخاصة ، لم أقم بإجراء مظاهرة على وجه التحديد حتى لا تكون هناك خيبة أمل عندما تكون هناك حاجة إلى مثل هذه الفرصة. سأترك إعدادات المشروع في CircleCI للقراء للدراسة لأنفسهم ، وسأقدم الإرشادات اللازمة للنشر بنفسي - في جذر مشروعنا سنقوم بإنشاء مجلد .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
لقد رسمت التدفق نفسه قبل ذلك بقليل ، حيث يتم ترجمته إلى تعليمات yaml لـ CircleCI ، دعنا نذهب من خلال تنفيذ خطوات محددة. من المهم ملاحظة وجود متغيرات البيئة المعرفة لـ CI والتي سيتم استخدامها خلال العمل:
هناك حاجة إلى 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. ما هو السحر؟ يقوم Checkout بتحميل الكود المصدري من فرع git إلى دليل العمل الحالي ، وتتكرر هذه العملية في كل وظيفة. في عملية الإنشاء ، نقوم بتسجيل الدخول بالتسلسل إلى المستودع ، ونجمع الكود استنادًا إلى Dockerfile.stg تحت العلامة XXX: dev ونرسله إلى المستودع. يقوم build-master بنفس الشيء ، فهو يستخدم Dockerfile "العادي" تحت العلامة XXX: الأحدث للتجميع.
نشر-stg بتثبيت AWS EB CLI وإنشاء ملف تعريف التخويل في ملف ~ / .aws / config ، وهو أمر ضروري ليعمل CLI بشكل صحيح ، ثم تهيئة المتغيرات لـ CLI - ستحتاج إلى تحديد المنطقة التي تختارها ، والنظام الأساسي - دومًا Docker واسم التطبيق الخاص بك. بعد ذلك ، نقوم بنسخ محتويات Dockerrun.aws.stg.json إلى ملف Dockerrun.aws.json الجديد ، وباستخدام البيئة والمنطقة المحددة ، نعطي الأمر لنشر تطبيقنا باستخدام ملف تعريف الترخيص الذي تم إنشاؤه. افتراضيًا ، كنتيجة لهذا الأمر ، سينتهي بكافة رمز الفرع الذي يتم مراقبته في أرشيف مضغوط ، سيتم تنزيله على ElasticBeanstalk وتفريغه هناك ، لكن هذه العملية باهظة الثمن نسبيًا ، لذلك أنشأنا ملف Dockerrun.aws.json جديدًا ، وهو ما يكفي لنشر الملف الذي أنشأناه الصورة عن بعد ، ونحن بحاجة فقط لتحميله ، في الواقع. للقيام بذلك ، قم بإنشاء ملف .ebignore في جذر المشروع:
يستخدم هذا الملف بناء جملة .gitignore وهو .gitignore ، ولكن ليس لـ Git CLI ، ولكن AWS EB CLI. في هذا الملف ، أخبر CLI بتخطي جميع الملفات باستثناء Dockerrun.aws.json. هذا كل شيء ، الآن عند تشغيل مهمة publish-stg في ElasticBeanstalk ، سيتم إرسال الملف الذي أنشأناه فقط. نشر-prod يفعل نفس الشيء ، فقط نسخ محتويات ملف Dockerrun.aws.prod.json إلى Dockerrun.aws.json ، والأخير هو إشارة إلى تسلسل العمل في تنسيق CircleCI (publish-stg بعد الإنشاء ونشر-prod بعد الإنشاء ماجستير) ، وعلى أي فروع تبحث البيانات عنه (تجاهل: - ماجستير وفقط: - ماجستير).
هناك مسألة مختلفة قليلاً مع AWS ECR ، كما وعدت ، سنعود إليها. لا تحتاج إلى تسجيل الدخول عن بعد إلى ECR وإنشاء ملف cr.json ، حيث أن ElasticBeanstalk "يعرف أخًا شخصيًا". وفقًا لذلك ، ستبدو Dockerrun.aws.json مختلفة - لن يكون هناك ببساطة كتلة مصادقة:
Dockerrun.aws.json (AWS ECR) { "AWSEBDockerrunVersion": "1", "Image": { "Name": "IMAGE_URL", "Update": "true" }, "Ports": [ { "ContainerPort": "80" } ] }
ولكن كيف إذن ستحدث المصادقة؟ الحقيقة هي أن الخدمة التي تصل إلى ECR لها مجموعة معينة من الحقوق ، والتي بدورها تعتمد على سياسات أمنية معينة. في حالتنا ، عند بدء النشر عبر AWS CLI من خادم جهة خارجية (من CI) ، يتم استخدام دور "aws-elasticbeanstalk-ec2-role" ، ابحث عنه في AWS IAM في قسم الأدوار وإرفاق السياسة الإضافية "AmazonEC2ContainerRegistryReadOnly" بها. الآن ينجح التنزيل من مستودع خاص إلى "جاره" دون أخطاء.
ولكن هذا يتم تحميله بالضبط من نفس VPC ، من خلال CLI ، لا يكون أمر تسجيل الدخول إلى عامل الإرساء "بدون حيل": تحتاج إلى الحصول على (الحصول على) أرصدة لتسجيل دخول عامل ميناء عبر 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 (لـ AWS ECR) 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