ソフトウェア・開発」カテゴリーアーカイブ

マイクロフレームワークっぽく使う Symfony 4 事始め 1 ~インストール編~

PHPのWebアプリケーションフレームワーク Symfony 4.x をマイクロフレームワークっぽく利用し始める事始め(入門)をまとめてみたいと思います。Symfonyは公式のドキュメントがそれなりに充実しているのでそこを読める人であれば読めばOK!なんですが、あまりにも日本語の情報が無く、有ってもバージョンが古い頃の情報だったりしてちょっとつらいです。今回は以下の環境でまとめています。私自身が使い始めたばかりなのでよく分かっていない部分はよく分かっていないと書いています。

Symfony: 4.2
PHP: 7.2 (Windows版ですが他の環境と特に違いは無いです)
Composer: 導入済み
MySQL: 8.0 (Windows版ですが他の環境と特に違いは無いです)

PHPのビルトインサーバーで動作するのでApacheやNginxは開発環境で動かす分には不要です。

インストール

インストール完了までの手順は以下の記事を大いに参考にさせて頂いております。リンク先の方が詳しいです。

Symfony4をインストールして”Hello World”を表示させるまでの手順 | QUARTETCOM TECH BLOG
Installing & Setting up the Symfony Framework (Symfony Docs)

プロジェクトを作るディレクトリに移動しComposerでインストールしていきます。symfony/skeltonを導入する事で必要な最小限の諸々 + Symfonyのパッケージ管理を楽にするための仕組み Symfony Flex が導入されます。

composer create-project symfony/skeleton <プロジェクト名>

作成されたプロジェクトのディレクトリに移動し、PHPのビルトインサーバを使うための Server レシピを導入します。serverという名前指定だけで目的のパッケージが導入されますが、この部分がFlexにより支援されている部分のようです。

composer require server

導入後は以下のコマンドでビルトインサーバーが起動します。consoleファイルの中身はPHPで実行するようにshebangが設定されたPHPファイルです。Windowsの場合はコマンドの頭に「php 」を付けてPHPのファイルである事を明示的に指定してやれば同様に動きます。

php console/bin server:run

実行した様子。Ctrl+C で終了。

コントローラなどを生成できる maker レシピ、コントローラを実装する際に定義ファイルの編集ではなくコントローラコード上のアノテーションで行えるようにする annot レシピを導入します。アノテーションでルーティングする機能は実態としては sensio/framework-extra-bundle に含まれています。デバッグ・プロファイリングに便利な debug-pack も導入します。

composer require maker
composer require annot
composer require debug-pack

テンプレートエンジンにTwigを使いたいので twig レシピを導入します。APIサーバーとして使う(JSONしか返さないつもり)なら入れなくても良いんじゃないかと思います。

composer require twig

これで「何かしらのURLにアクセスしたらコントローラがルーティングしてテンプレートエンジンがテンプレートを使ってページを表示する」という基本部分が完成しました(DB処理は後からふれます)。

色々と導入してきましたが、それに伴いconsoleコマンドでCLI実行できる機能も増えています。 bin/console xxx:xxx で使えるコマンドの一覧は特に引数を渡さずに実行すると確認できます。

php bin/console

以下が実行結果。多いので中略しています。

Hello World

決まった文字が文字が表示されるだけのページを作ってみます。以下のコマンドでコントローラを作成します。

php bin/console make:controller RootController

テンプレートとコントローラが作成されました。 maker:controller は便利コマンド的な物なので作り込んで来たら既存のコントローラをコピペするなどして手動で作成しても良いのですが、最初はこれを叩いた方が簡単です。

この時点でのプロジェクトのルート配下のファイル・ディレクトリ構成は以下のような感じになっています。

  • /bin :consoleコマンドやあとで導入するphpunitコマンドがここに入ります。
  • /config :各種設定ファイルが入ります。
  • /public :ドキュメントルートはここ。index.phpの場所。
  • /src :PHPのコード
    • Controller :コントローラーが作られる場所。
  • /template :Twigテンプレートの場所。src配下ではない。
  • /var :ログファイルであったりなどがここに作られます。
  • /vendor :Composerで導入されていくパッケージ。
  • .env :これもSymfonyの環境設定に関わるファイル。ここで環境によって設定を変えたりできる?
  • composer.json :Composerで導入されたパッケージの管理。
  • composer.lock :同上。
  • symfony.lock :Symfony関連のパッケージ管理。謎が多い。

コントローラのコードは以下のようになっています。

<?php

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\Routing\Annotation\Route;

class RootController extends AbstractController
{
    /**
     * @Route("/root", name="root")
     */
    public function index()
    {
        return $this->render('root/index.html.twig', [
            'controller_name' => 'RootController',
        ]);
    }
}

PHPDocに記載の有る @Route 定義がアノテーションによるルーティングです。”/root”にマッチするURLが来た場合にこの index 関数が実行されます。nameはユニーク(他とかぶりが無い)である必要が有るので注意してください。

結果はResponseオブジェクト( Symfony\Bundle\FrameworkBundle\Controller\Response)をreturnで返します。$this->render() を呼び出すとTwigでレンダリングした結果をResponseオブジェクトとして返してくれます。JSONで返したい場合は $this->json() という関数が有ります。

Twigテンプレートは以下のようになっています。

普通のTwigテンプレートなので特に必要はないかと思いますが、念のため雑に説明しておきます。

  • {{ xxx }} 変数の表示。自動でHTMLスケープされます。
  • {% xxx %} 変数を表示する以外の分岐やループなどの機能は {% で囲まれます。
  • {# xxx #} コメントアウト。コメントアウトは {# で囲みます。

$this->render() 時に渡した変数 controller_name からコントローラー名「RootController」が表示されるようになっていますね。

ではページを見てみます。php bin/console server:run でビルトインサーバを起動し、Webブラウザで http://127.0.0.1:8000 にアクセスします。

これはデフォルトのルートページ的な物になり、画面左下にも出ているように HTTP 404 Not Foundとなっています。ページ下部に表示されているステータスコード、処理時間、エラーログ確認などが debug-pack で導入された機能によって表示されているプロファイラ機能です。クリックするとより詳細な情報を確認する事が出来ます。

作成したコントローラに対応する http://127.0.0.1/root にアクセスしてみます。

目的のページが表示されました。画面左下よりステータスコードも HTTP 200 (正常) となっていますね。

とりあえずここまででページを表示するための最低限のものが動くようになりましたが、ルーティングの詳細やDB処理などまだ必要な物が有ります。次はルーティングについてまとめます。

ここまでのコードの状態は以下を参照してください。
https://github.com/lf-uraku-yuki/symfony4_tutorial/tree/tutorial01

続きの記事

Zabbixのバージョン間互換性について再確認する

この記事は Zabbix Advent Calender 2018 の12月15日分の記事です。今回はZabbix監視で利用する zabbix-agent、zabbix-server、zabbix-proxy の互換性について再度確認してみたいと思います。

互換性について参照する物

基本的にはまさに互換性に関する記載のあるページが公式のドキュメントに有ります。4.0の場合は以下。メニューのツリー的には Appendixes の中に有ります。

13 Version compatibility [Zabbix Documentation 4.0]
https://www.zabbix.com/documentation/4.0/manual/appendix/compatibility

ですが、互換性についてのページはあくまで疎通が取れるかについての言及になっているので、実際の細かいバージョン間差異については、新機能アップグレードノートアップグレード手順既知の問題ページなどバージョン間差異に言及しているページはいくつか読んでおくとより安心感が増すかと思います。エージェント監視アイテムはアイテム項目のページも読んでおきましょう。そこを読むことで気づく注意点がいくつか有ります。例えば同じアイテム(特にCPUやメモリ周りなど)で数値の取れ方に変更が有ったりと言った事が有ります。

互換性についてまとめる

2018年12月15日 Zabbix 4.0.2 現在においての状況をまとめてみます。

zabbix-server – zabbix-agent間の互換性

agent側が古い分についてはserverとの疎通を取る事が来ます。バージョン1.4以降のzabbix-agentであればzabbxi-server 4.0から監視可能です(もちろんバグ修正やパフォーマンス改善などの点からエージェント側もなるべく新しい方がいいです)。ただし古いエージェントほど対応しているアイテムの数が少ない、同じアイテムでも使えるオプションの数が少ない、値が取れても過去のバージョンでは算出方法が違う、と言った事が有りますので、それぞれアイテム項目の確認は行っておいた方がいいでしょう。

また、server – agent 間での通信を暗号化できるようになったのは 3.0 LTS からなので、必ず暗号化しておきたいという場合は 3.0 LTS までバージョンを上げた方がいいでしょう。

ちなみに zabbix-agent 1.4 以降という制限は、Zabbix 3.0 LTS や Zabbix 3.4 のドキュメントには記載が有りませんでした。あまりにも古い環境なので気にする方は少ないかと思いますが、これは4.0で新しく加えられた制限なのかと思われます。

Zabbix 4.0該当記載
https://www.zabbix.com/documentation/4.0/manual/appendix/compatibility
Zabbix 3.4 該当記載
https://www.zabbix.com/documentation/3.4/manual/appendix/compatibility
Zabbix 3.0 該当記載
https://www.zabbix.com/documentation/3.0/manual/appendix/compatibility

なお、逆にagentの方が新しい場合についての言及が見当たらないですが、実際の所 zabbix-server よりzabbix-agent が新しい場合については疎通が取れません。これはzabbix-server 4.0.2 と zabbix-agent 3.4.15 の環境で試してみて実際にダメでした。zabbix-get コマンド(4.0系)からの値の取得も動作しませんでした。

zabbix-server – zabbix-proxy間の互換性

zabbix-serverとzabbix-proxyは同じメジャーバージョンでなければ動作しません。例えばzabbix-proxyが多数動作する環境であってもzabbix-serverのバージョンを上げる際は一緒に対応する必要が有ります。

公式のドキュメントでも言及が有るようにzabbix-proxy側のバージョンが古い分には一応監視が継続出来る場合が有ります。ただしこれはZabbix的にはサポートしていない仕様外の動作となります。あくまで既に設定済みの監視設定のまま値が取れるだけであり、監視設定の変更が出来ません。

https://www.zabbix.com/documentation/4.0/manual/appendix/compatibility

proxyが有る状況での具体的なアップグレード手順は公式から提供されているのでそれに従った方がベターです。以下はRed Hat Enterprise Linux / CentOSでアップグレードする場合です。

1 Red Hat Enterprise Linux/CentOS [Zabbix Documentation 4.0]
https://www.zabbix.com/documentation/4.0/manual/installation/upgrade/packages/rhel_centos

なお、これは仕様と言うよりバグなのですが、zabbix-server 3.4.10 と zabbix-proxy 3.4.10 ではそのバージョン同士でしか通信が取れません。これは Zabbix 3.4のページにだけ記載が有ります。

https://www.zabbix.com/documentation/3.4/manual/appendix/compatibility

まとめ

内容としては既にまとめていますが、以上になります。今回は言及していませんがバージョンごとに求めるミドルウェアやライブラリのバージョンも異なるのでアップグレードを行う際はその点にも注意しましょう。いずれについてもZabbix公式のドキュメントは細かい所まで手が行き届いているのでGoogle 翻訳使ってでもいいからなるべく公式の資料は読みましょう!

Zabbix公式
https://www.zabbix.com/jp/
Zabbix Manual [Zabbix Documentation 4.0]
https://www.zabbix.com/documentation/4.0/manual

Zabbix Advent Calendar 2018 – Qiita
https://qiita.com/advent-calendar/2018/zabbix

私のほかのZabbix関連投稿
https://www.sodo-shed.com/archives/tag/zabbix

MySQLでDB内の全てのテーブルに対してshow create tableする

どうも簡単なスクリプトを書いた方が早いみたいなのでそうする。以下を実行すると指定したDBの全てのテーブルに show create table した結果が出力されます。mysqldupのスキーマのみオプションでは重厚すぎる場合などに。二つのDBに対して実行した結果をdiffで比べて簡易mysqldiffとしても使えます。

GitHub Gist – mysql_all_create_tables_for_php

<?php 
$con = new mysqli('localhost', 'root', 'pw', 'dbname');
$mysqli_result = $con->query('show tables');
$table_name_array = $mysqli_result->fetch_all(MYSQLI_BOTH);
$mysqli_result = null;
foreach ($table_name_array as $row) {
    $mysqli_result = $con->query('show create table ' . $row[0]);
    $create_table = $mysqli_result->fetch_array();
    echo $create_table[1] . "\r\n\r\n";
    $mysqli_result = null;
}