Kasoukatoka

ムスカリ(2024/4/7) 桜の花見に行ったとき、足元を見たらひっそりと咲いていました。 調べてみると、ムスカリは地中海原産の植物のようですが、日本でも野生化しており3月～5月に咲くようです。 本投稿はUAGをAWS上に構築するシリーズの第九回目の記事です。 今回は、UAGのイメージをAWSの仮想マシンイメージ(AMI)として利用可能なよう登録します。 なお、今回も全体像の掲載は割愛しています。 目次 UAGのVMDKイメージのアップロード UAGのVMDKイメージからAMIを登録 ■UAGのVMDKイメージのアップロード 最初にUAGのOVAイメージを7-zipのパワーシェルモジュールを用いて展開します。 サイズが大きいため、わたしのノートPCではすべての処理が完了するまで2-3分ほど待ちました。 展開が終わったら、展開したファイルの中の.vmdkファイルをS3バケットにアップロードします。 ■UAGのVMDKイメージからAMIを登録 S3にVMDKをアップロードしたら、次にVMDKをもとに仮想マシンのスナップショットを作成します。S3のVMDKをもとに仮想マシンのスナップショット（EC2スナップショット）を作成します。 VMDKからEC2スナップショットのインポートには少し時間がかかりますが、こちらもコマンドで確認ができます。 最終的にcompletedと表示されれば、完了です。 最後にEC2スナップショットからAMIイメージを作成します。 これで、ovaファイルをもとに、AWS上のAMIを作成することができました。あとはこのAMIをもとに、EC2インスタンスを作成するだけです。

桜(2024/4/7撮影) 先日花見に行った時に撮影した桜の接写です。 品種にもよりますが、桜は２週間前後で散ってしまうことが多いため、このポストを書いているときはすでに散って葉桜になっています。 本投稿はUAGをAWS上に構築するシリーズの第八回目の記事です。 今回は、UAGをAWSに展開するにあたって必要なAWSのロール（IAMロール）の構成をします。 なお、今回も全体像の掲載は割愛しています。 はじめにIAMロールの詳細な権限を記載したポリシーを変数に格納します。 ※ここでポリシーの中を見ると、vmimportYYYYMMDDとなっていますが、今回は既存のvmimportロールをもとに新しいIAMロールを作成する形になっているようで、最終的にYYYYMMDDを省いて定義する必要がありました。 次にそのポリシーをもとに、新しくIAMロールを作成します。 次に作成したロールに、対象となるS3バケットを限定するような役割を付加するポリシーを定義します。 定義後、再び作成したロールに適用します。 以上で、UAGの展開に必要なロールが作成できました。

桜と菜の花畑(2024/4/7) 市内を流れる川沿いの桜が満開を迎え、桜祭りが開催されていました。 出店も人もたくさん出て、そこかしこでお花見の宴会が開かれ、どこからともなく焼きそばやお好み焼きのにおいがして、さながら縁日のようでした。 本投稿はUAGをAWS上に構築するシリーズの第七回目の記事です。 今回は、UAGをAWSに展開するにあたって必要なPowerShellクライアントの構成をしていきます。 なお、今回も全体像の掲載は割愛しています。 ■目次 PowerShellモジュールのインストール アクセスキーの作成 アクセスキーをPowerShellで使えるようにする ■PowerShellモジュールのインストール 管理者権限でPowerShellを起動し、Install-Module -Name AWSPowerShell -Forceと入力して、AWS用のPowerShellモジュールをインストールします。 続いて、Install-Pachage 7Zip4PowerShellと入力して、UAGのOVAファイルを展開するための7Zipのモジュールをインストールします。 インストールが終わったら、Get-Packageでインストールしたモジュールが存在することを確認します。 次に、AWSマネジメントコンソール上でアクセスキーを作成します。 ■アクセスキーの作成 UAGをAWSにEC2インスタンスとして展開するときはデプロイのスクリプトを実行しますが、その際はAWSにPowerShellで接続できて、操作できる状態である必要があります。 UAGをAzureに展開する場合、ユーザー名/パスワードの認証を行う方式がメーカー公式マニュアルに記載されていますが、AWSはアクセスキーをあらかじめAWSマネジメントコンソールで作成しておいて、アクセス時のクレデンシャル情報として使用するようです。 アクセスキーは、AWSマネジメントコンソールにアクセスするユーザー単位で作成ていますが、そのユーザーが許可された操作であればなんでもできてしまうため、今回のような場合は使い終わったらできるだけ早く消す方がよさそうです（別の操作をしたいときに、再作成すれば事足りるので。。。）。 ちなみにこの記事を書くためのスクショを取得した後、アクセスキーはすぐ消しました。 Identity and...