تذكر أننا نستخدم تكوين النموذج الموضح في الرسم البياني أدناه ، ويرجى الانتباه إلى الملصقات المتوفرة هناك ، حيث سنستخدمها بنشاط في الأمثلة لدينا.
| مكونات البرمجيات | إصدارات |
|---|---|
| منصة حاوية Red Hat OpenShift | 4.5.7 |
| ريد هات إدارة الكتلة المتقدمة | 2.0 حزمة الإصلاح 2.0.2 |
مستودع Git
سنستخدم أيضًا مستودع Git من المقالة السابقة:
| فرع شجرة | وصف |
|---|---|
| التكوين | يخزن الملفات الأساسية للتطبيقات المستخدمة في جميع البيئات. |
| همز | يخزن ملفات التراكب للتطبيقات المستخدمة في بيئات الإنتاج. |
| المسرح | يخزن ملفات التراكب للتطبيقات المستخدمة في بيئات الاختبار |
انتشار أزرق / أخضر مع Red Hat ACM
في المقالة السابقة ، نشرنا تطبيقنا العكسي في بيئتين ، التطوير والإنتاج. دعنا نقول ، في التطوير ، لدينا الإصدار 0.0.3 ، وفي الإنتاج - 0.0.2.
لنفترض الآن أن المطورين قد أصدروا الإصدار 0.0.4 ونريد إجراء عملية نشر باللونين الأزرق والأخضر لمجموعات التطوير والإنتاج باستخدام إمكانات GitOps الخاصة بـ ACM.
في المقالة السابقة ، أنشأنا موارد القناة ، وقواعد الموضع ، والاشتراكات ، والتطبيقات الضرورية في ACM ، بحيث عند نشر الإصدار الجديد ، سيعمل Git فقط في كلا المجموعتين.
تحديث التطبيق في بيئة التطوير
نظرًا لأن جميع الموارد المطلوبة قد تم إنشاؤها بالفعل ، نحتاج فقط إلى تغيير أوصاف التطبيق في Git لتحديث الإصدارات في البيئات المقابلة.
ملحوظة. نظرًا لأننا نعرض هنا فقط إمكانات GitOps الخاصة بـ ACM ، فسنقوم بدفع التغييرات مباشرةً إلى فروع المستودع ، وهذا ليس جيدًا. في الحياة الواقعية ، يجب أن يكون لديك عملية محددة جيدًا لإجراء تغييرات على بيئات مختلفة ، يمكنك قراءة المزيد حول هذا هنا .
1. انتقل إلى مستودع Git المستنسخ:
ملاحظة: إذا قمت بإعادة إنتاج الأمثلة من المقالة السابقة ، فهذا يعني أنه لديك بالفعل فرع مستنسخ من هذا المستودع .
cd /path/to/acm-app-lifecycle-blog/forked/repository/
2. أولاً ، نريد تحديث إصدار التطبيق في بيئة التطوير حتى نتمكن من اختباره قبل دفع التغييرات إلى بيئة الإنتاج. لذلك ، سوف نعمل مع فرع المرحلة.
git checkout stage
3. أنت الآن بحاجة إلى تحديث التراكب لنشر التطبيق بحيث يستخدم هذا النشر صورة الإصدار الجديد (0.0.4).
حتى الآن ، يتم تشغيل الإصدار 0.0.3 في مجموعة التطوير.
sed -i "s/v0.0.3/v0.0.4/g" apps/reversewords/overlays/deployment.yaml
4. قبل تنفيذ التغييرات ، تحقق من الحالة الحالية للتطبيق في مجموعة التطوير.
curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
كما ترى ، الإصدار 0.0.3 يعمل حاليًا في بيئة التطوير:
Reverse Words Release: Stage Release v0.0.3. App version: v0.0.3
5. قم بإلزام الملف وادفعه إلى فرع المرحلة.
ملحوظة. مرة أخرى ، في الحياة الواقعية لا يجب عليك ذلك. يجب أن يكون لديك عملية محددة جيدًا لهذا الغرض.
git add apps/reversewords/overlays/deployment.yaml
git commit -m "Pushed development reverse-words app version to v0.0.4"
git push origin stage
6. نظرًا لأن لدينا اشتراكًا بالفعل ، عند اكتشاف التزام جديد في مستودعنا وفرعنا ، ستقوم ACM بتنفيذ إجراءات لتغيير الحالة من الحالة الحالية إلى الحالة المطلوبة ، كما هو مكتوب في Git.
oc --context dev -n reverse-words-stage get pods
كما ترى ، تم اكتشاف التغييرات وتم نشر الإصدار الجديد من الكبسولة مع الإصدار الجديد من التطبيق.
NAME READY STATUS RESTARTS AGE
reverse-words-5ff744d4bd-kkfvn 0/1 ContainerCreating 0 3s
reverse-words-68b9b894dd-jfgpf 1/1 Running 0 109m
7. لنقم الآن بتشغيل الطلب إلى التطبيق ونتأكد من نشرنا للإصدار 0.0.4.
curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Stage Release v0.0.4. App version: v0.0.4
8. إصدار الإنتاج لا يزال سليما.
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Production release v0.0.2. App version: v0.0.2
9. يمكنك الآن إجراء اختبارات التحقق من الصحة ، وإذا كان كل شيء على ما يرام ، فقم بطرح الإصدار الجديد من التطبيق في مرحلة الإنتاج.
تحديث التطبيق في بيئة الإنتاج
1. انتقل إلى مستودع Git المستنسخ.
cd /path/to/acm-app-lifecycle-blog/forked/repository/
2. نعتقد أننا اختبرنا الإصدار الجديد من التطبيق بنجاح في مجموعة التطوير وحان الوقت لإجراء التغييرات المناسبة لنشره في مجموعة الإنتاج ، لذلك سنعمل الآن مع فرع المنتج.
git checkout prod
3. يجب تحديث التراكب لنشر التطبيق بحيث يستخدم هذا النشر صورة الإصدار الجديد (0.0.4).
حتى الآن ، يتم تشغيل الإصدار 0.0.2 في مجموعة الإنتاج
sed -i "s/v0.0.2/v0.0.4/g" apps/reversewords/overlays/deployment.yaml
4. قبل إجراء التغييرات ، تحقق من الحالة الحالية للتطبيق في مجموعة الإنتاج.
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
كما ترى ، يعمل الإصدار 0.0.2 حاليًا في بيئة الإنتاج:
Reverse Words Release: Stage Release v0.0.2. App version: v0.0.2
5. قم بإيداع الملف وادفعه إلى فرع المنتج.
ملحوظة. مرة أخرى ، في الحياة الواقعية لا يجب عليك ذلك. يجب أن يكون لديك عملية محددة جيدًا لهذا الغرض.
git add apps/reversewords/overlays/deployment.yaml
git commit -m "Pushed production reverse-words app version to v0.0.4"
git push origin prod
6. نظرًا لأن لدينا اشتراكًا بالفعل ، عند اكتشاف التزام جديد في مستودعنا وفرعنا ، ستقوم ACM بتنفيذ إجراءات لتغيير الحالة من الحالة الحالية إلى الحالة المطلوبة ، كما هو مكتوب في Git.
oc --context pro -n reverse-words-prod get pods
كما ترى ، تم اكتشاف التغييرات وتم نشر الإصدار الجديد من الكبسولة مع الإصدار الجديد من التطبيق.
NAME READY STATUS RESTARTS AGE
reverse-words-68795d69ff-6t4c7 0/1 ContainerCreating 0 5s
reverse-words-7dd94446c-vkzr8 1/1 Running 0 115m
7. لنقم الآن بتشغيل الطلب إلى التطبيق ونتأكد من نشرنا للإصدار 0.0.4.
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Production Release v0.0.4. App version: v0.0.4
8. هذا كل شيء ، لقد قمنا بتحديث تطبيقنا إلى الإصدار 0.0.4 في كلا البيئتين: التطوير والإنتاج.
خاتمة
في الجزء الأول من هذه السلسلة ، قمنا بتغطية جوانب ACM التي تندرج تحت فئة GitOps. تعلمنا اليوم كيفية استخدام ACM لعمليات النشر باللونين الأزرق والأخضر ، وترحيل التطبيقات بين المجموعات ، والتعافي من الكوارث. في المنشور التالي ، سنوضح لك كيفية ترحيل تطبيق عكس الكلمات بسلاسة بين مجموعاتنا باستخدام ACM.