RHEL 8 бета семинар: Изграждане на работещи уеб приложения

RHEL 8 Beta предлага на разработчиците много нови функции, чийто списък може да отнеме страници, но научаването на нови неща винаги е по-добро на практика, така че по-долу предлагаме семинар за действително създаване на инфраструктура за приложения, базирана на Red Hat Enterprise Linux 8 Beta.

Нека вземем за основа Python, популярен език за програмиране сред разработчиците, комбинация от Django и PostgreSQL, доста често срещана комбинация за създаване на приложения, и да конфигурираме RHEL 8 Beta да работи с тях. След това ще добавим още няколко (некласифицирани) съставки.

Тестовата среда ще се промени, защото е интересно да се изследват възможностите за автоматизация, работа с контейнери и изпробване на среди с множество сървъри. За да започнете с нов проект, можете да започнете, като създадете малък, прост прототип на ръка, за да можете да видите точно какво трябва да се случи и как взаимодейства, след което преминете към автоматизиране и създаване на по-сложни конфигурации. Днес говорим за създаването на такъв прототип.

Нека започнем с внедряването на RHEL 8 Beta VM изображение. Можете да инсталирате виртуална машина от нулата или да използвате изображението за гости на KVM, налично с вашия бета абонамент. Когато използвате изображение за гост, ще трябва да конфигурирате виртуален компактдиск, който ще съдържа метаданни и потребителски данни за инициализация в облак (cloud-init). Не е необходимо да правите нищо специално със структурата на диска или наличните пакети; всяка конфигурация ще свърши работа.

Нека разгледаме по-отблизо целия процес.

Инсталиране на Django

С най-новата версия на Django ще ви трябва виртуална среда (virtualenv) с Python 3.5 или по-нова версия. В бета бележките можете да видите, че 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. Повече информация за промените и защо са направени можете да намерите в публикацията в Блогът на Лангдън Уайт (Лангдън Уайт).

Така че, за да получите работещ Python, трябва само да инсталирате два пакета, като python3-pip е включен като зависимост.

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, но трябва да е наличен само във виртуална среда, така че ще го инсталираме с помощта на 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, е скриптът за настройка на postgresql, който е инсталиран с пакета postgresql-сървър. Този скрипт ви помага да изпълнявате основни задачи, свързани с администрирането на клъстер на база данни, като инициализация на клъстер или процес на надграждане. За да конфигурираме нов екземпляр на 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 в проекта и настроите конфигурацията на базата данни, можете да стартирате сървъра за разработка, за да сте сигурни, че всичко работи. След стартиране на сървъра за разработка е добра идея да създадете администраторски потребител, за да тествате връзката с базата данни.

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

WSGI? Уай?

Сървърът за разработка е полезен за тестване, но за да стартирате приложението, трябва да конфигурирате подходящия сървър и прокси за интерфейса на шлюза на уеб сървъра (WSGI). Има няколко общи комбинации, например Apache HTTPD с uWSGI или Nginx с Gunicorn.

Задачата на интерфейса на шлюза на уеб сървъра е да препраща заявки от уеб сървъра към уеб рамката на Python. WSGI е реликва от ужасното минало, когато CGI двигателите са били наоколо, а днес WSGI е де факто стандартът, независимо от използвания уеб сървър или рамка на Python. Но въпреки широкото им използване, все още има много нюанси при работа с тези рамки и много възможности за избор. В този случай ще се опитаме да установим взаимодействие между Gunicorn и Nginx чрез сокет.

Тъй като и двата компонента са инсталирани на един и същи сървър, нека опитаме да използваме UNIX сокет вместо мрежов сокет. Тъй като комуникацията във всеки случай изисква сокет, нека се опитаме да направим още една стъпка и да конфигурираме активиране на сокет за Gunicorn чрез systemd.

Процесът на създаване на услуги, активирани от сокет, е доста прост. Първо се създава единичен файл, който съдържа директива ListenStream, сочеща към точката, в която ще бъде създаден UNIX сокетът, след това единичен файл за услугата, в която директивата Requires ще сочи към сокетния единичен файл. След това, във файла на сервизната единица, всичко, което остава, е да извикате Gunicorn от виртуалната среда и да създадете WSGI свързване за UNIX сокета и приложението Django.

Ето няколко примера за модулни файлове, които можете да използвате като основа. Първо настроихме гнездото.

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

Стартирайте сокета Gunicorn и Nginx с помощта на systemd и сте готови да започнете тестването.

Грешка в лошия шлюз?

Ако въведете адреса в браузъра си, най-вероятно ще получите грешка 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. Тъй като изпълняваме демон, за който не е създадена политика, той е маркиран като init_t. Нека проверим тази теория на практика.

sudo setenforce 0

Всичко това може да предизвика критики и кървави сълзи, но това е само отстраняване на грешки в прототипа. Нека деактивираме проверката само за да се уверим, че това е проблемът, след което ще върнем всичко на мястото му.

Като опресните страницата в браузъра или изпълните отново нашата 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 блокира нещо друго освен това, до което нашият неизвестен демон има достъп.

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 ще трябва да се рестартира, преди да може да бъде избран новият етикет. Можете да го рестартирате веднага или да спрете услугата и да оставите сокета да я стартира, когато отворите сайта в браузъра. Проверете дали процесите са получили правилните етикети с помощта на 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. Сега можете да продължите напред и да създадете (или просто да внедрите) Django приложения или да изследвате други налични инструменти в RHEL 8 Beta, за да автоматизирате процеса на конфигуриране, да подобрите производителността или дори да контейнеризирате тази конфигурация.

Източник: www.habr.com