WEBVTT

00:00:00.100 --> 00:00:05.280
m 365 fm のマイクロソフトナレッジナゲットへようこそホストのミルコピーターズです

00:00:05.280 --> 00:00:10.460
皆さんはこれまでポータルでクリック操作をしてアジュールリソースをデプロイしてきましたね うまくいっているうちはいいのですが問題が起きると困ります

00:00:10.460 --> 00:00:15.820
やり直そうとしても何を選んだのか正確には思い出せません チームメイトに引き継ごうとしても彼らはあなたの手順を再現できません

00:00:15.820 --> 00:00:20.580
バージョン管理はどうしますかコミットするものすらありません 今日解決するのはまさにその問題です

00:00:20.580 --> 00:00:27.560
このエピソードを終える頃にはインフラストラクタレアスコードとは何か なぜバイセップが存在するのかそしてそれが同アジュールのデプロイを簡単かつ確実にするのかが理解できるでしょう

00:00:27.560 --> 00:00:33.860
まずは問題点から次に解決策そして実践的な例を順に見ていきます コーヒーを片手に早速始めましょう

00:00:33.860 --> 00:00:40.320
ポータルの問題クリックによるデプロイの罠は早いと感じさせる点です ログインしてフォームを埋め作成ボタンを押せば完了です

00:00:40.320 --> 00:00:47.840
しかし同じ設定やリージョン命名規則でやり直す必要があるときはどうでしょうか 選んだすべての設定を覚えておく必要がありそこでほころびが生じます

00:00:47.840 --> 00:00:54.140
手動デプロイは結果の不一致人為的ミスそして監査証跡の欠如を招きます 実際の例を見てみましょう

00:00:54.140 --> 00:00:59.220
チームの誰かがわずかに異なる設定でリソースを作成したとします すると2つの環境が一致しなくなります

00:00:59.220 --> 00:01:04.860
一方は動き一方は動かないその理由を突き止めるのは一苦労です それにドキュメントの問題もあります

00:01:04.860 --> 00:01:10.600
ワード文書によるインフラ管理あるいはさらに悪いことに ポータルの見た目が今とは全く違う6ヶ月前の youtube 動画を頼りにするのは限界があります

00:01:10.600 --> 00:01:17.820
機能は移動しメニューは変わり新しい選択肢が登場します azure ポータルチームのプロダクトマネージャーに話を聞いたところ彼らは1日に2回も新機能をリリースしているそうです

00:01:17.820 --> 00:01:21.320
1日に2回です ワードドキュメントは書き終える頃にはもう時代遅れになっています

00:01:21.320 --> 00:01:24.080
要するにこういうことです クリック操作は学習には向いています

00:01:24.080 --> 00:01:27.080
しかし本番環境ではうまくいきません では代わりになるものは何でしょう

00:01:27.080 --> 00:01:32.540
必要なものを記述したファイルを作成しそれを azure に構築させるのです インフラストラクタレアスコードコードとしてのインフラとは何でしょうか

00:01:32.540 --> 00:01:36.660
インフラストラクタレアスコードとは web ポータルをクリックするのではなくコードを使ってクラウド設定を管理することです

00:01:36.660 --> 00:01:41.980
中心となる考え方はシンプルです インフラを記述したファイルを作成しそれをリポジトリに保存します

00:01:41.980 --> 00:01:47.580
そうすればバージョン管理が可能になり プルリクエストでレビューし明日また実行して同じ結果を得ることができます

00:01:47.580 --> 00:01:52.860
ここで重要な用語が宣言的です これはどう構築するかではなくどうあって欲しいかを記述することを意味します

00:01:52.860 --> 00:01:58.680
azureに対してリソースグループを先に作り次にストレージアカウントを追加し その次にネットワークを構成せよといった指示を出す必要はありません

00:01:58.680 --> 00:02:02.680
そうではなくリソースグループを作成しストレージアカウントとネットワークをこのように構成したいと指示するのです

00:02:02.680 --> 00:02:06.460
すると azureが手順を判断してくれます その結果がべき統制と呼ばれるものです

00:02:06.460 --> 00:02:10.120
1回実行しても100回実行しても同じ結果が得られます これこそがその力です

00:02:10.120 --> 00:02:15.060
手作業と設計図の違いと考えてください 設計図なら繰り返し使えて共有できレビューも可能です

00:02:15.060 --> 00:02:19.540
誰かに渡せばその人も全く同じものを作ることができます 今ではこれを実現するツールがいくつかあります

00:02:19.540 --> 00:02:24.200
アームテンプレートバイセップテラフォームプルミなどです これらはすべて同じコンセプトを異なる方法で実装しています

00:02:24.200 --> 00:02:27.620
これは重要な違いです インフラストラクタレアスコードイヤシーがコンセプトです

00:02:27.620 --> 00:02:31.180
バイセップはそれを実装するツールの一つにすぎません しかしここが重要な点です

00:02:31.180 --> 00:02:33.700
azureには長年アームテンプレートというイヤシー言語が存在していました

00:02:33.700 --> 00:02:37.700
マイクロソフトが新しい言語を開発したのには理由があります アームテンプレートの問題点です

00:02:37.700 --> 00:02:42.720
アームテンプレートはazureにおける元祖イヤシー形式です ジェイソンファイルであり多くの利点があります

00:02:42.720 --> 00:02:47.700
すべてのazureリソースを完全に網羅しており 内部で使用されているものと同じデプロイエンジンを使います

00:02:47.700 --> 00:02:52.600
ポータルで作成できるものであればアームテンプレートでも定義可能です では何が問題なのでしょうか

00:02:52.600 --> 00:02:56.660
ジェイソンは機械には最適ですが人間にとっては非常に扱いにくいのです どういうことかお見せしましょう

00:02:56.660 --> 00:03:02.120
アームテンプレートでストレージアカウントを作成すると約20項のコードが必要です 同じストレージアカウントをバイセップで書くと約10項で済みます

00:03:02.120 --> 00:03:06.040
ジェイソン版はおよそ2倍のサイズになります これは単なる単純なリソースの場合です

00:03:06.040 --> 00:03:10.200
ネットワークコンピューティングデータベースセキュリティルールを含む完全なデプロイを想像してみてください

00:03:10.200 --> 00:03:14.800
アームテンプレートは文字の壁のようになってしまいます よくある問題点は予測可能です

00:03:14.800 --> 00:03:20.300
カンマの抜けブラケットの不一致 冗長なネストによりどこでリソースが終わりどこで始まるのか判別が困難になります

00:03:20.300 --> 00:03:26.300
インフラの定義作業よりもジェイソンの構文と格闘する時間に多くの時間を費やすことになります さらに依存関係の問題もあります

00:03:26.300 --> 00:03:33.320
アームではディペンズオンを手動で宣言する必要があります リソースaがリソースbの存在を必要とする場合それを明示的に書き出さなければなりません

00:03:33.320 --> 00:03:37.620
一つでも書ければデプロイは失敗します どれが漏れていたのかを見つけ出すのは一苦労です

00:03:37.620 --> 00:03:44.020
もし手作業で200項のジェイソンファイルを書こうとしたことがあるならそれが楽しくない ことはお分かりでしょう少しも楽しくありません学習曲線は非常に急です

00:03:44.020 --> 00:03:49.480
新しいチームメンバーはアームテンプレートの理解に苦労します 参入障壁が高いのですでは実際にはどうなるでしょうか

00:03:49.480 --> 00:03:55.060
多くのチームではアームテンプレートを知っているのがたった一人という状態に陥ります その人が単一障害点シングルポイントオブフェーラーになってしまいます

00:03:55.060 --> 00:03:58.540
デプロイを変更できるのも何かが壊れた際にデバッグできるのもその人だけになってしまうのです

00:03:58.540 --> 00:04:03.740
それじゃあ持続可能じゃないマイクロソフトはフィードバックを受け まさにその問題を解決するためにバイセップを開発しました

00:04:03.740 --> 00:04:11.200
バイセップとは何でしょうかではバイセップとは一体何なのでしょうか アジュールリソースをデプロイするための言語でありその革新はトランスパイラです

00:04:11.200 --> 00:04:16.900
バイセップで記述すればアームのジェイソンにコンパイルされます 基盤のエンジンは同じですが書き方はずっとすっきりしています

00:04:16.900 --> 00:04:22.540
ちなみにバイセップという名前はアームを逆から読んだものです アームアームマイクロソフトのちょっとした内輪ネタですね

00:04:22.540 --> 00:04:26.900
でも実際に使ってみればその意味がわかります バイセップはアームに置き換わるのではなくその上に位置するものです

00:04:26.900 --> 00:04:31.440
同じパワーをよりシンプルな構文で得られます バイセップはアームを置き換えるのではなくその上に構築されます

00:04:31.440 --> 00:04:37.060
アームでできることはすべてバイセップでも可能です すべてのリソースタイプAPIバージョン設定オプションが揃っています

00:04:37.060 --> 00:04:40.600
唯一の違いはその書き方です 構文ははるかにクリーンです

00:04:40.600 --> 00:04:45.020
プロパティ名の引用符も間のカンマも追跡が必要なカッコもありません ただシンプルなんです

00:04:45.020 --> 00:04:50.160
2つのバージョンを並べて比較してみましょう ストレージアカウントのARMJSON版はノイズだらけです

00:04:50.160 --> 00:04:55.960
引用符カンマカッコネストの嵐 バイセップ版は同じ情報を含んでいますが読みやすい

00:04:55.960 --> 00:05:00.860
ジェイソンの構文の層をくぐり抜けることなく パッと見て何をしているか即座に理解できます

00:05:00.860 --> 00:05:03.960
大きな改善点の一つが依存関係の自動推論です

00:05:03.960 --> 00:05:07.040
アームでは手動でリペンズオンを宣言しなければなりません

00:05:07.040 --> 00:05:12.060
しかしバイセップではリソースAがリソースBを参照していれば システムが自動的に依存関係を判断します

00:05:15.020 --> 00:05:18.740
それだけでデバッグの時間が大幅に短縮されます モジュールも重要な要素です

00:05:18.740 --> 00:05:22.780
インフラを小さく再利用可能なパーツに分割し プロジェクト間で共有できます

00:05:22.780 --> 00:05:26.180
あるチームがネットワークモジュールを作り 別のチームがそれを利用する

00:05:26.180 --> 00:05:32.340
毎回シャリンの再発明をする必要はありません パラメータと変数を使えば入力を一度定義してどこでも使い回せます

00:05:32.340 --> 00:05:35.500
ハードコードされた値を検索して置き換える作業はもう終わりです

00:05:35.500 --> 00:05:40.260
文字列補完により複雑な連結関数を使わずに プレフィックスを指定してストレージをかけます

00:05:40.260 --> 00:05:45.380
ツールが充実していることもバイセップが扱いやすい理由の一つです ブスコード拡張機能がインテリセンス

00:05:45.380 --> 00:05:51.020
構文ハイライトリアルタイムの構文チェックを提供します 正直なところブスコードの言語拡張機能の中でも最高クラスです

00:05:51.020 --> 00:05:55.760
入力を始めれば次に何をすべきか提案してくれます ミスがあれば即座に指摘してくれます

00:05:55.760 --> 00:06:01.360
カンマの抜けに気づくためにデプロイ失敗を待つ必要はもうありません では実際に使ってみるとどんな感じでしょうか

00:06:01.360 --> 00:06:06.060
バイセップがアームとどう違うのかを見ていきましょう バイセップとアーム実際には何が違うのでしょうか

00:06:06.060 --> 00:06:11.800
ARMJSONの代わりにバイセップで記述する際 実際に何が違うのかを見ていきましょう ファイルサイズは明白な違いの一つです

00:06:11.800 --> 00:06:16.820
バイセップファイルは同等のアームテンプレートの約半分のサイズです これは誇張ではありません

00:06:16.820 --> 00:06:23.160
引用符カンマカッコ定型文をすべて取り除けば残るのはインフラ定義だけです コードは半分結果は同じです

00:06:23.160 --> 00:06:28.120
読みやすさも自然と向上します 行数が減り構造が整理され一目で理解しやすくなります

00:06:28.120 --> 00:06:31.440
バイセップファイルを開けば何がデプロイされるのかをすぐに把握できます

00:06:31.440 --> 00:06:38.340
ARMJSONでは実際の構成にたどり着くまでに何層もの入れ子をたどる必要があります 依存関係の管理は時間を大幅に節約してくれます

00:06:38.340 --> 00:06:42.680
ARMではdepends onを手動で宣言します 一つでも忘れるとデプロイは失敗します

00:06:42.680 --> 00:06:46.720
バイセップならリソースAがリソースBを参照していればシステムが自動的に処理します

00:06:46.720 --> 00:06:51.600
ARMJSONにコンパイルする際依存関係を自動的に追加するのです 意識しなくても正しく動作します

00:06:51.600 --> 00:06:55.780
これだけでデバッグの時間を何時間も節約できます モジュールも大きな違いの一つです

00:06:55.780 --> 00:07:01.220
ARMにもネストされたテンプレートはありましたが扱いが困難でした ファイルが分かれリンクが複雑でバージョン管理も困難でした

00:07:01.220 --> 00:07:08.720
バイセップのモジュールはよりクリーンでバージョン管理ができ再利用可能です 一度定義してレジストリに公開すればどこからでも参照できます

00:07:08.720 --> 00:07:13.620
同じモジュールで常に同じ構成が保てます デプロイのプロセス自体は全く同じです

00:07:13.620 --> 00:07:18.820
バイセップはARMJSONにコンパイルされAzureリソースマネージャーがそれをデプロイします エンジンもパイプラインも同じです

00:07:18.820 --> 00:07:26.680
デプロイプロセスを変更する必要はなくテンプレートの書き方を変えるだけです ワットイフはARMにもありますがバイセップではより使いやすくなっています

00:07:26.680 --> 00:07:33.860
デプロイ前に変更をプレビューし何が作成変更削除されるかを正確に確認できます 想定外の事態や誤った削除を防ぐことができます

00:07:33.860 --> 00:07:38.620
ワットイフを実行して結果を確認し問題なければデプロイするだけです 学習曲線の面でもバイセップは優れています

00:07:38.620 --> 00:07:43.640
ARMJSONは使う側が全てを理解している前提で作られています 人間向けではなく機械向けに設計されているからです

00:07:43.640 --> 00:07:49.900
バイセップは初心者向けに設計されています 直感的な構文とガイド付きのツールが備わっています 午後には習得でき週末には生産性を発揮できるでしょう

00:07:49.900 --> 00:07:55.560
マイクロソフトはバイセップを推奨される作成体験としています 全ての新機能や改善はまずバイセップを対象に行われます

00:07:55.560 --> 00:08:02.360
ARMテンプレートも使い続けられますし消えることはありませんが新しく書く必要はないでしょう 今日新しいプロジェクトを始めるならバイセップを使うべきです

00:08:02.360 --> 00:08:06.060
リソースグループをデプロイするのにバイセップなら3行です たった3行です

00:08:06.060 --> 00:08:12.320
同じことをARMJSONでするには約15行必要です 同じ結果同じデプロイ片方は読みやすくもう片方はノイズだらけ

00:08:12.320 --> 00:08:19.580
テラフォームはどうなのと思うかもしれません バイセップとテラフォームどちらを学ぶべきとバイセップ対テラフォームどちらを使うべきでしょうか

00:08:19.580 --> 00:08:22.680
マイクロソフトナレッジナゲットへようこそ ミルコピーターズです

00:08:22.680 --> 00:08:27.260
今日はよく寄せられる疑問について解説します バイセップかそれともテラフォームか詳しく見ていきましょう

00:08:27.260 --> 00:08:32.260
テラフォームはマルチクラウドに対応しています Azure AWS GCPあるいはそのすべてで同時に使用可能です

00:08:32.260 --> 00:08:37.120
一方バイセップはAzure専用に構築されています この根本的な違いがすべてに影響します

00:08:37.120 --> 00:08:45.060
マルチクラウド環境で作業するならテラフォームが最適です 一つの言語一つのツール一つのワークフローでどこでも使えます

00:08:45.060 --> 00:08:50.100
しかしAzureがメインならバイセップには大きな利点があります 一つ目の利点です

00:08:50.100 --> 00:08:56.080
管理するステートファイルがありません テラフォームはデプロイ内容を記録するステートファイルを維持しますがこれが重要です

00:08:56.080 --> 00:09:02.180
破損や動機ズレが起きると深刻な問題になります 安全な保存バックアップアクセス管理が必要

00:09:02.180 --> 00:09:07.540
です バイセップはAzureリソースマネージャーと直接やり取りし現状を確認して差分を特定します

00:09:07.540 --> 00:09:12.160
ステートファイルがないため同期の問題も破損のリスクもありません 二つ目の利点

00:09:12.160 --> 00:09:18.040
dayゼロサポートです マイクロソフトが新しいAzure機能をリリースするとバイセップは即日対応します

00:09:18.040 --> 00:09:26.280
テラフォームはプロバイダー更新を待つ必要があり数週間かかることもあります 新機能をすぐに使いたい場合バイセップが唯一の選択肢です

00:09:26.280 --> 00:09:33.520
三つ目Azureチームによる開発です ツールインテリセンスエラーメッセージなどAzureの仕組みに合わせて設計されています

00:09:33.520 --> 00:09:41.740
バイセップを拡散Azureリソースをネイティブに理解する言語を使用します 必要なプロパティ有効な値依存関係を把握しています

00:09:41.740 --> 00:09:46.800
この深い統合はサードパーティ性ツールでの再現が困難です 両方を併用することも可能です

00:09:46.800 --> 00:09:52.840
多くの組織がプラットフォームやランディングゾーンにはバイセップをマルチクラウドにはテラフォームを使っています 両者は排他的ではありません

00:09:52.840 --> 00:09:56.660
仕事に合わせて最適なツールを選べます 率直な答えはこうです

00:09:56.660 --> 00:10:01.620
Azureを学ぶならバイセップの方が要素が少なくシンプルです 初心者が最初に学ぶには最適です

00:10:01.620 --> 00:10:08.000
ステートファイルやプロバイダーバックエンド設定を覚える必要はありません Azure CLIを入れブスコードを開けばすぐに書けます

00:10:08.000 --> 00:10:15.980
理論はここまで実際に必要なものについて話しましょう 準備の進め方実際に必要なもの準備には2つのものが必要です

00:10:15.980 --> 00:10:22.660
Azure CLIとブスコード用のバイセップ拡張機能これだけです ベッドバイセップ CLIをインストールする必要も追加のツールを設定する必要もありません

00:10:22.660 --> 00:10:26.500
Azure CLIにはバイセップが組み込まれています Azure CLIのインストールはとても簡単です

00:10:26.500 --> 00:10:30.320
Microsoft Docsにアクセスしてください お使いのOS向けのインストールページを見つけます

00:10:30.320 --> 00:10:35.980
Macならコマンドは1つです Blue Insta Azure CLIを実行するだけです WindowsならMSIインストーラーがあります

00:10:35.980 --> 00:10:39.880
ダウンロードして実行すれば完了です Linuxでもパッケージマネージャー経由で動作します

00:10:39.880 --> 00:10:43.680
インストールしたらAsバージョンを実行し 正しく動作しているか確認しましょう

00:10:43.680 --> 00:10:46.860
Azure CLIとバイセップのバージョンが表示されるはずです

00:10:46.860 --> 00:10:51.320
次にブスコードを開き 左側の拡張機能パネルでバイセップと検索します

00:10:51.320 --> 00:10:54.940
サードパーティ制ではなく Microsoft公式のものをインストールしてください

00:10:54.940 --> 00:10:56.760
この拡張機能は必須です

00:10:56.760 --> 00:11:03.880
入力中のリソースプロパティを提案するインテリセンスや 構文を強調表示してミスを一目で発見する機能リアルタイムでのエラーチェックが可能です

00:11:03.880 --> 00:11:07.540
デプロイする前に間違っている箇所には赤い波線が表示されます

00:11:07.540 --> 00:11:12.480
正直なところこれはブスコードで最高の拡張機能の1つであり バイセップが快適に使える大きな理由です

00:11:12.480 --> 00:11:15.580
では新しいファイルを作成し メインバイセップという名前を付けます

00:11:15.580 --> 00:11:18.480
その拡張機能がブスコードに対して バイセップの機能を有効にするよう伝えます

00:11:18.480 --> 00:11:20.600
これがないと単なるテキストを書いているだけになります

00:11:20.600 --> 00:11:22.780
あればツールによる完全な支援を受けられます

00:11:22.780 --> 00:11:24.280
簡単な例を見てみましょう

00:11:24.280 --> 00:11:26.780
わずか3行のコードでリソースグループをデプロイします

00:11:26.780 --> 00:11:31.920
まずスコープをサブスクリプションに設定し 次に名前と場所を指定してリソースグループを定義します

00:11:31.920 --> 00:11:33.680
これだけたったの3行です

00:11:33.680 --> 00:11:38.140
これをARMJSONと比較すると 括弧や引用符だらけで約15行にもなります

00:11:38.140 --> 00:11:40.460
デプロイにはAzure CLIを使います

00:11:40.460 --> 00:11:45.020
サブスクリプションスコープでデプロイするため コマンドはAsDeploymentSubCreateです

00:11:45.020 --> 00:11:48.540
デプロイ用メタデータの場所を指定し バイセップファイルを指し示します

00:11:48.540 --> 00:11:51.700
コマンドラインでの方法もありますが ガイド付きの操作も可能です

00:11:51.700 --> 00:11:55.540
ブスコードでバイセップファイルを右クリックし デプロイビセップファイルを選択します

00:11:55.540 --> 00:11:57.160
手順を追って進められます

00:11:57.160 --> 00:12:01.680
デプロイ名サブスクリプションの選択 リソースグループの作成または選択

00:12:01.680 --> 00:12:04.020
そしてパラメータファイルの有無を尋ねられます

00:12:04.020 --> 00:12:06.260
いいえと答えればデプロイが始まります

00:12:06.260 --> 00:12:08.100
結果はAzureポータルに表示されます

00:12:08.100 --> 00:12:11.260
ポータルでクリック操作するのと同じですが これなら再利用可能なファイルが手元に残ります

00:12:11.260 --> 00:12:14.560
リポジトリにコミットしチームで共有し 明日また実行することもできます

00:12:14.560 --> 00:12:16.300
ここからが魔法のような部分です

00:12:16.300 --> 00:12:19.340
同じデプロイをもう一度実行して 何が起こるか見てみましょう

00:12:19.340 --> 00:12:20.800
デキトー性の力です

00:12:20.800 --> 00:12:23.000
デプロイを実行する際のポイント についてお話しします

00:12:23.000 --> 00:12:25.480
デプロイは何も壊すことなく何度 でも実行できるようにしたいもの

00:12:25.480 --> 00:12:25.680
です

00:12:25.680 --> 00:12:28.020
まさにそれこそが適当性が提供 してくれるものです

00:12:28.020 --> 00:12:30.540
バイセップファイルを初めて実行 するとリソースグループが作成

00:12:30.540 --> 00:12:32.720
されますが2回目に実行しても何も 起こりません

00:12:32.720 --> 00:12:34.780
エラーも重複も何も起きません

00:12:34.780 --> 00:12:38.600
バイセップはAzure上の既存リソース を確認し要求内容と比較して変更

00:12:38.600 --> 00:12:39.700
の必要がないと判断します

00:12:39.700 --> 00:12:42.360
新しいリソースグループを作成 しようとすることもなければ

00:12:42.360 --> 00:12:43.860
既に存在するというエラーも出ません

00:12:50.800 --> 00:12:53.300
すべてがすでにあるべき状態 の通りになっています

00:12:53.300 --> 00:12:55.560
これこそがインフラストラクタ レアスコードの力です

00:12:55.560 --> 00:12:58.680
何度デプロイを実行しても毎回 同じ結果が得られます

00:12:58.680 --> 00:13:00.800
驚きもなければ構成ドリフトも ありません

00:13:00.800 --> 00:13:02.860
ファイルに記述されている通りに デプロイされていることがわか

00:13:02.860 --> 00:13:03.860
ります

00:13:03.860 --> 00:13:05.420
そのファイルが唯一の信頼できる 情報源シングルソース

00:13:05.420 --> 00:13:06.420
オブトゥルースとなります

00:13:06.420 --> 00:13:09.120
設定を覚えていたかどうか悩ん だり自分の環境では動くという

00:13:09.120 --> 00:13:11.720
問題に直面したり誰かが何かを変更 していないかAzureポータル

00:13:11.720 --> 00:13:12.960
を探し回ったりする必要はありません

00:13:12.960 --> 00:13:14.940
何があるかはファイルが教えて くれます

00:13:14.940 --> 00:13:17.760
何かを変更したい場合はファイル を修正して再デプロイするだけ

00:13:17.760 --> 00:13:17.980
です

00:13:17.980 --> 00:13:20.880
検証したいときはデプロイをもう 一度実行すればすべてが一致

00:13:20.880 --> 00:13:21.840
していることが確認されます

00:13:21.840 --> 00:13:24.560
そのようにしてインフラに対する 信頼を構築していくのです

00:13:24.560 --> 00:13:26.580
ファイルこそが信頼できる情報源 です

00:13:26.580 --> 00:13:30.760
記憶でもワード文書でも半年前の youtube動画でもなくファイルなのです

00:13:30.760 --> 00:13:34.220
ではバイセップはAzureの全体像 の中でどのように位置付けられるのでしょうか

00:13:34.220 --> 00:13:36.580
全体像におけるバイセップの立ち位置です

00:13:36.580 --> 00:13:39.520
バイセップはAzureリソースマネージャー エコシステムの中に存在します

00:13:39.520 --> 00:13:41.100
独立したツールではありません

00:13:41.100 --> 00:13:43.880
多くの人がそう勘違いしています が実際にはARMテンプレートをより

00:13:43.880 --> 00:13:44.920
よく書くための方法にすぎません

00:13:44.920 --> 00:13:48.300
内部的には依然としてARMであり 同じデプロイエンジン同じAPI全て

00:13:48.300 --> 00:13:48.840
が共通です

00:13:48.840 --> 00:13:50.760
唯一の違いはその書き方です

00:13:50.760 --> 00:13:53.620
そしてバイセップはARMにコンパイル されるためARMで機能するものは

00:13:53.620 --> 00:13:54.760
すべてバイセップでも機能します

00:13:54.760 --> 00:13:57.580
Azureポリシーはデプロイに対する コンプライアンスを強制します

00:13:57.580 --> 00:14:00.040
RBACは誰が何をデプロイできる かを制御します

00:14:00.040 --> 00:14:02.360
コストマネジメントはリソース の支出を追跡します

00:14:02.360 --> 00:14:05.320
Azure DevOpsやGitHub Actionsはパイプライン を通じてバイセップファイルを

00:14:05.320 --> 00:14:05.740
デプロイします

00:14:05.740 --> 00:14:08.880
バイセップは標準的なARMJSONを 生成するためこれらすべてが完璧

00:14:08.880 --> 00:14:09.320
に動作します

00:14:09.320 --> 00:14:11.180
切り替えることで何かを失うことは ありません

00:14:11.180 --> 00:14:12.900
むしろ透明性が高まります

00:14:12.900 --> 00:14:15.380
マイクロソフトはバイセップの 周りに完全なエコシステムを構築

00:14:15.380 --> 00:14:15.900
しているのです

00:14:15.900 --> 00:14:19.700
Azure Verified Modules AVMはベストプラクティス に準拠したバイセップおよび

00:14:19.700 --> 00:14:21.200
テラフォームモジュールの厳選 ライブラリです

00:14:21.200 --> 00:14:23.280
すべてをゼロから書く必要はありません

00:14:23.280 --> 00:14:25.920
仮想ネットワークやストレージ アカウントアップサービスといった

00:14:25.920 --> 00:14:28.480
一般的なパターンには既成のモジュール が利用できます

00:14:28.480 --> 00:14:31.400
これらはテストされ保守されて おりwell-architectedフレームワーク

00:14:31.400 --> 00:14:32.260
にも準拠しています

00:14:32.260 --> 00:14:35.140
クラウドアドプションフレームワーク には標準化された企業向けアーキテクチャ

00:14:35.140 --> 00:14:37.080
のためのバイセップリファレンス 実装が含まれています

00:14:37.080 --> 00:14:39.680
ランディングゾーンを構築する場合もそのための バイセップテンプレート

00:14:39.680 --> 00:14:40.320
が用意されています

00:14:40.320 --> 00:14:42.980
デプロイスタックを使用すると リソースグループのライフサイクル

00:14:42.980 --> 00:14:43.840
管理が可能になります

00:14:43.840 --> 00:14:46.580
スタックをデプロイしバイセップ ファイルからリソースを削除すれば

00:14:46.580 --> 00:14:48.640
スタックが自動的にリソースを クリーンアップしてくれます

00:14:48.640 --> 00:14:51.120
あるいは誤操作による削除から 保護することもできます

00:14:51.120 --> 00:14:52.560
それはあなたが決められます

00:14:52.560 --> 00:14:55.420
エコシステムは拡大を続けており モジュールの追加ツールの改善

00:14:55.420 --> 00:14:57.780
AI及びGitHubコパイロットとの連携強化が進んでいます

00:14:57.780 --> 00:15:01.060
やりたいことを平易な英語で記述 するだけでコパイロットがバイセップ

00:15:01.060 --> 00:15:02.160
コードを生成してくれます

00:15:02.160 --> 00:15:05.360
マイクロソフトはAzureの主要な 作成エクスペリエンスとしてバイセップ

00:15:05.360 --> 00:15:06.440
への投資を継続しています

00:15:06.440 --> 00:15:09.120
そのため新機能はまずバイセップ を対象に提供されます

00:15:09.120 --> 00:15:11.580
ARMテンプレートも引き続き利用 可能ですがイノベーションはバイセップ

00:15:11.580 --> 00:15:12.040
で起きています

00:15:12.040 --> 00:15:13.580
さて結論をまとめましょう

00:15:13.580 --> 00:15:16.200
Azureで作業しているならポータル でのクリック操作の次の一歩として

00:15:16.200 --> 00:15:17.480
バイセップは自然な選択肢です

00:15:17.480 --> 00:15:20.560
テラフォームを学習したりARMJSON を習得したりする必要はありません

00:15:20.560 --> 00:15:23.500
2つのものをインストールして数項 のコードを書くだけで再現可能

00:15:23.500 --> 00:15:26.120
でバージョン管理された信頼性 の高いインフラをデプロイできます

00:15:26.120 --> 00:15:28.520
最後に今日から実践できること をお伝えします

00:15:28.520 --> 00:15:31.360
これでイヤシイインフラストラクタレアス コードとは何かなぜバイセップ

00:15:31.360 --> 00:15:33.580
が存在するのかそしてバイセップ がどのようにAzureのデプロイを

00:15:33.580 --> 00:15:34.580
簡素化するのかがわかったはず です

00:15:34.580 --> 00:15:35.980
重要なポイントはここです

00:15:35.980 --> 00:15:38.300
バイセップは別のデプロイシステム ではありません

00:15:38.300 --> 00:15:41.160
内部的には同じエンジンとAzure リソース マネージャーを使用して

00:15:41.160 --> 00:15:45.120
おり人間が読み書きしやすい言語 で同じARMテンプレートをより効率的

00:15:45.120 --> 00:15:46.260
に記述する方法なのです

00:15:46.260 --> 00:15:47.740
あなたへの挑戦状です

00:15:47.740 --> 00:15:49.820
メインバイセップファイルを作成 してリソースグループをデプロイ

00:15:49.820 --> 00:15:51.380
しそのデプロイを2回実行してみて ください

00:15:51.380 --> 00:15:53.480
2回とも正常に動作することを確認 しましょう

00:15:53.480 --> 00:15:56.680
1回目はリソースが作成され2回目 は何も変更されていないことが

00:15:56.680 --> 00:15:57.280
確認されます

00:15:57.280 --> 00:16:00.180
その瞬間ポータルでポチポチ とクリックする作業には二度と

00:16:00.180 --> 00:16:01.500
戻れないと実感するはずです

00:16:01.500 --> 00:16:02.840
これが基盤となります

00:16:02.840 --> 00:16:05.760
ここから同じパターンを使用 してストレージアカウントや仮想

00:16:05.760 --> 00:16:07.860
ネットワークアップサービスを 追加していけます

00:16:07.860 --> 00:16:10.520
ファイルを作成しデプロイしもう 一度実行する

00:16:10.520 --> 00:16:13.180
そのファイルが唯一の信頼できる 情報源となり他の全てがそこから

00:16:13.180 --> 00:16:14.060
導き出されるようになります

00:16:14.060 --> 00:16:16.520
この動画が役に立ったならまだ ポータルで作業している

00:16:16.520 --> 00:16:17.540
誰かにシェアしてあげてください

00:16:17.540 --> 00:16:19.040
きっと感謝されるはずです

00:16:19.040 --> 00:16:21.580
お使いのポッドキャストプラットフォーム で登録をお願いします

00:16:21.580 --> 00:16:24.740
次回は実際のプロパティを持つ リソースをデプロイしバイセップ

00:16:24.740 --> 00:16:25.680
をさらに深く掘り下げます