इस प्रोजेक्ट के बारे में

यह रिपॉजिटरी एक एकल Docker Compose स्टैक के रूप में एक स्व-होस्टेड XWiki तैनाती को पैकेज करती है। 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 अपनी स्कीमा और कोर पेज को initializes करता है, और सामान्य पहली-तैनाती समस्याओं की सूची दी गई है जैसे कि प्रमाणपत्र जारी करने में विफलता क्योंकि DNS ने प्रचार नहीं किया है या पोर्ट 80 पहुंच योग्य नहीं है, नेटवर्क-निर्माण चरण को छोड़ने से नेटवर्क त्रुटियां, और लापता-चर विफलताएं। एक update.sh स्क्रिप्ट चेकआउट को नवीनतम रिलीज़ टैग पर ले जाती है और docker compose up को फिर से चलाती है। यह बिना ध्यान दिए हुए प्रमुख संस्करण को पार करने से इनकार करती है, स्थानीय परिवर्तनों पर चलने से इनकार करती है, और किसी भी चर की रिपोर्ट करती है जो स्थापित संस्करण के बाद से आवश्यक हो गया है। एक --dry-run फ़्लैग क्रिया का पूर्वावलोकन करता है। तीन Docker Hub आधिकारिक इमेज (traefik, xwiki, postgres) को tag@sha256 डाइजेस्ट के रूप में इंटरपोलेशन डिफ़ॉल्ट के रूप में पिन किया गया है, इसलिए एक साधारण git pull परीक्षण किए गए संयोजन को वितरित करता है। प्रति-इमेज ओवरराइड स्तरों का दस्तावेजीकरण किया गया है: एक संस्करण चर केवल टैग को डाइजेस्ट के बिना स्वैप करता है, जबकि एक टैग चर पूरे संदर्भ को बदल देता है। नेस्टेड डिफ़ॉल्ट के लिए Docker Compose v2.5 या नया संस्करण आवश्यक है। एक दैनिक CI जॉब registries के खिलाफ पिन को फिर से हल करता है और पिन किए गए XWiki और Traefik संस्करणों की तुलना अपस्ट्रीम रिलीज़ से करता है; GitHub Actions को commit SHA द्वारा पिन किया गया है और Dependabot द्वारा ताजा रखा गया है। बैकअप्स को एक समर्पित कंटेनर द्वारा संभाला जाता है जो pg_dump को gzip के माध्यम से पाइप करता है और साथ ही विकी डेटा का एक tar.gz आर्काइव बनाता है, फिर पुराने बैकअप्स को काटता है और सो जाता है। डिफ़ॉल्ट हैं 30-मिनट का वार्म-अप, 24-घंटे का अंतराल और 7-दिन की प्रतिधारण। दो इंटरैक्टिव पुनर्स्थापना स्क्रिप्ट डेटाबेस और एप्लिकेशन डेटा को कवर करती हैं। रिपॉजिटरी सलाह देती है कि बैकअप वॉल्यूम को होस्ट-माउंट किया जाए और अपग्रेड से पहले बैकअप लिया जाए क्योंकि XWiki संस्करण जंप पर अपनी स्कीमा को माइग्रेट करता है। हार्डनिंग को एक समान रूप से लागू किया जाता है: हर सेवा no-new-privileges सेट करती है, इंफ्रास्ट्रक्चर कंटेनर सभी क्षमताओं को छोड़ देते हैं और केवल उन्हें जोड़ते हैं जिनकी उनकी एंट्रीपॉइंट्स को आवश्यकता होती है (Traefik के लिए NET_BIND_SERVICE, डेटाबेस इमेज के लिए CHOWN/SETUID/SETGID), जबकि एप्लिकेशन कंटेनर जानबूझकर डिफ़ॉल्ट क्षमता सेट को रखते हैं। प्रत्येक सेवा में मेमोरी और CPU सीमाएं प्लस आरक्षण होते हैं जो compose डिफ़ॉल्ट के रूप में होते हैं, जो .env चर के माध्यम से ओवरराइड किए जा सकते हैं। एक Deployment Verification वर्कफ़्लो हर पुश, पुल रिक्वेस्ट और दैनिक 06:00 UTC पर चलता है, जिसमें shellcheck, actionlint, तीन पिन किए गए इमेज के Trivy स्कैन, ताजगी चेक, और एक deploy-and-test जॉब शामिल है जो अस्थायी क्रेडेंशियल्स के साथ स्टैक को बूट करता है और Traefik के माध्यम से विकी UI से जवाब की आवश्यकता होती है। एक एंड-टू-एंड बैकअप/पुनर्स्थापना स्क्रिप्ट एक मार्कर पंक्ति को सम्मिलित करती है, सबसे पुराना बैकअप को पुनर्स्थापित करती है और दावा करती है कि मार्कर चला गया है; यह विफलता का पता लगाने के लिए डेटाबेस कंटेनर को अस्थायी रूप से रोकता है और इसका उद्देश्य स्टेजिंग के लिए है, उत्पादन के लिए नहीं। सुरक्षा नोट्स बताते हैं कि क्रेडेंशियल्स को gitignored .env से तैनाती के समय पढ़ा जाता है, कि PostgreSQL केवल आंतरिक नेटवर्क पर सुनता है, और कि v1.0.0 से पहले के रिलीज़ में एक ट्रैक किया गया .env था जिसमें एक जेनरेटेड-looking डेटाबेस पासवर्ड था जिसे अगर फिर से उपयोग किया जाए तो उसे घुमा दिया जाना चाहिए।