ワークショップ RHEL 8 ベータ: 動作する Web アプリケーションの構築

RHEL 8 ベータ版は開発者に多くの新機能を提供しており、そのリストを説明するには何ページもかかる場合がありますが、実際に新しいことを学ぶことは常に良いことです。そのため、以下では、Red Hat Enterprise Linux 8 ベータ版に基づいてアプリケーション インフラストラクチャを実際に作成するためのワークショップを提供します。

開発者の間で人気のあるプログラミング言語である Python をベースとして、アプリケーション作成によく使用される Django と PostgreSQL の組み合わせを使用し、それらと連携できるように RHEL 8 ベータを構成してみましょう。 次に、さらにいくつかの (未分類の) 材料を追加します。

自動化の可能性を探ったり、コンテナーを操作したり、複数のサーバーを使用した環境を試したりするのは興味深いため、テスト環境は変更されます。 新しいプロジェクトを開始するには、小さくて単純なプロトタイプを手動で作成することから始めて、何が起こる必要があるのか​​、どのように相互作用するのかを正確に確認してから、より複雑な構成の自動化と作成に進むことができます。 今日はそのようなプロトタイプの作成について話します。

RHEL 8 ベータ VM イメージをデプロイすることから始めましょう。 仮想マシンを最初からインストールすることも、ベータ サブスクリプションで利用可能な KVM ゲスト イメージを使用することもできます。 ゲスト イメージを使用する場合は、クラウド初期化 (cloud-init) 用のメタデータとユーザー データを含む仮想 CD を構成する必要があります。 ディスク構造や利用可能なパッケージに関して特別なことを行う必要はなく、任意の構成で十分です。

プロセス全体を詳しく見てみましょう。

Django のインストール

最新バージョンの 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 が含まれている XNUMX つのパッケージをインストールするだけで済みます。

sudo yum install python36 python3-virtualenv

Langdon が提案しているように、直接モジュール呼び出しを使用して pip3 をインストールしてはどうでしょうか? 今後の自動化を念頭に置いて、pip モジュールはカスタム pip 実行可能ファイルを含む virtualenvs をサポートしていないため、Ansible を実行するには pip がインストールされている必要があることが知られています。

動作する python3 インタープリタを自由に使えるので、Django のインストール プロセスを続行し、他のコンポーネントとともに動作するシステムを手に入れることができます。 インターネット上には多くの実装オプションが用意されています。 ここでは XNUMX つのバージョンが示されていますが、ユーザーは独自のプロセスを使用できます。

Yum を使用して、デフォルトで RHEL 8 で利用可能な PostgreSQL および Nginx バージョンをインストールします。

sudo yum install nginx postgresql-server

PostgreSQL には psycopg2 が必要ですが、virtualenv 環境でのみ利用できる必要があるため、Django および Gunicorn とともに pip3 を使用してインストールします。 ただし、最初に virtualenv を設定する必要があります。

Django プロジェクトをインストールする適切な場所を選択するというテーマについては、常に多くの議論が行われていますが、迷った場合には、いつでも Linux ファイルシステム階層標準を参照することができます。 具体的には、FHS によれば、/srv は「ホスト固有のデータ、つまり Web サーバーのデータやスクリプト、FTP サーバーに保存されたデータ、制御システム リポジトリなど、システムが生成するデータを保存する」ために使用されると述べられています。 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 を最初にインストールするときに留意すべき点の XNUMX つは、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? ワイ？

開発サーバーはテストには便利ですが、アプリケーションを実行するには、Web サーバー ゲートウェイ インターフェイス (WSGI) 用に適切なサーバーとプロキシを構成する必要があります。 たとえば、Apache HTTPD と uWSGI、Nginx と Gunicorn など、一般的な組み合わせがいくつかあります。

Web サーバー ゲートウェイ インターフェイスの仕事は、Web サーバーから Python Web フレームワークにリクエストを転送することです。 WSGI は CGI エンジンが存在していた恐ろしい過去の名残であり、現在では、使用されている Web サーバーや Python フレームワークに関係なく、WSGI が事実上の標準となっています。 しかし、広く使用されているにもかかわらず、これらのフレームワークを使用する場合には依然として多くの微妙な違いがあり、多くの選択肢があります。 この場合、ソケットを介して 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 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) を宣言し、システムが正しくマークするための遷移をセットアップします。実行中のプロセス。 最後の行は、ポリシーがロードされたときにデフォルトで有効になるように設定します。

ガニコーン.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 としてマークする必要があるかを把握する必要があります。また。 Web サイトにアクセスして、アクセス制限に関する新しいメッセージを確認してみましょう。

sudo ausearch -m AVC -c gunicorn

/srv/djangoapp 内のファイルに対してさまざまな処理を行う「comm="gunicorn"」を含むメッセージが多数表示されるため、これは明らかにフラグを立てる価値のあるコマンドの XNUMX つです。

ただし、さらに次のようなメッセージが表示されます。

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 インタープリターにアクセスしようとしているようです。 それでは、これら XNUMX つの実行可能ファイルにマークを付けて、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 ベータで他の利用可能なツールを探索して、構成プロセスを自動化し、パフォーマンスを向上させたり、この構成をコンテナ化したりすることができます。

出所： habr.com