概要
当エントリーではHyperglance製品を自身のAWS検証アカウントに導入し、その時の手順を自分へのメモも兼ねて情報として残します。
オフィシャル手順は以下となるので、実際にやる際はこちらを参照するようご注意ください。
- 概要
- Hyperglanceとは
- 0.対象AWS アカウントにログインしておく
- 1.Get Started
- 2.Choose Your Plan
- 3.AWS Marketplace で Subscribeする
- 4.AWS Marketplace関連のEmail受信を確認する
- 5. AWS Cloud Formation にて Launch
- 6.必要事項の入力
- 7.スタックの作成
- 8. (任意)指定通りEC2インスタンスが起動した事を確認する
- 9. Clientからアクセスしてみる
- 10. 管理画面にてログインする
- おまけ
- まとめ
- 関連エントリー
Hyperglanceとは
一言でいうとマルチクラウドの統合管理コンソールのような製品です。
AWSを利用する場合は、AWS Marketplaceで用意されており、デプロイしてすぐにブラウザ経由で利用する事が可能です。(これからお見せします)
製品オフィシャルHP
参考blog
製品概要を日本語でまとめてみた以下blogエントリーがあるので、どのような製品かについて先に把握したい場合はこちらをご参照ください。
https://blog.serverworks.co.jp/entry/Kav3BiRMppDXg3TBjOGFp0cDpTQblog.serverworks.co.jp
0.対象AWS アカウントにログインしておく
AWSでトライアルの場合は、AWS Marketplaceからスタートする必要があるので 別タブ等で対象AWSアカウントの好ましいユーザーでサインインしておきます。
1.Get Started
Hyperglanceオフィシャルページ右上の [Get Started]を押下した画面にて [Choose AWS] を押下
2.Choose Your Plan
利用するプランを選択して、[Start Free Trial]を押下
こちらのプランは今回導入してお試しする環境のリソース数を考えて選択する必要があります。
折角の14日間無料トライアルなので、導入対象として複数のクラウドアカウントを用意することをオススメします。
自分の場合は、検証環境3つなのと今回はリソースがオーバーした際の挙動も見たかったので Up to 250 resources としました。
3.AWS Marketplace で Subscribeする
内容を確認して問題なければ [Continue to Subscribe]を押下
4.AWS Marketplace関連のEmail受信を確認する
Subscribeを実行した対象AWSアカウントとして登録しているEmailアドレス宛に、以下2通のEmailを受信した事を確認
- From: 対象AWSアカウントとして登録しているEmailアドレス
- Subject: Your AWS Marketplace product: Hyperglance - up to 250 Resources
- Subject: Thank you for subscribing to Hyperglance - up to 250 Resources on AWS Marketplace
対象AWSアカウントのAWS Marketplaceで確認
Subscriptionの項目として表示される事を確認
5. AWS Cloud Formation にて Launch
Choose Action で Launch Cloudformation を選択して [Launch]を押下
6.必要事項の入力
※AWS CloudFormation の基礎的な細かい画面は割愛
AWS CloudFormation の画面に遷移するので必要事項を入力
以下が簡単な内容となりますが、必要事項となります。
一言でいうと「Hypeglanceサーバーの設置先として好ましい設定のVPCを事前に準備してください」です。
| No | 項目(*がある項目は必須) | 指定すべき値 | 備考 |
|---|---|---|---|
| 1 | インスタンスサイズ | メーカー推奨サイズ+α | 本番での用途によっては必要に応じて+αを検討 |
| 2 | SSHキーペア | 利用するキーペア | 事前に作成してプルダウンから指定する必要あり |
| 3 | ブラウザからHyperglanceへ接続を許可するレンジ | 絞る場合はそのCIDRを指定 | 絞らない場合は0.0.0.0/0と入力。後にSecurityGroupとして編集可能 |
| 4 | SSHで管理アクセスを許可するレンジ | 絞る場合はそのCIDRを指定 | (非推奨)絞らない場合は0.0.0.0/0と入力。後にSecurityGroupとして編集可能 |
| 5 | パブリックIPアドレスをアサインするか否か | True or False | AWS経由でインターネット向けに公開する場合はTrue |
| 6 | 静的プライベートIPをアサインするか否か | True or False | 静的に割り当てる社内ルールなり拘りがある場合はTrue |
| 7 | 静的プライベートIPをアサインしたい場合の指定値 | 未使用かつ有効なプライベートIPアドレス | |
| 8 | デプロイ先のVPCの指定 | 設置先として好ましいVPC | プルダウンから選択 |
| 9 | デプロイ先のサブネットの指定 | 設置先として好ましいサブネット | プルダウンから選択 |
管理アクセスとしてはSSHを利用しない構成も可能なようにも思えるのですが、執筆時点では必須となっているのでキーペアの作成が必要です。(製品内部として必要な可能性もあるので細かくは触れません)
7.スタックの作成
実行すると大した量ではないので数分程度で処理が完了しました。
リソースとしては以下が作成されます。(環境の管理者であれば把握しておきましょう)
8. (任意)指定通りEC2インスタンスが起動した事を確認する
必要に応じて、対象EC2インスタンスが 2/2チェックを通って正常起動している事、指定したVPCなりネットワーク経路に問題がない事やらSSHのアクセスについてもこのタイミングで確認
ちなみにOSとしては、Amazon Linux2なので IAMロールさえ設定すれば SessionManager経由でログイン可能です。
当該EC2インスタンスには以下IAMロールが付与された状態で起動してくる為、こちらに許可ポリシーを個別に追加する形となります。
IAMRole: Hyperglance250-HGRole-XXXXXXXXXXXX
何も制御をしないのであれば、AmazonSSMManagedInstanceCore のIAMポリシーを追加するだけで接続可能となります。
sh-4.2$ sh-4.2$ bash [ssm-user@ip-172-31-0-59 bin]$ uname -a Linux ip-172-31-0-59.ap-northeast-1.compute.internal 4.14.256-197.484.amzn2.x86_64 #1 SMP Tue Nov 30 00:17:50 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux [ssm-user@ip-172-31-0-59 bin]$ [ssm-user@ip-172-31-0-59 bin]$ cat /etc/system-release Amazon Linux release 2 (Karoo) [ssm-user@ip-172-31-0-59 bin]$
9. Clientからアクセスしてみる
今回は、PublicサブネットにてPublic IPアドレスを付与する設定をしたので、ブラウザから以下のようなURIにアクセスすればインターネット経由で接続できます
https://割り当てられたPublic IPアドレス
Private指定環境であれば好ましいネットワーク経由からPrivate IPアドレスで接続してください。
デフォルトでは、Hyperglanceの自己証明書が設定されており個別配布でもしない限りブラウザで警告が出る状態となっていますので、別途ドメイン設定およびTLS証明書の設定は個別に必要となります。
以下がオフィシャルのTLS証明書の設定手順となります。
本番利用の際には事前に確認して準備しておくと良いでしょう。
10. 管理画面にてログインする
以下手順のドキュメントに記載がある通り
- You can now see, and log in to, the Hyperglance console. The default userid is ‘admin’ and the password is the Hyperglance instance-id.
初期ユーザー/パスワードは admin / インスタンスID として設定されているので接続します。
(当然ですが、接続確認直後に初期パスワードはセキュアなものに設定しましょう)
ログインができたら導入作業は完了です。
お疲れ様でした。
おまけ
ついでに、導入時に気になったので調べたことを"おまけ"として記載します。
Amazon Elastic Block Store (EBS)について
EBSの構成がどうなっているのかについてですが
250リソースライセンスのデフォルト(t3.medium)だと、10GiBのgp2のEBSが2つアタッチされる形となっていました。
OS内で確認すると / と /var/lib/data とで分けているようです。
[ssm-user@ip-172-31-0-59 dev]$ ls -l /dev/ |egrep 'xvda|xvdf' lrwxrwxrwx 1 root root 7 Mar 7 23:24 xvda -> nvme0n1 lrwxrwxrwx 1 root root 9 Mar 7 23:24 xvda1 -> nvme0n1p1 lrwxrwxrwx 1 root root 11 Mar 7 23:24 xvda128 -> nvme0n1p128 lrwxrwxrwx 1 root root 7 Mar 7 23:24 xvdf -> nvme1n1 [ssm-user@ip-172-31-0-59 dev]$
[ssm-user@ip-172-31-0-59 bin]$ sudo fdisk -l Disk /dev/nvme1n1: 10 GiB, 10737418240 bytes, 20971520 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/nvme0n1: 10 GiB, 10737418240 bytes, 20971520 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 5207983C-BCF2-4AA8-867E-3FE59C8F68DD Device Start End Sectors Size Type /dev/nvme0n1p1 4096 20971486 20967391 10G Linux filesystem /dev/nvme0n1p128 2048 4095 2048 1M BIOS boot Partition table entries are not in disk order. [ssm-user@ip-172-31-0-59 bin]$
[ssm-user@ip-172-31-0-59 bin]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme1n1 259:0 0 10G 0 disk /var/lib/data nvme0n1 259:1 0 10G 0 disk ├─nvme0n1p1 259:2 0 10G 0 part / └─nvme0n1p128 259:3 0 1M 0 part [ssm-user@ip-172-31-0-59 bin]$
[ssm-user@ip-172-31-0-59 bin]$ df -hT Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 1.9G 0 1.9G 0% /dev tmpfs tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs tmpfs 1.9G 604K 1.9G 1% /run tmpfs tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/nvme0n1p1 xfs 10G 7.1G 3.0G 71% / /dev/nvme1n1 xfs 10G 926M 9.1G 10% /var/lib/data [ssm-user@ip-172-31-0-59 bin]$
/var/lib/data にはWebサーバーやらDBやらアプリケーション本体やらとログが格納される模様です。
[ssm-user@ip-172-31-0-59 ~]$ ls -l /var/lib/data/ total 0 drwxr-xr-x 4 root root 31 Jan 28 20:22 httpd drwx------ 5 ec2-user ec2-user 102 Jan 28 20:22 hyperglance drwxr-xr-x 4 root root 34 Jan 28 20:22 log drwxr-xr-x 4 postgres postgres 33 Jan 28 20:21 postgresql [ssm-user@ip-172-31-0-59 ~]$
EC2インスタンスが停止した場合のクライアント視点での挙動
EC2インスタンスを停止した場合の挙動について確認してみました。
ユーザーがHyperglance製品画面にて操作中の場合は、正常に描画がされなくなり、右上にERRORのポップアップが表示されるようです。
EC2インスタンスを停止した状態で新規でアクセスを試みたところChromeの場合、以下のような画面でタイムアウトしました。
バックアップはどう考えるべきか
製品としてバックアップ機能を有している訳ではなく、インフラ側の責任で実施を検討する必要があります。
製品内で設定した内容(特に細かいAutomation設定の作り込み等)は、すべてローカルのEBSにある形となるので、それを踏まえ取得頻度やら保管世代やらを設計して定期的なバックアップ取得は実施したほうが無難です。(EBS自体が小さいのでコストもそこまで気にしなくて良いですし)
こちらのガイドの backup の項目に記載がありますが 一般的なAMI取得やAWS Backup 等を使ってユーザー側で実施を検討する必要があります。
同ページの Recoveryの項目では以下のような設計がオススメされています。
- RTO:1hour
- RPO:24hours
トラブル時の一次対応について
AWSインフラや製品側でなんらかの問題があり正常利用出来なくなった場合の一次対応としては
Emergency Maintenance の項目に記載がありますが、原則として EC2インスタンスの停止/起動の対応だけで十分である と記載があります。
当オペレーションのみで通常は製品を動作させているDockerコンテナが再起動してくる形となります。
その他、細かいトラブルについてここでは記載はしませんが、Troubleshooting 項目に記載がありますので、システム管理者であれば内容を把握して有事に備えておきましょう。
まとめ
AWSを利用する場合の導入手順について記載してみましたが、作業自体はとても簡単でした。 気軽に導入出来るんやで〜といったイメージが伝われば幸いです。
次回は、ログイン後の製品操作画面についてご紹介予定です。
