WEBエンジニアの技術メモと日々

最近awsのcopilotを試しているんですが、たまたまバックエンドにLaravelを使ってみたので、1年半前にLaravelに触れてみようと思ったのを思い出しまた試行錯誤をしてみたいと思い立ちました。 以前に試した時はLaravel8だったんですが、Laravel9になっているんですね。。 Laravelのインストールは同じだったので前回途中だったログイン認証あたりから始めてみようかなと思います。 Laravel９の 認証のページ を参照すると Laravelアプリケーションスターターキット をインストールしてくださいとあります。 そしてデータベースをマイグレーションした後に…とあるのでDBも準備する必要があるのかな？ こちらの件の作業はローカルでdockerコンテナを使うのでphp8/mysql8で環境を準備してみたいと思います。 ※ちなみにどちらも使ったことがありません。。。特に理由はないですがせっかくなんでmysql8は新しい方をって理由くらいです。 Laravelアプリケーションスターターキットのページを見るとどうやら新規Laravelアプリケーションの作成（済）、データベースの設定（未完）、データベースマイグレーション（未完）を実行してください。ってあるのでDBコンテナから準備します。 試しに使ってみるのでDockerfileで手を加えず公式イメージをdocker runします。 M1チップなのでarm64のイメージを使います。 docker run --name {container name} -e MYSQL_ROOT_PASSWORD={root password} -d arm64v8/mysql:8.0 --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci あとはコンテナにログインしてmysqlにログイン CREATE DATABASE laravel; CREATE USER 'laravel'@'%' IDENTIFIED BY 'laravel'; GRANT ALL ON laravel.* TO 'laravel'; データベースとユーザーを作ってみました。 データベ

自分のためのターミナルの設定メモになります 転職や配置換え、またPCを買い換えたりすると意外と設定の変更って面倒なものです しかも、、、 あれ？どうやるんだっけ？？？ なんてもう一度調べ直したり。。。 まぁ現代はネットですぐヒットするのでいいのですが、いざ直面するとそういえばあの設定やってたは！！ なんてことがあったりします と言うことで自分の設定を残そうと思ったわけであります ちなみに私の環境は MacBook Pro 2017 になります bashのTab保管時に、大文字と小文字を区別しない方が早いので（正確なファイルやディレクトリを保管したいならやらない方がいいんですがそもそも大文字小文字が関係なく重複している名前はあまりよろしくないと思っているので。。）設定は嫌いでは無いので設定をしたいです ※会社ではWindowsなんですが、使っているターミナルソフトが何もしなくても大文字・小文字を無視して保管してくれるものがあります Tab保管時に大文字・小文字を区別しないで保管する # vim ~/.inputrc こちらを追記します set completion-ignore-case on 作業のディレクトリはaliasにして簡単移動！ # vim ~/.bash_profile こんな感じで追記をしておきます alias cdProjectName='cd /projectPath' GItもエイリアスを設定しておく [alias]         st = status         b  = branch GITのブランチ名を出しておく ~/.bash_profile source /usr/local/etc/bash_completion.d/git-prompt.sh source /usr/local/etc/bash_completion.d/git-completion.bash GIT_PS1_SHOWDIRTYSTATE=true export PS1='\[\033[32m\]\u@\h\[\033[00m\]:\[\033[34m\]\w\[\0

前回 で、copilot svc deployを実行したときにサービスの起動で失敗してエラーになっていた点を解消しました。 解消したので今回はサイドカーを設定して、ロードバランサーからnginxへ流してphp8-Laravelへ流して、結果レスポンスを表示する（Laravelデフォルト画面）をやっていきたいと思います。 まずサイドカーでnginxを利用してメインコンテナに流すように設定します。 サービスのmanifestに以下を記載しました。 nginxと言うコンテナ名で、８０番で待ち受け、指定イメージ（あらかじめメインコンテナに流すようにconfを配置してコンテナイメージをビルドとコミット・プッシュしたもの）でサイドカーを利用すると言う記載です。variablesは環境変数で今回は利用していないので設定しなくていいのですが今後の私の利用用途で使うことがあるので設定しています。 sidecars:   nginx:     port: 80     image: *********.dkr.ecr.ap-northeast-1.amazonaws.com/my-nginx:latest     variables:       NGINX_PORT: 80 imageではなくDockerfileを使いたいところでもあるのですがawsのドキュメントによると今後アップデートしていく予定はあるみたいですね。 それともう一つサービスのmanifestに設定するのが http.target_container 前回メインのphp8/Larabelの8000番で待ち受けしているコンテナがロードバランサーからのリクエストを受け付けていましたが、このメインのコンテナの代わりにサイドカーで立ち上げたコンテナがロードバランサーからのリクエストを受け付けるようにするための記述になります。 http:   target_container: nginx 私の場合ですとこんな感じで記載してあります。 すでにdeployしていますのでmanifestの変更は copilot svc deploy --name laravel-server --env test でアップデートされます。 デプロイを実行すると以下になります。 アクセスの確認とヘッダー情報にnginxの情報を確認

レイアウト崩れで挫折したところから。。 ※こちらの記事は以前の2021年前半に書いて下書きだったものを公開しています。自分のメモのために公開しました。 はじめになんですが公式サイト見てたら sailコマンド なる記載がありました。 デフォルトのdocker環境を操作するコマンドとあるんで、こっち使おっかななんて考えていますが、通常通りLaravelのプロジェクト作成し他場合のレイアウトの問題も気になるので今回はここを解決しようかと思います。 まずはcss/jsがないことがわかります 前回は気づきませんでしたがこのメッセージが出ているんですね # php artisan ui vue --auth Vue scaffolding installed successfully. Please run "npm install && npm run dev" to compile your fresh scaffolding. Authentication scaffolding generated successfully. npm install && npm run dev を実行してねというので実行 # npm install && npm run dev bash: npm: command not found npmをインストールしていないんですね。。。。 npmをインストールします。 # apt-get install npm すると nodejs/npm がインストールされています。 # npm --version 5.8.0 # node --version v10.24.0 インストールされたところで先程のコマンドを再度実行してみます。 # npm install && npm run dev そうするとエラーがでます。。。 Error: You are using an unsupported version of Node. Please update to at least Node v12.14     at assertSupportedNodeVersion (/var/www/html/laravel/node_modules/laravel-mix/sr

前回 は、Laravel/nginxでcopilotを実行するためにローカルでの動作確認を行い、いざcopilotでサービスのデプロイをまずはphp8/Laravelのサービスだけ単体で行ったのですが、エラーが発生してやめたところでした。 今回はエラーを確認していきたいと思います。 まずcopilot svc deployを実行すると以下のような画面で失敗し続けて、おそらく１０回失敗するとスタックがロールバックしてcleanupされる挙動になるかと思います。 前回にも載せましたがコマンドを実行したターミナルで表示されていたのは以下になります。 １０回失敗した後に以下のエラー出力もありました。 Cloudformationにも同じエラーがでています。 CREATE_FAILED Resource handler returned message: "Error occurred during operation 'ECS Deployment Circuit Breaker was triggered'." (RequestToken: Token, HandlerErrorCode: GeneralServiceException) ROLLBACK_IN_PROGRESS The following resource(s) failed to create: [Service]. Rollback requested by user. ぱっと見何が原因かわからなかったんですが、何回かやっていて、おおよそコンテナが起動できないとか、サービスのmanifestでミスっていることで起きていた感じでした。 今回で言うと原因はちょっと初めからわかっていたのですが、、 私の環境はM1チップのmacbook airなので、Laravelをインストールするphpの公式イメージはarm64v8/phpのイメージを使っていたんですね、しかし実際にcopilotで起動する場合はintelのイメージじゃないとダメだ！って気付きました。 と言うことで FROM amd64/php:latest こちらに変更して再度実行しました。 ※ここですがサービスのmanifestで platform: linux/arm64にすればarm64v8/phpでも

前回 はcopilot-cliのアップデートで少しserviceのデプロイまでが変わっていたので記事にしました。 今回ですが、より実際に使うであろう構造に近いものを試してみます。 WEBサービスの場合におおよそですが、HTTPクライアントが要求を受け取り、バックエンドが処理してHTTPクライアントがレスポンスをするという構成が私の経験してきているところなのでこれを試してみます。 今回はローカルであらかじめコンテナを立ち上げて、さらにコンテナ間通信まで確認したものでcopilotでのデプロイとHTTPでのアクセスを確認するまでを目標とします。 まずはLaravel(composerで特に指定していなくインストールされたもの Laravel Framework 9.21.6)をインストールして、php artisan serveで開発サーバーをポート8000で立ち上げてたコンテナに、nginxのコンテナがユーザーからの要求を８０番ポートで受け取りLaravelのコンテナに8000番に流してLaravelの初期画面を表示されるまでを確認しました。 続いてそれをAWSのcopilotでデプロイできるようにしたいと思います。 サイドカーで実行して８０番ポートでリクエストを受け取り８０００番で起動しているLaravelに流すというものを作成したいと思います。 ちなみにDockerfileはこんなものを用意しました。 php8/laravel FROM arm64v8/php:latest RUN cd /usr/local/src \     && php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" \     && php -r "if (hash_file('sha384', 'composer-setup.php') === '55ce33d7678c5a611085589f1f3ddf8b3c52d662cd01d4ba75c0ee0459970c2200a51f492d557530c71c15d8dba01eae') { echo

4年前に転職して多忙となりGitHubのアカウント放置していたら色々変わっているんですね。 メインブランチがmasterからmainに変わっていたり、メールとパスワード認証でpushしていたのが廃止になっているんですね。。 最近また使ってみようかと思いファイルをコミットしてプッシュしたらエラーが出てプッシュできない。。パーソナルアクセストークンを利用することになっていることに気づいたわけです。 2021年8月13日でパスワードによる認証は終わっているということで、どれだけ使っていなかったの？私は…。 ということでまたpublic/private含めて色々利用していきたいのでリポジトリにプッシュできるようにしたい！ ということで 右上のアイコンから settings→Developer settings→Personal access tokens と進んでいき Generate new token で新しいトークンを発行して % git push origin branch Username for 'https://github.com': myUserName Password for 'https://myUserName@github.com': *************** そしてパスワードのところで発行されたトークンを入力したらプッシュできました。 ついでに、リポジトリの公開設定もアラートのようになっていたので公開と非公開をリポジトリごとに設定。 ※もともと非公開なものはなかったのですが一応古くて恥ずかしいので非公開に。 デフォルトブランチをmasterからmainにリネームして、プルリクエストのマージでブランチを削除するように変更などちょこちょこ設定を変えてみました。 さてまだまだやることはたくさんあるけど、少しは進めていけそうになったかな？

いよいよcopilot で環境を作成へ copilot-cliの実行ユーザーに対するポリシーで四苦八苦していた今までですが、既存のポリシーアタッチで進めることを決意して進めております。 ただしcopilot-cliをアップデートする前と少し変更があったようなので記載します。 私は先にcopilot app initを実行します。 おすすめのアクションとして copilot init がいいと勧められるんですが、どうもminimumの環境がデプロイされてからmanifest.ymlを更新して再デプロイという動作がちょっと苦手でそうしています。 ですので copilot app init copilot env init copilot svc init copilot svc deploy --env test といった手順を踏んでデプロイしていたんです。 これで正常にECSでサービスを開始して利用できたのですが、copilot-cliをアップデートしたらどうも同じ手順ではサービスのデプロイができなくなりました。 落雷で停電したためエラーのコピペはできていないのですが、、 エラーはサービスをテスト環境にデプロイしようとしたら失敗しましたというようなもので、何がないから失敗したといった詳細なエラーはコンソールの出力を見ても、CloudFormationのスタック詳細を見てもわかりませんでした。 そこで一度 copilot app delete で全てを削除して、 copilot init で実行してみると成功！ そこでサービスを開始するために不足時していた実行コマンドに気づきました。 copilot app init copilot env init copilot env deploy --name test copilot svc init copilot svc deploy --env test copilot env deploy が追加されていたんですね。 copilot-cli v1.20.0 にアップデートされて、環境ごとのmanifestが用意されて、環境の変更もcopilot env deleteをしなくても更新が可能になったことから環境のデプロイが用意されたのだと思います。 ネットワーク構成などあらかじめ決まっていたら、

前回 と 前々回 でcopilotの実行awsユーザーの権限が最適なものを模索していて断念ということになったんですが、目的はクリアできませんでしたがわかったことがいくつかあって、今回はそれを記載したいと思います。 copilot実行時のエラーの確認について コンソールから実行時に権限不足とかで % copilot app init Your workspace is registered to application demo. ✘ Failed to create the infrastructure to manage services under application demo. ✘ wait until stack demo-infrastructure-roles create is complete: ResourceNotReady: failed waiting for successful resource state API: iam:GetRole User: arn:aws:iam::**********:user/copilot-user is not authorized to perform: iam:GetRole on resource: role demo-adminrole because no identity-based policy allows the iam:GetRole action こんな感じ出るんで iam:GetRole が必要なんだなと追加していけるんですがコンソールに明確に出ない場合もあり（リソースを削除できなかったというようなだけのエラー）、その場合はCloudFormationよりスタックの詳細で何のイベントで失敗しているのかを調べて、削除に必要な権限などを付与していました。 copilot cli のアップデートでの変更 私がcopilotに触れはじめたのが4月頃なのですが、その当時はcopilot initを実行すると以下ができました。 copilot ディレクトリ copilot/.workspace copilot/demo ディレクトリ（アプリケーション名のディレクトリ） copilot/demo/manifest.yaml という構成だったのですが

今回からタイトルのM1を削除しています。 手元のintelがなくなったので基本M1チップでの作業です。 (ローカルで作成したdockerイメージがもしかすると何かあるかも) さて、今回は copilot env init/delete を実行していき不足の権限をつけてみます。 今回copilotで作成する環境は Load Balanced Web Service になります。 ではまずは前回実行できるようにした copilot app init をしていきます。 ちなみに copilot app init を実行するとcopilotディレクトリが実行環境に作成されますので管理するのに都合のいい場所で実行するのがいいと思います。 copilot app init を実行すると以下のようになります。 userName demo % copilot app init Application name: demo ✔ Created the infrastructure to manage services under application demo. ✔ The directory copilot will hold service manifests for application demo. Recommended follow-up actions: - Run `copilot init` to add a new service to your application. 順調！順調！ applicationができたところで環境の作成をするためにcopilot env initを実行していきます。 そうするとやはり不足した権限が出てきました。 iam:getRolePolicy ecs:DescribeClusters ecs:DeleteCluster ec2:CreateInternetGateway elasticloadbalancing:* servicediscovery:CreatePrivateDnsNamespace servicediscovery:TagResource servicediscovery:DeleteNamespace cloudformation:DescribeStackSet cloudf

前回は、xcode 13が必要ということでインストールしてるところで、intelでも試してみたというところでした。xcode 13をインストールしてcopilot cliを利用できるようになりました。 おそらくここからはM1チップ固有はないと思いますので、copilotの試した内容で記載してきます。 前回と前々回は以下です。 aws copilotをM1で使う① aws copilotをM1で使う② intelでもやってみた では続きを進めていきます。 まずは、copilot cli実行して環境を作成するためのユーザーをIAMで作成しました。 AWSのドキュメントを見るとカスタムポリシーを作成するときは最小から始めて、必要なものを付与していくってあったので、一回すでにある既存のポリシーをアタッチして実行していたのですが、何もないところから必要なものだけだったらどうなるのか気になり、実行と付与を繰り返し最終的には、copilot app init を実行し copilot app deleteを実行できるところまで出来ました。 結果はこちらになります。 {     "Version": "2012-10-17",     "Statement": [         {             "Sid": "Copilot init1",             "Effect": "Allow",             "Action": [                 "iam:GetRole",                 "iam:CreateRole",                 "iam:DeleteRole",                 "iam:PutRolePolicy",                 "iam:DeleteRolePolicy",                 "iam:PassRole",                 &q

M1 MacBook Air にてkarabiner Elementsを使い日本語入力を楽にしたいと思います。 一番わかりやすく説明してくれていたサイトは こちら 。 こちらを参考にして私もこちらの Karabiner-Elements のサイトからダウンロード ダウンロードしたファイルをダブルクリックしてインストールします。 アプリケーションに追加されたKarabiner-Elementsを起動します。 セキュリティーで入力監視を許可しなくてはならないので許可します。 ※karabiner_grabber/karabiner_observer にチェックを入れて許可します。 次にKarabiner-Elements Preferences を開き、 Complex Modifications の add rule を選択します。 import more rules from the internet(open a web browser) を選択するとブラウザーが開きます。 International (Language Specific) を選択すると For Japanese（日本語環境向けの設定） (rev6) 　というのがあるのでimportします。（rev6とかは現時点ではということになるかと思います。） コマンドキーを単体で押したときに、英数・かなキーを送信する。（左コマンドキーは英数、右コマンドキーはかな） (rev 3) これがやりたい設定ですね。インポートするとKarabiner Elementsに戻りますので、先ほどの設定をEnableで有効にすると。 こんな感じで設定が増えますので、左commandと右commandを押してみてください。 それぞれで入力ソースが割り当てられていると思います。 以前に外付けキーボードでやったことあったんですけどね。 忘れちゃいまして、参考サイトを見ながら設定してまた忘れた時用にメモとして自分の記事も残させていただきました！