学習履歴一覧

551件中の 201-225件 を表示

[Docker][Laravel]新しいdocker環境での動作確認。Googleログインができないのを修正。更新時に日付が保持されていないバグを修正しようとするもうまくいかない……

今日のYWT やったこと Travelog 新しいDocker環境で動作確認 Googleログインが出来ないので出来るようにする 更新時に日付を保持しないエラー発見…… エラーを発見したので修正したい form.blade.phpで、日付を洗濯するとこで持ってくるデータをformatで形式合わせしてあげる これでedit時は解決したものの、これをするとcreate時に$articleがundefinedと出てしまう…… createアクション時に$article = new Article();としてviewに渡すもダメ 演算子変えて $article ? $article->start_date->format('Y-m-d') : old('start_date')と書くも、$articleがnullじゃformatは使えないと言われる…… わかったこと Googleログイン Googleログイン時、どこのURLにリダイレクトして戻ってくるかを環境変数で指定してるっぽく、.envのAPP_URLを参照するのでここの書き換えが必要だった。 Q. GDのインストールの際、コンテナに入ってインストールしてもボリューム消えたら何も残らないとのことでしたが、 docker-compose exec app composer require laravel/socialiteと打って socialiteをインストールするのもコマンドではなくDockerfileに記述したほうが上と同じで破棄したときに消えてしまわないから良い、という感じでしょうか? A. それはコンテナで実行するがローカルのディレクトリと同期されている場所にインストールされるから、コンテナから消えてもまた立ち上げた時にローカルから同期されるので問題ない Q.つまり、docker-compose.ymlの app: build: context: . dockerfile: ./docker/php-fpm/Dockerfile # ソケットで通信してるからポートは書かない volumes: - ./:/work - php-socket:/var/run/php-fpm app部分の volumes の記述により、コンテナの /work以下と、ローカルの docker-compose.ymlの入ったディレクトリ = travelog(laravelアプリのディレクトリ) が同期され、どちらにもインストールされる。 コンテナの socialite が消えたとしても、立ち上げるときにローカルにあることを参照して同期するので問題ない、という解釈ですが合ってますか? →合ってる!! 次やること 日付の不具合解決

Docker
Laravel

2020年12月18日(金)

1.9時間

[Docker][Laravel]postgresのコンテナ立ち上げ成功、migrateできた。GD Libraryを入れるのに苦戦するもなんとか入れて画像投稿も出来るようになった

今日のYWT やったこと Travelog Dockerでpostgres使えるように postgresqlを使うためのドライバを入れた DockerにGD Libraryをインストールして画像を圧縮できるように 画像投稿時にGD libraryがないよというエラーが出たので入れたい Dockerfileに記述してインストール わかったこと postgresのインストールとマイグレーション libpq-dev, libzip-devを追記し、docker-php-ext-install pdo_pgsql zipで pdo_pgsqlのインストールをする。 で、buildしてup -dし、 docker-compose exec app bashでコンテナに入り、 php artisan migrateで無事成功! GD Libraryの入れ方 画像の圧縮にIntervention Imageを使っているが、これにGD libraryが必要。 元のDockerfile FROM php:7.3-fpm-buster SHELL ["/bin/bash", "-oeux", "pipefail", "-c"] # timezone environment ENV TZ=UTC \ # locale LANG=en_US.UTF-8 \ LANGUAGE=en_US:en \ LC_ALL=en_US.UTF-8 \ # composer environment COMPOSER_ALLOW_SUPERUSER=1 \ COMPOSER_HOME=/composer COPY --from=composer:2.0 /usr/bin/composer /usr/bin/composer # multi state build 容量を削減するための小技 RUN apt-get update && \ apt-get -y install git libicu-dev libonig-dev libzip-dev libpq-dev unzip locales && \ apt-get clean && \ rm -rf /var/lib/apt/lists/* && \ locale-gen en_US.UTF-8 && \ localedef -f UTF-8 -i en_US en_US.UTF-8 && \ mkdir /var/run/php-fpm && \ docker-php-ext-install intl pdo_mysql zip bcmath && \ docker-php-ext-install pdo_pgsql zip && \ composer config -g process-timeout 3600 && \ composer config -g repos.packagist composer https://packagist.org COPY ./docker/php-fpm/zzz-www.conf /usr/local/etc/php-fpm.d/zzz-www.conf COPY ./docker/php-fpm/php.ini /usr/local/etc/php/php.ini WORKDIR /work この状態で画像をアップロードしようとすると Intervention\Image\Exception\NotSupportedException GD Library extension not available with this PHP installation. と、EC2へデプロイした本番環境でも見たことあるエラー。これはGD Libraryがないのね、とsudoコマンドで入れようとするも…… sudo apt-get install php7.0-gd bash: sudo: command not found 今度はsudoコマンドが無いと言われてしまう。 また、これはコンテナにインストールするだけで、ボリュームが消えたら何も残らないとメンターさんからの指摘。確かに……。 Dockerfileに書こう というわけで、ビルドするときにインストールする。 FROM php:7.3-fpm-buster SHELL ["/bin/bash", "-oeux", "pipefail", "-c"] # timezone environment ENV TZ=UTC \ # locale LANG=en_US.UTF-8 \ LANGUAGE=en_US:en \ LC_ALL=en_US.UTF-8 \ # composer environment COMPOSER_ALLOW_SUPERUSER=1 \ COMPOSER_HOME=/composer COPY --from=composer:2.0 /usr/bin/composer /usr/bin/composer RUN apt-get update && \ apt-get -y install git libicu-dev libonig-dev libzip-dev libpq-dev libjpeg-dev libpng-dev unzip locales && \ apt-get clean && \ rm -rf /var/lib/apt/lists/* && \ locale-gen en_US.UTF-8 && \ localedef -f UTF-8 -i en_US en_US.UTF-8 && \ mkdir /var/run/php-fpm && \ docker-php-ext-install intl pdo_mysql zip bcmath gd && \ docker-php-ext-install pdo_pgsql zip && \ docker-php-ext-configure \ gd --with-png-dir=/usr/include --with-jpeg-dir=/usr/include && \ composer config -g process-timeout 3600 && \ composer config -g repos.packagist composer https://packagist.org COPY ./docker/php-fpm/zzz-www.conf /usr/local/etc/php-fpm.d/zzz-www.conf COPY ./docker/php-fpm/php.ini /usr/local/etc/php/php.ini WORKDIR /work docker-php-ext-install intl pdo_mysql zip bcmathにgdを追記。 docker-php-ext-configure \ gd --with-png-dir=/usr/include --with-jpeg-dir=/usr/include && \ この2行も追記して解決。 次やること 動作確認 docker-php-ext-configureって何?を調べる

Docker
PostgreSQL
Laravel

2020年12月17日(木)

2.7時間

[Docker]メンターさんに教えてもらいながら自力でdocker-compose.ymlを書く練習。 [その他]TechCommitアドベントカレンダー用の記事を書く

今日のYWT やったこと 執筆 Techpitのアドベントカレンダー用に、今年の学習振り返り記事を書いた YWT Questのアプリ自体や設計を見返した docker-compose.ymlを自力で書いていく メンターさんとzoomつなぎながら、dockerについて教えてもらいつつ、docker-compose.ymlを書いてlaradockからの脱却を図る docker-compose.ymlを書く DockerHubで欲しいバージョンのDockerfileを探す Dockerfileをカスタマイズする そのDockerfileを読み込む設定をdocker-compose.ymlに書く docker-compose buildする docker-compose up -dする 勝利 わかったこと Docker雑記 build=イメージファイルを作る イメージファイル=コンテナの元になる、核になるものzipみたいな dockerファイルに書いてあるものを固めて一つのアイテムにしてしまう up=イメージを使ってコンテナを立ち上げる dockerfile = イメージのレシピ docker-compose.yml = イメージからコンテナの立ち上げのレシピ docker-compose up -d イメージがないときは、 docker-compose buildが走ってから docker-compose upが走る。 docker-compose.ymlっているの? コンテナを分けるのがそもそも美味しい 分けたコンテナたちを一つのサーバーとして扱いたい コンテナ=middlewareをコンテナ化して、付け替え可能=パズルみたいにしてる、ピースを組み合わせて一台のサーバーみたいにしたい 各コンテナ=ネットワーク的にはバラバラ、それぞれ別のIPが振られる それぞれを一つのネットワーク領域に置きたい →それをdockerfileでも書けるけど、超絶面倒くさい これを束ねるために登場したのがdocker-compose 1.18.0-perl ←perlが元になっている 1.18.0-alpine ←alpineが元になってます alpine = alpine linuxの略 - vimさえ入ってない最小構成 - dokcer imageを軽くしたい - なんでかっていうと、imageをロードしてコンテナを作る。そこの転送量に関わってくる - もっというと、今回はEC2でやってるけど、ECSっていうコンテナをそのままロードできるようなサービスを使ってできる cloud版 docker-composeがECS(Elastic Container Service) コンテナ=使い捨て - バグったら殺す - またイメージロードすればちゃんと立ち上がるはず - 結局、イメージの大きさをどれだけ小さくするかで戦う - だからなるべく小さく、余計なものを入れないように - その中でもalpineは本当になんにも入ってませんっていう状態のやつ alpineとbusterで数百倍サイズが違う docker-compose up -dしたけど、ローカルからは見れない状態 ports: - 8080:80 8080=被らなければなんでもよし EXPOSE 80 80を公開してる WORKDIR /work 最初のログインした場所がどこかを指定 SHELL ["/bin/ash", "-oeux", "pipefail", "-c"] デフォルトでつくshellのbashを指定している Linuxコマンドのオプション、デフォルトでつけるやつ dockerは行毎に差分管理 流し直して変わって無ければキャッシュしてくれている Step 1/5 : FROM nginx:1.18-alpine ---> ea1819c829a5 Step 2/5 : SHELL ["/bin/ash", "-oeux", "pipefail", "-c"] ---> Using cache ---> c5fb37b9d3e0 Step 3/5 : RUN apk update ---> Using cache ---> 0f1434228265 Step 4/5 : COPY ./docker/nginx/default.conf /etc/nginx/conf.d/default.conf ---> 2efefefae6c7 Step 5/5 : WORKDIR /work ---> Running in bc87086efbea Removing intermediate container bc87086efbea ---> efc7ecf5929c キャッシュしたいなら左側のコマンドはなるべく少なくして、 &&で書く phpのdockerfile タイムゾーンの設定が重要になる alpineだとそのへんの設定が大変 次やること dockerでdb入れる 執筆の続き

Docker

2020年12月14日(月)

4.3時間

[Laravel]phpのupload_max_filesizeを超えるような画像をアップロードしようとする時、意図しないバリデーションメッセージが出るのを修正

今日のYWT やったこと Travelog バリデーションメッセージの編集 laravel.iniのupload_max_filesizeを超えるような画像がアップロードされた時、意図したバリデーションメッセージが出なかったのでそれをどうにかしていた // バリデーションルールを設定 public function rules() { return [ // 略 'files.*.photo' => 'bail|image|mimes:jpeg,bmp,png|max:2000', ]; } public function attributes() { return [ // 略 'files.*.photo' => 'ファイル', ]; } public function messages() { return [ // attribute名 . 引っかかったバリデーションルール => 出したいメッセージ 'end_date.after_or_equal' => '開始日または終了日を確認してください', 'files.*.photo.max' => 'ファイルサイズが大きすぎます(2MBまで)', ]; } これで、5MBのpngファイルをアップロードした時、files.*.photosがサイズ制限のmax:2000に引っかかったら、「ファイルサイズが大きすぎます」というメッセージが出ると期待したが、実際は「ファイルのアップロードに失敗しました」と出てしまう。 このmax:2000をmax:200に変更し、600Kのpngファイルをアップロードしようとすると、意図したバリデーションメッセージである「ファイルサイズが大きすぎます」と表示される。 また、形式のエラーを発生させようと別にgifファイル(サイズ制限はクリア)をアップロードすると、ちゃんと「ファイルにはjpeg, bmp, pngタイプのファイルを指定してください」と表示される。 メンターさんから、upload_max_filesizeを大きめに設定して、バリデーションに到達するように調整するとどうか?とあったのでそのように設定 また、フォームに形式とファイルサイズの注意書きを追加する わかったこと バリデーション uploadedというバリデーションルールに引っかかってたようなので、このメッセージを編集することで変えられたようだ ec2でのphp.ini(php設定ファイル)の場所 ec2にログインし、 cd /etc cat php.ini ここにある 次やること dockerと向き合う

Docker
Laravel
AWS

2020年12月09日(水)

2.2時間

[Laravel]LPの編集、いらないコメントの削除。deploy済みの変更が本番環境に反映されていないと気づく。CodeDeployが失敗していることを確認。

今日のYWT やったこと Travelog faviconの色をテーマカラー基準に LPのTOPに文章追加 LPのタイトルにicon追加 不要なコメント削除 なぜか上の変更が本番環境に適用されていない→CodeDeployでエラーが出ていることが判明! わかったこと このPRからCodeDeployでエラーを吐いていて、うまくデプロイできていなかったよう。 この時のCodeDeployのエラーはAfterInstallを失敗していて、エラーコードはScriptFailed メッセージ Script at specified location: ./scripts/after_install.sh run as user webapp failed with error Errno::ENOMEM with message Cannot allocate memory - su ログ LifecycleEvent - AfterInstall Script - ./scripts/after_install.sh で、CodeDeployがうまくいっていないと気づいた今回のdeployでは、DownloadBundleのところで失敗しており、エラーコードは UnknownError エラーコードをクリックすると Cannot allocate memory - rm -rf /opt/codedeploy-agent/deployment-root/78ef54be-75c0-4f15-8e8c-39b40a08e555/d-X3B430GK7 2>&1と表示されてる。メモリが足らない? 最初にCodeDeployが走らなくなったdeployを、デプロイの再試行ボタンで再デプロイしようとしたが、 The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems. というエラー文が出て結局失敗のまま。 上の翻訳結果 展開に失敗した個々のインスタンスが多すぎる、展開に使用できる正常なインスタンスが少なすぎる、または展開グループ内の一部のインスタンスで問題が発生しているため、全体的な展開が失敗しました。 これはEC2関連でなにか不具合が起きている(メモリが足らない?) 次やること CodeDeployのエラーをなんとかして解決する😭

Docker
Laravel
AWS

2020年12月07日(月)

1.2時間

[Laravel]メンターさんとMTGしながらDockerのエラー解決。カスタムエラーページが表示されないバグ修正。ArticleRepositoryのメソッドのユニットテストを書く。

今日のYWT やったこと Travelog Dockerのエラーの解決 docker-compose upや docker-compose buildのときは、使うコンテナを指定する phpの設定 本番環境でのPostTooLargeExceptionエラーをローカルで再現するため、post_max_sizeやmax_file_uploadsの値を書き換えて本番と同じ数値にした 独自エラーページを表示する 作った独自エラーページが本番環境で表示できなかったのを直す nginxのnginx.confを書き換えて解決 UnitTestを書く ArticleRepositoryのgetAllArticleをテストするUnittestを書いた そのタイミングで、getAllArticleでcreated_atの降順にArticle全件取得するコードについて見直した また、getAllArticleで全件取得しようとするも、1件も無い時のテストも書いた わかったこと Laradockでのphpの設定をどこから見るか 今までは、docker-compose exec workspace bashでコンテナに入ったつもりになっていたが、ローカル環境で使われている設定を見るにはdocker-compose exec php-fpm bashで入る必要がある また、laradockのphp-fpmディレクトリ内にあるlaravel.iniを書き換えたら、docker-compose downしてdocker-compose build php-fpmしないと、書き直したところが反映されない。 そのあとに、起動したいコンテナを指定する形でdocker-compose up -d workspace php-fpm postgres nginxでコンテナ再起動をかける phpの設定を見る phpinfo();を適当なコントローラ(ログインが必要じゃないindexとか)に書くだけ 本番環境で独自エラーページが表示できなかった理由 nginxが、laravelに処理行く前にnginx側の処理で404ページを表示させていた→laravelの処理が走らないのでカスタマイズエラーページも表示されない これは、該当するコードをすべてコメントアウトすることで解決 # error_page 404 /404.html; # # error_page 500 502 503 504 /50x.html; UnitTest 今まで書いていたのはfeatureTestだったが、ユニットテスト(クラスやメソッド単位のテスト)を書く 対象はRepositoryに切り出したメソッド等 assertEqualは型まで見る。 assertSameは型は見ない Collectionにも種類がある Illuminate\Database\Eloquent\CollectionがEloquentのCollection Illuminate\Support\Collectionは上の継承元のCollection テストで検証するとき、この二つの型は違うものとみなされるので、toArray()などとして変換をして型を揃えてあげる必要がある getAllArticleのリファクタリング // $articles = Article::all() // ->sortByDesc('created_at') // ->load(['user', 'likes', 'tags', 'photos']); $articles = Article::query() ->with(['user', 'likes', 'tags', 'photos']) ->orderBy('created_at', 'desc') ->get(); 上のコメントアウトしたコードではCollectionに対する操作で、sortByDescやloadなども結局foreachで回しているので処理が遅い。 下のコードはDBでの処理。クエリを発行しているので処理が早い。 次やること CircleCIにかけてどうなるか見る……

Docker
Laravel

2020年12月01日(火)

4.6時間

551件中の 201-225件 を表示