以前、AnsibleでのOpsRampエージェントインストールをやりましたが、今回はPowerShell DSCです。
将来的にOpsRampエージェントのインストールをAzure Policyを使って「管理下のVM(Azure上のVMでもオンプレのVMでもすべて)にはOpsRampエージェントをインストールし、その状態を保つ」ということを実現したく、今回はその前準備的な感じです。
DSC自体はマルチプラットフォーム対応ですが、まずはWindowsを対象に進めます。
OpsRampエージェントをhttpsでアクセスできる場所へに配置する
今回はMSI版をダウンロードして利用しようと思います。(※exe版でも同じです)
将来的にAzureからの管理を考えているので、インストーラーはAzure上のストレージアカウントに配置しておきます。
当初SASを生成して利用しようとしましたが、SASだとDSCからきちんとMSIパッケージだと認識してもらえなかったので、直接URLを指定してダウンロードできるように、匿名の読み取りアクセスを許可しました。
このとき、exeにしてしまうと、OpsRampのテナントに接続するための情報も含まれてしまうのでこのやり方をするならMSIパッケージの方が良いですね。
手元のWindowsPCにDSCを適用する
ここから先はPowerShellコンソールで操作をします。Windows PowerShellではなくPowerShell Coreでやった方がいいのではと思います。(※これはよくわかっていません。将来的にAzure Policyでマルチプラットフォームを見越しているので、おそらく。でも今回はインストーラーがWindows専用ですから気にしなくていいのかもしれません。)
まずモジュールをインストールします。
つぎに、PowerShellでConfigurationを定義します。Functionを定義するような感じですね。
私はこんな感じで書きました。いくつかポイントがあります。
「Import-DscResource -ModuleName PSDscResources -ModuleVersion 2.12.0.0」の部分はあえてモジュールのバージョンを指定しています。前回の記事でモジュールの扱いで混乱したことについて書きましたが、私の環境では手動でモジュールを別の場所にコピーする必要があり、そうすると複数のモジュールがあるのでバージョンまで指定しないときちんとモジュールを読み込めなくなりました。
使っているパッケージはMsiPackageです。当初はMsiPackageではなくPackageを使っていたのですが、これはAzure Policyで利用することがサポートされていないのだそうです。なので、MsiPackageを使うようにしています。
Pathは記事冒頭で紹介したAzure上のblobストレージを指しています。SASではだめだったのは前述のとおり。(URLの最後が拡張子でないといけない？)
ProductIdは一度インストールして調べるなり、一度適当な値を入れて後の手順を進めると「ProductIdが違うぞ！」ってエラーが出るので、それでわかります。
ArgumentsはOpsRampのエージェントのダウンロードの隣にある「Instruction」から文字列を入手可能です。WRAPPED_ARGUMENTS以降をコピーすればOKです。
これで、configuratoinが定義できました。
次に、configurationドキュメントを作成します。これももちろんPowerShellコマンドです。
これで、InstallOpsRampClientフォルダ内にlocalhost.mofというファイルが生成されます。
では、手元のWindows PCに適用していきます。
この時に、私の環境では下記のエラーが出てしまいました。
なぜかモジュールが見つかりませんので、見つかるところにコピーしてあげます。私の場合には「C:\Program Files\PowerShell\Modules\PSDscResources」を「C:\Program Files\WindowsPowerShell\Modules\PSDscResources」にコピーすることで問題回避できました。
これで適用がなされます。OpsRampの管理コンソールで接続がなされていることも確認できます。
PowerShell DSC的な状態は下記コマンドで確認することができます。
これでまずはPowerShell DSCとしてOpsRampエージェントを導入することが可能となりました。
次回はAzure Policy用のゲスト構成パッケージを作成していく予定です！