クマの手も借りたい
馬とテニスとリラックマが好きな IT 系のエンジニアです。
PHP

PHPアプリに最適なデプロイ方法を考える

ローカルの開発環境については、この数年で選択肢が増えどれも短時間で準備ができるという便利な世の中になりました。

昔は、Windows 向けのアプリ開発においては VisualStudio という IDE(統合開発環境)があり(今もありますが)、VisualBasic(VB)を使って開発していた時代が懐かしいです。

しかし、Java についてはテキストエディタで開発している時代があり、コンパイルも javac コマンドを DOS の画面で実行するという今では考えられない開発環境でした。

今回は、.NET でも Java でもなく PHP のアプリのデプロイ方法について紹介したいと思います。

Eclipseによって効率化したJavaの開発環境

いきなりですが、話は Java に戻ります(笑)

Java については、その後登場した Eclipse の無償提供によって飛躍的に開発環境は進化し、多くのプラグインが登場したことによって Webアプリケーションサーバと連携した開発も一気に効率化されました。

主に Tomcat や WebLogic, JBOSS などでしょうか。

また、NetBeans など他の IDE も普及してきたことは良かったのですが、開発の効率化が進む半面、ツールの設定やプラグインの動作でハマるケースも多々ありました。

ビルド管理ツールの登場

ちなみに javac コマンドで行っていたコンパイルも ant や maven の登場によってタスク化され、javac コマンドがラップされたことによって実際に javac コマンドを打ち込むことはほぼほぼなくなりました。

最近のトレンドだと gradle でしょうか。ゾウのキャラクターのアプリって多いですよね。

入門書で「Hallo World.」を試すのも、もしかすると今では maven などの設定後というステージになっているのでしょうか?

Java の Web アプリケーションは業務系のシステムで多く採用されているイメージがあり、比較的規模も大きくなる傾向にあることから、このようなタスク化は実装者からするとコードを書くのに集中できる側面もあったような気がします。

もちろん、Web アプリの構成を検討する人は ant なら build.xml、maven なら pom.xml などタスク用の設定ファイルを作らないといけないので大変でしたが・・・。

PHPアプリの普及と規模の拡大

さて、本題に戻りますが、PHP のアプリケーションの場合はビルド(コンパイル)が不要なインタプリタ型のスクリプト言語です。

ロジックを記述したファイルを上書きすればすぐさま反映されるので、開発効率がいいのと、静的な html に少しだけ動的な要素を加えたい場合に html 内に PHP のロジックを埋め込んで使うという用途でも多く利用されてきました。

最近は、大規模な Web アプリケーションやソーシャルゲームのサーバサイド側の開発で利用されるシーンも多く、開発環境や開発手法(フレームワークの採用やオブジェクト指向の考え方)、ミドルウェアとの連携など、構成を考えるうえで考慮しないといけない範囲がものすごく増えました。

PHPアプリのデプロイってどうしてる?

そんな PHP の Web アプリですが、スクリプト言語ということもありプログラムを記述したファイルは上書きするとすぐに反映されます。

よって、本番サーバへ反映する場合も、直接コピー(scp, ftp)している古き良き?時代を継承しているプロジェクトもあるでしょうし、基点となるサーバから rsync などで複数台のサーバへ展開している場合もあるでしょう。

もちろん、その中で、中間コードのキャッシュクリアやデータベースのマイグレーションの考慮など、単純にファイルの更新だけで済まないパターンもあるでしょうから、いろいろ工夫されているプロジェクトもあると思います。

私が昔いた会社(10年以上前)では、Java のプロジェクトでしたが、Apache や Tomcat を再起動する際に監視用のデーモンがプロセスを見て、自動的にロードバランサ(LB)から切り離し Apache と Tomcat が起動したタイミングでヘルスチェックを行ってから LB に戻すといったような仕組みが用意されていました。

PHP においても、デプロイは rsync を使っているけどロードバランサからの切り離しを行っているという「ngx_dynamic_upstreamでnginxのアップストリームを動的に変更する」という記事を見かけました。

採用しているデプロイ方法

ちなみに私のプライベートな環境の場合、まず基点のサーバ(CIサーバ的なところ)で Git から取得した最新のソースを zip ファイルに圧縮して最新を置いておきます。

そして、リリースの際には各 Web サーバからその zip ファイルを scp で取得し、Web サーバ上のドキュメントルート(少し仕組みが入ります)に解凍して反映しています。

これを Jenkins のタスクにシェルを仕込んで実現させているので、1 クリックで git の master ブランチのソースが展開される仕組みです。

大雑把な説明だとわかりにくいと思いますので、構成を書いてみたいと思います。

基点となるサーバ

主にCIサーバ用途、Jenkins、各種ミドルウェアの監視、バッチ実行などをしている

Webサーバ

PHP、nginx

Git

プライベートではBitBucket

手順を紹介します。

  • CIサーバからGitへ接続し最新のソースを取得する(Jenkinsのプラグイン)
  • 配布先の Web サーバのシェルを CI サーバから実行 ※1
  • Web サーバで zip ファイルを解凍し所定の場所へ配備 ※2
  • ドキュメントルートの場所を解凍先ディレクトリに変更 ※3
  • 4世代前の解凍先ディレクトリを削除(掃除) ※4

以下は補足事項になります。

※1:シェルから ssh コマンドで行っています

※2:その時点のタイムスタンプでディレクトリを作成しそこへ配備

※3:シンボリックリンクを切り替えています

※4:3世代前まではシンボリックリンクの切り替えで戻せる

実際の現場で考慮すべきこと

プライベートな環境においてざっくりとしたデプロイ方法を書いてみましたが、実際のビジネスや開発現場においてはもっと考慮しないといけない点はたくさんあります。

まず、シンボリックリンクを切り替える際に動作しているプロセスへの影響。

データベースの変更が生じた際に手動作業が増える。

アプリに依存するログファイルなど、共通ディレクトリをアプリに依存しない場所にしておく。

などなどここでは書いていませんが、どこまで自動化するか安全性を高めるかはサイトのポリシーに依存するので、ここではシステムが落ちても影響のないプライベートなサイトをイメージして紹介してみました。

他のデプロイツール

そんな中、先日 Deployer というデプロイツールを発見しました。

私のデプロイ方法と似ていて、大きく間違ったことはしていなかったと安心感を得ました。

また、最近は Ruby アプリのデプロイでよく使われている Capistrano も PHP アプリのデプロイに使ってみました。

こちらも自由度はあるのですが ruby で書かないといけない部分もあり、デプロイのためだけに他の言語を覚えるのはちょっと苦痛です。デプロイ操作はシェルだけでいいような気もします。

ってこの記事書いてから発見しましたが、最近の PHP カンファレンスで PHP のデプロイツールについてのセッションがあったようですね。

ツールや手法については「PHPデプロイツールの世界」を見た方が最新のトレンドを知ることができるかもしれません。

Web API The Good Parts

オライリーの「Web API」に特化した本です。最近の多くの Web サービスは API が活用されていますが、その技術はこれまでの Web サイトとそれほど大きく変わりません。

今後、マイクロサービス化が進む中で知っておいて損はない内容が詰め込まれており、現場のエンジニアやこれから Web 系のエンジニアを目指す人にもオススメの一冊です。

created by Rinker
¥2,376
(2018/09/21 11:58:20時点 Amazon調べ-詳細)

あなたにオススメ