問題 mysql -u root -h localhost と入力し、mysql に接続しようとしたら以下のエラーが発生しました。 ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) 解決策 mysql サーバーを起動させれば解決しました。 サーバーが停止していたみたいでした。以下のコマンドで起動させ、再度接続を試みたらできました。 systemctl start mysqld.service 参考 以下サイトを参考にさせていただきました。ありがとうございます。

取り組みを実施した背景 社内の新人Webエンジニアがインフラにあまり慣れていなかった為、インフラスキルの向上を目的にAWS研修を実施していただきました?‍♂️ 実施にあたり自分のAWSに関するスキル感 EC2上でWordPressを立てたことがある プライベートサブネットにWordPressのEC2サーバを、プライベートサブネットにMySQLのEC2サーバを立てた ELBやAWS Auto Scalingは使用したことがない 今回作ったインフラの構成図と使用したもの 開発環境 本番環境 使用したもの OS: Amazon Linux release 2 (Karoo) リバースプロキシサーバ: nginx 1.18.0 WEBサーバ: PHPビルトインウェブサーバ PHP 8.0.1 DBサーバ: MySQL 8.0.20 研修の流れと「やったこと、わかったこと、わからなかったこと」 座学 ? IPアドレスやサブネットマスク IPアドレスの基礎知識 - Qiita OSの種類 yumやapt-getについて リージョンやアベイラビリティーゾーン 可用性の高め方 VPCやサブネット パブリックサブネットとプライベートサブネットの使い分け VPCやサブネットってなんなの？AWSをオフィスビルでわかりやすく表現してみた：穂苅智哉の Webビジネス！日進月歩：オルタナティブ・ブログ EC2、RDS、ELBについて 0から始めるAWS入門：概要 - Qiita 分からなかったこと ロードバランサーの設定方法イメージ出来なかった WEBサーバの前段でアクセス負荷を分散させてくれるということは知っていた しかし、スキーム、証明書の設定、ターゲットグループといった概念や設定方法をなんとなくでしか理解していなかった 後ほど行ったハンズオンで理解することが出来ました?‍♂️ 開発環境構築（ハンズオン）? やったこと パブリックサブネットでグローバルIPのあるEC2を作成 yumでnginxを入れて初期ページを表示する yumでPHP8系をインストール その後PHPのビルトインサーバでHelloWorld PHP-FPMとビルトインサーバの2つがWEBサーバの候補で、他の参加者がPHP-FPMを選んでいたため物は試しと思いあえてビルトインサーバの方を選んだ（結果的に良くない実装だった? ） yumでMySQL8系をインストール その後ビルトインサーバでHelloWorld PHPでMySQLに入れたダミーデータを取得し表示 WordPressをインストール nginx.confにルーティングを記述し、nginx再起動 ビルトインサーバを起動 IPアドレス経由でWordpressが開くかどうかをデバッグしながら確認 分かったこと EC2インスタンスの構築方法 MySQL5.7系以降のパスワードの初期値について 参考サイト: MySQLにrootでログインできない！初期設定やファイル変更が必要です！ PHPにおけるMySQLとの連携方法 分からなかったこと WordPressコンテンツが読み込まない状態になってしまった DB内の「WordPressの設定データ」が間違っていた可能性がある 原因調査しきれず?‍♂️ WordPress再インストールとconfigの再設定、DBの再生成で直った?‍♂️ 本番環境構築（ハンズオン）? やったこと 開発環境からのコピー 開発環境のEC2からamiを作成し、本番環境のEC2を生成&起動 開発環境のDBからdump取って、本番環境のRDSに入れる 分かったこと amiのとり方 amiから複製する方法 開発環境のDBからdumpをエクスポートする方法 本番環境のDBにdumpをインポートする方法 分からなかったこと 特になし 本番環境構築（ハンズオン）続き? やったこと ALBの作成 AWSの3種類のLBの比較と使い分け (ALB, NLB, CLB) - Qiita ACMを利用してSSL証明書の作成とALBへの設定 AutoScalingさせる ターゲットグループの設定 オートスケーリンググループの設定 わかったこと AutoScalingの設定方法 ApacheBenchコマンドを用いた負荷テストで、Scalingするかを確認する方法 Apache Benchでサクッと性能テスト - Qiita 分からなかったこと AutoScalingで新規起動したサーバでビルトインサーバを起動する方法? 個人アプリ検討、選定、実装まで 検討 MoonGift等でOSSを調べて以下のアプリに興味を持った OWASP ZAP Webアプリケーションセキュリティスキャナー Redmine プロジェクト管理ソフトウェア Lottery 懇親会等で使えそうなルーレットアプリ 選定 Dockerで立ち上げ可能なアプリを選定 第1候補: OwaspZap 理由: 今後業務でアプリを作った際に試しに自己診断してみたいと考えたため 第2候補: Redmine 理由: チケット管理ツールを立ち上げて実際に使ってみることで、今後の開発時に活きる「実装アイディア」を得られればなと考えた ただ、現状業務ではプロジェクト管理はGitHub内の機能を使用しているため、Redmineが業務に直接活きないと考えたため第2候補にした 実装 OwaspZap DockerでCUIが起動出来た しかし、GUIを起動するにはマシンリソース不足だったため断念? Redmine Dockerを用いて起動出来た GUIで起動出来た? 振り返り? うまくいったこと ? EC2インスタンスで開発環境と本番環境を作ること LBを経由してWordPressを公開すること うまくいかなかったこと? nginxのルーティングをベストな設定で記述したかった 十分な理解が無いままに記述して序盤上手く行ってしまったため、終盤にルーティングがぐちゃぐちゃになって困った WordPressを稼働させる上で最適な構成にしたかった ビルトインサーバで稼働させる方向で進めてしまった その影響もありAutoScalingの設定時に他の参加者では不要な作業が発生した もし次やるならPHP-FPMで作りたい 今後トライしたいこと? コンテナ周りのマネージドサービスを適切に使用して、運用負荷の少ないシステム構築すること nginxのルーティングを、きちんと理解した上で記述出来るようにすること AutoScalingで新規起動したサーバ上で、アプリケーションもちゃんと起動するようにすること まとめ 一度プライベートでEC2でWordPressを立てたことはあったのですが、ざっくりとしか着手していなかった為今回の研修では「わかっていなかった所」が数多く見つかり、かつその理解を深めることが出来たのでとても良かったです。ありがとうございました?‍♂️ 「ビルトインサーバでWordPress環境構築」という、「PHP-FPMを使った構築」より比較的情報が少ないかつ本番環境では非推奨な実装方法で進めてしまったため、問題が起こったときの原因究明が難しかったことが印象に残っています。（とはいえ、インフラの根本的な仕組みについて理解していれば解決は難しくないはず。主に自身の実力不足。） 今後技術選定を行うときは、「信頼できる情報源が豊富かどうか」も頭に入れた方が良いと学びました。

アプリの概要 アプリ名：ひとこと日記ver2 日々の記録をテキスト形式で保存する、シンプルな日記アプリです。 コードはGithubにてご覧いただけます。(フロントエンドのコード・バックエンドのコード) 作成環境 ・インフラ：AWS ・バックエンド：node.js ＋ Express ・フロントエンド：Vue.js ・データベース：MySQL ●各バージョン node.js v12.18.2, Express 4.17.1, Vue.js 2.6.12, Veu-CLI 4.4.6, MySQL 8.0 アプリで行う主な処理 ユーザー登録・認証処理 日記のCRUD処理 アプリの構成 ・インフラは、AWSのEC2上にExpressサーバーを立て、RDS上にMySQLデータベースを立てています。 ・フロントエンドは、Veu-CLIを使って構築し、SPAにしています。（Nuxt.jsは使っていません） ・Expressサーバーにて、SPAのホスティングと、データベース処理用のエンドポイントの提供を行っています。 ・Vue.js-Express間の通信は、axiosでデータをやり取りしています。 サーバーとクライアントの構成図 ユーザー登録・認証機能の動作 ・UIからユーザー登録、ログインを行います。 ・Vue.jsからaxiosで通信し、Expressサーバーのエンドポイントへアクセスすることで、ユーザー登録、ログインの処理を実現します。 ・ログインするとトークンが発行され、以降の処理はトークンによってユーザーを一意に特定します。 日記機能の動作 ・UIから日記の表示・作成・更新・削除を行います。 ・Vue.jsからaxiosで通信し、Expressサーバーのエンドポイントへアクセスすることで、日記のCRUD処理を実現します。 ・axios通信時にサーバーにトークンを送信することで、ユーザーを一意に特定して、日記データを処理します。 フォルダツリー ●vuecli-appのフォルダ構成（フロントエンド） [ルート] └ [public]フォルダ └ [images]フォルダ 　└ 各種imageは全てここに格納 └ index.html └ favicon-diary.ico └ [src]フォルダ └ [asset]フォルダ └ [components]フォルダ 　└ [diary]フォルダ　日記関係のVueコンポーネントを格納するフォルダ └ Index.vue　トップページ（アプリの紹介ページ） └ Mypage.vue　日記の一覧表示ページ └ Edit_Create.vue　日記作成ページ └ Edit_Update.vue　日記更新・削除ページ └ Header.vue　ログイン時のヘッダーコンポーネント └ Help.vue　機能紹介ページ 　└ [login]フォルダ　ユーザー認証関係のVueコンポーネントを格納するフォルダ └ Regist.vue　ユーザー登録ページ └ Login.vue　ログインページ └ Trial.vue　お試しユーザーログインページ └ App.vue └ main.js └ router.js　Vue.jsのルーティングを記述したJS └ store.js　Vuexの設定を記述したJS ●express-appのフォルダ構成（バックエンド） [ルート] └ [public]フォルダ　ビルドしたVue.jsのファイルをここに格納している。 └ 各種ファイル。Vue-CLIでビルドしたdistフォルダ内のファイルをそのままコピーしたもの。 └ [routes]フォルダ　axiosリクエストのエンドポイントを提供するためのルーターモジュールを格納したフォルダ └ get_diaries.js　一ヶ月分の日記を取得する処理のモジュール └ get_one_diary.js　一日分の日記を取得する処理のモジュール └ edit_create.js　日記を作成する処理のモジュール └ edit_update.js　日記を更新する処理のモジュール └ edit_delete.js　日記を削除する処理のモジュール └ user_regist.js　ユーザー登録する処理のモジュール └ user_login.js　ログインする処理のモジュール └ user_delete.js　ユーザーを削除する処理のモジュール └ user_auth.js　認証トークンを延長する処理のモジュール └ [function]フォルダ　サーバーに機能を与えるモジュールを格納したフォルダ └ db_connect.js　データベース接続設定モジュール └ token.js　認証トークン発行モジュール └ clear_auth.js　有効期限切れのトークン情報を削除するモジュール └ app.js

TL;DR MySQL の全文検索では、変更を commit しなければ index が作成されない。 これは、全文検索用の index を作成する処理は非常に重いので、内部では commit 後にバッチ処理を実行するため。 そのために、unittest では rollback ができないので、必要なデータを全て消す方法を採用した。 はじめに MySQL の全文検索を用いた Web Application を作った際にテスト時にハマったことがありましたので、その原因と対処について記したいと思います。 概要 実行環境 MySQL 5.7 Storage Engine は InnoDB を使っています Python 3.8 SqlAlchemy 1.4.7 やろうとしていたこと 検索機能を Web Application に作成する MySQL の全文検索を用いた この箇所のテストコードは session を使ってテスト後に rollback をする設計になっていた 困ったこととその対処 MySQL 全文検索を用いた方法は正しく動きました。しかしながら、そのテストが正しく動きませんでした。詳しく説明すると、対象箇所の全文検索箇所には投入したはずのデータがなく、毎回テストが落ちる結果になっていました。テストコードを何度も見ましたが、特に問題はなさそうだったために、念のためにMySQL のドキュメントを細かく調べることにしました。するとこのように書かれていました。 https://dev.mysql.com/doc/refman/5.6/ja/innodb-fulltext-index.html より抜粋 InnoDB による全文インデックスのトランザクション処理 InnoDB の FULLTEXT インデックスには、そのキャッシュおよびバッチ処理の動作のために、特別なトランザクション処理の特性が備わっています。特に、FULLTEXT インデックス上の更新および挿入は、トランザクションのコミット時に処理されます。つまり、FULLTEXT 検索では、コミットされたデータのみを表示できます。次の例で、この動作を実演します。FULLTEXT 検索では、挿入された行がコミットされたあとにはじめて、結果が返されます。 mysql> CREATE TABLE opening_lines ( id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY, opening_line TEXT(500), author VARCHAR(200), title VARCHAR(200), FULLTEXT idx (opening_line) ) ENGINE=InnoDB; mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> INSERT INTO opening_lines(opening_line,author,title) VALUES ('Call me Ishmael.','Herman Melville','Moby-Dick'), ('A screaming comes across the sky.','Thomas Pynchon','Gravity\'s Rainbow'), ('I am an invisible man.','Ralph Ellison','Invisible Man'), ('Where now? Who now? When now?','Samuel Beckett','The Unnamable'), ('It was love at first sight.','Joseph Heller','Catch-22'), ('All this happened, more or less.','Kurt Vonnegut','Slaughterhouse-Five'), ('Mrs. Dalloway said she would buy the flowers herself.','Virginia Woolf','Mrs. Dalloway'), ('It was a pleasure to burn.','Ray Bradbury','Fahrenheit 451'); Query OK, 8 rows affected (0.00 sec) Records: 8 Duplicates: 0 Warnings: 0 mysql> SELECT COUNT(*) FROM opening_lines WHERE MATCH(opening_line) AGAINST('Ishmael'); +----------+ | COUNT(*) | +----------+ | 0 | +----------+ 1 row in set (0.00 sec) mysql> COMMIT; Query OK, 0 rows affected (0.00 sec) mysql> SELECT COUNT(*) FROM opening_lines WHERE MATCH(opening_line) AGAINST('Ishmael'); +----------+ | COUNT(*) | +----------+ | 1 | +----------+ 1 row in set (0.00 sec) ここで初めて知りましたが、InnoDB では FullText 用の Index を作成する際には、commit することが条件だったのです。 テストコードの対処 今回のテストの設計では、DBを使った処理はテストの最後に確実に rollback がなされるような設計にしていました。しかしながら、これではこの方法では、FullText 用のインデックスを作成することができずに、正しくテストを行うことをできません。 苦肉の策ですが、FullText Index を用いる箇所のみデータを commit し、テスト後にはデータを全て削除するという方針に変更しました。もちろん、これが本当に良い方法であるかどうかわかりませんが、この方針で正しくテストが動くようになりました。 まとめ InnoDB において FullText 用のインデックスが作成されるのは、commit された後に実行される。そのために、テストの時にはこの点を留意して書かなければならない。