AWS EC2で手軽に試すためのAMI製作

[uzulla]

目標

• AMIイメージを作成し、手軽にAWSEC2インスタンスとしてFc2blogを試せるようにする

概要

• (AWSのコンソールでEC2を独力で立てられる程度のスキルを前提)
  • たとえばセキュリティグループの設定など責務外
• 各種クレデンシャルは生成、必要ならsshログインして参照させたり、AWSコンソールなどから参照させる
• sshキーはAWSに登録しているものが自動的にインスタンスに設定されるのでOK
• ディストリビューションはUbuntu 20
• ミドルウェアはアップデートの都合からディストリビューションの標準を活用
• インスタンス内にLAMPを構築
  • RDSなどマネージドは使わない（スケールアウトも無し）
  • （バックアップしたいのであれば、スナップショットをつかってもらう）

課題

• httpsをどうするか？（httpのみでよいか？）
  • ドメインが確定していれば、Let'sEncryptまで組めるが
  • httpsが必要なら、CloudFrontでやってもらう（SSL ターミネーションする）？

工程

• AMIベースイメージ決定
• 半自動化されたセットアップ手段作成
  • ミドルウェアインストール・更新
  • ミドルウェア設定
  • fc2blog アプリデプロイ
  • 動作チェック
  • クレデンシャル初期化スクリプト（AMI作成直前の掃除）作成
  • 公開AMIにするため、cloud-initによるクレデンシャル生成など調整
• 一式をベースに手順書を作成
• (FC2様で)インスタンスを作成、上記を実行し、AMIを保存、公開する

以下、当初の内容です。想定と要件がズレがあったためにかわりましたが、memoのために残します

インフラ例

• レンタルサーバー
• VPS
• IaaS （AWS EC2など
• PaaS （Heroku、Elasticbeanstalk、ロリポップマネージドクラウドなど
• コンテナ(AWS ECS、k8s系など
• サーバレス (Lamba、 GAEなど

先に結論

「お試し」であれば可能だと思う、対応したいインフラを指定お教えください。
「プロダクション環境」については課題が多い、ご検討ください。

課題

アプリケーションコード（=blog自体）の更新は、アプリケーションの自動アップグレードの仕組みをつくれば可能（将来的なタスク）だが、運用はアプリケーションコードに完結しない。そこはどうするのか？（無視してよいのか？）

（現実として、WordPressなどでも実現ができていない）

• 各種クレデンシャルのsnake oil問題（一見信用できるが全く信用できない）

  • 「単にAMIを起動する」だけで動くようにすると、初期のクレデンシャルが安全でない。なんらかのトリックや「sshキーを作成して登録する」程度の知識が必要になる。

• ミドルウェアのバージョンアップについて（VPS、IaaSなど）

  • 「その時点で、安全に試してみる」だけならば、問題ない（それでよいのか？）
  • ディストリビューションのパッケージマネージャの自動更新でよしとして（してよいとはおもっていないが）も、EOLがある

• ストレージの永続性について

  • PaaS、サーバレス、コンテナ系はミドルウェアメンテが不要に近いが、通常永続的なローカルストレージが無い
  • 生成されるCSSやアップロードされる画像をどうするか
    • S3などオブジェクトストレージに保持するようにする？
    • EFS(NFS)などネットワークストレージをアタッチを必須とする？
    • DBにBlobで保存?

• 構築手順（作業者のスキル設定）難易度設定

  • 「FTPでアップロードしてファイルを修正」以上をさせることができるか？
  • 例：AnsibleやDeployerなどで既存サーバーに自動デプロイ
  • 例：CloudFormationやTeraformなどでクラウド環境を構築
  • (そこまでできるユーザーは、自前でできるのでは？)

• バックアップ・レストア

  • 機能の実装が必要かと思われる
  • サーバースペック（CPU連続実行時間制限、空きディスクスペース）によっては困難なこともある

• サポートは？

  • 「かんたんに構築できる」のはいいとして、なにかあったとき作業者がセルフで作業できるか？

踏まえた上で

• 安全は万全でなくても「試しに動かす」程度ならば、可能かと思う
• ボタンを押すだけで起動して「プロダクションレディ、永続運用可能」な物を提供することはむずかしい
• configを書いて、自動化スクリプトを手元で走らせるなどの難易度が許されるか？
  • コンフィグを生成する（あるいはオートメーションを実行する）外部サービスを別途作る？

どこまで実現したいか？ハードルをさげるか？の検討ができればと思います。

[fc2dev]

@uzulla
AWSでAMIイメージを作成しておき、EC2インスタンスとして起動できるようにすることを第一歩として捉えています。
優先度としては、アップデートの機能を整えた後で考えています。

クレデンシャル
AMIイメージであれば、初回起動時にクレデンシャル（パスワード）を生成し
システムコンソールに表示するか、値をAWSコンソール上に表示することで
比較的安全に初期のパスワードを通知することが可能です。
また、SSHの鍵についてはクラウド側で生成してサーバーに登録されていることを前提とします。

ミドルウェアの管理
ミドルウェアの管理は厳格に行うのであれば、
AnsibleやChefなど構成管理ツールを適用しておき、レシピも管理しておく必要はありますが、
当初はディストリビューションのパッケージマネージャーの自動更新で構わないと思います。

永続性
EBSを使うことを前提とし、オブジェクトストレージへの対応は今後していけば良いと考えます。
Mysqlも含めたオールインワンのAMIです。

構築手順
AMIからEC2インスタンスを作り、コンソールで表示されたIPアドレスへアクセスを行うことにより
OSS版FC2ブログの管理画面で設定を行い、利用を開始いただくことを考えています。

バックアップ
クラウドの機能としてスナップショットの取得が可能なため、クラウドに任せて良いと考えています。

サポート
利用者様同士で解決していただくのが原則となりますが、
サポート用のフォーラムを弊社内に用意することで検討をしています。

[uzulla]

@fc2dev

ありがとうございます、要件理解できました。

• とりあえず、Amazon EC2でのみ実現ができれば良いのは承知しました（後でISSUE本文も修正します）
• 優先順位は自動アップデートの後（なので、当分先）
• クレデンシャルについては空なら自動生成するような仕組みを考慮して実装したいと思います
• AMIの更新を考えると、簡単なAnsibleの整備はしたいと思います
• 永続は当座かんがえなくてよし、DBはEC2にMysql(MariaDB)をインストール承知しました。

細かい質問ですが、

• ミドルウェア周りについて、一般的なLAMPスタックでよろしいですか？
• Linuxのディストリビューションにこだわりはございますか？Amazon LinuxかUbuntuで考えておりますが、将来的な水平展開を考えると、Ubuntu（あるいはDebianでもよいですが）のほうに分がありそうです。
• AMIはある程度継続的に更新する想定はありますか？それともたまにご指示でスポット作業でつくって保存、となりますか？

[fc2dev]

@uzulla

・ミドルウェアは一般的なLAMPスタックで構いません。
・Linuxのディストリビューションについては弊社でもUbuntuを利用しているため、Ubuntuに揃えていただけると助かります。
今だともう20.04でも安定して動くと考えています。
・AMIの更新は大きな変更があったタイミングでスポット作業で依頼させていただくことを考えております。

[uzulla]

note

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/building-shared-amis.html
https://aws.amazon.com/jp/articles/how-to-share-and-use-public-amis-in-a-secure-manner/
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharing-amis.html
https://cloud-init.io/
https://www.insight-tec.com/tech-blog/20201216_aws_marketplace_ami/