ConoHaでのVPSの利用

この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の１２日目の記事です。

この記事は｢Advent Calendar 2015｣で予定していた内容を後追いして執筆・公開している記事となります

今回は実際に｢ConoHa｣でサーバーを立ち上げる部分について簡単紹介したいと思います。

SSHキーの生成

まずサーバの追加を行う前にサーバ接続時に利用するSSHキーを準備しましょう。 SSHキーの生成もConoHaのコントロールパネル上から行う事が可能です。
　
コントロールパネルの左側メニューの｢SSH Key｣をクリックします。

右上に｢＋パブリックキー｣というボタンがありますのでクリックします。

｢リージョン｣｢登録方法｣｢ネームタグ｣の3項目があります。
｢リージョン｣は登録したSSHキーを利用する対象のリージョンです。
｢登録方法｣はConoHaのコントロールパネル上で新たにSSHキーを生成する場合は｢自動生成｣、既に生成済みのキーを利用する場合は｢インポート｣を選択します。今回はコントロールパネル上で新たに生成して利用しますので｢自動生成｣を選択し進みます。
｢ネームタグ｣はConoHaのコントロールパネル上で識別するための名前を設定します。
　
全ての入力及び選択を終えたら｢保存｣をクリックすると新たなSSHキーペアが生成されます。
なお｢保存｣をクリックすると次のような画面が表示されプライベートキーの保存ができますのでダウンロードして大切に保管しましょう。

SSHキーの生成が終わると次のように生成またはインポートしたキーの情報が表示されます。
ここで生成・インポートしたキーを認証情報として引き続きサーバを追加しましょう。

サーバーの追加

サーバーの追加はコントロールパネル左側の｢＋サーバー追加｣をクリックして行います。 ボタンをクリックするとサーバの追加画面が表示されます。

大きくわけて３つの項目があり｢1.プラン｣｢2.イメージ｣｢3.オプション｣の３つの項目をそれぞれ設定し作成するVPSを決定します。
初期状態ではメモリ1GB、CPUが2Core、ディスクサイズ50GBの月額900円（1.3円/時間）のプランが選択されていますので、この状態から必要とする構成に変更します。
　
今回は単純なサーバーを１つ立ち上げてみますので必要最小限の部分のみ変更します。 ｢OS｣を｢CentOS｣、｢バージョン｣を｢6.7(64bit)｣にします。 特にどのバージョンでもよいと思いますが、7系からは大幅に管理方法が変更された部分もある為、既存の知識や経験を活かすという事であれば現時点では6系を活用する事をお勧めします。
｢rootパスワード｣を入力します。必須項目ですので後に設定する｢SSH Key｣を利用する場合でも当然設定が必要です。
｢SSH Key｣を｢登録済みのキー｣とし、｢パブリックキー｣で先ほど登録したネームタグのキーを選択します。
｢ネームタグ｣に識別用の名称を設定します。

以上の内容で構成を変更したら｢追加｣ボタンをクリックし構成を決定します。 クリック後は｢サーバーリスト｣画面が表示されます。追加した直後はステータスが｢構築中｣となりますのでしばらく(およそ5分前後)まっていると｢起動中｣となりサーバーを利用する事が可能な状態となります。

　　

｢サーバーリスト｣画面で対象のサーバーをクリックすると詳細な情報を確認できます。

この画面上ではサーバのリソースやトラフィック状態の概略を確認するための｢リソース｣、標準または追加NICの設定内容を確認できる｢ネットワーク情報｣、サーバーの構成を変更する事ができる｢VPS設定｣が表示されます。
また上部にはサーバーの停止や起動、再起動を行うボタン、コンソールに接続する為のボタン、構築済みサーバーのイメージを作成し保存する為の｢イメージ保存｣、そしてサーバの再インストールを行う為の｢サーバーの再構築｣などのボタンが配置されています。
｢イメージ保存｣や｢サーバーの再構築｣などを行う為には一度対象のサーバーを｢シャットダウン｣させ停止状態にする必要があります。

今回はサーバー構築時に｢SSH Key｣を指定しましたので初期状態で｢PasswordAuthentication｣が｢no｣に設定されています。
その為、SSHで接続する際は事前に作成したプライベートキー(秘密鍵)を利用した認証を行う必要がありますので注意してください。

このようにサーバーの構築だけであればものの数分あれば準備できますので柔軟なサーバー運用が可能となります。

ロードバランサーの利用

折角ですので月1000円で利用できるロードバランサーも利用してみましょう。 ロードバランサーの追加はコントロールパネル左側の｢ネットワーク｣をクリックして表示されるメニュー内で行います。
　
画面下部の右側に｢＋ロードバランサー｣ボタンがありますので、ボタンをクリックしロードバランサーの追加を行います。

追加画面はリージョン選択のみを行う非常にシンプルな画面ですので、振り分け先となるサーバと同じリージョンを選択し｢追加｣をクリックします。

正常にロードバランサーが追加されると次のようにロードバランサー欄にグローバルIPが表示されます。
このグローバルIPアドレス宛のアクセスをそれぞれこれから追加するWEBサーバに振り分けを行うよう設定します。

まずはロードバランサーが各サーバを監視する為に用いるヘルスモニターに監視方法を追加します。
画面下部のヘルスモニターリストの右側に編集アイコンがありますのでそれをクリックしプロトコルリストを編集モードにします。 現在はリストが空ですので、新しくリストに項目を追加する為にプロトコルの下あたりにある「＋」アイコンをクリックします。

プロトコルリストに新しい監視方法が追加されます。
今回はプロトコルは｢HTTP｣、リージョンは｢東京｣、設定内容の判定時間（秒）を｢5｣、そしてパスに｢/｣を設定。
この設定は各サーバのルートディレクトリにHTTPでアクセスし、正常なレスポンスがなければエラーと判定するという監視が行われます。
設定内容を編集したら最後に｢保存｣をクリックし設定内容を保存します。

これで監視ルールが追加されました。
次は振り分け先のサーバーを追加します。
　
ロードバランサーが機能するには、１台以上のサーバーがロードバランサーに追加されており、且つ、登録されているサーバーのうち最低限１台が正常な状態と認識されている必要があります。
　
振り分け先のサーバーの追加はロードバランサー設定の中のバランシング設定にて行います。
ロードバランサーのグローバルIPをクリックするとバランシング設定などが表示されますので、バランシング設定内のバランシング元ポートから利用するポート番号を選択しそのポートでアクセスされた場合の振り分け先サーバを追加します。
今回は80番ポートへのアクセスを各サーバーに分散させますので、バランシング元ポートで｢80｣を選択します。

次に画面を編集モードにする為にここでも編集モードのボタンをクリックし編集モードに切り替えます。
編集モードにするとバランシング方法とヘルスモニターが選択できるようになりますのでそれぞれ選択します。
バランシング方法については今回は｢ラウンドロビン｣に設定します。
ヘルスモニターについては予め作成したものがリスト上に表示されているはずですのでそれを選択します。

最後に実際に振り分け先となる実サーバを登録します。
バランシング先IPアドレスの下にある｢＋｣をクリックすると一つ目の振り分け先サーバが選択できるようになりますので、表示されるリストから振り分け先となるサーバのグローバルIPを選択します。
なお追加IP等を使っている場合はそれらも表示されますので注意してください。 通常ロードバランサーを利用する場合は複数台の実サーバで構成する事になりますので、必要な台数分｢＋｣をクリックしそれぞれ振り分け先となるグローバルIPを選択します。
全ての実サーバの追加が完了したら｢保存｣をクリックして設定を完了します。

実サーバ側の設定

前述の内容でロードバランサー側の設定は完了しました。
実際にロードバランサーを利用するには振り分け先の実サーバー側でパケットの転送設定を行う必要があります。
具体的な手順は公式Blogの｢ロードバランサーを使う｣を参考にすると良いでしょう。

私の場合はループバックインターフェイスを追加して対応しました。
具体的には下記の内容で｢/etc/sysconfig/network-scripts/ifcfg-lo:0｣を作成します。

[(username)@www ~]$ vi /etc/sysconfig/network-scripts/ifcfg-lo:0

DEVICE=lo:0
IPADDR=[ロードバランサーのバーチャルIPアドレス]
NETMASK=255.255.255.255
ONBOOT=yes

以上の内容でファイルを作成したら最後にネットワークサービスのリスタートを行います。

service network restart

この作業を全ての実サーバーで行います。

これで実サーバ側の設定も完了です。
なお、当然ですがこの作業の他に各サーバでロードバランサーで処理を行う対象のバーチャルホストの設定なども行います。
正常の設定が完了していれば次のようにロードバランサー経由でアクセスする事で正しく実サーバーに対してラウンドロビン方式でアクセスが振り分けられます。

どうでしょうか。 非常に簡単にロードバランサーの利用ができる事がわかったと思います。

但し、下記の利用上の注意にも記載していますが準備の間も含めステータス確認や設定上の不備をロードバランサー側からの認識状態をもとに切り分ける事ができません。
その為、設定は確実に行う方がよいでしょう。

利用上の注意

さて、サーバが立ち上がってしまえばあとは一般的なVPSとそれほど違いはりませんが、いくつか利用に関して予め知っておいた方がよい事がありますのでその部分を説明します。

① 追加IPの利用は最低利用間として30日が設定されている

ConoHaの特徴でもある追加IPの利用ですが、表記上は｢1ヶ月 350円/月(0.5円/時間)｣となっていますが、これには最低利用期間(30日)が設定されています。
私が認識している限り最低利用期間についての表示はIPアドレスの追加画面で｢追加｣ボタンをクリックした際に表示される確認ダイアログのみで認識できます。
　
利用の可否に係らず最低利用期間分の費用は負担する必要がありますのでその点注意して利用してください。

② ロードバランサーからみた各サーバーの認知スタータスの確認は行えない

比較的致命的な問題ではあるのですが、ロードバランサーを利用した場合に各サーバーがロードバランサーからみてどのように認知されているかというのは重要な監視項目です。
各サーバーが正常であると思われても実際のアプリケーションのエントリーポイントが何らかの理由でエラーとなっているケースは存在する為、HTTPでの監視をステータスの識別に利用しているようなケースであっても現在ロードバランサーからみて各サーバーがどのような状態として認識されているかは個別に把握するのですが、ConoHaのロードバランサーではそのステータスを知る手段がありません。
　
一応サポートに問い合わせた結果、200番台または300番台以外のステータスの場合はダウンと判断されるとの回答をいただきましたのでそれを前提に認識状態の管理とコントロールは可能です。
例えばメンテナンスを行う場合、対象サーバーのアプリケーションで503のステータスコードを返す事で理論上はバランシング対象から外れる事になります。但し、現在はずれているのか、それともまだ対象となっているのかは判断できませんので、設定後、監視方法の監視タイミング以降の間隔を十分にとり作業を行う等の配慮が必要です。
　
もっともメンテナンスだけであればコントロールパネル上から｢有効/無効｣の設定が可能ですのでそこで制御も可能ですが、正しくバランシングされている事を把握するには、各サーバーのログ等をつなぎ合わせて確認するしか方法はありません。

③ ローカルネットワークを利用する際のIPアドレスは自動割り当てとなる

地味な欠点としてローカルネットワークを利用する場合、各サーバー割り当てられるIPアドレスは任意で選択する事はできません。
設定したサブネット内の割り当て可能なIPアドレスの空いているものから順に自動的に割り当てられます。
単純な利用であればそれほど影響を受けないのですが、本格的に内部ネットワークを設計・設定する場合はなれていないと設計を設定に反映する際にかなり戸惑う事になると思いますので注意してください。

ホント…この点は早めに改善してほしい…サーバー毎にIPアドレスを規則的に配布するってのは一括設定やコンフィグ設定時に影響するので、結構な欠点ですから…

他にも細かいポイントはありますが、使っていて他のサービスとの差異や後で｢しまった…｣と気づく点はこの部分がメインではないかと思います。

欠点を最後にあげましたが、使い勝手や仮想サーバーのスペック等も含めかなり良いサービスである事に変わりはありません。
特にコントロールパネルの改善は地味に日々行われている状況ですので、今は欠点として挙げた部分も今後改善される可能性も高く、今後の成長に期待してもよいと思います。

以上で簡単ではありますが、ConoHaでVPSを利用する方法についての簡単な紹介を終わります。

次回はからはまたライブラリの紹介に戻ります。

VPSサービスの利用（｢ConoHa｣の特徴）

この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の１１日目の記事です。
　
※本記事は実際の予定より遅れて投稿（12月16日）しております
　
今回はVPSサービスについて少し整理してみます。
　
さて数年前ですと、安価でそれなりのVPSを利用する場合は海外製のサーバを調達し利用する事も少なくありませんでした。
一番の理由は自由度とコストで設置場所が海外であるデメリット（コミュニケーション、安定性、レイテン等）を許容できるのであれば現実的な選択肢の一つでした。
　
しかし2008年に登場したさくらのVPSあたりから国内VPSは海外VPSと比較して安定性もコストも十分なものとなり、現在では特別な事情がない限り国内VPSの利用が当たり前の状況となっています。
そして、近年では単体サーバでのサービス構築だけでなく、ローカルネットワークやバックアップ、ロードバランサーなど様々な付加サービスも提供されており、一定の規模のサービスであればクラウドサーバを必要としない程のレベルまで成長しています。
　
以前の記事で昨今のレンタルサーバは優秀と書きましたが、コスト的な問題や構築の手間を許容できるのであれば実はVPSはレンタルサーバよりも優秀な選択肢となる事もありえます。
今回はそんなVPSについて少し整理をしていきたいと思います。

国内VPS事業社の状況

国内のVPSサービスを提供する事業社で私が理解しているものは以下の通りです。

提供会社	サービス名
さくらインターネット	さくらのVPS
GMOインターネット	ConoHa
GMOインターネット	Z.com Cloud VPS
GMOインターネット	お名前.COM VPS
NTTPCコミュニケーションズ	WebArena VPSクラウド
ドリーム・トレイン・インターネット	ServersMan@VPS
カゴヤ・ジャパン	カゴヤ・クラウド／VPS

まだまだ沢山のVPSサービスがありますが、私が現状認識しており定期的にチェックしているのはこのあたりです。

例えばGMO系ですとWEBKEEPERやラピッドサイト、他にもABLENETや使えるねっとなどもありますが、何れも今回は比較対象からはずしています

以前からVPSサービスそのものはありましたが加速度的にサービス価格の低下とサービスの向上が図られたのはやはりさくらインターネットのVPSサービスが登場してからだったと記憶しています。
その影響で多くのサービスがここ2年〜3年の間にVPSサービスの見直しを行い、以前の口コミを鵜呑みにしてしまうと全然状況が違っているということも少なくありません。
　
また個人的な感覚として近年はGMO系が類似サービスを沢山立ち上げたりまた買収する傾向もありふたを開けると実は同じ運営母体だったと言うこともありますので、例えばDR目的でブランチを作成する場合は、しっかりと運営母体やそのインフラの状況を確認しなければなりません。 　

例えば私の場合はConoHaのブランチとしてZ.com Cloudを検討しましたが、サポートへ問い合わせたり周囲から情報を集めたりした結果、実は運営会社も運営体制も別物として考える事は難しいという結論にいたりました

さてこのような状況ですが、個人的に多用するサービスとしては「さくらのVPS」と「ConoHa」が最近ではもっと利用実績が多いサービスとなっています。 それぞれ特徴がありますので利用用途に応じて選択する事が望ましいですが、私の場合は専ら最近では「ConoHa」を利用する事が続いています。 　 今回はそのあたりの事情も踏まえながら「ConoHa」と「さくらのVPS」の比較をしてみたいと思います。

｢ConoHa｣の特徴（メリット）

さて「ConoHa」についてはもう溢れる程記事が上がっておりいまさら説明するまでもありませんが、簡単に幾つかの特徴について紹介したいと思います。

① VPSでありながら時間単位の課金

まず最初に来るのはやはり時間単位の課金でしょう。
VPSサービスの難点は多くのサービスで少額とはいえ初期費用がかかる点とサービスの契約が月単位である事です。
｢さくらのVPS｣の場合、2週間の無料お試しがありますのでその期間を活用する事で環境の評価にあてる事も可能ですが、柔軟に規模を操作する事には向きません。
その点｢ConoHa｣の場合は、全てのサービスが初期費用無料で時間単位の課金（一部オプションを除く）ですので、サーバーの増減も途中で用途を変更するなども非常に柔軟に行う事が可能です。

② クラウド並のオプション提供されている

2つめの特徴はクラウド並に様々なオプションが提供されていることです。
例えば複数台のWEBサーバを使いそれらへのアクセスをバランシングしたい場合は簡単にロードバランサーの利用ができます。
またはもしも本格的な（柔軟性の高い）データベースを必要としない場合はアプリケーションサービスとしてデータベースサービスも提供されています。
その他にもマルチリージョンが利用可能であったり、それを生かすようにGeoDNSが提供されていたりとVPSとは思えない程のオプションが提供されています。
もっとも何れもVPSですので自ら構築すれば実現は可能ですが、コントロールパネルからの簡単な操作のみでそれらが利用できるというのは非常に心強いです。

③ サーバ側にIPアドレスを複数割り当てることができる

単純なサーバ用途ではそれほど重要性はないものの、突然「使いたい」と思ったときに実はこのオプションが全然ないんですね。
外部からのアクセスを捌く為の環境を構築する事は想定されているものの、サーバーそのものが複数のIPを利用する事を意識したサービスは片手で数えるほどしか存在せずその点でも非常に便利なサービスです。

このように比較的他のVPSサービスとは一線を画しており、ポジショニング的にはVPSとクラウドの間といったところを目指しているのではないかと感じ取れます。

｢ConoHa｣の微妙な点

一方で、死角がないように見える｢ConoHa｣ですが気をつけないといろいろな所に落とし穴が有ります。
多くのものは確りと評価したり、またサポートやドキュメントを確認する事で回避できますが、次の点はあらかじめ意識した方がよいでしょう。

① ドキュメントが中途半端

もう最大の難点はこれにつきます。
多くの機能やサービスを提供しているのですがそれらに対する十分な説明がありません。
例えば｢バックアップ｣機能は提供されており料金表には｢自動バックアップ／300円/月｣となっていますが、正しくは｢300円/月から｣となります。
これは容量に応じて増加するという基本的な話ではあるのですが、その仕様はどこにも書かれていませんし、実際にサーバを設定する際も｢有効／無効｣しかバックアップの設定には記述はありません。 その為料金表を見て仮見積もりを作りプロジェクトを進めてしまうとあとからバックアップ予算が足りない、ということも発生してしまいますのでオプションの見積りは必ずサーバー追加画面で操作しながら確認する事が重要です。
　
こういった単純なものはまだ良いのですが、逆にバックアップを契約したとしてどのようなタイミングでどのように行われるのか気になりませんか？
しかしその点について詳細なドキュメントは存在せず唯一の記載は｢お客様ごとに異なるタイミングで1週間に1回取得｣との一文のみです。時間の指定もありませんしタイミングもわかりません。長引く構築作業だった場合はどの時点のバックアップが行われるかこれは運命に委ねるしか有りませんね･･･。
これ以外でもロードバランサーの死活監視の仕組みの仕様であったり、その他追加IPアドレスの採番ルールであたったりと様々なものがドキュメントとして不足しており結構悩みどころではあります。

② 旧サービスのドキュメントと新サービスのドキュメントが公式で混在している

公式の技術ブログでは当然以前の情報も掲載されている事は止むを得ないと考えます。
ただその場合は旧サービスのドキュメントから新サービスのドキュメントの誘導であったり、記事を新サービスを前提に新しく書き起こすなどフォローが必要です。
例えば、2015年1月に作成されたプライベートネットワークを利用する記事では｢1〜10は管理用に予約されていて、使用できませんので注意してください｣とありますが、既に新サービスではそのような制限はありません。
一方でドキュメントには記載がありませんが、OS上で新しいインターフェースを追加する場合は自動的に割り当てが行われるIPを事前にコントロールパネルで確認し、その上で設定が必要になるのですが、旧サービスと新サービスでは任意と自動の違いがあるにも関わらずその説明は新しく書き起こされた記事でも触れていません。
　
このようにドキュメント自体が中途半端なだけでなく、新・旧のサービスの仕様の違いを吸収するどころか、むしろ混乱するドキュメントが散乱する状態というのが実情です。

③ 運用面がそれほど考慮されていない

結構痛いのですが運用面はあまり考慮してくれていません。
例えば先ほどのバックアップもそうですが、タイミングの指定はできませんので本格的な利用はできません。結局自分でバックアップロジックを実装する方が現実的です。
他にも先ほど記述したとおりロードバランサーであればHTTPを用いた死活監視のルールが明らかでないだけでなく、ロードバランサーから見た場合の各ノードの認識状況を確認する術もありません。その為、仕様を確りと確認して運用しないとバランシングが意図した形になっていない事も発生し、それを確認するにはログや確認する為の仕組みを自ら準備するしかありません。

このように地味ではありますが、結構致命的なものについて不足していたりしますのでこの点は注意が必要です。
　
もっとも｢ConoHa｣は今年リニューアルが行われましたのでこのような状況が発生していると言うこと自体にはある程度理解はできます。
ただそろそろリニューアルから半年経ちましたし、年も新しくなることですから･･･

今後このような点について改善が進むと利用者として非常にうれしいですので、この記事を通じて是非改善が進んでくれることを期待しています。

メリット・デメリットについて簡単にご紹介しましたが、あきらかに｢ConoHa｣の満足度は私の中では高く、不足する情報や機能については中の人の今後の対応に期待しつつ利用を重ねることで仕様面については理解を深めれば多くのデメリットは比較的安易に解消する事が可能です。
一部の機能だけを見ると代替できるサービスもありませんので、多くのVPSサービスの中で利用経験を重ねてもよいサービスの一つであると私は思います。
　
次回は実際に｢ConoHa｣でサーバを立ち上げる部分について幾つか実例を交えながら紹介を続けたいと思います。

15日までお休みします

「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の記事ですが11日目から途絶えており申し訳ありません。
ネタ原稿は手元にあるものの、仕事の関係から投稿まで至っておりません。
　　
15日を過ぎれば仕事も少し落ち着く（予定）ですので、16日から再会予定です。

SlimフレームワークからTwigを利用する

この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の１０日目の記事です。
　
今回はSlimフレームワークでTwigを利用する方法を紹介します。

導入

SlimフレームワークでTwigを利用するには｢Slim-Views｣と｢Twig｣の２つを導入する必要があります。
SlimフレームワークでTwigを利用する場合、Slimフレームワークのカスタムビューとして｢Twig｣を指定し利用します。そのカスタムビュークラスとして機能するようにインターフェースとして機能するものが｢Slim-Views｣です。

github.com

何れもComposerで簡単に導入ができます。

[(username)@www ~/bin]$ composer require slim/views
[(username)@www ~/bin]$ composer require twig/twig

｢Twig｣を利用する場合のシンプルなコードは次のようなものです。

index.phpの11行目でカスタムビューとして｢Twig｣の利用を設定しています。
11行目から14行目はビューに対する追加設定として｢debug｣と｢cache｣を設定しており、｢cache｣は文字通りキャッシュの生成先を指定します。 ｢debug｣を｢true｣にするとテンプレートに設定する変数を｢dump｣出力(var_dumpのようなもの)する事も可能です。
　
その場合は次のようにします。

index.php側では16行目から19行目に追加しているようにエクステンションの利用について設定します。 またテンプレート側ではdump出力したい変数に対して｢dump()｣関数経由で出力するように設定する事で変数の内容をdumpする事が可能です。
　
このようにSlimとTwigの連携は非常に簡単です。

Twigの機能

さてTwigには様々な機能がありますが幾つか紹介したいと思います。

include

一般的にTwigの勉強をすると最初に紹介されているのは｢extends｣つまりはテンプレートの継承ですが、私はまずはincludeを紹介します。
includeは基本的には単純に別なテンプレートを読み込み表示する機能です。
　
例えば次のように利用します。

ベースとなるページは｢page.html｣というテンプレートで作成し、その中のフッター部分は｢footer.html｣というテンプレートで別途作成、そしてそれを｢page.html｣テンプレートからincludeして使用しています。
ちょっとしたページを作成しその一部分を共通化するだけであればincludeの方が直感的で簡単に利用する事が可能です。
　
またincludeでは値を渡す事も可能です。

上記の例ではincludeするテンプレートに制作年である｢2015｣を｢year｣変数に対して渡しています。

extends

Twigで最も活用されるのが｢extends｣です。 いわゆるテンプレートの継承で、簡単に言えば予め雛形となるベースのテンプレートを作成しそこにそれぞれのページで部品となるコンテンツを設定し利用するものです。
　
簡単な例を次に示します。

まず予め雛形となるテンプレート(上記の例では｢base.html｣)を作成します。
次に実際に表示するページのテンプレートを作成しますが、そのテンプレートの中で雛形となる｢base.html｣を継承する設定を行います。
　
具体的には2行目の内容が継承を行う設定となります。
　
まず雛形となるテンプレートでは｢block｣を設定します。この｢block｣が継承先のページで実際のコンテンツに置き換わる部分となります。
例えば｢base.html｣の4行目を見ると｢{% block title %}｣から始まり｢{% endblock %}｣までの部分が一つの｢block｣となります。
なお、雛形となるテンプレートで｢block｣の中に記述されている内容は継承先のコンテンツに置き換わります。
　
実際にこのページを実際に表示すると次のようなHTMLとなります。

なお、このケースでは｢itemid｣に｢1234｣が渡されて表示されています。
｢include｣と｢extends｣は組み合わせて利用する事も当然可能ですので、ページ構成そのものは｢extends｣で準備し、うち一部の共通部品のみ｢include｣するような活用でもよいでしょう。

Twigにはその他にも様々な機能がありますので是非一度公式サイトで確認してみるとよいでしょう。

Twigを単体で利用する

さて今回はSlimフレームワークからの利用を前提に説明しましたが、そもそもTwigは単体での利用も当然可能です。 Twigを単体で利用する場合は次のような形で利用します。

使用したテンプレートは｢Example.05-1｣及び｢Example.05-2｣で準備したものをそのまま活用しています。
テンプレートを配置するディレクトリとキャッシュ用ディレクトリを指定しあとは出力する処理を記述するだけで利用可能です。

今回はSlimからTwigを利用する方法と簡単なテンプレートの利用方法について紹介しました。
Twigの機能を紹介するには具体的なケースを示しながらサンプルを準備する必要もあり今回は｢include｣と｢extends｣以外は一切説明していませんが、機能を利用するケースがあれば都度説明していきたいと思います。
　
テンプレートの活用は非常にコードの再利用性も高まり非常に作業効率の向上が期待できます。
一度覚えてしまうと直感的にテンプレートとコードの分離も行えるようになりますので積極的に活用する事でプロトタイプの開発にも生きてくると思います。
なお、Twigのようなテンプレートエンジンはページの出力だけでなくメール本文の作成やファイルの生成等実は様々な所で応用が可能です。
そういった活用方法も積極的に利用することで経験値として積み重ねる事ができますので積極的に活用を検討してみると新しい使い方が見つかるかもしれません。
　
さて次回は一度ライブラリの紹介を離れます。その後またライブラリの紹介を続けることを想定しています。

Slimフレームワークの利用（設定、ログ、環境の切替など）

この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の９日目の記事です。
　
今回までマイクロフレームワークであるSlimの説明を行います。
　
前回までの説明でルーティング、パラメータ、ビュー（レンダリング）、フック処理、Cookieの利用、Sessionの利用などいわゆるWebアプリケーションを作成する場合によく利用する機能について簡単に説明しました。
今回は最後にSlimフレームワークの設定やログの利用などについて簡単に説明します。

設定

設定と一概に言っても利用する機能で様々な設定がありますが、ここでは初期化時に行う設定について紹介します。
多くの設定は初期化時に一括して行う事も可能ですし、あとから個別に設定する事も可能です。

① Debug

デバッグモードの切り替えを行います。デフォルトは｢True｣が設定されています。 ｢True｣が設定されている場合、エラーが発生した場合はSlimのエラー画面(Slim Application Error) が表示されます。
｢False｣を設定した場合、｢$app->error()｣が呼び出されます。

このコードでは｢/｣パスにアクセスすると意図的にエラーを発生させています。 7行目でDebugを｢false｣に設定している為、エラーが発生すると｢$app->error()｣が呼び出されます。その結果画面に｢Error.｣のメッセージが出力されます。 　
運用環境にリリース後はSlimのエラー画面は利用者に見せるべきものでもありませんのでこの設定で変更を行います。

② Log

Log設定を行う事で簡単にログ出力を行う事が可能です。

このコードでは最も単純なログ出力を行っています。
Slimのログ出力はあらかじめLogWriterを準備しそれを設定する事で利用できます。標準のログ機能はソースを読むとわかりますが非常に単純なものです。
6行目がLogWriterの準備にあたりますが、単純にファイル出力のハンドルを引き渡しているだけです。
その他２つほど設定が可能です。 一つは｢log.level｣です。これは一般的なログレベルと同様で出力対象となるログを制御できます。
上記のコードでは｢INFO｣に設定されていますので、18行目の｢INFO｣レベルのログは出力されますが19行目の｢DEBUG｣レベルのログは出力されません。
もう一つは｢log.enabled｣で、｢false｣に設定した場合ログの出力は行われません。
　
なお、このように簡単に利用できる一方で実際のログでは出力時刻もなく単純に出力内容が行単位で書き込まれるのみですので実際の利用ではもう少しそのあたりを考慮したいものです。
自分で拡張してもよいのですが、もしも単純にログ出力時刻も合わせて出力したい程度の内容であれば｢Slim-Logger｣を利用する事をおすすめします。

github.com

｢Slim-Logger｣もComposerで簡単に導入でき利用する事ができます。

[(username)@www ~/bin]$ composer require slim/logger

｢Slim-Logger｣を利用した場合のサンプルは次のようなコードになります。

なお｢Slim-Logger｣を利用した場合デフォルトの出力先は｢./logs｣となります。
もしこれらの設定を変更したい場合は次のように初期化を行います。

6行目から11行目にかけての内容が初期化となります。
7行目でデフォルトの出力先である｢./logs｣から｢./log｣へ変更を行っています。その他はデフォルトのままですがこれらを変更する事で出力先、出力ファイル名、拡張子、出力フォーマットを変更する事が可能です。
　
Slimのログ出力ではmonologとの連携で実現されている方も多いと思いますが、私が利用しているプロトタイプ開発のようなケースでは｢Slim-Logger｣で十分機能的に耐えうるものだと思います。

③ TemplatesPath

以前の記事でビュー（テンプレート）の説明を軽く行いましたが、そのテンプレートファイルの配置を変更できます。 変更する場合は次のように変更します。

このコードではテンプレートファイルのディレクトリをデフォルトの｢./templates｣から｢./tpl｣に変更しています。

設定に関しては３つの内容について説明しましたが他にも幾つかの設定がありますが一部は今後のライブラリ紹介に合わせて紹介しますので今回は次の機能を紹介して最後にしたいと思います。

アプリケーションモードの制御

多くのフレームワークであるように運用環境と開発環境の設定をSlimフレームワークでも切り替える事が可能です。
切替方法は単純で環境変数の｢SLIM_MODE｣またはアプリケーションの｢mode｣パラメータに設定したいモードを指定するだけです。
　
例えば次のコードでは運用環境用の設定である｢production｣と開発環境用の設定である｢development｣を準備しており、開発環境用の設定を有効にしているものです。

このように運用環境ではDebugを無効にする事でSlimのエラー出力ではなくエラー画面に遷移させ、開発環境ではSlimのエラー画面を表示する事でデバッグを行いやすくするような運用が可能となります。
今回はコードで切替を行っておりますが環境変数を利用する事でコードの変更漏れ等も防げますので環境に合わせて設定方法を選択するといいでしょう。

以上の内容でまずはSlimの基本的な紹介は終了となります。
　
Slimフレームワークは軽量ですが必要とされる機能は十分有しており今回紹介した以外にもまだまだ便利な機能が整備されていますので、是非本家のドキュメントを見ながらいろいろと活用していただければと思います。
マイクロフレームワークではありますが、プロトタイプの開発や小規模なサービスの開発であれば十分な機能が整備されているだけでなく、取り扱う為の学習コストは非常に低いのも魅力ですので、時間や予算に制限のある企画担当者には非常に適したフレームワークであると思います。
　
さて次回はSlimフレームワークでTwigをテンプレートエンジンとして利用する方法の紹介を行います。

Slimフレームワークの利用（フック処理、Cookieの利用、Sessionの利用など）

この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の８日目の記事です。
　
今回も引き続きマイクロフレームワークであるSlimの説明を行います。
　
前回は最も基本的なルーティング、パラメータ、ビュー（レンダリング）について簡単に説明しました。
今回はフック処理、Cookieの利用、Sessionの利用について紹介します。

① フック処理

例えば認証が必要なアプリケーションを作成する場合、そのコンテンツの表示を行う前にあらかじめ認証状態を確認する必要があります。
そういった場合に利用するのがフック機能です。
　
フック機能ではあらかじめ設定されたフックポイントを利用する事で簡単に処理をフックする事が可能です。
　
例えば具体的なフック処理は次のようなものです。

このコードでは｢/｣｢/mypage｣｢/login｣の３つのパスに応じたルーティングが定義されています。
この内｢/mypage｣はログイン後のみ利用ができるコンテンツを想定しており事前に認証チェックを行っています。
　
具体的には、まず16行目で認証が必要なコンテンツであるかの確認を行っています。
この確認は12行目の｢$arrayAllowPath｣にあらかじめ登録したパスに一致しないパスの場合は認証状態の確認を行います。
そして17行目で認証状態を確認していますが、ここでは認証処理そのものは作っていませんので便宜上｢$app->isAuthenticated｣を認証状態に見た立て利用しています。
今回は認証状態に｢false｣を設定していますので、未認証状態と判定され18行目の｢$app->redirect('/login')｣により｢/login｣にリダイレクトされます。

さて、このフック機能で実装しますと今回のように特定の場合のみ適当するようなケースでは個別に適用または除外の処理を実装しなければなりません。
認証状態確認のような処理であれば問題ありませんが、事前確認が複数存在する場合それぞれにそれらの実装を行うのは非効率的かもしれません。
　
例えば先ほどのコードは次のようにも書くことができます。

このコードでは先ほどのコードとは違い｢/mypage｣にアクセスした場合のみ事前に実行する関数（isLogin関数）を24行目のルーティング設定で行っています。
このように特定の処理を特定のルーティングの振り分け時にのみ事前実行させることも可能です。
　
最初に紹介したフックポイントは紹介したものも含み｢slim.before｣｢slim.before.router｣｢slim.before.dispatch｣｢slim.after.dispatch｣｢slim.after.router｣｢slim.after｣があります。
ドキュメントは次のページにまとまっていますので参考にしてください。

Defaults - Slim Framework v2

② Cookieの利用

Cookieは認証をはじめ様々な機能されますがSlimでも当然利用可能です。
　
次のコードはアクセス数をCookieに保存し表示するものです。

この処理では10行目で対象のキーのCookieの存在を確認し存在していない場合は初期化（1をセット）し、存在している場合はカウントアップし表示しています。
　
このようにCookieも一般的なPHPと同じように利用する事が可能です。
その他設定可能なパラメータも以下のように通常のPHPと同じように利用する事が可能です。

$app->setCookie($name, $value, $expiresAt, $path, $domain, $secure, $httponly);

その他SlimフレームワークではCookieで取り扱うデータを暗号化する事も可能です。
暗号化する場合はあらかじめ設定が必要となります。

この例では｢/set/｣にアクセスした際にCookieにテキスト（myname）を保存し、｢/get/｣にアクセスした場合そのテキストを読み出し表示しています。
このデータが実際のクライアント環境でどのように保存されているかというと次のようになっています。

サーバ側で読み書きする場合は暗号化の事は意識する必要はありませんので簡易的なデータの取り回しの際は利用できるのではないでしょうか。

③ Sessionの利用

当然Cookie同様にSessionもそれほどフレームワークを意識せずに利用する事が可能です。
SlimフレームワークではSessionを利用する場合はPHP標準のSessionを利用する事も可能ですし、Slimフレームワークに統合されたSession機能を利用する事も可能です。
　
例えばSlimフレームワークのSessionを利用する場合は次のようなコードになります。

このコードはCookieのみで実装したコード（Example.3）をSessionを利用して書き直したものです。
実際の利用については一般的なPHPでの実装と変わりませんので特に躓く事なく利用する事ができるのではないでしょうか。

さて、今回も比較的利用頻度の多いSlimフレームワークの機能について紹介しました。 明日は設定やログなどに関する説明を行う最後のSlimフレームワークの説明となります。

Slimフレームワークの利用（基本的な処理）

この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の７日目の記事です。
　
今回はマイクロフレームワークであるSlimの説明を行います。 　
先日の紹介の際にも書きましたが、私がマイクロフレームワークであるSlimに求めるのはルーティングに関する機能、リクエストに関する機能、レスポンス及びビューに関する機能、そして拡張性を持たせる意味でフック処理やそれに類する機能でその他はそれぞれ必要に応じて個別のライブラリの導入で対応できれば特に不満はありません。
できるだけフレームワーク自体はシンプルでアプリケーションの開発を開始する時点で特別な準備を必要とせず直ぐに利用できることが望ましいです。また、企画担当者が作るプロトタイプの場合企画そのものが進行に合わせて変化する事も多く、序盤から設計と開発が依存しあうようなものは使い辛くなります。そういう点でもSlimは非常にシンプルで利用するだけであればモデルの設計も不要で仮に途中で実装方針が変わった場合も柔軟に対応する事が可能です。
　
もっともマイクロフレームワークと言いながらもWebアプリケーションとして主に利用する機能はその多くが標準で搭載されておりフルスタックフレームワークとの違いはマクロ的な機能の実装レベルの違いと考えても差し支えありません。
　

｢Slim｣の導入

Composerで簡単に導入できます。

[(username)@www ~/bin]$ composer require slim/slim

以上で完了です。 なお、Slimを利用するにはPHPのバージョンが5.3以上である必要があります。

｢Slim｣の基本的な使い方

それではSlimの基本的な使い方から紹介します。
もっともシンプルなコードは以下のようなコードでしょう。

<?php

require 'vendor/autoload.php';

$app = new \Slim\Slim();

$app->get('/', function () {
    echo "Application Root.";
});

$app->run();

このコードではルートパスへのアクセスがあった場合｢Application Root.｣とメッセージを返します。
Slimフレームワークで最もシンプルな利用方法はこのようなGETやPOSTのようなルーティングを定義しそれに応じた処理を記述する方法です。 　
さてSlimアプリケーションは基本的には一つのスクリプトから成ります。
前述のコードが例えば｢index.php｣に記述されている場合、全てはその一つのファイルで処理が振り分けられます。
例えば次のようなコードの場合はどうでしょうか。

<?php

require 'vendor/autoload.php';

$app = new \Slim\Slim();

$app->get('/example', function () {
    echo "Example.";
});

$app->run();

例えば｢example.com｣というドメインでアプリケーションが公開される場合｢/example｣へのアクセスはどのようになるでしょうか。
　
答えは｢http://example.com/index.php/example/｣となります。
できれば｢http://example.com/example/｣でアクセスしたいですね。その場合はHTTPサーバ側のRewrite機能を使いましょう。
さくらのレンタルサーバであれば以下のような内容を｢.htaccess｣ファイルに記述し該当のアプリケーションディレクトリに配置します。

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [QSA,L]

基本的にはサーバ側での対応はこれだけです。
あとは必要となる機能をファイルに記述するだけで簡単にアプリケーションを作成できます。
　
それでは実際に利用できる機能のうちもっとも基本的な機能を紹介します。

① ルーティングの定義

最も利用頻度の高いルーティングはGETやPOSTのようなメソッドのルーティングです。

<?php

require 'vendor/autoload.php';

$app = new \Slim\Slim();

$app->get('/', function () {
    echo "Application Root.";
});

$app->get('/example1', function () {
    echo "Example1.";
});

$app->post('/add/example2', function () {
    echo "Example2.";
});

$app->run();

このコードではGETメソッドで｢/example1｣パスにアクセスした場合と、POSTメソッドで｢/add/example2｣にアクセスした場合に対応したルーティングを記述しています。
何れの場合も単純にメッセージを返しているだけですが、このようにメソッドやパスに応じたルーティングを定義し処理する事が可能です。
GET及びPOST以外にもPUTやDELETEなどのメソッドにも対応していますのでRESTfulなAPIを実装する事も比較的容易に対応できます。

② パラメータの受取り

次に頻度が多いものとしてはパラメータの受取りでしょう。

<?php

require 'vendor/autoload.php';

$app = new \Slim\Slim();

$app->get('/item/:itemid', function ($itemid) {
    echo "ITEM ID : " . $itemid;
});

$app->post('/register/', function () use ($app) {
    $username = $app->request->post('username');
    echo "UserName : " . $username;
});

$app->run();

このコードではGETメソッドでパラメータとして｢itemid｣を受け取り出力し、またPOSTメソッドでは受け取ったパラメータの｢username｣を出力しています。
GETメソッドのパラメータはパスの構成通りに定義し受取り変数を指定する事でプログラム内で利用する事が可能です。
一方でPOSTメソッドのパラメータはuse句でSlimアプリケーションインスタンスである｢$app｣を受け渡し｢ $app->request->post()｣でアクセスする事が可能です。
なお、もしも｢$_REQUEST｣のようにメソッドを意識せずに利用したい場合は｢$app->request->params()｣を利用してください。

③ ビュー(レンダリング)の処理

Slimフレームワークでもビューの機能は準備されています。
使用する場合は本体と合わせてビューテンプレートも準備します。

■index.php

<?php

require 'vendor/autoload.php';

$app = new \Slim\Slim();

$app->get('/item/:itemid', function ($itemid) use ($app) {
    $app->render('item.html', array("itemid" => $itemid));
});

$app->run();

■item.html

<html>
<body>
<p>ITEM ID : <?php echo $itemid ?></p>
</body>
</html>

テンプレートフォルダはデフォルトではプログラムが配置されているディレクトリ直下の｢templates｣となりますので｢item.html｣を作成後配置する事で利用できます。
テンプレートを見てわかる通り記載内容はPHPプログラムそのものですので高度な使い方をする場合は別なテンプレートエンジンとの組み合わせが必要です。
もっともより高度な使い方を行う場合はフルスタックフレームワークの利用も検討が必要ですので一概にテンプレートエンジンに利用を必要とするものではありません。
テンプレートファイルのディレクトリの変更については初期化処理に関する説明の際に合わせて行いたいと思います。

さて初回はSlimアプリケーションのもっとも基本的な使い方を紹介しました。
次回はフック処理を含めもう少し高度な利用など引き続きSlimフレームワークの紹介を続けます。