വർക്ക്ഷോപ്പ് RHEL 8 ബീറ്റ: പ്രവർത്തിക്കുന്ന വെബ് ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നു

RHEL 8 ബീറ്റ ഡെവലപ്പർമാർക്ക് നിരവധി പുതിയ ഫീച്ചറുകൾ വാഗ്ദാനം ചെയ്യുന്നു, ഇവയുടെ ലിസ്റ്റിംഗ് പേജുകൾ എടുക്കാം, എന്നിരുന്നാലും, പുതിയ കാര്യങ്ങൾ പഠിക്കുന്നത് പ്രായോഗികമായി എല്ലായ്പ്പോഴും മികച്ചതാണ്, അതിനാൽ Red Hat Enterprise Linux 8 ബീറ്റയെ അടിസ്ഥാനമാക്കി യഥാർത്ഥത്തിൽ ഒരു ആപ്ലിക്കേഷൻ ഇൻഫ്രാസ്ട്രക്ചർ സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു വർക്ക്ഷോപ്പ് ഞങ്ങൾ ചുവടെ നൽകുന്നു.

ഡെവലപ്പർമാർക്കിടയിൽ ഒരു ജനപ്രിയ പ്രോഗ്രാമിംഗ് ഭാഷയായ പൈത്തൺ ഒരു അടിസ്ഥാനമായി എടുക്കാം, ആപ്ലിക്കേഷനുകൾ സൃഷ്ടിക്കുന്നതിനുള്ള വളരെ സാധാരണമായ സംയോജനമായ ജാങ്കോയുടെയും PostgreSQL-ന്റെയും സംയോജനം, കൂടാതെ അവരുമായി പ്രവർത്തിക്കാൻ RHEL 8 ബീറ്റ കോൺഫിഗർ ചെയ്യുക. തുടർന്ന് ഞങ്ങൾ കുറച്ച് കൂടി (വർഗ്ഗീകരിക്കാത്ത) ചേരുവകൾ ചേർക്കും.

ടെസ്റ്റ് പരിതസ്ഥിതി മാറും, കാരണം ഓട്ടോമേഷന്റെ സാധ്യതകൾ പര്യവേക്ഷണം ചെയ്യുന്നത് രസകരമാണ്, കണ്ടെയ്നറുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കുക, ഒന്നിലധികം സെർവറുകളുള്ള പരിതസ്ഥിതികൾ പരീക്ഷിക്കുക. ഒരു പുതിയ പ്രോജക്റ്റ് ആരംഭിക്കുന്നതിന്, നിങ്ങൾക്ക് കൈകൊണ്ട് ചെറുതും ലളിതവുമായ ഒരു പ്രോട്ടോടൈപ്പ് സൃഷ്ടിച്ചുകൊണ്ട് ആരംഭിക്കാം, അതിലൂടെ എന്താണ് സംഭവിക്കേണ്ടതെന്നും അത് എങ്ങനെ ഇടപെടുന്നുവെന്നും നിങ്ങൾക്ക് കൃത്യമായി കാണാനാകും, തുടർന്ന് ഓട്ടോമേറ്റ് ചെയ്യാനും കൂടുതൽ സങ്കീർണ്ണമായ കോൺഫിഗറേഷനുകൾ സൃഷ്ടിക്കാനും കഴിയും. അത്തരമൊരു പ്രോട്ടോടൈപ്പിന്റെ സൃഷ്ടിയെക്കുറിച്ചാണ് ഇന്ന് നമ്മൾ സംസാരിക്കുന്നത്.

RHEL 8 ബീറ്റ VM ഇമേജ് വിന്യസിച്ചുകൊണ്ട് നമുക്ക് ആരംഭിക്കാം. നിങ്ങൾക്ക് ആദ്യം മുതൽ ഒരു വെർച്വൽ മെഷീൻ ഇൻസ്റ്റാൾ ചെയ്യാം, അല്ലെങ്കിൽ നിങ്ങളുടെ ബീറ്റ സബ്‌സ്‌ക്രിപ്‌ഷനിൽ ലഭ്യമായ കെവിഎം ഗസ്റ്റ് ഇമേജ് ഉപയോഗിക്കുക. ഒരു ഗസ്റ്റ് ഇമേജ് ഉപയോഗിക്കുമ്പോൾ, ക്ലൗഡ് ഇനീഷ്യലൈസേഷനായി (Cloud-init) മെറ്റാഡാറ്റയും ഉപയോക്തൃ ഡാറ്റയും അടങ്ങിയിരിക്കുന്ന ഒരു വെർച്വൽ സിഡി നിങ്ങൾ കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്. ഡിസ്ക് ഘടനയോ ലഭ്യമായ പാക്കേജുകളോ ഉപയോഗിച്ച് നിങ്ങൾ പ്രത്യേകമായി ഒന്നും ചെയ്യേണ്ടതില്ല; ഏത് കോൺഫിഗറേഷനും ചെയ്യും.

മുഴുവൻ പ്രക്രിയയും നമുക്ക് സൂക്ഷ്മമായി പരിശോധിക്കാം.

ജാങ്കോ ഇൻസ്റ്റാൾ ചെയ്യുന്നു

ജാംഗോയുടെ ഏറ്റവും പുതിയ പതിപ്പിൽ, നിങ്ങൾക്ക് പൈത്തൺ 3.5 അല്ലെങ്കിൽ അതിന് ശേഷമുള്ള ഒരു വെർച്വൽ എൻവയോൺമെന്റ് (virtualenv) ആവശ്യമാണ്. ബീറ്റ കുറിപ്പുകളിൽ, പൈത്തൺ 3.6 ലഭ്യമാണെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും, ഇത് ശരിക്കും അങ്ങനെയാണോ എന്ന് പരിശോധിക്കാം:

[cloud-user@8beta1 ~]$ python
-bash: python: command not found
[cloud-user@8beta1 ~]$ python3
-bash: python3: command not found

RHEL-ൽ ഒരു സിസ്റ്റം ടൂൾകിറ്റായി Red Hat പൈത്തൺ സജീവമായി ഉപയോഗിക്കുന്നു, എന്തുകൊണ്ടാണ് ഇത് സംഭവിക്കുന്നത്?

പല പൈത്തൺ ഡെവലപ്പർമാരും ഇപ്പോഴും പൈത്തൺ 2 ൽ നിന്ന് പൈത്തൺ 2 ലേക്ക് മാറുന്നതിനെക്കുറിച്ച് ആലോചിക്കുന്നുണ്ട് എന്നതാണ് വസ്തുത, അതേസമയം പൈത്തൺ 3 തന്നെ സജീവമായ വികസനത്തിലാണ്, കൂടാതെ കൂടുതൽ കൂടുതൽ പുതിയ പതിപ്പുകൾ നിരന്തരം പ്രത്യക്ഷപ്പെടുന്നു. അതിനാൽ, പൈത്തണിന്റെ വിവിധ പുതിയ പതിപ്പുകളിലേക്ക് ഉപയോക്താക്കൾക്ക് ആക്സസ് നൽകുമ്പോൾ സ്ഥിരതയുള്ള സിസ്റ്റം ടൂളുകളുടെ ആവശ്യകത നിറവേറ്റുന്നതിനായി, സിസ്റ്റം പൈത്തൺ ഒരു പുതിയ പാക്കേജിലേക്ക് മാറ്റുകയും പൈത്തൺ 2.7, 3.6 എന്നിവ ഇൻസ്റ്റാൾ ചെയ്യാനുള്ള കഴിവ് നൽകുകയും ചെയ്തു. മാറ്റങ്ങളെക്കുറിച്ചും അവ എന്തുകൊണ്ടാണ് വരുത്തിയതെന്നതിനെക്കുറിച്ചും കൂടുതൽ വിവരങ്ങൾ പ്രസിദ്ധീകരണത്തിൽ കാണാം ലാംഗ്ഡൺ വൈറ്റിന്റെ ബ്ലോഗ് (ലാങ്ഡൺ വൈറ്റ്).

അതിനാൽ, പ്രവർത്തിക്കുന്ന പൈത്തൺ ലഭിക്കുന്നതിന്, നിങ്ങൾ രണ്ട് പാക്കേജുകൾ ഇൻസ്റ്റാൾ ചെയ്താൽ മതി, പൈത്തൺ3-പിപ്പ് ഒരു ഡിപൻഡൻസിയായി ഉൾപ്പെടുത്തിയിട്ടുണ്ട്.

sudo yum install python36 python3-virtualenv

ലാംഗ്‌ഡൺ നിർദ്ദേശിക്കുന്നതുപോലെ നേരിട്ടുള്ള മൊഡ്യൂൾ കോളുകൾ ഉപയോഗിക്കുകയും pip3 ഇൻസ്റ്റാൾ ചെയ്യുകയും ചെയ്യേണ്ടത് എന്തുകൊണ്ട്? വരാനിരിക്കുന്ന ഓട്ടോമേഷൻ മനസ്സിൽ വെച്ചുകൊണ്ട്, ഒരു ഇഷ്‌ടാനുസൃത പൈപ്പ് എക്‌സിക്യൂട്ടബിൾ ഉള്ള virtualenvs-നെ പിപ്പ് മൊഡ്യൂൾ പിന്തുണയ്‌ക്കാത്തതിനാൽ, പ്രവർത്തിപ്പിക്കുന്നതിന് അൻസിബിളിന് പൈപ്പ് ഇൻസ്റ്റാൾ ചെയ്യേണ്ടതായി വരുമെന്ന് അറിയാം.

നിങ്ങളുടെ പക്കലുള്ള ഒരു പ്രവർത്തിക്കുന്ന python3 വ്യാഖ്യാതാവ് ഉപയോഗിച്ച്, നിങ്ങൾക്ക് ജാങ്കോ ഇൻസ്റ്റാളേഷൻ പ്രക്രിയയിൽ തുടരാനും ഞങ്ങളുടെ മറ്റ് ഘടകങ്ങൾക്കൊപ്പം ഒരു വർക്കിംഗ് സിസ്റ്റം ഉണ്ടായിരിക്കാനും കഴിയും. ഇന്റർനെറ്റിൽ നിരവധി നടപ്പിലാക്കൽ ഓപ്ഷനുകൾ ലഭ്യമാണ്. ഇവിടെ ഒരു പതിപ്പ് അവതരിപ്പിച്ചിട്ടുണ്ട്, എന്നാൽ ഉപയോക്താക്കൾക്ക് അവരുടെ സ്വന്തം പ്രോസസ്സുകൾ ഉപയോഗിക്കാൻ കഴിയും.

Yum ഉപയോഗിച്ച് സ്ഥിരസ്ഥിതിയായി RHEL 8-ൽ ലഭ്യമായ PostgreSQL, Nginx പതിപ്പുകൾ ഞങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യും.

sudo yum install nginx postgresql-server

PostgreSQL-ന് psycopg2 ആവശ്യമായി വരും, പക്ഷേ ഇത് ഒരു virtualenv പരിതസ്ഥിതിയിൽ മാത്രമേ ലഭ്യമാകൂ, അതിനാൽ Django, Gunicorn എന്നിവയ്‌ക്കൊപ്പം pip3 ഉപയോഗിച്ച് ഞങ്ങൾ ഇത് ഇൻസ്റ്റാൾ ചെയ്യും. എന്നാൽ ആദ്യം നമ്മൾ virtualenv സജ്ജീകരിക്കേണ്ടതുണ്ട്.

ജാംഗോ പ്രോജക്റ്റുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നതിനുള്ള ശരിയായ സ്ഥലം തിരഞ്ഞെടുക്കുന്ന വിഷയത്തിൽ എല്ലായ്പ്പോഴും ധാരാളം ചർച്ചകൾ നടക്കുന്നുണ്ട്, എന്നാൽ സംശയമുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും Linux ഫയൽസിസ്റ്റം ഹൈരാർക്കി സ്റ്റാൻഡേർഡിലേക്ക് തിരിയാം. പ്രത്യേകമായി, FHS പറയുന്നു: "ഹോസ്റ്റ്-നിർദ്ദിഷ്‌ട ഡാറ്റ സംഭരിക്കാൻ-സിസ്റ്റം നിർമ്മിക്കുന്ന ഡാറ്റ, വെബ് സെർവർ ഡാറ്റ, സ്‌ക്രിപ്റ്റുകൾ, FTP സെർവറുകളിൽ സംഭരിച്ചിരിക്കുന്ന ഡാറ്റ, സിസ്റ്റം റിപ്പോസിറ്ററികൾ എന്നിവ നിയന്ത്രിക്കുക." പതിപ്പുകൾ (FHS-ൽ ദൃശ്യമാകുന്നു. -2.3 ൽ 2004)."

ഇത് ഞങ്ങളുടെ കാര്യമാണ്, അതിനാൽ ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ ഉപയോക്താവിന്റെ (ക്ലൗഡ്-ഉപയോക്താവിന്റെ) ഉടമസ്ഥതയിലുള്ള / srv-യിൽ ഞങ്ങൾ ആവശ്യമുള്ളതെല്ലാം ഇട്ടു.

sudo mkdir /srv/djangoapp
sudo chown cloud-user:cloud-user /srv/djangoapp
cd /srv/djangoapp
virtualenv django
source django/bin/activate
pip3 install django gunicorn psycopg2
./django-admin startproject djangoapp /srv/djangoapp

PostgreSQL, Django എന്നിവ സജ്ജീകരിക്കുന്നത് എളുപ്പമാണ്: ഒരു ഡാറ്റാബേസ് സൃഷ്‌ടിക്കുക, ഒരു ഉപയോക്താവിനെ സൃഷ്‌ടിക്കുക, അനുമതികൾ ക്രമീകരിക്കുക. ആദ്യം PostgreSQL ഇൻസ്റ്റാൾ ചെയ്യുമ്പോൾ ശ്രദ്ധിക്കേണ്ട ഒരു കാര്യം postgresql-സെർവർ പാക്കേജിനൊപ്പം ഇൻസ്റ്റാൾ ചെയ്ത postgresql-സെറ്റപ്പ് സ്ക്രിപ്റ്റാണ്. ക്ലസ്റ്റർ ഇനീഷ്യലൈസേഷൻ അല്ലെങ്കിൽ അപ്‌ഗ്രേഡ് പ്രോസസ്സ് പോലുള്ള ഡാറ്റാബേസ് ക്ലസ്റ്റർ അഡ്മിനിസ്ട്രേഷനുമായി ബന്ധപ്പെട്ട അടിസ്ഥാന ജോലികൾ ചെയ്യാൻ ഈ സ്ക്രിപ്റ്റ് നിങ്ങളെ സഹായിക്കുന്നു. ഒരു RHEL സിസ്റ്റത്തിൽ ഒരു പുതിയ PostgreSQL ഇൻസ്റ്റൻസ് കോൺഫിഗർ ചെയ്യുന്നതിന്, ഞങ്ങൾ കമാൻഡ് പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട്:

sudo /usr/bin/postgresql-setup -initdb

നിങ്ങൾക്ക് systemd ഉപയോഗിച്ച് PostgreSQL ആരംഭിക്കാനും ഒരു ഡാറ്റാബേസ് സൃഷ്ടിക്കാനും ജാങ്കോയിൽ ഒരു പ്രോജക്റ്റ് സജ്ജീകരിക്കാനും കഴിയും. ആപ്ലിക്കേഷൻ ഉപയോക്താവിനായി പാസ്‌വേഡ് സംഭരണം കോൺഫിഗർ ചെയ്യുന്നതിന് ക്ലയന്റ് ആധികാരികത കോൺഫിഗറേഷൻ ഫയലിൽ (സാധാരണയായി pg_hba.conf) മാറ്റങ്ങൾ വരുത്തിയ ശേഷം PostgreSQL പുനരാരംഭിക്കാൻ ഓർമ്മിക്കുക. നിങ്ങൾക്ക് മറ്റ് ബുദ്ധിമുട്ടുകൾ നേരിടുകയാണെങ്കിൽ, pg_hba.conf ഫയലിലെ IPv4, IPv6 ക്രമീകരണങ്ങൾ മാറ്റുന്നത് ഉറപ്പാക്കുക.

systemctl enable -now postgresql

sudo -u postgres psql
postgres=# create database djangoapp;
postgres=# create user djangouser with password 'qwer4321';
postgres=# alter role djangouser set client_encoding to 'utf8';
postgres=# alter role djangouser set default_transaction_isolation to 'read committed';
postgres=# alter role djangouser set timezone to 'utc';
postgres=# grant all on DATABASE djangoapp to djangouser;
postgres=# q

ഫയലിൽ /var/lib/pgsql/data/pg_hba.conf:

# IPv4 local connections:
host    all        all 0.0.0.0/0                md5
# IPv6 local connections:
host    all        all ::1/128                 md5

ഫയലിൽ /srv/djangoapp/settings.py:

# Database
DATABASES = {
   'default': {
       'ENGINE': 'django.db.backends.postgresql_psycopg2',
       'NAME': '{{ db_name }}',
       'USER': '{{ db_user }}',
       'PASSWORD': '{{ db_password }}',
       'HOST': '{{ db_host }}',
   }
}

പ്രൊജക്റ്റിലെ settings.py ഫയൽ കോൺഫിഗർ ചെയ്‌ത് ഡാറ്റാബേസ് കോൺഫിഗറേഷൻ സജ്ജീകരിച്ച ശേഷം, എല്ലാം പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കാൻ നിങ്ങൾക്ക് ഡെവലപ്‌മെന്റ് സെർവർ ആരംഭിക്കാം. ഡെവലപ്‌മെന്റ് സെർവർ ആരംഭിച്ചതിന് ശേഷം, ഡാറ്റാബേസിലേക്കുള്ള കണക്ഷൻ പരിശോധിക്കുന്നതിന് ഒരു അഡ്മിൻ ഉപയോക്താവിനെ സൃഷ്ടിക്കുന്നത് നല്ലതാണ്.

./manage.py runserver 0.0.0.0:8000
./manage.py createsuperuser

WSGI? വായ്?

ഡെവലപ്‌മെന്റ് സെർവർ ടെസ്റ്റിംഗിന് ഉപയോഗപ്രദമാണ്, എന്നാൽ ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കുന്നതിന് നിങ്ങൾ വെബ് സെർവർ ഗേറ്റ്‌വേ ഇന്റർഫേസിനായി (WSGI) ഉചിതമായ സെർവറും പ്രോക്സിയും കോൺഫിഗർ ചെയ്യണം. നിരവധി പൊതുവായ കോമ്പിനേഷനുകൾ ഉണ്ട്, ഉദാഹരണത്തിന്, uWSGI ഉള്ള Apache HTTPD അല്ലെങ്കിൽ Gunicorn ഉള്ള Nginx.

വെബ് സെർവറിൽ നിന്നുള്ള അഭ്യർത്ഥനകൾ പൈത്തൺ വെബ് ഫ്രെയിംവർക്കിലേക്ക് കൈമാറുക എന്നതാണ് വെബ് സെർവർ ഗേറ്റ്‌വേ ഇന്റർഫേസിന്റെ ജോലി. CGI എഞ്ചിനുകൾ ഉണ്ടായിരുന്ന കാലത്തെ ഭയാനകമായ ഭൂതകാലത്തിന്റെ അവശിഷ്ടമാണ് WSGI, വെബ് സെർവറോ പൈത്തൺ ചട്ടക്കൂടോ പരിഗണിക്കാതെ തന്നെ ഇന്ന് WSGI യഥാർത്ഥ നിലവാരമാണ്. എന്നാൽ വ്യാപകമായ ഉപയോഗം ഉണ്ടായിരുന്നിട്ടും, ഈ ചട്ടക്കൂടുകൾക്കൊപ്പം പ്രവർത്തിക്കുമ്പോൾ നിരവധി സൂക്ഷ്മതകളും നിരവധി തിരഞ്ഞെടുപ്പുകളും ഉണ്ട്. ഈ സാഹചര്യത്തിൽ, ഒരു സോക്കറ്റ് വഴി Gunicorn ഉം Nginx ഉം തമ്മിലുള്ള ആശയവിനിമയം സ്ഥാപിക്കാൻ ഞങ്ങൾ ശ്രമിക്കും.

ഈ രണ്ട് ഘടകങ്ങളും ഒരേ സെർവറിൽ ഇൻസ്റ്റാൾ ചെയ്തിരിക്കുന്നതിനാൽ, നെറ്റ്‌വർക്ക് സോക്കറ്റിന് പകരം UNIX സോക്കറ്റ് ഉപയോഗിക്കാൻ ശ്രമിക്കാം. ആശയവിനിമയത്തിന് ഒരു സോക്കറ്റ് ആവശ്യമുള്ളതിനാൽ, നമുക്ക് ഒരു ഘട്ടം കൂടി എടുത്ത് systemd വഴി Gunicorn-നായി സോക്കറ്റ് ആക്റ്റിവേഷൻ ക്രമീകരിക്കാൻ ശ്രമിക്കാം.

സോക്കറ്റ് സജീവമാക്കിയ സേവനങ്ങൾ സൃഷ്ടിക്കുന്ന പ്രക്രിയ വളരെ ലളിതമാണ്. ആദ്യം, UNIX സോക്കറ്റ് സൃഷ്‌ടിക്കുന്ന പോയിന്റിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്ന ഒരു ListenStream ഡയറക്‌ടീവ് അടങ്ങിയിരിക്കുന്ന ഒരു യൂണിറ്റ് ഫയൽ സൃഷ്‌ടിക്കുന്നു, തുടർന്ന് ആവശ്യമുള്ള നിർദ്ദേശം സോക്കറ്റ് യൂണിറ്റ് ഫയലിലേക്ക് പോയിന്റ് ചെയ്യുന്ന സേവനത്തിനുള്ള യൂണിറ്റ് ഫയൽ. തുടർന്ന്, സർവീസ് യൂണിറ്റ് ഫയലിൽ, വെർച്വൽ എൻവയോൺമെന്റിൽ നിന്ന് Gunicorn-നെ വിളിച്ച് UNIX സോക്കറ്റിനും Django ആപ്ലിക്കേഷനും ഒരു WSGI ബൈൻഡിംഗ് സൃഷ്ടിക്കുക മാത്രമാണ് അവശേഷിക്കുന്നത്.

നിങ്ങൾക്ക് അടിസ്ഥാനമായി ഉപയോഗിക്കാവുന്ന യൂണിറ്റ് ഫയലുകളുടെ ചില ഉദാഹരണങ്ങൾ ഇതാ. ആദ്യം ഞങ്ങൾ സോക്കറ്റ് സജ്ജമാക്കി.

[Unit]
Description=Gunicorn WSGI socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

ഇപ്പോൾ നിങ്ങൾ Gunicorn ഡെമൺ കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്.

[Unit]
Description=Gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=cloud-user
Group=cloud-user
WorkingDirectory=/srv/djangoapp

ExecStart=/srv/djangoapp/django/bin/gunicorn 
         —access-logfile - 
         —workers 3 
         —bind unix:gunicorn.sock djangoapp.wsgi

[Install]
WantedBy=multi-user.target

Nginx-നെ സംബന്ധിച്ചിടത്തോളം, പ്രോക്‌സി കോൺഫിഗറേഷൻ ഫയലുകൾ സൃഷ്‌ടിക്കുകയും നിങ്ങൾ ഒരെണ്ണം ഉപയോഗിക്കുകയാണെങ്കിൽ സ്റ്റാറ്റിക് ഉള്ളടക്കം സംഭരിക്കുന്നതിന് ഒരു ഡയറക്‌ടറി സജ്ജീകരിക്കുകയും ചെയ്യുക എന്നത് ഒരു ലളിതമായ കാര്യമാണ്. RHEL-ൽ, Nginx കോൺഫിഗറേഷൻ ഫയലുകൾ /etc/nginx/conf.d-ൽ സ്ഥിതി ചെയ്യുന്നു. നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന ഉദാഹരണം /etc/nginx/conf.d/default.conf ഫയലിലേക്ക് പകർത്തി സേവനം ആരംഭിക്കാം. നിങ്ങളുടെ ഹോസ്റ്റ് നാമവുമായി പൊരുത്തപ്പെടുന്നതിന് server_name സജ്ജമാക്കുന്നത് ഉറപ്പാക്കുക.

server {
   listen 80;
   server_name 8beta1.example.com;

   location = /favicon.ico { access_log off; log_not_found off; }
   location /static/ {
       root /srv/djangoapp;
   }

   location / {
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_pass http://unix:/run/gunicorn.sock;
   }
}

systemd ഉപയോഗിച്ച് Gunicorn സോക്കറ്റും Nginx ഉം ആരംഭിക്കുക, നിങ്ങൾ പരീക്ഷണം ആരംഭിക്കാൻ തയ്യാറാണ്.

മോശം ഗേറ്റ്‌വേ പിശക്?

നിങ്ങളുടെ ബ്രൗസറിൽ വിലാസം നൽകിയാൽ, നിങ്ങൾക്ക് മിക്കവാറും 502 ബാഡ് ഗേറ്റ്‌വേ പിശക് ലഭിക്കും. തെറ്റായി കോൺഫിഗർ ചെയ്‌ത UNIX സോക്കറ്റ് അനുമതികൾ മൂലമാകാം, അല്ലെങ്കിൽ SELinux-ലെ ആക്‌സസ്സ് നിയന്ത്രണവുമായി ബന്ധപ്പെട്ട കൂടുതൽ സങ്കീർണമായ പ്രശ്‌നങ്ങൾ മൂലമാകാം.

nginx പിശക് ലോഗിൽ നിങ്ങൾക്ക് ഇതുപോലുള്ള ഒരു ലൈൻ കാണാം:

2018/12/18 15:38:03 [crit] 12734#0: *3 connect() to unix:/run/gunicorn.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.122.1, server: 8beta1.example.com, request: "GET / HTTP/1.1", upstream: "http://unix:/run/gunicorn.sock:/", host: "8beta1.example.com"

Gunicorn നെ നേരിട്ട് ടെസ്റ്റ് ചെയ്താൽ ഒരു പൊള്ളത്തരം കിട്ടും.

curl —unix-socket /run/gunicorn.sock 8beta1.example.com

എന്തുകൊണ്ടാണ് ഇത് സംഭവിക്കുന്നതെന്ന് നമുക്ക് കണ്ടെത്താം. നിങ്ങൾ ലോഗ് തുറക്കുകയാണെങ്കിൽ, പ്രശ്നം SELinux-മായി ബന്ധപ്പെട്ടതാണെന്ന് നിങ്ങൾ കാണും. നയങ്ങളൊന്നും സൃഷ്‌ടിച്ചിട്ടില്ലാത്ത ഒരു ഡെമൺ ഞങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നതിനാൽ, അത് init_t എന്ന് അടയാളപ്പെടുത്തിയിരിക്കുന്നു. ഈ സിദ്ധാന്തം പ്രായോഗികമായി പരിശോധിക്കാം.

sudo setenforce 0

ഇതെല്ലാം വിമർശനത്തിനും രക്തക്കണ്ണീർക്കും കാരണമായേക്കാം, പക്ഷേ ഇത് പ്രോട്ടോടൈപ്പ് ഡീബഗ്ഗിംഗ് മാത്രമാണ്. ഇതാണ് പ്രശ്‌നം എന്ന് ഉറപ്പാക്കാൻ നമുക്ക് പരിശോധന പ്രവർത്തനരഹിതമാക്കാം, അതിനുശേഷം ഞങ്ങൾ എല്ലാം അതിന്റെ സ്ഥാനത്തേക്ക് തിരികെ നൽകും.

ബ്രൗസറിൽ പേജ് പുതുക്കുന്നതിലൂടെയോ ഞങ്ങളുടെ curl കമാൻഡ് വീണ്ടും പ്രവർത്തിപ്പിക്കുന്നതിലൂടെയോ നിങ്ങൾക്ക് Django ടെസ്റ്റ് പേജ് കാണാൻ കഴിയും.

അതിനാൽ, എല്ലാം പ്രവർത്തിക്കുന്നുണ്ടെന്നും കൂടുതൽ അനുമതി പ്രശ്‌നങ്ങളൊന്നുമില്ലെന്നും ഉറപ്പുവരുത്തിയ ശേഷം, ഞങ്ങൾ SELinux വീണ്ടും പ്രവർത്തനക്ഷമമാക്കുന്നു.

sudo setenforce 1

audit2allow അല്ലെങ്കിൽ sepolgen ഉപയോഗിച്ച് അലേർട്ട് അടിസ്ഥാനമാക്കിയുള്ള നയങ്ങൾ സൃഷ്ടിക്കുന്നതിനെ കുറിച്ച് ഞാൻ ഇവിടെ സംസാരിക്കില്ല, കാരണം ഇപ്പോൾ യഥാർത്ഥ ജാംഗോ ആപ്ലിക്കേഷൻ ഒന്നുമില്ല, അതിനാൽ Gunicorn ആക്‌സസ് ചെയ്യാൻ ആഗ്രഹിക്കുന്നതിന്റെയും ആക്‌സസ് നിരസിക്കേണ്ടതിന്റെയും പൂർണ്ണമായ മാപ്പ് ഒന്നുമില്ല. അതിനാൽ, സിസ്റ്റം പരിരക്ഷിക്കുന്നതിനായി SELinux പ്രവർത്തിപ്പിക്കേണ്ടത് ആവശ്യമാണ്, അതേ സമയം ഓഡിറ്റ് ലോഗിൽ സന്ദേശങ്ങൾ പ്രവർത്തിപ്പിക്കാനും അവയിൽ നിന്ന് യഥാർത്ഥ നയം സൃഷ്ടിക്കാനും ആപ്ലിക്കേഷനെ അനുവദിക്കുകയും ചെയ്യുന്നു.

അനുവദനീയമായ ഡൊമെയ്‌നുകൾ വ്യക്തമാക്കുന്നു

SELinux-ൽ അനുവദനീയമായ ഡൊമെയ്‌നുകളെ കുറിച്ച് എല്ലാവരും കേട്ടിട്ടുണ്ടാവില്ല, എന്നാൽ അവ പുതിയതല്ല. പലരും അറിയാതെ അവരോടൊപ്പം പ്രവർത്തിച്ചു. ഓഡിറ്റ് സന്ദേശങ്ങളെ അടിസ്ഥാനമാക്കി ഒരു നയം സൃഷ്ടിക്കുമ്പോൾ, സൃഷ്ടിച്ച നയം പരിഹരിച്ച ഡൊമെയ്‌നെ പ്രതിനിധീകരിക്കുന്നു. ലളിതമായ ഒരു പെർമിറ്റിംഗ് പോളിസി ഉണ്ടാക്കാൻ ശ്രമിക്കാം.

Gunicorn-നായി അനുവദനീയമായ ഒരു പ്രത്യേക ഡൊമെയ്‌ൻ സൃഷ്‌ടിക്കുന്നതിന്, നിങ്ങൾക്ക് ഒരു തരത്തിലുള്ള നയം ആവശ്യമാണ്, കൂടാതെ നിങ്ങൾ ഉചിതമായ ഫയലുകൾ അടയാളപ്പെടുത്തുകയും വേണം. കൂടാതെ, പുതിയ പോളിസികൾ കൂട്ടിച്ചേർക്കാൻ ടൂളുകൾ ആവശ്യമാണ്.

sudo yum install selinux-policy-devel

അനുവദനീയമായ ഡൊമെയ്‌നുകളുടെ സംവിധാനം പ്രശ്‌നങ്ങൾ തിരിച്ചറിയുന്നതിനുള്ള ഒരു മികച്ച ഉപകരണമാണ്, പ്രത്യേകിച്ചും ഒരു ഇഷ്‌ടാനുസൃത അപ്ലിക്കേഷനോ അല്ലെങ്കിൽ ഇതിനകം സൃഷ്‌ടിച്ച നയങ്ങളില്ലാതെ ഷിപ്പുചെയ്യുന്ന അപ്ലിക്കേഷനുകളോ വരുമ്പോൾ. ഈ സാഹചര്യത്തിൽ, Gunicorn-നുള്ള അനുവദനീയമായ ഡൊമെയ്ൻ നയം കഴിയുന്നത്ര ലളിതമായിരിക്കും - ഒരു പ്രധാന തരം (gunicorn_t) പ്രഖ്യാപിക്കുക, ഒന്നിലധികം എക്സിക്യൂട്ടബിളുകൾ (gunicorn_exec_t) അടയാളപ്പെടുത്താൻ ഞങ്ങൾ ഉപയോഗിക്കുന്ന ഒരു തരം പ്രഖ്യാപിക്കുക, തുടർന്ന് ശരിയായി അടയാളപ്പെടുത്തുന്നതിന് സിസ്റ്റത്തിനായി ഒരു പരിവർത്തനം സജ്ജമാക്കുക. പ്രവർത്തിക്കുന്ന പ്രക്രിയകൾ. ലോഡുചെയ്യുന്ന സമയത്ത് ഡിഫോൾട്ടായി നയം പ്രവർത്തനക്ഷമമാക്കിയതായി അവസാന വരി സജ്ജീകരിക്കുന്നു.

gunicorn.te:

policy_module(gunicorn, 1.0)

type gunicorn_t;
type gunicorn_exec_t;
init_daemon_domain(gunicorn_t, gunicorn_exec_t)
permissive gunicorn_t;

നിങ്ങൾക്ക് ഈ പോളിസി ഫയൽ സമാഹരിച്ച് നിങ്ങളുടെ സിസ്റ്റത്തിലേക്ക് ചേർക്കാം.

make -f /usr/share/selinux/devel/Makefile
sudo semodule -i gunicorn.pp

sudo semanage permissive -a gunicorn_t
sudo semodule -l | grep permissive

നമ്മുടെ അജ്ഞാത ഡെമൺ ആക്‌സസ് ചെയ്യുന്നതല്ലാതെ മറ്റെന്തെങ്കിലും SELinux തടയുന്നുണ്ടോയെന്ന് പരിശോധിക്കാം.

sudo ausearch -m AVC

type=AVC msg=audit(1545315977.237:1273): avc:  denied { write } for pid=19400 comm="nginx" name="gunicorn.sock" dev="tmpfs" ino=52977 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=0

Gunicorn ഉപയോഗിക്കുന്ന UNIX സോക്കറ്റിലേക്ക് ഡാറ്റ എഴുതുന്നതിൽ നിന്ന് Nginx-നെ SELinux തടയുന്നു. സാധാരണഗതിയിൽ, അത്തരം സന്ദർഭങ്ങളിൽ, നയങ്ങൾ മാറാൻ തുടങ്ങുന്നു, എന്നാൽ മറ്റ് വെല്ലുവിളികൾ മുന്നിലുണ്ട്. നിങ്ങൾക്ക് ഒരു നിയന്ത്രണ ഡൊമെയ്‌നിൽ നിന്ന് ഒരു അനുമതി ഡൊമെയ്‌നിലേക്ക് ഡൊമെയ്‌ൻ ക്രമീകരണങ്ങൾ മാറ്റാനും കഴിയും. ഇനി നമുക്ക് httpd_t അനുമതി ഡൊമെയ്‌നിലേക്ക് മാറ്റാം. ഇത് Nginx-ന് ആവശ്യമായ ആക്‌സസ് നൽകും, ഞങ്ങൾക്ക് കൂടുതൽ ഡീബഗ്ഗിംഗ് ജോലികൾ തുടരാം.

sudo semanage permissive -a httpd_t

അതിനാൽ, നിങ്ങൾ SELinux പരിരക്ഷിതമായി നിലനിർത്താൻ കഴിഞ്ഞാൽ (നിങ്ങൾ ഒരു SELinux പ്രോജക്റ്റ് നിയന്ത്രിത മോഡിൽ ഉപേക്ഷിക്കരുത്) അനുമതി ഡൊമെയ്‌നുകൾ ലോഡുചെയ്‌തുകഴിഞ്ഞാൽ, എല്ലാം ശരിയായി പ്രവർത്തിക്കുന്നതിന് gunicorn_exec_t എന്ന് കൃത്യമായി അടയാളപ്പെടുത്തേണ്ടത് എന്താണെന്ന് നിങ്ങൾ കണ്ടെത്തേണ്ടതുണ്ട്. വീണ്ടും. ആക്സസ് നിയന്ത്രണങ്ങളെക്കുറിച്ചുള്ള പുതിയ സന്ദേശങ്ങൾ കാണുന്നതിന് വെബ്സൈറ്റ് സന്ദർശിക്കാൻ ശ്രമിക്കാം.

sudo ausearch -m AVC -c gunicorn

/srv/djangoapp-ലെ ഫയലുകളിൽ വിവിധ കാര്യങ്ങൾ ചെയ്യുന്ന 'comm="gunicorn" അടങ്ങിയ ധാരാളം സന്ദേശങ്ങൾ നിങ്ങൾ കാണും, അതിനാൽ ഇത് വ്യക്തമായും ഫ്ലാഗുചെയ്യേണ്ട കമാൻഡുകളിൽ ഒന്നാണ്.

എന്നാൽ ഇതുകൂടാതെ, ഇതുപോലുള്ള ഒരു സന്ദേശം ദൃശ്യമാകുന്നു:

type=AVC msg=audit(1545320700.070:1542): avc:  denied { execute } for pid=20704 comm="(gunicorn)" name="python3.6" dev="vda3" ino=8515706 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file permissive=0

നിങ്ങൾ gunicorn സേവനത്തിന്റെ സ്റ്റാറ്റസ് നോക്കുകയോ ps കമാൻഡ് പ്രവർത്തിപ്പിക്കുകയോ ചെയ്താൽ, പ്രവർത്തിക്കുന്ന പ്രക്രിയകളൊന്നും നിങ്ങൾ കാണില്ല. ഞങ്ങളുടെ virtualenv പരിതസ്ഥിതിയിൽ Gunicorn പൈത്തൺ ഇന്റർപ്രെറ്റർ ആക്‌സസ് ചെയ്യാൻ ശ്രമിക്കുന്നതായി തോന്നുന്നു, ഒരുപക്ഷേ വർക്കർ സ്‌ക്രിപ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന്. അതിനാൽ ഇപ്പോൾ നമുക്ക് ഈ രണ്ട് എക്സിക്യൂട്ടബിൾ ഫയലുകൾ അടയാളപ്പെടുത്തുകയും ഞങ്ങളുടെ ജാങ്കോ ടെസ്റ്റ് പേജ് തുറക്കാൻ കഴിയുമോ എന്ന് പരിശോധിക്കുകയും ചെയ്യാം.

chcon -t gunicorn_exec_t /srv/djangoapp/django/bin/gunicorn /srv/djangoapp/django/bin/python3.6

പുതിയ ടാഗ് തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് ഗണികോൺ സേവനം പുനരാരംഭിക്കേണ്ടതുണ്ട്. നിങ്ങൾക്ക് ഇത് ഉടനടി പുനരാരംഭിക്കാം അല്ലെങ്കിൽ സേവനം നിർത്തി ബ്രൗസറിൽ സൈറ്റ് തുറക്കുമ്പോൾ സോക്കറ്റ് അത് ആരംഭിക്കാൻ അനുവദിക്കുക. ps ഉപയോഗിച്ച് പ്രോസസ്സുകൾക്ക് ശരിയായ ലേബലുകൾ ലഭിച്ചിട്ടുണ്ടോയെന്ന് പരിശോധിക്കുക.

ps -efZ | grep gunicorn

പിന്നീട് ഒരു സാധാരണ SELinux നയം സൃഷ്ടിക്കാൻ മറക്കരുത്!

നിങ്ങൾ ഇപ്പോൾ എവിസി സന്ദേശങ്ങൾ നോക്കുകയാണെങ്കിൽ, അവസാന സന്ദേശത്തിൽ ആപ്ലിക്കേഷനുമായി ബന്ധപ്പെട്ട എല്ലാത്തിനും പെർമിസിവ്=1, സിസ്റ്റത്തിന്റെ ശേഷിക്കുന്നവയ്ക്ക് പെർമിസിവ്=0 എന്നിവ അടങ്ങിയിരിക്കുന്നു. ഒരു യഥാർത്ഥ ആപ്ലിക്കേഷന് ഏത് തരത്തിലുള്ള ആക്‌സസാണ് ആവശ്യമെന്ന് നിങ്ങൾ മനസ്സിലാക്കിയാൽ, അത്തരം പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള ഏറ്റവും നല്ല മാർഗം നിങ്ങൾക്ക് വേഗത്തിൽ കണ്ടെത്താനാകും. എന്നാൽ അതുവരെ, സിസ്റ്റം സുരക്ഷിതമായി സൂക്ഷിക്കുകയും ജാംഗോ പ്രോജക്റ്റിന്റെ വ്യക്തമായ ഉപയോഗയോഗ്യമായ ഓഡിറ്റ് നേടുകയും ചെയ്യുന്നതാണ് നല്ലത്.

sudo ausearch -m AVC

സംഭവിച്ചു!

Nginx, Gunicorn WSGI എന്നിവയെ അടിസ്ഥാനമാക്കിയുള്ള ഒരു ഫ്രണ്ട്‌എൻഡുമായി പ്രവർത്തിക്കുന്ന ഒരു ജാങ്കോ പ്രോജക്റ്റ് പ്രത്യക്ഷപ്പെട്ടു. RHEL 3 ബീറ്റ ശേഖരണങ്ങളിൽ നിന്ന് ഞങ്ങൾ Python 10, PostgreSQL 8 എന്നിവ ക്രമീകരിച്ചു. കോൺഫിഗറേഷൻ പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനും പ്രകടനം മെച്ചപ്പെടുത്തുന്നതിനും അല്ലെങ്കിൽ ഈ കോൺഫിഗറേഷൻ കണ്ടെയ്‌നറൈസ് ചെയ്യുന്നതിനും ഇപ്പോൾ നിങ്ങൾക്ക് മുന്നോട്ട് പോകാനും ജാംഗോ ആപ്ലിക്കേഷനുകൾ സൃഷ്ടിക്കാനും (അല്ലെങ്കിൽ വിന്യസിക്കാനും) അല്ലെങ്കിൽ RHEL 8 ബീറ്റയിൽ ലഭ്യമായ മറ്റ് ടൂളുകൾ പര്യവേക്ഷണം ചെയ്യാം.

അവലംബം: www.habr.com