منصوبے کے بارے میں

یہ ریپوزٹری ایک self-hosted XWiki تعیناتی کو ایک واحد Docker Compose اسٹیک کے طور پر پیک کرتی ہے۔ XWiki، جو ایک انٹرپرائز ویکی پلیٹ فارم ہے، Traefik کے پیچھے چلتا ہے جو ریورس پراکسی کا کردار ادا کرتا ہے، اور کنفیگر شدہ ہوسٹ نیمز کے لیے Let's Encrypt سرٹیفکیٹس خودکار طور پر جاری کیے جاتے ہیں۔ PostgreSQL 15 ویکی ڈیٹا اسٹور کرتا ہے۔ سیٹ اپ ایک مختصر ترتیب پر چلتا ہے: ریپوزٹری کلون کریں، متوقع دو Docker نیٹ ورکس (traefik-network اور xwiki-network) بنائیں، .env.example کو .env پر کاپی کریں اور مطلوبہ ویلیوز (XWIKI_DB_PASSWORD، XWIKI_HOSTNAME، TRAEFIK_HOSTNAME، TRAEFIK_ACME_EMAIL، TRAEFIK_BASIC_AUTH) بھریں، پھر docker compose کے ذریعے اسٹیک اپ کریں۔ README بتاتا ہے کہ پہلا اسٹارٹ کئی منٹ لیتا ہے جبکہ XWiki اپنا اسکیما اور بنیادی صفحات initialize کرتا ہے، اور عام پہلی تعیناتی کے مسائل درج کرتا ہے جیسے سرٹیفکیٹ جاری ہونے میں ناکامی کیونکہ DNS propagate نہیں ہوا یا پورٹ 80 قابل رسائی نہیں، نیٹ ورک بنانے کا مرحلہ چھوڑنے سے نیٹ ورک ایررز، اور غائب متغیر کی ناکامیاں۔ ایک update.sh اسکرپٹ چیک آؤٹ کو تازہ ترین ریلیز ٹیگ پر منتقل کرتا ہے اور دوبارہ docker compose up چلاتا ہے۔ یہ بغیر نگرانی میجر ورژن عبور کرنے سے انکار کرتا ہے، لوکل تبدیلیوں کے اوپر چلنے سے انکار کرتا ہے، اور انسٹال شدہ ورژن کے بعد سے مطلوب ہونے والے کسی بھی متغیر کی رپورٹ کرتا ہے۔ ایک --dry-run فلیگ عمل کا پیش منظر دکھاتا ہے۔ تین Docker Hub آفیشل امیجز (traefik، xwiki، postgres) کو tag@sha256 digests پر interpolation defaults کے طور پر pin کیا گیا ہے، لہٰذا ایک سادہ git pull ٹیسٹ شدہ امتزاج فراہم کرتا ہے۔ فی امیج override لیولز دستاویز شدہ ہیں: ایک version variable صرف ٹیگ کو digest کے بغیر بدلتا ہے، جبکہ ایک tag variable پوری ریفرنس کو بدل دیتا ہے۔ Nested defaults کے لیے Docker Compose v2.5 یا نیا درکار ہے۔ ایک روزانہ CI جاب registries کے خلاف pins کو دوبارہ حل کرتی ہے اور pinned XWiki اور Traefik ورژنز کا upstream ریلیزز سے موازنہ کرتی ہے؛ GitHub Actions commit SHA کے ذریعے pinned ہیں اور Dependabot کے ذریعے تازہ رکھی جاتی ہیں۔ بیک اپس ایک مخصوص کنٹینر کے ذریعے سنبھالے جاتے ہیں جو gzip کے ذریعے pipe شدہ pg_dump کے علاوہ ویکی ڈیٹا کا tar.gz آرکائیو چلاتا ہے، پھر پرانے بیک اپس prune کرتا ہے اور سوتا ہے۔ ڈیفالٹس 30 منٹ کی warm-up، 24 گھنٹے کا وقفہ اور 7 دن کی retention ہیں۔ دو interactive restore اسکرپٹس ڈیٹا بیس اور ایپلیکیشن ڈیٹا کا احاطہ کرتی ہیں۔ ریپوزٹری backup volumes کو host-mount کرنے اور اپ گریڈ سے پہلے بیک اپ لینے کی صلاح دیتی ہے کیونکہ XWiki ورژن جمپس پر اپنا اسکیما migrate کرتا ہے۔ ہارڈننگ یکساں طور پر لاگو کی جاتی ہے: ہر سروس no-new-privileges سیٹ کرتی ہے، infrastructure کنٹینرز تمام capabilities drop کرتے ہیں اور صرف وہی واپس شامل کرتے ہیں جو ان کے entrypoints کو درکار ہوتا ہے (Traefik کے لیے NET_BIND_SERVICE، database امیجز کے لیے CHOWN/SETUID/SETGID)، جبکہ application کنٹینرز جان بوجھ کر default capability set رکھتے ہیں۔ ہر سروس memory اور CPU limits کے ساتھ reservations کو compose defaults کے طور پر رکھتی ہے، جنہیں .env variables کے ذریعے override کیا جا سکتا ہے۔ ایک Deployment Verification workflow ہر push، pull request اور روزانہ 06:00 UTC پر چلتی ہے، جو shellcheck، actionlint، تینوں pinned امیجز کے Trivy اسکینز، freshness چیک، اور ایک deploy-and-test جاب کا احاطہ کرتی ہے جو ephemeral credentials کے ساتھ اسٹیک بوٹ کرتی ہے اور تقاضا کرتی ہے کہ wiki UI Traefik کے ذریعے جواب دے۔ ایک end-to-end backup/restore اسکرپٹ ایک marker row داخل کرتی ہے، سب سے قدیم بیک اپ بحال کرتی ہے اور تصدیق کرتی ہے کہ marker غائب ہو گیا ہے؛ یہ failure detection ثابت کرنے کے لیے مختصراً database کنٹینر روکتی ہے اور production کے بجائے staging کے لیے ہے۔ سیکیورٹی نوٹس بتاتے ہیں کہ credentials deploy کے وقت gitignored .env سے پڑھے جاتے ہیں، PostgreSQL صرف internal network پر سنتا ہے، اور v1.0.0 سے پہلے کی ریلیزز ایک tracked .env کے ساتھ آئیں جن میں generated-looking database password تھا جسے دوبارہ استعمال کی صورت میں rotate کر دینا چاہیے۔