संग्रहीत दस्तावेज़. अपने इंस्टॉलेशन से मेल खाने वाले संस्करण का उपयोग करें.

Repovio की तैनाती

Repovio के लिए उत्पादन परिनियोजन, टीएलएस प्रॉक्सी, बैकअप, पुनर्स्थापना, अपग्रेड और रोलबैक मार्गदर्शन।

संग्रहीत स्रोत स्नैपशॉट। उत्पाद लेबल को Repovio पर सामान्यीकृत कर दिया गया है। इस ऐतिहासिक रिलीज़ के लिए, इसकी टैग की गई परिनियोजन फ़ाइलों से कॉन्फ़िगरेशन पहचानकर्ताओं और कंटेनर संदर्भों का अपरिवर्तित उपयोग करें।

Repovio का कंपोज़ स्टैक PostgreSQL शुरू करता है, एक बार प्रिज्मा माइग्रेशन लागू करता है, और फिर एपीआई और वेब एप्लिकेशन शुरू करता है। यह टीएलएस को समाप्त नहीं करता है. वेब और एपीआई सेवाओं को एक रिवर्स प्रॉक्सी के पीछे रखें जो सार्वजनिक होस्टनाम और प्रमाणपत्रों का स्वामी हो।

पूर्वावश्यकताएँ

डॉकर कंपोज़ v2 के साथ डॉकर इंजन।
सार्वजनिक होस्टनाम के लिए एक DNS रिकॉर्ड।
एक रिवर्स प्रॉक्सी जो टीएलएस प्रमाणपत्र प्राप्त और नवीनीकृत करती है।
एक निजी सर्वर निर्देशिका जो केवल परिनियोजन प्रशासकों द्वारा पढ़ी जा सकती है।

कंपोज़ स्टैक PostgreSQL डेटा को बनाए रखता है, जिसमें सामान्यीकृत उपयोगकर्ता प्रोफ़ाइल चित्र भी शामिल हैं, इसके नामित PostgreSQL वॉल्यूम को टैग की गई कंपोज़ फ़ाइल में कॉन्फ़िगर किया गया है। इस वॉल्यूम को तब तक न हटाएं जब तक आप जानबूझकर सभी Repovio डेटा को हटाना नहीं चाहते।

पहली तैनाती

चरण 1: जारी किए गए Repovio संस्करण को देखें और निजी वातावरण फ़ाइल बनाएं:

cp .env.example .env
chmod 600 .env

चरण 2: `.env` में प्रत्येक प्लेसहोल्डर को बदलें, विशेष रूप से `POSTGRES_PASSWORD`, दोनों डेटाबेस URL, `AUTH_JWT_SECRET`, और

TOKEN_ENCRYPTION_KEY. इसके साथ एन्क्रिप्शन कुंजी उत्पन्न करें:

openssl rand -base64 32

चरण 3: बाहरी रूप से दृश्यमान यूआरएल सेट करें। `https://repovio.example.com` पर परिनियोजन के लिए, उपयोग करें:

PUBLIC_URL=https://repovio.example.com
OIDC_CALLBACK_URL=https://repovio.example.com/api/v1/auth/oidc/callback
CORS_ORIGIN=https://repovio.example.com
NUXT_PUBLIC_API_BASE_URL=https://repovio.example.com/api/v1
OAUTH_CALLBACK_URL=https://repovio.example.com/api/v1/provider-accounts/oauth/callback

चरण 4: जब रिवर्स प्रॉक्सी एक ही होस्ट पर चलती है तो कंटेनर पोर्ट को लूपबैक से बांधें:

रिलीज़ के .env.example में क्रमशः 127.0.0.1:3001 और 127.0.0.1:3000 मानों के साथ एपीआई और वेब पोर्ट वेरिएबल का उपयोग करें। ऐतिहासिक चर नाम वर्तमान Repovio रिलीज़ से भिन्न हैं।

अन्यथा, होस्ट फ़ायरवॉल के साथ पोर्ट 3000 और 3001 तक पहुंच प्रतिबंधित करें। PostgreSQL कंटेनर को कभी भी उजागर न करें।

चरण 5: `.env` में टैग किए गए `.env.example` से रिलीज़-चयन चर को सटीक रिलीज़ छवि जोड़ी पर सेट करें, फिर स्टैक शुरू करें:

docker compose pull
docker compose up --detach --wait

उस मान को .env में रखें ताकि प्रत्येक बाद वाला कंपोज़ कमांड उसी एपीआई और वेब संस्करण का उपयोग करे।

चरण 6: स्थानीय स्तर पर एपीआई स्वास्थ्य समापन बिंदु की पुष्टि करें:

curl --fail http://127.0.0.1:3001/api/health

चरण 7: सार्वजनिक Repovio URL खोलें और पहला बनाने के लिए एक बार का प्रथम-रन सेटअप को पूरा करें

सिस्टम प्रशासक.

रिवर्स प्रॉक्सी और टीएलएस

सार्वजनिक वेब मूल को पोर्ट 3000 पर प्रॉक्सी करें, और एपीआई और सॉकेट.आईओ पथ को पोर्ट 3001 पर प्रॉक्सी करें। उदाहरण के लिए, एक कैडी साइट ब्लॉक इसका उपयोग कर सकता है:

repovio.example.com {
  reverse_proxy /api/* 127.0.0.1:3001
  reverse_proxy /socket.io/* 127.0.0.1:3001
  reverse_proxy /mcp 127.0.0.1:3001
  reverse_proxy 127.0.0.1:3000
}

प्रॉक्सी को HTTP को HTTPS पर रीडायरेक्ट करना होगा, अपनी स्थानीय नीति के अनुसार अपस्ट्रीम कनेक्शन को मान्य करना होगा और सार्वजनिक होस्टनाम को संरक्षित करना होगा। OAUTH_CALLBACK_URL में समान HTTPS कॉलबैक URL सेट के साथ OAuth प्रदाताओं को कॉन्फ़िगर करें।

उन्नयन करना

इस ऐतिहासिक रिलीज़ के साथ भेजे गए सटीक कॉन्फ़िगरेशन और छवि संदर्भों का उपयोग करें। वर्तमान ब्रांडिंग-अपग्रेड निर्देश केवल नए Repovio रिलीज़ पर जाने पर ही लागू होते हैं; पुनर्नामित कॉन्फ़िगरेशन पहचानकर्ताओं को कभी भी पुरानी कंपोज़ फ़ाइल में कॉपी न करें।

चरण 1: छवियां बदलने से पहले एक डेटाबेस बैकअप बनाएं और सत्यापित करें।

चरण 2: रिलीज़-चयन चर को टैग किए गए `.env.example` से `.env` में सटीक रिलीज़ संस्करण पर सेट करें।

चरण 3: रिलीज को खींचें और लागू करें:

docker compose pull
docker compose up --detach --wait

migrate सेवा एपीआई शुरू होने से पहले लंबित प्रिज्मा माइग्रेशन लागू करती है। प्रत्येक अद्यतन के बाद इसका निरीक्षण करें:

docker compose logs migrate

चरण 4: अद्यतन को पूर्ण मानने से पहले स्वास्थ्य समापन बिंदु और प्रॉक्सी-सेवित डैशबोर्ड को सत्यापित करें।

डेटाबेस बैकअप

परिनियोजन निर्देशिका से बैकअप चलाएँ। यह क्रेडेंशियल प्रिंट किए बिना या कमांड लाइन में डाले बिना होस्ट को PostgreSQL कस्टम-फॉर्मेट डंप लिखता है:

mkdir -p backups
backup_file="backups/repovio-$(date +%F-%H%M%S).dump"
docker compose exec -T postgres sh -c 'pg_dump -U "$POSTGRES_USER" -Fc "$POSTGRES_DB"' \
  > "$backup_file"
pg_restore --list "$backup_file"

एन्क्रिप्टेड प्रतियों को ऑफ-होस्ट स्टोर करें और समय-समय पर एक अलग सिस्टम पर रिस्टोर का परीक्षण करें।

डेटाबेस पुनर्स्थापित करें

पुनर्स्थापित करना वर्तमान डेटाबेस ऑब्जेक्ट को प्रतिस्थापित करता है। पहले एक नया बैकअप लें और डाउनटाइम शेड्यूल करें।

docker compose stop api web
docker compose exec -T postgres sh -c 'pg_restore -U "$POSTGRES_USER" --clean --if-exists --no-owner -d "$POSTGRES_DB"' \
  < backups/repovio-YYYY-MM-DD-HHMMSS.dump
docker compose up --detach --wait

बाद में, docker compose logs migrate और एपीआई स्वास्थ्य समापन बिंदु की जाँच करें। स्कीमा परिवर्तनों को वापस रोल करते समय संगत Repovio संस्करण द्वारा बनाए गए डंप को पुनर्स्थापित करें।

रोलबैक

चरण 1: असफल अपग्रेड से तुरंत पहले का बैकअप बनाकर रखें।

चरण 2: रिलीज़-चयन चर को `.env` में टैग किए गए `.env.example` से अंतिम ज्ञात-अच्छी छवि संस्करण पर सेट करें।

चरण 3: `docker compose pull` और `docker compose up --detach --wait` चलाएँ।

चरण 4: यदि नई रिलीज़ ने डेटाबेस को असंगत रूप से माइग्रेट किया है, तो एपीआई और वेब को रोकें, संगत बैकअप को पुनर्स्थापित करें, और फिर

पिछला छवि संस्करण फिर से प्रारंभ करें.

docker compose down --volumes को कभी भी अपडेट या रोलबैक कमांड के रूप में उपयोग न करें: यह नामित PostgreSQL वॉल्यूम को हटा देता है।

इस पृष्ठ को संपादित करें

पिछला

दस्तावेज़ खोजें...