როგორ დავჰოსტოთ Django ვებსაიტი?
როგორ გამოვაქვეყნოთ Python/Django-თი შექმნილი საიტი უფასოდ? უბრალოდ მიჰყევით ამ გზამკვლევს.
თუ Django-ზე დაწერილი პროექტი მზად გაქვთ და გსურთ მისი დაჰოსტვა/გამოქვეყნება მარტივად, მაშინ გეტყვით, რომ Render-ი ერთ-ერთი ყველაზე მარტივი პლატფორმაა ამისთვის. ეს გზამკვლევი/ტუტორიალი გაგატარებთ ყოველ ნაბიჯს, კონფიგურაციის ფაილების შექმნიდან დაწყებული LIVE-ში გასვლამდე!
გზამკვლევი დავყავი ხუთ ფაზად. მიჰყევით მათ თანმიმდევრობით და დაახლოებით, 30 წუთში თქვენი საიტი დაიჰოსტება. მაშ ასე, დავიწყოთ!
ფაზა 1: ორი ფაილი, რომელიც უნდა შექმნათ
თქვენი პროექტის root დირექტორიაში, manage.py-ს გვერდით, შექმენით ეს ორი ფაილი.
ფაილი 1: requirements.txt
ეს ეუბნება Render-ს, რომელი Python პაკეტები უნდა დააყენოს თქვენი აპლიკაციის გაშვებამდე.
ჩაწერეთ მასში:
django
gunicorn
dj-database-url
psycopg2-binary
whitenoiseფაილი 2: build.sh
ეს არის shell სკრიპტი, რომელსაც Render ავტომატურად უშვებს ყოველ დაჰოსტვაზე. ის აყენებს პაკეტებს, აგროვებს სტატიკურ ფაილებს, უშვებს მიგრაციებს და სურვილისამებრ ქმნის superuser-ს.
შექმენით ფაილი სახელწოდებით build.sh და დააკოპირეთ ეს კოდი მასში:
#!/usr/bin/env bash
set -o errexit
pip install -r requirements.txt
python3 manage.py collectstatic --no-input
python3 manage.py migrate
if [[ "$CREATE_SUPERUSER" == "True" ]]; then
python3 manage.py createsuperuser \
--no-input \
--username "$DJANGO_SUPERUSER_USERNAME" \
--email "$DJANGO_SUPERUSER_EMAIL" || true
fi|| true createsuperuser-ის ხაზის ბოლოში ნიშნავს, რომ build არ ჩავარდება, თუ სუპერმომხმარებელი უკვე არსებობს. ხოლო set -o errexit აიძულებს მთელ სკრიპტს დაუყოვნებლივ შეჩერდეს, თუ რომელიმე ბრძანება ჩავარდება, რათა შეცდომები ადრეულ ეტაპზე დაიჭიროთ.
თუ თქვენ ხართ macOS-ზე ან Linux-ზე, გაუშვით chmod +x build.sh ტერმინალში. Windows-ის მომხმარებლებმა Git Bash-ში უნდა გაუშვან git update-index --chmod=+x build.sh, რათა Render-მა სკრიპტის გაშვება შეძლოს.
ფაზა 2: settings.py-ის განახლება
გახსენით თქვენი Django პროექტის settings.py. აქ ჩვენ გავმართავთ იმპორტებს, საიდუმლო გასაღებს, debug რეჟიმს, დაშვებულ ჰოსტებს, middleware-ს, მონაცემთა ბაზის კონფიგურაციას, სტატიკურ ფაილებს და HTTPS-ის მხარდაჭერას. განვიხილოთ ისინი სათითაოდ.
იმპორტები
ფაილის ზედა ნაწილთან ახლოს, დაამატეთ ეს ორი ხაზი:
import os
import dj_database_urlსაიდუმლო გასაღები
შეწყვიტეთ საიდუმლო გასაღების ხისტად ჩაწერა და ამის ნაცვლად აიღეთ ის გარემოს ცვლადიდან:
SECRET_KEY = os.environ["SECRET_KEY"]თუ გსურთ სარეზერვო ვარიანტი ლოკალური დეველოპმენტისთვის, გააკეთეთ ასე:
SECRET_KEY = os.environ.get("SECRET_KEY", "your-local-development-secret-key")Debug რეჟიმი
შეცვალეთ ხაზი, რომელიც ამბობს DEBUG = True, ამით:
DEBUG = os.environ.get("DEBUG", "False") == "True"ამგვარად, debug რეჟიმი default-ად გამორთული იქნება და მას მხოლოდ მაშინ ჩართავთ, როცა პირდაპირ დააყენებთ DEBUG=True -ს თქვენს გარემოში.
დაშვებული ჰოსტები
ყველასთვის ღია ALLOWED_HOSTS = ["*"]-ის ნაცვლად, გადადით ამაზე:
ALLOWED_HOSTS = os.environ.get(
"ALLOWED_HOSTS",
"localhost,127.0.0.1",
).split(",")გარემოს ცვლადების გარეშე თქვენი აპლიკაცია ლოკალურად იმუშავებს უპრობლემოდ, ხოლო Render-ზე დაგჭირდებათ გადასცეთ მძიმით გამოყოფილი თქვენი დომენების სია ან Render-ის მიერ მოცემული URL your-app-name.onrender.com.
Middleware
იპოვეთ MIDDLEWARE სია და დაამატეთ WhiteNoise-ის ჩანაწერი პირდაპირ SecurityMiddleware-ს შემდეგ, ასე:
MIDDLEWARE = [
"django.middleware.security.SecurityMiddleware",
"whitenoise.middleware.WhiteNoiseMiddleware",
...
]აქ თანმიმდევრობა არ აგერიოთ. WhiteNoise უნდა იყოს მეორე, არა პირველი და არა ბოლო.
მონაცემთა ბაზა
შეცვალეთ თქვენი მთელი DATABASES dictionary ამით:
DATABASES = {
"default": dj_database_url.config(
default="sqlite:///db.sqlite3",
conn_max_age=600,
)
}ამ კონფიგურაციის წყალობით, როცა პროექტს ლოკალურად უშვებთ, ვებსაიტი ავტომატურად იყენებს SQLite-ს (რადგან DATABASE_URL ცვლადი არ არსებობს). ხოლო Render-ზე, თუ გარემოს ცვლადებში DATABASE_URL-ს დაამატებთ, აპლიკაცია კოდის შეცვლის გარეშე, პირდაპირ PostgreSQL-ზე გადაერთვება. პარამეტრი conn_max_age=600 კი მონაცემთა ბაზასთან კავშირს 10 წუთის (600 წამის) განმავლობაში ღიას ტოვებს, რაც ყოველ ახალ მოთხოვნაზე (request) ხელახალი დაკავშირების დროსა და რესურსს (overhead) დაგიზოგავთ.
სტატიკური ფაილები
დაამატეთ ეს კოდი settings.py-ის ბოლოში:
STATIC_URL = "static/"
STATIC_ROOT = BASE_DIR / "staticfiles"
STORAGES = {
"staticfiles": {
"BACKEND": "whitenoise.storage.CompressedManifestStaticFilesStorage",
},
}WhiteNoise მოემსახურება თქვენს სტატიკურ ფაილებს პირდაპირ Django პროცესიდან. მცირე და საშუალო ზომის საიტებისთვის ეს სრულიად მისაღებია და გათავისუფლებთ ცალკე CDN-ის ან ობიექტების საცავის (object storage bucket) კონფიგურაციისგან.
HTTPS მხარდაჭერა
დაამატეთ ეს ერთი ხაზი:
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")Render შიფრავს HTTPS/TLS კავშირს თავის გარე სერვერზე (edge-ზე) და შემდეგ მოთხოვნებს შიდა ქსელში HTTP-ით გადასცემს, ამასთან ერთად ამატებს X-Forwarded-Proto ჰედერს, რომელიც მიუთითებს, რომ თავდაპირველი მოთხოვნა HTTPS-ით იყო გაკეთებული. ეს პარამეტრი ეუბნება Django-ს, რომ ენდოს ამ სათაურს, რათა მან დააგენერიროს უსაფრთხო URL-ები და სწორად დაამუშაოს გადამისამართებები.
ფაზა 3: GitHub-ზე ატვირთვა
Render აკვირდება თქვენს GitHub რეპოზიტორიას, ამიტომ საჭიროა თქვენი კოდის აქ ატვირთვა. (აქ ვგულისხმობ, რომ საბაზისო დონეზე Git-ისა და Github ის გამოყენება უკვე იცით).
git add .
git commit -m "Deployment ready"
git push origin mainფაზა 4: Render-ის მართვის პანელის მორგება
შედით render.com-ზე. გადადით Render-ის მართვის პანელზე. დააკლიკეთ New და აირჩიეთ Web Service. დაუკავშირეთ GitHub რეპოზიტორია, რომელშიც თქვენი Django პროექტია.
დაკავშირების შემდეგ ნახავთ ბრძანების ორ ველს.
Build Command-ისთვის ჩაწერეთ:
./build.shStart Command-ისთვის ჩაწერეთ:
gunicorn YOUR_PROJECT_NAME.wsgiშეცვალეთ YOUR_PROJECT_NAME თქვენი Django-s პროექტის რეალური სახელით, რომელიც არის ის ფოლდერი, რომელიც შეიცავს settings.py-ს და wsgi.py-ს. მაგალითად, თუ თქვენს პროექტს ჰქვია blog, თქვენ დაწერთ gunicorn blog.wsgi.
შემდეგ, დაამატეთ გარემოს ცვლადები Environment სექციაში.
PYTHON_VERSION 3.13.0
SECRET_KEY your-django-secret-key
DEBUG False
ALLOWED_HOSTS your-app-name.onrender.com
CREATE_SUPERUSER True
DJANGO_SUPERUSER_USERNAME your-username
DJANGO_SUPERUSER_PASSWORD your-password
DJANGO_SUPERUSER_EMAIL [email protected]თუ Render-ის მართვის პანელზე შექმნით PostgreSQL მონაცემთა ბაზას (New > PostgreSQL), დაგჭირდებათ მისი ხელით დაკავშირება. დააკოპირეთ ბაზის Internal Database URL, დაბრუნდით თქვენი Web Service-ის Environment განყოფილებაში, დაამატეთ ახალი ცვლადი სახელად DATABASE_URL და ჩასვით დაკოპირებული URL მის მნიშვნელობად.
ფაზა 5: დაჰოსტვის დასრულება
დააკლიკეთ Create Web Service და უყურეთ build-ის ლოგებს. პირველ განთავსებას რამდენიმე წუთი სჭირდება, რადგან Render-ს სჭირდება გარემოს მოწყობა, პაკეტების დაყენება, მიგრაციების გაშვება და სტატიკური ფაილების შეგროვება.
როგორც კი სტატუსი აჩვენებს "Live," გახსენით URL, რომელსაც Render გაძლევთ. თქვენ უნდა ნახოთ თქვენი Django აპლიკაცია.
ეწვიეთ /admin-ს და შედით superuser-ის მონაცემებით, რომლებიც გარემოს ცვლადებში დააყენეთ.
მას შემდეგ, რაც დარწმუნდებით, რომ ჩვულებრივ შეგიძლიათ შესვლა ადმინ პანელში, დაბრუნდით Render-ის მართვის პანელზე, გახსენით Environment ჩანართი თქვენი სერვისისთვის და შეცვალეთ CREATE_SUPERUSER True-დან False-ზე. თუ მას True-ზე დატოვებთ, სკრიპტი შეეცდება კვლავ შექმნას სუპერმომხმარებელი ყოველ მომავალ, ხელახლა დაჰოსტვაზე. || true build.sh-ში ნიშნავს, რომ განთავსება არ ჩავარდება, მაგრამ თქვენ იხილავთ შეცდომას ლოგებში ყოველ ჯერზე, რაც ლამაზი არ იქნება.
რას მიიღებთ საბოლოოდ
როგორც კი ყველაფერი იმუშავებს, თქვენი კონფიგურაცია აკეთებს შემდეგს:
- დამოკიდებულებები (dependencies) ავტომატურად დაყენდება ყოველ გამოქვეყნებაზე.
- სტატიკური ფაილები ავტომატურად გროვდება ყოველ გამოქვეყნებაზე.
- მონაცემთა ბაზის მიგრაციებიც ეშვება ავტომატურად ყოველ გამოქვეყნებაზე.
- სუპერმომხმარებელი ავტომატურად იქმნება მხოლოდ პირველ განთავსებაზე.
- სტატიკურ ფაილებს ემსახურება WhiteNoise.
- მონაცემთა ბაზა გადადის SQLite-დან PostgreSQL-ზე production გარემოში, კოდის ცვლილების გარეშე.
- სენსიტიური მონაცემები, როგორიცაა საიდუმლო გასაღები და debug ის მნიშვნელობა, იკითხება გარემოს ცვლადებიდან.
- HTTPS მუშაობს სწორად, Render-ის პროქსის უკან.
სულ ეგ არის. თუ რაიმე ისე არ გამოვიდა, როგორც გინდოდათ, მომწერეთ. გისურვებთ წარმატებებს.
ავტორის შესახებ
გიგი ჩაკაბერია
back-end დეველოპერი და მენტორი