RHEL 8 Beta praktikum: Loome töötavaid veebirakendusi

RHEL 8 Beta pakub arendajatele palju uusi võimalusi, mille loetlemine võiks võtta lehekülgi, kuid uut on alati parem õppida praktikas. Seetõttu soovitame allpool läbida praktilise harjutuse, et luua rakenduste infrastruktuur Red Hat Enterprise Linux 8 Beta baasil.

Võtame aluseks Python'i, arendajate seas populaarse programmeerimiskeele, kombinatsiooni Django ja PostgreSQL, mis on üsna levinud zest rakenduste loomisel, ning konfigureerime RHEL 8 Beta töötamiseks nende keskkondadega. Peale selle lisame veel paar (mitte saladuslikku) koostisosade.

Testimiskeskkond muutub, sest on huvitav uurida automatiseerimise võimalusi, töötada konteineritega ja proovida keskkondi, kus on mitu serverit. Uue projekti alustamiseks võib alustada väikese ja lihtsa prototüübi loomisega käsitsi – nii on võimalik näha, mis täpselt peaks juhtuma ja kuidas toimib koostegevus, ning seejärel liikuda automatiseerimise ja keerukamate konfigureerimise loomise suunas. Täna räägime sellise prototüübi loomise protsessist.

Alustame RHEL 8 Beta VM pildi juurutamisega. Võib installida virtuaalse masina nullist või kasutada KVM külalispildi, mis on saadaval koos Beta tellimusega. Külalispildi kasutamisel peab seadistama virtuaalse CD, mis sisaldab meetaandmeid ja kasutajandmeid pilveiniitsialiseerimiseks (cloud-init). Diskistruktuuri või saadaval olevate paketiga ei pea midagi erilist tegema, sobib igasugune konfiguratsioon.

Vaadakem kogu protsessi lähemalt.

Django installimine

Uueimaga Django versiooniga on vajalik virtuaalne keskkond (virtualenv) Python 3.5 või uuema versiooniga. Beta märkustes oleme näinud, et Python 3.6 on saadaval, vaatame, kas see tõepoolest nii on:

[cloud-user@8beta1 ~]$ python
-bash: python: käsku ei leitud
[cloud-user@8beta1 ~]$ python3
-bash: python3: käsku ei leitud

Red Hat kasutab Pythonit aktiivselt RHEL-i süsteemide tööriistana, seega, miks saadakse selline tulemus?

As it turns out, many developers using Python are still considering a transition from Python 2 to Python 2, while Python 3 is under active development and new versions are constantly being released. Therefore, to meet the need for stable system tools and simultaneously offer users access to various new versions of Python, the system Python has been moved to a new package, allowing the installation of both Python 2.7 and 3.6. More detailed information about the changes and why this was done can be found in the publication on Langdon White's blog (Langdon White).

Thus, to obtain a functioning Python, it is necessary to install just two packages, while python3-pip will be pulled in as a dependency.

sudo yum install python36 python3-virtualenv

Why not use direct calls to the module as Langdon suggests, and not install pip3? Keeping in mind the upcoming automation, it is known that Ansible requires pip to be installed, as the pip module does not support virtual environments (virtualenvs) with a custom pip executable.

Having a working python3 interpreter at your disposal, you can continue the Django installation process and obtain a functioning system along with our other components. There are many implementation options available online. Here is one version presented, but users can use their own processes.

The versions of PostgreSQL and Nginx that are available in RHEL 8 by default will be installed using Yum.

sudo yum install nginx postgresql-server

PostgreSQL will require psycopg2, but it needs to be available only in the virtualenv environment, so we will install it using pip3 along with Django and Gunicorn. But first, we need to set up virtualenv.

There is always a lot of debate about the proper choice of installation location for Django projects, but when doubts arise, one can always refer to the Linux Filesystem Hierarchy Standard. In particular, the FHS states that /srv is used for: "storing data specific to a particular node — data served by the system, such as data and scripts of web servers, data stored on FTP servers, as well as repositories of version control systems (introduced in FHS-2.3 in 2004)."

See on just meie juhtum, seega paneme kõik vajalikud asjad kausta /srv, mille omanikuks on meie rakenduse kasutaja (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 ja Django seadistamine ei ole keeruline: loome andmebaasi, loome kasutaja, seadistame õigused. On üks asi, mida tuleb meeles pidada PostgreSQL algse installimise juures – see on skript postgresql-setup, mis paigaldatakse koos paketiga postgresql-server. See skript aitab täita põhiülesandeid, mis on seotud andmebaasi klastrite haldamisega, näiteks klastrite algatamine või värskendamise protsess. Uue PostgreSQL instantsi seadistamiseks RHEL süsteemis peame käivitama käsu:

sudo /usr/bin/postgresql-setup -initdb

Pärast seda saame PostgreSQL käivitada systemd'ga, luua andmebaasi ja seadistada projekti Django's. Ära unusta PostgreSQL'i taaskäivitada pärast muudatuste tegemist kliendi autentimise konfiguratsioonifailis (tavaliselt pg_hba.conf) rakenduse kasutaja parooli salvestamise seadistamiseks. Kui kohtate muid raskusi, veenduge, et IPv4 ja IPv6 seaded on muudetud failis 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

Failis /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

Failis /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 }}',
   }
}

Pärast settings.py faili konfigureerimist projektis ja andmebaasi konfiguratsiooni seadistamist saame käivitada arendusserveri, et veenduda, et kõik toimib. Pärast arendusserveri käivitamist on hea luua admin kasutaja, et testida andmebaasi ühendust.

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

WSGI? Mis see on?

Arendusserver on kasulik testimiseks, kuid rakenduse töötamiseks tuleb seadistada vastavad server ja proksi Web Server Gateway Interface (WSGI) jaoks. On mitmeid levinud kombinatsioone, näiteks Apache HTTPD koos uWSGI-ga või Nginx koos Gunicorniga.

Web Server Gateway Interface'i ülesanne on suunata päringud edasi veebiserver Pythoni veebiraamistikule. WSGI on midagi, mis pärineb õudse mineviku ajast, kui olid kasutusel CGI mehhanismid, ja tänapäeval on WSGI praktiliselt standard, sõltumata kasutatavast veebiserverist või Pythoni raamistikust. Kuid malakaine laialdase leviku tõttu on siiski palju nüansse nende raamistikudega töötamisel ja palju valikuvõimalusi. Sel juhul püüame seadistada Gunicorni ja Nginxi suhtlemise soketi kaudu.

Kuna mõlemad komponendid on installitud samale serverile, proovime kasutada võrgu soketi asemel UNIX soketti. Kuna suhtlemiseks on igal juhul vaja soketti, proovime astuda veel ühe sammu ja seadistada Gunicorni soketi aktiveerimine systemd kaudu.

Soketiga aktiveeritavate teenuste loomise protsess on üsna lihtne. Esiteks luuakse unit-fail, mis sisaldab direktiivi ListenStream, mis näitab punkti, kus UNIX sokett luuakse, seejärel — teenuse unit-fail, mille direktiiv Requires näeb ette soketi unit-faili. Seejärel jääb teenuse unit-failis lihtsalt kutsuda Gunicorn virtuaalsest keskkonnast ja luua WSGI seotus UNIX soketi ja Django rakenduse jaoks.

Siin on mõned näidised unit-failidest, mida saab aluseks võtta. Esiteks seadistame soketi.

[Unit]
Description=Gunicorn WSGI sokett

[Socket]
ListenStream=\/run\/gunicorn.sock

[Install]
WantedBy=sockets.target

Nüüd on vaja seadistada Gunicorni deemon.

[Unit]
Description=Gunicorn deemon
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

Nginxi jaoks on piisav lihtsalt luua pöördiste konfiguratsioonifailid ja seadistada välistatud sisu salvestamise kataloog, kui kasutate seda. RHEL-is asuvad Nginxi konfiguratsioonifailid \/etc\/nginx\/conf.d. Saate kopeerida järgmise näite faili \/etc\/nginx\/conf.d\/default.conf ja käivitada teenuse. Veenduge, et olete määranud server_nimi vastavalt oma hosti nimele.

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

Käivitage Gunicorni ja Nginxi sokett systemd abil, ja võite alustada testimist.

Bad Gateway viga?

Kui sisenete aadressi brauserisse, saate tõenäoliselt vea 502 Bad Gateway. See võib olla tingitud valesti seadistatud UNIX-soketi õigustest või keerukamatest probleemidest, mis on seotud juurdepääsu haldamisega SELinuxis.

Nginx'i vealogis võib sageli leida sellise joone:

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"

Kui testida Gunicorn'i otse, saame tühja vastuse.

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

Vaatame, miks see juhtub. Kui avame logi, näeme tõenäoliselt, et probleem on seotud SELinuxiga. Kuna meil on käivitatud teenus, mille jaoks ei ole loodud oma poliitikat, tähistatakse seda kui init_t. Kontrollime seda teooriat praktikas.

sudo setenforce 0

Kõik see võib tekitada kriitikat ja veretuks pisaraid, kuid see on vaid prototüübi silumine. Lülitame kontrolli välja, et veenduda, et probleem on tõepoolest selles, pärast mida paneme kõik tagasi paika.

Brauseris lehte uuendades või meie curl'i käsku uuesti käivitades näeme Django testlehte.

Nii et, veendudes, et kõik töötab ja muid õiguse probleeme pole, lülitame SELinuxi taas sisse.

sudo setenforce 1

Siin ei räägita audit2allow'st ja poliitikate loomise protsessist, mis põhinevad teadaannete sepolgen'i abil, kuna hetkel ei ole reaalset Django rakendust, seega pole ka täielikku kaarti sellest, millele Gunicorn võib juurdepääsu taotleda ja millele see juurdepääs peab olema keelatud. Seega on vajalik, et SELinux töötaks süsteemi kaitsmiseks, samas lubades rakendusel käivituda ja logida auditi sõnumeid, et hiljem saaks nende põhjal luua tõelise poliitika.

Lubatud domeenide määramine (permissive domains)

Paljud ei ole kuulnud lubatud domeenidest SELinuxis, kuid need pole midagi uut. Paljud on isegi nendega töötanud, sellest aru saamata. Kui poliitika luuakse audititeadete põhjal, esindab loodud poliitika lubatud domeeni. Proovime luua lihtsaimat lubavat poliitikat.

Gunicorn'i konkreetse lubatud domeeni loomiseks on vajalik poliitika ning vastavaid faile tuleb märgistada. Samuti on vajalikud tööriistad uute poliitikate koostamiseks.

sudo yum install selinux-policy-devel

Lubatud domeenide mehhanism on suurepärane tööriist probleemide tuvastamiseks, eriti kui tegemist on kohandatud rakenduse või rakendustega, mis on tarnitud juba loodud poliitikateta. Antud juhul on Gunicorn'i lubatud domeeni poliitika maksimaalselt lihtne – kuulutame välja põhiliigi (gunicorn_t), määrame tüübi, mida kasutame mitmete täitmisfailide märgistamiseks (gunicorn_exec_t), ja seejärel seadistame ülemineku (transition) süsteemile, et õigesti märgistada töötavaid protsesse. Viimane rida määrab poliitika vaikimisi lubatuks selle laadimise hetkeks.

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;

Selle poliitikafaili saab kompileerida ja süsteemi lisada.

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

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

Kontrollime, kas SELinux ei blokeeri midagi muud, peale selle, mida meie tundmatu deemon kasutab.

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 ei luba Nginx'il kirjutada andmeid Unix socket'i, mida Gunicorn kasutab. Tavalistes olukordades hakatakse poliitikaid muutma, kuid ees on veel teised ülesanded. Samuti on võimalik muuta domeeni seadeid, muutes selle piirangute domeenist lubatud domeeniks. Nüüd kanname httpd_t lubatud domeeni. See tagab Nginx'i vajaliku juurdepääsu ning saame jätkata tõrkeotsingut.

sudo semanage permissive -a httpd_t

Nii, kui õnnestub säilitada SELinux'i kaitse (päriselt ei tohiks projekti jätta SELinux'i piirangute režiimi) ja lubatud domeenid on laaditud, on vajalik välja selgitada, mida tuleb märgistada kui gunicorn_exec_t, et kõik uuesti õigesti töötaks. Proovime külastada veebisaiti, et näha uusi juurdepääsu piiranguid.

sudo ausearch -m AVC -c gunicorn

Näeme mitmeid teateid, mis sisaldavad ‘comm=«gunicorn»’, mis teevad erinevaid toiminguid failidega aadressil /srv/djangoapp, seega on ilmselge, et see on üks käsk, mida tasub märgistada.

Kuid lisaks ilmub sõnum nagu järgmine:

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

Kui vaatate gunicorni teenuse staatust või käivitate käsu ps, siis ei ilmu käivitatud protsesside hulka midagi. Tundub, et gunicorn üritab pääseda meie virtualenv'i Python'i tõlgile, võib-olla tööscriptide (workers) käivitamiseks. Seetõttu märgistame praegu need kaks täitmisfaili ja kontrollime, kas suudame avada meie testimislehe Django.

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

Gunicorn teenuse uuesti käivitamine on vajalik, et valida uus märgis. Võite selle kohe uuesti käivitada või stoppida teenuse ja lasta sokkel selle käivitada, kui avate lehe brauseris. Veenduge, et protsessid on saanud õiged märgised, kasutades ps.

ps -efZ | grep gunicorn

Ärge unustage seejärel luua korralik SELinux poliitika!

Kui vaatate praegu AVC teateid, siis viimane sõnum sisaldab permissive=1 kõigi rakenduse kohta ja permissive=0 kogu ülejäänud süsteemi jaoks. Kui mõista, millist ligipääsu tegelik rakendus vajab, on võimalik kiiremini leida optimaalseid lahendusi selliste probleemide lahendamiseks. Kuid seni on parem, et süsteem oleks kaitstud, et saada arusaadavat ja kasutatavat auditit Django projekti kohta.

sudo ausearch -m AVC

Saime hakkama!

Ilmus töötav Django projekt Nginxi ja Gunicorni WSGI-ga. Oleme seadistanud Python 3 ja PostgreSQL 10 RHEL 8 Beta hoidlatest. Nüüd on aeg edasi liikuda ja luua (või lihtsalt juurutada) Django rakendusi või uurida teisi RHEL 8 Beta saadaval olevaid tööriistu seadistamise protsessi automatiseerimiseks, jõudluse suurendamiseks või isegi selle konfiguratsiooni konteineriseerimiseks.

Allikas: habr.com