როგორ დავჰოსტოთ Django ვებსაიტი?

როგორ გამოვაქვეყნოთ Python/Django-თი შექმნილი საიტი უფასოდ? უბრალოდ მიჰყევით ამ გზამკვლევს.

By გიგი ჩაკაბერია
როგორ დავჰოსტოთ 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.sh

Start 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 დეველოპერი და მენტორი