PHP と Docker の例を含む Twelve-Factor App 方法論に基づいたアプリケーション開発と Blue-Green デプロイメント

まず、ちょっとした理論です。 どうしたの Twelve-Factor アプリ?

簡単に言えば、このドキュメントは SaaS アプリケーションの開発を簡素化することを目的として設計されており、最新のアプリケーションの開発で最も頻繁に遭遇する問題と実践方法について開発者と DevOps エンジニアに知らせることに役立ちます。

このドキュメントは Heroku プラットフォームの開発者によって作成されました。

Twelve-Factor アプリは、任意のプログラミング言語で記述され、バッキング サービス (データベース、メッセージ キュー、キャッシュなど) を任意に組み合わせて使用​​するアプリケーションに適用できます。

この方法論の基礎となる要素について簡単に説明します。

1. コードベース – バージョン管理で追跡される XNUMX つのコードベース – 複数のデプロイメント
2. 依存関係 – 依存関係を明示的に宣言して分離する
3. 設定 – 実行時に構成を保存する
4. 支援サービス – プラグイン リソースとしてのバッキング サービスを検討する
5. ビルド、リリース、実行 – 組み立て段階と実行段階を厳密に分離する
6. Процессы – アプリケーションを XNUMX つ以上のステートレス プロセスとして実行する
7. ポートバインディング – ポート バインディング経由でサービスをエクスポートする
8. 並列処理 – プロセスを使用してアプリケーションをスケールする
9. 使い捨て性 – 高速起動とクリーンなシャットダウンにより信頼性を最大化
10. アプリケーション開発/運用の同等性 – 開発環境、ステージング環境、実稼働環境を可能な限り類似した状態に保ちます
11. ロギング – ログをイベントのストリームとして表示する
12. 管理タスク – アドホックプロセスを使用して管理/管理タスクを実行する

12 の要素についての詳細は、次のリソースから入手できます。

• 公式ソース - 必読
• ハブに関する記事。 Twelve-Factor アプリ — 公式翻訳
• ハブに関する記事。 7 Factor アプリに欠けている 12 つの要素 - 改善を目的とした 12 の要素の再検討。

ブルーグリーン展開とは何ですか?

Blue-Green デプロイメントは、アプリケーションを配信する方法です。 製造 エンドクライアントが自分側の変更を認識しないような方法で。 つまり、ゼロでアプリケーションをデプロイします。 ダウンタイム.

古典的な BG Deploy スキームは、以下の画像のようになります。

• 開始時点では、まったく同じコード、アプリケーション、プロジェクトを持つ 2 台の物理サーバーがあり、ルーター (バランサー) があります。
• ルーターは最初にすべてのリクエストをいずれかのサーバー (グリーン).
• 再度リリースする必要がある時点で、プロジェクト全体が別のサーバーで更新されます (ブルー)、現在リクエストを処理していません。
• コードをオンにした後 青 サーバーが完全に更新されると、ルーターに切り替えるコマンドが与えられます。 グリーン на ブルー サーバ。
• これで、すべてのクライアントにコードの実行結果が表示されます。 青 サーバ。
• しばらくの間、 グリーン サーバーは、展開が失敗した場合のバックアップとして機能します。 ブルー サーバーに接続し、障害やバグが発生した場合、ルーターはユーザー フローを元のサーバーに切り替えます。 グリーン サーバーに古い安定バージョンがインストールされ、新しいコードが改訂とテストのために送信されます。
• そしてプロセスの最後に、同じ方法で更新されます グリーン サーバ。 更新後、ルーターはリクエスト フローを元の状態に切り替えます。 グリーン サーバ。

どれもとても良く見えますし、一見すると何の問題もないはずです。
しかし、私たちは現代世界に生きているため、古典的なスキームで示されているような物理的なスイッチングを伴うオプションは私たちには適していません。 とりあえず情報を記録しておきます。後で確認します。

悪いアドバイスと良いアドバイス

免責事項: 以下の例は、私が使用するユーティリティ/方法論を示しています。同様の機能を持つ代替手段をまったく使用できます。

ほとんどの例は、何らかの形で Web 開発 (これは驚くべきことです)、PHP および Docker と関連しています。

以下の段落では、特定の例を使用して、因子の使用法について簡単に実践的に説明します。このトピックに関する理論をさらに詳しく知りたい場合は、上のリンクから元のソースを参照してください。

1. コードベース

FTP と FileZilla を使用してファイルを一度に XNUMX つずつサーバーにアップロードします。実稼働サーバー以外の場所にはコードを保存しないでください。

プロジェクトには常に単一のコード ベースが必要です。つまり、すべてのコードは XNUMX つのコード ベースから来ています。 Gitの リポジトリ。 サーバー (本番、ステージング、test1、test2...) は、XNUMX つの共通リポジトリのブランチからのコードを使用します。 このようにして、コードの一貫性を実現します。

2. 依存関係

フォルダー内のすべてのライブラリをプロジェクトのルートに直接ダウンロードします。 新しいコードを現在のバージョンのライブラリが含まれるフォルダーに転送するだけで更新できます。 さらに 20 個のサービスが実行されているホスト サーバーに、必要なユーティリティをすべて直接インストールします。

プロジェクトには、常に明確に理解できる依存関係のリストが必要です (依存関係とは環境のことも意味します)。 すべての依存関係を明示的に定義し、分離する必要があります。
例として見てみましょう 作曲家 и デッカー.

作曲家 — PHP にライブラリをインストールできるようにするパッケージ マネージャー。 Composer では、バージョンを厳密または大まかに指定し、明示的に定義することができます。 サーバー上には 20 の異なるプロジェクトを存在させることができ、各プロジェクトには、互いに独立したパッケージとライブラリの個人用リストがあります。

デッカー — アプリケーションが実行される環境を定義および分離できるユーティリティ。 したがって、composer の場合と同様に、アプリケーションが何で動作するかをより徹底的に判断できます。 特定のバージョンの PHP を選択し、プロジェクトが動作するために必要なパッケージのみをインストールし、余分なものは追加しません。 そして最も重要なことは、ホスト マシンや他のプロジェクトのパッケージや環境に干渉しないことです。 つまり、Docker を介して実行されているサーバー上のすべてのプロジェクトは、あらゆるパッケージのセットとまったく異なる環境を使用できます。

3. 構成

構成を定数としてコードに直接保存します。 テスト サーバー用に別の定数、実稼働用に別の定数。 if else 構造を使用して、環境に応じたアプリケーションの操作をプロジェクトのビジネス ロジックに直接結び付けます。

設定 - これが、プロジェクトのデプロイメントが異なる唯一の方法です。 理想的には、設定は環境変数 (env var) を介して渡される必要があります。

つまり、複数の構成ファイル .config.prod .config.local を保存し、展開時にそれらの名前を .config (アプリケーションがデータを読み取るメインの構成) に変更したとしても、これは正しいアプローチではありません。この場合、構成からの情報はすべてのアプリケーション開発者に公開され、運用サーバーのデータが危険にさらされることになります。 すべての構成はデプロイメント システム (CI/CD) に直接保存し、デプロイメント時に特定の環境に必要なさまざまな値を使用してさまざまな環境用に生成する必要があります。

4. 第三者サービス

環境に厳密に関連付けられ、特定の環境では同じサービスに対して異なる接続を使用します。

実は、この点は設定に関する点と非常に重なります。この点がなければ通常の設定データを作成することができず、一般に設定機能がゼロになってしまいます。

キュー サーバー、データベース、キャッシュ サービスなどの外部サービスへのすべての接続は、ローカル環境とサードパーティ/運用環境の両方で同じである必要があります。 つまり、接続文字列を変更することで、アプリケーション コードを変更せずに、いつでもベース #1 への呼び出しをベース #2 に置き換えることができます。 あるいは、今後の例として、サービスをスケーリングするときに、追加のキャッシュ サーバーに対して特別な方法で接続を指定する必要がなくなります。

5. ビルド、リリース、実行

サーバー上にはコードの最終バージョンのみが存在し、リリースをロールバックする可能性はありません。 ディスク容量を埋める必要はありません。 エラーがあってもコードを本番環境にリリースできると考える人は、悪いプログラマです。

導入のすべての段階は互いに分離されている必要があります。

ロールバックするチャンスがあります。 クイック アクセスで保存されたアプリケーションの古いコピー (すでに組み立てられ、戦闘の準備ができている) を使用してリリースを作成します。これにより、エラーが発生した場合に古いバージョンを復元できます。 つまり、条件付きでフォルダーが存在します リリース とフォルダー 現在、展開とアセンブリが正常に完了すると、フォルダーが 現在 内部にある新しいリリースへのシンボリック リンクによってリンクされています リリース 従来のリリース番号の名前が付けられています。

ここで、Blue-Green デプロイメントを思い出します。これにより、コード間の切り替えだけでなく、すべてのリソース間や、すべてをロールバックできる環境間の切り替えも可能になります。

6. プロセス

アプリケーションの状態データをアプリケーション自体内に直接保存します。 アプリケーション自体の RAM 内のセッションを使用します。 サードパーティのサービス間で可能な限り共有を使用します。 アプリケーションが持つことができるプロセスは XNUMX つだけであり、スケーリングはできないという事実に依存してください。

セッションに関しては、サードパーティ サービス (memcached、redis) によって制御されるキャッシュにのみデータを保存します。そのため、20 個のアプリケーション プロセスが実行されている場合でも、キャッシュにアクセスしたプロセスのいずれかがクライアントとの作業を継続できます。ユーザーが別のプロセスでアプリケーションを操作していたときと同じ状態です。 このアプローチでは、使用するサードパーティ サービスのコピーが何個であっても、すべてが正常に動作し、データへのアクセスに問題がないことがわかります。

7. ポートバインディング

Web サーバーのみがサードパーティのサービスと連携する方法を知っている必要があります。 さらに良いのは、サードパーティのサービスを Web サーバー内に直接インストールすることです。 たとえば、Apache の PHP モジュールとして。
すべてのサービスは、いくつかのアドレスとポート (localgost:5432、localhost:3000、nginx:80、php-fpm:9000) へのアクセスを通じて相互にアクセスできる必要があります。つまり、nginx から php-fpm とpostgres、php-fpmからpostgres、nginxに移行し、実際には各サービスから別のサービスにアクセスできます。 こうすることで、サービスの実行可能性が別のサービスの実行可能性に結びつかなくなります。

8. 平行度

XNUMX つのプロセスで動作します。そうしないと、複数のプロセスが相互に連携できなくなります。

スケーリングのための余地を残しておきます。 Docker swarm はこれに最適です。
Docker Swarm は、異なるマシン間および同じマシン上の多数のコンテナの両方でコンテナのクラスタを作成および管理するためのツールです。

swarm を使用すると、各プロセスに割り当てるリソースの数と、起動する同じサービスのプロセスの数を決定できます。内部バランサーは、特定のポートでデータを受信すると、そのデータを自動的にプロセスにプロキシします。 したがって、サーバーの負荷が増加したことを確認して、プロセスを追加して、特定のプロセスの負荷を軽減できます。

9. 使い捨て可能性

プロセスやデータを操作するためにキューを使用しないでください。 XNUMX つのプロセスを強制終了すると、アプリケーション全体に影響が及ぶはずです。 XNUMX つのサービスがダウンすると、すべてがダウンします。

各プロセスとサービスはいつでもオフにすることができ、これが他のサービスに影響を与えることはありません (もちろん、これは、そのサービスが別のサービスで使用できなくなるという意味ではありませんが、このサービスの後に別のサービスがオフにならないという意味ではありません)。 すべてのプロセスは正常に終了する必要があります。そうすることで、プロセスが終了してもデータが損傷せず、次回電源を入れたときにシステムが正常に動作します。 つまり、緊急終了が発生した場合でも、データが損傷することはありません (トランザクション メカニズムはここで適切であり、データベース内のクエリはグループでのみ機能し、グループからの少なくとも XNUMX つのクエリが失敗するか、エラーが発生した場合、グループからの他のクエリは実際には最終的に失敗しません)。

10. アプリケーション開発/運用の同等性

アプリケーションの実稼働バージョン、ステージング バージョン、およびローカル バージョンは異なる必要があります。 実稼働環境では Yii Lite フレームワークを使用し、ローカルでは Yii を使用するため、実稼働環境ではより高速に動作します。

実際には、すべてのデプロイメントとコードの操作はほぼ同一の環境にある必要があります (物理ハードウェアについて話しているのではありません)。 また、開発従業員は必要に応じてコードを実稼働環境にデプロイできる必要があります。特別な訓練を受けた DevOps 部門ではなく、特別な力のおかげでアプリケーションを実稼働環境に移行できる必要があります。

Docker もこれに役立ちます。 上記のすべての点が守られている場合、docker を使用すると、本番環境とローカル マシンの両方に環境をデプロイするプロセスが XNUMX つまたは XNUMX つのコマンドを入力するだけになります。

11. ログ

ログをファイルとデータベースに書き込みます。 ファイルやデータベースをログから消去することはありません。 9000 ペタバイトのハードドライブを購入しましょう。それで問題ありません。

すべてのログはイベントのストリームとして考慮される必要があります。 アプリケーション自体はログの処理に関与すべきではありません。 ログの操作によってアプリケーションに問題が発生しないように、ログは stdout に出力されるか、udp などのプロトコル経由で送信される必要があります。 これにはgraylogが適しています。 Graylog は udp 経由ですべてのログを受信します (このプロトコルでは、パケットの受信成功に関する応答を待つ必要がありません) がアプリケーションに干渉することはなく、ログの構造化と処理のみを処理します。 アプリケーション ロジックは、このようなアプローチで動作するために変更されません。

12. 管理タスク

データやデータベースなどを更新するには、APIで別途作成したエンドポイントを使用します。これを2回連続で実行すると、すべてが複製されます。 しかし、あなたは愚かではありません。2 回クリックすることはありません。移行する必要はありません。

すべての管理タスクは、リリース レベルですべてのコードと同じ環境で実行する必要があります。 つまり、データベースの構造を変更する必要がある場合、列の名前を変更したり、ビジュアルなデータベース管理ツールを使用して新しい列を追加したりすることは手動では行われません。 このようなものに対しては、移行という個別のスクリプトを作成します。これは、どこでも、すべての環境で同じ方法で実行され、共通でわかりやすい結果が得られます。 プロジェクトにデータを入力するなど、他のすべてのタスクについても、同様の方法論を使用する必要があります。

PHP、Laravel、Laradock、Docker-Compose での実装例

PS すべての例は MacOS で作成されました。 それらのほとんどは Linux にも適しています。 Windows ユーザーの皆様、申し訳ありませんが、私は長い間 Windows を使って仕事をしていませんでした。

PC にどのバージョンの PHP もインストールされておらず、何もインストールされていない状況を想像してみましょう。
最新バージョンの docker と docker-compose をインストールします。 （これはインターネットで見つけることができます）

docker -v && 
docker-compose -v

1.入れます ララドック

git clone https://github.com/Laradock/laradock.git && 
ls

Laradock については、多くのコンテナーや補助的なものが含まれており、非常にクールなものだと言えます。 ただし、冗長性があるため、運用環境で Laradock を変更せずにそのまま使用することはお勧めしません。 Laradock の例に基づいて独自のコンテナを作成することをお勧めします。そこにあるすべてのものを同時に必要とする人はいないため、より最適化されます。

2. アプリケーションを実行するように Laradock を構成します。

cd laradock && 
cp env-example .env

2.1. 何らかのエディタでhabrディレクトリ(laradockのクローンが作成される親フォルダ)を開きます。 (私のPHPStormの場合)

この段階では、プロジェクトに名前を付けるだけです。

2.2. ワークスペースイメージを起動します。 (あなたの場合、イメージの構築には時間がかかります)
ワークスペースは、開発者に代わってフレームワークを操作するために特別に用意されたイメージです。

を使用してコンテナ内に入ります

docker-compose up -d workspace && 
docker-compose exec workspace bash

2.3. Laravelのインストール

composer create-project --prefer-dist laravel/laravel application

2.4. インストール後、プロジェクトが含まれるディレクトリが作成されているかどうかを確認し、compose を強制終了します。

ls
exit
docker-compose down

2.5. PHPStorm に戻り、.env ファイル内の laravel アプリケーションへの正しいパスを設定しましょう。

3. すべてのコードを Git に追加します。

これを行うには、Github (または他の場所) にリポジトリを作成します。 ターミナルで habr ディレクトリに移動し、次のコードを実行してみましょう。

echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status

すべてが順調かどうかを確認してみましょう。

便宜上、Git には何らかのビジュアル インターフェイスを使用することをお勧めします。私の場合は次のとおりです。 ギットクラッケン。 （こちらが紹介リンクです）

4. 出発しましょう！

開始する前に、ポート 80 と 443 に何もハングしていないことを確認してください。

docker-compose up -d nginx php-fpm

したがって、私たちのプロジェクトは 3 つの個別のサービスで構成されています。

• nginx - ウェブサーバー
• php-fpm - Webサーバーからリクエストを受信するためのphp
• ワークスペース - 開発者向けの php

現時点では、4 点中 12 点を満たすアプリケーションを作成することができました。

1. コードベース — すべてのコードは XNUMX つのリポジトリにあります (注意: laravel プロジェクト内に docker を追加するのが正しいかもしれませんが、これは重要ではありません)。

2. 依存関係 - すべての依存関係は、application/composer.json と各コンテナーの各 Dockerfile に明示的に書き込まれます。

3. 支援サービス — 各サービス (php-fom、nignx、workspace) は独自の生活を送り、外部から接続されており、XNUMX つのサービスを操作する場合、もう XNUMX つのサービスは影響を受けません。

4. Процессы — 各サービスは XNUMX つのプロセスです。 各サービスは内部状態を維持しません。

5. ポートバインディング

docker ps

ご覧のとおり、各サービスは独自のポートで実行され、他のすべてのサービスにアクセスできます。

6. 並列処理

Docker を使用すると、同じサービスの複数のプロセスを生成し、それらの間で自動的に負荷分散を行うことができます。

コンテナを停止してフラグを実行しましょう - 規模

docker-compose down && 
docker-compose up -d --scale php-fpm=3 nginx php-fpm

ご覧のとおり、php-fpm コンテナのコピーが作成されています。 このコンテナを操作する際には何も変更する必要はありません。 また、引き続きポート 9000 でアクセスし、Docker がコンテナ間の負荷を調整します。

7. 使い捨て性 - 各コンテナは、他のコンテナを傷つけることなく停止できます。 コンテナーを停止または再起動しても、その後の起動時のアプリケーションの動作には影響しません。 各コンテナはいつでも持ち上げることができます。

8. アプリケーション開発/運用の同等性 - 私たちの環境はすべて同じです。 運用環境のサーバー上でシステムを実行すると、コマンドを何も変更する必要がなくなります。 すべて同じように Docker ベースになります。

9. ロギング — これらのコンテナ内のすべてのログはストリームに送られ、Docker コンソールに表示されます。 （この場合、実際、他の手作り容器の場合、手入れをしないとこのようにならない可能性があります）

 docker-compose logs -f

ただし、PHP と Nginx のデフォルト値でもファイルにログが書き込まれるという落とし穴があります。 12の要素を満たすためには、 無効にする 各コンテナの構成内のファイルにログを個別に書き込みます。

Docker は、標準出力だけでなく、上で説明した Graylog などにもログを送信する機能も提供します。 また、graylog 内ではログを自由に操作でき、アプリケーションはこれにまったく気づきません。

10. 管理タスク — すべての管理タスクは、12 要素アプリケーションの作成者の希望どおりに、職人ツールのおかげで、laravel によって解決されます。

例として、いくつかのコマンドがどのように実行されるかを示します。
コンテナに入ります。

 
docker-compose exec workspace bash
php artisan list

これで、任意のコマンドを使用できるようになりました。 (データベースとキャッシュを構成していないため、コマンドの半分は正しく実行されないことに注意してください。コマンドはキャッシュとデータベースで動作するように設計されているためです)。

11. 設定 および12。 ビルド、リリース、実行

この部分を Blue-Green デプロイメントに捧げたかったのですが、この記事では広すぎることが判明しました。 これについては別の記事を書きます。

一言で言えば、このコンセプトは次のような CI/CD システムに基づいています。 ジェンキンズ и Gitlab CI。 どちらの場合も、特定の環境に関連付けられた環境変数を設定できます。 したがって、この状況では、点 c が満たされます。 構成.

そしてその点については、 ビルド、リリース、実行 という名前の組み込み関数によって解決されます パイプライン.

パイプライン を使用すると、展開プロセスを多くの段階に分割し、アセンブリ、リリース、実行の各段階を強調できます。 また、Pipeline では、バックアップなどあらゆるものを作成できます。 無限の可能性を秘めたツールです。

アプリケーションコードは次の場所にあります githubの.
このリポジトリを複製するときは、サブモジュールを初期化することを忘れないでください。

PS: これらのアプローチはすべて、他のユーティリティやプログラミング言語でも使用できます。 重要なことは、本質は変わらないということです。

出所： habr.com