‘Laravel’ タグのついている投稿
Laravelのテスト用便利トレイトの動作を変えてみる
Laravel 5.5 です。
Laravelにはunit test等の際にuseするとよろしくやってくれるトレイトがあります。
昨日の記事に出てきたRefreshDatabaseやDatabaseMigrations、他にはDatabaseTransactions、WithoutMiddleware、WithoutEventsがあります。
本当に便利なのですが、すこし動作を調整したいこともあります。
例えばDatabaseMigrationsでマスターの流し込みまでやりたいとか。
(さらに…)
Laravel Dusk メモ
Laravel 5.5 & Laradock(https://github.com/laradock/laradock)環境です。
Laradockについては少し古いかもしれません(活発に更新されているのですぐに古くなる)。
Laravel Dusk はブラウザテストをお手軽に!というパッケージです。
https://readouble.com/laravel/5.5/ja/dusk.html
Laradockでのセットアップと使い始めてすぐのログインテストで何回かつまづいたのでメモを残しておきます。
(さらに…)
Laravel 5.5 でデータベースdumpをお手軽にとったりもどしたり
- 2017/11/27
- murave
- Laravel
- PostgreSQL
muraveです。LTSを使いたい人なのでLaravelのバージョンが5.1から5.5にジャンプアップしました。
その際、いままで使っていたデータベースバックアップのプラグインが使えなくなりました。
データベースdumpをお手軽にとったりもどしたりしたかっただけだったんだけど、重厚なバックアップ用パッケージが見つかった。これはこれで入れとくかぁ。
— murave (@murave) 2017年11月24日
ということで
https://github.com/spatie/laravel-backup
を導入。良い感じです。もしかして?と、この方のリポジトリを探してみたらありました。
https://github.com/spatie/laravel-db-snapshots
This package provides Artisan commands to quickly dump and load databases in a Laravel application.
そうそう、この記事の対象データベースはPostgreSQLです。
PostgreSQLの場合にレストア時にエラーでデータベースを飛ばしたので、その対処方法のメモだったりします。MySQL、SQLiteにも対応らしいですが試してません。導入や使い方はドキュメント見てくださいね。
dockerからAmazon EC2への奮闘記
- 2017/08/09
- okada
- Amazon EC2
- Docker
- Laravel
今までdockerを使ったことがなかった私、勉強がてらLaradockを使ってLaravelで開発を行っていました
そこからAmazon EC2へ移行するまでの過程で色々行き詰まり、
なんとかLaradockからEC2へ環境移行することができましたので、
今後のメモのためにログを残しておこうと思います
今回書く内容はLaradockの環境設定〜Amazon EC2へ設置するまでの簡単な流れで行き詰ったものを晒すだけのほぼ日記の様なものです(笑)
Docker for Mac 〜 Laradockを導入するまで
$ git clone --depth=1 -b v5.5.1 https://github.com/LaraDock/laradock.git
$ cd laradock
$ cp env-example .env
$ vi .env
…とこのようにまずはドキュメントに従って導入を行っていました
しかし
問題1:Laradockを導入したが起動しない
$ docker-compose up -d nginx mysql
ERROR: Couldn't connect to Docker daemon - you might need to run `docker-machine start default`.
$ docker-machine start default
Host does not exist: "default"
defaultを設定しないといけない?
$ docker-machine create --driver virtualbox default
をすればよい、とのことだったので実行してみたけれどエラー発生
そもそもDocker for Macはvirtualbox使わなくても良くなった、との記述を見かけた気が…
解決:boot2dockerとDocker for macが混在していた
Laradockの問題ではなく、dockerの問題でした
どうやらDocker for Macを入れる前にboot2dockerをhomebrewで入れていたようで、
PC内にdockerが2つある状態でした
ということでboot2dokerを削除
brew uninstall docker boot2docker docker-compose docker-machine
念のためDocker for Macもアンインストールして入れ直し、もう一度動かしてみた所無事にLaradockを動かすことができました!
まぁこんなことしでかすなんて自分くらいしかいないと思うので参考にはならないかもしれませんが、思い出の一つとして…
問題2:MySQLが動かない
次のようなエラーが発生してMySQLが起動しない
docker-compose ps
を実行してみた所、laradock_mysql_1のstateはExitでした
$ docker-compose up --build -d nginx mysql
$ docker-compose exec mysql bash
ERROR: No container found for mysql_1
ログを確認
$ docker logs laradock_mysql_1
2017-08-01T08:01:50.339823Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4800!
解決:MySQLのデータファイルを削除
このエラーに関しては.envファイルを確認し、MySQLのデータファイルを削除した所、起動に成功しました
$ vi .env ⇐ laradock/.envを確認
10 ### Data Path:
11 # For all storage systems.
12
13 DATA_SAVE_PATH=~/.laradock/data
$ cd ~/.laradock/data
$ mv data data.old
Laradockが動かない…動かない…と入れ直しを繰り返した時にゴミファイルとして残ってしまっていた模様
ローカルからAmazon EC2へ
システムが出来上がり、次はシステムをローカルからEC2へ移行作業へ…
まずLaradock環境内のバージョンを確認
EC2側にもPHP7.1、MySQL5.7、nginxをインストール
$ docker-compose exec workspace bash
# php -v
PHP 7.1.4-1+deb.sury.org~xenial+1 (cli) (built: Apr 11 2017 22:12:32) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.1.4-1+deb.sury.org~xenial+1, Copyright (c) 1999-2017, by Zend Technologies
# php artisan --version
Laravel Framework 5.4.30
# exit
exit
$ docker-compose exec mysql bash
# mysql --version
mysql Ver 14.14 Distrib 5.7.19, for Linux (x86_64) using EditLine wrapper
# exit
exit
EC2側環境作成
PHP、MySQL、nginxインストール後…
以下のファイルを編集
$ vi /etc/php-fpm.d/www.conf
24 user = nginx
25 ; RPM: Keep a group allowed to write in log dir.
26 group = nginx
48 listen.owner = nginx
49 listen.group = nginx
50 listen.mode = 0660
$ vi /etc/nginx/nginx.conf
40 server {
44 root /var/www/html/public;
73 location ~ \.php$ {
74 root /var/www/html/public;
75 fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
76 fastcgi_index index.php;
77 fastcgi_param SCRIPT_FILENAME /var/www/html/public$fastcgi_script_name;
78 include fastcgi_params;
79 }
それぞれのサービスを起動 & 自動起動するように設定
$ sudo service nginx start ⇐ サービス起動
$ sudo service php-fpm start
$ sudo service mysqld start
$ sudo chkconfig nginx on ⇐ 自動起動
$ sudo chkconfig php-fpm on
$ sudo chkconfig mysqld on
MySQL5.7ではrootユーザには初期パスワードなるものが存在し、
最初はそのパスワードでログインする
[ec2-user@ip-172-31-46-167 ~]$ sudo cat /var/log/mysqld.log
2017-08-03T06:59:34.488345Z 1 [Note] A temporary password is generated for root@localhost: Jt?eJUpbO6kl ⇐コレ
rootのパスワードは変更しておくべし
$ mysql -u root -p
> ALTER USER 'root'@'localhost' IDENTIFIED BY 'パスワード';
Laravelのドキュメントに従いComposerをインストール後、Laravel5.4を導入
$ composer global require "laravel/installer"
$ cd /var/www/
$ laravel new html
ブラウザでLaravelのTOP画面が表示されることを確認
Laradockからお引っ越し
ローカルのLaravelより、gitを使ってアーカイブファイル作成!
Laradockには既に.gitignoreファイルが準備されており、logファイル等など必要ないファイルは省かれる様になっていました。便利!
git archive HEAD --output=~/WorkSpace/project/release/archive.zip
このファイルを/var/www/htmlに上書き(.envの取扱い注意!)し、
ファイルの権限を変更 chmod o+w -R storage
そして以下のコードを実行
$ php artisan config:cache
$ php artisan route:cache
.env.exampleを.envに書き換え、EC2上の環境に合わせた設定に書き換えます
そしてブラウザで確認!
The only supported ciphers are AES-128-CBC and AES-256-CBC with the correct key lengths.
こんなエラーが表示されましたよ…
以下を実行
$ php artisan key:generate
$ php artisan config:clear
.envファイルの APP_KEY=
にキーがセットされるわけですね
無事TOPが表示されました!
でもページが遷移しませんよ?
/loginへ遷移できません。404エラーです。
原因はnginxの設定。5.4のドキュメント通りにnginx.confを編集。
$ vi /etc/nginx/nginx.conf
49 location / {
50 try_files $uri /index.php?$query_string;
51 }
これで他のページへも遷移できるようになりました!
以上がEC2への引っ越し奮闘記になります。
Laravel 5.1 でログ出力、faultline-php追加編
Laravel の次のLTS、5.5もそろそろ来そうな昨今ですが、また5.1のログ出力の話です。
昨日のBlogに書いたようにプロジェクトのログ出力に faultline-php (https://github.com/faultline/faultline-php) を組み込みました。Monolog integration のありがたさよ。
今日は faultline 関係の .env 対応を進めているのですが、コードがややこしくなる前の素朴なのをサンプルとして出しておこうかな〜と。
Laravel 5.1 でログ出力、それから (ログメールドライバー動作不良対処、クエリ出力の調整)
おひさしぶりです。運用していたら結構変わったので、またこのネタです。
一応以前の記事へのリンクおいときます。
『Laravel 5.1 でログ出力、その後 (出力レベル設定、クエリ出力)』
が、以前の記事の方法だとログメールドライバーが動作しないという問題が発生したので参考にしちゃだめ。
というわけで、以下の要件と不具合対処のために改修した内容を紹介します。
- ログファイルの権限絡みのエラー回避、何処から起動された処理かわかりやすくする等の目的で実行ユーザー名ベースでログファイルを作成。
- 動作環境(local, testing, production等のenvironment)でもログファイルを分ける。
- バッチ処理やartisanのコマンド実行の場合はARTISAN_BINARYをログファイル名に挿入してWebアクセスとはログファイルを分ける。
- デバッグフラグ(app.debug)を落とした状態ではINFO以上のログのみ出力。
- .envでAPP_QUERY_LOGGINGにtrueを設定したら発行されたクエリをinfoログで専用ログファイルに出力(デバッグフラグでのコントロールを廃止し個別にコントロール可能とし、ファイルも分けた)
- 以前の実装ではログメールドライバー(メール送信内容をログ出力するドライバ)が正常動作しなかったためLoggerインスタンスを差し替える方法から既存Loggerインスタンスのhandlerを差し替える方法に実装を変更。
Laravel 5.1 でログ出力、その後 (出力レベル設定、クエリ出力)
2017/2/1
不具合があったので『Laravel 5.1 でログ出力、それから (ログメールドライバー動作不良対処、クエリ出力の調整)』のほうを見て下さい
少し前に書いた『Laravel 5.1 で実行ユーザー毎にログ出力』という記事の続き的なものです。
環境も変わらず Laravel Framework version 5.1.35 (LTS) です。
前回のあらすじ
「ログ出力時に実行ユーザー名ベースでログファイルを作るようにすればログファイルの権限絡みのエラーを回避できるし何処から起動された処理かわかりやすくなって良くない?」と思ったボク。AppServiceProviderのboot()でloggerを差し替えつつも「ここでやっちゃっていいのかしら」という戸惑いを感じたりもして…
で、戸惑ってましたが実行準備の一貫としてAppServiceProviderでやってて問題なさそうかなと思ってます。ツッコミもこなかったし。
今回は実際に開発で使っていて
・デバッグフラグ(app.debug)を落とした状態ではINFO以上のログのみ出力
・デバッグフラグ(app.debug)を立てた状態では発行されたクエリをDEBUGログで出力
という機能追加をしたので、その紹介です。
Laravel 5.1 で実行ユーザー毎にログ出力
2017/2/1
不具合があったので『Laravel 5.1 でログ出力、それから (ログメールドライバー動作不良対処、クエリ出力の調整)』のほうを見て下さい
Laravel Framework version 5.1.35 (LTS) についての記事です。
muraveです。あんまりにもあんまりな記事(「PHP カンファレンス福岡 2016 で思ったこと」)を上げて反省しましたのでPHPお役立ち記事を書きたいと思います。
CLIコマンドを作ることができるフレームワーク、CakePHPなどもですが、ログ出力時にWebとCLIで実行したユーザーが異なり、権限がらみのエラーが発生したりしがちです。
そもそもログを調べる時、WebとCLIは別ファイルになってた方が良くないです?
『Laravel リファレンス』発売、電子とキャンプ、そして紙
muraveです。最近はCakePHP(2系)を扱っていてLaravelはすっかりご無沙汰です。
2016/1/8 に株式会社インプレスより発売された『Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク』(以降『Laravelリファレンス』)の見本誌を頂きました。ありがとうございます!
電子書籍のはなし
『Laravelリファレンス』、電子書籍版も同日に発売されました。すばらしい!
見本誌をいただけるというお話はあったのですが辛抱たまらず「田舎で最速で読むには電子書籍だべやばってん荒川」(嘘方言)とKindle版の予約をクリッククリックしておりました。
おかげで発売日の0時から読み始めることができましたが残念な点もかなり。