الخدمات

تغطي هذه الصفحة نشر وإدارة الخدمات المحتوية، بما في ذلك ملفات Rediaccfile وشبكات الخدمات والتشغيل/الإيقاف والعمليات المجمّعة والتشغيل التلقائي.

ملف Rediaccfile

Rediaccfile هو سكريبت Bash يحدد كيف يتم تشغيل الخدمات وإيقافها. يتم استدعاؤه (وليس تنفيذه كعملية منفصلة)، لذا تشاركه الدوال نفس السياق الحد وتملك الوصول إلى جميع متغيرات البيئة المُصدّرة. يجب أن يكون اسمه Rediaccfile أو rediaccfile (غير حساس لحالة الأحرف) ويوضع داخل نظام ملفات المستودع المحمّل.

يتم اكتشاف ملفات Rediaccfile في موقعين:

جذر مسار تحميل المستودع
المجلدات الفرعية من المستوى الأول لمسار التحميل (غير تكراري)

يتم تخطي المجلدات المخفية (الأسماء التي تبدأ بـ .).

دوال دورة الحياة

يحتوي Rediaccfile على دالتين كحد أقصى:

الدالة	وقت التشغيل	الغرض	سلوك الخطأ
`up()`	عند التشغيل	بدء الخدمات (مثل `renet compose -- up -d`)	فشل الجذر حرج (يوقف كل شيء). فشل المجلدات الفرعية غير حرج (يُسجّل ويستمر)
`down()`	عند الإيقاف	إيقاف الخدمات (مثل `renet compose -- down`)	أفضل جهد — الأخطاء تُسجّل لكن تُنفّذ جميع ملفات Rediaccfile دائماً

كلتا الدالتين اختيارية. إذا لم تُعرّف دالة، يتم تخطيها بصمت.

ترتيب التنفيذ

التشغيل (up): Rediaccfile الجذر أولاً، ثم المجلدات الفرعية بـترتيب أبجدي (A إلى Z).
الإيقاف (down): المجلدات الفرعية بـترتيب أبجدي عكسي (Z إلى A)، ثم الجذر أخيراً.

متغيرات البيئة

عند تنفيذ دالة Rediaccfile، تكون متغيرات البيئة التالية متاحة:

المتغير	الوصف	مثال
`REDIACC_WORKING_DIR`	مسار تحميل المستودع	`/mnt/rediacc/mounts/abc123`
`REDIACC_REPOSITORY`	معرّف GUID للمستودع	`a1b2c3d4-e5f6-...`
`REDIACC_NETWORK_ID`	معرّف الشبكة (عدد صحيح)	`2816`
`DOCKER_HOST`	مقبس Docker للعملية المعزولة لهذا المستودع	`unix:///var/run/rediacc/docker-2816.sock`
`{SERVICE}_IP`	عنوان IP الحلقي لكل خدمة معرّفة في `.rediacc.json`	`POSTGRES_IP=127.0.11.2`

يتم إنشاء متغيرات {SERVICE}_IP} تلقائياً من خلال تعيينات الفتحات في .rediacc.json وتُصدّر قبل تنفيذ دوال Rediaccfile. تحوّل قاعدة التسمية اسم الخدمة إلى أحرف كبيرة مع استبدال الشرطات بشرطات سفلية، ثم تضيف _IP. على سبيل المثال، الخدمة باسم listmonk-app مع فتحة 0 تصبح LISTMONK_APP_IP=127.0.11.2.

تحذير: لا تستخدم sudo docker في ملفات Rediaccfile. أمر sudo يعيد تعيين متغيرات البيئة، مما يعني فقدان DOCKER_HOST واستهداف أوامر Docker لعملية النظام بدلاً من العملية المعزولة للمستودع. هذا يكسر عزل الحاويات وقد يسبب تعارضات في المنافذ. سيمنع Rediacc التنفيذ إذا اكتشف sudo docker بدون -E.

استخدم renet compose في ملفات Rediaccfile، فهو يتعامل تلقائياً مع DOCKER_HOST ويحقن تسميات الشبكة لاكتشاف المسارات ويهيئ شبكات الخدمات. راجع الشبكات لتفاصيل كيفية كشف الخدمات عبر الوكيل العكسي. إذا استدعيت Docker مباشرة، استخدم docker بدون sudo، دوال Rediaccfile تعمل بالفعل بصلاحيات كافية. إذا كان يجب عليك استخدام sudo، استخدم sudo -E docker للحفاظ على متغيرات البيئة.

renet هي أداة منخفضة المستوى بعيدة. لسير العمل الطبيعي للمستخدم من محطة العمل، فضّل أوامر rdc مثل rdc repo up و rdc repo down. راجع rdc vs renet.

مثال

#!/bin/bash

up() {
    echo "Starting services..."
    renet compose -- up -d
}

down() {
    echo "Stopping services..."
    renet compose -- down
}

مهم: استخدم دائماً renet compose -- بدلاً من docker compose. غلاف renet compose يفرض شبكة المضيف وتخصيص عناوين IP وتسميات اكتشاف الخدمات المطلوبة بواسطة renet-proxy. تُضاف قدرات CRIU checkpoint/restore للحاويات التي تحمل تسمية rediacc.checkpoint=true. يتم رفض الاستخدام المباشر لـ docker compose بواسطة التحقق من صحة Rediaccfile. راجع الشبكات للتفاصيل.

تسميات الصلاحيات

تعمل الحاويات بحد أدنى من صلاحيات Linux افتراضياً. تنضم الخدمة إلى صلاحيات إضافية بإضافة تسمية في docker-compose.yml الخاص بها:

التسمية	تمنح	تُستخدم لـ
`rediacc.checkpoint=true`	`CHECKPOINT_RESTORE`، `SYS_PTRACE`، `NET_ADMIN`	نقطة تفتيش/استعادة CRIU (الترحيل المباشر، الحفظ والاستئناف)
`rediacc.wireguard=true`	`NET_ADMIN` بالإضافة إلى جهاز `/dev/net/tun`	تشغيل عميل WireGuard داخل الحاوية

services:
  vpn:
    image: alpine
    labels:
      - "rediacc.wireguard=true"

تتيح rediacc.wireguard للخدمة إنشاء نفق WireGuard، لتوجيه عملية واحدة مثلاً عبر نقطة نهاية بعيدة. بما أن كل خدمة تعمل بشبكة المضيف، احصر النفق في نطاق شبكة داخل الحاوية حتى لا يُغير توجيه المضيف. خيارات الامتياز الواسعة كـ privileged: true وpid: host وipc: host تبقى مرفوضة بالتحقق بصرف النظر عن التسميات.

تخطيط متعدد الخدمات

للمشاريع ذات مجموعات خدمات مستقلة متعددة، استخدم المجلدات الفرعية:

/mnt/rediacc/repos/my-app/
├── Rediaccfile              # Root: shared setup
├── docker-compose.yml
├── database/
│   ├── Rediaccfile          # Database services
│   └── docker-compose.yml
├── backend/
│   ├── Rediaccfile          # API server
│   └── docker-compose.yml
└── monitoring/
    ├── Rediaccfile          # Prometheus, Grafana, etc.
    └── docker-compose.yml

ترتيب التنفيذ لـ up: الجذر، ثم backend، database، monitoring (A-Z). ترتيب التنفيذ لـ down: monitoring، database، backend، ثم الجذر (Z-A).

شبكات الخدمات (.rediacc.json)

يحصل كل مستودع على شبكة فرعية /26 (64 عنوان IP) في نطاق 127.x.x.x الحلقي. ترتبط الخدمات بعناوين IP حلقية فريدة بحيث يمكنها العمل على نفس المنافذ دون تعارض.

ملف .rediacc.json

يربط أسماء الخدمات بأرقام الفتحات (slots). تتوافق كل فتحة مع عنوان IP فريد ضمن الشبكة الفرعية للمستودع.

{
  "services": {
    "api": {"slot": 0},
    "postgres": {"slot": 1},
    "redis": {"slot": 2}
  }
}

الإنشاء التلقائي من Docker Compose

لا تحتاج إلى إنشاء .rediacc.json يدوياً. عند تشغيل rdc repo up، يقوم Rediacc تلقائياً بما يلي:

فحص جميع المجلدات التي تحتوي على Rediaccfile بحثاً عن ملفات compose (docker-compose.yml أو docker-compose.yaml أو compose.yml أو compose.yaml)
استخراج أسماء الخدمات من قسم services:
تعيين الفتحة التالية المتاحة للخدمات الجديدة
حفظ النتيجة في {repository}/.rediacc.json

حساب عنوان IP

يُحسب عنوان IP للخدمة من معرّف شبكة المستودع وفتحة الخدمة. يتم توزيع معرّف الشبكة على الثُمانية الثانية والثالثة والرابعة من عنوان الاسترجاع 127.x.y.z. تحصل الخدمات على إزاحة تبدأ من 2:

Offset	Address	Purpose
.0	`127.0.11.0`	Network address (reserved)
.1	`127.0.11.1`	Gateway (reserved)
.2–.62	`127.0.11.2` – `127.0.11.62`	Services (`slot + 2`)
.63	`127.0.11.63`	Broadcast (reserved)

مثال لمعرّف الشبكة 2816 (0x0B00)، العنوان الأساسي 127.0.11.0:

الخدمة	الفتحة	عنوان IP
api	0	`127.0.11.2`
postgres	1	`127.0.11.3`
redis	2	`127.0.11.4`

يدعم كل مستودع ما يصل إلى 61 خدمة (الفتحات من 0 إلى 60).

استخدام عناوين IP للخدمات في Docker Compose

بما أن كل مستودع يشغّل عملية Docker معزولة، يقوم renet compose تلقائياً بتهيئة network_mode: host لجميع الخدمات. يعيد النواة تلقائياً توجيه استدعاءات bind() إلى عنوان IP الحلقي المخصص للخدمة، لذا يمكن للخدمات الارتباط بـ 0.0.0.0 أو localhost دون تعارض. للاتصال بالخدمات الأخرى، استخدم اسم الخدمة. يحقن renet كل اسم خدمة كاسم مضيف يُحلَّل دائماً إلى عنوان IP الصحيح، حتى في الفروع:

services:
  postgres:
    image: postgres:16
    environment:
      PGDATA: /var/lib/postgresql/data
      POSTGRES_PASSWORD: secret
    # لا حاجة لـ listen_addresses صريح - تعيد النواة توجيه bind إلى عنوان IP الحلقي الصحيح

  api:
    image: my-api:latest
    environment:
      DATABASE_URL: postgresql://postgres:secret@postgres:5432/mydb  # استخدام اسم الخدمة
      LISTEN_ADDR: 0.0.0.0:8080                                      # تعيد النواة توجيهه إلى IP الخدمة

أسماء الخدمات للاتصالات: استخدم اسم الخدمة (مثل postgres، redis) للاتصال بالخدمات الأخرى. يقوم renet تلقائياً بتعيين كل اسم خدمة إلى عنوان IP الحلقي الخاص به عبر /etc/hosts. تضمين ${POSTGRES_IP} في سلاسل الاتصال المخزنة في قواعد البيانات أو ملفات الإعداد سيثبت عنوان IP الخام، مما يكسر عزل الفروع وهو خطأ تحقق. متغيرات ${SERVICE_IP} لا تزال متاحة للاستخدام الصريح، لكن الارتباط يتم تلقائياً بواسطة النواة.

ملاحظة: لا تضف network_mode: host يدوياً، يقوم renet compose بحقنه تلقائياً. سياسات إعادة التشغيل (مثل restart: always) آمنة للاستخدام، يزيلها renet تلقائياً لتوافق CRIU ويتولى watchdog استعادة الحاويات.

استعادة الحاويات وسياسة إعادة التشغيل

يختلف renet و Docker عن قصد في كيفية التعامل مع إعادة تشغيل الحاويات. فهم هذا التقسيم مهم عند تشخيص سبب عودة حاوية إلى العمل أو عدمها.

ترجمة سياسة إعادة التشغيل. عند كتابة restart: always (أو unless-stopped أو on-failure) في ملف compose، يقوم renet بحذفها عند تجميع نشر compose الفعلي ويستبدلها بـ restart: no. يتم حفظ القيمة الأصلية في .rediacc.json الخاص بالمستودع تحت services.<name>.restart_policy. هذا يمنع إعادة التشغيل التلقائية على مستوى Docker daemon من التدخل في عملية CRIU checkpoint/restore (فإعادة تشغيل يقودها daemon ستستأنف من حالة قديمة ما قبل نقطة التفتيش).

تطبيق الـ watchdog. يعمل watchdog الموجّه دورياً على كل جهاز. في كل دورة:

يقرأ .rediacc.json لكل مستودع ويجد الخدمات ذات restart_policy قابلة للاسترداد.
يسرد جميع الحاويات لـ daemon ذلك المستودع، ويحدد الموقوفة منها، ويعيد تشغيلها وفقاً للسياسة المحفوظة. فترة سماح مدتها 30 ثانية تمنع التعارض مع مشغّل نفّذ docker stop للتو.
تعالج نفس الحلقة أيضاً /var/run/rediacc/cold-backup-<guid>.running.json (راجع دلالات النسخ الاحتياطية الباردة). تُعاد تشغيل الحاويات المدرجة بغض النظر عن السياسة المحفوظة، لأن الـ sidecar يعني “أوقف renet هذه الحاويات عن قصد وعليه إعادة تشغيلها للمشغّل.”

لماذا قد تبدو on-failure معطوبة. سياسة Docker on-failure تُعيد التشغيل فقط عند خروج الحاوية بكود غير صفري. الإيقاف الطبيعي (الخروج 0) من docker stop أو إيقاف daemon ليس “فشلاً” ولا يُشغّل إعادة تشغيل، لا بالمنطق الأصلي لـ Docker ولا بمسار السياسة المحفوظة لـ watchdog. sidecar النسخ الاحتياطية الباردة هو شبكة الأمان: أي حاوية أوقفناها عن قصد تُعاد تشغيلها بغض النظر عن سياستها.

كيفية تفسير حالة وقت التشغيل:

docker inspect <container> ← RestartPolicy.Name: ستكون دائماً no للحاويات المُدارة بـ renet. لا تعتمد على هذا للسياسة الدلالية.
.rediacc.json في جذر تحميل المستودع ← services.<name>.restart_policy: النية الحقيقية.
docker ps --format '{{.Status}}': حالة وقت التشغيل.

كيفية إصلاح الانحراف. إذا كانت السياسة المحفوظة في .rediacc.json للحاوية غير صحيحة (مثلاً لأنك عدّلت compose لكن لم تُعد إنشاء الحاوية)، أعد تشغيل rdc repo up --name <repo> -m <machine>. ستُعاد إنشاء الحاوية مع تسجيل السياسة المحدّثة.

تجريبي: وصل استرداد sidecar النسخ الاحتياطية الباردة وعلامة --sync-certs في rdc machine query في renet 0.9+. الإصدارات الأقدم تعتمد كلياً على restart_policy المحفوظة لاسترداد watchdog، مما قد يترك حاويات on-failure عالقة بعد نسخة احتياطية باردة.

شبكات Docker bridge معطّلة لعمليات daemon الخاصة بكل مستودع. يتم تكوين كل daemon خاص بمستودع (FlavorRediacc) بالقيم "bridge": "none" و "iptables": false. سيظل أمر docker run <image> البسيط داخل شل المستودع يبدأ، لكن الحاوية ستحصل فقط على واجهة loopback وبدون DNS أو اتصال خارجي. هذا بالتصميم، لأن عزل الـ loopback بين المستودعات تفرضه خطاطيف cgroup الخاصة بـ eBPF، وهي خطاطيف تتجاوزها الحاويات التي تعمل عبر bridge. يجب أن تستخدم خدمات الإنتاج renet compose (الذي يحقن شبكة المضيف تلقائياً)؛ وللتصحيح العابر، مرّر --network host بشكل صريح: docker run --rm --network host -it ubuntu bash.

عمليات Hub daemon الخاصة بكل مستخدم (FlavorHub، المستخدمة في بيئات التطوير) هي الاستثناء: فهي تضبط bridge="docker0" و iptables=true و live-restore=true لكي تحصل الحاويات التي يشغّلها المستخدم على شبكة bridge عادية واتصال خارجي.

ملاحظة: مستودعات fork تحصل على مسارات تلقائية تحت نطاق فرعي الأصل: {service}-fork-{tag}.{repo}.{machine}.{baseDomain}. يتم تخطي النطاقات المخصصة لمستودعات fork.

تشغيل الخدمات

حمّل المستودع وشغّل جميع الخدمات:

rdc repo up --name my-app -m server-1

مرجع CLI: rdc repo up

الخيار	الوصف
`--detach`	العودة فور انطلاق الحاويات؛ تستمر فحوصات الجاهزية في الخلفية
`--skip-router-restart`	تخطي إعادة تشغيل خادم المسارات بعد العملية

تسلسل التنفيذ هو:

تحميل المستودع المشفر بـ LUKS (تحميل تلقائي إذا لم يكن محمّلاً)
بدء عملية Docker المعزولة
إنشاء .rediacc.json تلقائياً من ملفات compose
تشغيل up() في جميع ملفات Rediaccfile (بترتيب A-Z)

بعد النشر، يُظهر الإخراج قسم PROXY ROUTES مع عناوين URL الفعلية لكل خدمة. الخدمات ذات تسميات Traefik المخصصة (مثل traefik.http.routers.myapp.rule=Host(...)) تُظهر نطاقاتها المخصصة كعناوين URL رئيسية:

HTTP services (accessible via proxy after ~3s):
  gitlab-server:
    HTTPS: https://gitlab.example.com  (custom)
    Auto:  https://gitlab-server.gitlab.server-1.example.com
    IP:    127.0.11.130

الخدمات بدون تسميات Traefik المخصصة تُظهر فقط المسار المُنتج تلقائياً. استخدم هذه العناوين (وليس النمط العام المطبوع بواسطة CLI) لولوج المتصفح وندءات API والإعدادات بين الخدمات.

التشغيل المنفصل

مع --detach، يعود الأمر فور انطلاق الحاويات دون انتظار اكتمال فحوصات الجاهزية. يُنهي التشغيل عمله في الخلفية: يواصل الوكيل إعادة المحاولة حتى ترتبط كل خدمة بمنفذها، فتستعيد المسارات عملها تلقائياً. تابع التقدم بـ rdc machine query --containers --name <machine>. مثالي للنسخ المؤقتة والحلقات البرمجية التي لا تحتاج إلى جاهزية الخدمات قبل الخطوة التالية.

اختبار الجاهزية

بعد up()، يفحص renet كل خدمة HTTP ويتحقق من قبولها اتصالات TCP قبل إعلانها جاهزة، حتى لا يصطدم أول طلب من المتصفح بخطأ 502 من الوكيل. تُعامَل الحاويات التي تُعرّف فحص صحة Docker معاملةً مميزة: الحاوية السليمة تتجاوز الفحص مباشرةً، وتلك التي لا تزال ضمن start_period تُسجَّل كملاحظة إعلامية لا تحذيراً. يتخلى renet عن الانتظار بعد 15 ثانية (عدّلها بمتغير البيئة REDIACC_READINESS_TIMEOUT، بالثواني، على الجهاز)؛ ويتجاوز التشغيل المنفصل هذا الفحص كلياً.

إيقاف الخدمات

rdc repo down --name my-app -m server-1

مرجع CLI: rdc repo down

الخيار	الوصف
`--unmount`	إلغاء تحميل المستودع المشفر بعد إيقاف الخدمات. إذا لم يسرِ مفعوله، استخدم `rdc repo unmount` بشكل منفصل.
`--skip-router-restart`	تخطي إعادة تشغيل خادم المسارات بعد العملية

تسلسل التنفيذ هو:

تشغيل down() في جميع ملفات Rediaccfile (بترتيب Z-A عكسي، أفضل جهد)
إيقاف عملية Docker المعزولة (إذا تم تحديد --unmount)
إلغاء تحميل وإغلاق وحدة LUKS المشفرة (إذا تم تحديد --unmount)

العمليات المجمّعة

شغّل أو أوقف جميع المستودعات على جهاز دفعة واحدة:

rdc repo up -m server-1

مرجع CLI: rdc repo up

الخيار	الوصف
`--include-forks`	تضمين المستودعات المنسوخة
`--mount-only`	التحميل فقط، بدون تشغيل الحاويات
`--dry-run`	عرض ما سيتم تنفيذه
`--parallel`	تشغيل العمليات بالتوازي
`--concurrency <n>`	الحد الأقصى للعمليات المتزامنة (الافتراضي: 3)
`--skip-router-restart`	تخطي إعادة تشغيل خادم المسارات بعد العملية

التشغيل التلقائي عند الإقلاع

افتراضياً، يجب تحميل المستودعات وتشغيلها يدوياً بعد إعادة تشغيل الخادم. يقوم التشغيل التلقائي بتهيئة المستودعات للتحميل تلقائياً وبدء Docker وتنفيذ up() في Rediaccfile عند إقلاع الخادم.

كيف يعمل

عند تفعيل التشغيل التلقائي لمستودع:

يتم إنشاء ملف مفتاح LUKS عشوائي بحجم 256 بايت وإضافته إلى فتحة LUKS رقم 1 للمستودع (تبقى الفتحة 0 لعبارة مرور المستخدم)
يُخزّن ملف المفتاح في {datastore}/.credentials/keys/{guid}.key بصلاحيات 0600 (الجذر فقط)
يتم تثبيت خدمة systemd (rediacc-autostart) تعمل عند الإقلاع لتحميل جميع المستودعات المفعّلة وتشغيل خدماتها

عند إيقاف النظام، تقوم الخدمة بإيقاف جميع الخدمات بسلاسة (Rediaccfile down()) وإيقاف عمليات Docker وإغلاق وحدات LUKS.

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

تفعيل

rdc repo autostart enable --name my-app -m server-1

مرجع CLI: rdc repo autostart enable

سيُطلب منك إدخال عبارة مرور المستودع.

تفعيل الكل

rdc repo autostart enable -m server-1

مرجع CLI: rdc repo autostart enable

تعطيل

rdc repo autostart disable --name my-app -m server-1

مرجع CLI: rdc repo autostart disable

يزيل هذا ملف المفتاح ويحذف فتحة LUKS رقم 1.

تحديث ملف المفتاح عند النشر

عند تفعيل التشغيل التلقائي، يتحقق rdc repo up من ملف مفتاح LUKS في الفتحة رقم 1. إذا كان ملف المفتاح على القرص لا يزال مطابقاً لفتحة LUKS، لا يتم إجراء أي تغييرات.

بعد نقل مستودع بين الأجهزة عبر repo push / repo pull، ملف المفتاح على الجهاز الجديد لن يتطابق. في هذه الحالة، يُعيد repo up تلقائياً إنشاء ملف المفتاح وتحديث فتحة LUKS رقم 1. ستظهر رسائل السجل:

Refreshing keyfile credential for <guid>
Killing LUKS slot 1: /mnt/rediacc/repositories/<guid>
Adding keyfile to LUKS slot 1: /mnt/rediacc/repositories/<guid>

هذا آمن، الفتحة 0 (عبارة مرورك) لا تُعدَّل أبداً. إذا لم يكن التشغيل التلقائي مفعّلاً، يتم تخطي الفحص بصمت. الأخطاء غير حرجة ولا تعيق النشر.

عرض الحالة

rdc repo autostart list -m server-1

مرجع CLI: rdc repo autostart list

لتفاصيل حول كيفية استرداد المُوفِّق الدوري للمستودعات التي تتوقف بعد الإقلاع، راجع التشغيل التلقائي والاسترداد.

مثال كامل

ينشر هذا تطبيق ويب مع PostgreSQL و Redis وخادم API.

1. الإعداد

curl -fsSL https://www.rediacc.com/install.sh | bash
rdc config init --name production --ssh-key ~/.ssh/id_ed25519
rdc config machine add --name prod-1 --ip 203.0.113.50 --user deploy
rdc config machine setup --name prod-1
rdc repo create --name webapp -m prod-1 --size 10G

مرجع CLI: rdc config init · rdc config machine add · rdc config machine setup · rdc repo create

2. التحميل والتحضير

rdc repo mount --name webapp -m prod-1

مرجع CLI: rdc repo mount

3. إنشاء ملفات التطبيق

داخل المستودع، أنشئ الملفات التالية:

docker-compose.yml:

services:
  postgres:
    image: postgres:16
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: webapp
      POSTGRES_USER: app
      POSTGRES_PASSWORD: changeme

  redis:
    image: redis:7-alpine

  api:
    image: myregistry/api:latest
    environment:
      DATABASE_URL: postgresql://app:changeme@postgres:5432/webapp
      REDIS_URL: redis://redis:6379
      LISTEN_ADDR: 0.0.0.0:8080

Rediaccfile:

#!/bin/bash

up() {
    mkdir -p data/postgres
    renet compose -- up -d

    echo "Waiting for PostgreSQL..."
    for i in $(seq 1 30); do
        if renet compose -- exec postgres pg_isready -q 2>/dev/null; then
            echo "PostgreSQL is ready."
            return 0
        fi
        sleep 1
    done
    echo "Warning: PostgreSQL did not become ready within 30 seconds."
}

down() {
    renet compose -- down
}

4. التشغيل

rdc repo up --name webapp -m prod-1

مرجع CLI: rdc repo up

5. تفعيل التشغيل التلقائي

rdc repo autostart enable --name webapp -m prod-1

مرجع CLI: rdc repo autostart enable

استخدام أسرار المستودع في compose

العنصر النائب POSTGRES_PASSWORD: changeme أعلاه بخير للبرنامج التعليمي، لكن التطبيقات الحقيقية تحتاج بيانات اعتماد حقيقية، والتزام تخزينها في ملف compose (أو ملف .env داخل المستودع) يعني أن fork يرثها أيضاً. للبيانات الاعتمادية على النشر، استخدم rdc repo secret. تعيش القيم خارج صورة المستودع المشفرة، لذا تبدأ forks بخريطة أسرار فارغة.

يعمل نمطا تسليم في compose:

نمط env. قم بالاستيفاء عبر ${REDIACC_SECRET_<KEY>} في أي قيمة environment:. يمرر غلاف renet القيمة إلى بيئة الحاوية عند النشر.

نمط file. تنزل القيمة إلى ملف tmpfs على جانب المضيف في /var/run/rediacc/secrets/<networkID>/<KEY>، وتحمّله في الحاوية عبر كتلة secrets: القياسية لـ Docker compose. تقرأ الحاوية /run/secrets/<key>. فضّل هذا النمط لأي شيء حساس. القيم لا تظهر أبداً في docker inspect أو /proc/<pid>/environ.

services:
  api:
    image: myregistry/api:latest
    environment:
      DATABASE_URL: ${REDIACC_SECRET_DATABASE_URL}
    secrets:
      - stripe_live_key

secrets:
  stripe_live_key:
    file: /var/run/rediacc/secrets/${REDIACC_NETWORK_ID}/STRIPE_LIVE_KEY

ازرع القيم باستخدام rdc repo secret set --name <repo> --key DATABASE_URL --value <val> --mode env --current "" والمعادل لنمط الملف. راجع المستودعات § الأسرار للحصول على طريقة شاملة و أسرار المستودع في ورقة الغش للحصول على مرجع الأمر.

يتم رفض مسارات متعددة المستودعات في وقت التحقق. تصريح compose secrets: file: (أو configs: file: أو env_file:) يشير إلى دليل /var/run/rediacc/secrets/<other-networkID>/ لمستودع آخر يتم رفضه بشدة بواسطة غلاف renet قبل تشغيل docker compose. --unsafe لا تعكس. دفاع متعدد الطبقات: sandbox الـ Landlock حول شل Rediaccfile ينطاق القراءات إلى دليل الأسرار لشبكة حالية، لذا cat /var/run/rediacc/secrets/<other>/X من bash Rediaccfile يفشل مع EACCES حتى إذا تجاوز مدقق YAML. لا تحتاج إلى الانضمام؛ هذا بالفعل مفعّل بشكل افتراضي لكل repo up.