워크샵 RHEL 8 베타: 작동하는 웹 애플리케이션 구축

RHEL 8 베타는 개발자에게 많은 새로운 기능을 제공하며 목록을 작성하는 데는 몇 페이지가 걸릴 수 있습니다. 그러나 실제로는 새로운 것을 배우는 것이 항상 더 좋습니다. 따라서 아래에서는 Red Hat Enterprise Linux 8 베타를 기반으로 애플리케이션 인프라를 실제로 생성하는 방법에 대한 워크숍을 제공합니다.

개발자들 사이에서 널리 사용되는 프로그래밍 언어인 Python을 기반으로 애플리케이션 생성을 위한 상당히 일반적인 조합인 Django와 PostgreSQL의 조합을 사용하고 이들과 함께 작동하도록 RHEL 8 Beta를 구성해 보겠습니다. 그런 다음 (분류되지 않은) 재료를 몇 가지 더 추가하겠습니다.

자동화의 가능성을 탐구하고, 컨테이너로 작업하고, 여러 서버로 환경을 시도하는 것이 흥미롭기 때문에 테스트 환경이 바뀔 것입니다. 새 프로젝트를 시작하려면 먼저 작고 간단한 프로토타입을 직접 만들어서 무슨 일이 일어나야 하는지, 어떻게 상호 작용하는지 정확히 확인한 다음 자동화하여 더 복잡한 구성을 만들 수 있습니다. 오늘 우리는 그러한 프로토타입을 만드는 것에 대해 이야기하고 있습니다.

RHEL 8 베타 VM 이미지 배포부터 시작해 보겠습니다. 가상 머신을 처음부터 설치하거나 베타 구독에서 제공되는 KVM 게스트 이미지를 사용할 수 있습니다. 게스트 이미지를 사용하는 경우 클라우드 초기화(cloud-init)를 위한 메타데이터 및 사용자 데이터를 포함할 가상 CD를 ​​구성해야 합니다. 디스크 구조나 사용 가능한 패키지에 대해 특별한 작업을 수행할 필요는 없으며 어떤 구성이든 수행됩니다.

전체 과정을 자세히 살펴보겠습니다.

장고 설치

최신 버전의 Django를 사용하려면 Python 3.5 이상이 설치된 가상 환경(virtualenv)이 필요합니다. 베타 노트에서 Python 3.6을 사용할 수 있음을 확인할 수 있습니다. 이것이 실제로 해당되는지 확인해 보겠습니다.

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

Red Hat은 RHEL에서 Python을 시스템 툴킷으로 적극적으로 사용하는데, 이런 결과가 나오는 이유는 무엇입니까?

사실 많은 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을 설치하는 것은 어떨까요? 다가오는 자동화를 염두에 두고, pip 모듈은 사용자 정의 pip 실행 파일이 있는 virtualenv를 지원하지 않기 때문에 Ansible을 실행하려면 pip가 설치되어 있어야 하는 것으로 알려져 있습니다.

작동 중인 Python3 인터프리터를 사용하여 Django 설치 프로세스를 계속 진행하고 다른 구성 요소와 함께 작동하는 시스템을 가질 수 있습니다. 인터넷에는 다양한 구현 옵션이 있습니다. 여기에는 하나의 버전이 제시되어 있지만 사용자는 자신의 프로세스를 사용할 수 있습니다.

기본적으로 Yum을 사용하여 RHEL 8에서 사용 가능한 PostgreSQL 및 Nginx 버전을 설치합니다.

sudo yum install nginx postgresql-server

PostgreSQL에는 psycopg2가 필요하지만 virtualenv 환경에서만 사용할 수 있어야 하므로 Django 및 Gunicorn과 함께 pip3을 사용하여 설치하겠습니다. 하지만 먼저 virtualenv를 설정해야 합니다.

Django 프로젝트를 설치할 올바른 위치를 선택하는 주제에 대해서는 항상 많은 논쟁이 있지만, 의심스러울 경우 언제든지 Linux Filesystem Hierarchy Standard를 참고할 수 있습니다. 특히 FHS는 /srv가 "호스트별 데이터(웹 서버 데이터 및 스크립트, FTP 서버에 저장된 데이터, 제어 시스템 저장소 등 시스템이 생성하는 데이터)를 저장하는 데 사용됩니다." 버전(FHS에 표시됨)에 대해 설명합니다. 2.3년에는 -2004)."

이것이 바로 우리의 경우이므로 필요한 모든 것을 애플리케이션 사용자(클라우드 사용자)가 소유한 /srv에 넣습니다.

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-server 패키지와 함께 설치되는 postgresql-setup 스크립트입니다. 이 스크립트는 클러스터 초기화 또는 업그레이드 프로세스와 같은 데이터베이스 클러스터 관리와 관련된 기본 작업을 수행하는 데 도움이 됩니다. RHEL 시스템에서 새 PostgreSQL 인스턴스를 구성하려면 다음 명령을 실행해야 합니다.

sudo /usr/bin/postgresql-setup -initdb

그런 다음 systemd를 사용하여 PostgreSQL을 시작하고, 데이터베이스를 생성하고, Django에서 프로젝트를 설정할 수 있습니다. 애플리케이션 사용자에 대한 비밀번호 저장소를 구성하려면 클라이언트 인증 구성 파일(일반적으로 pg_hba.conf)을 변경한 후 PostgreSQL을 다시 시작해야 합니다. 다른 문제가 발생하면 pg_hba.conf 파일에서 IPv4 및 IPv6 설정을 변경해야 합니다.

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(웹 서버 게이트웨이 인터페이스)에 적합한 서버와 프록시를 구성해야 합니다. 예를 들어 uWSGI가 포함된 Apache HTTPD 또는 Gunicorn이 포함된 Nginx와 같은 몇 가지 일반적인 조합이 있습니다.

웹 서버 게이트웨이 인터페이스의 역할은 웹 서버의 요청을 Python 웹 프레임워크로 전달하는 것입니다. WSGI는 CGI 엔진이 존재했던 끔찍한 과거의 유물이며, 오늘날 WSGI는 사용되는 웹 서버나 Python 프레임워크에 관계없이 사실상의 표준입니다. 그러나 널리 사용됨에도 불구하고 이러한 프레임워크로 작업할 때 여전히 미묘한 차이가 많고 선택 사항도 많습니다. 이 경우 소켓을 통해 Gunicorn과 Nginx 간의 상호 작용을 설정하려고 합니다.

이 두 구성 요소는 모두 동일한 서버에 설치되므로 네트워크 소켓 대신 UNIX 소켓을 사용해 보겠습니다. 어떤 경우든 통신에는 소켓이 필요하므로 한 단계 더 나아가 systemd를 통해 Gunicorn에 대한 소켓 활성화를 구성해 보겠습니다.

소켓 활성화 서비스를 생성하는 과정은 매우 간단합니다. 먼저, UNIX 소켓이 생성될 지점을 가리키는 ListenStream 지시어가 포함된 유닛 파일이 생성되고, 그런 다음 Requires 지시어가 소켓 유닛 파일을 가리키는 서비스에 대한 유닛 파일이 생성됩니다. 그런 다음 서비스 단위 파일에 남은 것은 가상 환경에서 Gunicorn을 호출하고 UNIX 소켓 및 Django 애플리케이션에 대한 WSGI 바인딩을 생성하는 것입니다.

다음은 기초로 사용할 수 있는 단위 파일의 몇 가지 예입니다. 먼저 소켓을 설정합니다.

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

systemd를 사용하여 Gunicorn 소켓과 Nginx를 시작하면 테스트를 시작할 준비가 된 것입니다.

잘못된 게이트웨이 오류인가요?

브라우저에 주소를 입력하면 502 잘못된 게이트웨이 오류가 발생할 가능성이 높습니다. 이는 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

이 모든 것이 비판과 피눈물을 낳을 수 있지만 이는 프로토타입을 디버깅하는 것일 뿐입니다. 이것이 문제인지 확인하기 위해 검사를 비활성화한 다음 모든 것을 원래 위치로 되돌립니다.

브라우저에서 페이지를 새로 고치거나 컬 명령을 다시 실행하면 Django 테스트 페이지를 볼 수 있습니다.

따라서 모든 것이 작동하고 더 이상 권한 문제가 없는지 확인한 후 SELinux를 다시 활성화합니다.

sudo setenforce 1

현재 실제 Django 애플리케이션이 없기 때문에 audit2allow나 sepolgen을 사용하여 경고 기반 정책을 생성하는 것에 대해 이야기하지 않을 것입니다. 따라서 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가 Gunicorn에서 사용하는 UNIX 소켓에 데이터를 쓰는 것을 방지합니다. 일반적으로 이러한 경우 정책이 변경되기 시작하지만 앞에는 다른 과제가 있습니다. 제한 도메인에서 권한 도메인으로 도메인 설정을 변경할 수도 있습니다. 이제 httpd_t를 권한 도메인으로 이동해 보겠습니다. 이렇게 하면 Nginx에 필요한 액세스 권한이 부여되고 추가 디버깅 작업을 계속할 수 있습니다.

sudo semanage permissive -a httpd_t

따라서 SELinux를 보호한 상태로 유지하고(SELinux 프로젝트를 제한 모드로 놔두어서는 안 됨) 권한 도메인이 로드되면 모든 것이 제대로 작동하도록 하려면 정확히 무엇이 gunicorn_exec_t로 ​​표시되어야 하는지 파악해야 합니다. 다시. 액세스 제한에 대한 새로운 메시지를 보려면 웹사이트를 방문해 보세요.

sudo ausearch -m AVC -c gunicorn

/srv/djangoapp의 파일에 대해 다양한 작업을 수행하는 'comm="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

gunicorn 서비스의 상태를 확인하거나 ps 명령을 실행하면 실행 중인 프로세스가 표시되지 않습니다. gunicorn이 작업자 스크립트를 실행하기 위해 virtualenv 환경에서 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이 포함되어 있습니다. 실제 애플리케이션에 어떤 종류의 액세스가 필요한지 이해하면 이러한 문제를 해결하는 가장 좋은 방법을 빠르게 찾을 수 있습니다. 하지만 그때까지는 시스템을 안전하게 유지하고 Django 프로젝트에 대해 명확하고 유용한 감사를 받는 것이 가장 좋습니다.

sudo ausearch -m AVC

그것은 나왔다!

Nginx와 Gunicorn WSGI를 기반으로 하는 프론트엔드를 갖춘 작동하는 Django 프로젝트가 등장했습니다. RHEL 3 베타 리포지토리에서 Python 10 및 PostgreSQL 8을 구성했습니다. 이제 Django 애플리케이션을 생성(또는 간단히 배포)하거나 RHEL 8 Beta에서 사용 가능한 다른 도구를 탐색하여 구성 프로세스를 자동화하고 성능을 향상시키거나 이 구성을 컨테이너화할 수도 있습니다.

출처 : habr.com