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

前回のxcode12が古いとhomebrew経由でcopilotがインストールできなかった件 前回は こちら 本日の実行メモ 前回のxcode12が古いとhomebrew経由でcopilotがインストールできなかったですが、本日別のPC(macbook pro/intel)でインストール作業をしたら普通にできました。 違いM1かintelかのプロセッサーの違いかなと思っています。 なので今日はintelで作業しています。 先日はcopilot init でtest環境作成がエラーでできなかったんですが、一旦cliユーザーにアクセス権を結構持たせたらできたのでここから絞り込んでミニマム見つけていこうと思います。 ssm:PutParameter action cloudformation:DescribeStacks action ここら辺が必要だと表示されていたので関連するアクセス権をフルで追加して再びcopilot initを実行すると最後まで完了し、表示された。 https://aws.amazon.com/jp/blogs/news/introducing-aws-copilot/  ここに記載しているとおりに、nginxのDockerfileを配置して、index.htmlを置いたんですが、 index.htmlは表示されず、nginxのデフォルトが表示されていました。 おそらくDockerfileはdockerのフォルダに配置して、index.htmlはその上の階層にしてしまったのでかな。 前進したので、M1含めて色々試していきたいと思います。

業務で使うことになったaws copilot 一旦自分のmacbook air(M1)で試してみることに。 まずcopilot-cliをインストールする。 AWSのドキュメント https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/AWS_Copilot.html こちらに書いてある通りで https://github.com/aws/copilot-cli 私はbrewでインストールしようとしたんですがそもそもbrewがインストールされていない。 ということでこちらからコマンドをコピペして実行します。 https://brew.sh/index_ja 実行が終わって brew を実行するがコマンドがないと言われてしまいます。 インストール時のメッセージを辿っていくと警告が出ています。 /opt/homebrew/bin　にパスが通っていないということです。 echo $SHELL  でシェルの種類を確認すると zsh とのことなのでホームディレクトリに.zshrc を作成します。 typeset -U path PATH path=(      /opt/homebrew/bin(N-/)      /opt/homebrew/sbin(N-/)      /usr/bin      /usr/sbin      /bin      /sbin      /usr/local/bin(N-/)      /usr/local/sbin(N-/)      /Library/Apple/usr/bin ) 優先して通す順で記載するようです。 /opt/homebrew/bin だけ＄PATHに追記するような記載で.zshrcに記載したんですが、rmも使えなくなり焦りました。 これでbrewでインストールできるようになりました。 brew install aws/tap/copilo...

何をしていいかわからないまま。。 結局業務で使うことがないと、何しようか発想が出てこない私。。 とりあえずログイン認証かなと思い今回はそれを作ってみようかな。 前回 でdockerを利用してアクセスまではできているので こんな感じで。。 ここからログイン認証機能を作っていきたいな。そんなとこしか思い浮かばないんですもの。。 ※ちなみに前提としては、書籍ではなくネットサーフィン的エンジニアな私です。書籍買うか公式みろよって話ですが。。 まぁ何はともあれやっていきましょう！ でも作るっていうより、こう言ったフレームワークは強力なプラグインだったりですぐできるんでしょ？そうなんでしょ？ ということで はじめは以下のコマンドで実行しましたがエラー php artisan make:auth 参考にしていたのがLaravel5系でしたので利用できませんでした。 ※調べるバージョン合わせろよオレ。。。 Laravel８を利用いして構築しましたので再度検索をしました。 composer require laravel/ui php artisan ui vue --auth これだけでログインと新規登録のリンクが出てきてページが表示される こんな感じ 楽ですね。 がしかしですよ。 レイアウトが崩れているんです。。 こんな感じ どうやらJS・CSSがないみたいです。 DBもmigrationしてユーザー登録できるようにしなきゃならんみたいだしまた次回に調べてやるかな。 今日はここまで！

私、初Laravel ということで最近なんだか転職のことを考えたりして、忙しさにかまけて業務に使うもの以外触れてないな。。 最近は仕事でこれしか触れていない。。 cakePHP3/php7/mysql5.7/apache2.4 Go言語忘れた,,, python忘れた... ruby忘れた... 私の市場価値定価がやばい。。。 ということで、PHPであればlaravelでしょ？そうなんでしょ？ と思ってまずは最近主に使っているPHP関連で触ってみました。 さてどうしよっかなー 動かすだけならapacheでいいやと思ってdocker hubからhttpdの公式イメージで作るかと思いはじめてみる。 Laravelのプロジェクトはローカルに作るかな。 なのでcomposerをローカルにインストールしてLaravelのプロジェクトの作成は以下でできるよう composer create-project laravel/laravel laravel ※ちなみにインストールされたLaravelは php artisan --version Laravel Framework 8.26.1 で、laravelの配下にもろもろできるので、dockerコンテナの/var/www/htmlにマウントしよってやってみました。 結論から言うとめんどくさい。 こんな感じで、ディレクトリ構造みれたり、.phpをテキストファイルとして認識していたりね。まぁapacheの設定いじったり、モジュール読み込んだり、拡張子設定したりやればいいんですがそもそもLaravelを使いたいんですよ私は！ 後からphpをインストールした場合、phpのモジュールとか読み込むんですがapacheのコンテナの方が/usr/local/apache2でphpのモジュールなんかは/etc/apache2/の中に配置されるので、設定いじってなんかやらないと行けなかったので面倒くさいし、時間もったいないのでイメージを変えました。 phpの公式イメージより php:8-apache このイメージでよくない？ ってことでこれでやったのですが、表示したんですがなんかwelcomページじゃないし。。 よくよくみるとapache入れなくてもLaravelサーバーとやらを起動しているので同じやり方にしよって思い 今度はphpのみのイメー...

初めてtmuxを使ってみた最低限の利用 以前から使いたかったtmux 最近はリリースなどは自動化（シニアエンジニアの私はSCPアップロードから知っている。。）だったり、コンテナ化やログディレクトリのマウントや同期など直接ログインしなくてもいい環境だったりするが、私の作業環境ではログインすることが多々あります。 そんな中でそこそこ台数があるサービスなんかで、confファイルを編集なんてたまーにあったりしますが、同じ作業をすることになるので同時にコマンドを打ちたかったりします。SSHクライアントでもできるものがあるようですが、OSに依存せず利用したいのでtmuxを利用することにしました。 インストール $ brew install tmux tmuxを起動 $ tmux prefixはデフォルトの　ctrl + b ペイン分割（左右） prefix % ペイン分割（上下） prefix " ペインの移動 prefix o ペインの破棄 prefix x そして一番やりたかった、ウィンドウで開いているペインに対してコマンドの同時実行 開始 prefix :set-window-option synchronize-panes on 終了 prefix :set-window-option synchronize-panes off ウィンドウの終了 prefix &

AWS　EFSのインスタンス起動時に自動マウント 前回の続きです。 前回はs3fsを利用していたら勝手にマウントが解除され、イメージが表示されなくなっていたというトラブルを受けて、EFSに切り替えるところまでやりました。 前回 AWS　EFSに切り替える しかしこれだと何かのトラブルでインスタンスを再起動した場合に、作業者以外ができない、コマンドを知らないなどで2次災害が起こらないとも言えません。 ですので、基本的にインスタンスをコピーをしたりしてもマウントされているように自動でマウントをするようにしたいわけです。 そもそもですが、ディレクトリをNFSへマウントしなくてもいいじゃん？ って思うかもしれません。 なぜやるか？というところでいうと 複数台あるサーバーで同じものを参照させたいからというところが大きい理由です。 手法としていはいろいろあって 共有できるサーバーを用意して全てのアプリケーションサーバーはそこに保存・参照 s3に保存し、SDKなどを使いプログラムから参照 s3に保存して、パブリックURLで参照 どっかのサーバに保存する際、全てのサーバに配信 などなど。 ちなみに全てやったことあります。4は現在の世の中ではありえない気がしていますが。。。 化石の知識😅 よくイメージサーバー作ってなんてことしてたっけ昔。。 そんなサーバーの構築しないで、マウントすればプログラムで意識しなくても保存や、同じファイル参照できるよってのがディレクトリをマウントするメリットかなって思います。 ということで話は長くなりましたが、インスタンス起動時に自動でマウントするやり方はとっても簡単でした。 sudo vim /etc/fstab 追記>> fs-*******:/nfs_dir /mount_dir efs defaults,_netdev 0 0 これを記載すればインスタンスを再起動してもマウントされています。 同じ環境でオートスケールするなんて時も記載しておかないと、マウントされていないと思うので、これで負荷がかかった時の準備もできたかな。 次回はEFSのオプションについてメモっときます。

s3fsからEFSに切り替えを行いました 先日、s3fsが意図せずにマウントが外れており、短期的にマウントが外れていないかチェックをして、外れている場合は再度マウントする定期実行処理を作りました。 AWSのS3バケットをマウントするs3fsでマウントが外れた件 というところで、長期的な対応はどうするかなと思って調べていたら、『無理してs3fsとか使わなくてもEFSってAWSのサービスがあるからそっち使えば？』みたいな記事を発見しました。 なんと。。。 ということでこれが使えるか調査。 普通にマウントできますね。 しかも同じVPCからのアクセスに絞れたりするので安心な面も デメリットとしては、s3より料金が高いことのようです。 2020/02/07時点　アジアパシフィック東京 標準ストレージクラス　　　0.36USD/GB　月額 低頻度アクセスストレージ　0.072USD/GB 月額 低頻度アクセスリクエスト  0.012USD 転送GB プロビジョニングスループット 7.2USD　MB/秒 月額 アクセス数と容量を加味した料金比較（ミニマム版） S3は 最初の50TB 0.025USD/GB　月額 ファイル転送を考慮せずあくまでアクセスに絞るとGETのみとし GET・SELECT、他の全てのリクエスト 1000リクエストあたり　0.00037USD インターネット転送が 9.999TB以内程度と想定して　0.114USD/GB　月額 が計算するに、ストレージ料金は確かにS3の方が格段に安いですが、リクエスト数と転送量を加味するとEFSの方が安いのでは？っと思ってしまいました。 多分、参考にしたサイトがストレージ料金でしたみていなかったのかもしれませんし、私の扱っているシステムが要領の観点で少ないからだと思います。 それぞれの用途により金額は変わるのでシミュレーションをしてどちらをどのように使うかを決めればいいと思います。 EFSを作成していきます。 新規作成 まずはEFSのメニューから【ファイルシステムの作成】を選択します。 ネットワークアクセスを設定 次にネットワークアクセスを設定します。特に新規でお試しなどであ...