ກອງປະຊຸມ RHEL 8 Beta: ການສ້າງຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ເຮັດວຽກ

RHEL 8 Beta ສະເຫນີໃຫ້ນັກພັດທະນາມີຄຸນສົມບັດໃຫມ່ຫຼາຍ, ລາຍຊື່ທີ່ສາມາດເອົາຫນ້າ, ຢ່າງໃດກໍຕາມ, ການຮຽນຮູ້ສິ່ງໃຫມ່ແມ່ນສະເຫມີໄປທີ່ດີກວ່າໃນການປະຕິບັດ, ດັ່ງນັ້ນຂ້າງລຸ່ມນີ້ພວກເຮົາສະເຫນີກອງປະຊຸມກ່ຽວກັບການສ້າງໂຄງສ້າງພື້ນຖານຂອງຄໍາຮ້ອງສະຫມັກໂດຍອີງໃສ່ Red Hat Enterprise Linux 8 Beta.

ໃຫ້ເອົາ Python, ພາສາການຂຽນໂປລແກລມທີ່ນິຍົມໃນບັນດານັກພັດທະນາ, ເປັນພື້ນຖານ, ການປະສົມປະສານຂອງ Django ແລະ PostgreSQL, ການປະສົມປະສານທີ່ຂ້ອນຂ້າງທົ່ວໄປສໍາລັບການສ້າງແອັບພລິເຄຊັນ, ແລະ configure RHEL 8 Beta ເພື່ອເຮັດວຽກກັບພວກເຂົາ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາຈະເພີ່ມສ່ວນປະກອບ (ບໍ່ໄດ້ຈັດປະເພດ) ຕື່ມອີກ.

ສະພາບແວດລ້ອມການທົດສອບຈະປ່ຽນແປງ, ເພາະວ່າມັນຫນ້າສົນໃຈທີ່ຈະຄົ້ນຫາຄວາມເປັນໄປໄດ້ຂອງອັດຕະໂນມັດ, ການເຮັດວຽກກັບເຄື່ອງບັນຈຸແລະພະຍາຍາມສະພາບແວດລ້ອມທີ່ມີເຄື່ອງແມ່ຂ່າຍຫຼາຍ. ເພື່ອເລີ່ມຕົ້ນໂຄງການໃຫມ່, ທ່ານສາມາດເລີ່ມຕົ້ນດ້ວຍການສ້າງຕົ້ນແບບຂະຫນາດນ້ອຍ, ງ່າຍດາຍດ້ວຍມືເພື່ອໃຫ້ທ່ານສາມາດເຫັນໄດ້ຊັດເຈນວ່າສິ່ງທີ່ຕ້ອງເກີດຂຶ້ນແລະມັນໂຕ້ຕອບແນວໃດ, ແລະຫຼັງຈາກນັ້ນຍ້າຍໄປອັດຕະໂນມັດແລະສ້າງການຕັ້ງຄ່າທີ່ສັບສົນຫຼາຍ. ມື້ນີ້ພວກເຮົາກໍາລັງເວົ້າເຖິງການສ້າງແບບຕົ້ນແບບດັ່ງກ່າວ.

ມາເລີ່ມຕົ້ນດ້ວຍການນຳໃຊ້ຮູບ RHEL 8 Beta VM. ທ່ານສາມາດຕິດຕັ້ງເຄື່ອງ virtual ຕັ້ງແຕ່ເລີ່ມຕົ້ນ, ຫຼືໃຊ້ຮູບພາບແຂກ KVM ທີ່ມີຢູ່ກັບການສະຫມັກເບຕ້າຂອງທ່ານ. ເມື່ອໃຊ້ຮູບພາບແຂກ, ທ່ານຈະຕ້ອງຕັ້ງຄ່າ CD virtual ທີ່ຈະປະກອບດ້ວຍ metadata ແລະຂໍ້ມູນຜູ້ໃຊ້ສໍາລັບການເລີ່ມຕົ້ນຄລາວ (cloud-init). ທ່ານບໍ່ຈໍາເປັນຕ້ອງເຮັດຫຍັງພິເສດກັບໂຄງສ້າງຂອງແຜ່ນຫຼືຊຸດທີ່ມີຢູ່;

ຂໍໃຫ້ພິຈາລະນາຢ່າງລະອຽດກ່ຽວກັບຂະບວນການທັງຫມົດ.

ການຕິດຕັ້ງ Django

ດ້ວຍ Django ຮຸ່ນໃຫມ່ທີ່ສຸດ, ທ່ານຈະຕ້ອງມີສະພາບແວດລ້ອມ virtual (virtualenv) ກັບ Python 3.5 ຫຼືຫຼັງຈາກນັ້ນ. ໃນບັນທຶກ Beta ທ່ານສາມາດເຫັນໄດ້ວ່າ Python 3.6 ແມ່ນມີຢູ່, ໃຫ້ກວດເບິ່ງວ່ານີ້ແມ່ນກໍລະນີທີ່ແທ້ຈິງ:

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

Red Hat ໃຊ້ Python ຢ່າງຈິງຈັງເປັນຊຸດເຄື່ອງມືລະບົບໃນ RHEL, ດັ່ງນັ້ນຜົນໄດ້ຮັບນີ້ເປັນຫຍັງ?

ຄວາມຈິງແລ້ວແມ່ນວ່ານັກພັດທະນາ Python ຫຼາຍຄົນຍັງຄິດເຖິງການຫັນປ່ຽນຈາກ Python 2 ໄປ Python 2, ໃນຂະນະທີ່ Python 3 ຕົວຂອງມັນເອງແມ່ນຢູ່ພາຍໃຕ້ການພັດທະນາຢ່າງຫ້າວຫັນ, ແລະສະບັບໃຫມ່ໆເພີ່ມຂຶ້ນຢ່າງຕໍ່ເນື່ອງ. ດັ່ງນັ້ນ, ເພື່ອຕອບສະຫນອງຄວາມຕ້ອງການເຄື່ອງມືລະບົບທີ່ຫມັ້ນຄົງໃນຂະນະທີ່ສະເຫນີໃຫ້ຜູ້ໃຊ້ເຂົ້າເຖິງ Python ຮຸ່ນໃຫມ່ຕ່າງໆ, ລະບົບ Python ໄດ້ຖືກຍ້າຍໄປຢູ່ໃນຊຸດໃຫມ່ແລະສະຫນອງຄວາມສາມາດໃນການຕິດຕັ້ງທັງ Python 2.7 ແລະ 3.6. ຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບການປ່ຽນແປງແລະເປັນຫຍັງພວກມັນຖືກສ້າງຂື້ນສາມາດພົບໄດ້ໃນການພິມໃນ blog ຂອງ Langdon White (Langdon White).

ດັ່ງນັ້ນ, ເພື່ອໃຫ້ໄດ້ Python ເຮັດວຽກ, ທ່ານພຽງແຕ່ຕ້ອງການຕິດຕັ້ງສອງແພັກເກັດ, ໂດຍມີ python3-pip ລວມເປັນ dependency.

sudo yum install python36 python3-virtualenv

ເປັນຫຍັງຈຶ່ງບໍ່ໃຊ້ການໂທໂມດູນໂດຍກົງຕາມທີ່ Langdon ແນະນໍາແລະຕິດຕັ້ງ pip3? ການຮັກສາຢູ່ໃນໃຈຂອງອັດຕະໂນມັດທີ່ຈະມາເຖິງ, ມັນເປັນທີ່ຮູ້ຈັກວ່າ Ansible ຈະຮຽກຮ້ອງໃຫ້ມີການຕິດຕັ້ງ pip ເພື່ອດໍາເນີນການ, ເນື່ອງຈາກວ່າໂມດູນ pip ບໍ່ສະຫນັບສະຫນູນ virtualenvs ທີ່ມີ pip ກໍານົດເອງທີ່ສາມາດປະຕິບັດໄດ້.

ດ້ວຍນາຍພາສາ python3 ທີ່ເຮັດວຽກຢູ່ໃນການກໍາຈັດຂອງທ່ານ, ທ່ານສາມາດສືບຕໍ່ຂະບວນການຕິດຕັ້ງ Django ແລະມີລະບົບການເຮັດວຽກພ້ອມກັບອົງປະກອບອື່ນໆຂອງພວກເຮົາ. ມີຫຼາຍທາງເລືອກໃນການປະຕິບັດທີ່ມີຢູ່ໃນອິນເຕີເນັດ. ມີສະບັບຫນຶ່ງທີ່ນໍາສະເຫນີຢູ່ທີ່ນີ້, ແຕ່ຜູ້ໃຊ້ສາມາດນໍາໃຊ້ຂະບວນການຂອງຕົນເອງ.

ພວກເຮົາຈະຕິດຕັ້ງເວີຊັນ PostgreSQL ແລະ Nginx ທີ່ມີຢູ່ໃນ RHEL 8 ໂດຍຄ່າເລີ່ມຕົ້ນໂດຍໃຊ້ Yum.

sudo yum install nginx postgresql-server

PostgreSQL ຈະຕ້ອງການ psycopg2, ແຕ່ມັນຈໍາເປັນຕ້ອງມີຢູ່ໃນສະພາບແວດລ້ອມ virtualenv ເທົ່ານັ້ນ, ດັ່ງນັ້ນພວກເຮົາຈະຕິດຕັ້ງມັນໂດຍໃຊ້ pip3 ພ້ອມກັບ Django ແລະ Gunicorn. ແຕ່ທໍາອິດພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຕັ້ງຄ່າ virtualenv.

ມີການໂຕ້ວາທີເລື້ອຍໆກ່ຽວກັບຫົວຂໍ້ຂອງການເລືອກສະຖານທີ່ທີ່ເຫມາະສົມໃນການຕິດຕັ້ງໂຄງການ Django, ແຕ່ເມື່ອສົງໃສ, ທ່ານສາມາດຫັນໄປຫາ Linux Filesystem Hierarchy Standard. ໂດຍສະເພາະ, FHS ກ່າວວ່າ / srv ຖືກນໍາໃຊ້ເພື່ອ: "ເກັບຮັກສາຂໍ້ມູນສະເພາະຂອງເຈົ້າພາບ - ຂໍ້ມູນທີ່ລະບົບຜະລິດ, ເຊັ່ນຂໍ້ມູນເຊີຟເວີເວັບແລະສະຄິບ, ຂໍ້ມູນທີ່ເກັບໄວ້ໃນເຄື່ອງແມ່ຂ່າຍ FTP, ແລະລະບົບການຄວບຄຸມການເກັບຮັກສາ (ປະກົດຢູ່ໃນ FHS -2.3 ໃນປີ 2004).

ນີ້ແມ່ນກໍລະນີຂອງພວກເຮົາແທ້ໆ, ດັ່ງນັ້ນພວກເຮົາເອົາທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາຕ້ອງການເຂົ້າໄປໃນ / srv, ເຊິ່ງເປັນເຈົ້າຂອງໂດຍຜູ້ໃຊ້ແອັບພລິເຄຊັນຂອງພວກເຮົາ (cloud-user).

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 ແມ່ນ script postgresql-setup ທີ່ຖືກຕິດຕັ້ງກັບຊຸດ postgresql-server. ສະຄຣິບນີ້ຊ່ວຍໃຫ້ທ່ານປະຕິບັດວຽກງານພື້ນຖານທີ່ກ່ຽວຂ້ອງກັບການຄຸ້ມຄອງກຸ່ມຖານຂໍ້ມູນ, ເຊັ່ນ: ການເລີ່ມຕົ້ນຂອງກຸ່ມຫຼືຂະບວນການຍົກລະດັບ. ເພື່ອຕັ້ງຄ່າຕົວຢ່າງ PostgreSQL ໃຫມ່ໃນລະບົບ RHEL, ພວກເຮົາຈໍາເປັນຕ້ອງດໍາເນີນການຄໍາສັ່ງ:

sudo /usr/bin/postgresql-setup -initdb

ຈາກນັ້ນທ່ານສາມາດເລີ່ມ PostgreSQL ໂດຍໃຊ້ systemd, ສ້າງຖານຂໍ້ມູນ, ແລະຕັ້ງໂຄງການໃນ Django. ຈື່ໄວ້ວ່າຈະປິດເປີດ PostgreSQL ຄືນໃໝ່ຫຼັງຈາກເຮັດການປ່ຽນແປງໄຟລ໌ການຕັ້ງຄ່າການພິສູດຢືນຢັນລູກຂ່າຍ (ໂດຍປົກກະຕິແລ້ວ pg_hba.conf) ເພື່ອຕັ້ງຄ່າການເກັບຮັກສາລະຫັດຜ່ານສໍາລັບຜູ້ໃຊ້ແອັບພລິເຄຊັນ. ຖ້າທ່ານພົບຄວາມຫຍຸ້ງຍາກອື່ນໆ, ໃຫ້ແນ່ໃຈວ່າປ່ຽນການຕັ້ງຄ່າ IPv4 ແລະ IPv6 ໃນໄຟລ໌ pg_hba.conf.

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 ໃນໂຄງການແລະການຕັ້ງຄ່າຖານຂໍ້ມູນ, ທ່ານສາມາດເລີ່ມຕົ້ນເຄື່ອງແມ່ຂ່າຍຂອງການພັດທະນາເພື່ອໃຫ້ແນ່ໃຈວ່າທຸກສິ່ງທຸກຢ່າງເຮັດວຽກ. ຫຼັງຈາກເລີ່ມຕົ້ນເຄື່ອງແມ່ຂ່າຍການພັດທະນາ, ມັນເປັນຄວາມຄິດທີ່ດີທີ່ຈະສ້າງຜູ້ໃຊ້ admin ເພື່ອທົດສອບການເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນ.

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

WSGI? ຫວາຍ?

ເຊີບເວີພັດທະນາແມ່ນເປັນປະໂຫຍດສໍາລັບການທົດສອບ, ແຕ່ເພື່ອດໍາເນີນການຄໍາຮ້ອງສະຫມັກທ່ານຕ້ອງກໍາຫນົດຄ່າເຄື່ອງແມ່ຂ່າຍທີ່ເຫມາະສົມແລະຕົວແທນສໍາລັບ Web Server Gateway Interface (WSGI). ມີຫຼາຍການປະສົມປະສານທົ່ວໄປ, ສໍາລັບການຍົກຕົວຢ່າງ, Apache HTTPD ກັບ uWSGI ຫຼື Nginx ກັບ Gunicorn.

ວຽກຂອງ Web Server Gateway Interface ແມ່ນເພື່ອສົ່ງຕໍ່ຄໍາຮ້ອງຂໍຈາກເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ໄປຫາກອບເວັບ Python. WSGI ເປັນທີ່ລຶກລັບຂອງອະດີດທີ່ຂີ້ຮ້າຍໃນເວລາທີ່ເຄື່ອງຈັກ CGI ປະມານ, ແລະມື້ນີ້ WSGI ແມ່ນມາດຕະຖານ de facto, ບໍ່ວ່າຈະເປັນເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ຫຼືກອບ Python ຖືກນໍາໃຊ້. ແຕ່ເຖິງວ່າຈະມີການນໍາໃຊ້ຢ່າງກວ້າງຂວາງ, ຍັງມີຫຼາຍ nuances ໃນເວລາທີ່ເຮັດວຽກກັບກອບເຫຼົ່ານີ້, ແລະທາງເລືອກຫຼາຍ. ໃນກໍລະນີນີ້, ພວກເຮົາຈະພະຍາຍາມສ້າງການໂຕ້ຕອບລະຫວ່າງ Gunicorn ແລະ Nginx ຜ່ານເຕົ້າຮັບ.

ເນື່ອງຈາກທັງສອງອົງປະກອບເຫຼົ່ານີ້ຖືກຕິດຕັ້ງຢູ່ໃນເຄື່ອງແມ່ຂ່າຍດຽວກັນ, ໃຫ້ລອງໃຊ້ຊັອກເກັດ UNIX ແທນຊັອກເກັດເຄືອຂ່າຍ. ເນື່ອງຈາກການສື່ສານຕ້ອງການເຕົ້າຮັບໃນກໍລະນີໃດກໍ່ຕາມ, ໃຫ້ພະຍາຍາມດໍາເນີນຂັ້ນຕອນຫນຶ່ງແລະກໍານົດການເປີດໃຊ້ socket ສໍາລັບ Gunicorn ຜ່ານ systemd.

ຂະບວນການສ້າງ socket activated services ແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ. ທໍາອິດ, ໄຟລ໌ຫນ່ວຍຖືກສ້າງຂື້ນທີ່ປະກອບດ້ວຍຄໍາສັ່ງ ListenStream ຊີ້ໄປຫາຈຸດທີ່ເຕົ້າຮັບ UNIX ຈະຖືກສ້າງຂື້ນ, ຫຼັງຈາກນັ້ນໄຟລ໌ຫນ່ວຍງານສໍາລັບການບໍລິການທີ່ຄໍາສັ່ງ Requires ຈະຊີ້ໄປຫາໄຟລ໌ຫນ່ວຍເຕົ້າຮັບ. ຫຼັງຈາກນັ້ນ, ໃນໄຟລ໌ຫນ່ວຍບໍລິການ, ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນໂທຫາ Gunicorn ຈາກສະພາບແວດລ້ອມ virtual ແລະສ້າງການຜູກມັດ WSGI ສໍາລັບຊັອກເກັດ UNIX ແລະຄໍາຮ້ອງສະຫມັກ Django.

ນີ້ແມ່ນບາງຕົວຢ່າງຂອງໄຟລ໌ຫນ່ວຍງານທີ່ທ່ານສາມາດນໍາໃຊ້ເປັນພື້ນຖານ. ທໍາອິດພວກເຮົາຕັ້ງຄ່າເຕົ້າຮັບ.

[Unit]
Description=Gunicorn WSGI socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

ຕອນນີ້ທ່ານຕ້ອງການຕັ້ງຄ່າ Gunicorn daemon.

[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;
   }
}

ເລີ່ມຕົ້ນຊັອກເກັດ Gunicorn ແລະ Nginx ໂດຍໃຊ້ systemd ແລະທ່ານພ້ອມທີ່ຈະເລີ່ມການທົດສອບ.

ຄວາມຜິດພາດ Gateway ບໍ່ດີ?

ຖ້າທ່ານໃສ່ທີ່ຢູ່ເຂົ້າໄປໃນຕົວທ່ອງເວັບຂອງທ່ານ, ທ່ານຈະໄດ້ຮັບຄວາມຜິດພາດ 502 Bad Gateway. ມັນອາດຈະເປັນສາເຫດມາຈາກການອະນຸຍາດຊັອກເກັດ 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. ເນື່ອງຈາກພວກເຮົາກໍາລັງໃຊ້ daemon ທີ່ບໍ່ມີນະໂຍບາຍຖືກສ້າງຂຶ້ນ, ມັນຈະຖືກຫມາຍເປັນ init_t. ໃຫ້ທົດສອບທິດສະດີນີ້ໃນພາກປະຕິບັດ.

sudo setenforce 0

ທັງຫມົດນີ້ອາດຈະເຮັດໃຫ້ເກີດການວິພາກວິຈານແລະນ້ໍາຕາຂອງເລືອດ, ແຕ່ນີ້ແມ່ນພຽງແຕ່ debugging ຕົ້ນແບບ. ໃຫ້ປິດການກວດສອບພຽງແຕ່ເພື່ອໃຫ້ແນ່ໃຈວ່ານີ້ແມ່ນບັນຫາ, ຫຼັງຈາກນັ້ນພວກເຮົາຈະສົ່ງທຸກສິ່ງທຸກຢ່າງກັບຄືນສູ່ສະຖານທີ່ຂອງມັນ.

ໂດຍການໂຫຼດຫນ້າຈໍຄືນຫນ້າໃນຕົວທ່ອງເວັບຫຼືດໍາເນີນການຄໍາສັ່ງ curl ຂອງພວກເຮົາຄືນໃຫມ່, ທ່ານສາມາດເບິ່ງຫນ້າການທົດສອບ Django.

ດັ່ງນັ້ນ, ໃຫ້ແນ່ໃຈວ່າທຸກສິ່ງທຸກຢ່າງເຮັດວຽກແລະບໍ່ມີບັນຫາການອະນຸຍາດ, ພວກເຮົາເປີດໃຊ້ SELinux ອີກເທື່ອຫນຶ່ງ.

sudo setenforce 1

ຂ້າພະເຈົ້າຈະບໍ່ເວົ້າກ່ຽວກັບ audit2allow ຫຼືການສ້າງນະໂຍບາຍເຕືອນທີ່ມີ sepolgen ຢູ່ທີ່ນີ້, ເນື່ອງຈາກວ່າບໍ່ມີຄໍາຮ້ອງສະຫມັກ Django ຕົວຈິງໃນປັດຈຸບັນ, ດັ່ງນັ້ນບໍ່ມີແຜນທີ່ຄົບຖ້ວນສົມບູນຂອງສິ່ງທີ່ 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 ກໍາລັງຂັດຂວາງສິ່ງອື່ນນອກເຫນືອຈາກສິ່ງທີ່ daemon ທີ່ບໍ່ຮູ້ຈັກຂອງພວກເຮົາກໍາລັງເຂົ້າຫາ.

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

SELinux ປ້ອງກັນບໍ່ໃຫ້ Nginx ຂຽນຂໍ້ມູນໃສ່ເຕົ້າຮັບ UNIX ທີ່ໃຊ້ໂດຍ Gunicorn. ໂດຍປົກກະຕິ, ໃນກໍລະນີດັ່ງກ່າວ, ນະໂຍບາຍເລີ່ມຕົ້ນມີການປ່ຽນແປງ, ແຕ່ຍັງມີສິ່ງທ້າທາຍອື່ນໆຢູ່ຂ້າງຫນ້າ. ນອກນັ້ນທ່ານຍັງສາມາດປ່ຽນການຕັ້ງຄ່າໂດເມນຈາກໂດເມນຈໍາກັດໄປຫາໂດເມນທີ່ອະນຸຍາດ. ຕອນນີ້ໃຫ້ຍ້າຍ httpd_t ໄປຫາໂດເມນການອະນຸຍາດ. ນີ້ຈະໃຫ້ Nginx ເຂົ້າເຖິງທີ່ຈໍາເປັນແລະພວກເຮົາສາມາດສືບຕໍ່ກັບວຽກງານການດີບັກຕື່ມອີກ.

sudo semanage permissive -a httpd_t

ດັ່ງນັ້ນ, ເມື່ອທ່ານໄດ້ຈັດການ SELinux ປ້ອງກັນ (ທ່ານກໍ່ບໍ່ຄວນປ່ອຍໃຫ້ໂຄງການ SELinux ຢູ່ໃນໂຫມດຈໍາກັດ) ແລະໂດເມນການອະນຸຍາດຖືກໂຫລດ, ທ່ານຈໍາເປັນຕ້ອງຊອກຫາສິ່ງທີ່ຕ້ອງຖືກຫມາຍເປັນ gunicorn_exec_t ເພື່ອໃຫ້ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຢ່າງຖືກຕ້ອງ. ອີກເທື່ອຫນຶ່ງ. ລອງເຂົ້າເບິ່ງເວັບໄຊທ໌ເພື່ອເບິ່ງຂໍ້ຄວາມໃຫມ່ກ່ຽວກັບຂໍ້ຈໍາກັດການເຂົ້າເຖິງ.

sudo ausearch -m AVC -c gunicorn

ທ່ານຈະເຫັນຫຼາຍຂໍ້ຄວາມທີ່ມີ 'comm="gunicorn"' ທີ່ເຮັດສິ່ງຕ່າງໆໃນໄຟລ໌ຕ່າງໆໃນ /srv/djangoapp, ດັ່ງນັ້ນແນ່ນອນນີ້ແມ່ນຫນຶ່ງໃນຄໍາສັ່ງທີ່ມີມູນຄ່າການລາຍງານ.

ແຕ່ນອກຈາກນັ້ນ, ຂໍ້ຄວາມເຊັ່ນນີ້ປະກົດວ່າ:

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, ທ່ານຈະບໍ່ເຫັນຂະບວນການແລ່ນໃດໆ. ເບິ່ງຄືວ່າ gunicorn ກໍາລັງພະຍາຍາມເຂົ້າເຖິງຕົວແປພາສາ Python ໃນສະພາບແວດລ້ອມ virtualenv ຂອງພວກເຮົາ, ອາດຈະດໍາເນີນການສະຄິບຂອງພະນັກງານ. ສະນັ້ນຕອນນີ້ໃຫ້ພວກເຮົາເຮັດເຄື່ອງຫມາຍທັງສອງໄຟລ໌ທີ່ສາມາດປະຕິບັດໄດ້ແລະກວດເບິ່ງວ່າພວກເຮົາສາມາດເປີດຫນ້າທົດສອບ Django ຂອງພວກເຮົາໄດ້ບໍ.

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

ການບໍລິການ gunicorn ຈະຕ້ອງຖືກເລີ່ມຕົ້ນໃຫມ່ກ່ອນທີ່ຈະສາມາດເລືອກແທັກໃຫມ່ໄດ້. ທ່ານສາມາດ restart ມັນທັນທີຫຼືຢຸດການບໍລິການແລະໃຫ້ socket ເລີ່ມຕົ້ນມັນໃນເວລາທີ່ທ່ານເປີດເວັບໄຊທ໌ໃນຕົວທ່ອງເວັບ. ກວດສອບວ່າຂະບວນການໄດ້ຮັບປ້າຍທີ່ຖືກຕ້ອງໂດຍໃຊ້ ps.

ps -efZ | grep gunicorn

ຢ່າລືມສ້າງນະໂຍບາຍ SELinux ປົກກະຕິໃນພາຍຫຼັງ!

ຖ້າທ່ານເບິ່ງຂໍ້ຄວາມ AVC ໃນປັດຈຸບັນ, ຂໍ້ຄວາມສຸດທ້າຍປະກອບດ້ວຍ permissive=1 ສໍາລັບທຸກສິ່ງທຸກຢ່າງທີ່ກ່ຽວຂ້ອງກັບແອັບພລິເຄຊັນ, ແລະ permissive=0 ສໍາລັບສ່ວນທີ່ເຫຼືອຂອງລະບົບ. ຖ້າທ່ານເຂົ້າໃຈວ່າປະເພດຂອງການເຂົ້າເຖິງຄໍາຮ້ອງສະຫມັກທີ່ແທ້ຈິງຕ້ອງການ, ທ່ານສາມາດຊອກຫາວິທີທີ່ດີທີ່ສຸດເພື່ອແກ້ໄຂບັນຫາດັ່ງກ່າວຢ່າງໄວວາ. ແຕ່ຈົນກ່ວານັ້ນ, ມັນດີທີ່ສຸດທີ່ຈະຮັກສາລະບົບໃຫ້ປອດໄພແລະໄດ້ຮັບການກວດສອບທີ່ຊັດເຈນແລະສາມາດໃຊ້ໄດ້ຂອງໂຄງການ Django.

sudo ausearch -m AVC

ເກີດຂຶ້ນ!

ໂຄງການ Django ທີ່ເຮັດວຽກໄດ້ປາກົດຢູ່ກັບຫນ້າດ້ານຫນ້າໂດຍອີງໃສ່ Nginx ແລະ Gunicorn WSGI. ພວກເຮົາໄດ້ຕັ້ງຄ່າ Python 3 ແລະ PostgreSQL 10 ຈາກ RHEL 8 Beta repositories. ໃນປັດຈຸບັນທ່ານສາມາດກ້າວໄປຂ້າງຫນ້າແລະສ້າງ (ຫຼືພຽງແຕ່ນໍາໃຊ້) ຄໍາຮ້ອງສະຫມັກ Django ຫຼືຄົ້ນຫາເຄື່ອງມືອື່ນໆທີ່ມີຢູ່ໃນ RHEL 8 Beta ເພື່ອເຮັດໃຫ້ຂະບວນການຕັ້ງຄ່າອັດຕະໂນມັດ, ປັບປຸງການປະຕິບັດ, ຫຼືແມ້ກະທັ້ງບັນຈຸການຕັ້ງຄ່ານີ້.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com