2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

現実世界を動かす技術をシェアしよう！～身近なものづくりから最先端テクノロジーまで大募集！～
@hidekko(hideaki koga)

【みんな大好き】AWSのCloudWatchでログインの必要なサイトの正常性を監視する01【App Service】

2
Posted at

皆様おはようございます。
今回あるお客様から、IT基盤の運用をある程度自動化したい、とご相談を受けたので、これを簡単に実装していきたいと思います。
今回の自動化対象はWebサイトの正常性監視で、ログイン行為をオペレーターの方が一定期間ごとに手動で実施している、という内容だったので、サイト監視機能を用いて実装します。
また今回の構成は外部から公開サイトの正常性監視という位置づけなので外形監視にあたります。

構成図

diagram01.png
今回はAWS CloudWatch Synthetics Canaryを使ってWebアプリやWebサイトの正常性監視を行います。
以降本記事では、WebアプリやWebサイトをまとめてWebサービスと呼びます。
AWS上にWebサービスを構築しても良かったのですが、AWS上に構築したWebサービスをAWSの機能で監視するとAWSでしか通用しない監視体制になってしまう(AWSバックボーンネットワークを経由した死活監視など)可能性を排除するため、Webサービス側はあえてAzure上に構築しました。

本記事ではまずは以下の赤枠内Azure上のApp ServiceにログインできるWebサービスを構築します。
image.png

環境構築

では早速環境構築を行いましょう。

Webサービス(App Service)側

Azure Portalログイン

https://portal.azure.com
にアクセスしログインします。
[すべてのサービス]をクリックします。
image.png

App Service デプロイ

画面上部の[サービスフィルター]に[App Service]と入力するとサービスが絞られます。
検索後最上位にお目当ての[App Service]が出てきますのでクリックします。
image.png

当たり前ですが何もないので画面上段の[作成]をクリックし[Webアプリ]をクリックします。
本来はログインユーザーを管理するDBもあっても良いかなと思いますが、今回Webサービス側のDBの有無は本論でなないのでDB構築はスキップします。
お金もかかりますしね。
image.png

こんな感じでやいのやいの設定項目入れましょうと出てくるので上から順に行きましょう。
image.png

まずは適当に[リソースグループ名]を決めて
image.png

以下設定項目が多いのでリストにします。

項目名 設定値 備考
名前 test-webapp01 インターネット上でユニークになるようにAzure側で調整してくれます。
公開 コード [公開]という翻訳がイケてないですね。コードかコンテナかという選択肢なので今回はコードを選びます。
ランタイムスタック PHP 8.5 たぶんお試しWebサービスの実装が一番簡便であろうPHPの最新版を選びますが、お得意なコードがある場合はお好きに選択してください。
オペレーティングシステム Linux こちらはコードでPHPを選ぶと自動選択されます。
リージョン Southeast Asia(東南アジア) 日本から近くて安いリージョンです。
価格プラン Free F1 1日60分しか使えませんが無料のプランです。1サブスクリプションあたり1つしかデプロイできません。

他のパラメーターはもう必要ないので[確認および作成]をクリックします。
image.png

[作成]をクリックします。
image.png

デプロイは一瞬で済みました。

カスタムドメイン設定01

念のためカスタムドメインを設定します。

[設定]から[カスタムドメイン]を選択します。
image.png

[カスタムドメインの追加]をクリックします。
以降はまたリスト形式にします。

項目名 設定値 備考
ドメインプロバイダー その他のすべてのドメインサービス ドメイン名をDNSレコード設定できる場合はこちらを選びます。
ドメイン 任意のドメイン名を入力 こちらは任意で大丈夫です。
ホスト名レコードの種類 CNAME こちらはApp ServiceなのでCNAMEがおすすめです。

ここまで入力し出てきたした二つのCNAMEレコードとTXTレコードをDNSレコードに登録します。
image.png

以降、DNS設定はそのまま置いておきましょう。
閉じてしまっても再度続きから設定は可能です。

DNS設定

CNAME

まずはCNAMEから設定していきます。
Azure DNSでDNSをホストしている場合は以下のように設定します。

項目名 設定値 備考
ホスト test-webapp01 サブドメイン名を入力します。
種類 CNAME 先のApp Serviceの設定で指定されたようにCNAMEを選択します。
値 先のApp Serviceの設定で出力された値をコピーします。 先のApp Serviceの設定で出力された値をコピーします。

最後に[保存]をクリックします。
image.png

TXTレコード

こちらもCNAMEと同じです。

項目名 設定値 備考
ホスト asuid.test-webapp01 先のApp Serviceの設定で出力された値をコピーします。
種類 TXT 先のApp Serviceの設定で指定されたようにTXTを選択します。
値 先のApp Serviceの設定で出力された値をコピーします。 先のApp Serviceの設定で出力された値をコピーします。

最後に[保存]をクリックします。
image.png

カスタムドメイン設定02

カスタムドメイン設定01の設定を閉じずにおいていれば、最後の[検証]をクリックします。
image.png

無事検証が終われば[追加]をクリックします。
image.png

[バインドの追加]をクリックします。
image.png

[検証]をクリックします。
image.png

[状態]に緑色のチェックマークがついたらこの作業は[キャンセル]を押して終了です。
image.png

カスタムドメインの状態が[セキュリティ保護付き]になります。
image.png

設定したカスタムドメインでアクセスして以下のような画面が出れば設定は完了です。
image.png

Webサービス(アプリ)設定

作成したWebサイトにSSHでアクセスし、PHPファイルを配置していきます。
Azure Portal内の[開発ツール]から[SSH]を選択します。
image.png
[移動]をクリックします。
image.png
/home/site/wwwrootという場所にhtmlファイルが置いてあり、ログイン後のカレントディレクトリは/homeという構成になっています。
image.png
試しにhostingstart.htmlをリネームして同名で適当なファイルを置いて先のApp Serviceのサイトが変化するか見てみましょう。
いったん切り戻しを考慮して以下のようにコマンドを書いてみましょう。

site_change.sh
mv site/wwwroot/hostingstart.html site/wwwroot/hostingstart.html_org
echo "test site" > site/wwwroot/hostingstart.html

実際にコマンドを実行してみると以下のようになります。
エラーは出ませんでしたね。
image.png
試しにアクセスしてみるとちゃんと変わってますね。
image.png

PHPファイルの配置

以下のPHPファイルを配置します。
まずはログイン用のページから。

login.php
<?php
session_start();

$error = "";

if ($_SERVER["REQUEST_METHOD"] === "POST") {

    $username = $_POST["username"] ?? "";
    $password = $_POST["password"] ?? "";

    // 固定ID/PW
    $valid_user = "admin";
    $valid_pass = "P@ssw0rd0123";

    if ($username === $valid_user && $password === $valid_pass) {

        $_SESSION["logged_in"] = true;
        $_SESSION["username"] = $username;

        header("Location: dashboard.php");
        exit;

    } else {
        $error = "ログインに失敗しました";
    }
}
?>

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Login</title>
</head>
<body>

<h1>Login</h1>

<?php if ($error): ?>
<p style="color:red;">
    <?php echo htmlspecialchars($error, ENT_QUOTES, 'UTF-8'); ?>
</p>
<?php endif; ?>

<form method="POST" action="login.php">

    <label>User Name:</label><br>
    <input type="text" name="username"><br><br>

    <label>Password:</label><br>
    <input type="password" name="password"><br><br>

    <button type="submit">Login</button>

</form>

</body>
</html>

注意事項としては、今回は検証用サイトなのでこのログイン用のPHPファイルにログインIDとパスワードを直接記載していることですね。

次にログイン後のページです。

dashboard.php
<?php
session_start();

// 未ログインならlogin.phpへ
if (!isset($_SESSION["logged_in"]) || $_SESSION["logged_in"] !== true) {

    header("Location: login.php");
    exit;
}

$username = $_SESSION["username"];
?>

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Dashboard</title>
</head>
<body>

<h1>Dashboard</h1>

<p>
    Welcome,
    <?php echo htmlspecialchars($username, ENT_QUOTES, 'UTF-8'); ?>
</p>

<p id="login-success">
    ログイン成功
</p>

<a href="logout.php">Logout</a>

</body>
</html>

ポイントとしては2つあります。
1つ目
サイトにsession_start();というログインセッション確認用のコードがあることです。
これでログインしているセッションかどうか確認しています。
ログイン後のページなので必須のパラメーターです。
2つ目
<p id="login-success">です。
サイトの構成次第ですが、今回はログイン成功を正確に読み取るためphpファイルの中にidを埋め込みました。

次にログアウト時のページです。

logout.php
<?php
session_start();

session_unset();
session_destroy();

header("Location: login.php");
exit;
?>

ポイントとしてはこちらも最初にセッション確認のコードがあり、ログアウトのページなのでsession_unset()とsession_destroy()とがあります。

試しにアクセスしてみましょう。
image.png
更に試しにログインしてみると
image.png

はい。
問題なさそうですね。

監視基盤構築まで進めてしまいたかったですが思ったよりも長くなってしまったので本日はここまで。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?