Google Cloud e2-micro पर पायथन वेबसर्वर का SSL कॉन्फ़िगरेशन: वास्तविक अनुभव

Google Cloud की नि:शुल्क e2-micro इंस्टेंस पर पायथन वेबसर्वर का SSL कॉन्फ़िगरेशन

Google Cloud की नि:शुल्क टियर में e2-micro इंस्टेंस का उपयोग करना एक बढ़िया विकल्प है, विशेष रूप से छोटे प्रोजेक्ट्स और व्यक्तिगत वेबसाइटों के लिए। मुझे यह अवसर मिला इसका उपयोग करने का, और मैं अपने अनुभव आपके साथ साझा करना चाहता हूँ।

वैसे मैं एक महत्वपूर्ण विषय – SSL प्रमाणपत्र कॉन्फ़िगरेशन के बारे में बात करूँगा। क्योंकि सीमित संसाधनों के कारण, मैंने पायथन आधारित वेबसर्वर का चयन किया, और इसमें SSL सेटिंग्स जोड़ने की प्रक्रिया दिलचस्प रही।

Google Cloud

Free Trial and Free Tier Services and Products Start building on Google Cloud with $300 in free credits and free usage of 20+ products like Compute Engine and Cloud Storage, up to monthly limits.

डोमेन और IP एड्रेस मैपिंग का महत्व

SSL प्रमाणपत्र प्राप्त करने से पहले, यह सुनिश्चित करना अत्यंत आवश्यक है कि आपका डोमेन नाम सही ढंग से आपके सर्वर के IP एड्रेस से जुड़ा हो। यह एक बुनियादी आवश्यकता है जिसे अक्सर नज़रअंदाज़ कर दिया जाता है, लेकिन यह SSL प्रमाणीकरण प्रक्रिया का मूल है।

DNS सेटिंग्स की जांच

सबसे पहले, अपने डोमेन के DNS कॉन्फ़िगरेशन में A रिकॉर्ड (या आवश्यकतानुसार CNAME रिकॉर्ड) की जांच करें। सुनिश्चित करें कि वह आपके सर्वर के सही IP एड्रेस की ओर इंगित करता है। इस महत्वपूर्ण सेटिंग से यह सुनिश्चित होता है कि जब कोई आगंतुक आपके डोमेन पर आए, तो वह सही सर्वर से कनेक्ट हो।

प्रमाणीकरण प्रक्रिया पर प्रभाव

Let’s Encrypt का Certbot यह पुष्टि करने के लिए HTTP (पोर्ट 80) पर आपके डोमेन तक पहुँचने का प्रयास करता है कि डोमेन वास्तव में आपके नियंत्रण में है। यदि DNS सेटिंग्स सही नहीं हैं, तो प्रमाणीकरण विफल हो जाएगा, और आप SSL प्रमाणपत्र प्राप्त नहीं कर पाएंगे।

समय देरी का ध्यान रखें

DNS सेटिंग्स में परिवर्तन करने के बाद, इन परिवर्तनों के प्रभावी होने में समय लग सकता है। आमतौर पर कुछ घंटों का इंतज़ार करें, लेकिन कभी-कभी यह प्रक्रिया 24 घंटे तक भी ले सकती है। धैर्य रखें – जल्दबाजी में किए गए प्रयास अक्सर व्यर्थ साबित होते हैं।

सुरक्षा दृष्टिकोण

सही DNS कॉन्फ़िगरेशन न केवल SSL प्रमाणपत्र के लिए महत्वपूर्ण है, बल्कि यह आपकी समग्र सुरक्षा रणनीति का भी आधार है। गलत सेटिंग्स से मध्यस्थ हमले (MITM) जैसे जोखिम बढ़ सकते हैं, इसलिए हर कदम पर सावधानी बरतना आवश्यक है।

Certbot का इंस्टालेशन

यदि आप Ubuntu 24.04 (मेरी तरह) या किसी अन्य Debian-आधारित सिस्टम का उपयोग कर रहे हैं, तो Certbot इंस्टॉल करना सरल है:

Debian/Ubuntu पर इंस्टालेशन:

1. पैकेज लिस्ट अपडेट करें:

sudo apt-get update

2. Certbot इंस्टॉल करें:

sudo apt-get install certbot

टिप: यदि आप Nginx या Apache का उपयोग कर रहे हैं, तो आप विशिष्ट प्लगइन (python3-certbot-nginx या python3-certbot-apache) भी इंस्टॉल कर सकते हैं। लेकिन क्योंकि हम सीधे Python वेबसर्वर का उपयोग कर रहे हैं, हमें स्टैंडअलोन मोड का उपयोग करना होगा।

प्रमाणपत्र प्राप्त करने की विधि

जब आप पायथन वेबसर्वर (जैसे Flask, FastAPI) का सीधे उपयोग कर रहे हैं, तो Certbot का स्टैंडअलोन मोड सबसे उपयुक्त विकल्प है। इस मोड में, Certbot अस्थायी रूप से अपना सर्वर चलाता है और पोर्ट 80 (HTTP) पर प्रमाणीकरण करता है।

स्टैंडअलोन मोड में प्रमाणपत्र प्राप्त करना:

1. यदि आपका वेबसर्वर चल रहा है, तो उसे अस्थायी रूप से बंद करें (क्योंकि Certbot को पोर्ट 80 का उपयोग करना होगा):

# अपने सर्विस को रोकने का कमांड, उदाहरण के लिए:
sudo systemctl stop your-python-service

2. निम्न कमांड से प्रमाणपत्र प्राप्त करें:

sudo certbot certonly --standalone -d yourdomain.example

(यहां yourdomain.example को अपने वास्तविक डोमेन नाम से बदलें)

सफल होने पर, प्रमाणपत्र फाइलें सामान्यतः /etc/letsencrypt/live/yourdomain.example/ डायरेक्टरी में स्थापित हो जाएंगी।

महत्वपूर्ण सुझाव (मेरा अनुभव)

मैंने अपने प्रयासों के दौरान सीखा कि Google Cloud के e2-micro इंस्टेंस पर Certbot चलाते समय, मेमोरी का प्रबंधन महत्वपूर्ण है। कभी-कभी, मेमोरी की कमी के कारण प्रक्रिया धीमी हो सकती है या टाइम-आउट हो सकती है। ऐसी स्थिति में, इन कदमों का पालन करें:

1. अनावश्यक सेवाओं को अस्थायी रूप से बंद करें
2. स्वैप मेमोरी बढ़ाएं (यदि संभव हो)
3. शांत समय में प्रमाणपत्र नवीनीकरण शेड्यूल करें

Python वेबसर्वर में SSL प्रमाणपत्र का एकीकरण

जब आप प्रमाणपत्र प्राप्त कर लेते हैं, तो अगला चरण इसे अपने Python वेबसर्वर में एकीकृत करना है। यहां मैं अपने अनुभव से साझा करता हूं कि विभिन्न फ्रेमवर्क्स में यह कैसे काम करता है:

Flask के साथ SSL का उपयोग:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello():
    return "नमस्ते, SSL सुरक्षित वेबसाइट पर आपका स्वागत है!"

if __name__ == '__main__':
    # प्रमाणपत्र और प्राइवेट की के पाथ निर्दिष्ट करें
    context = ('/etc/letsencrypt/live/yourdomain.example/fullchain.pem',
               '/etc/letsencrypt/live/yourdomain.example/privkey.pem')
    app.run(host='0.0.0.0', port=443, ssl_context=context)

FastAPI के साथ (मेरी पसंद):

FastAPI के साथ, आप Uvicorn का उपयोग करते हुए SSL सक्षम कर सकते हैं। मुझे यह फ्रेमवर्क इसके बेहतर प्रदर्शन और आधुनिक सुविधाओं के कारण पसंद है:

from fastapi import FastAPI
import uvicorn

app = FastAPI()

@app.get("/")
def root():
    return {"message": "सुरक्षित FastAPI सर्वर पर आपका स्वागत है!"}

if __name__ == "__main__":
    uvicorn.run(
        "main:app",
        host="0.0.0.0",
        port=443,
        ssl_certfile="/etc/letsencrypt/live/yourdomain.example/fullchain.pem",
        ssl_keyfile="/etc/letsencrypt/live/yourdomain.example/privkey.pem"
    )

सावधानी: e2-micro इंस्टेंस पर FastAPI चलाते समय, मैंने पाया कि डिफॉल्ट वर्कर्स संख्या को कम करके (जैसे workers=2) मेमोरी उपयोग को अनुकूलित करना महत्वपूर्ण है। इससे आपका सर्वर स्थिर रहेगा।

प्रमाणपत्र स्वचालित नवीनीकरण की व्यवस्था

Let’s Encrypt प्रमाणपत्र केवल 90 दिनों के लिए वैध होते हैं, इसलिए स्वचालित नवीनीकरण सेट करना अत्यंत महत्वपूर्ण है। यहां दो प्रभावी तरीके हैं:

1. Cron का उपयोग करके स्वचालित नवीनीकरण

Cron Linux का मानक शेड्यूलिंग टूल है। इसे निम्न तरीके से सेट कर सकते हैं:

1. अपना crontab एडिट करें:

crontab -e

2. निम्न लाइन जोड़ें (हर दिन सुबह 3 बजे नवीनीकरण चेक करने के लिए):

0 3 * * * sudo certbot renew --dry-run >> /var/log/certbot-renew.log 2>&1

इस सेटिंग से Certbot हर दिन रात 3 बजे चेक करेगा कि क्या आपके प्रमाणपत्र को नवीनीकरण की आवश्यकता है। --dry-run फ्लैग पहले यह सुनिश्चित करता है कि प्रक्रिया सही ढंग से काम करेगी।

प्रमाणपत्र नवीनीकरण के समय ध्यान देने योग्य बातें

मैंने व्यक्तिगत अनुभव से सीखा है कि प्रमाणपत्र नवीनीकरण के दौरान निम्न समस्याएं हो सकती हैं:

1. पोर्ट बंधन मुद्दे: यदि आपका सर्वर पोर्ट 80 पर चल रहा है, तो नवीनीकरण विफल हो सकता है। एक समाधान यह है कि अपने स्क्रिप्ट में नवीनीकरण से पहले सर्वर को रोकना और बाद में पुनः आरंभ करना शामिल करें।
2. अनुमति संबंधी समस्याएं: सुनिश्चित करें कि आपके सर्वर प्रक्रिया को प्रमाणपत्र फाइलों तक पहुंच है। यह मुद्दा विशेष रूप से e2-micro इंस्टेंस पर बार-बार सामने आया, जहां संसाधन प्रबंधन अधिक कठिन है।

systemd टाइमर से स्वचालित नवीनीकरण सेटअप

Cron के अलावा, systemd टाइमर भी एक शक्तिशाली विकल्प है जो बेहतर लॉगिंग और निगरानी प्रदान करता है। मैंने शुरू में cron का उपयोग किया, लेकिन बाद में systemd टाइमर को अपनाया क्योंकि यह अधिक आधुनिक और विश्वसनीय लगा। यहां पूरी प्रक्रिया है:

1. सर्विस यूनिट फाइल बनाएं

सबसे पहले, Certbot के नवीनीकरण परीक्षण को चलाने के लिए एक सर्विस यूनिट फाइल बनाएं:

sudo nano /etc/systemd/system/certbot-renew.service

फाइल में निम्न सामग्री जोड़ें:

[Unit]
Description=Certbot Renewal Dry-Run

[Service]
Type=oneshot
ExecStart=/usr/bin/sudo /usr/bin/certbot renew --dry-run

[Install]
WantedBy=multi-user.target

2. टाइमर यूनिट फाइल बनाएं

अब, इस सेवा को नियमित रूप से चलाने के लिए एक टाइमर बनाएं:

sudo nano /etc/systemd/system/certbot-renew.timer

फाइल में निम्न सामग्री जोड़ें:

[Unit]
Description=Run certbot renew twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=1hour
Persistent=true

[Install]
WantedBy=timers.target

विशेषज्ञ टिप: RandomizedDelaySec Let’s Encrypt सर्वर पर लोड को फैलाने में मदद करता है, जिससे उनके सर्वर पर अचानक ट्रैफ़िक बढ़ने से बचा जाता है और आपके नवीनीकरण की सफलता की संभावना बढ़ जाती है।

3. टाइमर सक्रिय करें

अब टाइमर को सक्रिय करें और चालू करें:

sudo systemctl daemon-reload
sudo systemctl enable certbot-renew.timer
sudo systemctl start certbot-renew.timer

4. टाइमर की स्थिति जांचें

टाइमर की स्थिति जांचने के लिए:

sudo systemctl status certbot-renew.timer

VSCode की रिमोट डेवलपमेंट और संसाधन चुनौतियां

Google Cloud के e2-micro इंस्टेंस पर काम करते समय एक बड़ी चुनौती संसाधनों के प्रबंधन की है, विशेष रूप से VSCode रिमोट डेवलपमेंट का उपयोग करते समय। जाइए इन सीमाओं और समाधानों को गहराई से समझते हैं।

e2-micro संसाधन विनिर्देश

इस बजट-अनुकूल इंस्टेंस के स्पेसिफिकेशन निम्नलिखित हैं:

इन विनिर्देशों को देखकर मन में सवाल आता है, “क्या इतने कम संसाधनों में वेब सर्वर चलाना और डेवलपमेंट करना संभव है?” मैंने अपने अनुभव से पाया कि – हां, बिल्कुल संभव है, लेकिन कुछ सावधानियां बरतनी होती हैं।

VSCode रिमोट डेवलपमेंट और सिस्टम संसाधन प्रबंधन

जब मैंने अपने e2-micro इंस्टेंस का अध्ययन किया, तो एक आश्चर्यजनक तथ्य सामने आया। मैं प्रक्रियाओं की सूची देख रहा था और पाया कि सबसे अधिक संसाधन उपभोग करने वाला प्रोसेस था – node (PID 3062)!

वर्चुअल मेमोरी आकार: 31.3GB (बहुत अधिक!)
वास्तविक मेमोरी उपयोग: कुल सिस्टम मेमोरी का 13.1%

यह हैरानी की बात थी क्योंकि मेरा सर्वर तो FastAPI और Uvicorn पर आधारित पायथन इम्प्लीमेंटेशन था! मैं सोचने लगा, “अरे, यह नोड प्रोसेस कहां से आ गया? मैंने तो Node.js का इस्तेमाल ही नहीं किया!”

समस्या का निदान

थोड़ी जांच-पड़ताल के बाद, मुझे पता चला कि VSCode का Remote – SSH फीचर और कुछ एक्सटेंशन बैकग्राउंड में Node.js का उपयोग करते हैं। वास्तव में, VSCode एडिटर की कई सुविधाएं (जैसे लैंग्वेज सर्वर) Node.js पर आधारित हैं।

आहा मोमेंट: जब मैंने TeraTerm जैसे सरल SSH क्लाइंट से कनेक्ट किया, तो मेमोरी उपयोग आधा हो गया! यह स्पष्ट हो गया कि VSCode रिमोट एक्सटेंशन ही मेमोरी खपत का प्रमुख स्रोत थे।

सिस्टम संसाधनों की निगरानी के तरीके

अगर आप लिनक्स पर नए हैं या सिस्टम संसाधनों की निगरानी के तरीके नहीं जानते, तो ये टूल्स आपकी मदद करेंगे:

top कमांड

यह सबसे बुनियादी और सर्वव्यापी टूल है। बस टर्मिनल में top टाइप करें और एंटर दबाएं:

top

आपको रीयल-टाइम में चल रही प्रक्रियाओं की सूची दिखाई देगी, जो CPU और मेमोरी उपयोग के अनुसार सॉर्ट की गई होगी।

htop कमांड

top का एक बेहतर और अधिक विज़ुअल विकल्प है htop। इसे पहले इंस्टॉल करें:

sudo apt install htop

फिर बस चलाएं:

htop

free कमांड

मेमोरी उपयोग की त्वरित जानकारी के लिए free -m कमांड का उपयोग करें, जो मेगाबाइट्स में मेमोरी स्थिति दिखाता है:

free -m

उदाहरण आउटपुट:

              total        used        free      shared  buff/cache   available
Mem:            981         423         112          21         445         392
Swap:          2047         157        1890

परिणाम और समाधान

मेरे स्थिति में, यह स्पष्ट हो गया कि VSCode के Remote – SSH कनेक्शन के दौरान Node.js प्रोसेस अधिक मेमोरी उपयोग करता है। लेकिन यह एक आवश्यक ट्रेडऑफ है – आधुनिक, सुविधा-संपन्न डेवलपमेंट अनुभव के लिए कुछ अतिरिक्त संसाधन खर्च करने पड़ते हैं।

कुछ व्यावहारिक समाधान:

1. लंबे सत्रों के लिए TeraTerm या अन्य हल्के SSH क्लाइंट का उपयोग करें: जब आप केवल कुछ कमांड चलाना चाहते हैं।
2. VSCode एक्सटेंशन सीमित करें: केवल वही एक्सटेंशन इंस्टॉल करें जिनका आप वास्तव में उपयोग करते हैं।
3. स्वैप मेमोरी बढ़ाएं: Google Cloud के e2-micro इंस्टेंस पर, अतिरिक्त स्वैप मेमोरी सेट करना फायदेमंद हो सकता है:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

स्थायी बनाने के लिए, /etc/fstab में जोड़ें:

/swapfile swap swap defaults 0 0

SSL प्रमाणपत्र प्राप्ति में आने वाली समस्याएं और समाधान

प्रमाणपत्र प्राप्त करने की प्रक्रिया हमेशा सरल नहीं होती। मैंने इस यात्रा में कई बाधाओं का सामना किया और उन्हें हल करने के लिए कई घंटे बिताए। आइए मेरे अनुभवों से सीखें ताकि आप इन चुनौतियों से बच सकें।

प्रमुख त्रुटि: प्रमाणीकरण विफलता

जब मैंने प्रमाणपत्र प्राप्त करने का प्रयास किया, तो निम्न त्रुटि संदेश मिला:

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: stellar.minokamo.tokyo
Type: unauthorized
Detail: 34.71.218.202: Invalid response from http://stellar.minokamo.tokyo/.well-known/acme-challenge/ta2ZWJxbF37vku_iX0pSC8FoBluxEimCphE2NHfViYY: "\n\n\n\n \n <meta name=\"viewport\" content=\"width=device-width, ini"

यह त्रुटि संदेश बताता है कि Certbot डोमेन प्रमाणीकरण के लिए आवश्यक चैलेंज फाइलों को सही ढंग से सेट करने में विफल रहा। मेरे मामले में, यह समस्या Cloudflare कॉन्फ़िगरेशन से संबंधित हो सकती थी, क्योंकि मैंने पहले एक अलग डोमेन के लिए Cloudflare का उपयोग किया था।

यह जानना महत्वपूर्ण है: कभी-कभी पिछले कॉन्फ़िगरेशन हमारे नए प्रयासों को प्रभावित कर सकते हैं। मैंने सोचा, “अरे, शायद मेरी DNS सेटिंग्स में कोई पुरानी कॉन्फ़िगरेशन बाधा डाल रही है!”

समस्याओं की पहचान और समाधान

मेरी मुख्य चुनौतियां थीं:

1. सर्वर पोर्ट 8080 पर चल रहा था

समस्या: Certbot का standalone मोड ACME चैलेंज के लिए पोर्ट 80 का उपयोग करता है। लेकिन मेरा FastAPI सर्वर पोर्ट 8080 पर चल रहा था, जिससे Certbot सही तरीके से काम नहीं कर पा रहा था।

समाधान:

• Certbot चलाने से पहले Python सर्वर को अस्थायी रूप से बंद करें
• फिर प्रमाणपत्र प्राप्त करें
• फिर सर्वर को पुनः आरंभ करें

sudo systemctl stop my-python-service  # अस्थायी रूप से सर्वर बंद करें
sudo certbot certonly --standalone -d stellar.minokamo.tokyo
sudo systemctl start my-python-service  # सर्वर पुनः आरंभ करें

2. –webroot मोड का उपयोग करना

वैकल्पिक समाधान: सर्वर को बंद किए बिना प्रमाणपत्र प्राप्त करने के लिए –webroot मोड का उपयोग करें।

प्रक्रिया:

1. Certbot के लिए डायरेक्टरी बनाएं:

sudo mkdir -p /var/www/html/.well-known/acme-challenge
sudo chown -R $USER:$USER /var/www/html

2. FastAPI में इस पाथ के लिए रूट जोड़ें:

from fastapi.staticfiles import StaticFiles
# अन्य कोड के बाद
app.mount("/.well-known", StaticFiles(directory="/var/www/html/.well-known"), name="well-known")

3. Certbot को –webroot मोड में चलाएं:

sudo certbot certonly --webroot -w /var/www/html -d stellar.minokamo.tokyo

बड़ी गलतफहमी: पोर्ट फॉरवर्डिंग

मैं लगातार इस बात से कंफ्यूज़ था कि कैसे मेरा सर्वर पोर्ट 8080 पर चल रहा था, फिर भी http://stellar.minokamo.tokyo/ पर (पोर्ट 80) एक्सेस किया जा सकता था!

जांच करने पर पता चला कि मैंने पहले iptables द्वारा पोर्ट फॉरवर्डिंग कॉन्फ़िगर किया था और फिर इसे भूल गया था। कमांड sudo iptables -t nat -L -n -v से निम्न आउटपुट मिला:

Chain PREROUTING (policy ACCEPT 6341 packets, 394K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 4041  238K REDIRECT   6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 8080

यह दर्शाता है कि पोर्ट 80 पर आने वाले सभी अनुरोध स्वचालित रूप से पोर्ट 8080 पर रीडायरेक्ट हो रहे थे!

मैंने अपने आप से कहा: “अच्छा! तो यह बात है! मैं बिना पोर्ट नंबर स्पेसिफाई किए भी वेबसाइट एक्सेस कर पा रहा था, क्योंकि iptables सिलेंट मोड में काम कर रहा था।”

अंतिम समाधान: –webroot विधि

मेरे मामले में, मौजूदा iptables सेटअप को देखते हुए –webroot विधि सबसे अच्छा समाधान था:

1. सर्वर को बंद करने की आवश्यकता नहीं
2. वर्तमान HTTP स्थानांतरण का लाभ उठाता है
3. अधिक नियमित नवीनीकरण के लिए अनुकूल

इसके बाद, मैंने अपने वेबसर्वर को HTTPS सक्षम करने के लिए अंतिम कदम उठाए। यहां वे कदम हैं जो मुझे करने पड़े:

FastAPI में SSL प्रमाणपत्र एकीकरण

प्रमाणपत्र मिलने के बाद, मुझे web.py में uvicorn.run() कॉल को अपडेट करना था ताकि SSL कॉन्फ़िगरेशन शामिल हो सके:

# पहले (SSL के बिना)
uvicorn.run("web:app", host="0.0.0.0", port=8080, proxy_headers=True, forwarded_allow_ips="*")

# बाद में (SSL के साथ)
uvicorn.run(
    "web:app",
    host="0.0.0.0",
    port=8080,
    proxy_headers=True,
    forwarded_allow_ips="*",
    ssl_certfile="/etc/letsencrypt/live/stellar.minokamo.tokyo/fullchain.pem",
    ssl_keyfile="/etc/letsencrypt/live/stellar.minokamo.tokyo/privkey.pem"
)

HTTPS के लिए पोर्ट फॉरवर्डिंग सेटअप

HTTP (पोर्ट 80) से पोर्ट 8080 तक कनेक्शन तो ठीक से हो रहे थे, लेकिन HTTPS (पोर्ट 443) के लिए भी एक समान रीडायरेक्ट की आवश्यकता थी:

sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8080

इस कमांड से HTTPS अनुरोध भी पोर्ट 8080 पर चल रहे मेरे FastAPI सर्वर तक पहुंच सकेंगे।

अनुमति संबंधी समस्याओं का समाधान

वेबसर्वर SSL फाइलों को पढ़ नहीं पा रहा था:

ls -l /etc/letsencrypt/live/stellar.minokamo.tokyo/
ls: cannot access '/etc/letsencrypt/live/stellar.minokamo.tokyo/': Permission denied

FastAPI प्रोसेस के लिए अनुमतियां सेट करने के लिए, मैंने ACL (एक्सेस कंट्रोल लिस्ट) का उपयोग किया:

# पहले, acl टूल इंस्टॉल करें
sudo apt install acl

# फिर फाइल अनुमतियां सेट करें
sudo setfacl -m u:minok:rx /etc/letsencrypt
sudo setfacl -m u:minok:rx /etc/letsencrypt/live
sudo setfacl -R -m u:minok:rx /etc/letsencrypt/live/stellar.minokamo.tokyo
sudo setfacl -m u:minok:rx /etc/letsencrypt/archive
sudo setfacl -R -m u:minok:rx /etc/letsencrypt/archive/stellar.minokamo.tokyo

Systemd सर्विस में SSL कॉन्फ़िगरेशन जोड़ना

सबसे महत्वपूर्ण अंतिम कदम था systemd सर्विस में SSL सर्टिफिकेट पाथ जोड़ना। मैंने गलती से इसे छोड़ दिया था और इसी कारण HTTPS काम नहीं कर रहा था!

# पहले (गलत सेटअप)
[Service]
User=minok
Group=minok
WorkingDirectory=/home/minok/web
Environment="PATH=/home/minok/web/venv/bin"
ExecStart=/home/minok/web/venv/bin/uvicorn web:app --host 0.0.0.0 --port 8080 --proxy-headers --forwarded-allow-ips="*"

# सही सेटअप
[Service]
User=minok
Group=minok
WorkingDirectory=/home/minok/web
Environment="PATH=/home/minok/web/venv/bin"
ExecStart=/home/minok/web/venv/bin/uvicorn web:app --host 0.0.0.0 --port 8080 --proxy-headers --forwarded-allow-ips="*" --ssl-certfile /etc/letsencrypt/live/stellar.minokamo.tokyo/fullchain.pem --ssl-keyfile /etc/letsencrypt/live/stellar.minokamo.tokyo/privkey.pem

इस परिवर्तन के बाद, सर्विस को रीलोड और रीस्टार्ट करना आवश्यक था:

sudo systemctl daemon-reload
sudo systemctl restart web.service

iptables सेटिंग्स को स्थायी बनाना

अंत में, मैंने iptables सेटिंग्स को स्थायी बनाया ताकि सर्वर रीस्टार्ट के बाद भी ये सेटिंग्स बनी रहें:

sudo apt install iptables-persistent
sudo netfilter-persistent save

इन सभी चरणों के बाद, मेरा FastAPI वेबसर्वर Google Cloud के e2-micro इंस्टेंस पर SSL के साथ सुरक्षित रूप से चल रहा था! यह एक लंबी यात्रा थी, लेकिन अंत में, हर समस्या का समाधान मिला और मैं HTTPS सुरक्षा का लाभ उठा पा रहा हूँ।

संपूर्ण प्रक्रिया का सारांश और अतिरिक्त सुझाव

आखिरकार, मैंने Google Cloud पर e2-micro इंस्टेंस पर अपने Python वेबसर्वर के लिए SSL कॉन्फ़िगरेशन सफलतापूर्वक पूरा कर लिया। यह अनुभव न केवल तकनीकी रूप से चुनौतीपूर्ण था, बल्कि सीखने के लिए भी अत्यंत मूल्यवान था। मैं यहां कुछ अतिरिक्त विचार और सुझाव साझा करना चाहता हूं जो आपके लिए उपयोगी हो सकते हैं।

सुरक्षित वेबसर्वर की जांच

जब सब कुछ सेट हो जाए, तो अपने सर्वर की सुरक्षा और कॉन्फ़िगरेशन की जांच करना महत्वपूर्ण है। मैंने निम्न तरीकों से अपने सेटअप की जांच की:

ब्राउज़र से परीक्षण: सबसे पहले, मैंने https://stellar.minokamo.tokyo/ पर नेविगेट करके जांचा कि कनेक्शन सुरक्षित है या नहीं।

SSL लैब्स टेस्ट: SSL Labs पर अपने डोमेन की जांच करें। यह आपके SSL कॉन्फ़िगरेशन की गुणवत्ता का ग्रेड देगा।

कमांड लाइन से परीक्षण:

curl -I https://stellar.minokamo.tokyo/

e2-micro इंस्टेंस पर प्रदर्शन अनुकूलन

SSL जोड़ने के बाद, संसाधन उपयोग पर नज़र रखना और प्रदर्शन को अनुकूलित करना महत्वपूर्ण है। मेरे कुछ सुझाव हैं:

1. वर्कर्स की संख्या कम रखें: उदाहरण के लिए, Uvicorn में --workers=2 या कम का उपयोग करें।
2. कैशिंग का उपयोग करें: स्थिर सामग्री के लिए कैशिंग जोड़कर CPU उपयोग कम करें।
3. लॉगिंग को अनुकूलित करें: विस्तृत लॉगिंग डिस्क I/O बढ़ा सकती है, जिससे इंस्टेंस धीमा हो सकता है।
4. मेमोरी लीक पर नज़र रखें: Python सर्वर को लंबे समय तक चलाते समय, संसाधनों पर नियमित रूप से नज़र रखें।

बग फिक्स और अंतिम समाधान

SSL सेटअप के बाद भी, मुझे अपने वेबसर्वर में कुछ बग्स मिले और उन्हें ठीक करना पड़ा। यहां मेरे अनुभवों का एक संक्षिप्त सारांश है:

1. परमिशन इश्यू: मुझे अक्सर “Permission denied” त्रुटियां मिलीं। इसके लिए ACL (एक्सेस कंट्रोल लिस्ट) का उपयोग करना सबसे अच्छा समाधान साबित हुआ।
2. सिस्टम सर्विस पुनः प्रारंभ करने पर कॉन्फिगरेशन लॉस: हर बार जब सर्वर रीस्टार्ट होता, तो iptables नियम खो जाते। इसे ठीक करने के लिए, मैंने iptables-persistent पैकेज का उपयोग किया।
3. मेमोरी प्रबंधन: बड़ी संख्या में अनुरोधों से निपटने के लिए, मैंने एक संतुलित वर्कर कॉन्फ़िगरेशन और स्वैप मेमोरी का उपयोग किया।
4. SSL सर्टिफिकेट अपडेट करना याद रखें: प्रमाणपत्र 90 दिनों के बाद समाप्त हो जाते हैं, इसलिए नवीनीकरण प्रक्रिया स्वचालित और सुरक्षित होनी चाहिए।

निष्कर्ष: बजट-अनुकूल होस्टिंग के लिए अंतिम सुझाव

Google Cloud के e2-micro इंस्टेंस पर SSL-सुरक्षित पायथन वेबसर्वर चलाना निश्चित रूप से संभव है, और यह छोटे से मध्यम आकार के प्रोजेक्ट्स के लिए एक किफायती विकल्प है। मेरे अंतिम सुझाव:

1. संसाधन प्रबंधन पर ध्यान केंद्रित करें: सिस्टम उपयोग की निगरानी करें और संसाधन-भारी प्रक्रियाओं को सीमित करें।
2. सर्वर तैनाती के लिए स्क्रिप्ट बनाएं: आसान अपडेट और रीडेप्लॉयमेंट के लिए संपूर्ण सेटअप प्रक्रिया को स्वचालित करें।
3. बैकअप रणनीति रखें: नियमित बैकअप सुनिश्चित करें, विशेष रूप से SSL कॉन्फ़िगरेशन फाइलों के लिए।
4. स्केलिंग सीमाओं को समझें: e2-micro के पास सीमित संसाधन हैं। जब आपकी साइट पर ट्रैफ़िक बढ़े, तो अपग्रेड करने के लिए तैयार रहें।
5. CloudFlare जैसे CDN पर विचार करें: अतिरिक्त सुरक्षा परत के लिए और स्थिर सामग्री के लिए कैशिंग सुनिश्चित करने के लिए।

इस प्रोजेक्ट ने मुझे सिखाया है कि बजट की सीमाएं आपको रचनात्मक समाधान खोजने के लिए प्रेरित कर सकती हैं। मुझे उम्मीद है कि मेरा अनुभव आपकी अपनी SSL यात्रा में सहायक होगा।

अगर आप e2-micro इंस्टेंस पर अन्य प्रकार के प्रोजेक्ट्स आज़माना चाहते हैं, तो मैं अपनी वेबसाइट या सोशल मीडिया पर अपडेट शेयर करता रहूंगा। आप प्रश्न या सुझाव के लिए मुझसे संपर्क कर सकते हैं।

शुभकामनाएं!