لماذا تختار Elasticsearch السحابي على خادم VPS خاص بك
يتألق Elasticsearch حيث لا يعود البحث البسيط كافيًا: تسجيل BM25 قابل للضبط، والمرادفات، والمحلّلات اللغوية المخصّصة (الفرنسية والعربية ICU)، والاستعلامات الجغرافية، وحزمة ELK الكاملة لمركزة سجلات تطبيقاتك. تصبح عروض Elastic Cloud وOpenSearch Service باهظة بسرعة بمجرد أن يتجاوز الحجم المُفهرَس بضعة غيغابايتات، مع إضافة رسوم البيانات الصادرة. وعلى خادم VPS الخاص بك، أنت من يقرّر الإصدار المُنشَر والإضافات المُفعَّلة ومدة الاحتفاظ بالبيانات وسياسة اللقطات. وهو أيضًا السبيل الوحيد للاحتفاظ بالبيانات الحساسة — سجلات التطبيقات وفهارس العملاء — داخل بنيتك التحتية الخاصة، دون أي تبعية لطرف سحابي خارجي.
ما الذي تكسبه باستضافة Elasticsearch ذاتيًا
- بحث متقدّم بالنص الكامل: تسجيل BM25 والمرادفات ومحلّلات لغوية مخصّصة (الفرنسية والعربية ICU)
- تجميعات وأوجه (facets) معقّدة للتجارة الإلكترونية أو ذكاء الأعمال أو مركزة السجلات
- حزمة ELK كاملة (Logstash وBeats وKibana) دون رسوم برمجيات إضافية
- تحكّم كامل في الإصدار والإضافات وسياسات دورة حياة الفهارس (ILM)
- لا فوترة لكل حجم مُفهرَس ولا رسوم للبيانات الصادرة عبر الشبكة
- لقطات (snapshots) إلى تخزينك الكائني الخاص للتعافي من الكوارث بشكل مُتحكَّم فيه
- البيانات الحساسة محفوظة داخل بنيتك التحتية الخاصة، تحت اختصاصك القضائي وحدك
المتطلبات بالأرقام قبل تشغيل أول حاوية
الحدّ الأدنى من ذاكرة RAM: 4 غيغابايت لبيئة اختبار، 8 غيغابايت (2-4 vCPU) لاستخدام إنتاجي خفيف، 16 غيغابايت بمجرد إضافة Kibana أو فهرسة عدة ملايين من المستندات. المعامل الرئيسي هو كومة JVM: اضبط -Xms و-Xmx على 50% من ذاكرة RAM المتاحة، دون تجاوز 32 غيغابايت (فوق ذلك، تنتقل JVM إلى وضع ضغط المؤشرات الأقل كفاءة). على خادم VPS بذاكرة 8 غيغابايت، استخدم -Xms4g -Xmx4g. على مستوى الشبكة، يستخدم Elasticsearch منفذين: 9200 (HTTP، واجهة API REST) و9300 (النقل بين العقد). لا تعرض المنفذ 9200 مباشرةً على الواجهة العامة — فهذا المصدر الأول للاختراق على الأنظمة غير المؤمَّنة. أما على مستوى التخزين، فـSSD NVMe موصى به: يُجري Elasticsearch عمليات قراءة عشوائية كثيرة على شرائح Lucene؛ ويتشبّع القرص المغناطيسي أو SSD منخفض الجودة بسرعة على الفهارس الكبيرة. خطّط أيضًا لتثبيت Docker وDocker Compose، ونطاق فرعي es.yourdomain.com يشير إلى الخادم.
النشر خطوة بخطوة
تجهيز نواة Linux
قبل تشغيل الحاوية، طبّق ضبطَين إلزاميَّين على مستوى النظام. أولًا، ارفع حدّ مناطق الذاكرة المُعيَّنة: sysctl -w vm.max_map_count=262144. ثبّت هذا الإعداد بإضافة vm.max_map_count=262144 إلى /etc/sysctl.conf — بدونه، يرفض Elasticsearch الإقلاع برسالة خطأ max virtual memory areas vm.max_map_count [65530] is too low. ثم عطّل التبديل (swap) على الخادم (swapoff -a وعلّق السطر المتعلق بـ swap في /etc/fstab)، أو اضبط bootstrap.memory_lock=true في elasticsearch.yml لمنع JVM من الترحيل إلى القرص، مما قد يُدمّر الأداء.
كتابة ملف docker-compose.yml
أنشئ دليل عمل، ثم ملف docker-compose.yml يحتوي على خدمة Elasticsearch: الصورة docker.elastic.co/elasticsearch/elasticsearch:8.13.4، ومتغير البيئة ES_JAVA_OPTS=-Xms4g -Xmx4g (اضبطه بحسب الخادم)، وحجم تخزين مُسمَّى مثبَّت على /usr/share/elasticsearch/data، والمنفذ 9200 مربوط بـ 127.0.0.1 فقط (127.0.0.1:9200:9200). أضف أيضًا discovery.type=single-node لنشر أحادي العقدة. لا تنشر 0.0.0.0:9200:9200 في الإنتاج أبدًا.
تفعيل xpack.security وتشغيل الخدمة
في elasticsearch.yml، أضف xpack.security.enabled: true وxpack.security.http.ssl.enabled: true. منذ الإصدار 8.x، يكون الأمان مُفعَّلًا افتراضيًا، لكن تحقّق من أن ملف الإعداد لا يُعطّله صراحةً. شغّل المجموعة: docker compose up -d. عند التشغيل الأول، انتظر من 2 إلى 3 دقائق — تهيئة فهارس النظام (.security-* و.kibana_*) تستغرق وقتًا. راجع السجلات: docker compose logs -f elasticsearch.
إنشاء المستخدمين واسترجاع كلمة مرور elastic
بعد تشغيل الحاوية، أعد تعيين كلمة مرور المستخدم المتميّز elastic: docker exec -it elasticsearch bin/elasticsearch-reset-password -u elastic. احتفظ بهذه الكلمة في مدير أسرار. ثم أنشئ مستخدم النظام kibana_system إن أضفت Kibana: docker exec -it elasticsearch bin/elasticsearch-users useradd kibana_system -r kibana_system. يجب ألّا يُستخدم هذا الحساب في استعلامات التطبيقات — أنشئ مستخدمين مخصّصين لكل تطبيق مع أدوار بالحدّ الأدنى اللازم.
التحقّق من المجموعة باستخدام curl
اختبر الاتصال من الخادم (وليس من الخارج): curl -u elastic:<كلمة_المرور> https://localhost:9200 --cacert /usr/share/elasticsearch/config/certs/http_ca.crt. استجابة JSON تحتوي على cluster_name وstatus: green أو yellow تؤكّد أن المجموعة تعمل. الحالة yellow على مجموعة أحادية العقدة طبيعية: لا يمكن تخصيص نسخ الشظايا (shard replicas) دون عقدة ثانية.
الكشف عبر وكيل عكسي HTTPS مع Nginx
ثبّت Nginx على الخادم وعيّن مضيفًا افتراضيًا لـ es.yourdomain.com. يُعيد الوكيل العكسي توجيه الطلبات إلى https://127.0.0.1:9200 ويُقدّم شهادة Let's Encrypt للعميل. أضف مصادقة أساسية Nginx كطبقة حماية إضافية إن كانت واجهة API يجب الوصول إليها من الخارج. أعِد توجيه المسارات الضرورية لتطبيقك فقط — تجنّب كشف /_cat/* أو /_cluster/* للعموم.
أمان xpack: TLS والأدوار وعزل الشبكة
يغطّي أمان xpack في Elasticsearch ثلاث طبقات. TLS بين العقد (xpack.security.transport.ssl.enabled: true) يشفّر حركة البيانات بين العقد على المنفذ 9300 — ضروري حالما تنضمّ عقدة ثانية إلى المجموعة. TLS على HTTP (xpack.security.http.ssl.enabled: true) يشفّر المنفذ 9200؛ بدونه تنتقل كلمات المرور بنصّ واضح حتى على شبكة خاصة. التحكّم في الأدوار: يوفّر Elasticsearch أدوارًا مُحدَّدة مسبقًا (read وwrite وmonitor وkibana_system وlogstash_writer). خصّص الدور الأدنى المطلوب لكل تطبيق: لا يحتاج تطبيق يقرأ فهرسًا واحدًا إلى دور superuser. تجنّب استخدام حساب elastic في الإنتاج — خصّصه للإدارة الأولية فقط. نقطة أخيرة: معامل network.host في elasticsearch.yml. قيمته الافتراضية هي _local_ (loopback فقط). الانتقال إلى 0.0.0.0 للاستماع على كل الواجهات دون تهيئة أمان xpack يُعرّض مجموعتك للإنترنت بأسره.
تصليب الوصول إلى الشبكة باستخدام UFW
بعد التحقّق من أن Elasticsearch يستمع على 127.0.0.1 فقط، أغلق جدار الحماية: ufw deny 9200/tcp وufw deny 9300/tcp. يجب أن يكون الوكيل العكسي Nginx (المنفذ 443) هو الوحيد المتاح. إن تواصلت عدة عقد مع بعضها، اسمح صراحةً لعناوين IP العقد على المنفذ 9300 (ufw allow from <IP_العقدة_2> to any port 9300)، وأغلق كل ما عدا ذلك. يمنحك الأمر ufw status بعد الضبط صورة دقيقة عمّا هو مفتوح.
استكشاف الأخطاء: الأعطال الخمسة الأكثر شيوعًا
1. OOM Killer يوقف عملية Elasticsearch. العرَض: تتوقف الحاوية دون رسالة خطأ في السجلات، ويكشف dmesg | grep -i killed عن Killed process. السبب: الكومة -Xmx أكبر مما تتيحه ذاكرة RAM، أو تُشبعها عمليات أخرى. الحلّ: قلّص -Xmx إلى 50% من ذاكرة RAM المتاحة الفعلية، وراقب استهلاك الذاكرة بـ docker stats.
2. max_map_count منخفض جدًا. العرَض: يرفض Elasticsearch الإقلاع برسالة max virtual memory areas vm.max_map_count [65530] is too low. الحلّ: sysctl -w vm.max_map_count=262144 ثم أضف vm.max_map_count=262144 إلى /etc/sysctl.conf.
3. Permission denied على /usr/share/elasticsearch/data. العرَض: تظهر رسالة AccessDeniedException في السجلات عند تثبيت الحجم. السبب: دليل المضيف يملكه root لكن الحاوية تعمل بالمعرّف UID 1000 (المستخدم elasticsearch). الحلّ: chown -R 1000:1000 <مسار_حجم_المضيف> قبل تشغيل docker compose up.
4. رفض الاتصال على المنفذ 9200. العرَض: curl localhost:9200 يُعيد Connection refused. السبب الشائع: network.host مُضبوط بشكل خاطئ في elasticsearch.yml (قيمة _site_ أو عنوان IP لا يتطابق مع واجهة Docker). على مجموعة Docker أحادية العقدة، اترك network.host بقيمته الافتراضية (_local_) وادخل عبر 127.0.0.1:9200 من الحاوية أو المضيف. تحقّق أيضًا من أن الحاوية تعمل: docker ps.
5. بطء الإقلاع: طبيعي عند التهيئة الأولى. العرَض: تستغرق المجموعة من 2 إلى 3 دقائق للاستجابة عند التشغيل الأول. هذا ليس عطلًا. Elasticsearch يُهيّئ فهارس النظام (.security-7 و.kibana_1 وخرائط الأعمدة الافتراضية). انتظر ظهور mode [basic], reason [security is enabled] أو Cluster health status changed from [RED] to [GREEN] في السجلات قبل إرسال أي استعلام.
هل تريد بديلًا مفتوح المصدر بالكامل؟
OpenSearch هو التفريع المجتمعي من Elasticsearch، وُلد عام 2021 حين غيّرت شركة Elastic ترخيصها إلى SSPL (غير معتمد من OSI). يحافظ OpenSearch على ترخيص Apache 2.0، ويوفّر واجهة API REST متوافقة إلى حدٍّ بعيد، ويتضمّن ميزات أمان متقدّمة في توزيعته المجانية (التحكّم في الوصول بالأدوار، وتسجيل الأحداث، وتشفير البيانات أثناء التخزين). إن كان قيدك هو الترخيص مفتوح المصدر صراحةً أو الاستقلالية عن Elastic BV، فإن OpenSearch بديل مباشر يستحق التقييم. يتّبع نشر Docker النمط ذاته، باستخدام الصورة opensearchproject/opensearch بدلًا من ذلك.
