دليل شامل: استضافة تطبيقات ويب Hugo ذاتياً باستخدام FreeBSD Jails و Bastille

Updated يونيو 19, 2026 14 min read

Aldawsari

دقائق القراءة: 14

بعد سنوات من الاعتماد على خدمات الاستضافة مثل Netlify، قررتُ العودة إلى الاستضافة الذاتية (Self-hosting). كانت الأسباب متعددة، لكن الدافع الرئيسي هو الرغبة في التحكم الكامل في كيفية عمل الأمور. في هذا المقال، سأشارككم سير عملي الخاص لنشر موقعي المُنشأ بواسطة Hugo. بدلاً من استخدام الطرق الشائعة، سأقوم بكل ذلك باستخدام خادم يعتمد على FreeBSD Jails مع أداة Bastille. بالإضافة إلى ذلك، سأكشف لكم بعض الحيل التي تعلمتها على مر السنين بخصوص تغيير حجم الصور دفعة واحدة والمزيد. لنبدأ!

أين تستضيف موقعك؟

إذا كنت ترغب في استضافة خدمتك الخاصة، فستحتاج إلى خادم. هنا يأتي دور مزودي الخوادم الافتراضية الخاصة (VPS) مثل Digital Ocean أو Vultr. لقد كنت من المعجبين بـ Digital Ocean واستخدمته لفترة طويلة. لإعداد خادم جديد، اتبع الخطوات التالية:

سجل الدخول إلى Digital Ocean. (إذا لم يكن لديك حساب وترغب في دعم هذه المدونة، انقر هنا لإنشاء حساب).
انتقل إلى Account Settings -> Security وتأكد من إعداد مفتاح SSH.
أنشئ خادم FreeBSD droplet جديد. تأكد من استخدام إصدار UFS.

تأكد من اختيار خطة 5 دولارات شهرياً. للمواقع البسيطة، هذا أكثر من كافٍ!

تأكد من تحديد مفتاح SSH الخاص بك.

أخيراً، انقر على الزر الأخضر Create Droplet!

بعد الانتهاء، قم بالاتصال بالخادم عبر SSH:

ssh root@<yourserverip>

إعداد خادم FreeBSD الخاص بك باستخدام Bastille

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

إذن، ما هو البديل؟ FreeBSD Jails باستخدام Bastille. لقد كنت أتعامل مع Bastille منذ بضعة أشهر، وكلما استخدمته أكثر، كلما أدركت أنه الخيار الأمثل. يسمح لك Bastille بإنشاء jails خفيفة الوزن تعتمد على FreeBSD (والتي أصبحت الآن قابلة للنقل). هذه الـ jails هي “حاويات” لا تتطلب أي موارد إضافية تقريباً. لا يوجد daemon خاص بها (نظام التشغيل هو الـ “daemon“!). بالإضافة إلى ذلك، تعتبر الـ jails أكثر أماناً مقارنة بـ Docker الذي يمكن أن يفتح “صندوق باندورا” من المشاكل الأمنية. نعم، قد تحتاج إلى تجميع وتهيئة بعض الأدوات المساعدة. لكن معظمها مدعوم بالفعل في مدير حزم FreeBSD، وهو pkg. في هذا القسم، ستتعلم كيفية تشغيل jail مع caddy لتتمكن من استضافة موقعك بشكل آمن. لنحافظ على الزخم!

بمجرد حصولك على عنوان IP لخادمك، يجب عليك تسجيل الدخول:

ssh root@123.456.789.10

يجب أن تتلقى رسالة MOTD وموجه sh. ممتاز!

FreeBSD 12.1-RELEASE-p2 GENERIC Welcome to FreeBSD! ... #

لنقم بتثبيت بعض الأدوات الهامة باستخدام pkg (مدير حزم FreeBSD):

pkg install restic rsync bastille

سنستخدم restic للنسخ الاحتياطي، rsync لنقل الملفات، و bastille لإعداد الـ jail. يجب عليك أيضاً إعداد بعض المسارات الثابتة في ملف pf.conf الخاص بك. إليك مثال على إعداداتي:

ext_if="vtnet0" # Caddy related caddy_addr=10.10.2.20 set block-policy return scrub in on $ext_if all fragment reassemble set skip on lo table <jails> persist nat on $ext_if from <jails> to any -> $ext_if # container routes rdr pass inet proto tcp from any to port 80 -> $caddy_addr port 8880 rdr pass inet proto tcp from any to port 443 -> $caddy_addr port 4443 # Enable dynamic rdr (see below) rdr-anchor "rdr/*" block in all pass out quick modulate state antispoof for $ext_if inet pass in inet proto tcp from any to any port ssh flags S/SA keep state

هذا ملف pf.conf قياسي لـ bastille. تأكد من تعديل caddy_addr إلى عنوان IP الذي اخترته. الآن لنبدأ جدار الحماية. سيتم قطع اتصال ssh الخاص بك:

sysrc pf_enable="YES" service pf start

ثم لنقم ببعض إعدادات bastille:

# set up bastille networking sysrc cloned_interfaces+=lo1 sysrc ifconfig_lo1_name="bastille0" service netif cloneup # bootstrap the base jail and start bastille bastille bootstrap 12.1-RELEASE update sysrc bastille_enable="YES" service bastille start

سيقوم هذا بإعداد شبكتك، وجلب أحدث base jail افتراضي ستستخدمه لاحقاً. بعد ذلك، لنقم بإعداد الـ jail:

bastille create caddy 12.1-STABLE 10.10.2.20 bastille start caddy

ثم قم بتثبيت caddy:

#install the binary fetch https://github.com/caddyserver/caddy/releases/download/v1.0.4/caddy_v1.0.4_freebsd_amd64.tar.gz tar xvf caddy_v1.0.4_freebsd_amd64.tar.gz caddy bastille cp caddy caddy /usr/local/bin/ rm caddy #create the caddy user bastille cmd caddy pw useradd caddy -m -s /usr/sbin/nologin #install ca root file bastille pkg caddy install ca_root_nss

عند تثبيت ca_root_nss، سيتعين على pkg التهيئة. اقبل المطالبات. بمجرد الانتهاء من هنا، سننتقل إلى الخطوة التالية!

بمجرد اكتمال التثبيت، يجب علينا أيضاً تهيئة caddy للبدء عند الإقلاع. أسهل طريقة للقيام بذلك هي استخدام هذا السكريبت rc.d:

#!/bin/sh # $FreeBSD: head/net/caddy/files/caddy.in 452063 2017-10-14 12:58:24Z riggs $ # # PROVIDE: caddy # REQUIRE: LOGIN # KEYWORD: shutdown # # Add the following lines to /etc/rc.conf.local or /etc/rc.conf # to enable this service: # # caddy_enable (bool): Set to NO by default. # Set it to YES to enable caddy. # caddy_user (user): Set user to run caddy. # Default is "caddy". # caddy_group (group): Set group to run caddy. # Default is "caddy". # caddy_conf (path): Path to caddy configuration file. # Default is /usr/local/etc/caddyfile.conf . /etc/rc.subr name=caddy rcvar=caddy_enable load_rc_config $name : ${caddy_enable:="NO"} : ${caddy_user:="caddy"} : ${caddy_group:="caddy"} : ${caddy_conf:="/usr/local/etc/caddyfile.conf"} : ${caddy_log:="/home/caddy/caddy.log"} : ${caddy_env:="CADDYPATH=/home/caddy/"} : ${caddy_https_port:="4443"} : ${caddy_http_port:="8880"} pidfile="/var/run/caddy.pid" procname="/usr/local/bin/caddy" command="/usr/sbin/daemon" command_args="-f -p ${pidfile} /usr/bin/env ${caddy_env} ${procname} -agree -http-port ${caddy_http_port} -https-port ${caddy_https_port} -conf=${caddy_conf} -log=${caddy_log} ${caddy_args}" extra_commands="reload" start_precmd=caddy_startprecmd reload_cmd=caddy_reloadcmd caddy_startprecmd () { if [ ! -e ${pidfile} ]; then install -o ${caddy_user} -g ${caddy_group} /dev/null ${pidfile} ; fi } caddy_reloadcmd () { kill -s USR1 $(cat ${pidfile}) } run_rc_command "$1"

احذف ملف caddy التنفيذي إذا لم تكن قد فعلت ذلك بالفعل. ثم أنشئ ملفاً جديداً باستخدام vi. سيكون هذا هو سكريبت rc.d الخاص بك!

vi caddy

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

chmod +x caddy bastille cp caddy caddy /usr/local/etc/rc.d/

أخيراً، سنحتاج إلى ملف Caddyfile. إليك مثال عليه:

stage.jaredwolff.com { tls hello@jaredwolff.com log /home/caddy/stage.jaredwolff.com.log root /var/www/stage.jaredwolff.com/ gzip log stderr }

يشير log إلى سجل الوصول الخاص بهذا الموقع. يشير root إلى مكان مجلد public الرئيسي على جهازك. في حالتي، هو المسار الشائع /var/www/<name of site>. قم بتعيين مساراتك وتذكرها. سنحتاجها لاحقاً!

لكي يقوم Caddy بإنشاء شهادات لهذا النطاق الفرعي، سيتعين عليك تعيين خيار tls. كل ما هو مطلوب هو عنوان بريد إلكتروني. لمزيد من المعلومات حول بنية Caddyfile، راجع الوثائق.

أنشئ ملفاً باسم caddyfile.conf وانسخه إلى /usr/local/etc/ في حاوية Caddy الخاصة بك:

vi caddyfile.conf # Paste your caddyfile contents and save bastille cp caddy caddyfile.conf /usr/local/etc/

يجب عليك الآن إعادة توجيه نظام أسماء النطاقات (DNS) الخاص بك إلى عنوان IP للخادم. بهذه الطريقة، يمكن لـ Caddy إنشاء/جلب الشهادات الصحيحة. ثم يمكنك بدء Caddy باستخدام:

bastille service caddy caddy start

يمكنك التحقق من السجل في /usr/home/caddy/caddy.log للتأكد من أن نطاقك تم توفيره بشكل صحيح. ملاحظة جانبية: إعداد شهادات SSL قد يكون صعباً في البداية، خاصة إذا كنت تنتقل من خادم آخر. سيتوقف موقعك لفترة قصيرة أثناء تبديل إعدادات DNS وبدء تشغيل caddy. (هذا إذا كنت تستخدم caddy 1.0 القياسي. يمكنك أيضاً استخدام إضافات مزود DNS هنا والتي تجعل الأمور أسهل قليلاً).

الآن بعد أن أصبح caddy يعمل، حان الوقت لنسخ أصول hugo المُنشأة باستخدام rsync. نحن في طريقنا إلى الخطوة التالية!

تبسيط عملية البناء والنشر

أقضي الكثير من الوقت في كتابة أكواد C، وهذا يعني أنني أقضي الكثير من الوقت في استخدام Makefiles. بالنسبة للكثيرين، make (أو gmake لـ GNU make) هو كابوس وجودهم. لكن لبناء ونشر المواقع، يجعل make من السهل إنشاء “وصفات” قابلة لإعادة الاستخدام. بهذه الطريقة، يمكنك النشر بثقة في كل مرة.

يستعير ملف Makefile الخاص بي من الملف الذي نشرته فيكتوريا دريك مؤخراً. قمت بتعديله قليلاً ليناسب احتياجاتي. دعنا نلقي نظرة على محتوياته:

.POSIX: HUGO_VERSION := 0.66.0 OPTIMIZED_DIR := optimized CONTENT_DIR := content DEST_DIR := public SERVER := 123.456.789.10 USER := user

يحتوي القسم الأول على جميع المتغيرات التي أستخدمها لإخبار الدوال لاحقاً بما يجب فعله. كما يحتوي على مرجع إلى الهدف .POSIX. هذا يعني أن ملف Makefile سيكون قابلاً للنقل بين إصدارات مختلفة من make. ثم، أضفت بعض المنطق لتحديد ما إذا كنت أقوم بالنشر إلى بيئة التطوير (stage) أو الإنتاج (production):

# Set the place where it's deployed to. ifdef PRODUCTION $(info Building for production. ?) TARGET := www else $(info Building for development. ?) BASEURL := --baseURL "https://stage.jaredwolff.com" TARGET := stage endif

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

PRODUCTION=1 make build

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

# Full path DEPLOY_DIR := /usr/local/bastille/jails/caddy/root/path/to/$(TARGET).jaredwolff.com

باستخدام المتغير TARGET أعلاه، أقوم بعد ذلك بتعريف المسار إلى أصول خادمي. أستخدم Bastille لتنظيم الـ jails الخاصة بي، لذلك المسار طويل جداً. هذا يسمح لنا باستخدام rsync لنشر الملفات بسهولة.

الآن تأتي الأجزاء الممتعة. للقيام بتغيير حجم الصور دفعة واحدة، أستخدم وظيفة wildcard في Makefile.

IMAGES := \ $(wildcard $(CONTENT_DIR)/*/images/*.jpg) \ $(wildcard $(CONTENT_DIR)/*/images/*.JPG) \ $(wildcard $(CONTENT_DIR)/*/images/*.jpeg) \ $(wildcard $(CONTENT_DIR)/*/images/*.png) \ $(wildcard $(CONTENT_DIR)/*/*/images/*.jpg) \ $(wildcard $(CONTENT_DIR)/*/*/images/*.jpeg) \ $(wildcard $(CONTENT_DIR)/*/*/images/*.png) \ $(wildcard $(CONTENT_DIR)/*/*/images/*.JPG) \

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

for f in *\ *; do mv "$f" "${f// /_}" ; done

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

OPTIMIZED_IMAGES := \ $(subst $(CONTENT_DIR)/, $(OPTIMIZED_DIR)/, $(IMAGES))

الآن، لنلقِ نظرة على “وصفة” optimize:

.PHONY : optimize optimize: build $(OPTIMIZED_IMAGES) @echo "✨ Optimizing images" rsync -r $(OPTIMIZED_DIR)/ $(DEST_DIR)/ du -sh $(CONTENT_DIR)/ du -sh $(DEST_DIR)/ $(OPTIMIZED_IMAGES) : convert -strip -compress JPEG -resize '730>' $(subst $(OPTIMIZED_DIR)/, $(CONTENT_DIR)/, $@) $@

تستدعي أولاً “وصفة” build ثم “وصفة” $(OPTIMIZED_IMAGES). الأخيرة ستقوم بتحسين الصورة باستخدام أمر convert من Imagemagick. في هذه الحالة، أقوم فقط بتغيير حجم الملفات التي يزيد عرضها عن 730 بكسل. قم بتعديل إعداداتك وفقاً لذلك لتحقيق أقصى استفادة من موقع محسّن.

بعد تغيير الحجم، تستخدم الوصفة rsync لنسخ الملفات من OPTIMIZED_DIR إلى DEST_DIR. إذا ألقينا نظرة على “وصفة” build، أقوم أولاً ببناء الأصول. ثم، أنسخ الصور من دليل content إلى دليل optimized. الشيء الجيد هو أن rsync سينقل فقط الملفات التي تغيرت. وبالتالي، لا يضطر إلى نسخ الملفات مراراً وتكراراً في كل مرة تقوم فيها بالبناء.

أخيراً، “وصفة” deploy:

.PHONY : deploy deploy: @echo rsync to $(DEPLOY_DIR) @rsync -r --del public/ $(USER)@$(SERVER):$(DEPLOY_DIR)/ @echo making restic snapshot @scp scripts/backup.sh $(USER)@$(SERVER):/root/backup.sh @ssh $(USER)@$(SERVER) sh /root/backup.sh $(DEPLOY_DIR) @echo "🚀 Site is deployed!"

يمكنك أن ترى مرة أخرى أنني أستخدم rsync لمزامنة محتويات public/ مع الخادم. تأكد من تعيين USER و SERVER و DEPLOY_DIR. في حالتي، يصبح DEPLOY_DIR هو /usr/local/bastille/jails/caddy/root/var/www/www.jaredwolff.com.

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

bastille service caddy caddy start

ستقوم “وصفة” deploy أيضاً بشيء مفيد إضافي هنا. ستقوم بنشر سكريبت النسخ الاحتياطي restic الخاص بي وتشغيله. سأتحدث عن هذا بمزيد من التفصيل في قسم النسخ الاحتياطي.

بشكل عام، إليك ملف Makefile كاملاً:

.POSIX: HUGO_VERSION := 0.66.0 OPTIMIZED_DIR := optimized CONTENT_DIR := content DEST_DIR := public SERVER := 155.138.230.8 USER := root # Set the place where it's deployed to. ifdef PRODUCTION $(info Building for production. ?) TARGET := www else $(info Building for development. ?) BASEURL := --baseURL "https://stage.jaredwolff.com" TARGET := stage endif # Full path DEPLOY_DIR := /usr/local/bastille/jails/caddy/root/var/www/$(TARGET).jaredwolff.com IMAGES := \ $(wildcard $(CONTENT_DIR)/*/images/*.jpg) \ $(wildcard $(CONTENT_DIR)/*/images/*.JPG) \ $(wildcard $(CONTENT_DIR)/*/images/*.jpeg) \ $(wildcard $(CONTENT_DIR)/*/images/*.png) \ $(wildcard $(CONTENT_DIR)/*/*/images/*.jpg) \ $(wildcard $(CONTENT_DIR)/*/*/images/*.jpeg) \ $(wildcard $(CONTENT_DIR)/*/*/images/*.png) \ $(wildcard $(CONTENT_DIR)/*/*/images/*.JPG) \ OPTIMIZED_IMAGES := \ $(subst $(CONTENT_DIR)/, $(OPTIMIZED_DIR)/, $(IMAGES)) .PHONY : all all: build optimize .PHONY : clean clean: rm -rf public/ rm -rf optimized/ .PHONY : serve serve: @hugo serve -D .PHONY : ssh ssh: @ssh $(USER)@$(SERVER) .PHONY : build build: @echo "✨ Generating site" hugo --gc --minify -d $(DEST_DIR) $(BASEURL) rsync -av --del -f "+ */" -f "- *" $(CONTENT_DIR)/ $(OPTIMIZED_DIR)/ .PHONY : optimize optimize: build $(OPTIMIZED_IMAGES) @echo "✨ Optimizing images" rsync -r $(OPTIMIZED_DIR)/ $(DEST_DIR)/ du -sh $(CONTENT_DIR)/ du -sh $(DEST_DIR)/ $(OPTIMIZED_IMAGES) : convert -strip -compress JPEG -resize '730>' $(subst $(OPTIMIZED_DIR)/, $(CONTENT_DIR)/, $@) $@ .PHONY : deploy deploy: @echo rsync to $(DEPLOY_DIR) @rsync -r --del public/ $(USER)@$(SERVER):$(DEPLOY_DIR)/ @echo making restic snapshot @scp scripts/backup.sh $(USER)@$(SERVER):/root/backup.sh @ssh $(USER)@$(SERVER) sh /root/backup.sh $(DEPLOY_DIR) @echo "🚀 Site is deployed!"

هناك بعض الأجزاء المفيدة الأخرى التي قد ترغب في استخدامها. كانت clean و serve و ssh مفيدة جداً عند الاختبار والاتصال. في النهاية، سيكون لديك عملية نشر من خطوتين. الأولى تولد موقعك بالصور المحسنة. والثانية تنشر إلى خادم للاستضافة الثابتة.

النسخ الاحتياطي التزايدي (Incremental Backup)

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

إعداد المستودع (Repo)

تهيئة المستودع بسيطة. الجزء الأكثر أهمية هو التأكد من عدم فقدان/نسيان كلمة المرور الخاصة بك!

# restic init -r /root/backups enter password for new repository: enter password again: created restic repository 32e14c7052 at /root/backups Please note that knowledge of your password is required to access the repository. Losing your password means that your data is irrecoverably lost.

عيّن متغير البيئة RESTIC_PASSWORD لتجنب إدخال كلمة المرور. لجعله دائماً، يجب عليك وضع export RESTIC_PASSWORD="Your password here!" داخل ملف .profile في /root/.

النسخ الاحتياطي

استدعاء restic عبر SSH أمر صعب. فما هو أفضل بديل؟ نقل سكريبت (shell script) (موجز جداً) إلى الخادم وتشغيله بعد النشر. إليك محتويات ما أستخدمه اليوم:

#!/bin/sh export RESTIC_PASSWORD="Your password here!" restic backup $1 -r /root/backups/

ملاحظة جانبية: بينما أنظر إلى هذا السكريبت، لأسباب أمنية، يمكنك استبدال "Your password here!" بـ $2 وهو الوسيط الثاني للسكريبت. بهذه الطريقة لا تحتاج إلى تضمين/دفع كلمة المرور المخزنة في ملف ثابت!

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

./backup.sh /path/to/your/public/folder/

ملاحظة: تحتاج إلى تهيئة نسخة restic الاحتياطية قبل البدء في النسخ الاحتياطي. وإلا فستواجه خطأ!

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

عرض النسخ الاحتياطية

لعرض النسخ الاحتياطية الخاصة بك، يمكنك تشغيل الأمر التالي:

restic snapshots -r /root/backups -g paths -c enter password for repository: repository e140b5e4 opened successfully, password is correct snapshots for (paths [/usr/local/bastille/jails/caddy/root/var/www/www.jaredwolff.com]): ID Time Host Tags d3328066 2020-03-10 00:30:58 vultr.guest f3360819 2020-03-10 04:03:03 vultr.guest 231dd134 2020-03-10 04:44:00 vultr.guest 3c1be26a 2020-03-10 04:56:19 vultr.guest e96c947c 2020-03-10 05:03:00 vultr.guest 34c3682a 2020-03-10 14:01:37 vultr.guest fbccdb8c 2020-03-10 14:04:26 vultr.guest 9ce11146 2020-03-10 15:38:49 vultr.guest 046b3da3 2020-03-10 15:47:06 vultr.guest 9c28d4bc 2020-03-10 15:48:25 vultr.guest 469dc228 2020-03-10 15:48:54 vultr.guest 6f78af72 2020-03-10 17:00:21 vultr.guest 29ad17b2 2020-03-10 20:18:23 vultr.guest ed22ce1f 2020-03-10 20:20:24 vultr.guest 9c8c1b03 2020-03-11 13:56:40 vultr.guest b6cfcfec 2020-03-11 14:08:14 vultr.guest e8546005 2020-03-11 14:27:22 vultr.guest 49a134fe 2020-03-17 00:47:58 vultr.guest c0beb283 2020-03-18 20:44:52 vultr.guest

يمكنك استخدام هذه القائمة لتحديد ما إذا كنت بحاجة إلى التراجع عن عملية نشر معينة.

الاستعادة

الاستعادة من نسخة احتياطية، خاصة في بيئة حية، يجب أن تكون سريعة. بعد عرض النسخ الاحتياطية الخاصة بك، يمكنك استعادة نسخة احتياطية محددة باستخدام معرفها (ID).

restic restore d3328066

سيؤدي هذا إلى استعادة الملفات إلى النسخة الاحتياطية التي تم إنشاؤها في 2020-03-10 00:30:58. رائع. بالإضافة إلى ذلك، لن يقوم بالكتابة فوق كل ملف. سيطبق فقط الاختلافات بين الحالة الحالية والحالة المخزنة.

الخلاصة

لقد غطينا الكثير من الأرض في هذا المقال. لقد تعلمت كيفية:

نشر خادمك الخاص باستخدام Vultr (أو Digital Ocean).
استخدام Bastille لإنشاء Jails شبيهة بالحاويات.
إعداد Caddy لتقديم أصول الملفات الثابتة مع TLS.
نشر الملفات باستخدام Makefile بسيط نسبياً و rsync.
النسخ الاحتياطي بعد كل نشر باستخدام restic.

في النهاية، لدينا منصة قوية وآمنة وبسيطة لاستضافة الملفات والخدمات الثابتة. ترقبوا المزيد من المقالات المشابهة قريباً! في غضون ذلك، تحققوا من مقالاتي الأخرى. شكراً للقراءة وإلى اللقاء في المرة القادمة! 👋

الخلاصة التقنية

يقدم هذا المقال نهجاً متكاملاً وفعالاً لاستضافة تطبيقات Hugo الثابتة ذاتياً، مع التركيز على الكفاءة والأمان. الانتقال من Docker إلى FreeBSD Jails المدعومة بـ Bastille يمثل خياراً تقنياً ذكياً يقلل من استهلاك الموارد ويزيد من الأمان بفضل العزل الفعال. استخدام Caddy كخادم ويب يعالج تلقائياً شهادات TLS، مما يبسط عملية تأمين الموقع بشكل كبير. كما أن دمج Makefile لأتمتة البناء والنشر، بما في ذلك تحسين الصور باستخدام Imagemagick و rsync، يضمن سير عمل متسقاً وموثوقاً. وأخيراً، يوفر Restic حلاً قوياً للنسخ الاحتياطي التزايدي، مما يعزز مرونة النظام وقدرته على التعافي من الكوارث. هذا المزيج من الأدوات والتقنيات يخلق بيئة استضافة ذاتية قوية ومستقرة، مثالية للمطورين الذين يسعون للتحكم الكامل والأداء الأمثل.