РХЕЛ 8 Бета нуди програмерима многе нове функције, чија листа може да заузме странице, међутим, учење нових ствари је увек боље у пракси, па у наставку нудимо радионицу о стварном креирању инфраструктуре апликације засноване на Ред Хат Ентерприсе Линук 8 Бета.
Узмимо за основу Питхон, популарни програмски језик међу програмерима, комбинацију Дјанго и ПостгреСКЛ, прилично уобичајену комбинацију за креирање апликација, и конфигуришите РХЕЛ 8 Бета да ради са њима. Затим ћемо додати још пар (некласификованих) састојака.
Тестно окружење ће се променити, јер је занимљиво истражити могућности аутоматизације, рада са контејнерима и испробавање окружења са више сервера. Да бисте започели са новим пројектом, можете започети креирањем малог, једноставног прототипа ручно како бисте могли тачно да видите шта треба да се деси и како то делује, а затим пређите на аутоматизацију и креирање сложенијих конфигурација. Данас говоримо о стварању таквог прототипа.
Почнимо са постављањем РХЕЛ 8 Бета ВМ слике. Можете да инсталирате виртуелну машину од нуле или да користите КВМ слику госта која је доступна уз вашу Бета претплату. Када користите слику госта, мораћете да конфигуришете виртуелни ЦД који ће садржати метаподатке и корисничке податке за иницијализацију облака (цлоуд-инит). Не морате ништа посебно да радите са структуром диска или доступним пакетима.
Хајде да детаљније погледамо цео процес.
Инсталирање Дјанга
Са најновијом верзијом Дјанга, биће вам потребно виртуелно окружење (виртуаленв) са Питхон-ом 3.5 или новијим. У бета белешкама можете видети да је Питхон 3.6 доступан, хајде да проверимо да ли је то заиста случај:
[cloud-user@8beta1 ~]$ python
-bash: python: command not found
[cloud-user@8beta1 ~]$ python3
-bash: python3: command not found
Ред Хат активно користи Питхон као системски комплет алата у РХЕЛ-у, па зашто је то резултат?
Чињеница је да многи програмери Питхон-а још увек размишљају о преласку са Питхон-а 2 на Питхон 2, док је сам Питхон 3 у активном развоју, а све више и више нових верзија се стално појављује. Због тога, да би се задовољила потреба за стабилним системским алатима док корисницима нуди приступ разним новим верзијама Питхон-а, системски Питхон је пребачен у нови пакет и пружа могућност инсталирања и Питхон-а 2.7 и 3.6. Више информација о променама и зашто су оне направљене можете пронаћи у публикацији у (Лангдон Вајт).
Дакле, да би Питхон почео да ради, потребно је да инсталирате само два пакета, са укљученим питхон3-пип као зависношћу.
sudo yum install python36 python3-virtualenv
Зашто не користите директне позиве модула као што Лангдон предлаже и инсталирате пип3? Имајући у виду предстојећу аутоматизацију, познато је да ће Ансибле захтевати инсталиран пип за покретање, пошто пип модул не подржава виртуаленвс са прилагођеним извршним пип-ом.
Са исправним питхон3 интерпретатором који вам је на располагању, можете наставити са процесом инсталације Дјанга и имати радни систем заједно са нашим осталим компонентама. Постоји много опција имплементације које су доступне на Интернету. Овде је представљена једна верзија, али корисници могу да користе сопствене процесе.
Инсталираћемо ПостгреСКЛ и Нгинк верзије доступне у РХЕЛ 8 подразумевано користећи Иум.
sudo yum install nginx postgresql-server
ПостгреСКЛ ће захтевати псицопг2, али мора бити доступан само у виртуелном окружењу, тако да ћемо га инсталирати користећи пип3 заједно са Дјангом и Гуницорн-ом. Али прво морамо да подесимо виртуаленв.
Увек постоји много дебата на тему избора правог места за инсталацију Дјанго пројеката, али када сте у недоумици, увек се можете обратити Линук стандарду хијерархије система датотека. Конкретно, ФХС каже да се /срв користи за: „чување података специфичних за хост – података које систем производи, као што су подаци веб сервера и скрипте, подаци који се чувају на ФТП серверима и контролне верзије система (који се појављују у ФХС-у). -2.3 у 2004).“
Ово је управо наш случај, тако да смо све што нам треба ставили у /срв, који је у власништву корисника наше апликације (цлоуд-усер).
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
Подешавање ПостгреСКЛ-а и Дјанго-а је једноставно: креирајте базу података, креирајте корисника, конфигуришите дозволе. Једна ствар коју треба имати на уму када почетно инсталирате ПостгреСКЛ је скрипта постгрескл-сетуп која се инсталира са пакетом постгрескл-сервер. Ова скрипта вам помаже да извршите основне задатке повезане са администрацијом кластера базе података, као што је иницијализација кластера или процес надоградње. Да бисмо конфигурисали нову ПостгреСКЛ инстанцу на РХЕЛ систему, морамо да покренемо наредбу:
sudo /usr/bin/postgresql-setup -initdb
Затим можете покренути ПостгреСКЛ користећи системд, креирати базу података и подесити пројекат у Дјангу. Не заборавите да поново покренете ПостгреСКЛ након што унесете промене у конфигурациони фајл за аутентификацију клијента (обично пг_хба.цонф) да бисте конфигурисали складиште лозинке за корисника апликације. Ако наиђете на друге потешкоће, обавезно промените ИПв4 и ИПв6 подешавања у датотеци пг_хба.цонф.
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
У датотеци /вар/либ/пгскл/дата/пг_хба.цонф:
# IPv4 local connections:
host all all 0.0.0.0/0 md5
# IPv6 local connections:
host all all ::1/128 md5
У датотеци /срв/дјангоапп/сеттингс.пи:
# Database
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': '{{ db_name }}',
'USER': '{{ db_user }}',
'PASSWORD': '{{ db_password }}',
'HOST': '{{ db_host }}',
}
}
Након конфигурисања датотеке сеттингс.пи у пројекту и подешавања конфигурације базе података, можете покренути развојни сервер да бисте били сигурни да све функционише. Након покретања развојног сервера, добра је идеја да направите администраторског корисника како бисте тестирали везу са базом података.
./manage.py runserver 0.0.0.0:8000
./manage.py createsuperuser
ВСГИ? Ваи?
Развојни сервер је користан за тестирање, али да бисте покренули апликацију морате да конфигуришете одговарајући сервер и прокси за интерфејс мрежног пролаза веб сервера (ВСГИ). Постоји неколико уобичајених комбинација, на пример, Апацхе ХТТПД са уВСГИ или Нгинк са Гуницорн.
Посао интерфејса мрежног пролаза веб сервера је да проследи захтеве са веб сервера на Питхон веб оквир. ВСГИ је реликт ужасне прошлости када су ЦГИ мотори постојали, а данас је ВСГИ де фацто стандард, без обзира на коришћени веб сервер или Питхон фрамеворк. Али упркос широкој употреби, још увек постоји много нијанси када радите са овим оквирима и много избора. У овом случају, покушаћемо да успоставимо интеракцију између Гуницорн-а и Нгинк-а преко соцкета.
Пошто су обе ове компоненте инсталиране на истом серверу, покушајмо да користимо УНИКС утичницу уместо мрежне утичнице. Пошто комуникација у сваком случају захтева сокет, хајде да покушамо да направимо још један корак и конфигуришемо активацију утичнице за Гуницорн преко системд-а.
Процес креирања услуга активираних сокетом је прилично једноставан. Прво се креира јединична датотека која садржи директиву ЛистенСтреам која указује на тачку у којој ће се креирати УНИКС сокет, затим јединична датотека за услугу у којој ће директива Рекуирес указивати на датотеку јединице утичнице. Затим, у датотеци сервисне јединице, остаје само да позовете Гуницорн из виртуелног окружења и креирате ВСГИ везу за УНИКС сокет и Дјанго апликацију.
Ево неколико примера јединичних датотека које можете користити као основу. Прво смо поставили утичницу.
[Unit]
Description=Gunicorn WSGI socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
Сада морате да конфигуришете Гуницорн демона.
[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
За Нгинк је једноставно креирање конфигурационих датотека проксија и подешавање директоријума за складиштење статичког садржаја ако га користите. У РХЕЛ-у, Нгинк конфигурационе датотеке се налазе у /етц/нгинк/цонф.д. Можете копирати следећи пример у датотеку /етц/нгинк/цонф.д/дефаулт.цонф и покренути услугу. Обавезно подесите сервер_наме тако да одговара вашем имену хоста.
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;
}
}
Покрените Гуницорн соцкет и Нгинк користећи системд и спремни сте за почетак тестирања.
Грешка лошег мрежног пролаза?
Ако унесете адресу у свој претраживач, највероватније ћете добити грешку 502 Бад Гатеваи. То може бити узроковано погрешно конфигурисаним дозволама УНИКС сокета, или може бити због сложенијих проблема везаних за контролу приступа у СЕЛинук-у.
У нгинк евиденцији грешака можете видети ову линију:
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"
Ако директно тестирамо Гуницорн, добићемо празан одговор.
curl —unix-socket /run/gunicorn.sock 8beta1.example.com
Хајде да схватимо зашто се то дешава. Ако отворите дневник, највероватније ћете видети да је проблем повезан са СЕЛинук-ом. Пошто покрећемо демон за који није креирана политика, он је означен као инит_т. Хајде да тестирамо ову теорију у пракси.
sudo setenforce 0
Све ово може изазвати критике и крвне сузе, али ово је само отклањање грешака прототипа. Хајде да онемогућимо проверу само да бисмо се уверили да је то проблем, након чега ћемо све вратити на своје место.
Освежавањем странице у претраживачу или поновним покретањем наше команде цурл, можете видети Дјанго тест страницу.
Дакле, након што смо се уверили да све функционише и да више нема проблема са дозволама, поново омогућавамо СЕЛинук.
sudo setenforce 1
Нећу овде да говорим о аудит2аллов или креирању смерница заснованих на упозорењима са сеполгеном, пошто тренутно не постоји стварна Дјанго апликација, тако да не постоји потпуна мапа чему би Гуницорн могао да приступи и чему би требало да забрани приступ. Због тога је неопходно да се СЕЛинук настави да ради да би се систем заштитио, док истовремено дозвољавате апликацији да се покрене и оставља поруке у евиденцији ревизије тако да се стварна политика може креирати од њих.
Одређивање дозвољених домена
Нису сви чули за дозвољене домене у СЕЛинуку, али они нису ништа ново. Многи су чак и радили са њима а да тога нису ни свесни. Када се политика креира на основу порука ревизије, креирана политика представља разрешени домен. Хајде да покушамо да креирамо једноставну политику издавања дозвола.
Да бисте креирали одређени дозвољени домен за Гуницорн, потребна вам је нека врста политике, а потребно је и да означите одговарајуће датотеке. Поред тога, потребни су алати за састављање нових политика.
sudo yum install selinux-policy-devel
Механизам дозвољених домена је одличан алат за идентификацију проблема, посебно када је у питању прилагођена апликација или апликације које се испоручују без већ креираних политика. У овом случају, дозвољена политика домена за Гуницорн ће бити што је могуће једноставнија - прогласите главни тип (гуницорн_т), прогласите тип који ћемо користити да означимо више извршних датотека (гуницорн_екец_т), а затим подесите прелаз да систем исправно означи покренути процеси. Последњи ред поставља политику као подразумевано омогућену у тренутку када се учита.
гуницорн.те:
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
Хајде да проверимо да ли СЕЛинук блокира нешто друго осим ономе чему приступа наш непознати демон.
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
СЕЛинук спречава Нгинк да уписује податке у УНИКС сокет који користи Гуницорн. Обично у таквим случајевима политике почињу да се мењају, али пред нама су други изазови. Такође можете да промените подешавања домена са домена ограничења на домен дозволе. Сада преместимо хттпд_т на домен дозвола. Ово ће дати Нгинк-у неопходан приступ и можемо наставити са даљим радом на отклањању грешака.
sudo semanage permissive -a httpd_t
Дакле, када сте успели да сачувате СЕЛинук заштићен (заиста не би требало да остављате СЕЛинук пројекат у ограниченом режиму) и када се домени дозвола учитају, морате да схватите шта тачно треба да буде означено као гуницорн_екец_т да би све функционисало како треба опет. Покушајмо да посетимо веб локацију да бисмо видели нове поруке о ограничењима приступа.
sudo ausearch -m AVC -c 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
Ако погледате статус услуге гуницорн или покренете команду пс, нећете видети покренуте процесе. Изгледа да гуницорн покушава да приступи Питхон интерпретеру у нашем виртуаленв окружењу, вероватно да би покренуо радне скрипте. Дакле, хајде да сада означимо ове две извршне датотеке и проверимо да ли можемо да отворимо нашу Дјанго тест страницу.
chcon -t gunicorn_exec_t /srv/djangoapp/django/bin/gunicorn /srv/djangoapp/django/bin/python3.6
Гуницорн услугу ће морати поново покренути пре него што се може изабрати нова ознака. Можете га одмах поново покренути или зауставити услугу и пустити сокету да га покрене када отворите локацију у претраживачу. Проверите да ли су процеси примили исправне ознаке помоћу пс.
ps -efZ | grep gunicorn
Не заборавите да касније креирате нормалну СЕЛинук политику!
Ако сада погледате АВЦ поруке, последња порука садржи пермиссиве=1 за све што се односи на апликацију и пермиссиве=0 за остатак система. Ако разумете какав приступ је потребан стварној апликацији, можете брзо пронаћи најбољи начин да решите такве проблеме. Али до тада, најбоље је да систем буде сигуран и да добијете јасну, употребљиву ревизију Дјанго пројекта.
sudo ausearch -m AVC
Десило!
Појавио се радни Дјанго пројекат са фронтендом заснованим на Нгинк-у и Гуницорн ВСГИ. Конфигурисали смо Питхон 3 и ПостгреСКЛ 10 из РХЕЛ 8 Бета спремишта. Сада можете да наставите даље и направите (или једноставно примените) Дјанго апликације или истражите друге доступне алате у РХЕЛ 8 Бета да бисте аутоматизовали процес конфигурације, побољшали перформансе или чак спремили ту конфигурацију.
Извор: ввв.хабр.цом