OpsRamp

この記事はシリーズの3つ目の記事です！前回までの記事を未読の方はそちらを先に読んでいただくことを推奨します！ https://cloud.ebisuda.net/2022/02/21/azure-policy%e3%81%a7opsramp%e3%82%a8%e3%83%bc%e3%82%b8%e3%82%a7%e3%83%b3%e3%83%88%e3%82%92%e3%82%a4%e3%83%b3%e3%82%b9%e3%83%88%e3%83%bc%e3%83%ab%e3%81%99%e3%82%8b-%e3%81%9d%e3%81%ae%ef%bc%91-opsram/ https://cloud.ebisuda.net/2022/02/22/azure-policy%e3%81%a7opsramp%e3%82%a8%e3%83%bc%e3%82%b8%e3%82%a7%e3%83%b3%e3%83%88%e3%82%92%e3%82%a4%e3%83%b3%e3%82%b9%e3%83%88%e3%83%bc%e3%83%ab%e3%81%99%e3%82%8b-%e3%81%9d%e3%81%ae2-azure-policy/ では、前回まででAzure Policyを公開できていますのでそれを割り当てていきたいと思います。 ポリシーの割り当て では、テスト的にサブスクリプション全体に対してポリシーを割り当ててエージェントが入っているもの、入っていないものがきちんと可視化されることを確認します。 せっかくですのでAzure Arcのサーバーも対象可能とします。これでAzure内のVMのみならずどこにあるVMでも実機でも対象にすることができます。 修復タスクも実行可能なようにします。ポリシー割り当て自体がマネージドIDを持ち、その権限でVMを修正することになります。素敵な仕組みですね。 反映にはしばらく時間がかかりますので、待ちます。 しばらく時間を置くと、すでに展開済みのVMが準拠していないということが検出されました。 これで、OpsRampエージェントが入っていないVMをすぐに見つける事が可能となりました！とっても便利ですね。 次は、エージェントが入っていないVMに対して修復アクションを実行してエージェントをインストールすることができるようにしていきたいと思います！

この記事は前回の続きです。前回の記事を未読の方は前回の記事から読んでいただくことを推奨します！ https://cloud.ebisuda.net/2022/02/21/azure-policy%e3%81%a7opsramp%e3%82%a8%e3%83%bc%e3%82%b8%e3%82%a7%e3%83%b3%e3%83%88%e3%82%92%e3%82%a4%e3%83%b3%e3%82%b9%e3%83%88%e3%83%bc%e3%83%ab%e3%81%99%e3%82%8b-%e3%81%9d%e3%81%ae%ef%bc%91-opsram/ ゲスト構成用パッケージを作成する 前回までで動作確認できてますのでゲスト構成用パッケージを作成していきます。 まず、ゲスト構成用のモジュールをインストールします。 I n s t a l l - M o d u l e - N a m e G u e s t C o n f i g u r a t i o n 次に、ゲスト構成パッケージを作成します。 N e w - - - - - N C T F G a o y o u m n p r e e f e c s i e t ' g A C O u u o p r d n s a i f R t t i a i A g m o n u p n d r A S a g e t e t i n / o t I ` n I n P n s a s t c t a k a l a l l g l O e ' p s ` ` R a m p C l i e n t / l o c a l h o s t . m o f ' ` 作成に成功するとZipファイルが生成されます。 ...

以前、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専用ですから気にしなくていいのかもしれません。) まずモジュールをインストールします。 I # n s D t o a c l s l の - 記 M 事 o で d は u ス l コ e ー プ - 指 N 定 a は m 無 e い で P す S が D 、 s 私 c は R A e l s l o U u s r e c r e s s に 入 - れ S た c 方 o が p よ e い の A で l は l と U 思 s っ e て r い s ま す - V e r b o s e - F o r c e つぎに、PowerShellでConfigurationを定義します。Functionを定義するような感じですね。 ...

この記事はOpsRamp Advent Calendar 2021の12月16日の記事です。 このブログでOpsRampを扱うのは初めてです。ありがたいことにOpsRampさんから検証用ライセンスを支援いただきましたので環境を作りながらAdvent Calendarにも1日参加させていただきました。 私は現在Youtubeで企業でよくあるWindows/M365環境を構築してみるというシリーズを作成しています。AnsibleをつかってHyper-VでInfrastructure as Codeを実現していますので、コードによって自動的に生成されたVMが自動的にOpsRampから監視されるように構成してみたいと思います。 OpsRampのエージェントをAnsibleから管理する方法に関しては下記の記事に記載がありますので、この内容に沿って試してみます。 https://docs.opsramp.com/platform-features/agents/managing-agents-ansible/ 上記ドキュメントでは主にLinuxに関しての言及がなされています。ですが、私が今検証を進めている環境は今のところWindows Serverおよびそのうえで動いているWSL環境しか存在していません。Windows Server + WSLをAnsible環境として利用しつつ、Windows Serverを管理することができるのかどうか、ドキュメントの枠を超えて試してみたいと思います。 OpsRamp環境の初期セットアップ～手動でのエージェントインストール Ansibleでの検証に先立って、そもそものOpsRamp環境の初期セットアップを行い、試しに1台手動でエージェントを導入してみます。下記ドキュメントを参考にしながら作業を行いました。 https://jpdemopod2.docs.opsramp.com/ 管理ポータルにアクセスし…。 パスワードを変更し…。 Windows用のインストーラーをダウンロードし…。 インストーラーはネットワーク上の共有フォルダに配置しました。 監視対象には、ネットワーク上の共有フォルダから直接管理者として実行してエージェントをインストールしました。 「Undefined Resource」として見えてくることが確認できました。 モニターテンプレートを割り当てました。 Upの状態として認識されることを確認しました。 テスト的に監視対象を停止し、Downと検知されるところまで確認しました。 これで本当に基本的な部分のみですが、動作が確認できましたので、Ansibleを使ったエージェントインストールに進んでいきます。 Ansibleを使ったWindows ServerへのOpsRampエージェントインストール 管理者権限で実行すればエージェントがインストールされ、OpsRampからの監視を始めることのできるEXEファイルはOpsRampが用意してくれているわけですから単純にこのEXEファイルを実行させてインストールさせればよさそうです。 これを実現するにはwin_packageモジュールを利用すればよさそうです。 https://docs.ansible.com/ansible/latest/collections/ansible/windows/win_package_module.html パスとしては共有フォルダへのUNCパスもサポートしているので都合が良いです。 インストール済みかどうかの判定にはProduct_IDを利用するということですので、インストール済みのVMにてProduct_IDを確認します。 コンピューター\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall{5DD30F80-C9BD-429B-89CA-03C0578C77B4} 結果的に「5DD30F80-C9BD-429B-89CA-03C0578C77B4」がProduct_IDであるとわかりました。 - n a m w e i : n p P _ a r O p t o p a h d s c = u R k " c a a \ t m g \ _ p e \ I エ : \ d ー n = ジ e " ェ s 5 ン t D ト e D イ d 3 ン h 0 ス y F ト p 8 ー e 0 ル r - v C \ 9 \ B S D h - a 4 r 2 e 9 \ B \ - O 8 p 9 s C R A a - m 0 p 3 \ C \ 0 O 5 p 7 s 8 R C a 7 m 7 p B A 4 g " e n t - d e m o 0 0 1 . e x e " これをPlaybookに追加追記します。 ...