تقريبا. العابرة. - مع هذه المقالة ، نبدأ سلسلة من الترجمات المكرسة لموضوع تعطل الصفر. ستسلط المنشورات التالية الضوء على نشر إصدارات جديدة من التطبيق مع قاعدة البيانات والنشر في Kubernetes.
على الرغم من أن الحل التقني الموضح أدناه مثير للجدل ، فإن الغرض من هذه المقالة هو تعريف القارئ مباشرة بطريقة النشر Blue-Green ، والتي ، بالمناسبة ، لا تنطبق على تطبيقات Spring فقط.
الهدف من نشر Blue-Green هو التخلص من وقت التوقف أثناء نشر نسخة جديدة من التطبيق.
يرتبط وقت التوقف عن عدم توفر الخادم عند تثبيت إصدار جديد من التطبيق لاستبدال الإصدار القديم. تتمثل فكرة النشر باللون الأزرق / الأخضر في نشر الإصدار الجديد من التطبيق في مكان منفصل حيث يمكنك اختباره ، حتى يتم اتخاذ القرار النهائي بالتبديل إليه باعتباره الإصدار الرئيسي.
في هذه المقالة ، سننظر في كيفية تكوين نشر تطبيقات التشغيل باللون الأزرق والأخضر. سنستخدم Nginx كخادم الويب الرئيسي لإعادة توجيه الطلبات الواردة إلى تطبيقاتنا.
إعداد الخادم
يفترض هذا الدليل أن لديك خادمًا ويقوم بتشغيل تطبيق تمهيد Spring والذي يمكن نشره عليه.
على الخادم ، انتقل إلى الدليل الرئيسي وإنشاء مجلدين: blue green . ثم نحتاج إلى اثنين من الروابط الرمزية available testing . سوف تشير هذه الروابط إلى مجلد أزرق أو أخضر. على سبيل المثال ، إذا كانت النقاط available green ، testing النقاط إلى blue .
mkdir blue mkdir green ln -s ./green ./available ln -s ./blue ./testing
سيحتوي كل مجلد على تطبيق Spring الخاص به وتكوين Nginx. في مرحلة ما أثناء النشر ، سيعمل كلا التطبيقين في وقت واحد (على الرغم من أنه على منافذ مختلفة) ، وللتحول من التطبيق الأزرق إلى الأخضر ، نحتاج فقط إلى تغيير تكوين Nginx إلى اللون الأخضر أو الأزرق.
تكوينات Nginx
دعنا نقول لدينا مجال springsite.com. سيقوم التكوين الأخضر لـ Nginx بإعادة توجيه جميع المكالمات إلى springsite.com/api/ إلى التطبيق green على المنفذ 8080 ، وجميع المكالمات إلى springsite.com/api-test/ إلى التطبيق blue على المنفذ 8090.
لنقم بإنشاء ملفات التكوين هذه. افتح المحرر المفضل لديك وأضف المحتوى التالي.
http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name mysite.com; location /api { proxy_pass http://localhost:8090/api; } location /api-test { proxy_pass http://localhost:8080/api; } } include servers/*; }
http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name mysite.com; location /api { proxy_pass http://localhost:8080/api; } location /api-test { proxy_pass http://localhost:8090/api; } } include servers/*; }
يجب أن تبدو بنية الملف كما يلي:
--root |--- blue |--- nginx.conf.blue |--- app-V2.jar |--- green |--- nginx.conf.green |--- app-V1.jar |--- available -> ./green |--- testing -> ./blue
لنفترض أننا نريد نشر إصدار جديد في حاوية blue . يمكننا اختباره بينما لا يزال الإصدار السابق متاحًا . بمجرد أن يكون الجميع سعداء بالإصدار الجديد ، سنحتاج فقط إلى تغيير الروابط!
قم swap.sh ملف swap.sh في المجلد الذي يحتوي على المجلدين blue green :
touch swap.sh chmod +x swap.sh
أضف المحتويات التالية إلى ملف swap.sh :
#!/bin/bash testing_now=$(ls -l ./ | grep testing) if [[ "$testing_now" == *blue ]] then testing="blue" active="green" else testing="green" active="blue" fi #remove current links rm ./available rm ./testing rm -f /etc/nginx/nginx.conf #create new links with the active/inactive reversed ln -s ./$inactive ./available ln -s ./$active ./testing ln -s /home/ubuntu/spring/$active/nginx.conf /etc/nginx/nginx.conf #reload the http server service nginx reload echo swap completed $active is now available
في هذه المرحلة ، يمكننا تشغيل تطبيقين Spring على المنفذين 8090 و 8080 ./swap.sh عن طريق تشغيل sudo ./swap.sh .
نشر
بفضل الروابط الرمزية ، نعلم أن التطبيق الرئيسي يتم الإشارة إليه دائمًا بواسطة التطبيق available ، والتطبيق قيد الاختبار عن طريق testing . لذلك ، يجب علينا دائمًا نشر إصدار جديد من التطبيق في مجلد testing باستخدام رابط رمزي. من المفترض أننا قمنا بتعبئة التطبيق للتو ، والآن يمكننا تنزيله باستخدام scp .
scp -r -i ~/.ssh/MyKeyPair.pem <package name.jar> <user>@<ip>:spring/testing
المضي قدما
سيؤدي إعداد نشر Blue-Green على الخادم الخاص بك إلى تقليل وقت التوقف عن العمل بشكل كبير . يشرح هذا الدليل كيفية نشر إصدارات جديدة من التطبيق الخاص بك الموجودة على نفس الخادم الفعلي. يمكن أن تتكيف مع الحالات مع خوادم فعلية متعددة وموازن التحميل. ومع ذلك ، سيتطلب ذلك وجود ضعف عدد بيئات الإنتاج حسب الضرورة. بالنسبة للبنية التحتية الكبيرة جدًا ، يكون هذا مستحيلًا أو مكلفًا للغاية.
يؤدي هذا إلى السؤال التالي: كيف تمكِّن الشركات الكبيرة من إصدار إصدارات جديدة من تطبيقاتها دون توقف؟ فكر في Google أو Facebook المتوفرة دائمًا!
استخدام نشر Blue-Green هنا غير واقعي بسبب كثرة الخوادم الضرورية. يتم تنفيذ تحديثات التطبيق بشكل تدريجي: يتم إخراج الخوادم من الخدمة واحدة تلو الأخرى ، ويتم إرجاعها بعد التحديث. علاوة على ذلك ، يتم إصدار الإصدارات الجديدة أيضًا تدريجيًا: في البداية ، لن يعمل سوى جزء صغير من الخوادم مع الإصدار الجديد. بعد ذلك ، إذا لم يتم العثور على أي مشاكل أو أخطاء ، فسيبدأ عدد أكبر من الخوادم بالرمز الجديد. في هذه المرحلة ، يتم تقييم مقاييس الأداء المهمة مثل وحدة المعالجة المركزية والذاكرة وأداء الاستعلام. إذا سارت الأمور على ما يرام ، فسيكون الإصدار كاملاً ، وسيتم إطلاق نسخة جديدة من التطبيق على كل خادم في جميع أنحاء العالم.
استنتاج
آمل أن تفهم الآن كيفية حل مشكلة التوقف عن العمل بفضل نشر Blue-Green. يمكنك الآن تهيئة نشر Blue-Green الأساسي لتطبيق Spring الخاص بك باستخدام NGINX.
كما لاحظت ، عندما نستخدم هذا الحل ، فإن الإصدارات القديمة والحالية من تطبيقاتك تعمل في وقت واحد وكلاهما متصل بقاعدة البيانات. هذا يمكن أن يؤدي إلى مشاكل غير متوقعة عند تغيير بنية قاعدة البيانات. توضح هذه المقالة الرائعة https://spring.io/blog/2016/05/31/zero-downtime-deployment-with-a-database كيفية التعامل مع مثل هذه الحالات.
وأخيرًا ، قد تكون مهتمًا بحقيقة أن كلاً من AWS و Google Cloud Compute يعرضان خدمات نشر Blue-Green خارج الصندوق:
https://aws.amazon.com/quickstart/architecture/blue-green-deployment/
https://cloud.google.com/solutions/continuous-delivery/
اقرأ أيضًا مقالات أخرى على مدونتنا: