Azure

Announcing the Public Preview of AVD Insights at Scale https://techcommunity.microsoft.com/t5/azure-virtual-desktop-blog/announcing-the-public-preview-of-avd-insights-at-scale/ba-p/3685387 AVD Insitesで複数のホストプールをまとめてみられる機能がパブリックプレビューで登場しています。特に何もしなくても使えるようです。便利になりますね。

Announcing general availability of support for Azure availability zones in the host pool deployment https://techcommunity.microsoft.com/t5/azure-virtual-desktop-blog/announcing-general-availability-of-support-for-azure/ba-p/3636262Azure Virtual Desktop のホストプール展開のアベイラビリティゾーン対応がGAになってますね。 可用性が高まって良いことです。

毎週土曜日に一週間分のAzure更新情報を簡単にさらっと確認するという内容でYouTube の動画を更新してます。 https://youtu.be/BItLUJiTJ4w 今週は個人的に1番気になったのは下記のプレビューです。 https://azure.microsoft.com/ja-jp/updates/public-preview-azure-arc-enabled-azure-container-apps/ Azure Arcで接続、管理したオンプレや他クラウドのKubernetesサーバーでAzure Container Appsを動かせるという話ですね。とてもハイブリッドな感じで素敵です。 まだマネージドIDには対応していないようですが対応してくれるのも時間の問題でしょう。おそらく。

現在業務でAzureをプラットフォームにしたシステムの開発をしています。.netのコードがありそれがAzure functionsに展開されて動いている感じです。「何を作るか」「どうやって作るか」などかなりの部分を私がコントロール可能な状況にさせてもらってるので、色々とやりたいことが実現出来て素敵な感じです。 そんな中、アプリ開発はチームメンバーに任せて、私は主にインフラ周りのコードなどを書いてます。これまで個人でボッチ開発しかまともにしたことが無かったのでgitでbranchの扱いとか、commit履歴のコントロールとか色々と勉強になっております。 そして、開発基盤にAzure DevOpsを使っております。GitレポジトリもAzure Repos, パイプラインもAzure Pipelinesを使っています。 そこで、PullRequestの生成をトリガーに完全に独立した環境を構築してそこで事前確認ができる環境を作ってみました。レポジトリが1つなら簡単だったのですが、アプリケーションのレポジトリとインフラ展開のレポジトリを分割している状況であまり直接的な例が見つけられずかなり苦労してしまいました。多分丸4日くらいかかりました…。 次回以降簡単に実装できるように記録しておきたいと思います。 なお、私はまだまともなAzure Pipelines歴は3ヶ月くらいなので効率的じゃない部分多いかと思います。アドバイスありましたらコメントいただけると嬉しいです。 レポジトリ構成 AppRepo - .netのアプリケーションのコードが書かれている- InfraRepo - インフラ展開周りのコードが書かれている できるようにしたこと アプリもインフラも更新があったら最新のコードでメインの環境が更新される- アプリもインフラもPullRequestがあったらPullRequestに対応した独立環境が作成される。PullRequestに使われたBranchに更新があったらその更新も反映される。これによりmainブランチにマージする前にAzureの環境上で実際の動作を確認できる。 もうちょっと詳しいできるようにしたこと AppRepoのmainレポジトリに更新があったら自動でビルド&テスト。ビルド&テストがOKなら最新のインフラのコードとともにメイン環境に展開(更新)。- InfraRepoのmainレポジトリに更新があったら自動で最新のアプリのビルドとともにメイン環境に展開(更新)。- AppRepoにPullRequestがあったらPullRequestのbranchの最新のアプリのコードで自動でビルド&テスト。ビルド&テストがOKなら最新のインフラのコードとともにPullRequestのIDから作成した新規のリソースグループに最新のインフラのコードとともに展開(新規作成)。- PullRequestのbranchに更新があったらその最新のコードで自動で自動でビルド&テスト。ビルド&テストがOKなら最新のインフラのコードとともにPullRequestのIDから作成したリソースグループの環境をインフラもアプリも更新(更新)。- InfraRepoにPullRequestがあったらPullReqestのbranchの最新のインフラのコードでPullRequestのIDから作成した新規のリソースグループにmainブランチの最新のアプリのコードとともに展開(新規作成)。 実装アイデアおよび苦労した点 PipelineはAppRepoにパイプライン1つ、InfraRepoにパイプライン1つという形で実装しました。ほかにも良いやり方がある気がしましたが、色々と悩んだ末…。- Pipelineが起動された時、特にインフラ側のPipelineが起動された時にそれがどういうパターンで起動されたのかを判別させる部分で苦労しました。下記4パターンがあります。具体的な判別のさせ方はPipelineの中身のコードの方で解説します。1. AppRepoのPipelineが直接起動されたか、mainブランチの更新で起動されてビルドに成功した結果としてInfraRepoのパイプラインが起動された場合- 2. AppRepoのPipelineがPullRequestで起動された結果ビルドに成功し、その結果としてInfraRepoのパイプラインが起動された場合- 3. InfraRepoのパイプラインが直接あるいはmainブランチの更新によって起動された場合- 4. InfraRepoのパイプラインがPullRequestにより起動された場合- Azure PipelinesのPipeline間で情報を連携する良い方法がわからなくて苦労しました。結局ビルド結果やほかの方法での受け渡し方がわからなかったのでPullRequestのIDを書いたテキストも一緒にZipで固めてArtifactsとして発行し、インフラ展開側のPipelineでダウンロードして利用しました。(※PullRequestIDの受け渡しはもっと良い方法が明らかにある気がしています。) 具体的なやり方 AppRepoのPipeline n t v s a r a t m i b b p r - e - - # - - # - e g a r a i p : g t a i - t e a n v s t d i t d i P s c t d i 発 p d a e c n n h x b a a : a i n a i n u c o a i n 行 u i r $ r h c c m s c - l m l s s p c p a s s p c p a l r n s s p r i a a r b s t ( : : h l a : l e e u k p u o r r k p u o r r l i d k p u o n r r e l p i D e u i u R s : e : l t m o g : l t m o g R p i : l t o c c c p i l f a t s d n d E : : a s m j u a s m j u e t t a s t l h h l s a a t r : e e A v D y : a e m D y : a e m q : i A y : F u i i a h y c e u : : D m " o N n c e o N n c e u o r N o d v v c : N t : e M I w t a d t n t a d t n e e n c a l e e e e a : y E m i N m : s t N m : s t s c : h m d R T F E $ m y . a n e e : s e e : s t h i e e o y i x ( e d y m g d t : " : t : ' : I o e v : r o p l i B : r y d e o C b C t D q e O t e e s u o M w o B u o T e も " ( F " r F : : t i C p M s r u i r e s 保 $ v i A F o i l r d - e i l o e s t - 存 ( a l r i l z $ n d e d l C l d u C t ' * c し s r e c l d i ( g . a ) a L d " . t L T o て y i s h e e p B A A t . t I c p I e n お s a @ i : r u r r e $ e @ a s u @ s f く t b 2 v : i c t ( s 2 n p t 2 t i e l e " l h i f R t d r . g m e $ f d i f u e " o $ c u . s F ( a . v a n v R j ( s r p [ i S l A e c c : e ' S p a u ' l y s r : t t r s y r t l B e s e t S i ) t s o i l u s t i t t o o t j o R i " e f r a n r e ' n e l m a u g e m q d . c e i a . R u . D t n p D e e R e S g p e l s e f t D f e t a a a i a a a . s u g r r u s p o l i e t l e u n t n c i t ' l ' W g t f W l ] o D o a o R , r i r c r e k r y t k q ' i e ) i u P n c / n e u g t $ g s l D o ( D t l i r B i I R r y u r d e e ) i e ) q c / l c " u t $ d t e o ( . o > s r B B r t y u u y $ ' ) i i ) ( ) / l l / S p d d p y u . I u s b B d b t l u ) l e i i . i m s l z s . h d i h D _ I p _ e o d o f u ) u a t . t u p z p l u i u t t p t W " o r - k c i o n n g f D i i g r u e r c a t t o i r o y n ) / R p e u l b e l a i s s e h _ o u t p u t / p u l l r e q u e s t I D . t x t ほとんど素直にビルド、テストしたうえでArtifactを発行しているだけですが下記の部分で「PullRequestで起動された場合にはPullRequestのIDをpullrequestID.txtというテキストファイルに書いて一緒に発行されるようにしています。 ...

自分のYoutubeチャンネルにアップロードした動画も283(2022/2/28時点)となりました。全く日の目を見られない動画も多数…。 動画を掘り起こして適切な人の目に触れさせることはYoutube自身がやってくれているので私が何かしても別に意味はない…のではありますが、せっかくなので自分のTwitterのフォロワー向けに定期的に紹介することをしたいなと思いました。 そこで、Azure Functionsのタイマートリガーで定期的に下記の処理を実行させることにしてみました。 Youtubeの特定チャンネルのアップロード動画の一覧を取得- 動画一覧の中から1つの動画をランダムでピックアップ- 動画のタイトルとURLを含むtweetを行う ソースはここに置いてあります。 https://github.com/ebibibi/youtubemanagement/tree/main YoutubeのDataAPIは初めていじってみました。Webで公開して誰でも使える…という構造ではなく自分専用なのでOAuthではなくAPIキーを使う形で実装しました。 アプリケーションを登録する- APIキーを作成する- googleapisライブラリを使う- Channels:listにてforUsernameを指定してリスト一覧を取得→UploadsのリストのIDを取得- PlaylistItems:listにて動画の情報を50件づつ最後まで取得 という感じにしてみました。

この記事はシリーズの4番目の記事です。まだほかの記事を読んでない方は先に読むことをお勧めします！ 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/ 今回は、「修復タスク」を使って、OpsRampエージェントが入っていないと判断されたVMに対してエージェントを自動インストールさせちゃいます！ …、とはいえ、前回のポリシー適用時に、修復タスクも作成してありますので、全自動です（笑 自動的に、評価され、しばらくすると完了となりました。 どのノードに対して適用されたのかもわかります。Azure Stack HCI OSのノードも対象になっていますね。 ですが、ポリシーへの準拠状況としてはまだ準拠していないものがほとんどです。反映にはそれなりに時間がかかります。のんびりと待ちます。 ここで、1日以上時間をおきました。ですが、結局適用されたのは2台のみでした…。おかしいですね。 適用され、きちんと準拠している状態と出ているサーバーはOpsRampのコンソールからも確認できました。 準拠してくれない原因を調べたところ、例えばVMが停止したままだったり、Azure Arcで接続が切れていたりなどきちんと稼働してAzureと通信が取れていないVMであることがわかりました。Azureポリシーのコンプライアンスの状態の画面からだとパッと見ではそこまでわかりませんね…。 とはいえ、1台づつリソースを簡単に確認することはできます。 この状態では、コンプライアンスに準拠した状態にならないのは当たり前ですね…。 このようなオフラインのままのVMを一括でリストアップするようなことはAzure MonitorやResource Graphあたりを使ってやれば簡単にできそうですね。また別の機会に記事にしたいと思います。 というわけで、100%になっておらずちょっと気持ちが悪いところもありますが、オリジナルのAzure Policyのポリシーを作成し、それを展開することでOpsRampエージェントをVMに導入し、管理しているテナントに紐づけることを自動化することができました。さらに、コンプライアンスの状態も継続的に確認できます。これなら誤ってエージェントをアンインストールしたような状況でも再度エージェントがインストールされますし、管理化に入っていないVMを簡単に追跡できますね。 また、見てきたようにAzure Arcを使ってAzure外のVMも対象にすることができます。今回は触れていませんがAzure LightHouseと連携させて、顧客のテナントに対してポリシーを適用することも可能です。色々と夢がひろがりますね！

この記事はシリーズの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を定義するような感じですね。 ...

Youtubeの動画作成リクエストをもらったので作成しました。 Microsoftが公開しているチュートリアルに沿ってアプリケーションを動かしながらどのようにWebアプリケーションからデータベースに接続をしているのかという点を説明しています。 https://youtu.be/kqx2ds1NBhA 一番単純に接続する方法としては接続文字列をアプリケーションのコードに生で書いてしまうことでしょうが、さすがにそれは筋が悪すぎるので、チュートリアルでは接続文字列内にIDとパスワードを記載しそれを利用して接続する形態になっています。 次のステップとしてはKeyvaultの利用、あるいはマネージドIDの利用ということになります。 https://www.youtube.com/watch?v=tAfwj_HH02E

Azure SQL DBの認証にAzure ADを利用している場合にプログラムからアクセスしたいとします。 Azure AD認証を行う方法は色々とあるのですが、Azure ADにアプリケーションを登録するところから始めると色々と面倒だったりもしますよね、管理者が登録を禁止してたりとか…。 そんな時に一番簡単にできるのはMicrosoft.Data.SqlClientを使ってインタラクティブにAAD認証する方法だと思います。これならアプリケーションのAADへの登録すら必要ありません。 u u n { } s s a i i m n n e g g s c { } p l S M a a y i c s s c e s s { } t r t e o A P a m s z r t ; o u o i s u } f r g c t s t e r r i . S a i n D Q m o n g c a L i g o t D d ( n a B C S n . A M o q . S u a n l O q t i n C p l h n e o e C e ( c n n l n s t n ( i t t i e ) e i r o c ; n c i n t t a n S i ; t g t o i [ r n o ] i n n c a g o r n g = n s ) @ = " S n e e r w v e S r q = l x C x o x n s n q e l c s t e i r o v n e ( r C n o a n m n e e x c x t x i . o d n a S t t a r b i a n s g e ) . ) w i { n d o w s . n e t ; A u t h e n t i c a t i o n = A c t i v e D i r e c t o r y I n t e r a c t i v e ; D a t a b a s e = t e s t d b ; " ; これだけでOKです。 ...

以前の記事に続いてMicrosoftのクラウドサービスを使うならこれだけは知っておかないとまずいこと その2です。前提としてAzure Active Directoryと「テナント」の関係を理解している必要がありますので前回のエントリが未読の方はそちらから先に読んでいただけると嬉しいです。 https://cloud.ebisuda.net/2021/09/23/azure-ad%e3%81%a8%e3%80%8c%e3%83%86%e3%83%8a%e3%83%b3%e3%83%88%e3%80%8d%e3%81%ae%e8%a9%b1-microsoft%e3%81%ae%e3%82%af%e3%83%a9%e3%82%a6%e3%83%89%e3%82%b5%e3%83%bc%e3%83%93%e3%82%b9%e3%82%92%e4%bd%bf/ 今回は前回の内容を踏まえた上で、「テナントをまたいだ外部組織とのコラボレーション」の仕組みについての解説です。自テナントのAzure Active Directoryにユーザーを作成するのではなく、ゲストとして招待し、さらにそのゲストのライフサイクル管理もきちんとしましょうねというお話です。 このエントリの内容はYoutubeの動画にもしていますので、動画の方がお好みの方は動画でご覧ください。 https://www.youtube.com/watch?v=lpatFbZnJyg テナントにはAzure ADが1つ テナントにはAzrue ADが1つです。Azure AD内にユーザーがあり、そのユーザーに対して各種サービスにアクセス権を付与することも可能です。 これは組織の外部も同様です。下図は2つの組織がそれぞれ独立している様子だと思ってください。 テナントをまたいだコラボレーション この時にAさんとBさんが一緒に作業したいことってありますよね。 AさんとBさんが同じTeamsのグループメンバーとしてチャットをしたりファイルを共有したり会議をしたりしたいわけです。でも、別々の異なるテナントに存在するAさんとBさんなのでこのままではコラボレーションできません。権限はテナントにあるAzure AD内に存在しているユーザーにしか出すことはできないのです。 コラボレーションするための良くない方法 コラボレーションをするための1つの方法として「新規にユーザーを自テナント内に作成する」という方法があります。下の図のような状況にする方法です。 この例ではAさんと同じAzure ADに、Bさんを新規にユーザーとして作成しています。こうしてしまえば確かにAさんとBさんはコラボレーションできるようにはなるわけですが、色々と良くないこともあります。 (左のテナントの)Bさんのために有償のライセンスを別途割り当てる必要がある。- Bさんは2つのアカウントの両方にきちんと異なるパスワードを設定する等適切に管理する必要がある。- Bさんはアカウントを切り替えるときには、サインアウトやサインインを繰り返す必要がある。 個人的にもこの構成は極力避けるべきと思います。 推奨構成：ゲストとして招待 推奨する構成は「ゲストとして招待する」です。これはAzure B2Bという名前がついています。 外部組織のユーザーもAzure ADであれば「ゲストとして招待」することができるのです。これは事実上「ゲストユーザーアカウントを自テナント内に作成する」というような感じです。招待された側は1つのアカウントで複数のテナントにアクセスすることが可能となります。 これはM365系でもそうですし、Azureでも同じです。 Active Directoryの時代にはこのような「他のテナントのユーザーに権限を出す」というようなことをするのはかなりハードルが高かったですし、完全に外部組織となれば不可能に近いところもありました。ですが、クラウド時代になってユーザーのメールアドレスだけ入力すれば簡単に外部のユーザーを招待して権限を付与することができるようになりました。これはものすごい技術革新です。 どれだけ簡単にできるのかは、実際のデモを見てもらうとわかりやすいです。是非動画でご覧ください。 https://www.youtube.com/embed/lpatFbZnJyg?start=313 ゲストの「ライフサイクル管理」も必要 良いことづくめのゲスト招待ではありますが、これによってオンプレミスのActive Directoryの時には存在しなかった「ゲストのライフサイクル管理」というタスクが発生します。 目的に沿うようにゲストを招待しつつ、ゲストのライフサイクル管理を行うのも招待元テナント管理者の仕事になります。 だれがゲストを招待するのか?(設定によってコントロール可能)- ゲストはどこに対して権限を持つのか?- いつ、ゲストは権限を無くすのか?- いつ、ゲストアカウントは削除されるのか? Azure ADのエンタイトルメント管理の機能などを用いてゲストユーザーを管理することが理想的です。 https://docs.microsoft.com/ja-jp/azure/active-directory/governance/entitlement-management-external-users まとめ テナント内のサービスにはテナント内のAzure ADに存在しているユーザーしか権限を出すことができない- Azure ADにはゲストを招待する機能がある(Azure B2B)- 招待することも招待されることも可能- 自組織のユーザーやグループと同じように、ゲストのライフサイクル管理が必須 オンプレミス時代のActive Direcotryにはできなかった「外部のユーザーを招待する」という機能をうまく使って企業間のコラボレーションを実現しましょう!

記録する機会があったのでブログにも記録しておきます。 Azure Active Directory管理者の設定 前提条件としてSQL ServerにてAzure Active Directory管理者を設定します。SQL DB自体ではなく、そのDBを稼働させているSQL Server側での設定です。 管理者として指定したAAD上の組織アカウントでSQL Serverにアクセスします。今回はAzure Data Studioを利用しました。 きちんとアクセスできることを確認します。ここではじかれる場合には条件付きアクセスの条件を満たしていないことなどが考えられます。条件付きアクセスの内容も確認してください。 きちんとAADのユーザーでアクセスできることが確認できました。 Azure ADグループの準備 次にAzure AD上にグループを作成し、その中にユーザーをメンバーとして追加しておきます。今回はsqldbaccessというグループにadmin@hccjp.orgというユーザーを追加しました。(アカウントの選択が適当でごめんなさい。) 権限を付与する前に、まずは、アクセスができないことを確認しておきます。 Login failed for user ‘’. と怒られました。AADで認証し、トークンは取得できている状態ですが、権限がなく認可されない場合にはこのようなメッセージが出るのですね。 SQL DBへの権限付与 今回はtestdbというテスト用のDBに権限を出していきます。まずはAAD上のグループに対応するユーザーを作成します。 C R E A T E U S E R F R O M E X T E R N A L P R O V I D E R ; ...

Microsoftのクラウドサービスを利用すると裏では必ずAzure ADが使われています。Azure ADを中心にして組織が利用可能な「テナント」が構成されるわけです。あまりにも重要な事なのですがあまりにも重要すぎて自動的にAzure ADが生成されることもあり、きちんと意識していない組織があります。 よくわかっていない状態で別のMicrosoftのクラウドサービス、特にAzureの利用を開始するととても変な構成になってしまい、修正するのにとても時間と手間がかかってしまうことにもなりかねません。 特に管理者の方、Microsoft 365やAzureの契約を担当する方はしっかりとAzure ADとテナントの関係を理解してから契約を進めてください。 Youtubeでも解説していますので、ブログでも動画でもお好きな方をご覧ください。 https://youtu.be/x2hkwqt-K80 Microsoft 365を契約したらどうなるか？ まず、Microsoft 365を契約したらどうなるかという話をしましょう。 Microsoft 365を契約する時には必ずAzure Active Directoryがセットです。Azure ADが存在します。あるいは存在しなければ作成されます。 そして、Azure Active DirectoryにM365のライセンスが紐づきます。1つの契約で入手したライセンスをどこでも好きな複数のAzure ADに割り当てることはできません。1契約で100ユーザー分購入し、50ユーザー分をAAD1に、30ユーザー分をAAD2に、20ユーザー分をAAD3に…というようなことはできないのです。 Azure Active Direcotryにはユーザーやグループを作成できます。そして、そのユーザーにライセンスを割り当てます。M365のライセンスはユーザーに割り当てるライセンスなのです。 ライセンスを割り当てられたユーザーはMicrosoft 365の様々なサービスにアクセス可能となります。 この時に、Azure Active Direcotryを中心として、ユーザーが存在し、様々なサービスが使える範囲を「テナント」と呼びます。「テナント」といえば1組織が利用しているサービスの範囲が明確にわかるわけです。 Microsoft 365においては… 1テナント内にAzure Active Direcotryは1つだけ存在する- 契約したライセンスはAzure Active Direcotryに紐づく- ライセンスはユーザーに付与される ということになります。 やろうと思えば同一組織が複数のMicrosoft 365の契約を行うことも可能ですが、その場合にはテナントが2つになります。 1企業が2つの契約をし、テナントを2つもつ…ということは通常行いませんが、やろうと思えばできます。ですが、それぞれのテナントは別の環境です。技術的にはほかの企業がMicrosoft 365の契約をしているのと何も変わりません。 ユーザーにライセンスを割り当てるサービス群はすべて一緒 ここまで、Microsoft 365を例として記載してきましたが、これはほかのサービス群でも同じです。Azureのみが唯一の例外です(後述します)。 Dynamics 365でも、PowerBIでも、契約をしてライセンスを入手するとそれはAzure Active Direcotryに紐づき、Azure Active Direcotry内のユーザーにライセンスを付与し、ライセンスを持ったユーザーがサービスを利用することができます。 間違ったテナントにライセンスを紐づけてしまわないように注意 テナント内にAzure Active Direcotryは1つだけですので、テストで作ったAzure Active Direcotryに本番用のライセンスが紐づいてしまわないように注意してください。 テスト用の適当な名前のAzure Active Directoryをそのまま本番利用するのは事実上問題ないとはいえ、やっぱり気持ちが悪いですよね。 ...

個人で管理しているブログをAzureのPaaSに移行しました。合計で6個ほどのブログを移行してみました。 いろいろとハマってしまって、結局丸一日かかってしまったので、事の顛末を記録しておきたいと思います。 動画でも同じ内容を喋っているので、動画でご覧になりたい方は下記からご覧ください。 環境 移行元と移行先は下記です。 移行元Azure VM(Wordpress on Apache2 + MySQL)- 移行先Azure App Service(Linux)- WebApp- Azure Database for MySQL- Azure Blob Storage Wordpress on AppService Wordpress自体はAppService上でコンテナとして動作させました。このコンテナ自体は以前からこのブログ含めて複数ブログで利用していたもので、それを再利用しました。 https://github.com/ebibibi/wordpress-cocoon Wordpressの公式のイメージをもとにそこに自分が利用するテーマやプラグインを追加しているだけのシンプルなものです。 レポジトリにコードをコミットすれば自動的にGitHub Actionsでイメージがビルドされたうえで、Azure Container Registryに格納され、AppServiceにPushされるところまで全自動で動きます。 画像データのAzure Blobストレージへのオフロード 移行先の環境はコンテナなので、画像データをコンテナ内に持っておくわけにはいきません。そこでWordpressプラグインでAzure Blobストレージにあらかじめ画像を逃がすようにしました。 つかったプラグインはこちらです。 https://wordpress.org/plugins/wp-azure-offload/ 少し古いプラグインなのですが、以前から使ってますし、今回もきちんとうまく動いてくれました。このプラグインを使って、あらかじめAzureのブログに画像をオフロードさせます。その際にこのプラグインはブログのエントリーの中に埋め込まれているURLも書き換えるところまで自動的にやってくれます。 MySQL間のデータ移行 MySQL間のデータ移行に関しては、当初Azure Database Migration Servicesを使おうと考えたのですが、スキーマ移行には別途MySQL Workbenchが必要でしたし、それならMySQL Workbenchでそのままデータ移行してしまえばよさそうな感じでした。もちろんこれは私がサイトを簡単に停めても大丈夫だし、データ量も少ないからです。何度もデータ移行を継続的に繰り返さなければいけない時にはAzure Database Migration Sericesが役に立つと思います。 ですが、この方法はうまくいかず文字化けしてしまいました。原因はそもそも私が以前作っていたデータベースの文字コード設定が間違っていたからです。下記の状況でした。 Latin1に設定されたDBにUTF8のデータが入っていた- データ移行をそのまま行うと文字化け…。 いろいろ悩みましたが、結局下記の方法で回避しました。 先に移行先DBをUTF8で作成- Mysqldumpでダンプしたデータ内のcharset関連の部分を置換してから取り込み 具体的には下記のように行いました。 # c # m s s # m D r D y e e D y B e B s d d B s 作 a ダ q 取 q 成 t ン l - - り l e プ d e e 込 u み d m s s - a p / / h t l l o a - a a s b u t t t a i i = s u n n n e s 1 1 e e / _ w w r u g m p t e y _ - f n s d p 8 e q b / r l n a d a - w l b m d p _ . e e _ c m f d s y c a b / s h u n u q a l a t l r t m f . a - e 8 d c c . _ a t h d g t e a u e a r r m n b a p e a s c r s e t > a e t e l . r w _ a U - p c z T s _ i u F e d / r 8 t b e = n w . c l a p c o a m _ o l t e d m l i _ b a n u n t 1 t a - e f m u w 8 e s u p . _ e t _ d u r f d u t = 8 b m f u _ n p 8 s g a . e e m d r n e u e m - r > p p a l w > w _ p p c _ w _ i d p d ; b _ b n d n a b a m n m e a e . m d e u _ m u p t f 8 _ g e n e r a l _ c i . d u m p その他のはまった点 その他にもあれこれはまりました…。 ...

下記のエントリがまとめエントリになっていますのでそちらも参照下さい。 Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回はAzure Database for MySQLからログを取り込みます。 まずは、ログの取り込み対象のAzure Database for MySQLを作成します。 診断設定からログの取り込み設定を行います。 以上でログ収取設定は完了です。とても簡単ですね。 今回はさらに、監査ログも有効化してみました。 少しDBを操作して、ログを出力させます。今回は下記のチュートリアルに従って操作しました。 クイック スタート:Python を使用して接続する - Azure Database for MySQL | Microsoft Docs しばらくたつと、きちんとログが検索可能となりました。 きちんとクエリ内容も含めて出力されています。 なお、Azure Monitorでログを収集する場合にはファイルへのログ出力はOFFにしておいてかまいません。OFFにした方がサーバーの負荷が下がりますのでお勧めです。

Azure LogAnalyticsワークスペースに様々なログを取り込んでみます。他にも色々とやってますので下記エントリも確認お願いします！ Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回はAzure Database for PostreSQLからログを取り込んでみます。 まず、Azure Database for PostreSQLを作成します。 これも、PaaSであり、診断設定からLog Analyticsワークスペースへのログの取り込みが可能です。 今回はさらに監査ログも取得するようにします。下記の記事に従って設定します。 監査ログ - Azure Database for PostgreSQL - Single Server | Microsoft Docs https://docs.microsoft.com/ja-jp/azure/postgresql/concepts-audit サーバーを再起動します。 pgAudit拡張機能を有効にします。 サーバーパラメーターにて対象のログを選択します。 少しDBを触って、実際にログを出したいと思います。今回は下記のクイックスタートの記事に従って操作しました。 クイック スタート:PostgreSQL に対する接続およびクエリ - Azure Data Studio | Microsoft Docs しばらく待つと、きちんとログが検索可能となりました。 ただし、ちょっとさすがにログの量が多すぎる感じがあります。監査ログでALLを選択していることが原因ですので、ALLは外しておくのが現実的かなという印象です。 ちなみに、docsのドキュメント含めてあちこちに、「Azure Monitorでログを収集するならlogging_collectorはOFFにしておいたほうがいいぞ」と書かれているにもかかわらず、サーバーパラメーターにはlogging_collectorの設定がなくて戸惑ってしまいました。 実際にクエリしてみるとOFFになっていたので、何もしなくてよいようです。

下記のエントリがまとめエントリになっていますのでそちらも参照下さい。 Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回は、BIG-IPのVMからのログ取り込みを行ってみたいと思います。 BIG-IPはAzure上に展開できるものを使いました。 BIG-IPからは、リモートのSyslogサーバーにログを送信するように構成します。 Syslogサーバーは別途構築してログを受けられるようにしておきます。今回はCentOSをSyslogサーバーとして構成しました。 まず、Rsyslogパッケージをyumでインストールします。 s u d o y u m - y i n s t a l l r s y s l o g https://support.f5.com/csp/article/K13080　によるとBIG-IPからのsyslog送信はTCPを利用しているようです。TCPを利用するように/etc/rsyslog.confを構成します。 # $ $ M I P o n r d p o L u v o t i a T d d C e P s i S m e T t r C c v P p e r s R y u s n l o 5 g 1 4 r e c e p t i o n rsyslogを再起動します。 ...

Azure LogAnalyticsワークスペースに様々なログを取り込んでみます。他にも色々とやってますので下記エントリも確認お願いします！ Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators さて、今回はApp Serviceからのログを取り込んでみます。 もともと作成してあったfunctionsの実行環境がありましたので今回はそちらを対象にしてみます。 診断設定からログを取り込む方法と、Application Insightsからログを取り込む方法の大きく2つがあります。 診断設定 まずは診断設定から見ていきます。 Functionsに関してのログがLog Analyticsワークスペースに取り込まれ検索可能となりました。 診断設定から取得できるのは、生のログに近いもの…というイメージでしょうか。 Application Insights より詳細な監視、分析はApplication Insightsを使うことで可能です。これも裏ではAzure Log Analyticsワークスペースにデータがため込まれておりそれが使われますが、1つのサービスとして利用可能となっています。 有効化するのも簡単です。 Application Insightsでは様々な観点で監視ができます。 かなりリッチな画面が並んでいますが、裏にあるのはどれもAzure Log Analyticsワークスペースのデータです。 Application Insightsにより様々なテーブルが定義されています。 こんな分析も… 裏にあるのはAzure Log Analyticsワークスペースのログです。 Azure Log Analyticsワークスペースにどのようにデータをためて、どのようなクエリでどんな分析ができるのか？という点のわかりやすいサンプルとしても、Application Insightsは優秀ですね。

Azure LogAnalyticsワークスペースに様々なログを取り込んでみます。他にも色々とやってますので下記エントリも確認お願いします！ Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回はPaaSであるAzure SQL DBのログをAzure LogAnalyticsワークスペースに取り込んでみます。 まずはSQL DBとそれを動作させるSQL Serverを作成します。 作成後、診断設定を行います。 診断設定を追加する また、監査データもLog Analyticsワークスペースに取り込むことができます。これは「監査」で設定可能です。 既定の監査設定には、次の一連のアクション グループが含まれています。これにより、データベースに対して実行されたすべてのクエリとストアド プロシージャ、および成功したログインと失敗したログインが監査されます。BATCH_COMPLETED_GROUPSUCCESSFUL_DATABASE_AUTHENTICATION_GROUPFAILED_DATABASE_AUTHENTICATION_GROUP これでログの取り込み設定としては完了です。 実際にDBにクエリを実行しつつ、ログを確認してみます。(クエリは何でもいいので、適当にネットで検索して実行しています。) ログとしては、AzureDiagnostics, AzureMetricsというテーブルが定義され、データが取り込まれていることが確認できます。 SQLの実際のクエリなんかも記録されています。