Home | Symfony2Doc

コンテンツ上部に更新日の記載のないページは、翻訳の内容が2.0相当のものになっております。最新の内容は原文のページをご確認ください。

Note

  • 対象バージョン:2.7以降
  • 翻訳更新日:2015/03/28

Symfony アプリケーションをデプロイする方法

Note

デプロイは、体制やアプリケーションの要件に応じて、複雑で多種多様な作業になります。 この記事は、それぞれの段階をひとつひとつガイドするものではなく、 デプロイに共通する要件や考え方の一般的な項目について記載しています。

Symfony のデプロイの基本原則

Symfony アプリケーションをデプロイするときの典型的なステップは以下です。

  1. 本番サーバーにコードをアップロードする
  2. Vendor に依存関係するライブラリをインストールする(典型的にはアップロードする前に Composer で完了させる)
  3. データベースのマイグレーション、あるいはそれに似たような変更されたデータ構成を更新するなタスクを実行する
  4. キャッシュを削除する(そして、オプションで warming up する)

デプロイには、これら以外に次のような作業も含まれます。

  • ソースコード管理レポジトリにリリース用バージョンのタグを付ける。
  • 一時的なステージング領域を作る
  • コードとサーバの安定性を確実にするためのテストの実行
  • 本番環境をクリーンに保つために web/ ディレクトリから不要なファイルを削除する
  • 外部のキャッシュシステムの削除( MemcachedRedis 等 )

Symfony アプリケーションをデプロイする方法

Symfony アプリケーションのデプロイにはさまざまな方法があります。 まずは、基本的なデプロイからはじめて、そこから作り上げていきましょう。

基本的なファイル転送

アプリケーションをデプロイする最も基本的な方法は FTP や SCP (またはそれに似た方法) によってファイルを手動でコピーする方法です。 このやり方は、アップグレードを進めていく上で発生するような、システムの上書きをコントロールしにくいというデメリットがあります。 さらに、この方法はファイルを転送した後にいくつかの手動作業が必要です。(参考 共通のデプロイ後の作業

ソース管理ツールを利用する

もしソース管理ツール(例えば Git や SVN)を利用しているのであれば、 レポジトリのコピーを本番環境として使うことができます。 アップグレードする準備ができたら、ソース管理システムから最新の更新を取得するように簡単に作業できます。

この方法では、ファイルの更新は簡単になりますが、 これ以外の作業は、手動で対応しなくてはなりません。(参考 共通のデプロイ後の作業 )

ビルドスクリプトやその他のツールを利用する

デプロイの苦痛を楽にするツールがあり、 いくつかのツールは Symfony の必要要件のために特別に作られています。

Capifony
Ruby 製の Capistrano の一部を使って提供されたツールで Symfony プロジェクト専用に作られたツールです。
sf2debpkg
Symfony プロジェクトのための Debian パッケージ のビルドを補助するツールです。
Magallanes
Capistrano のようなデプロイツールが PHP にビルドインしています。 PHP を利用する開発者にとっては必要に応じて簡単に拡張できます。
Fabric
Python 製のローカルやリモートでシェルコマンドやファイルの アップロード・ダウンロードを実行するための操作の基本セットを提供するライブラリです。
バンドル
デプロイメント機能を含むバンドルが Symfony console にあります。(参考 `bundles that add deplyment features`_
基本的なスクリプト
もちろん、 シェルや Ant やその他のビルドツールのプロジェクトのデプロイスクリプトでも可能です。
Platform as a Service Providers

Symfony クックブックにはいくつかのよく知られた PaaS の詳細な記事があります。

  • Microsoft Azure
  • Heroku
  • Platform.sh

共通のデプロイ後の作業

実際のソースコートをデプロイした後に、いくつかの共通の作業を実行する必要があります。

A) 必要要件の確認

サーバが必要要件を満たして稼働しているか確認します。

$ php app/check.php

B) app/config/parameters.yml ファイルの設定

このファイルはデプロイ するべきではない ですが、Symfony によって提供されている ユーティリティによって自動的に管理されます。

C) Vendors のインストール / 更新

Vendor ディレクトリは、ソースコードを転送する前にアップデートすることが可能です。 (例. vendor/ ディレクトリを更新し、その後ソースコードを転送する) これは、ソースコードを転送した後に更新することも可能です。 どちらにしても、vendors を更新するだけのときは通常はこのようにします。

$ composer install --no-dev --optimize-autoloader

Tip

--optimize-autoloader フラグは “class map” をビルドすることで Composer のオートローダーのパフォーマンスをかなり向上させます。 --no-dev フラグは開発用パッケージを本番環境でインストールしないようにします。

Caution

もし “class not found” というエラーをこのステップで発生したら、 本番環境で post-install-cmd スクリプトが実行される前に export SYMFONY_ENV=prod を実行する必要があります。

D) Symfony のキャッシュ削除

Symfony キャッシュを削除(と warm-up)を実行します。

$ php app/console cache:clear --env=prod --no-debug

E) Assetic Assets のダンプ

Assetic を利用している場合は、assets をダンプします。

$ php app/console assetic:dump --env=prod --no-debug

F) その他

やるべきことは他にもたくさんあります。これは、それぞれのアプリケーションの体制・環境に依存しています。

  • データベースのマイグレーションの実行
  • APC キャッシュの削除
  • assets:install の実行 (composer install に実行後)
  • クーロンの追加・編集
  • CDN へ assets の追加
  • ・・・

アプリケーションのライフライクル、継続的インテグレーション、QA、その他

ここではデプロイの技術的な詳細を記載しましたが、 開発環境からコードを取得し本番環境にアップするまでの全てのライフサイクルには もっと多くのステップがあります。(ステージング環境へのデプロイ、QA(品質保証)、テスト実行、その他)

ステージング環境、テスト、QA、継続的インテグレーション、データベースマイグレーション そして失敗した場合にロールバック機能、これらについては、全て利用することを強くお勧めします。

アプリケーションをデプロイする作業には、依存関係の更新(一般的には Composer を利用)、 データベースのマイグレーション、キャッシュの削除、そして CDN に assets を更新するなどの 作業が潜んでいることを忘れないで下さい。(参考 共通のデプロイ後の作業

blog comments powered by Disqus