عصور ما قبل التاريخ
في يوم من الأيام كنت بحاجة إلى نشر بيئة تطوير لمشروعي. لقد سئمت Vagrant بالفعل وأرادت أن يكون لها بيئة تطوير واحدة لجميع المشاركين في المشروع تكون مماثلة لخادم الإنتاج. وبناءً على ذلك ، بعد الاستماع إلى معلومات حول عامل إرساء محب ، قررت البدء في التعامل معها. بعد ذلك ، سأحاول أن أصف بأكبر قدر ممكن من التفاصيل جميع الخطوات من تثبيت عامل إرساء على شبكة LAN إلى نشر منتج إلى KVM.
مكدس التكنولوجيا الأصلي:- عامل ميناء
- سيمفوني 4
- nginx
- php-fpm
- postgresql
- البحث المرن
- rabbitmq
- جنكينز
الحديد:- كمبيوتر محمول تحت نظام التشغيل Ubuntu 16.04
- خادم إنتاج على استضافة KVM
لماذا ، بالإضافة إلى المكدس التكنولوجي ، قمت أيضًا بإدراج المكدس الحديدي؟إذا لم تكن قد عملت من قبل مع عامل إرساء ، فقد تواجه عددًا من المشاكل المتعلقة على وجه التحديد بالأجهزة أو نظام تشغيل الكمبيوتر المحمول أو نوع الاستضافة الافتراضية.
الجانب الأول وربما الأهم عند بدء العمل مع عامل الميناء هو نظام تشغيل الكمبيوتر المحمول. أسهل طريقة للعمل مع عامل الميناء هي أنظمة Linux. إذا كنت تعمل على نظام Windows أو Mac ، فستواجه بعض الصعوبات بنسبة 100٪ ، ولكن هذه الصعوبات لن تكون حرجة وإذا كنت تريد "google" كيفية إصلاح ذلك ، فلن تكون هناك مشاكل.
السؤال الثاني هو الاستضافة. لماذا الاستضافة مطلوبة مع نوع المحاكاة الافتراضية KVM؟ والسبب هو أن المحاكاة الافتراضية VPS تختلف اختلافًا كبيرًا عن KVM ولن تتمكن ببساطة من تثبيت docker على VPS ، حيث تقوم VPS بتخصيص موارد الخادم ديناميكيًا.
المجموع الفرعي: للحصول على أسرع بداية على عامل الإرساء ، من الأفضل اختيار Ubuntu كنظام تشغيل محلي واستضافة KVM (أو خادمك الخاص). علاوة على ذلك ، ستعتمد القصة بدقة على هذين المكونين.
إرساء Docker لشبكة LAN
التثبيت
تحتاج أولاً إلى تثبيت عامل الميناء نفسه محليًا. يمكنك الاطلاع على تعليمات التثبيت على
رابط الموقع
الرسمي للوثائق الرسمية لـ ubuntu (تحتاج إلى تثبيت docker و docker-compose) ، أو عن طريق تشغيل الأمر في وحدة التحكم:
curl -sSl https://get.docker.com/ | sh
يقوم هذا الأمر بتثبيت docker و docker-compose. بعد ذلك ، تحقق من إصدار عامل الميناء بالأمر:
docker --version
لقد بدأت هذا الأمر برمته في إصدار عامل الميناء 18.06.0-ce.
اكتمال التثبيت!
الوعي
للعمل مع شيء أقل نجاحًا - تحتاج إلى فكرة عن كيفية عمله. إذا كنت قد عملت سابقًا فقط مع Vagrant أو شيء مماثل ، فسيكون الأمر غير عادي للغاية وغير مفهوم في البداية ، ولكن هذا فقط في البداية.
سأحاول رسم القياس ل Vagrant. يمكن للكثيرين الآن أن يقولوا إن مقارنة Vagrant و Docker خطأ جوهري. نعم ، أوافق على ذلك ، لكنني لن أقارنهم ، سأحاول فقط أن أنقل إلى الوافدين الجدد الذين يعملون فقط مع نظام عمل Vagrant the Docker ، مناشدين ما يعرفه الوافدون الجدد.
رؤيتي للحاوية "على الأصابع" هي كما يلي: كل حاوية هي عالم معزول صغير. يمكن تصور كل حاوية كما لو كانت Vagrant صغيرة مثبت عليها أداة واحدة فقط ، على سبيل المثال nginx أو php. في البداية ، يتم عزل الحاويات بشكل عام عن كل شيء حولها ، ولكن من خلال التلاعبات الصعبة ، يمكنك تكوين كل شيء بحيث تتواصل مع بعضها البعض وتعمل معًا. هذا لا يعني أن كل حاوية هي آلة افتراضية منفصلة ، على الإطلاق. لكن الأمر أسهل للفهم الأولي ، كما يبدو لي.
يقوم Vagrant ببساطة بتقطيع جزء من موارد جهاز الكمبيوتر الخاص بك ، وإنشاء جهاز افتراضي ، وتثبيت نظام تشغيل عليه ، وتثبيت المكتبات ، وتثبيت كل ما كتبته في البرنامج النصي بعد التشرد. في النهاية ، يبدو الأمر مثل هذا:
→
عرض التخطيطييعمل Docker ، بدوره ، بشكل مختلف جذريًا. لا يقوم بإنشاء أجهزة افتراضية. تنشئ Docker حاويات (في الوقت الحالي ، يمكنك التفكير فيها على أنها آلات افتراضية دقيقة) باستخدام نظام التشغيل Alpine ومكتبات 1-3 الضرورية للتطبيق للعمل ، على سبيل المثال php أو nginx. في الوقت نفسه ، لا يحظر Docker موارد نظامك لنفسه ، ولكنه ببساطة يستخدمها حسب الضرورة. في النهاية ، لتوضيح ذلك ، سيبدو شيئًا مثل هذا:
→
عرض التخطيطيتحتوي كل حاوية على صورة يتم إنشاؤها منها. الغالبية العظمى من الصور هي امتداد لصورة أخرى ، على سبيل المثال ، Ubuntu xenial أو Alpine أو Debian ، حيث يتم لف برامج تشغيل إضافية ومكونات أخرى في الأعلى.
كانت صورتي الأولى لـ php-fpm. توسع صورتي الصورة php الرسمية: 7.2-fpm-alpine3.6. هذا ، في جوهره ، يأخذ الصورة الرسمية ويقدم المكونات التي أحتاجها ، على سبيل المثال ، pdo_pgsql ، imagick ، zip وما إلى ذلك. وبالتالي ، يمكنك إنشاء الصورة التي تحتاجها. إذا كنت تريد ، يمكنك استخدامه
هنا .
مع إنشاء الصور ، كل شيء بسيط للغاية في رأيي إذا تم تصنيعها على أساس زينيال على سبيل المثال ، لكنها تقدم القليل من البواسير إذا تم تصنيعها على أساس جبال الألب. قبل بدء العمل مع عامل الرصيف ، لم أسمع أساسًا عن جبال الألب ، لأن فاجرانت كان يعمل دائمًا معي تحت Ubuntu xenial. Alpine هو نظام تشغيل Linux فارغ ، حيث لا يوجد أي شيء على الإطلاق (الحد الأدنى الأقصى). لذلك ، في البداية ، من غير المريح للغاية العمل معه ، لأنه على سبيل المثال لا يوجد نفس التثبيت apt-get (الذي تعتاد عليه) ، ولكن هناك فقط إضافة apk ومجموعة غير معقولة من الحزم. زيادة كبيرة في جبال الألب هي وزنها ، على سبيل المثال ، إذا كان Xenial يزن (بشكل تجريدي) 500 كيس ، فإن Alpine (بشكل تجريدي) يبلغ حوالي 78 كيسًا. ماذا يؤثر حتى هذا؟ وهذا يؤثر على سرعة البناء والوزن النهائي لجميع الصور التي سيتم تخزينها على خادمك في النهاية. لنفترض أن لديك 5 حاويات مختلفة وكل شيء يعتمد على الزينيال سيكون وزنها الإجمالي أكثر من 2.5 العربات ، وجبال الألب - حوالي 500 كيس فقط. لذلك ، من الناحية المثالية ، يجب أن نسعى لضمان أن تكون الحاويات رقيقة قدر الإمكان. (رابط مفيد لتثبيت الحزم في حزم Alpine -
Alpine ).
في كل مكان على
مركز عامل الميناء ، يكتبون كيفية تشغيل الحاوية باستخدام
docker run ، ولسبب ما لا يكتبون كيف يمكن إطلاقه من خلال إنشاء عامل الميناء ، ومن خلال إنشاء عامل الميناء ، سيبدأ معظم الوقت ، نظرًا لقلة الصيد بدء تشغيل جميع الحاويات والشبكات والمنافذ المفتوحة يدويًا والمزيد. يبدو Docker-compose نيابة عن المستخدم وكأنه ملف yaml مع الإعدادات. يتضمن وصفا لكل من الخدمات التي يجب أن تبدأ. بناء بلدي للبيئة المحلية على النحو التالي:
version: '3.1' services: php-fpm: image: otezvikentiy/php7.2-fpm:0.0.11 ports: - '9000:9000' volumes: - ../:/app working_dir: /app container_name: 'php-fpm' nginx: image: nginx:1.15.0 container_name: 'nginx' working_dir: /app ports: - '7777:80' volumes: - ../:/app - ./nginx/nginx.conf:/etc/nginx/conf.d/default.conf postgres: image: postgres:9.6 ports: - '5432:5432' container_name: 'postgresql' working_dir: /app restart: always environment: POSTGRES_DB: 'db_name' POSTGRES_USER: 'db_user' POSTGRES_PASSWORD: 'db_pass' volumes: - ./data/dump:/app/dump - ./data/postgresql:/var/lib/postgresql/data rabbitmq: image: rabbitmq:3.7.5-management working_dir: /app hostname: rabbit-mq container_name: 'rabbit-mq' ports: - '15672:15672' - '5672:5672' environment: RABBITMQ_DEFAULT_USER: user RABBITMQ_DEFAULT_PASS: password RABBITMQ_DEFAULT_VHOST: my_vhost elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:6.3.0 container_name: 'elastic-search' environment: - discovery.type=single-node - "discovery.zen.ping.unicast.hosts=elasticsearch" - bootstrap.memory_lock=true - "ES_JAVA_OPTS=-Xms512m -Xmx512m" ports: - 9200:9200 - 9300:9300 working_dir: /app volumes: - ../:/app - ./data/elasticsearch:/usr/share/elasticsearch/data volumes: elasticsearch: postgresql:
docker-compose.yaml لـ SF4 هي مجموعة معينة من الخدمات: nginx ، php-fpm ، postgresql ، rabbitmq (إذا كنت بحاجة إليها) ، elasticsearch (إذا كنت بحاجة إليها). بالنسبة للبيئة المحلية ، هذا يكفي. لجعل كل شيء يعمل - هناك مجموعة صغيرة من الإعدادات ، والتي بدونها لن يعمل أي شيء. غالبًا ما تكون هذه الصور والأحجام والمنافذ والبيئة وأعمال_العمل واسم الحاوية. يتم وصف كل شيء لبدء هذه الصورة أو تلك في وثائقها على
hub.docker.com . لا يوجد دائمًا وصف لرسو السفن ، لكن هذا لا يعني أنه لا يعمل معه. من الضروري فقط نقل جميع البيانات الواردة من الأمر docker run إلى docker-compose وسيعمل كل شيء.
على سبيل المثال ، هناك صورة لـ RabbitMQ
هنا . عندما ترى هذا للمرة الأولى ، فإنه يسبب مشاعر وعواطف مختلطة ، ولكن ليس كل شيء مخيفًا جدًا. يشار إلى العلامات في هذه الصورة. عادة علامات - تمثل صور مختلفة ، إصدارات مختلفة من التطبيق مع صور مختلفة قابلة للتوسيع. على سبيل المثال ، تعني العلامة 3.7.7-alpine أن هذه الصورة أرق من ، على سبيل المثال ، 3.7.7 ، لأنها تستند إلى Alpine. حسنًا ، وكذلك في العلامات غالبًا ما تتم الإشارة إلى إصدارات التطبيق. أختار عادةً أحدث إصدار وإصدار مستقر من التطبيق نفسه وصورة جبال الألب.
بعد دراسة العلامة وتحديدها - غالبًا ما ترى شيئًا من هذا النوع:
docker run -d --hostname my-rabbit --name some-rabbit -e RABBITMQ_DEFAULT_USER=user -e RABBITMQ_DEFAULT_PASS=password rabbitmq:3-management
والفكر الأول هو WTF؟ كيفية نقل هذا إلى تكوين عامل الميناء؟
كل شيء سهل للغاية. في الواقع ، يشير هذا السطر إلى جميع المعلمات نفسها الموجودة في ملف yaml ، المختصر فقط. على سبيل المثال ، -e هي بيئة يتم فيها تمرير معلمات مختلفة ، قد تكون هناك أيضًا إدخالات مثل -p - هذه منافذ تسمى منافذ في yaml. وفقًا لذلك ، من أجل استخدام صورة غير مألوفة بطريقة جيدة ، تحتاج فقط إلى "google" تشغيل الاختصارات في عامل الميناء وتطبيق الأسماء الكاملة في ملف yaml.
الآن نعود إلى docker-compose.yml ، الذي ذكرته كعينة أعلاه.
يستخدم هذا المثال صورة php7.2 الخاصة بي التي تم إنشاؤها كملحق للصورة alpp7.2-fpm-alpine الرسمية ، ولكن إذا لم تكن بحاجة إلى العديد من المكتبات الإضافية ، فيمكنك إنشاء ملحق للصورة الرسمية واستخدامها. بقية الصور لشبكة الاتصال المحلية أصلية ورسمية تمامًا.
صورة - تشير إلى الصورة المراد تنزيلها. على سبيل المثال (rabbitmq: 3.7.7-management-alpine).
المنافذ - حدد المنافذ التي ستستخدمها الحاوية (انظر وثائق الصورة). منفذ nginx كمثال هو 80 افتراضيًا. وفقًا لذلك ، إذا كنت ترغب في استخدام المنفذ 80 ، يجب عليك تحديد 80:80 هنا وسيكون موقعك متاحًا على المضيف المحلي. أو يمكنك تحديد 7777: 80 ، وبعد ذلك سيكون موقعك على url localhost: 7777. يعد ذلك ضروريًا بحيث يمكن نشر العديد من المشاريع على نفس المضيف.
مجلدات - يشار هنا الدلائل المشتركة. على سبيل المثال ، يكمن مشروعك في دليل ~ / projects / my-sf4-app ، ويتم تكوين حاوية php للعمل مع دليل / app (كما هو الحال في / var / www / my-sf4-app). وبناءً على ذلك ، سيكون من الملائم للحاوية الوصول إلى المشروع. وفقًا لذلك ، في المجلدات ، نكتب
~/projects/my-sf4-app:/app (انظر هذا المثال في
~/projects/my-sf4-app:/app أعلاه (لقد أشرت إليه بطريقة نسبية ../:/app)).
وبالتالي ، ستتم مشاركة المجلد للحاوية وسيكون قادرًا على تنفيذ إجراءات مختلفة فيه مثل
php bin/console doctrine:migrations:migrate . من السهل أيضًا استخدام هذه الأدلة من أجل حفظ بيانات التطبيق. على سبيل المثال ، postgresql ، يمكنك تحديد دليل لتخزين بيانات قاعدة البيانات ، وعند إعادة إنشاء الحاوية ، لن تحتاج إلى تدوير ملف تفريغ أو تركيبات.
working_dir - يشير إلى دليل عمل الحاوية. في هذه الحالة ، / app (أو عن طريق القياس مع متشرد / var / www / my-sf4-app).
البيئة - يتم تمرير جميع متغيرات الحاوية هنا. على سبيل المثال ، بالنسبة إلى rabbitmq ، يتم إرسال اسم المستخدم وكلمة المرور ، وبالنسبة لـ postgresql ، يتم تمرير الاسم الأساسي واسم المستخدم وكلمة المرور.
container_name حقلاً اختياريًا ، لكنني أفضل تحديده ، لراحة الاتصال بالحاويات. إذا لم يكن محددًا ، فسيتم تعيين الأسماء الافتراضية ذات التجزئة.
هذه هي المعلمات الرئيسية التي يجب تحديدها. يمكن أن يكون الباقي اختياريًا لإعدادات إضافية ، أو وفقًا لوثائق الحاوية.
الآن ، لبدء كل هذا ، تحتاج إلى تشغيل الأمر
docker-compose up -d في الدليل حيث يوجد ملف docker-compose.
كيف وأين لتخزين كل هذا لشبكة LAN؟
بالنسبة للشبكة المحلية ، أستخدم مجلد عامل الميناء في جذر المشروع.
يحتوي على مجلد البيانات الذي أقوم فيه بتخزين جميع المعلومات postgresql و elasticsearch ، بحيث عندما تقوم بإعادة إنشاء المشروع ، لن تضطر إلى لف التركيبات من البداية. هناك أيضًا بابا nginx أقوم فيه بتخزين التكوين لحاوية nginx المحلية. أقوم بمزامنة هذه المجلدات في docker-compose.yml مع الملفات والمجلدات المقابلة في الحاويات. في رأيي أيضًا أنه من الملائم جدًا كتابة نصوص باش للعمل مع عامل الميناء. على سبيل المثال ، يقوم البرنامج النصي start.sh بتشغيل الحاويات ، ثم تثبيت الملحن وتنظيف ذاكرة التخزين المؤقت والترحيل. كما أنها مناسبة لزملاء المشروع ، حيث لا يتعين عليهم القيام بأي شيء ، وإنما يقومون فقط بتشغيل البرنامج النصي ويعمل كل شيء.
مثال على البرنامج النصي Start.sh
مثال PHP-FPM-command.sh النصي
مثال البرنامج النصي
Connect-to-php-fpm.sh #!/usr/bin/env bash docker exec -i -t --privileged php-fpm bash
تنتهي بيئة التنمية المحلية هنا. تهانينا ، يمكنك مشاركة النتيجة النهائية مع زملائك! )
منتجة
تحضير
لنفترض أنك كتبت شيئًا بالفعل على شبكة LAN وتريد وضعها على خادم إنتاج أو على خادم اختبار. لديك استضافة على الافتراضية KVM أو الخادم الخاص بك في الغرفة المجاورة مع تكييف الهواء.
لنشر منتج أو إصدار بيتا - يجب أن يكون لدى الخادم نظام تشغيل (يُفضل أن يكون لينكس) ومُرسى مثبت. يمكن تثبيت Docker بنفس الطريقة التي يتم بها تثبيت الشبكة المحلية ، ولا توجد فروق.
عامل الميناء في الإنتاجية يختلف قليلاً عن LAN. أولاً ، لا يمكنك فقط أخذ كلمات مرور ومعلومات أخرى وتحديدها وإنشاء عامل الميناء. ثانيًا ، لا يمكنك استخدام Docker-compose مباشرة.
يستخدم Docker سرب عامل الميناء ومكدس عامل الميناء للإنتاجية. إذا كان موجودًا على الأصابع ، فإن هذا النظام يختلف فقط في الأوامر الأخرى وفي سرب عامل الميناء هذا هو موازن تحميل للكتلة (مرة أخرى مجردة قليلاً ، ولكن سيكون من الأسهل فهمها).
ملاحظة: أنصحك بالتدرب على إعداد سرب عامل الميناء على Vagrant (بغض النظر عن مدى التناقض الذي قد يبدو عليه هذا). وصفة بسيطة للتدريب - التقط Vagrant فارغة مع نفس نظام التشغيل الموجود في المنتج وقم بتكوينه للبدء.
لتكوين سرب عامل الميناء ، تحتاج فقط إلى تشغيل بعض الأوامر:
docker swarm init --advertise-addr 192.168.***.** (ip- ) mkdir /app ( app) chown docker /app ( ) docker stack deploy -c docker-compose.yml my-first-sf4-docker-app
دعونا الآن ننظر في كل هذا بمزيد من التفصيل.
سرب docker init - advertise-addr - يطلق
سرب docker نفسه مباشرة ويخرب رابطًا حتى تتمكن من ربط خادم آخر بهذا "السرب" بحيث يعمل في المجموعة.
mkdir / app && chown .. - يجب عليك إنشاء جميع الدلائل اللازمة لكي يعمل عامل الميناء مسبقًا حتى لا يشكو من نقص الدلائل أثناء البناء.
نشر docker stack -c docker-compose.yml my-first-sf4-docker-app - هذا الأمر يبدأ تجميع التطبيق الخاص بك ، وهو تناظري من تكوين docker up -d فقط لسرب عامل الميناء.
لبدء أي تجميع ، تحتاج إلى نفس docker-compose.yaml ، ولكنه تم تعديله قليلاً بشكل خاص للإنتاجية / بيتا.
version: '3.1' services: php-fpm: image: otezvikentiy/php7.2-fpm:0.0.11 ports: - '9000:9000' networks: - my-test-network depends_on: - postgres - rabbitmq volumes: - /app:/app working_dir: /app deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager] nginx: image: nginx:1.15.0 networks: - my-test-network working_dir: /app ports: - '80:80' depends_on: - php-fpm volumes: - /app:/app - ./nginx/nginx.conf:/etc/nginx/conf.d/default.conf deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager] postgres: image: postgres:9.6 ports: - '5432:5432' working_dir: /app networks: - my-test-network secrets: - postgres_db - postgres_user - postgres_pass environment: POSTGRES_DB_FILE: /run/secrets/postgres_db POSTGRES_USER_FILE: /run/secrets/postgres_user POSTGRES_PASSWORD_FILE: /run/secrets/postgres_pass volumes: - ./data/dump:/app/dump - ./data/postgresql:/var/lib/postgresql/data deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager] rabbitmq: image: rabbitmq:3.7.5-management networks: - my-test-network working_dir: /app hostname: my-test-sf4-app-rabbit-mq volumes: - /app:/app ports: - '5672:5672' - '15672:15672' secrets: - rabbitmq_default_user - rabbitmq_default_pass - rabbitmq_default_vhost environment: RABBITMQ_DEFAULT_USER_FILE: /run/secrets/rabbitmq_default_user RABBITMQ_DEFAULT_PASS_FILE: /run/secrets/rabbitmq_default_pass RABBITMQ_DEFAULT_VHOST_FILE: /run/secrets/rabbitmq_default_vhost deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager] elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:6.3.0 networks: - my-test-network depends_on: - postgres environment: - discovery.type=single-node - discovery.zen.ping.unicast.hosts=elasticsearch - bootstrap.memory_lock=true - ES_JAVA_OPTS=-Xms512m -Xmx512m ports: - 9200:9200 - 9300:9300 working_dir: /app volumes: - /app:/app - ./data/elasticsearch:/usr/share/elasticsearch/data deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager] jenkins: image: otezvikentiy/jenkins:0.0.2 networks: - my-test-network ports: - '8080:8080' - '50000:50000' volumes: - /app:/app - ./data/jenkins:/var/jenkins_home - /var/run/docker.sock:/var/run/docker.sock - /usr/bin/docker:/usr/bin/docker deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager] volumes: elasticsearch: postgresql: jenkins: networks: my-test-network: secrets: rabbitmq_default_user: file: ./secrets/rabbitmq_default_user rabbitmq_default_pass: file: ./secrets/rabbitmq_default_pass rabbitmq_default_vhost: file: ./secrets/rabbitmq_default_vhost postgres_db: file: ./secrets/postgres_db postgres_user: file: ./secrets/postgres_user postgres_pass: file: ./secrets/postgres_pass
كما ترى ، يختلف ملف الإعدادات الخاص بالمنتج قليلاً عن ملف LAN. وأضاف أسرار ونشر والشبكات.
أسرار - ملفات لتخزين المفاتيح. يتم إنشاء المفاتيح بكل بساطة. تقوم بإنشاء ملف باسم المفتاح - اكتب القيمة بداخله. بعد ذلك ، في docker-compose.yml ، يمكنك تحديد قسم الأسرار ونقل قائمة الملفات بالكامل مع مفاتيح إليه.
مزيد من التفاصيل .
الشبكات - وهذا يخلق شبكة داخلية معينة تتواصل من خلالها الحاويات مع بعضها البعض. على LAN - يتم ذلك تلقائيًا ، ولكن على الإنتاجية - يجب القيام بذلك يدويًا قليلاً. بالإضافة إلى ذلك ، يمكنك تحديد إعدادات إضافية باستثناء الإعدادات الافتراضية.
مزيد من التفاصيل .
نشر هو الفرق الرئيسي بين LAN و Product / Beta.
deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager]
مجموعة مقاتلة الحد الأدنى:
النسخ المتماثلة - تشير إلى عدد النسخ المتماثلة التي تحتاج إلى تشغيلها (في الواقع ، يتم استخدام هذا إذا كان لديك كتلة وتستخدم موازن التحميل من عامل الميناء). على سبيل المثال ، لديك خادمان وقمت بتوصيلهما من خلال سرب دوكر. تحديد الرقم 2 هنا ، على سبيل المثال ، سيتم إنشاء مثيل واحد على خادم واحد ، والثاني على الخادم الثاني. وبالتالي ، سيتم تقسيم الحمل على الخادم إلى النصف.
reset_policy - سياسة "إعادة رفع" الحاوية تلقائيًا في حالة سقوطها لسبب ما.
موضع - مكان مثيل الحاوية. على سبيل المثال ، هناك أوقات تريد فيها أن تدور جميع مثيلات الحاوية على خادم واحد فقط من 5 خوادم ، ولا يتم توزيعها فيما بينها.
أريد أن أقرأ الوثائق!حسنًا ، لقد أصبحنا أفضل قليلاً بشأن ما يميز docker-compose.yaml لـ LAN عن المنتج / إصدار بيتا. الآن دعنا نحاول تشغيل هذا العمل.
لنفترض أنك تتدرب على Vagrant وفي جذر الخادم لديك بالفعل الملف الذي تم تكوينه لمنتج docker-compose.yml sudo apt-get update sudo apt-get -y upgrade sudo apt-get install -y language-pack-en-base export LC_ALL=en_US.UTF-8 export LANGUAGE=en_US.UTF-8 export LANG=en_US.UTF-8 curl -sSl https://get.docker.com/ | sh sudo usermod -aG docker ubuntu sudo apt-get install git sudo docker swarm init --advertise-addr 192.168.128.77 sudo mkdir /app sudo chmod 777 /app -R docker stack deploy -c /docker-compose.yml my-app git clone git@bitbucket.org:JohnDoe/my-app.git /app docker stack ps my-app docker stack ls docker stack services my-app
ملاحظة: لا تتنافس على sudo و 777 ، بالطبع لا يستحق القيام بذلك على الإنتاجية. هذا فقط لسرعة التعلم.لذا ، نحن أكثر اهتمامًا بالخطوط المرتبطة بالرسو.أولا نقوم بتهيئة "سرب" (سرب حوض السفن).ثم ننشئ الدلائل اللازمة للعمل.قم بتنزيل اللفت مع كود SF4 الخاص بنا في دليل / التطبيق.بعد ذلك هناك ثلاثة أوامر: ps ، ls والخدمات.كل منهم مفيد بطريقته الخاصة. أستخدم ps في أغلب الأحيان ، لأنها تعرض حالة الحاويات وجزء من الخطأ ، إن وجد.لنفترض أن الحاويات قد ارتفعت ، لكن بعضها يتحطم باستمرار مع وجود خطأ وفي رصيف المكدس ps my-app ترى مجموعة من عمليات إعادة التشغيل. لمعرفة سبب السقوط ، تحتاج إلى تشغيل حاوية docker ps -a - وستظهر هناك حاوية تسقط باستمرار. سيكون هناك العديد من الحالات من نفس الحاوية ، على سبيل المثال my-app_php-fpm.1. * بعض التجزئة الشديدة *.وبناءً على ذلك ، الآن ، بعد معرفة اسم الحاوية ، تنفيذ سجلات عامل الميناء my-app_php-fpm.1. * بعض التجزئة الشديدة * والبحث في السجلات. صحح الخطأ وأعد تشغيل كل شيء. لتفجير جميع الحاويات ، يمكنك القيام بذلك: docker stack rm my-app
بعد ذلك ، سيكون لديك سرب نظيف بدون أي حاويات. إصلاح الخطأ - ومرة أخرى نشر مكدس عامل الميناء -c docker-compose.yml my-app.