Работилница RHEL 8 Beta: Градење работни веб-апликации

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

Зошто да не користите директни повици на модул како што предлага Лангдон и да не инсталирате pip3? Имајќи ја предвид претстојната автоматизација, познато е дека Ansible ќе бара инсталиран пип за да работи, бидејќи модулот pip не поддржува virtualenvs со прилагодена извршна датотека за пип.

Со работен преведувач на python3 на располагање, можете да продолжите со процесот на инсталација на Django и да имате работен систем заедно со нашите други компоненти. Постојат многу опции за имплементација достапни на Интернет. Постои една верзија претставена овде, но корисниците можат да ги користат сопствените процеси.

Ќе ги инсталираме верзиите PostgreSQL и Nginx достапни во RHEL 8 стандардно користејќи Yum.

sudo yum install nginx postgresql-server

PostgreSQL ќе бара psycopg2, но треба да биде достапен само во виртуелна средина, така што ќе го инсталираме користејќи pip3 заедно со Django и Gunicorn. Но, прво треба да поставиме virtualenv.

Секогаш има многу дебати на темата за избор на вистинското место за инсталирање проекти на Django, но кога се сомневате, секогаш можете да се свртите кон стандардот за хиерархија на датотечниот систем Linux. Поточно, 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.

Работата на интерфејсот на портата на веб-серверот е да препраќа барања од веб-серверот до веб-рамката на Пајтон. 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 {
   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 во нашата виртуелна средина, можеби за да изврши работни скрипти. Сега, ајде да ги означиме овие две извршни датотеки и да провериме дали можеме да ја отвориме нашата тест страница за 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 за остатокот од системот. Ако разбирате каков пристап и треба на вистинска апликација, можете брзо да го најдете најдобриот начин за решавање на ваквите проблеми. Но, дотогаш, најдобро е системот да биде безбеден и да се добие јасна, употреблива ревизија на проектот Џанго.

sudo ausearch -m AVC

Се случи!

Се појави работен проект Django со фронтанд базиран на Nginx и Gunicorn WSGI. Ги конфигуриравме Python 3 и PostgreSQL 10 од RHEL 8 Beta складиштата. Сега можете да се движите напред и да креирате (или едноставно да распоредите) Django апликации или да истражувате други достапни алатки во RHEL 8 Beta за да го автоматизирате процесот на конфигурација, да ги подобрите перформансите или дури и да ја контејнеризирате оваа конфигурација.

Извор: www.habr.com