Docker Swarm عبر ثلاث قارات: توافر عالٍ مصمَّم لوقت تشغيل بنسبة 100%

الخادم الواحد في مركز بيانات واحد نقطة فشل وحيدة، مهما بلغت جودة العتاد والشبكة. فإذا تعطل الموقع، بسبب خلل في الكهرباء أو في الشبكة مثلاً، أو ببساطة بسبب خطأ أثناء أعمال الصيانة، يتوقف التطبيق بالكامل. ويحل Docker Swarm عبر عدة مراكز بيانات هذه المشكلة تحديداً: تعمل الحاويات في ثلاثة مواقع مستقلة، وفي الحالة المثالية على ثلاث قارات، وإذا تعطل أحدها كلياً تولّى الموقعان الآخران العمل دون أن يلاحظ المستخدمون شيئاً.

يشرح هذا المقال خطوة بخطوة كيف تبنون عنقوداً (Cluster) بتقنية Docker Swarm مصمَّماً لوقت تشغيل بنسبة 100%: خادم واحد في كل من أمريكا الشمالية وأوروبا وآسيا، وشبكة WireGuard مشفرة بين العُقد، ونصاب (Quorum) من عُقد المدير يصمد أمام تعطل قارة بأكملها، ونقطة دخول لكل منطقة، وتجاوز الفشل (Failover) عبر DNS لتوجيه المستخدمين تلقائياً إلى أقرب موقع سليم. ونشرح كذلك بصراحة ما الذي يمكن أن يتعطل حتى مع هذه البنية، وكيف تحدّون من هذه المخاطر أيضاً.

هل يمكن تحقيق وقت تشغيل بنسبة 100% باستخدام Docker Swarm؟

عنقود Docker Swarm الممتد عبر ثلاث قارات مصمَّم لوقت تشغيل بنسبة 100%: لا يستطيع أي خادم منفرد، ولا أي مركز بيانات منفرد، ولا أي قارة منفردة، إيقاف التطبيق بمفرده. ومع ذلك لا يستطيع أحد أن يضمن توافراً مطلقاً، ولا حتى كبار مزودي الخدمات السحابية الذين تتراوح أعلى تعهداتهم بين 99٫99 و99٫999%. والسبب ليس مراكز البيانات، بل العناصر المشتركة بين جميع المواقع. وهذه العناصر بالذات يتناولها هذا المقال أيضاً، لكي تقتربوا من نسبة 100% إلى أقصى حد ممكن تقنياً.

ماذا يعني التوافر بالأرقام

الحساب مبني على 8٬760 ساعة في السنة و730 ساعة في الشهر. وكل رقم تسعة إضافي يقلّص وقت التوقف المسموح به إلى العُشر، وهنا تحديداً يبدأ العمل الذي لم يعد خادم منفرد قادراً على إنجازه.

لماذا تُحدث ثلاث قارات كل هذا الفرق

ثلاثة مواقع مستقلة بعضها عن بعض، يبلغ توافر كل منها 99٫9%، لا تتعطل معاً من الناحية الحسابية إلا إذا أصاب الخلل المواقع الثلاثة كلها في الوقت نفسه: 0٫1% مضروبة في 0٫1% مضروبة في 0٫1% تساوي 0٫0000001%. وكلما تباعدت المواقع، ازدادت استقلاليتها فعلياً: لكل منها شبكة كهرباء خاصة، واتصالات شبكية خاصة، وأحوال جوية خاصة، ونوافذ صيانة خاصة. لذلك يُعد التوزيع على أمريكا الشمالية وأوروبا وآسيا أقوى أشكال الحماية من الأعطال التي يمكن بناؤها بالخوادم.

ما الذي يمكن أن يتعطل حتى مع ثلاث قارات

المخاطر المتبقية هي الاعتماديات المشتركة بين جميع المواقع، ولكل منها إجراء مضاد:

• التحديث المعيب يوزّعه العنقود على جميع المواقع بالموثوقية نفسها التي يوزّع بها التحديث السليم. الإجراء المضاد: فحوص السلامة (Health Checks) والتراجع التلقائي، إضافة إلى التحديث منطقةً تلو الأخرى.
• DNS هو النقطة الوحيدة التي يمر عبرها جميع المستخدمين. الإجراء المضاد: مزود DNS بشبكة موزعة حول العالم مع تجاوز الفشل، ومدة صلاحية (TTL) قصيرة.
• قاعدة البيانات يجب أن تحتوي على البيانات نفسها في جميع المواقع. الإجراء المضاد: النسخ المتماثل مع التبديل التلقائي، انظروا القسم الخاص بالبيانات.
• الشهادات والنطاقات المنتهية الصلاحية تصيب جميع المواقع في آن واحد. الإجراء المضاد: التجديد التلقائي ومراقبة تواريخ انتهاء الصلاحية.
• عملية التبديل نفسها تستغرق وقتاً إلى أن تستجيب فحوص السلامة وDNS، غالباً دقيقة إلى دقيقتين قد تفشل خلالها بعض الطلبات. الإجراء المضاد: فواصل فحص قصيرة، وTTL قصيرة، وبرامج عميل (Clients) تعيد إرسال الطلبات الفاشلة.

نظرة عامة على البنية

يتكون عنقود Docker Swarm الممتد عبر عدة قارات من ستة مكونات. ويزيل كل منها نقطة فشل محددة:

كم عقدة مدير، وأين؟

تدير عُقد المدير (Manager) في عنقود Swarm حالة العنقود بخوارزمية الإجماع Raft. ويحتاج كل تغيير إلى موافقة أغلبية عُقد المدير، أي ما يُسمى النصاب (Quorum). وإذا غابت الأغلبية، تواصل الحاويات الموجودة عملها، لكن العنقود لا يستطيع إعادة الجدولة ولا تعويض الأعطال ولا توزيع التحديثات.

توصي Docker بعدد فردي من عُقد المدير وبتوزيعها على ثلاث مناطق (Zones) على الأقل: بنسبة 1-1-1 عند ثلاث عُقد مدير، وبنسبة 2-2-1 عند خمس. ومن هنا تأتي أهم قاعدة في هذا المقال: موقعان لا يكفيان. ففي حالة موقعين يضم أحدهما حتماً عدداً أكبر من عُقد المدير، وإذا تعطل هذا الموقع تحديداً ضاعت الأغلبية. ولا يصمد النصاب أمام تعطل أي مركز بيانات كان إلا مع ثلاثة مواقع، وعندما تكون المواقع على ثلاث قارات فهذا يعني الصمود أمام تعطل قارة بأكملها.

ثلاث قارات أم قارة واحدة: الموازنة بين الخيارين

كل تغيير في العنقود، وكل عملية نشر (Deployment)، وكل إعادة جدولة لحاوية، ينتظر تأكيد أغلبية عُقد المدير. وبين أوروبا وأمريكا الشمالية وآسيا يستغرق كل تأكيد من هذه التأكيدات زمن انتقال للحزم يبلغ نحو 80 إلى 250 مللي ثانية. هذا لا يهم المستخدمين، لأن طلباتهم تُجاب محلياً؛ لكن عمليات النشر وإعادة الجدولة تستغرق وقتاً أطول بشكل ملحوظ مما تستغرقه في عنقود مساراته قصيرة.

للتطبيقات التي يتوزع مستخدموها على عدة قارات وتهدف إلى أعلى توافر ممكن، يكون خيار القارات الثلاث هو الصحيح، وهو ما نبنيه في الدليل. والمهم هنا قاعدة تسري على جميع الخطوات: يُجاب عن كل طلب في منطقته، ولا ينتقل أبداً ذهاباً وإياباً بين القارات.

مواقع KernelHost المناسبة

تشغّل KernelHost خوادم في مركز بيانات maincubes في فرانكفورت أم ماين، وتوفر خوادم افتراضية في مواقع أخرى في أوروبا وأمريكا الشمالية وآسيا والمحيط الهادئ، منها ثلاثة مواقع في الولايات المتحدة، إضافة إلى كندا ولندن وستراسبورغ ووارسو وهلسنكي وسنغافورة واليابان وسيدني ومومباي. القائمة الكاملة مع الخريطة موجودة في صفحة مواقع الخوادم. وفي مثال هذا المقال نختار فرانكفورت أم ماين لأوروبا، والساحل الشرقي للولايات المتحدة لأمريكا الشمالية، وسنغافورة لآسيا.

دليل: بناء Docker Swarm عبر ثلاث قارات

يستخدم المثال ثلاثة خوادم: swarm-eu في فرانكفورت أم ماين، وswarm-us على الساحل الشرقي للولايات المتحدة، وswarm-asia في سنغافورة. العناوين العامة مأخوذة من شبكة التوثيق 203.0.113.0/24، وشبكة WireGuard تستخدم 10.10.0.0/24. استبدلوا كليهما بقيمكم. والعُقد الثلاث كلها هي في الوقت نفسه عُقد مدير وعُقد عامل؛ ولمزيد من الأداء أضيفوا لاحقاً في كل منطقة عُقداً تعمل كعُقد عامل فقط.

الخطوة 1: تجهيز الخوادم على ثلاث قارات

اطلبوا ثلاثة خوادم بنظام Debian 12 أو 13 في ثلاث مناطق، وطبّقوا التحصين الأساسي: SSH بالمفتاح فقط، وتحديثات أمنية تلقائية، ومستخدمون مستقلون. تغطي قائمة التحقق للخوادم الجذرية الجديدة ذلك. امنحوا الخوادم أسماء مضيف معبّرة، لتروا فوراً في docker node ls أي عقدة موجودة في أي مكان.

hostnamectl set-hostname swarm-eu

الخطوة 2: تثبيت Docker على جميع العُقد

ثبّتوا Docker Engine من مستودع Docker الرسمي على الخوادم الثلاثة، كما هو موضح في مقال تثبيت Docker على Debian وUbuntu. ثم تحققوا من الإصدار على كل عقدة، إذ ينبغي أن تعمل العُقد الثلاث بالإصدار الرئيسي نفسه:

docker version --format '{{.Server.Version}}'

الخطوة 3: بناء شبكة WireGuard بين القارات

تتواصل العُقد فيما بينها عبر الإنترنت العام. ولكي تكون كل حركة مرور العنقود مشفرة، ولا تكون منافذ Swarm متاحة للعموم أبداً، تربط شبكة WireGuard بين الخوادم الثلاثة. أنشئوا أولاً زوج مفاتيح على كل عقدة:

apt-get install -y wireguard
umask 077
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key

بعد ذلك تحصل كل عقدة على ملف /etc/wireguard/wg0.conf. هكذا يبدو على swarm-eu، أما العقدتان الأخريان فتُعدّان بالطريقة نفسها بصورة معكوسة:

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = SWARM_EU_المفتاح_الخاص
MTU = 1420

[Peer]
PublicKey = SWARM_US_المفتاح_العام
Endpoint = 203.0.113.12:51820
AllowedIPs = 10.10.0.2/32
PersistentKeepalive = 25

[Peer]
PublicKey = SWARM_ASIA_المفتاح_العام
Endpoint = 203.0.113.13:51820
AllowedIPs = 10.10.0.3/32
PersistentKeepalive = 25

systemctl enable --now wg-quick@wg0
ping -c 3 10.10.0.2

إذا استجابت جميع العُقد عبر عناوين 10.10.0.x الخاصة بها، فالشبكة جاهزة. ويُبقي PersistentKeepalive الاتصال مفتوحاً حتى خلف جدران الحماية ذات الحالة (Stateful). وأزمنة الانتقال التي يعرضها ping الآن بين القارات هي بالضبط أزمنة الانتظار التي يكلّفها كل تغيير في العنقود.

الخطوة 4: جدار الحماية: الدخول لعُقد Swarm فقط

يحتاج Docker Swarm بين العُقد إلى المنفذ 2377/TCP لإدارة العنقود، والمنفذ 7946/TCP وUDP لتواصل العُقد فيما بينها، والمنفذ 4789/UDP لشبكة Overlay. اسمحوا بهذه المنافذ حصراً على واجهة WireGuard، ولا يبقى مفتوحاً للعموم سوى WireGuard نفسه، وللعُقد الأخرى فقط. باستخدام ufw يبدو ذلك على swarm-eu كما يلي:

ufw allow from 203.0.113.12 to any port 51820 proto udp
ufw allow from 203.0.113.13 to any port 51820 proto udp
ufw allow in on wg0 to any port 2377 proto tcp
ufw allow in on wg0 to any port 7946
ufw allow in on wg0 to any port 4789 proto udp

مهم: المنافذ التي ينشرها Docker للحاويات تتجاوز ufw، لأن Docker يضع قواعد iptables خاصة به. لذلك لا تنشروا سوى منافذ نقطة الدخول (80 و443)، ولا تنشروا أبداً منافذ قواعد البيانات أو منافذ الإدارة.

الخطوة 5: تهيئة Swarm وإضافة عُقد المدير

على swarm-eu هيّئوا Swarm، واحرصوا على أن تمر حركة الإدارة وحركة البيانات عبر WireGuard:

docker swarm init --advertise-addr 10.10.0.1 --data-path-addr 10.10.0.1
docker swarm join-token manager

يعرض الأمر الثاني أمر الانضمام لعُقد المدير الإضافية. نفّذوه على swarm-us وswarm-asia، كلٌّ بعنوان WireGuard الخاص به، وهذا مثال لـ swarm-us:

docker swarm join --token SWMTKN-1-... --advertise-addr 10.10.0.2 --data-path-addr 10.10.0.2 10.10.0.1:2377
docker node ls

بعد ذلك يعرض docker node ls ثلاث عُقد، إحداها بالحالة Leader والأخريان بالحالة Reachable. رمز الانضمام (Join Token) سرّ: من يعرفه يستطيع أن يدسّ عقدة مدير خاصة به في عنقودكم. بعد الانتهاء من البناء جدّدوه بالأمر docker swarm join-token --rotate manager.

الخطوة 6: تفعيل Autolock

تحفظ عُقد المدير حالة العنقود، ومعها المفاتيح التي تُشفَّر بها سجلات Raft، في المسار /var/lib/docker/swarm/. ومع Autolock تُشفَّر هذه المفاتيح نفسها، ولا تعود عقدة المدير التي أُعيد تشغيلها إلى العنقود إلا بعد إدخال مفتاح فك القفل:

docker swarm update --autolock=true
docker swarm unlock

يعرض الأمر الأول مفتاح فك القفل، فاحفظوه في مدير كلمات المرور. أما الأمر الثاني فتحتاجونه بعد كل إعادة تشغيل لعقدة مدير. ومن دون هذا المفتاح لا يمكن استعادة Swarm حتى من نسخة احتياطية، لذلك احفظوه بمعزل عن الخوادم.

الخطوة 7: وسم العُقد حسب المنطقة

تُخبر الوسوم (Labels) المُجدوِل (Scheduler) بمكان وجود كل عقدة. وعليها تقوم قواعد التوزيع (Constraints) في الخطوات التالية:

docker node update --label-add region=eu swarm-eu
docker node update --label-add region=us swarm-us
docker node update --label-add region=asia swarm-asia

الخطوة 8: إنشاء شبكة Overlay بقيمة MTU مناسبة

تتواصل الحاويات الموجودة في مواقع مختلفة فيما بينها عبر شبكة Overlay. ولأن هذه الشبكة تمر عبر نفق WireGuard، يجب أن تكون قيمة MTU الخاصة بها أصغر: يعمل WireGuard بقيمة 1420 بايت، وتحتاج شبكة Overlay (VXLAN) منها إلى 50 بايت لترويساتها الخاصة، فيتبقى 1370 بايت:

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1370 appnet

تظهر مشكلة MTU الأكبر من اللازم بطريقة خادعة: الطلبات الصغيرة تعمل، أما الاستجابات الكبيرة فتتعلق. ومن يستغني عن WireGuard يمكنه بدلاً من ذلك تشفير شبكة Overlay بالخيار --opt encrypted؛ وعندها يجب أيضاً السماح ببروتوكول IP رقم 50 (ESP) بين العُقد، وتنبّه Docker صراحةً إلى تراجع ملحوظ في الأداء. نحن نوصي بـ WireGuard، لأنه يغطي كل حركة المرور بما فيها حركة الإدارة.

الخطوة 9: تشغيل التطبيق في كل منطقة

توزّع خدمة Swarm العادية الطلبات عبر عنوان الخدمة على جميع النسخ (Replicas) في العنقود، أي على القارات الأخرى أيضاً. ومع ثلاث قارات سيعني ذلك أن كل طلب ثانٍ أو ثالث يقطع نصف العالم. لذلك تحصل كل منطقة على خدمة خاصة بها، تبقى في منطقتها بفضل قاعدة التوزيع. وتضمن إعدادات التحديث أن تُطرح الإصدارات الجديدة حاويةً تلو الأخرى، وأن يُتراجع عنها تلقائياً عند حدوث أخطاء:

for r in eu us asia; do
  docker service create --name web-$r --replicas 2 --network appnet \
    --constraint node.labels.region==$r \
    --update-parallelism 1 --update-delay 30s \
    --update-failure-action rollback \
    registry.example.com/web:1.0
done

لكي يميّز Swarm بين حاوية تؤدي عملها فعلاً وحاوية قيد التشغيل فحسب، ينبغي أن يكون فحص السلامة جزءاً من الصورة (Image)، مثل هذا السطر في ملف Dockerfile الخاص بتطبيقكم:

HEALTHCHECK --interval=10s --timeout=3s --retries=3 CMD wget -qO- http://127.0.0.1:8080/health || exit 1

الحاوية التي يفشل فحص السلامة الخاص بها ثلاث مرات متتالية تُستبدل، وأثناء التحديث يوقف فحص السلامة الفاشل عملية الطرح.

الخطوة 10: نقطة دخول لكل منطقة

يتولى دور نقطة الدخول وكيل عكسي (Reverse Proxy) مثل Caddy أو Traefik أو nginx. وهو أيضاً يعمل في كل منطقة كخدمة مستقلة، ولا يمرر الطلبات إلا إلى تطبيق منطقته. وفي وضع المضيف (Host Mode) ينشر المنفذين 80 و443 مباشرة على خادم منطقته. ويكفي إعداد مشترك واحد، لأن Caddy يقرأ الوجهة من متغير بيئة:

example.com {
    reverse_proxy {$UPSTREAM}:80
}

docker config create caddyfile ./Caddyfile
for r in eu us asia; do
  docker service create --name edge-$r --network appnet \
    --constraint node.labels.region==$r \
    --env UPSTREAM=web-$r \
    --config source=caddyfile,target=/etc/caddy/Caddyfile \
    --publish mode=host,target=80,published=80 \
    --publish mode=host,target=443,published=443 \
    caddy:2
done

تحتاج جميع المناطق إلى شهادة TLS للنطاق نفسه. لذلك احصلوا على الشهادات عبر تحدي DNS (DNS Challenge)، الذي يعمل بغض النظر عن المنطقة التي يشير إليها سجل DNS حالياً؛ ويحتاج Caddy لذلك إلى الوحدة الخاصة بمزود DNS لديكم. أساسيات الوكيل العكسي موضحة في مقال إعداد nginx كوكيل عكسي.

الخطوة 11: إعداد Geo-DNS مع تجاوز الفشل

المكوّن الأخير يقود المستخدمين إلى المنطقة الصحيحة. فخدمة DNS تدعم التوجيه الجغرافي (Geo-Routing) وفحوص السلامة توجّه المستخدمين من أوروبا إلى فرانكفورت أم ماين، ومن أمريكا إلى الساحل الشرقي للولايات المتحدة، ومن آسيا إلى سنغافورة. وإذا تعطلت منطقة، يكتشف فحص السلامة ذلك خلال 30 إلى 60 ثانية، ويوجّه مستخدميها إلى أقرب منطقة سليمة. اضبطوا مدة صلاحية السجلات (TTL) على 60 ثانية، لكي تعتمد المحلّلات (Resolvers) التحويل بسرعة. أما سجلات A المتعددة دون فحص سلامة فليست سوى حل اضطراري: صحيح أن المتصفحات تجرّب غالباً العنوان التالي، لكن ليس كل برنامج عميل يفعل ذلك، وتبقى المنطقة المعطلة ضمن الإجابة.

احسبوا بواقعية: بين التعطل والتحويل يمضي فاصل الفحص مضافاً إليه TTL، أي في هذا المثال دقيقة إلى دقيقتين، يظل خلالها جزء من مستخدمي المنطقة المتأثرة يصل إلى الموقع المعطل. أما التطبيقات وتطبيقات الجوال التي تعيد إرسال الطلبات الفاشلة بعد توقف قصير، فتتجاوز هذه الفترة دون أن يُلاحَظ ذلك تقريباً.

الخطوة 12: اختبار تعطل منطقة

تجاوز الفشل الذي لم يُجرَّب قط نادراً ما ينجح عند الحاجة الفعلية. حاكوا تعطل منطقة بإخراج عقدتها من الخدمة، وراقبوا كيف يستجيب العنقود وDNS:

docker node update --availability drain swarm-asia
docker node ls
docker service ls
docker node update --availability active swarm-asia

لأن خدمات المنطقة مرتبطة بعقدتها عبر قاعدة التوزيع، فإنها لا تنتقل إلى عقدة أخرى بل تتوقف مؤقتاً؛ ويتولى تجاوز الفشل عبر DNS أمر مستخدمي المنطقة. لذلك تحققوا في هذا الاختبار قبل كل شيء من أن فحص السلامة يُخرج المنطقة من الإجابات، وأن المنطقة المجاورة تتحمل الحمل الإضافي. ولاختبار أشد افصلوا العقدة عن الشبكة كلياً، مثلاً بإيقاف WireGuard. كرروا الاختبار بعد التغييرات الكبيرة، ومرة واحدة كل ربع سنة على الأقل.

البيانات: أصعب جزء في التوافر العالي

يوفّر Docker Swarm النسخ المتماثل للحاويات، لا للبيانات. فوحدة التخزين (Volume) توجد دائماً على العقدة التي تعمل عليها الحاوية. لذلك يمكن تشغيل الخدمات عديمة الحالة، مثل الواجهات الأمامية للويب وواجهات API، في كل منطقة دون مشكلات، أما كل ما يتضمن بيانات فيحتاج إلى نسخ متماثل خاص به.

النسخ المتماثل لقواعد البيانات عبر القارات

تأتي قواعد البيانات بآليات نسخ متماثل خاصة بها، وهذه الآليات أفضل دائماً من تخزين مشترك يمتد عبر مراكز البيانات. وعبر القارات أثبت نموذج بعينه جدواه: مثيل أساسي (Primary) في منطقة واحدة مع نسخ متماثلة غير متزامنة في المنطقتين الأخريين، ففي PostgreSQL مثلاً عبر Streaming Replication مع أداة مثل Patroni للتبديل التلقائي، وفي MariaDB وMySQL عبر النسخ المتماثل المدمج. عندها تجيب كل منطقة عن طلبات القراءة محلياً، بينما تذهب عمليات الكتابة إلى المثيل الأساسي. ولنكن صريحين: غير متزامن يعني أيضاً أنه إذا تعطلت المنطقة الأساسية، فقد تضيع عمليات الكتابة التي جرت في الثواني الأخيرة. ومن يريد الكتابة من أي مكان في العالم دون أن يفقد شيئاً، يلجأ إلى قواعد بيانات مصممة لعدة مناطق، مثل CockroachDB أو YugabyteDB. اربطوا عُقد قاعدة البيانات بمنطقتها ربطاً ثابتاً عبر قاعدة التوزيع، حتى لا ينقلها Swarm أبداً بعيداً عن بياناتها:

docker service create --name db-asia --constraint node.labels.region==asia ...

الملفات والمحتوى المرفوع

لا مكان للملفات المرفوعة في وحدة تخزين محلية، بل في تخزين كائنات (Object Storage) متوافق مع S3 مع نسخ متماثل إلى منطقة ثانية، أو في نظام تخزين خاص بكم يعمل بالنسخ المتماثل. أما أنظمة الملفات الشبكية مثل NFS عبر القارات فبطيئة، وهي نفسها نقطة فشل وحيدة.

الجلسات وذاكرات التخزين المؤقت

إذا كان التطبيق يحفظ الجلسات في ذاكرة الحاوية، يفقد المستخدمون تسجيل دخولهم عند التبديل. احفظوا الجلسات في قاعدة بيانات أو ذاكرة تخزين مؤقت (Cache) تعمل بالنسخ المتماثل مثل Redis، أو استخدموا رموزاً موقّعة (Tokens) تستطيع كل منطقة التحقق منها بنفسها.

النسخ الاحتياطية تبقى إلزامية

يحمي النسخ المتماثل من تعطل موقع، لكنه لا يحمي من الأخطاء: السجل الذي يُحذف عن طريق الخطأ يُحذف بعد ثوانٍ في جميع المناطق. لذلك تُعد النسخ الاحتياطية المنتظمة والمختبرة في مكان مستقل جزءاً من كل بنية عالية التوافر، كما هو موضح في مقال استراتيجية النسخ الاحتياطي للخوادم.

التشغيل: التحديثات والصيانة والمراقبة

التحديث منطقةً تلو الأخرى

لا تطرحوا الإصدارات الجديدة في جميع المناطق في وقت واحد، بل منطقةً تلو الأخرى، وراقبوا كل منطقة لفترة قصيرة قبل الانتقال إلى التالية. بهذه الطريقة لا يصل الخطأ الذي لا يكتشفه أي فحص سلامة إلا إلى منطقة واحدة على الأكثر، وتواصل المنطقتان الأخريان خدمة مستخدميها:

for r in asia us eu; do
  docker service update --image registry.example.com/web:1.1 web-$r || break
  sleep 300
done

إذا فشل تحديث، يتراجع عنه Swarm تلقائياً بفضل الإعدادات من الخطوة 9، وينهي || break الحلقة بمجرد أن يُبلغ الأمر عن خطأ. أما التحديث الذي لا تظهر مشكلته إلا لاحقاً، فتتراجعون عنه يدوياً بالأمر docker service rollback web-asia.

صيانة منطقة

إذا كان لا بد من إعادة تشغيل خادم أو تحديثه، فأخرجوه من الخدمة بالأمر docker node update --availability drain، ودعوا تجاوز الفشل عبر DNS يحوّل مستخدميه مسبقاً إلى المناطق المجاورة. وبعد الصيانة أعيدوه إلى الخدمة بالخيار --availability active. ولا تنتقلوا إلى عقدة المدير التالية حتى يعرض docker node ls العُقد الثلاث كلها متاحة من جديد، لكي لا تغيب عقدتا مدير في الوقت نفسه أبداً.

المراقبة من الخارج

راقبوا كل منطقة على حدة ومن خارج العنقود: إمكانية الوصول إلى نقاط الدخول، وفحوص سلامة الخدمات، وحالة عُقد المدير، وتأخر النسخ المتماثل لقاعدة البيانات، وتواريخ انتهاء صلاحية الشهادات والنطاقات. يجب أن يصل التنبيه حتى عندما تصمت منطقة بأكملها. أما كيف تبنون ذلك للخوادم المنفردة، فيوضحه مقال إعداد مراقبة الخادم.

توزيع الأسرار بأمان

لا مكان لكلمات المرور والمفاتيح في متغيرات البيئة أو ملفات Compose، بل في Docker Secrets. فهي تُحفظ مشفرة في سجل Raft، ولا تُسلَّم إلا إلى الخدمات التي تسندونها إليها صراحةً:

printf '%s' 'كلمة_مرور_قاعدة_بياناتكم' | docker secret create db_password -
docker service update --secret-add db_password web-eu

لماذا KernelHost لعنقود Swarm عبر عدة قارات

يفرض العنقود الممتد عبر عدة قارات على المزود متطلبات تختلف عن متطلبات الخادم المنفرد. وهذه هي النقاط الحاسمة عملياً:

تجدون نظرة عامة على جميع الباقات السحابية مع أسعارها، ومقارنة للتكاليف مع كبار مزودي الخدمات السحابية، في صفحة استئجار خادم سحابي.

أخطاء شائعة وكيف تتجنبونها

• عُقد المدير في موقعين فقط. إذا تعطل الموقع الذي يضم الأغلبية، يتوقف العنقود. الحل: ثلاثة مواقع، بتوزيع 1-1-1 أو 2-2-1.
• عدد زوجي من عُقد المدير. أربع عُقد مدير لا تتحمل أعطالاً أكثر مما تتحمله ثلاث، لكنها تزيد عبء التنسيق. الحل: 3 أو 5 أو 7.
• طلبات تنتقل بين القارات. عنوان خدمة واحد لكل المناطق يرسل المستخدمين عبر نصف العالم. الحل: خدمة ونقطة دخول لكل منطقة.
• منافذ Swarm متاحة للعموم. المنفذ 2377 وشبكة Overlay لا مكان لهما أبداً على الإنترنت المفتوح. الحل: عبر WireGuard فقط، ولا يُفتح للعموم سوى 80 و443 وWireGuard للعُقد الأخرى.
• نسيان MTU. الاستجابات الكبيرة تتعلق، والصغيرة تعمل. الحل: MTU لشبكة Overlay بقيمة 1370 مع WireGuard بقيمة 1420.
• الاعتماد على ufw في منافذ الحاويات. يتجاوز Docker جدار ufw في المنافذ المنشورة. الحل: نشر نقطة الدخول فقط.
• قاعدة بيانات في Volume دون نسخ متماثل. إذا تعطلت المنطقة، يتعذر الوصول إلى البيانات. الحل: نسخ متماثل لقاعدة البيانات، وتثبيت توزيعها على منطقتها.
• التحديث في جميع المناطق في وقت واحد. عندها يصيب الخطأ جميع المستخدمين حول العالم. الحل: الطرح منطقةً تلو الأخرى.
• قيمة TTL عالية في DNS. مع TTL مدتها يوم كامل لا يسري مفعول تجاوز الفشل إلا في اليوم التالي. الحل: 60 ثانية.
• النسخ المتماثل بدلاً من النسخ الاحتياطي. الخطأ يُنسخ تماثلياً تماماً كما تُنسخ البيانات السليمة. الحل: نسخ احتياطية مختبرة إضافية في مكان مستقل.

الخلاصة باختصار

• عنقود Docker Swarm الممتد عبر ثلاث قارات مصمَّم لوقت تشغيل بنسبة 100%: يمكن أن يتعطل موقع كامل أو قارة كاملة دون أن يتوقف التطبيق.
• لا يستطيع أحد أن يضمن التوافر ضماناً مطلقاً، والمخاطر المتبقية هي DNS والتحديثات المعيبة وقاعدة البيانات والشهادات، ولكل منها إجراء مضاد.
• ثلاث عُقد مدير في ثلاثة مواقع هي الحد الأدنى، وموقعان لا يكفيان لنصاب يصمد أمام الأعطال.
• يبقى كل طلب في منطقته: خدمة ونقطة دخول لكل منطقة، إضافة إلى Geo-DNS مع فحوص السلامة وTTL قصيرة.
• يشفّر WireGuard حركة مرور العنقود، وتبقى منافذ Swarm غير مرئية، وتنخفض قيمة MTU لشبكة Overlay إلى 1370.
• يوفّر Swarm النسخ المتماثل للحاويات، لا للبيانات: تحتاج قواعد البيانات إلى نسخ متماثل خاص بها، وتبقى النسخ الاحتياطية إلزامية.
• توفر KernelHost مواقع في أوروبا وأمريكا الشمالية وآسيا والمحيط الهادئ، وحركة مرور غير محدودة، وحماية DDoS في كل موقع، ومحاسبة بنظام PrePaid دون حد أدنى للمدة.