Your system is not supported by certbot-auto anymore.
certbot-auto and its Certbot installation will no longer receive updates.
You will not receive any bug fixes including those fixing server compatibility
or security problems.
Please visit https://certbot.eff.org/ to check for other alternatives.

ちゃんと読んでなかったので､これは証明書変更ができない!!どうしようと焦っていました｡

いろいろ調べると､Certbot-autoの導入をGitHubからしているとこのメッセージがでるようです｡解決さくとしては､Snapdから取得しなさいということでした｡

このページをみながら､実施していたけど､2回目のInstalling snapdのところでエラー｡エラー内容は､https://people.canonical.com/~mvo/snapd/amazon-linux2/repo/aarch64がない｡｡｡うぅん?といろいろ調べているなか､このサーバをt4g.microで作ったことを思い出しました｡サーバ見てもない｡まだ､来ていないとのことか｡

ちょっとパッケージを他のものから持ってくればいいはずなんだけど､ちょっと沼っぽいので､証明書は今の所､新しいものが入っているので､このままで放置したいと思います｡

やったことは､ユーザからAWSのリソースを変更する権限を削除して､Roleに書き込み､Switch Roleするように変更しました｡

CLI実行のためAccess key接続をする､ユーザを作ろうと思っていました｡

CLIではEC2の起動停止をしたかったのですが､起動停止してよいかどうかをEC2のTagの設定を見て実施できるようにしたいと思いました｡その再EC2のタグを参照できるようにするため､ec2:DescribeInstancesの権限を与えないといけないことがわかりました｡この権限を与えてしまうと､EC2のインスタンスIDを知られてしまうので､この権限付きのAccess Key接続ユーザを作りたくないと思いました｡

なので､認証と認可をわけるため､認可部分であるRoleをユーザ認証から分離するようにしました｡

どうせやるなら､ということで､普段ログインしているアカウントにも実施しました｡私は､U2Fのデバイスでログインしているので､デバイスごとのユーザを作って､それぞれSwitch Roleするようにしました｡CFnで作成したので､これからはCFnで管理していこうと思っています｡

今日は久しぶりにEC2のメンテナンスでSSHしたのですが､何故か｡｡｡｡つながらない｡

そうです､Security Groupに登録しているIP Adressが変わったため､接続できませんでした｡ちょっとこのあたり､見直してみたいと思います｡

このサイトは2､3年前に作った以来､エラーもなく動作しているので､リファクタをしていなかったのですが､データベースの破壊とか､なにかあったときに備えて､コード化をしたいと思います｡

AWSのリソースはそれなりにCFnになっているので､そこから､AnsibleでWordpressまで作るところをやっていきたいと思います｡

調査といっても、作成するための手順は下記のページにあるので、そちらを参考にしてください。

https://level69.net/archives/26362

https://dev.classmethod.jp/articles/site_vpn_azure_aws/#toc-2

どちらのページも完成度が高く、両方参考にしながら、作成することができました。なので、手順は載せないのですが、それぞれのリソースの役割を記載してみようと思います。

AWS

Virtual Private Gateway : AWS側の接続設定
Customer Gateway : 接続先IPの管理
Site-to-Site VPN Connections : AWS側のIP、Pre-Shared keyの管理、接続先のRoute情報

Azure

仮想ネットワークゲートウェイ : Azure側の接続設定
ローカルネットワークゲートウェイ : 接続先のIPの管理
ローカルネットワークゲートウェイの接続 :接続先のPre-Shared key、接続先Route情報の管理

絵で表現すると下記の通り。

これを理解し、AWSの1つのVCPとAzureの二つのVnetを接続させることにも成功しました。イメージはこんな感じです。

うぅ、インフラって楽しい。

かねてよりやりたかったのですが、今までのサイトはt2インスタンスのまま使っていて、暗号化に耐えれるのかというところがあって先延ばしにしていました。この度、t4g.microにしたので、パフォーマンスもついてくるだろうと思って暗号化しました(S3に逃がしているのでメンテナンスだけなので、あまり使わないだろうという考えもあります)。

Let’s Encryptを使ったのですが、全然使い方が見えず、また、Amazon Linux2ではすんなり、プログラムが動かないという事もあって結構苦労しました。ちょっと落ち着いたら、再度作って見ながら、手順にまとめたいと思います。

この環境はAuthrizationはPassphreseをLambdaの中で実施しているので、近いうちにCogniteに変更する予定ですが、作るのに結構苦労したので、記載します。

Lambda関数の作成

Lambda用のIAM Roleを作成します。内容は下記のとおりで、最小権限の考えに乗って設定します。Logを書き出すための情報と、EC2を起動できるアクションをつけ、Resource でインスタンスIDを指定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "ec2:StartInstances"
            ],
            "Resource": [
                "arn:aws:logs:*:*:*",
                "arn:aws:ec2:*:*:instance/i-XXXXXXXXXXXXXXXXXXXX"
            ]
        }
    ]
}

Lambda作成の画面で、下記のように登録します。

Lambda関数にAPI名をしられてもパスフレーズがわからないと実行できないように、パスフレーズの確認をするようにし、ターゲットのインスタンスのインスタンスIDを設定し、デプロイします。

import boto3

def lambda_handler(event, context):
    if event['passphrase'] == "passphraseDayo":
        client = boto3.client('ec2')
        response = client.start_instances(
            InstanceIds=[
                'i-XXXXXXXXXXXXXXXXXXXX',
            ]
        )
    else:
        response = 'bad request'
    
    return response

Lambda単体動作するかテストします。テストをクリックして、書きを登録します。

{
“passphrase”: “passphraseDayo”
}

テストを実施すると下記のようにJsonファイルが返ってきます。

ちなみに、パスフレーズが正しくないと下記のようになります。

API Gatewayの作成

APIの作成では、REST APIで作成します。下記のように設定します。

ActionsからCreate Methodを選択し、現れたチェックボックスにGETを選択肢、をクリックします。その後、新しく右側にできたところのLambda Functionに先程作ったtestをいれ、作成します。

パーミッションの設定はOKをクリックし、詳細設定をしていきます。

まずは、GETのクエリストリングを受け付けるようにするため、Method Requestにクエリストリングの設定をします。param1という名前で受けれるようにします。

←Method Executionをクリックし、元に戻り、Integration Requestをクリックし、Mapping TEmplateに下記の設定をします。

←Method Executionをクリックし、元に戻り、testをリックします。Query Settingsにparam1=passphraseDayoを入れ、Testを実行します。

レスポンスにLambdaと同じようなJson形式の文字列が現れます。

実際にAPI Gatewayを利用するために、APIをデプロイします。「Actions」を選択し、Deploy APIをクリックします。デプロイでは、Deployment StageにNew Stageを選択し、Stage Name はメソッド名になるので、下記のように登録し、Deployします。

APIゲートウェイが作成されます。ここに現れるInvoke URLに対して、クエリストリングをつけて実行します。

今回の例では下記のようなURLになります。

https://82smxmuxte.execute-api.ap-northeast-1.amazonaws.com/launch-ec2?param1=passphraseDayo 

実行結果は下記のように、Lambdaの実行結果が返ってきます。

現在、API GatewayでPassphraseを設定し、Lambdaで確認しているのですが、この部分をCognitoに変更して実装してみたいと思います。

と、この投稿がmirai006.comに現れることでチェックします。

EC2のサイトを東京リージョンに持ってきたので、WordPressの動きが良くなってGood!

それに合わせてEC2のインスタンスをt4gに変更しています。WordPressで利用する、PHP、MariaDBともにARMのバージョンがあり、順調にサイトを持ってこれました。

これから、EC2からS3、S3からCloudFrontの設定をしていきます。

合わせてEC2をAPI　Gateway を通じて、起動できるようにLambdaを変更したいと思っています。

https://qiita.com/aki3061/items/3a3c5fca3c185173eda1

Cronには起動時に1度実行する@rebootという記述ができます。これで実行させます。今回は、ec2-userでCronを実行させるようにしました。

対象のLinuxサーバに接続し、Bashで以下のコマンドを実施します。

crontab -e

開いたテキストエディタで下記を追加します。

SHELL=/bin/bash

@reboot /home/ec2-user/manage/reboot.sh

このreboot.shに下記の一文を追加しています。

sudo yum update -y

また、以前に紹介した、コマンドをreboot.shに登録しています。

今回、Cronの実行をec2-userにしたかですが、作業によっては6時間で済まない更新があるかもしれません。そのとき、AtコマンドのatqでAtの状況を確認し、atrmでスケジュールを削除できるのですが、Rootで動かしているのと、ログインユーザであるec2-userから確認するとき、sudo atqなど確認する必要があり、わすれそうなので、ログインユーザで設定しました。