Lab 2b

Lab2b:高い可用性を持つブログサイトの構築 Part2

概要

この Lab では、Amazon Elastic Compute Cloud (Amazon EC2)、Elastic Load Balancing (ELB)、Amazon Virtual Private Cloud (Amazon VPC)、Amazon Relational Database Service (Amazon RDS) を使用して可用性の高いブログサイトを構築します。

目標

このラボを修了すると、次のことが出来るようになります。

  • Lab1 で構成したシングル構成の Web サーバーおよび DB サーバーをマルチアベイラビリティーゾーン構成に変更する

  • ELB を使って Web サーバーの可用性を高める

  • 最終的には、次の図で示すようなアプリケーション環境を構築する

    Lab2 Architecture

前提条件

このラボの前提条件を次に示します。

  • Microsoft Windows、Mac OS(X 以降)、または Linux(Ubuntu、SUSE、または Red Hat)が搭載されているノートパソコンで、Wi-Fi アクセスができること
  • Microsoft Windows ユーザーの場合は、コンピュータへの管理者アクセスができること
  • Chrome、Firefox、Internet Explorer 11(これより前のバージョンの Internet Explorer はサポートされていません)などのインターネットブラウザを利用できること

時間

このラボは、終了までに 30 分かかります。

各タスクへのリンク

Lab2b-Task1: ELB (ALB) を作成

ラボのこのセクションでは、Web サーバーの可用性を高めるために、ELB を作成します。
ELB には複数の種類のロードバランサーがありますが、ここでは HTTP 通信を分散するために Application Load Balancer (ALB) を使用します。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインで [セキュリティグループ] をクリックします。

  3. [セキュリティグループを作成] をクリックします。

  4. [基本的な詳細] のセクションで、セキュリティグループ名、説明、および VPC を次のように入力します。

    セキュリティグループ名 lbsg
    説明 Security Group for Load Balancer
    VPC LabVPC
    入力欄の右端の×で一度削除すると
    選択できるようになります。
  5. [インバウンドルール] のセクションで [ルールを追加] をクリックします。

    注意 : [インバウンドルール] のセクションを編集していることを確認してください。間違えて [アウトバウンドルール] を編集すると今回の環境は正常に動作しません。

  6. 以下の内容で、ルールを追加します。

    タイプ プロトコル ポート範囲 ソース(またはリソースタイプ) 説明
    HTTP を選択 (自動的に選択されます) (自動的に選択されます) Anywhere-IPv4 を選択 Access to Load Balancer
  7. [タグ] のセクションで、[新規タグを追加]をクリックし、タグのキーと値を次のように入力します。

    キー
    Name lbsg
  8. [セキュリティグループを作成] をクリックします。

  9. 左側のナビゲーションペインで [ターゲットグループ] をクリックします。 マネジメントコンソールが英語表示になった方:画面左下の 日本語English(US) にして、再度 日本語 にすると、日本語表示に戻ります

  10. [ターゲットグループの作成] をクリックします。

  11. [基本的な設定] のセクションで、ターゲットタイプ、ターゲットグループ名、および VPC を次のように入力します。

    ターゲットタイプ インスタンス
    ターゲットグループ名 wptarget
    VPC LabVPC
  12. [ヘルスチェック] のセクションで、[ヘルスチェックパス] に /readme.html を入力します。

  13. [ヘルスチェックの詳細設定] を開き、以下の設定を指定します。

    正常のしきい値: 3デフォルトから変更) ロードバランサーは、ヘルスチェックが連続して 3 回成功した場合に、インスタンスが正常であると判断し、そのインスタンスへのトラフィック送信を開始します。

    非正常のしきい値: 2(デフォルトのまま) ロードバランサーは、ヘルスチェックが連続して 2 回失敗した場合に、インスタンスが異常であると判断し、インスタンスが正常になるまでインスタンスへのトラフィック送信を停止します。

    タイムアウト: 5(秒:デフォルトのまま) ロードバランサーは、ヘルスチェックへ応答するために 5 秒待ってからタイムアウトします。

    間隔: 10 (秒:デフォルトから変更) ロードバランサーは 10 秒おきにヘルスチェックを実施します。

  14. [次へ] をクリックします。

  15. [使用可能なインスタンス] に表示された サーバ (Web Server01) へチェックを入れます。

  16. [保留中として以下を含める] をクリックします。[ターゲット] に Web Server01 が登録されます。

  17. [ターゲットグループの作成] をクリックします。

  18. 左側のナビゲーションペインで [ロードバランサー] をクリックします。

  19. [ロードバランサーの作成] をクリックします。

  20. [ロードバランサーの種類の選択] で [Application Load Balancer] の [作成] をクリックします。

  21. 以下の設定を指定します。(その他の項目はデフォルトのままとします。)

    基本的な設定
    ロードバランサー名 WordPressLB
    ネットワークマッピング
    VPC LabVPC を選択
    マッピング 1. ap-northeast-1a を選択し、サブネットの選択で PublicSubnet01 をクリック
    2. ap-northeast-1c を選択し、サブネットの選択で PublicSubnet02 をクリック
    セキュリティグループ
    セキュリティグループ default を削除し lbsg を選択
    リスナーとルーティング
    リスナー HTTP:80 のデフォルトアクション wptarget を選択
  22. [ロードバランサーの作成] をクリックします。

  23. [ロードバランサーを表示] をクリックします。

  24. 新しいロードバランサーのプロビジョニングが開始されます。

    1 分程度経過したらページの右上隅にある更新アイコンをクリックし、[状態] が active になるまで待ちます。active になるまで数分かかる場合もあります。 (下部の [説明] タブの中で ロードバランサーの名前の横に [!] がついている場合は無視して下さい)

  25. 左側のナビゲーションペインから [ターゲットグループ] をクリックします。
    一覧から wptarget のリンクを選択して、画面下部の [ターゲット] タブをクリックします。
    登録済みターゲットのインスタンスの [ヘルスステータス (Health status)] が [healthy] になるまでページ右上の更新ボタンを定期的にクリックして下さい。これは 2 分以内に完了します。

  26. 左側のナビゲーションペインから [ロードバランサー] をクリックします。
    一覧から WordPressLB にチェックを入れ、画面下部の [説明] タブに表示されている [DNS 名] の値をコピーします。「(A レコード)」は含めないで下さい。

  27. 新しいブラウザタブかウィンドウを開き、コピーした DNS 名をアドレスバーに貼り付けて Enter キーを押します。
    WordPress で構築したブログサイトが表示されることを確認します。

    ロードバランサー (WordPressLB)のDNS名は、この後の手順でも使用するため、メモ帳などのテキストエディタへコピーします。

    ロードバランサーのプロビジョニングが完了する前にアクセスすると接続エラーになる場合があります。この場合、ブラウザや OS がネガティブキャッシュを持ってしまい、ロードバランサーが正常に動作していても応答が得られなくなります。IE などの他のブラウザを使用して接続することで動作を確認できる場合があります。不明な場合はインストラクターに連絡してください。

Lab2b-Task2: WordPress URL の変更

ラボのこのセクションでは、Web サーバーが ELB 経由でアクセスした際にも、正常にリクエストを返せるよう WordPress アドレスを変更します。

  1. WordPress の管理者用ページで、左側のナビゲーションペインの [設定] > [一般]をクリックします。 WordPress の管理者用ページを閉じてしまっている場合は、以下の手順で再度ログインしてください。

    ・URL http://<インスタンスのパブリック DNS 名>/wp-admin/

    <インスタンスのパブリック DNS 名> の部分を、先の手順でメモしておいた EC2 インスタンス ( Web Server01 ) のパブリック IPv4 DNS に上書きして下さい。これが、WordPress のセットアップ用ページの URL です。

    ・以下のような形式の URL になります。

    例)http://ec2-54-248-7-xxx.ap-northeast-1.compute.amazonaws.com/wp-admin/

  2. 下記 URL をテキストエディタにコピーして下さい。

    URL http://<ロードバランサー (WordPressLB)の DNS 名>

  3. テキストエディタにて、<ロードバランサー (WordPressLB)の DNS 名> の部分を、 Task1 でメモしておいた ELB の DNS 名に置き換えてください。これが ELB 経由での WordPress アドレスになります。

    以下のような形式の URL になります。

    例)http://wordpresslb-123456789012.ap-northeast-1.elb.amazonaws.com

    WordPress アドレス は、テキストエディタにコピーしてください。

  4. ブラウザに戻って、[WordPress アドレス (URL)] へ、WordPress アドレスを貼り付けます。

    同様に、「サイトアドレス (URL)」に WordPress アドレスを貼り付けます。

    WordPress の設定として「WordPress アドレス (URL)」と 「サイトアドレス (URL)」は同じになります。

    注意 : 「WordPress アドレス (URL)」と「サイトアドレス (URL)」の 2 箇所の変更を行いましたか?

  5. 設定ページ下部の [変更を保存] をクリックします。

    注意 : この手順の後に WordPress が正常に動作しなくなった場合は、上記設定が保存された MySQL データベース上のデータを直接修正する必要があります。

    こちらをクリック すると復旧手順が記載されています。MySQL の操作に不慣れな場合はインストラクターに連絡してください。

  6. 変更が反映されると、自動的に ELB 経由での WordPress アドレスにリダイレクトされます。

Lab2b-Task3: WordPress の動作確認

このセクションでは、WordPress で作成したブログサイトの動作確認を行います。

  1. WordPress の管理画面にログインします。

    ユーザー名 admin
    パスワード ラボ1で設定したパスワード

    注意 : WordPress の管理者 (admin) パスワードを忘れてしまった場合は、上記設定が保存された MySQL データベース上のデータを直接修正する必要があります。
    こちらをクリックすると復旧手順が記載してあります。MySQL の操作に不慣れな場合はインストラクターに連絡してください。

  2. WordPress の管理画面で、画面左の [投稿] メニューから [新規追加] をクリックして、画像付きの記事を投稿します。

  3. ブログのタイトル (英語で入力してください) と本文を入力し、 [ブロックの追加]アイコンをクリックし、 [画像]を選択します。

    ※ WordPress のデフォルト設定では、ブログのタイトルを日本語にすると、投稿が正常に表示されません。

  4. [アップロード] をクリックし、ローカル PC にある任意の画像ファイルを選択します。
    さらに、右下の [開く] をクリックします。

  5. ブログに画像が挿入されたことを確認し、画面右側にある [公開] をクリックし、[公開] をクリックします。

  6. 投稿したブログ内容を表示するには、[投稿を表示] をクリックします。

  7. ブログ記事内の画像を右クリックして別のタブで開き、表示された画像の URL を確認します。

Lab2b-Task4: カスタム AMI の作成

このセクションでは Web サーバーを追加作成するために、ベースイメージとなる Web Server01 のカスタム AMI を作成します。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインから [インスタンス] をクリックします。

  3. ラボ 1 で作成した Web サーバーインスタンス (Web Server01) を右クリックし、[イメージとテンプレート] - [イメージを作成] の順に選択します。

  4. [イメージを作成] ダイアログボックスで以下の設定を指定します。

    イメージ名 myAMI-lab2b
    イメージの説明 lab2b-wordpress-ami
    再起動しない チェックあり

    実際のシステム運用では、静止点を確保する場合は AMI 作成時に EC2 インスタンスの再起動 を行うことを検討してください。

  5. [イメージを作成]をクリックします。

  6. イメージの作成リクエストが受領されたメッセージが表示されたら、その画面で [閉じる] をクリックします。

  7. 左側のナビゲーションペインで [AMI] をクリックし、AMI の一覧を表示します。
    作成した AMI(myAMI) の [状態] が [available] になるまで待ちます。数分かかる場合があります。

    ※表示が変わらない場合は、マネジメントコンソール右上の [更新] アイコンをクリックし、画面をリフレッシュしてください。

Lab2b-Task5: Web サーバーの追加作成

このセクションでは、Web サーバーの可用性を高めるために、Web サーバーを追加作成します。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインで [インスタンス] をクリックし、[インスタンスを起動] をクリックします。

  3. Amazon Machine Image (AMI) を選択します。[マイ AMI] で Task4 で作成した [myAMI-lab2b] の [選択] をクリックします。

  4. [インスタンスタイプの選択] ページで、t2.micro を選択して、[次のステップ:インスタンスの詳細の設定] をクリックします。

  5. [インスタンスの詳細の設定] ページで、次のように指定します。

    ネットワーク LabVPC
    サブネット PublicSubnet02
    自動割り当てパブリック IP 有効
    IAM ロール WP-Role
    モニタリング [レ] CloudWatch 詳細モニタリングを有効化

    注意 : インスタンスの配置先サブネットは PublicSubnet02 になっていますか?

  6. [次のステップ: ストレージの追加] をクリックします。
    インスタンスのストレージ設定はデフォルトのままにします。

  7. [次のステップ: タグの追加] をクリックします。

  8. [クリックして Name タグを追加します] のリンクをクリックします。

  9. 追加されたテキストボックスに以下の値を入力します。

    キー Name
    Web Server02
  10. [次のステップ: セキュリティグループの設定] をクリックします。

  11. [セキュリティグループの割り当て] で、[既存のセキュリティグループを選択する] ラジオボタンをクリックします。  

  12. [websg]を選択します。

  13. [確認と作成]をクリックします。

    ヒント:【警告メッセージが出た場合】
    下記警告メッセージは、このハンズオンでは無視して下さい。
    「AMI では、アクセスを可能にするためにポート 22 を開く必要があるため、このインスタンスに接続できません。現在のセキュリティグループでは、ポート 22 が開いていません。」
    尚、実際のシステム構築・運用では、警告メッセージをよく読み、セキュリティや運用上の問題がないか確認することをお勧めします。

  14. 表示された設定を確認して、[起動] をクリックします。

  15. [既存のキーペアの選択] をクリックして[キーペアなしで続行] を選択します。

  16. “私は、キーペアがない場合、EC2 Instance Connect を使用するか、AMI に組み込まれているパスワードを知っている場合にのみ、このインスタンスに接続できることを認識しています。EC2 Instance Connect は、Amazon Linux 2 および Ubuntu でのみサポートされています。詳細はこちらをご覧ください。“のチェックボックスに、チェックを入れます。

  17. [インスタンスの作成]をクリックします。

  18. [インスタンスの表示] をクリックします。

  19. EC2 インスタンスの一覧に作成したインスタンスが表示されます。
    作成した EC2 インスタンス (Web Server02) の[ステータスチェック] が [2/2 のチェックに合格しました] と表示されるのを確認します。

  20. 作成した EC2 インスタンス (Web Server02) のパブリック DNS 名へブラウザでアクセスし、WordPress の README ページが表示されることを確認します。

    アクセス先 URL は、http://<Web Server02 の パブリック IPv4 DNS>/readme.html と指定します。

    以下は URL の例です。
    http://ec2-54-238-126-112.ap-northeast-1.compute.amazonaws.com/readme.html

    【考えてみよう!】 Web Server02 は新規作成したばかりなのに、なぜ WordPress のブログサイトが稼働しているのですか?

Lab2b-Task6: ELB (ALB) へ Web サーバーを追加

ラボのこのセクションでは、Web サーバーの可用性を高めるために、ELB (ALB) へ 2 台目の Web サーバーを追加します。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインで [ターゲットグループ] をクリックします。

  3. Task1 で作成したターゲットグループ [wptarget] をクリックします。

  4. [ターゲット( Targets )] タブ内の[ターゲットの登録( Register targets )] をクリックします。

  5. [使用可能なインスタンス( Available instances )]から、Task5 で起動した 2 つ目の EC2 インスタンス Web Server02 にチェックを入れ、[保留中として以下を含める( include ad pending below )]をクリックします。

  6. [保留中のターゲットの登録( Register pending targets )] をクリックします。

  7. 30 秒経過したら更新アイコンをクリックします。Web Server02の [ステータス(Health status)] が [healthy] になるまでページを定期的に更新します。

  8. ALB のDNS 名 にブラウザで複数回アクセスし、WordPress で構築したブログサイトが表示されるか確認します。

    アクセス先 URL は、http://[メモしてあるELBの"ロードバランサー (WordPressLB)のDNS名"を入力] と指定します。

    以下は URL の例です。

    例)http://wordpresslb-123456789012.ap-northeast-1.elb.amazonaws.com

ここまでの手順で、ALB を利用して複数 AZ に配置されている 2 台の Web サーバー へ HTTP アクセスを負荷分散することで可用性の向上ができました。 では、次にデータベースサーバーの可用性向上を行っていきましょう。

Lab2b-Task7: DB サーバーの Multi-AZ オプションを有効化

ラボのこのセクションでは、DB サーバーの可用性を高めるために、Multi-AZ オプションを有効化します。

  1. AWS マネジメントコンソールで [サービス] から [RDS] をクリックします。

  2. 左側のナビゲーションペインで [データベース] をクリックします。

  3. 作成されている DB サーバー [chapter1] の左側の〇をクリックして、 [変更] を選択します。

  4. [可用性と耐久性] 内の [マルチ AZ 配置] で [スタンバイインスタンスを作成する] を選択します。

  5. 画面下部の [続行] をクリックします。

  6. [変更のスケジューリング] で [すぐに適用] チェックボックスをオンにして [DB インスタンスを変更] をクリックします。

    ・警告メッセージ “Potential performance impact” が表示される場合、このトレーニングでは無視してください。DB インスタンスのスペックが不足する可能性を伝えるメッセージとなっております。

    ・警告メッセージ “予期されないダウンタイムの可能性” が表示される場合、このトレーニングでは無視してください。データベースの変更を即時適用することで、ダウンタイムが生じる可能性について考慮するよう伝えるメッセージとなっております。

  7. DB サーバーの [ステータス] が [変更中]になります。 [変更中]になっていない場合には[更新]アイコンを押して更新してください。[利用可能] になれば、DB サーバーの Multi-AZ 化は完了です。

    Multi-AZ 化には 5 分 〜 15 分程度かかります。 Multi-AZ 化の進捗状況は DB サーバー(chapter1) をクリック > [ログとイベント] タグ内の 最近のイベント から参照できます

Lab2b-Challenge Task1: ELB(ALB) の動作確認

このセクションでは、作成した Web サーバーが ELB (ALB) によって負荷分散されているかを、Web サーバーのアクセスログで確認します。

ヒント : Challenge Task はハンズオンをより深く理解をするための Task です。次のモジュールやラボに進むための必須手順ではありません。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインで [インスタンス] をクリックします。

  3. Web Server01 左のチェックボックスをクリックします。 ​

  4. 画面上部の [接続] をクリックします。 ​

  5. 接続方法 [セッションマネージャー] を選択します。 ​

  6. [接続] をクリックします。

  7. 同様の手順で、Web Server02 にも Session Manager で接続します。

  8. Web Server01、Web Server02 それぞれで、以下のコマンドを実行します。

    sudo su ec2-user
    sudo tail /var/log/httpd/access_log
    

    ALB から負荷分散ターゲットである Web Server01 と Web Server02 にヘルスチェックが行われている様子が確認できます。

  9. Web Server01、Web Server02 の両方で、次のコマンドを実行します。 ALB からのヘルスチェック以外の HTTP リクエストが来ると、アクセスログが表示されます。

    sudo tail -f /var/log/httpd/access_log | grep -v HealthChecker
    
  10. ALB の DNS 名 にブラウザで複数回 (10 回程度) アクセスします。

  11. Web Server01、Web Server02 の双方にアクセスログが出力されていることを確認します。 どのようなリクエストが実行されているか、アクセスログを読んでみましょう。

    tail コマンドによるログ出力は Ctrl + c で終了できます。

以上で ELB (ALB) の動作確認は完了です。

Lab2b-Challenge Task2: RDS フェイルオーバーの動作確認

このセクションでは、作成した DB サーバーが RDS の Multi-AZ オプションによってフェイルオーバーされるか確認します。

ヒント : Challenge Task はハンズオンをより深く理解をするための Task です。次のモジュールやラボに進むための必須手順ではありません。

  1. AWS マネジメントコンソールで [サービス] から [RDS] をクリックします。

  2. 左側のナビゲーションペインで [データベース] をクリックします。

  3. 作成されている DB インスタンス (chapter1) の “リージョンと AZ” を確認し、DB インスタンスが稼働している AZ をテキストエディタにメモします。

    ハンズオン手順通り進めている場合は ap-northeast-1a で DB インスタンス (Primary) が稼働しているはずです。
    スタンバイレプリカ DB インスタンスの所属 AZ を知りたい場合は、chapter1 の名前をクリック > 設定タブ > インスタンス の “セカンダリゾーン” にて確認可能です。

    ヒント : Web サーバ (Web Server01 または Web Server02) にて dig <DBエンドポイント> のコマンドを実施することで、WordPress から実際に SQL 接続している DB インスタンスの IP アドレスを知ることができます。 時間に余裕がある際は、DB 再起動 (フェイルオーバーを行う) の前後で、dig コマンドを実施してください。DB エンドポイントに対する IP アドレス (つまり、接続先の DB インスタンス) が切り替わっている様子を見ることができるでしょう。

  4. 作成されている DB インスタンスを選択し、[アクション] で [再起動] を選択します。

    【再起動が選べない?】 DB クラスタの Multi-AZ 化のオペレーションが完了するまで「再起動」が選べません。データベースのステータスが "利用可能" になるまで、適宜リロードしてお待ちください。
  5. [フェイルオーバーし再起動しますか?] のチェックボックスをオンにして [確認] をクリックします。

  6. 左側のナビゲーションペインで [データベース] をクリックします。

  7. DB サーバー (chapter1) の名前をクリックします。

  8. RDS コンソールの [ログとイベント] にて、DB インスタンスの再起動から 2 分程経つと 最近のイベント 内容が更新されます。時間が昇順 (▲) になっている場合は、クリックして降順 (▼) に変更します。

    ヒント : 画面が更新されない場合は、右上の[最近のイベント] 画面右上の [更新] ボタンをクリックして、画面をリフレッシュします。

  9. 最近のイベント に処理の進行に従ってメッセージが表示されます(最新のメッセージは最終ページに表示されます)。
    数分経過して最終的に [Multi-AZ instance failover completed]のメッセージが出力されていれば、フェイルオーバーの完了です。

    新しい Primary DB インスタンスが稼働しているアベイラビリティゾーンは、chapter1 のステータスが “再起動中” から “利用可能” になったタイミングで “リージョンと AZ” の箇所にて確認できます(実際の FailOver とマネジメントコンソールへの情報の反映には数分の時間差が発生することがあります)。 手順通り実施されている場合は、新しい Primary DB インスタンスが ap-northeast-1c 稼働しているはずです。

以上で RDS の動作確認は完了です。

終了

このラボでは、Amazon EC2、ELB、Amazon RDS を使用してマルチリージョンによる可用性の高いブログサイトにアーキテクチャを発展させました。

Lab2 Architecture

お疲れさまでした。これで Lab2b は終了です。 このラボで作成した環境は継続して利用するので、[ラボを終了] はクリックしないでください。

補足:WordPressアドレス、サイトアドレスの復旧手順

  1. Web Server01 に Session Manager でログインする。

  2. 次のコマンドで RDS に SQL 接続する。

    mysql -u wpuser -p -h [メモしてあるRDS DBインスタンスの"DBエンドポイント"を入力]
    
  3. Lab1 で設定した DB ユーザ"wpuser” のパスワードを入力 (手順通りの場合は、“wppassword” です)

  4. “ロードバランサーの DNS 名"を書き換えて、次の SQL コマンドを実行する。

    USE wordpress;
    
    SELECT * 
    FROM wp_options
    WHERE option_name = 'siteurl' or option_name = 'home';
    
    UPDATE wp_options 
    SET option_value = 'http://[メモしてある"ロードバランサー (WordPressLB)の DNS 名"を入力]/' 
    WHERE option_name = 'siteurl' or option_name = 'home';
    
  5. こちらをクリック して、もとの Task に戻る。

補足:WordPress の管理者用パスワードの復旧手順

  1. Web Server01 に Session Manager でログインする。

  2. 次のコマンドで RDS に接続する。

    mysql -u wpuser -p -h [メモしてあるRDS DBインスタンスの"DBエンドポイント"を入力]
    

    DB エンドポイントはお手元のメモを参照してください DB の password は手順通りに設定してある場合は wppassword です

  3. 次の SQL コマンドを実行する。

    SHOW databases;
    
    USE wordpress;
    
    SELECT user_login, user_pass 
    FROM wp_users;
    
    UPDATE wp_users 
    SET user_pass = md5('NEWPASSWORD') 
    WHERE user_login = 'admin';
    

    NEWPASSWORD の箇所を、任意の文字列に置き換えて下さい。

  4. こちらをクリック して、もとの Task に戻る。