m 365 fm のマイクロソフトナレッジナゲットへようこそホストのミルコピーターズです皆さんはこれまでポータルでクリック操作をしてアジュールリソースをデプロイしてきましたね うまくいっているうちはいいのですが問題が起きると困りますやり直そうとしても何を選んだのか正確には思い出せません チームメイトに引き継ごうとしても彼らはあなたの手順を再現できませんバージョン管理はどうしますかコミットするものすらありません 今日解決するのはまさにその問題ですこのエピソードを終える頃にはインフラストラクタレアスコードとは何か なぜバイセップが存在するのかそしてそれが同アジュールのデプロイを簡単かつ確実にするのかが理解できるでしょうまずは問題点から次に解決策そして実践的な例を順に見ていきます コーヒーを片手に早速始めましょうポータルの問題クリックによるデプロイの罠は早いと感じさせる点です ログインしてフォームを埋め作成ボタンを押せば完了ですしかし同じ設定やリージョン命名規則でやり直す必要があるときはどうでしょうか 選んだすべての設定を覚えておく必要がありそこでほころびが生じます手動デプロイは結果の不一致人為的ミスそして監査証跡の欠如を招きます 実際の例を見てみましょうチームの誰かがわずかに異なる設定でリソースを作成したとします すると2つの環境が一致しなくなります一方は動き一方は動かないその理由を突き止めるのは一苦労です それにドキュメントの問題もありますワード文書によるインフラ管理あるいはさらに悪いことに ポータルの見た目が今とは全く違う6ヶ月前の youtube 動画を頼りにするのは限界があります機能は移動しメニューは変わり新しい選択肢が登場します azure ポータルチームのプロダクトマネージャーに話を聞いたところ彼らは1日に2回も新機能をリリースしているそうです1日に2回です ワードドキュメントは書き終える頃にはもう時代遅れになっています要するにこういうことです クリック操作は学習には向いていますしかし本番環境ではうまくいきません では代わりになるものは何でしょう必要なものを記述したファイルを作成しそれを azure に構築させるのです インフラストラクタレアスコードコードとしてのインフラとは何でしょうかインフラストラクタレアスコードとは web ポータルをクリックするのではなくコードを使ってクラウド設定を管理することです中心となる考え方はシンプルです インフラを記述したファイルを作成しそれをリポジトリに保存しますそうすればバージョン管理が可能になり プルリクエストでレビューし明日また実行して同じ結果を得ることができますここで重要な用語が宣言的です これはどう構築するかではなくどうあって欲しいかを記述することを意味しますazureに対してリソースグループを先に作り次にストレージアカウントを追加し その次にネットワークを構成せよといった指示を出す必要はありませんそうではなくリソースグループを作成しストレージアカウントとネットワークをこのように構成したいと指示するのですすると azureが手順を判断してくれます その結果がべき統制と呼ばれるものです1回実行しても100回実行しても同じ結果が得られます これこそがその力です手作業と設計図の違いと考えてください 設計図なら繰り返し使えて共有できレビューも可能です誰かに渡せばその人も全く同じものを作ることができます 今ではこれを実現するツールがいくつかありますアームテンプレートバイセップテラフォームプルミなどです これらはすべて同じコンセプトを異なる方法で実装していますこれは重要な違いです インフラストラクタレアスコードイヤシーがコンセプトですバイセップはそれを実装するツールの一つにすぎません しかしここが重要な点ですazureには長年アームテンプレートというイヤシー言語が存在していましたマイクロソフトが新しい言語を開発したのには理由があります アームテンプレートの問題点ですアームテンプレートはazureにおける元祖イヤシー形式です ジェイソンファイルであり多くの利点がありますすべてのazureリソースを完全に網羅しており 内部で使用されているものと同じデプロイエンジンを使いますポータルで作成できるものであればアームテンプレートでも定義可能です では何が問題なのでしょうかジェイソンは機械には最適ですが人間にとっては非常に扱いにくいのです どういうことかお見せしましょうアームテンプレートでストレージアカウントを作成すると約20項のコードが必要です 同じストレージアカウントをバイセップで書くと約10項で済みますジェイソン版はおよそ2倍のサイズになります これは単なる単純なリソースの場合ですネットワークコンピューティングデータベースセキュリティルールを含む完全なデプロイを想像してみてくださいアームテンプレートは文字の壁のようになってしまいます よくある問題点は予測可能ですカンマの抜けブラケットの不一致 冗長なネストによりどこでリソースが終わりどこで始まるのか判別が困難になりますインフラの定義作業よりもジェイソンの構文と格闘する時間に多くの時間を費やすことになります さらに依存関係の問題もありますアームではディペンズオンを手動で宣言する必要があります リソースaがリソースbの存在を必要とする場合それを明示的に書き出さなければなりません一つでも書ければデプロイは失敗します どれが漏れていたのかを見つけ出すのは一苦労ですもし手作業で200項のジェイソンファイルを書こうとしたことがあるならそれが楽しくない ことはお分かりでしょう少しも楽しくありません学習曲線は非常に急です新しいチームメンバーはアームテンプレートの理解に苦労します 参入障壁が高いのですでは実際にはどうなるでしょうか多くのチームではアームテンプレートを知っているのがたった一人という状態に陥ります その人が単一障害点シングルポイントオブフェーラーになってしまいますデプロイを変更できるのも何かが壊れた際にデバッグできるのもその人だけになってしまうのですそれじゃあ持続可能じゃないマイクロソフトはフィードバックを受け まさにその問題を解決するためにバイセップを開発しましたバイセップとは何でしょうかではバイセップとは一体何なのでしょうか アジュールリソースをデプロイするための言語でありその革新はトランスパイラですバイセップで記述すればアームのジェイソンにコンパイルされます 基盤のエンジンは同じですが書き方はずっとすっきりしていますちなみにバイセップという名前はアームを逆から読んだものです アームアームマイクロソフトのちょっとした内輪ネタですねでも実際に使ってみればその意味がわかります バイセップはアームに置き換わるのではなくその上に位置するものです同じパワーをよりシンプルな構文で得られます バイセップはアームを置き換えるのではなくその上に構築されますアームでできることはすべてバイセップでも可能です すべてのリソースタイプAPIバージョン設定オプションが揃っています唯一の違いはその書き方です 構文ははるかにクリーンですプロパティ名の引用符も間のカンマも追跡が必要なカッコもありません ただシンプルなんです2つのバージョンを並べて比較してみましょう ストレージアカウントのARMJSON版はノイズだらけです引用符カンマカッコネストの嵐 バイセップ版は同じ情報を含んでいますが読みやすいジェイソンの構文の層をくぐり抜けることなく パッと見て何をしているか即座に理解できます大きな改善点の一つが依存関係の自動推論ですアームでは手動でリペンズオンを宣言しなければなりませんしかしバイセップではリソースAがリソースBを参照していれば システムが自動的に依存関係を判断します

それだけでデバッグの時間が大幅に短縮されます モジュールも重要な要素ですインフラを小さく再利用可能なパーツに分割し プロジェクト間で共有できますあるチームがネットワークモジュールを作り 別のチームがそれを利用する毎回シャリンの再発明をする必要はありません パラメータと変数を使えば入力を一度定義してどこでも使い回せますハードコードされた値を検索して置き換える作業はもう終わりです文字列補完により複雑な連結関数を使わずに プレフィックスを指定してストレージをかけますツールが充実していることもバイセップが扱いやすい理由の一つです ブスコード拡張機能がインテリセンス構文ハイライトリアルタイムの構文チェックを提供します 正直なところブスコードの言語拡張機能の中でも最高クラスです入力を始めれば次に何をすべきか提案してくれます ミスがあれば即座に指摘してくれますカンマの抜けに気づくためにデプロイ失敗を待つ必要はもうありません では実際に使ってみるとどんな感じでしょうかバイセップがアームとどう違うのかを見ていきましょう バイセップとアーム実際には何が違うのでしょうかARMJSONの代わりにバイセップで記述する際 実際に何が違うのかを見ていきましょう ファイルサイズは明白な違いの一つですバイセップファイルは同等のアームテンプレートの約半分のサイズです これは誇張ではありません引用符カンマカッコ定型文をすべて取り除けば残るのはインフラ定義だけです コードは半分結果は同じです読みやすさも自然と向上します 行数が減り構造が整理され一目で理解しやすくなりますバイセップファイルを開けば何がデプロイされるのかをすぐに把握できますARMJSONでは実際の構成にたどり着くまでに何層もの入れ子をたどる必要があります 依存関係の管理は時間を大幅に節約してくれますARMではdepends onを手動で宣言します 一つでも忘れるとデプロイは失敗しますバイセップならリソースAがリソースBを参照していればシステムが自動的に処理しますARMJSONにコンパイルする際依存関係を自動的に追加するのです 意識しなくても正しく動作しますこれだけでデバッグの時間を何時間も節約できます モジュールも大きな違いの一つですARMにもネストされたテンプレートはありましたが扱いが困難でした ファイルが分かれリンクが複雑でバージョン管理も困難でしたバイセップのモジュールはよりクリーンでバージョン管理ができ再利用可能です 一度定義してレジストリに公開すればどこからでも参照できます同じモジュールで常に同じ構成が保てます デプロイのプロセス自体は全く同じですバイセップはARMJSONにコンパイルされAzureリソースマネージャーがそれをデプロイします エンジンもパイプラインも同じですデプロイプロセスを変更する必要はなくテンプレートの書き方を変えるだけです ワットイフはARMにもありますがバイセップではより使いやすくなっていますデプロイ前に変更をプレビューし何が作成変更削除されるかを正確に確認できます 想定外の事態や誤った削除を防ぐことができますワットイフを実行して結果を確認し問題なければデプロイするだけです 学習曲線の面でもバイセップは優れていますARMJSONは使う側が全てを理解している前提で作られています 人間向けではなく機械向けに設計されているからですバイセップは初心者向けに設計されています 直感的な構文とガイド付きのツールが備わっています 午後には習得でき週末には生産性を発揮できるでしょうマイクロソフトはバイセップを推奨される作成体験としています 全ての新機能や改善はまずバイセップを対象に行われますARMテンプレートも使い続けられますし消えることはありませんが新しく書く必要はないでしょう 今日新しいプロジェクトを始めるならバイセップを使うべきですリソースグループをデプロイするのにバイセップなら3行です たった3行です同じことをARMJSONでするには約15行必要です 同じ結果同じデプロイ片方は読みやすくもう片方はノイズだらけテラフォームはどうなのと思うかもしれません バイセップとテラフォームどちらを学ぶべきとバイセップ対テラフォームどちらを使うべきでしょうかマイクロソフトナレッジナゲットへようこそ ミルコピーターズです今日はよく寄せられる疑問について解説します バイセップかそれともテラフォームか詳しく見ていきましょうテラフォームはマルチクラウドに対応しています Azure AWS GCPあるいはそのすべてで同時に使用可能です一方バイセップはAzure専用に構築されています この根本的な違いがすべてに影響しますマルチクラウド環境で作業するならテラフォームが最適です 一つの言語一つのツール一つのワークフローでどこでも使えますしかしAzureがメインならバイセップには大きな利点があります 一つ目の利点です管理するステートファイルがありません テラフォームはデプロイ内容を記録するステートファイルを維持しますがこれが重要です破損や動機ズレが起きると深刻な問題になります 安全な保存バックアップアクセス管理が必要です バイセップはAzureリソースマネージャーと直接やり取りし現状を確認して差分を特定しますステートファイルがないため同期の問題も破損のリスクもありません 二つ目の利点dayゼロサポートです マイクロソフトが新しいAzure機能をリリースするとバイセップは即日対応しますテラフォームはプロバイダー更新を待つ必要があり数週間かかることもあります 新機能をすぐに使いたい場合バイセップが唯一の選択肢です三つ目Azureチームによる開発です ツールインテリセンスエラーメッセージなどAzureの仕組みに合わせて設計されていますバイセップを拡散Azureリソースをネイティブに理解する言語を使用します 必要なプロパティ有効な値依存関係を把握していますこの深い統合はサードパーティ性ツールでの再現が困難です 両方を併用することも可能です多くの組織がプラットフォームやランディングゾーンにはバイセップをマルチクラウドにはテラフォームを使っています 両者は排他的ではありません仕事に合わせて最適なツールを選べます 率直な答えはこうですAzureを学ぶならバイセップの方が要素が少なくシンプルです 初心者が最初に学ぶには最適ですステートファイルやプロバイダーバックエンド設定を覚える必要はありません Azure CLIを入れブスコードを開けばすぐに書けます理論はここまで実際に必要なものについて話しましょう 準備の進め方実際に必要なもの準備には2つのものが必要ですAzure CLIとブスコード用のバイセップ拡張機能これだけです ベッドバイセップ CLIをインストールする必要も追加のツールを設定する必要もありませんAzure CLIにはバイセップが組み込まれています Azure CLIのインストールはとても簡単ですMicrosoft Docsにアクセスしてください お使いのOS向けのインストールページを見つけますMacならコマンドは1つです Blue Insta Azure CLIを実行するだけです WindowsならMSIインストーラーがありますダウンロードして実行すれば完了です Linuxでもパッケージマネージャー経由で動作しますインストールしたらAsバージョンを実行し 正しく動作しているか確認しましょうAzure CLIとバイセップのバージョンが表示されるはずです次にブスコードを開き 左側の拡張機能パネルでバイセップと検索しますサードパーティ制ではなく Microsoft公式のものをインストールしてくださいこの拡張機能は必須です入力中のリソースプロパティを提案するインテリセンスや 構文を強調表示してミスを一目で発見する機能リアルタイムでのエラーチェックが可能ですデプロイする前に間違っている箇所には赤い波線が表示されます正直なところこれはブスコードで最高の拡張機能の1つであり バイセップが快適に使える大きな理由ですでは新しいファイルを作成し メインバイセップという名前を付けますその拡張機能がブスコードに対して バイセップの機能を有効にするよう伝えますこれがないと単なるテキストを書いているだけになりますあればツールによる完全な支援を受けられます簡単な例を見てみましょうわずか3行のコードでリソースグループをデプロイしますまずスコープをサブスクリプションに設定し 次に名前と場所を指定してリソースグループを定義しますこれだけたったの3行ですこれをARMJSONと比較すると 括弧や引用符だらけで約15行にもなりますデプロイにはAzure CLIを使いますサブスクリプションスコープでデプロイするため コマンドはAsDeploymentSubCreateですデプロイ用メタデータの場所を指定し バイセップファイルを指し示しますコマンドラインでの方法もありますが ガイド付きの操作も可能ですブスコードでバイセップファイルを右クリックし デプロイビセップファイルを選択します手順を追って進められますデプロイ名サブスクリプションの選択 リソースグループの作成または選択そしてパラメータファイルの有無を尋ねられますいいえと答えればデプロイが始まります結果はAzureポータルに表示されますポータルでクリック操作するのと同じですが これなら再利用可能なファイルが手元に残りますリポジトリにコミットしチームで共有し 明日また実行することもできますここからが魔法のような部分です同じデプロイをもう一度実行して 何が起こるか見てみましょうデキトー性の力ですデプロイを実行する際のポイント についてお話ししますデプロイは何も壊すことなく何度 でも実行できるようにしたいものですまさにそれこそが適当性が提供 してくれるものですバイセップファイルを初めて実行 するとリソースグループが作成されますが2回目に実行しても何も 起こりませんエラーも重複も何も起きませんバイセップはAzure上の既存リソース を確認し要求内容と比較して変更の必要がないと判断します新しいリソースグループを作成 しようとすることもなければ既に存在するというエラーも出ません

すべてがすでにあるべき状態 の通りになっていますこれこそがインフラストラクタ レアスコードの力です何度デプロイを実行しても毎回 同じ結果が得られます驚きもなければ構成ドリフトも ありませんファイルに記述されている通りに デプロイされていることがわかりますそのファイルが唯一の信頼できる 情報源シングルソースオブトゥルースとなります設定を覚えていたかどうか悩ん だり自分の環境では動くという問題に直面したり誰かが何かを変更 していないかAzureポータルを探し回ったりする必要はありません何があるかはファイルが教えて くれます何かを変更したい場合はファイル を修正して再デプロイするだけです検証したいときはデプロイをもう 一度実行すればすべてが一致していることが確認されますそのようにしてインフラに対する 信頼を構築していくのですファイルこそが信頼できる情報源 です記憶でもワード文書でも半年前の youtube動画でもなくファイルなのですではバイセップはAzureの全体像 の中でどのように位置付けられるのでしょうか全体像におけるバイセップの立ち位置ですバイセップはAzureリソースマネージャー エコシステムの中に存在します独立したツールではありません多くの人がそう勘違いしています が実際にはARMテンプレートをよりよく書くための方法にすぎません内部的には依然としてARMであり 同じデプロイエンジン同じAPI全てが共通です唯一の違いはその書き方ですそしてバイセップはARMにコンパイル されるためARMで機能するものはすべてバイセップでも機能しますAzureポリシーはデプロイに対する コンプライアンスを強制しますRBACは誰が何をデプロイできる かを制御しますコストマネジメントはリソース の支出を追跡しますAzure DevOpsやGitHub Actionsはパイプライン を通じてバイセップファイルをデプロイしますバイセップは標準的なARMJSONを 生成するためこれらすべてが完璧に動作します切り替えることで何かを失うことは ありませんむしろ透明性が高まりますマイクロソフトはバイセップの 周りに完全なエコシステムを構築しているのですAzure Verified Modules AVMはベストプラクティス に準拠したバイセップおよびテラフォームモジュールの厳選 ライブラリですすべてをゼロから書く必要はありません仮想ネットワークやストレージ アカウントアップサービスといった一般的なパターンには既成のモジュール が利用できますこれらはテストされ保守されて おりwell-architectedフレームワークにも準拠していますクラウドアドプションフレームワーク には標準化された企業向けアーキテクチャのためのバイセップリファレンス 実装が含まれていますランディングゾーンを構築する場合もそのための バイセップテンプレートが用意されていますデプロイスタックを使用すると リソースグループのライフサイクル管理が可能になりますスタックをデプロイしバイセップ ファイルからリソースを削除すればスタックが自動的にリソースを クリーンアップしてくれますあるいは誤操作による削除から 保護することもできますそれはあなたが決められますエコシステムは拡大を続けており モジュールの追加ツールの改善AI及びGitHubコパイロットとの連携強化が進んでいますやりたいことを平易な英語で記述 するだけでコパイロットがバイセップコードを生成してくれますマイクロソフトはAzureの主要な 作成エクスペリエンスとしてバイセップへの投資を継続していますそのため新機能はまずバイセップ を対象に提供されますARMテンプレートも引き続き利用 可能ですがイノベーションはバイセップで起きていますさて結論をまとめましょうAzureで作業しているならポータル でのクリック操作の次の一歩としてバイセップは自然な選択肢ですテラフォームを学習したりARMJSON を習得したりする必要はありません2つのものをインストールして数項 のコードを書くだけで再現可能でバージョン管理された信頼性 の高いインフラをデプロイできます最後に今日から実践できること をお伝えしますこれでイヤシイインフラストラクタレアス コードとは何かなぜバイセップが存在するのかそしてバイセップ がどのようにAzureのデプロイを簡素化するのかがわかったはず です重要なポイントはここですバイセップは別のデプロイシステム ではありません内部的には同じエンジンとAzure リソース マネージャーを使用しており人間が読み書きしやすい言語 で同じARMテンプレートをより効率的に記述する方法なのですあなたへの挑戦状ですメインバイセップファイルを作成 してリソースグループをデプロイしそのデプロイを2回実行してみて ください2回とも正常に動作することを確認 しましょう1回目はリソースが作成され2回目 は何も変更されていないことが確認されますその瞬間ポータルでポチポチ とクリックする作業には二度と戻れないと実感するはずですこれが基盤となりますここから同じパターンを使用 してストレージアカウントや仮想ネットワークアップサービスを 追加していけますファイルを作成しデプロイしもう 一度実行するそのファイルが唯一の信頼できる 情報源となり他の全てがそこから導き出されるようになりますこの動画が役に立ったならまだ ポータルで作業している誰かにシェアしてあげてくださいきっと感謝されるはずですお使いのポッドキャストプラットフォーム で登録をお願いします次回は実際のプロパティを持つ リソースをデプロイしバイセップをさらに深く掘り下げます