しみゆーメモ

C#,JavaScript,Azureなど

Azureのネットワークサービス

▼ 仮想ネットワーク

  • 仮想ネットワークは独立している
    • 同一のネットワークに接続しているマシンは、通信が可能
    • 異なるネットワークに接続しているマシンとは通信が不可能

異なる仮想ネットワークでの通信

設定によって、異なる仮想ネットワークに属する仮想マシン間で通信することもできる(ピアリング)。

グローバルピアリング

異なるリージョンの仮想ネットワークに属する仮想マシンが通信する場合は、グローバルピアリングと呼ぶ。

ピアリングのポイント

  • ピアリングをすることで、異なるリージョン間の仮想ネットワークでも接続ができる
  • アドレス空間が重複している仮想ネットワーク同士は接続できない
    • たとえば、10.13.2.0/1610.13.2.0/17の仮想ネットワークはピアリングができない

▼ サブネット

仮想ネットワーク内を分割して管理するためのもの

特徴としては、

  • Azureリソースは、このサブネット内に置く
  • 仮想ネットワークを分割して管理する必要性がない場合は、サブネットを1つだけ作る
  • サブネットを分離しても、中に配置されたアプリケーション同士は通信が可能(同じ仮想ネットワーク内なので通信できる)
    • ネットワークセキュリティグループやAzure Firewallなどの機能を使うことで同じ仮想ネットワーク内のサブネット同士の通信を制限することもできる

▼ オンプレミスネットワークとの通信

サイト間接続

仮想ネットワークとオンプレミスネットワークを接続すること。例えば、仮想ネットワーク上のAzure仮想マシンと自社ネットワークの社内コンピュータが通信させられる。

VPNを使って、サイド間接続を実現する

仮想ネットワークとオンプレミスネットワークにそれぞれVPN装置を準備し、そのVPN同士を接続する。

手順

Azure側

オンプレミス側

  • VPNバイスの設置
    • ハードウェア、ソフトウェアのどちらか
    • Azureに対応したものを選ぶ

: Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-rendersの原因と解消方法

Vue.jsを使っていて、

[Vue warn]: Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-renders. Instead, use a data or computed property based on the prop's value. Prop being mutated: "count"

というエラーに遭遇した。

ChildComponent内でemitより、親コンポーネントにイベントが渡ってくる。

その値をpropsのcountに格納する流れ。

<template>
  <h2>タイトル</h2>
  <p>{{ count }}</p>
  <ChildComponent @count-up="count = $event">
</template>

<script>
export default {
  props: {
    count: {
      type: Number,
      default() {
        return 0
      },
    },
  }
}
</script>

この場合、子コンポーネントからpropの値を直接変更しないでと怒られる。

解消方法

emitで変更が加わるcountをpropsではなく、dataで定義するように変更。

<script>
export default {
  data() {
    return {
      count: 0
    }
  }
}
</script>

Microsoft Learnの「Azure Active Directory に Azure のユーザーとグループを作成する」をやってみる

Microsoft Learnに 「Azure Active Directory に Azure のユーザーとグループを作成する」というチュートリアルでやったこと、途中で調べたことなどを書いておく。

docs.microsoft.com

このチュートリアルでできるようになること

  • Azure ADにユーザを追加する
  • Azure ADグループを使用して、アプリとリソースへのアクセスを管理する

Azure AD B2Bでゲストユーザーアクセスを許可するという章もあったが、別記事とする。

Azure ADのユーザーアカウント

  • すべてのユーザーアカウントに既定のアクセス許可セットが付与されている
  • ユーザーアカウントにはアクセス権限の異なる様々な種類がある。たとえば、以下は上から順番にアクセス権限が強い。
    • 管理者
    • AzureAD組織のメンバー
    • ゲストユーザー(外部組織の人が想定される)

アクセス許可とAzureADロール

Azure ADには、異なるアクセス許可を持つ多数のロールが存在する。

グローバル管理者

  • フルアクセス権を持ち、すべての操作ができる
  • Azure ADテナントを作成したユーザーは、自動的にグローバル管理者となる

ユーザー管理者

Azure ADテナントのユーザーとグループを管理できる

メンバーユーザー(組織内のユーザー)

新しいユーザーがAzure ADで管理している組織に参加したとき、デフォルトではこのメンバーユーザーになる。

  • 自分のプロフィール情報を管理できる
  • ゲストユーザーを招待できる(設定で許可されている場合)
  • ユーザー名に初期ドメインかカスタムドメイン名を含む
  • 組織の内の他のユーザーを管理することはできない

ゲストユーザー

  • 組織外のパートナーなどが想定される
    • 登録すれば、メンバーユーザーと同様に管理できるので、外部の人と共同で作業するのに適している
  • 任意のメールアドレス(初期ドメインやカスタムドメインを含まない)で、招待&登録できる

外部コラボレーションの設定

プロジェクトによっていは、外部のゲストユーザーを招待したくない場合もある。そういう場合は、Azure ADテナント単位で、ゲストユーザー招待を禁止することができる。

[Azure Active Directory] → [ユーザー設定] → [外部コラボレーションの設定を管理します]

の順に進むと、ゲスト招待に関する設定を変更できる。

f:id:navyferret:20220122214501p:plain

Azure AD テナントを作成する

Azure ADを使うには、まずテナントが必要。

テナントとは?

そもそも、テナントとは何か?公式によると、下記のとおり。

Azure Active Directory (Azure AD) では、ユーザーやアプリなどのオブジェクトを "テナント" と呼ばれるグループにまとめます。 テナントを使用することで、管理者は組織内のユーザーと、組織が所有するアプリに対してポリシーを設定して、セキュリティおよび運用ポリシーを満たすことができます。

docs.microsoft.com

テナント作成の手順

  • リソースの作成
  • Marketplaceで「DNS ゾーン」と検索して、選択する
  • すべてを表示をクリック
  • 「Azure Active Directory」で検索して、選択する f:id:navyferret:20220122214343p:plain
  • 作成する

初期ドメイン

Azure ADテナントを作成する時にデフォルトで付いてくるドメインで、フォーマットは、 任意の文字列.onmicrosoft.comとなる。 なお、Azure ADで作成するユーザーのユーザー名は、ユーザー名@ドメイン名となる。

カスタムドメイン

docs.microsoft.com

新しいユーザーを追加とユーザーの削除

ここは、ドキュメントに従って、ポチポチ作成&削除をするだけ。 なお、過去30日以内に削除したユーザは復元可能。

アクセス権を付与する方法

  • メンバーに直接付与する
  • アクセス権を付与したグループにメンバーを割り当てる
    • 直接割り当て
    • 動的割り当て

Azure ADグループとは?

Azure ADのユーザーを束ねる概念。 グループにアクセス権を付与すると、そのグループに属するユーザー全員に一括でアクセス権を与えることができる。

Azure ADグループにメンバーを割り当てる

グループにメンバーを割り当てる方法は、

  • 直接割り当てる方法
  • 動的メンバーシップルールを作成する方法

の2種類ある。

直接割り当て

その名の通り、あるグループにメンバーを手動で追加する。

f:id:navyferret:20220122214533p:plain

動的割り当て

グループに対して、あるルールを設定しておく。 このルールに合致する場合、メンバーがグループに追加される。

https://docs.microsoft.com/ja-jp/azure/active-directory/enterprise-users/groups-dynamic-membership

  • グループの[プロパティ]の[メンバーシップの種類]を動的ユーザーに変更
  • [動的なユーザーメンバー]の下にある[動的クエリの追加]を選択

ここで、このグループに所属させるユーザーの条件を追加していく。

f:id:navyferret:20220122214213p:plain
上記の例だと、国籍が日本で部署が開発部のユーザーは、Developer groupのメンバーとなる。

fnmを使ってNode.jsをインストールする(Windows)

WindowsでNode.jsの開発環境を構築したい。

dockerでも良いが、勉強や実験用にサクッとNode.jsの開発環境を立ち上げる程度の用途なので、

fnmというバージョン管理ツールを使って、直接インストールしてしまおうと思う。

Node.jsのバージョン管理ツールとして何を使うか

満たしておきたい条件としては、

  • 更新が止まってない
  • プロジェクトごとにバージョンを自動で切り替えられる

の2点。この辺りの検討については、下記サイトを参考にさせていただいた

qiita.com

結果としては、「fnmを使おう」という結論に落ち着いた。

fnmのインストール

chocolateyでfnmをインストールする

# chocolateyでfnmをインストール
> choco install fnm -y
# インストール済のパッケージ一覧を表示
> choco list -localonly
fnm 1.28.2

PowerShellの設定ファイルに必要事項を追記

github.com

ドキュメントによると、fnmを使う前にいくつかの実行しないといけないコマンドがあり、Microsoft.PowerShell_profile.ps1にコマンドを追加する必要があるとのこと。

Microsoft.PowerShell_profile.ps1とは??

Windowsを使い始めたばかりで、そもそも「Microsoft.PowerShell_profile.ps1って何?」となった。

Microsoft.PowerShell_profile.ps1は、Powershellの設定ファイルであり、bashの".bash_profile"に相当するものと考えれば良さそう。

このファイルは、Powershellが立ち上がるたびに実行される。

docs.microsoft.com

Microsoft.PowerShell_profile.ps1の確認と作成

$PROFILEという変数に、現在のセッションで使用できる設定ファイルのパスが格納されているので、PowerShellを開いて$PROFILE(小文字でもok)と打つと確認できる。

> $profile
C:\Users\〇〇〇〇〇〇\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

パスは設定されているものの、初期状態だとMicrosoft.PowerShell_profile.ps1自体は存在しなかった。

なので、Microsoft.PowerShell_profile.ps1を作成し、$PROFILEで出てきたパスの通りに配置する。

さらに、fnmのドキュメントに従って、下記を追加。

fnm env --use-on-cd | Out-String | Invoke-Expression

Microsoft.PowerShell_profile.ps1 を読み込めません」と怒られる

上の設定を終えて、PowerShellを立ち上げると、

C:\Users\〇〇〇〇〇〇\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 を読み込めません。
ファイル C:\Users\〇〇〇〇〇〇\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 はデジタル署名されていません。
このスクリプトは現在のシステムでは実行できません。
スクリプトの実行および実行ポリシーの設定の詳細については、
「about_Execution_Policies」(https://go.microsoft.com/fwlink/?LinkID=135170) を参照してください。

となって、スクリプトが実行できない。

PowerShellのポリシー

PowerShellでは、

でポリシーが異なるらしい。

デフォルトでは、ローカルのスクリプトも外部ファイルのスクリプトも実行不可(デジタル証明書で署名されたファイルは実行できる)。

そこで、ローカルのスクリプトのポリシーをRemoteSignedに変更した。

RemoteSigned

  • インターネットからダウンロードしたスクリプトのみデジタル署名を必要とする
  • ローカルで記述されたスクリプトにはデジタル署名を必要としない

というもの。

これで、ローカルスクリプトを実行できるようになったので、Powershellを立ち上げてもエラーが出なくなった。

docs.microsoft.com

fnmの使い方

fnmで使うNode.jsのバージョンをインストール

# 使いたいNode.jsのバージョンを指定してインストール
> fnm install 16.13.1
# fnmでインストールしたNode.jsのバージョン一覧を確認
> fnm list
* v16.13.1 default
* system

実際に使用するNode.jsのバージョンを指定

fnm installでインストールするだけでは、まだNodeを使えない。

fnm useコマンドで使用するバージョンを指定する必要がある。

# useで使用するバージョンを指定
> fnm use 16.13.1
Using Node v16.13.1
# バージョン確認(これでようやく使えるようになる)
> node -v
v16.13.1

プロジェクトごとに.node-versionファイルを設置

プロジェクトごとにバージョンを切り替えるために、プロジェクトディレクトリに.node-versionというファイルを配置する。

このファイルには、下記のように使用したいNode.jsのバージョンを記載。

v17.3.0

github.com

.node-versionファイルが配置されたディレクトリでは、fnmが自動的にNode.jsのバージョンが切り替えてくれる。

# 新たにNodeのバージョンとして17.3.0をインストール
> fnm install 17.3.0
# 17.3.0を使いたいプロジェクトに移動し、バージョンを切り替え
> fnm use 17.3.0
# 現在のバージョンを.node-versionに書き込みつつ、ファイルを生成
# これで、次回以降このディレクトリに移動すると自動的にNodeのバージョンが切り替わる
> node -v > .node-version

ARP:Address Resolution Protocol

通信には4つのアドレスが必要

ARPとは

IPアドレス〇〇にデータを送信したいので、MACアドレスを教えて」

というプロトコル

ARPの動作の流れ

参考

www.amazon.co.jp

Azure App Service プランを作成すると、OSがWindowsになってしまう

概要

最近、Azure App Serviceを可用性ゾーンにデプロイすることができるようになった(ゾーン冗長)。これで、アプリケーションを別々のゾーンに分散できるようになり、リージョンを別にするよりも手軽に可用性向上ができるようになる。

このゾーン冗長を利用するべく、App Service Planを作成した。

docs.microsoft.com

App Serviceの可用性ゾーンを使用する際の制約など

このゾーン冗長の設定は、2022年1月の段階で

  • App Service プランを作成するときのみ設定できる
  • 既存のApp Service プランにゾーン冗長を追加することができない
  • Azure Portalから設定できない(ARMテンプレートを使用する必要あり)

などの制約がある。

ARM テンプレートでApp Service プランを作成する

テンプレートの内容

{
  "$schema": "http://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "hostingPlanName": {
      "type": "string"
    },
    "sku": {
      "type": "string"
    },
    "skuCode": {
      "type": "string"
    },
    "numberOfWorkers": {
      "type": "string"
    }
  },
  "resources": [
    {
      "apiVersion": "2020-12-01",
      "name": "[parameters('hostingPlanName')]",
      "type": "Microsoft.Web/serverfarms",
      "location": "[resourceGroup().location]",
      "kind": "linux",
      "properties": {
        "zoneRedundant": true,
        // これがtrueだとlinux / falseだとwindows
        "reserved": true,
      },
      "sku": {
        "tier": "[parameters('sku')]",
        "name": "[parameters('skuCode')]",
        "capacity": "[parameters('numberOfWorkers')]"
      }
    }
  ]
}

手順

  • Azure portalの[カスタム テンプレートからのデプロイ]
  • [作成]を選択
  • [エディターで独自のテンプレートを作成する]を選択
  • 表示されたエディタにARMテンプレートをコピぺ
  • [インスタンスの詳細]を埋める
    • ARMテンプレートのparametersの中で指定した項目が表示される(skuやskuCodeなど)
  • デプロイ

これで、このApp Service プランに登録するApp Serviceを複数のゾーンに分散することができる(Zone redundantがtrueになっているはず)。

なお、Linux App Service プランを使用したい場合は、

  • kindlinux
  • properties.reservedtrue

にする必要がある。

詰まったこと

"properties": {
  "reserved": true,
},

が抜けていた。

kindをlinuxにして、properties.reservedfalseにすると、Linuxプランなのに、OSがWindowsになるというなんとも気持ち悪い状態になってしまった。

パッと見で、reservedがLinuxかどうかを指定するプロパティに見えなかったので、悩んだ。

結局、答えはドキュメントに書いてあった。

properties.reserved boolean Linux app service プランの場合は true 、 false それ以外の場合はです。

docs.microsoft.com

参考にさせていただいたサイト

blog.shibayan.jp

docs.microsoft.com

【Azure】App Service プランについてのざっくりとした理解

App Service プランとは

ざっくりとした理解

  • マシンスペックを定義するもの
  • サーバーファームみたいなもの
  • アプリケーションを入れる箱

App Service プランを作成するのは、仮想サーバを1台作る(借りる)イメージ。

作成時には、サーバのスペック(CPUやメモリ)とインスタンス数を決める。

このサーバ上で、App ServiceやAzure Functionを動かすことができる。

App Service プランで実行できるもの

同じApp Service プランに紐づくApp ServiceやFunctionのスペックやインスタンス数は同じ

スペックやインスタンス数は、あくまでもApp Service プランに対して設定する。 同じApp Service プランに登録されたApp ServiceやFunctionは、同じスペック、同じインスタンス数となる。

スケールアップ

  • 1台のサーバのスペックを上げること。具体的にはCPUのコア数やメモリ
  • 必要な時に一時的に変更することはできない

スケールアウト

  • サーバ(インスタンス)の台数を増やすこと。複数のリクエストを同時に捌けるようになる。
  • 必要になったときだけ一時的に増やすことができる。
  • オートスケール機能がある()

リージョン

App Service プランのリージョンとそこで実行されるアプリのリージョンは、同一である必要がある

App Service プランの価格に影響するもの

CPUの利用状況では価格は変動しない。

docs.microsoft.com

App Service プランの価格プラン

  • Free、Sharedプランは複数ユーザーで仮想マシンを共有する。そのため、CPUやストレージのスケールアウトはできない
  • 最大インスタンス
    • Basic: 3
    • Standard: 10
    • Premium: 30
  • ディスク領域
    • Basic: 10GB
    • Standard: 50GB
    • Premium: 250GB

azure.microsoft.com

参考

docs.microsoft.com

qiita.com