Laravel+Nginx+PostgreSQLのDocker環境を作成する-コンテナ立ち上げまで-
こんにちは。たいきゅんです。
転職して最初の案件が新規案件で、当たり前のようにDockerを使うことになりました。
そこで改めてDockerの基礎について学習したのでまとめてみます。
最低限の設定で動くようにしてみています。
内容は初心者レベルですので、ポートフォリオ作成でDockerを使いたいという方は参考にして頂けると幸いです。
設定を細かく書く形ですので、基礎理解を深めたい方向けになっております。
また今回はコンテナの立ち上げまでをまとめております。次回の記事で以後の設定も記載します。
1. 今回作成する環境の要件
今回はLaravel環境を作成してみました。作成するコンテナは以下の3つです。
- Laravelコンテナ(PHP fpm)
- nginxコンテナ(プロキシ)
- PostgreSQLコンテナ
(PHP-fpmについては別途記事を作成してますのでそちらを参考に)
バージョンは基本的に記事作成時(2022年8月時点)の最新版で作成してます。
Nginx 1.23.1
Laravel Framework 9.25.1
PostgreSQL 14.4
2. フォルダ構造と実際に作成したDockerfile・docker-compose.yml
フォルダ構成は今回下記の形を使ってみました。
docker-compose.ymlを修正してお好みの形に編集して頂ければと思います。
.tree
.
├── docker
│ ├── laravel
│ │ ├── Dockerfile
│ │ └── settings
│ │ └── php.ini
│ ├── nginx
│ ├── Dockerfile
│ └── settings
│ └── default.conf
├── docker-compose.yml
docker/laravel/Dockerfile
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
WORKDIR /var/www/app
docker/nginx/Dockerfile
FROM nginx:1.23.1-alpine
COPY ./settings/default.conf /etc/nginx/conf.d/default.conf
docker-compose.yml
version: '3.8'
services:
app:
build: ./docker/laravel
volumes:
- ./laravel:/var/www/app
- 9000:9000
nginx:
build: ./docker/nginx
- 80:80
volumes:
- ./laravel:/var/www/app
db:
image: postgres:latest
environment:
TZ: Asia/Tokyo
POSTGRES_DB: test
POSTGRES_USER: admin
POSTGRES_PASSWORD: password
- 5432:5432
volumes:
postgres_data:
driver: local
3. それぞれの設定項目の説明
それぞれのファイルの設定項目をまとめます。
1. docker/laravel/Dockerfile
php-fpmの8.0をイメージに設定しています。
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
composerインストールの部分です。
composerの設定箇所は決まっているので、上記で問題ないはずです。
php.iniファイルをdocker環境にセットしています。
必要な機能を諸々apt-get installしています。
今回は、laravelで必要になるnode、postgresqlとの接続に必要なlibpq-dev pdo_pg 、composer実行時に必要なzip,unzip,gitを選択しています。
xdebugのインストールと実行できるように設定
WORKDIR /var/www/app
今回は/var/www/appにlaravelをダウンロードしたいため、WORKDIRを設定しました。
これがあると、laravelコンテナに入った際の最初の作業位置が/var/www/appになります
2. docker/nginx/Dockerfile
FROM nginx:1.23.1-alpine
作成当時の最新バージョンを設定。
COPY ./settings/default.conf /etc/nginx/conf.d/default.conf
動かすことだけ考えると、default.confの設定のみで十分なので/settings/default.confファイルをCOPYする形にしました。
3. docker-compose.yml
Laravelコンテナ
buildセクションで、buildに使用するDockerfileを指定しています。
またvolumeセクションで、laravelフォルダと、コンテナ内の/var/www/appがvolumeするように設定しています。
nginxコンテナ
buildセクションで、buildに使用するDockerfileを指定しています。
プロキシ設定するため、volumeセクションでlaravelコンテナと同様の設定をしています。
portsはなlaravelコンテナ同様、明示したかったためnginxデフォルトの80番を設定してます。
dbコンテナ
db:
image: postgres:latest
environment:
TZ: Asia/Tokyo
POSTGRES_DB: test
POSTGRES_USER: admin
POSTGRES_PASSWORD: password
- 5432:5432
volumes:
postgres_data:
driver: local
imageセクションで、PostgreSQLの最新版をimageに設定しています。
TZは時間設定のための設定です。
POSTGRS_DBはデータベース作成時に自動で作成されるdb名を設定しています。今回はtestというデータベースを作成する形にしてみました。
POSTGRS_USERは、データベース作成時に自動で作成されるユーザー名を設定しています。今回はadminユーザーを作成する形にしてみました。
POSTGRS_PASSPORDデータベース作成時に自動で作成されるユーザーのパスワードの設定しています。今回はpasspordというパスワードを設定してみました。
volumesで、データの永続化の設定をしています。
この記述がないと、DBに登録したデータがコンテナを停止させると同時に消えてしまいますので注意してください。
4. nginx.confの設定
今回はnginxをプロキシサーバーとして使用したいため、その設定が必要です。そのためにはnginxコンテナに設定を書かないといけないのですが、それを今回はnginx.confファイルに記載しました。こちらを紹介します
docker/nginx/settings/default.conf
それぞれ説明していきます
listen 80;
root /var/www/app/public;
index index.php;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
listen: 80番ポートをlistenさせます。
root: ルートフォルダを設定します。laravelの場合は、publicがルートフォルダになるので、コンテナ内でのパス(/var/www/app/public)を設定しました。
index: 最初に読み込むファイルを設定します。laravelの場合は、public/index.phpを最初に読み込む必要があるので、そちらを設定します。
location: ファイルの振り分けの設定をしています。urlの設定があれば、そのURLにプロキシし、なければindex.php?$query_string....という形でプロキシするという設定にしています。
php-fpmの設定が必要なので、頭文字にfstcgiとついています。
pass: phpコンテナのパスを設定します。ここは、コンテナ名:ポート名と設定します。
param: サーバーに渡すパラメーターを設定します。詳細は省略しますが、上記設定でパラメータを渡すことができました。
include: パラメーターをincludeできるように設定しています
参考
4. docker-compose コマンドで立ち上げ
設定が完了したら、docker-composeコマンドでコンテナを立ち上げられるはずです。
長くなったのでDB設定や、laravelのダウンロードは次回以降記載します。
今回の記事は以上となります。
LaravelのインストールとDB接続は次の記事に記載しておりますので是非参考にしてください。
最後まで読んで頂きありがとうございました！！
達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへ
こんにちは。たいきゅんです。
今回は私がエンジニアになって初めて本気で読んだ技術書についてまとめていこうと思います。
是非最後までお付き合いください。
今回読んだ技術書はこちらになります。
今回は以下の4点でまとめていきます。
1.なぜこの本を読みたいと思ったのか?
2.特に勉強になったこと
3.本書をお奨めしたい人
4.まとめ
1.なぜこの本を読みたいと思ったのか?
3点あります。
1点目は、DB周りの知識はあるに越したことないし、普通のエンジニアのDB知識や経験が私にはないなと強く実感しました。これは転職活動の経験で学んだことです。こちらを補うために学習したいと考えていました。
2点目は、突き抜けたエンジニアに将来なるために、DBの知識は必要不可欠と考えたからです。簡単なSQLの知識というものは、その場で分からないものをググっていけばなんとなくついていくものです。(私がそうでした。)しかしそれだとその場凌ぎのエンジニアになってしまうと危機感も感じておりました。将来突き抜けるにはこのままじゃダメだなと考えるようになりました。
3点目は、技術トレンドはどんどん変わっていくけど、SQLやDBって開発言語ほどトレンドが変わっていくものではないし、深く学習することによるコスパが高いなとも考えるようにななったからです。近年NoSQLが流行っていますが、DBMSがなくなるってことは中々想像し難いですし。
以上の理由からDBの体系的な学習をしようと決心し、書籍を探していました。その中で私のようなエンジニア歴1年目のエンジニアが読んでおくと良いオススメとして多く紹介されていたため、こちらをチョイスしてみました。
2.特に勉強になったこと
一番勉強になったのはCASE式に関するセクションです。
実務であまりCASE式を書く機会が多くなかったのですが、本書を読み進めていくうちに「こんなに良くできたものなのか!!」と感動させられました。
正直実務で使いこなすにはまだまだですが、絶対に自分のものにしてSQLをゴリゴリ書いていこうと思います。
3.本書をお奨めしたい人
是非私のようなエンジニア歴1年前後の人が読んでおくべき書籍だと思います。
技術書と聞くと難しいイメージを持ちがちですが、内容自体はその場凌ぎでやってきた私でも理解できましたし、今まで何となくだったところが明確になったり、微量ながらDBの知識がついたりと、発見の多い一冊だと思います。
3年目とかでこの書籍のSQLが書けないとなるとちょっと厳しい気もしたので、出来る方は不要ですが、「SQLに自信がなく、基礎から学び直したい」と考えている方には最適な一冊なのではと思いました。
4.まとめ
この書籍を通して、自身のDBの知識不足を痛感させられましたし、逆にDBに強くなればもっと世界が広がり、自身の武器にもなるとも感じました。今年はDBに強くなることをテーマに、残りの半年も頑張っていこうと決心がつきました。またもう一冊買って6月もDB学習してきたいと思います。
最後まで読んで頂き、ありがとうございました。
転職サイトについてまとめてみる
こんにちは。たいきゅんです。
今回は、私が転職活動時に使用していた転職サイトとその感想についてまとめてみようと思います。
①転職活動時の私のスペック
初めに転職活動をしていた時の私の簡単なスペック紹介です。
都内受託系webIT勤務
エンジニア経験:1年2ヶ月
開発言語:PHP
ポートフォリオ:Go,Vue,Firebaseを使用して作成
②使用した転職サイト
私は主に以下の3つを使って転職活動を行いました。最終的には転職ドラフト経由で転職しました。
・Green
・転職ドラフト
③それぞれのメリット・デメリット
それぞれのサイトの詳細については、ググってもらうとして私が感じたメリット・デメリットを書いていこうと思います。
(1) Green
メリット
・掲載社数・スカウトの数が多い
スカウトを受ける数は、3つの中で一番多かったです。広く認知されていることもあったさすがとしか言えないですね。
・十分な情報量
企業側の情報がフォーマットに沿って最低限表示されているので、Greenのページ＋コーポレートサイトを確認すれば、大体の情報を掴むことができました。
サクッと進めることができ効率的にできたのはよかったなと思います。
デメリット
・UXが微妙
たまにバグっぽい表示になったり、通知が多かったりとその点残念でした。
UXで残念に感じたのはGreenだけだったので、もう少し改善して欲しいです。
ただ転職活動に影響が出るような部分では特に感じなかったので、転職活動に支障はないと思います。
・選別が大変
通知がどんどんくるので優秀な方ほど煩わしく感じてしまうかもしれません。
またエンジニア転職を希望しているのに、全く違う業種からのスカウトが来たときはちょっとな…と思いました。
スカウトを送る側にも制限をかけて、業界違いからの連絡は来ないようになったらなと個人的に思いました。
(2) Wantedly
メリット
・シンプルで洗練されている
転職活動以外にも社会人同士が繋がるSNSみたいな形で機能しているアプリで機能が複雑になりがちかと思いきや、割とシンプルに洗練されていてすごいなと思います。
Wantedlyについては転職活動以外でも使用できるので、人脈拡大に使用したりするのもいいかもしれません。
デメリット
・プレミア会員じゃないとまずスカウトはこない。
転職活動専用サイトではないため、無料会員だとまず連絡は来ないです。
そのため転職活動をする際は絶対にプレミアム会員となり企業側にアピールできる状態になる必要があります。
唯一お金をかける必要が生じてしまっているのですが、専門サイトではないので仕方ないですね。
(3) 転職ドラフト
メリット
・他の求職者の情報から自身の立ち位置を確認できる
他のサイトにはない一番のメリットがこれです。
匿名ですが高年収でスカウトを受けている人のスペックを確認することができ、「どういった人材が転職市場で評価され、自身は今どの位置にいるのか」を客観視することができます。
自身のキャリア形成の参考にもなるし、モチベーションになります。
・名だたる有名企業が参加している
ITメガベンチャーで有名な企業であったり大きなスタートアップ企業であったり有名な企業からスカウトを受けるチャンスがあります。
・レジュメの審査が厳しく洗練されている。
名だたる企業からのスカウトのチャンスがあるため、求職者側の選別も厳格に行われます。未経験では恐らく通過できないでしょうし、経験者でもモダンでない技術を使っていると弾かれます。現に私もポートフォリオの作成でGo言語等を触ってない時期に書いたら、レジュメの審査に普通に落ちました。笑
・年収提示型である
スカウトされる際、年収も同時に提示されます。これが便利で最終面接まで進んだのに年収が低かった等のトラブルを回避できます。
デメリット
・ドラフトされるハードルが高い
時期にもよりますが、ハイレベルのドラフトというのが前提になってくるためドラフトを一回も受けずに終わってしまう可能性もあります。
以上です。
ざっとまとめてみましたが、個人的には転職ドラフトが新しく求職者にとってメリットの多いサイトなのかなと思いました。
年収提示型である点、エンジニア転職のみである点等、Webエンジニア転職に使うサービスとしての最適解の一つなのではと思いました。
今後も新しいサービスはどんどん公開されていくと思うので、出たらとりあえず使ってみるのスタンスでどんどん便利を享受していきましょう。
最後まで読んで頂きありがとうございました。
web系エンジニア転職日記〜面接対策編〜
こんにちは。たいきゅんです。
今回は2022年3-4月で行った転職活動において面接対策をメインにまとめていきます。
①面接の流れ
私の経験した流れは主に以下の形でした。
カジュアル面談→書類選考→一次面接→二次面接→最終面接
これにプラスして技術試験があったり、面談があったりといった形でした。
それぞれの段階について掻い摘んでまとめていこうと思います。
①カジュアル面談
サイトによって異なりますが、基本的に経験1年の私でもかなりの数のスカウトを頂けました。時期的なものもあったかもしれませんが、未経験の時の転職時と比べると大違いです。
そのためこの時点でかなり絞るようにしていました。仕事をしながら転職活動する方が多いと思うので、キャパを考えて最低限の条件を決めてそれを満たしていなかったらカジュアル面談に進まないことをお勧めします。
またカジュアル面談でいかに良い質問ができるかが選考を左右するのではないかと私は考えています。当たり前なのですが、基本的にカジュアル面談では評価なしに質問できるいい機会です。
カジュアル面談後に書類選考がある企業の場合、ここで書類選考で参考になるような情報を聞き出すようにしていました。カジュアル面談でこのような質問をするようにした時としなかった時とで、書類選考の通過率が格段に変わった気がしてます。
ちなみに私が聞いてよかったなという質問がこちらです。
採用に関する質問です。教えて頂ける範囲でいいので、エンジニア採用の中途採用にて大事にされていることを教えてください。
ここで聞き出せたことをベースに志望動機を書くことで、書類選考の通過率が上がった気がしてます。
②書類選考
転職活動を始めた最初の1ヶ月間はこの書類選考に悩まされました。転職活動で使用する履歴書・職務経歴書って決まった形がないのが難しくする点かもしれません。
落ちている頃は志望動機を書かずにずっと出していたり、最新版の状態にアップデートしていなかったりとしていたのがよくなかったなと思います。
対策として上記質問例のように、志望動機作成に使えそうなことをカジュアル面談で聞き、それを踏まえた志望動機を作成し提出するようにしていました。この結果、書類選考で落ちることが減るようになりました。
また毎回書類を添削することはもちろん、その企業に沿った内容にするようにして、使い回し感を出さないようにしました。
③一次面接
面接官は主にエンジニアの方が担当してくれました。そのため結論からより端的に伝えることを徹底していました。
また「私はテイカーではなくギバーである」ということを伝えることを一番意識していました。
当たり前ですが、エンジニアは基本的に指示待ちのテイカーよりも自ら動いて働くギバーの方が成長するし戦力になります。これを理解しているエンジニアが多い気がするので、面接官の方に論理的に伝えることを大切にしていました。
面接の初期段階で経験について深掘りされてテイカーだと判断されてしまった場合は落ちていましたし、反対にギバーだと伝えることができた時は通っていた気がしてます。
一次面接での評価ポイントは他にもあるとは思いますが、「私はテイカーではなくギバーである」ということを伝えることを意識してみてもいいのではと思っています。
④二次面接
ここではエンジニアチームのリーダーやCTO、事業部部長等が面接官になると思います。
スタンスは一次面接と同じで基本問題ないですが、より深く考えたり、よりビジネスよりの視点が必要になってくるのかなと思います。
ジョインした際、働くチームの上長にあたる方になるので、「一緒に働きたい人材像はどんな人材か。」というのを突き詰めて考える必要があるかと思います。
この点は技術や経験があまりなくても伝え方次第で高評価を得られる可能性が高いので、深く考えるようにしていました。
より企業研究を行い、欲しい人物像を理解しそれが私であるというのを伝えられるかどうかが一番大事です。
⑤最終面接
最終面接は社長や役員クラスの方が面接官になると思います。
最終面接にまで進めたということは、技術や経験等の要素はクリアしているということなので、この点自信を持つようにしていました。
そして「私は長く御社で活躍していきたいです。」ということを伝えることを第一に考えていました。
経営者にとっての一番のリスクは、「早く辞めてしまうこと」で間違いないでしょう。
いかに会社のことを知っていてくれて、魅力に感じていて、長く活躍してくれる人材であるかどうかが一番重要でしょう。
そのため面接を通して、「私は長く御社で活躍していきたいです。」ということを伝えることができれば内定をもらえると思います。
⑥まとめ
これはエンジニア転職に限ったことではないですが、「いかに戦略的に、いかに相手の立場に立って考えられるか」が面接を突破するための共通条件になると思います。
私はトライアンドエラーを繰り返して良くなっていくタイプで、最初は全然ダメで失敗ばかりでしたが、徐々に良くなっていき内定を頂くまで成長できました。
失敗を恐れずに挑戦し続ければ絶対成果が出ると思いますので、諦めずに挑戦し続けてください。
この記事があなたの転職活動の成功に貢献できていたら非常に嬉しいです。
最後まで読んで頂きありがとうございました。
転職活動でこれだけは大事にしてくれよ。
こんにちは。たいきゅんです。
今回は転職活動において大事にして欲しいことを私なりにまとめてみました。
①転職先が決まってから、退職の意向を伝えること。
これはよくひろゆきさんの切り抜きで回っていてご存じの方も多いかもしれませんが、転職先が決まってから退職の意向を伝えることはとても大事です。
理由は「余裕を持って面接等に挑めるから」です。
未経験からIT業界に転職する際、私はまさにこれができずに苦労しました。
退職→学習→転職というプロセスをとったため、金銭的に段々と余裕がなくなってきて、それが転職活動に影響をもたらす可能性があります。
私も金銭的にキツくなりとりあえず転職しなきゃと思い転職した経験があります。
結果的には良かったのですが、今思えば無茶なことをしたなと深く反省しております。
今回の転職活動では、この原則を守って活動したので「落ちてもとりあえず給与は入ってくる」という安心感があり、メンタル的に追い込まれることがなかったのがよかったと感じております。
時間的に難しい等の理由はあると思いますが、基本的にこの原則は守って転職活動をして欲しいです。
②多くの会社を受けて練習もすること
就職・転職活動において失敗する人の典型例として「いきたい企業だけ受ける」という人があると思います。
基本的に面接は場数を踏んでるかどうかで変わってくると私は考えており、この数が多ければ多いほど上手くいく可能性が高いです。
少なくとも場数を踏めば、「初対面の人の前で自分のことを話せない」等の悩みは解決するはずです。
とりあえず受けてみるってスタンスでもいいと思うので、面接の機会はたくさん作って面接慣れしてください。
また行きたい企業でない場合であっても、面接中は「この企業が第一志望である。」という気持ちで面接に臨むことも大事です。
行きたくない企業だと緊張感等が足りず、行きたい企業の面接のための経験を積めなかったり、面接に通らなかった場合多少でも落ち込んだりする時があると思います。
建前だけでもいいので面接中は「この企業が第一志望である。」ってスタンスで面接を受けるようにしましょう。
行きたくない企業の面接でも落ちたりすると落ち込むので、受けるからには受かるようにすることも大事です。
以上です。エンジニア転職のアドバイスになれば幸いです。
最後まで読んでいただきありがとうございました。
転職活動を通して改めて勉強方法を再定義してみる
こんにちは。たいきゅんです。
今回は、改めてエンジニアの勉強法を学習を再定義してみようと思います。
転職活動のエンジニア面接において毎回「勉強法を教えてください。」という質問を行い、面接官の方の勉強法を色々と聞いてみました。
そこで学んだことをアウトプットしていきたいと思います。
①私の学習法
私はまず作りたいものを決めてそれを達成するために必要な学習を積み上げる学習方法でやってます。
「GoでTodoアプリを作りたい」とか「Vueでaxiosを使ってリクエストを送信できるものを作成したい」等です。
作るために必要な知識は基本的に理解できるものの、より深い知識や体系的な知識が不足していたのも事実でした。
②参考になった学習方法
ここからは面接を通して「印象的だった！」「参考にしたい」と感じた学習方法についていくつか紹介してみます。
②-1 「平日は業務に全力コミット。休日に体系的に学習する。」
多くの方にインタビューする中で一番いいなと感じた学習方法です。
基本的にエンジニアの学習は業務時間内に済ませるのが一番効率的です。お金はもちろんそれが業務経験として残るので、ベースは業務時間内でのI/Oが多いことがベストだと思います。
そのため業務時間中は業務で分からないこと、知らないことに全力でコミットし知識を伸ばす。そして休日で本を読む等して体系的に学習することで、より深く理解するという方法は実に理に適っているなと思いました。
とりあえず体系的な学習をするということで、データベースの本を一冊ポチってやってみようと思います。
②-2「チュートリアルをやっておいてください。あとは業務やりながらキャッチアップして欲しい。」
チュートリアルをやっておいてほしい。という声が一番多かったです。
公式で出していて基礎中の基礎を体系的に学ぶにはチュートリアルが最適であると考える方が多いんだなと思いました。
私はこれを機に、Reactはチュートリアルの五目並べの学習から始めてみました。
②-3「学習はキャッチアップベースでやってほしい。」
新しいフレームワークを扱う会社の場合は、このように回答する所も多かった気がします。業務で使うコードとチュートリアルのコードが全く違うことなんてザラにあると思います。
そういう企業の方はこのような回答をしている方が多いのかなという印象でした。
③まとめ
いくつかの回答を紹介してみましたが、どれもに共通することは「アウトプットベースである。」ということかなと思います。
本を読んで学習すると回答された方も、その後は業務でその知識を活かしていくことが前提なので、インプットばかりしてもダメというのは共通見解でした。
いかに質の良いアウトプットをするのかにかかっているのかもしれないです。
私は、「本で体系的に学習する」「チュートリアルをやってみる」を実践し、アウトプットの質向上に励みたいと思います。
以上です。
皆さんのエンジニア学習方法の新たな発見になったら幸いです。
最後まで読んで頂きありがとうございました。
AWSが突然アカウント停止になった件についてまとめてみる
こんにちはたいきゅんです。
今回はAWSアカウントが突然停止になってしまったことについてまとめてみようと思います。
①経緯
転職活動に必要なポートフォリオをAWSを使ってデプロイしていたのですが、応募先の企業から「サイトが見れないのですが」と連絡を頂き確認したところ、サイトが非公開となっていました。
解決のためAWSにログインしようとした所「アカウントが停止されています」と表示されており、アカウント停止に気がつきました。
②原因は？
これが正直分からないです。AWSさんとやりとりさせて頂くと、IAMユーザーから攻撃を受けていると聞いたのですが、AWSCLIは全て環境変数に設定しておきましたし、もしかしたら無差別攻撃を受けてやられた？のかもしれないです。こればかりはわからないので、わかる方がいたら教えて頂きたいです。。。
③結果は？
AWSさんにご丁寧に対応して頂き、アカウントを復活させサービスを復旧させることができました。対応頂いた担当者の方、ありがとうございました。
④攻撃の中身
全てのリージョンにおいて、EC2インスタンスを1つ以上作成させられていました。サイズの大きなものを作成させられていたのですが、不幸中の幸いで、インスタンスは全て停止させられていたので、一月25000円程請求を受けた程度で済みました。
⑤今後の対応
まず料金体系を確認し、料金のアラートを受けたら中身を確認することが必要だと思いました。今回のサービスはCloudFrontを使用しているため、てっきり全てのリージョンから請求を受けるものかと誤解していました。アラート自体は確認しており、料金請求を見ていたので、この知識不足が原因の一つと思いました。
AWSサービスを使用する上で、使い方とセットで料金体系を理解する必要があると思いました。
またPWを複雑化すること等の基本的な対策を改めて行う必要があると再認識させられました。
以上になります。
皆さんセキュリティ対策はしっかりしましょう！！
最後まで読んで頂きありがとうございました。
