Azure

Azure DevOpsのパイプラインからAppServiceへのデプロイ はじめに 本記事では、マイクロソフトから提供されているサンプルWebアプリケーションを使ってr，Azure DevOpsでのリポジトリの作成～パイプラインの作成からAppServiceの デプロイを行うまでの一連の操作を記載する。 AppServiceにWebアプリケーションを作成 以下の手順で、Webアプリケーションを作成。 DebOpsで組織を作成 DevOps用のプロジェクトの作成 リポジトリの作成 サービスコネクションを作成 サンプルプログラムを取得。 以下のサイトから、サンプルプログラムを取得してZIPダウンロードする。 先程クローンしたローカルリポジトリに展開する。 https://github.com/MicrosoftDocs/pipelines-java コミットを行い、その後リモートリポジトリにPushする。 $ git add . $ git commit -m "Sample WebAppを追加" $ git push パイプラインYAML作成 以下のパイプラインを作成する。 trigger: - master variables: # Azure Resource Manager connection created during pipeline creation azureSubscription: '作成したサービスコネクション名を指定' # Web app Type webAppType : 'webAppLinux' # Web app name webAppName: 'sample-web-application' # Environment name environmentName: 'sample-enviroment' # Agent VM image name vmImageName: 'ubuntu-latest' stages: - stage: Build displayName: 'Build stage' jobs: - job: Debug displayName: 'Show debug message' steps: - script: | echo "Subscription : $(azureSubscription)" echo "Web App Name : $(webAppName)" echo "Environment Name : $(environmentName)" echo "Vm Image Name : $(vmImageName)" echo "Pipeline Workspace Name : $(Pipeline.

Azure Shared Access Signatureのクエリパラメータまとめ はじめに 本記事では、Azure Storageへのアクセス権を付与されたURI(トークン)を発行するShared Access Signature (SAS) において利用される、クエリパラメータについてまとめた。 SASトークンのクエリパラメータ SASトークンに設定できるクエリパラメータは以下になる。 クエリ文字 名称 内容 設定例 備考 sv SignedVersion SAS認証のバージョン sv=2019-02-02 srt SignedResourceType 認可するリソース(アカウント SAS) srt=sco s : サービスレベルのapi c : コンテナーレベルのapi o : オブジェクトレベルのapi sr SignedResource 認可するリソース(サービス SAS) sr=bc b : Blob bs : Blob スナップショット c : コンテナー ss SignedService 認可するサービス(アカウント SASのみ) ss=bqtf b : Blob q : キュー t : テーブル f : ファイル sp SignedPermissions 認可する権限 sp=racwd 認可するサービスごとに、認可できる権限がそれぞれ用意されている spr SignedProtocol 認可するプロトコル spr=https sip SignedIP 認可するIP アドレス sip=168.

Azure Administrator対策「Azure PowerShellの命名規約」 はじめに AZ-103「Azure Administrator」対策として、Azure PowerShellの 各コマンドを記憶しやすくするため、Azure PowerShellの命名規約を記載する。 Azure PowerShellの命名規 https://docs.microsoft.com/ja-jp/powershell/scripting/developer/cmdlet/approved-verbs-for-windows-powershell-commands?view=powershell-7 類似の動詞 NewとSetとUpdate New 新しいリソースを作成するために使用。 # 仮想マシンを作成 New-AzVm ` -ResourceGroupName "myResourceGroup" ` -Name "myVM" ` -Location "East US" ` -VirtualNetworkName "myVnet" ` -SubnetName "mySubnet" ` -SecurityGroupName "myNetworkSecurityGroup" ` -PublicIpAddressName "myPublicIpAddress" ` -OpenPorts 80,3389 Set 対象のリソースが存在しない場合にリソースを作成、 また、既存のリソースを変更するために使用される # VMを一般化(マシンとユーザーの固有の情報を VM から削除する) Set-AzVM -ResourceGroupName "ResourceGroup11" -Name "VirtualMachine07" -Generalized Update 仮想マシンの状態を最新化する。 仮想マシンオブジェクトに対して変更した内容を、 仮想マシンに反映させる。 RDBにおけるコミットと同じようなものと思われる。 # 仮想マシンオブジェクトにデータディスクを追加 $vm = Add-AzVMDataDisk -VM $vm -Name "myDataDisk" -CreateOption Attach -ManagedDiskId $dataDisk.

Azure Administrator対策「オンプレミスのデータの取り込み」 はじめに AZ-103「Azure Administrator」対策として、Microsoft Learnなどを要約したものを記載。 Azure Import/Export 物理ディスクドライブから、Azure Blob Storage と Azure Filesに大量のデータをインポートすることができるサービス。 Azureデータセンターにデータをコピーした物理ディスクドライブを送付することで、インポートが行われる。 逆にAzure Blob Storageから物理ディスクにデータを転送し、オンプレミスの拠点に送付することでエクスポートを行うことも可能。 Microsoft 提供のディスク ドライブを使用してデータを転送する場合は、Azure Data Box Diskを使用してデータをAzureにインポート。 https://docs.microsoft.com/ja-jp/azure/storage/common/storage-import-export-service#how-does-importexport-work ディスクドライブ ソリッドステートドライブ (SSD) またはハードディスクドライブ (HDD)に対応。 https://docs.microsoft.com/ja-jp/azure/storage/common/storage-import-export-requirements#supported-hardware 構成 以下の2つの機能が用意されている。 Import/Exportサービス Azure Portalからインポートジョブとエクスポートジョブを作成するGUIツール。 WAImportExportツール インポート、エクスポートを支援するコマンドラインツール。 以下の機能を提供する。 ディスクドライブの配送準備 データをドライブにコピーする ドライブ上のデータを暗号化 インポート作成中に使用されるドライブのジャーナルファイルを生成 エクスポートジョブに必要なドライブの数を特定 データセットCSV インポート、エクスポート対象のファイル、ディレクトリの一覧と、インポート、エクスポート設定を記載したCSVファイル。 https://docs.microsoft.com/ja-jp/previous-versions/azure/storage/common/storage-import-export-tool-preparing-hard-drives-import ジョブ Import/Exportサービスを利用にする場合、‘ Azure Portalなどでインポート、エクスポートジョブを作成する必要がある。 各ジョブは、1つのストレージアカウントに関連付けられる。 インポートジョブ Azure Blobsまたは Azure Filesにデータをインポートするためのジョブ。 手順は以下の通り。 インポートするデータ、必要ドライブ数、インポート先のBlobの場所を決定 WAImportExportツールで、データをディスクドライブにコピー

Azure Administrator対策「リソースへの操作まとめ」 はじめに AZ-103「Azure Administrator」対策として、Microsoft Learnなどを要約したものを記載。 デプロイ デプロイ履歴の表示 Azureポータルから「リソースグループ」⇒「デプロイ」でデプロイ履歴の一覧が表示できる。 https://docs.microsoft.com/ja-jp/azure/azure-resource-manager/templates/deployment-history?tabs=azure-portal デプロイされた日時を表示 リソース履歴に表示されている最終更新日時から、各リソースがデプロイが行われた日時を表示できる。 デプロイに使用したテンプレートの表示 リソース履歴画面から「対象リソース」 ⇒ 「テンプレート」の順に選択すると、デプロイに使用したテンプレートが表示される https://docs.microsoft.com/ja-jp/azure/azure-resource-manager/templates/export-template-portal Cloud-initを利用したデプロイ Linuxには、Cloud-initというVM作成時にのみ、 パッケージのインストールや、任意のスクリプトを実行し、構築作業を自動化してくれるOSSがある。 AzureポータルからVirtual Maschineをデプロイする際に、詳細タブにあるカスタムデータ欄にcloud-init用構成ファイルを記載すると、 VM作成時にパッケージのインストールや、任意のスクリプトを自動実行することが可能。 https://docs.microsoft.com/en-us/azure/virtual-machines/linux/tutorial-automate-vm-deployment Application Gatewayのデプロイ時間 Application Gatewayはアプリケーション層のロードバランサー。 Application Gateway v1 SKU 最大20分。 Application Gateway v2 SKU 基本的には、約6分。 構成によっては、6分以上かかることもある。 VMのネットワークインターフェースのデタッチ ネットワークインターフェイスをデタッチする場合は、 仮想マシンを先に停止しておく必要がある。 – リソースの移動 リソースを新しいリソースグループまたはサブスクリプションに移動しても、 リソースが配置されるリージョンは変わらない。 https://docs.microsoft.com/ja-jp/azure/azure-resource-manager/management/move-resource-group-and-subscription 仮想マシンを別のサブスリクションまたは、リソースグループに移動 VMは別のサブスリクションまたは、別のリソースグループに移動することができる。 VMを移動するためにVMを停止する必要はなく、起動した状態で移行することができる。 移動が完了するとVMには新しいリソースIDが発行される。 https://docs.microsoft.com/en-us/azure/virtual-machines/windows/move-vm AppServiceを別のサブスリクションまたは、リソースグループに移動 Web アプリをサブスクリプション間で移動する場合には、以下の制約が適用される。 移動先リソースグループに既存のApp Serviceリソースが含まれていてはいけない App Service リソースには次のものがある。 Web Apps

Azure Administrator対策「Azureのリカバリサービス」 はじめに AZ-103「Azure Administrator」対策として、Microsoft Learnなどを要約したものを記載。 Azure Backup Service Azureや、オンプレミス上のデータをAzureのストレージ上にバックアップするサービス。 https://docs.microsoft.com/en-us/azure/backup/ バックアップ手順 以下の手順で作成を実施。 https://docs.microsoft.com/en-us/azure/backup/backup-azure-arm-vms-prepare エージェントのインストール Azureマーケットプレイスのイメージから作成されたVMではなく、カスタムVMを作成する場合、またはオンプレミスマシンを移行する場合は、エージェントを手動でインストールする必要がある。 Recoveryコンテナーを作成 コンテナーの名称と、リージョン、サブスリクションを設定する。 バックアップポリシーを作成 バックアップの頻度やデータの保持期間を設定する。 Azure VMのバックアップを有効に設定 Azure VMのバックアップを有効に設定するとバックアップが行えるようになる。 バックアップの履歴は⼀覧メニューから確認でき、各バックアップからVMを復元できるようになる。 バックアップを消す場合は、Recoveryコンテナーを削除するのではなくバックアップポリシーを先に変更する必要がある リカバリー手順 以下は仮想マシンのバックアップを実施する場合の手順。 リカバリーする仮想マシンを選択 Azureポータルのブレードから[仮想マシン]をクリック。 仮想マシンのリストから対象の仮想マシンを選択して、ダッシュボードを開く。 バックアップダッシュボードを開く 仮想マシンのメニューで、[バックアップ]をクリックしてバックアップダッシュボードを開く。 ファイルの回復 [バックアップ]ダッシュボードメニューで、[ファイルの回復]をクリックします。 復元ポイントの選択 [復元ポイントの選択]ドロップダウンメニューから、必要なファイルを保持する復元ポイントを選択。 リカバリーソフトのダウンロード 復元ポイントからファイルをコピーするために使用するソフトウェアをダウンロードする。 Windows VMの場合は、[実行可能ファイルのダウンロード] Linux VMの場合は、[スクリプトのダウンロード] リカバリーソフトのパスワードを取得 ファイルの回復メニューからリカバリーソフトを実行するためのパスワードをコピーする。 リカバリーの実施 リカバリーソフトを実行するとリカバリー用のボリュームがマウントされる。 エクスプローラなどを使用して、リカバリーボリュームからファイルをコピーして、復元する。 https://docs.microsoft.com/en-us/azure/backup/backup-azure-restore-files-from-vm 主な利用条件・制限事項 仮想マシンのバックアップ期間の上限は最大99年間 https://azure.microsoft.com/ja-jp/blog/azure-backup-update-new-features-in-iaas-vm-backup-support/ 仮想マシンのバックアップのサポートは、下表の通り↑ 操作 サポート シャットダウン状態/オフライン状態の VM をバックアップする サポート対象 マネージド ディスクへの移行後にディスクをバックアップする サポート対象 リソース グループのロックを有効にした後、マネージド ディスクをバックアップする サポート対象外 ※ Azure Backup は古い復元ポイントを削除できないので、復元ポイントの上限に達するとバックアップが失敗する VM のバックアップ ポリシーを変更する サポート対象 バックアップ ジョブを取り消す スナップショットの処理中に可能 スナップショットがコンテナーに転送されているときは不可能。 別のリージョンまたはサブスクリプションに VM をバックアップする サポート対象外 1 日あたりのバックアップ回数 (Azure VM 拡張機能を使用した場合) 1 日あたり 1 回のスケジュール済みバックアップ。 1 日あたり最大 9 回のオンデマンド バックアップ 1 日あたりのバックアップ回数 (MARS エージェントを使用した場合) 1 日あたり 3 回のスケジュール済みバックアップ。 1 日あたりのバックアップ回数 (DPM/MABS を使用した場合) 1 日あたり 2 回のスケジュール済みバックアップ。 毎月/毎年のバックアップ Azure VM 拡張機能を使用してバックアップする場合以外は、毎日および毎週のみ クロックの自動調整 サポート対象外 ハイブリッド バックアップのセキュリティ機能 セキュリティ機能の無効化は不可能。 コンピューター時間が変更された VM をバックアップする サポート対象外 仮想マシン スケール セット内の Azure VM オーケストレーション モードが 3 に設定されている VM では、バックアップと復元がサポート対象。可用性セットはサポート対象外 https://docs.

DevOpsとは 開発～公開までの作業（ビルド、テスト、デプロイ）を迅速に行うことができるAzureのサービスです。 手動でのリリースの場合、 作業時間がかかる テスト漏れ リリースミス というデメリットがありますが、DevOpsを使用することで迅速に、頻繁に、確実に行える仕組みを構築することができます。 Azure DevOpsの特色 リリース作業に必要なサービスが揃っている ビルド、テスト、資産管理、チケット管理まで一括して行える。 GUIでの操作性に優れている GUIリリース作業フローを作成できる。 AWSのサービスと比べ構築しやすい。 利用コストが安い 5人までのプロジェクトであれば無料。 他サービスと連携できる GitHubなどの他のサービスと連携できる Azure DevOpsの主な機能 Overview プロジェクトの概要を表示します。 Aure Boards JIRAやTrelloのようなタスク管理が行え、バグトラッキングとして修正資産と紐づけることができます。 Azure Repos Gitホスティング ソース管理が行えます。 Azure Pipelines 継続的インテグレーション（CI）/継続的デリバリー（CD）処理をGUIを利用して、YAML形式で設定が可能。 連携次第で、GitHubやその他のリポジトリサービスも利用可能。 ビルドツール Ant .Net Gradle Mavenも利用可能です。 Azure Test Plans 手動の探索的テストの管理ができるサービスです。 https://news.mynavi.jp/article/zeroazure-30/ Azure Artifacts パッケージ リポジトリ 成果物を格納することができるサービスです。 例えば、リリース作業時のテスト結果のエビデンスを格納することもできる。

Azure Functionsにおけるコールドスタート コールドスタートとは 関数アプリケーションを起動する際に、起動中の関数アプリケーションを一度停止して、 ランタイムなどを初期化してから起動を行なうこと。 コールドスタートの場合の、Functionsが実行されるまでの大まかなフローは下記のようになっている、 容量のあるサーバーに関数アプリケーションを割り当てる Functionsランタイムをそのサーバーで起動する 関数アプリケーションのコードを実行する コードの実行に対するオーバーヘッドに当たる1、2の実行には時間がかかる。 そのため、毎回ゼロから開始するのではなく、Functionsランタイムが稼働するように事前構成されたアイドルワーカーが常に存在している。 これを活用することで、コールドスタート時間を大幅に改善できる。 コールドスタートとウォームスタート プールから事前構成されたサーバーを関数アプリに割り当る。 2.　サーバを関数アプリ用に専門化 ※ 割り当てられたサーバにAzure Filesコンテンツをマウント ※ 関数アプリ固有のアプリ設定を適用 関数ランタイムをリセット ※ ランタイムは関数アプリ内の関数のfunction.jsonファイルから拡張機能を読み込む ※ ソースコードを言語プロバイダーによってメモリに読み込まれる 関数アプリのコードを実行 コールドスタートの場合は、1～4の準備作業が行われてからコードが実行される。 一度コードを実行すると暫くの間はリソースが保持されるため、1～4の準備作業でコードをすぐに実行することができる。(ウォームスタート) 非アクティブ状態が約20分間続いた後、リソースの割り当てが解除される。 その後、次の呼び出しはコールドスタートとなる。 長期間のコールドスタートを回避する ※ 2.0ランタイムで実行されている言語はプレビュー版であり、完全に最適化されていないことにも注意 軽量なコードを書く コードが起動する前に発生する必要がある作業の量を最小限に抑え、大量のCPUを消費するコードを避ける。 ファイルサイズ、ファイル数を減らす 関数アプリ内に依存関係ファイルなどのファイルが大量にある場合、 Azure FilesからのI / O操作の時間が増加し、メモリにロードするために必要な時間が長くなるため、コールドスタートが長くなる。 また、ファイル数が増えるとAzure Filesが処理する必要のあるファイルの数も増えるため、速度が低下する。 できるだけ多くの処理を非同期にする 重い同期呼び出しがコードの完了をブロックしている場合、関数はうまく機能しない。 コールドスタートを完​​全に回避する App Serviceプランで関数を実行すると、VMで発生することを制御できるため、これらの問題が緩和される。 参考 https://azure.microsoft.com/ja-jp/blog/understanding-serverless-cold-start/

Azure Administrator対策「Azure AppService」 はじめに AZ-103「Azure Administrator」対策として、Microsoft Learnなどを要約したものを記載。 AppService スロットスワップ スロット FQDN形式の命名で生成されるAppServiceの実行環境。 スロットスワップ スロット間でスロット内のアプリケーションや、コンテンツを入れ替えること。 スワップ後もスロットのドメイン名は同じまま。 検証スロットで検証後、本番スロットと検証スロットをスワップすると、 アプリケーションのURLはそのまま、中身を変更することが可能 スワップのメリット アプリをデプロイする際のダウンタイムがなくなる スロットにスワップ前の運用アプリが残るため、切り戻しが用意 ※ 利用できるスロット数は、App Service プラン レベルごとに異なる ※ スロットは追加料金なしで利用可能

Azure Administrator対策「IDの管理」 はじめに AZ-103「Azure Administrator」対策として、Microsoft Learnなどを要約したものを記載。 Azure Active Directory Azureクラウド上で組織内のユーザアカウントの管理、認証を行うサービス。 Azure AD デバイス ID Azureクラウドにアクセスできるデバイスを設定することが可能。 [Azure Active Directory] > [デバイス] から設定が行える。 https://docs.microsoft.com/ja-jp/azure/active-directory/devices/ 「Azure AD 参加 : Azure AD Join」 以下のような機能を提供するAzure上にアカウント管理サービス。 クラウドと、オンプレミスのデバイス間の双方向のシングルサインオン MDM(モバイルデバイス管理)機能 ※ この設定はWindows10にのみ対応 https://jpazureid.github.io/blog/azure-active-directory/azure-ad-join-vs-azure-ad-device-registration/ デバイス設定の構成 以下の設定項目をもつ。 [ユーザーはデバイスをAzure ADに参加させることができます] デバイスを「Azure AD 参加」に登録させることができるユーザーを選択する。　※ 既定値は [すべて(All)]で全ユーザがデバイスの登録が作業が可能 [Azure AD 参加済みデバイスの追加のローカル管理者] デバイスに対するローカル管理者権限が付与されるユーザーを選択する。 ここに追加されたユーザーは、Azure ADの"デバイス管理者"ロールが追加される。 [ユーザーはデバイスをAzure ADに登録できます] ユーザーがデバイスをAzure ADに登録できるかどうかを設定する。 ※ Allか、Noneの2択 [デバイスを参加させるには Multi-factor Auth が必要] デバイスが「Azure AD に参加」するときに、 ユーザーが追加の認証要素の提供を求められるようにする設定。 ※ デフォルトは「No」