ANAの投稿 - Crieit

Azure Administratorへの道（6回：AzureAD周辺）

2020-12-26T13:03:48+09:00

Qrunchからお引越しした記事です : created_at: 2019-09-02 21:16:06 +0900

知識が薄ぼんやりとしているAzureADのおさらい。

0. スキルの評価対応

アイデンティティの管理
　＞　Azure Active Directory (AD) を管理する
　＞　Azure AD オブジェクト (ユーザー、グループ、およびデバイス) の管理
　＞　ハイブリッドアイデンティティの実装と管理

1. AzureAD

・Office365やAzureの管理に利用する。
・カスタムドメインの登録が可能。
・AzureにはAADのユーザに対してRBACで権限を割り振る。
・ユーザの種類
　＞AADで作成したユーザ OR ドメコンから連携されたユーザ
　＞メンバー OR ゲスト
・ユーザの属性
　通常のドメコンと違うような属性は次の２つ。
　①利用場所
　　国を指定。これを指定しないとライセンス(Premiumライセンスなど)が割り振れない。
　②ユーザープリンシパルネーム
　　ユーザーのインターネット形式のログイン名
　　[email protected]みたいな形式
　　AzureやOffice365へログインする際のユーザ名の名前
・グループ
　動的にグループ割り当てができる
　→開発部所属のメンバーは開発部グループに自動所属のような感じか
　グループに有効期限を設け、破棄したりもできる
　グループの所有権があるユーザは、グループにユーザを追加できる。
・セルフパスワードリセット
　SMS、メール、秘密の質問、いずれかで変更。
・外部アクセス
　外部のメールアカウントを登録することで外部アクセスさせることが可能
・デバイス管理
　デバイスもAADに参加させ管理できる。
・アプリケーション
　3rd Partyのアプリとも統合できるケースがある。
　→Boxとか。
・条件付アクセス
　条件付アクセスポリシーにより設定。
　条件：ユーザ、グループ、デバイス、場所、などなど。
　制御：MFA、準拠デバイス指定、アプリ利用、利用規約を読ませる、などなど。
・アクセスレビュー
　現在のアクセス状況をレビュアが参照し、アクセス権を引き続き付与するか、
　破棄するか、などの判断・処理を実施できる。
・アイデンティティ保護（identiry Protection）
　脆弱性、リスクイベント、リスクを出しているユーザ、などが分かる。
　→Torブラウザで接近しているユーザは誰、MFAの設定をしない人がいる、とかが分かる。
　リスクイベントのレベルはポリシー（ユーザリスクポリシー、サインインリスクポリシー）で設定できる。
　→ポリシーに準拠しない場合はアクセスブロック、もできる。

2.ハイブリッドアイデンティティ

・オンプレミスドメコンとの同期。
・セットアップの流れ
★前提
　AzureAD：plazazurecontoso.onmicrosoft.com
　ドメコン：consoto.local
　→これをplazcontoso.comとして統一連携する。

　①AzureADの作成
　②AADでカスタムドメインの設定（plazcontoso.com）
　③ドメコンにUPN Suffix追加（plazcontoso.com）
　④同期対象ユーザのUPNを[user]@plazcontoso.comに変更
　　→powershellで一括変更
　⑤AzureADコネクトのデプロイ
　　→オンプレミス側にAADコネクト専用のドメコンを用意し、そこにデプロイする
　　　インターネットへ接続できる環境に存在する必要がある。
　⑥連携対象を指定（ドメインやOUなどで指定）
　⑦AzureADのごみ箱を有効にする

・ドメインフォレスト、AADコネクト、AzureAD
　①ドメインフォレスト：AADコネクト = N:1
　　複数フォレストの情報を１つのAADコネクトに集約はできる
　②AADコネクト：AzureAD = 1:1
　　AzureADとAADコネクトは1つに対して1つ
　　なので、もしAフォレストはAzureAD1、BフォレストはAzueAD2に連携、
　　という場合はAADコネクトは2台必要。
・AADコネクトの３つのSSO（シングルサインオン）認証
　①パスワードハッシュ同期
　　ドメコン→AADコネクト→AzureADの流れでハッシュ化したパスワードを連携し、
　　その内容を元にAzureADは認証を行う方式。
　　AzureADアカウントの有効期限は「無期限」になる。
　②パススルー認証
　　（流れ）
　　AzureADの認証情報をAADコネクトに暗号化して引き渡す
　　→AADコネクトは認証情報を解号してドメコンに引き渡す
　　→ドメコンは認証結果をAADコネクトに返す
　　→AADコネクトは認証結果をAzureADへ返す
　③フェデレーション認証
　　ドメコンに参加しているPCから、「追加の認証情報入力なし（シームレス）」で
　　AzureADの認証をする場合はコレ。（…くそダルイ構成だな）
　　【前提１】ADFSとWebアプリケーションプロキシ(WAP)が必要
　　【前提２】ドメコン⇔AzureAD間はAzureADコネクトでディレクトリを同期している

　　（流れ）
　　ユーザはドメイン参加PCからサービス（例：Office365）へ接近する。
　　→Office365はADFSに認証トークンを要求
　　→ドメイン参加PCはADFSから認証トークンを受領
　　→ドメイン参加PCはWAPを経由してAzureADへトークンを連携
　　→AzureADはトークンを受領し、Office365アクセストークンを発行
　　→ユーザはOffice365へアクセスできる
・パスワードライトバック
　AzureAD側でパスワードを変更した場合、それをドメコン側にも反映させる。
　通常、同期方向はドメコン→AzureADだが、この機能をオンにしていると
　パスワードの変更だけは双方同期になるような感じ。（かな？）
・同期間隔
　最短で30分間隔。間隔は変更可能。
・同期内容のフィルタ
　AD情報で何を同期するかをフィルタできる。
　勤務地は連携しない、とか。通常はデフォルト設定で十分らしい。

3.所感

・他にも色々あったけど、AZ-103の枠から外れるので飛ばした。
・「AzureAD」だけで覚えることありすぎでしょ…
　Azureの試験範囲にいれないでよ…
　（Azureと密接な関係にあるのは分かるけど）
・ハイブリッド連携はなんとなく理解していたけど、良いおさらいになりました。

Azure Administratorへの道（5回：Load Balancer）

2020-12-26T13:01:33+09:00

Qrunchからお引越しした記事です : created_at: 2019-09-02 21:16:06 +0900

ネットワーク周辺は業務でしっかりやったので概ね割愛。
ロードバランサだけ知識不足なため、そこだけは学習する。

0. スキルの評価対応

仮想ネットワークの構成と管理
　> Azure 負荷分散の実装

1. ロードバランサ（全体）

・Azureの負荷分散は大きく次の４つ
　①Public Load Balancer
　　OSI参照モデル4層（Tranceport層：TCP/UDP）の制御。
　　インターネットに接している。（パブリックIPアドレスが必要）
　②Internal Load Balancer
　　OSI参照モデル4層（Tranceport層：TCP/UDP）の制御。
　　VNet内の制御。⇒パブリックIPは不要。
　③Application Gateway
　　OSI参照モデル7層（Application層）の制御。
　　SSLオフロードやWAF（WebApplicationFirewall）の機能もある。
　④Traffic Manager
　　OSI参照モデル7層（Application層）の制御。
　　厳密にはロードバランサではない。
　　DNSレベルでの地理的負荷分散（?）を行う。

2. パブリックロードバランサ

・SKUはBasicとStandardの２種類 : 詳細
　⇒機能差、性能差の面でStandardにすることが望ましい。
・バックエンドプール
　ロードバランサにより負荷分散している同一構成のマシン達のことを指す。
・正常性プルーブ(Health Probe)
　負荷分散対象のマシンのうち、どれが正常でどれが死んでいるかを検査する方法。
　プルーブ（Probe）は「調べる、精査する」の意味なので、「健康診断」くらい雑に訳しておくと覚えやすい。
・SNAT（送信元NAT）
　SNATの機能を持つ。（中から外へのNAT）
　DNATとSNATがよくわからなくなるので以下まとめを記載しておく。（我ながらへっぽこ）

SNAT はプライベートアドレスから発生した通信をグローバルアドレスに届ける技術。
プライベートアドレス(S)をグローバルアドレスに書き換えて通信を実現している。
ホームネットワークから外部サービスへの通信等がこれ。

DNAT はグローバルアドレスから発生した通信をプライベートアドレスに届ける技術。
グローバルアドレス(D)をプライベートアドレスに書き換えて実現している。
ホームネットワークで web/mail 等のサーバ等を複数台構築してアドレスを一つに見せて外部に公開する場合がこれ。

　引用元サイト
　他参考サイト

　この機能があるので、Load BalancerのNAT規則を整理すればバックエンドにいる任意のVMにRDPで接近できる。
　（3389ポートで接近した場合はVM1、3390ポートで接近した場合はVM2、みたいな制御）
　受信NAT規則（Inbound Nat Rule）として構成する。

　ちなみに、VM自体にパブリックIPがひもづけられている場合、SNATはしない。
　→VMに付いているパブリックIPでの通信を優先する。

・分散モード
　①ハッシュベースの分散モード
　　５要素（送信元IP、送信元ポート、あて先IP、あて先ポート、プロトコル）を元に
　　ハッシュ値を作成する。そのハッシュ値を元にバックエンドのVMへ分散していく。
　　→なので、クライントPCの利用ポートが変わるとあて先VMが変わったりする。
　②ソース IP アフィニティモード
　　２要素（送信元IP、あて先IP）を元にハッシュ値を作成し、その値を元に分散する。
　　①と違って、クライアントPCのIPアドレスが変わらない限りあて先VMは変わらない。
　　→処理途中で通信先VMが変わると困るこまる場合はこっち。
　　　リモートデスクトップゲートウェイの構成に使うそうな。

3. インターナルロードバランサ

・VNet内の負荷分散に使う。FrontEndにPublicロードバランサを置いてWEBアクセスを負荷分散している裏で、
　WEBサーバ→複数DBサーバへのアクセス負荷分散を実施するのに使う、など。
・Vnet内で使う、パブリックIPアドレスがない、などを除いて、基本パブリックロードバランサとできることは同じ。

4. Application Gateway

・Web Traffic load Balancer。（なので、WEBアクセスのトラフィック制御での利用しかできない）
・URLベースのルーティングができる。
　→例えばURLが
　　①https:\//xxx/imagesの場合、画像を保管するWEBサーバへ転送
　　②https:\//xxx/videosの場合、動画を保管するWEBサーバへ転送。
　　という制御ができる。（すごい）
・SSLオフロードの機能。
　→SSL/TLSのエンコード、デコードをサーバから肩代わり。
・複数サイトのホスティングへも対応。
　→http:\//contoso.comはcontosoサーバプールへ転送、http:\//fabrikam.comはfabrikamサーバプールへ転送、など。
・WAF（Web Application Firewall）の役割ができる。
　→Webサーバへのアクセスにおいて不正な通信内容
　　（SQLインジェクション、クロスサイトスクリプティングなどの恐れがある通信）を遮断する。

5. Traffic Manager

・「DNS ベースのトラフィックロードバランサー」
　というのが、どういうことか全然分からなかったけどこの図を見てやっと分かった。
　①クライアントがDNSサーバに問い合わせる。
　②DNSサーバはTraffic Managerへ問い合わせる。
　③Traffic Managerは定められた分散規則にしたがって、いずれかのエンドポイントのパブリックIPを返す。
　④取得したIPアドレスで直接エンドポイントへ接近する。
・この手法をとることで、地理的負荷分散もできる。
　→例えば、東日本リージョン、西日本リージョンにそれぞれWEBサーバを配置した構成も実現できる。
・分散方法（ルーティング方法）は次の通り。
　①優先順位
　　基本、プライマリサイトへアクセスさせ、障害時だけセカンダリを使うときはコレ。
　②重み付け
　　均等に分散したりするときはコレ。例えば、本番環境A、本番環境B、トライアル環境Cがある場合。
　　A:50、B:50、C:1としたときはAかBにアクセスし、Cにはアクセスしない。Aが障害時はBにアクセスする。
　　Cのトライアルが終了し、一般公開するときはCも50にするだけでよい。
　③パフォーマンス
　　地理冗長しているような構成のとき、「ユーザから最も近いエンドポイント」を指定させるときはコレ。
　　この後の「地理的」とはちょっと違う。こちらはあくまで「ネットワーク待ち時間」が最も短いルートをいく。
　④Geographic(地理的)
　　DNS クエリの発信元の地理的な場所に基づいて分散させるときはコレ。
　　アメリカ本社はUSリージョン、日本支社は東日本リージョンへアクセス！という使い方かな。
　⑤複数値
　　エンドポイントがオンプレしかない(IPv4、v6のアドレス指定しかない)場合につかう。
　　この場合、正常なエンドポイントのアドレスを全て返答してくる。
　⑥サブネット
　　クライアントのIPレンジによってアクセス先を変更したい場合はコレ。
　　x.y.a.0/24はA環境、x.y.b.0/24はB環境へ行け、ということができる。
・Azure（IaaS、PaaS）以外にオンプレミスのエンドポイントも指定できる。
・Traffic Managerのネスト（入れ子）もできる。
　この場合エンドポイントにTraffic Managerを指定する。
　→複雑。
・イントラ内では使えないのではないか？

「Traffic Manager のしくみ」で説明したとおり、Traffic Manager エンドポイントとして、Azure の内部または外部でホストされているインターネット接続サービスを指定することができます。したがって、Traffic Manager は、インターネットに接続されている一連のエンドポイントにパブリックインターネットからのトラフィックをルーティングすることができます。エンドポイントがプライベートネットワーク内にある場合 (内部バージョンの Azure Load Balancer など)、またはユーザーが内部ネットワークから DNS 要求を行う場合、Traffic Manager をこのトラフックのルーティングに使用することはできません。　

引用元

6. 所感

・「軽くさらっておこう」くらいの気持ちで始めたら、大分奥が深い。
・ApplicationGatewayとTrafficManagerの概要が理解できたのは良かった。（何にも分かってなかった）

Azure Administratorへの道（4回：仮想マシン）

2020-12-26T12:59:58+09:00

Qrunchからお引越しした記事です : created_at: 2019-08-31 10:56:03 +0900

仮想マシン周りは概ね理解しているので、微妙に知識が足りないところだけ補足学習。

0. スキルの評価対応

仮想マシン（VM）のデプロイと管理

1. 仮想マシンの複数展開

1.1 イメージからの作成

イメージを作成するVMはSysprepを使う。
Linuxの場合waagent -deprovision+userでAzureのエージェントを初期化する。

1.2 ARMテンプレートでの展開

CopyオブジェクトやCopyIndexを利用するとよい。
複数の名前や値を生成できる。
例）次の場合、storage0、storage1、storage2の名前が生成される。
　名前
　"name": "[concat('storage', copyIndex())]",
　Copyオブジェクト
　　 "copy": { "name": "storagecopy", "count": 3 } 　
なお、ARMテンプレートの編集はVisual Studioで実施するとやりやすいらしい。

1.3 仮想マシンスケールセット

可用性セットとは別物。
この機能でVMを作成すると

すべての VM インスタンスが同一のベース OS イメージと構成から作成されます。
　というようにVMとして同一内容を保持した状態で自動スケールが実行できる。

基本、LoadBalancerを通してアクセスすることになる。
スケール方法は３つ
①手動
②スケジュール指定（スケールアウトするVM数も指定可能）
③メトリクス（CPU利用率など）の数値で自動スケールアウト

「え、すごい便利じゃん」と思ったが、下記情報あり。

※仮想マシン内にデータの保存はできますが、スケールインされるため、大切なデータは保存しない方が良いです。また、仮想マシン間でデータを共有する事もありません。

参考：https://www.cloudou.net/virtual-machine-scale-sets/vmss001/

…使えるケースが限られますね。（ログファイルとか消失するじゃん）
保存が必要なファイル（ログファイルなど）は別場所保管に設計すればいけるか。

2. 仮想マシン移行（オンプレミス to Azure）

2.1 Azure Site Rocovery

・実施前にDeploy Planner Toolを実行して情報収集をした方が良い。
　⇒ASR利用にあたるオンプレミスの情報がEXCELで出力される。
　　移行に必要な帯域幅や時間の情報を把握できる。
・構成サーバ、および移行元ホストはそれぞれHTTPSでAzureと通信し移行する。
　⇒443ポートで行うが、データ転送は9443ポートで行う。注意。
・Azure側ではリカバリーサービスコンテナ、ストレージアカウントが必要。

2.1.1 From Hyper-V

Hyper-VがSystem Center VMMで管理されている場合VMMが必要なケースあり。
移行元ホストにはAgentを導入する。
　

2.1.2 From Physical Server　

・構成サーバが必要。構成サーバがレプリケーション調整などを実施。
　⇒ちなみに構成サーバはSQL ServerでなくMySQLで稼動するらしい。
　⇒データ転送ポートを9443から変更することもできる模様。
・レプリケーション対象のサーバにはモビリティサービスエージェントを導入する。
・ASR自体はフェールバックも考慮したサービスだが、P2C移行になると
　フェールバックは難しい。物理サーバからの移行についてはP⇒Cへの一方向で考えたほうがよい。
　⇒ドキュメントを参照するかぎりできなくはないと思うが、あまり推奨しないということだろう。

2.1.3 From VMware

構成サーバーが必要。⇒OVFファイルがあるため、VMware上にデプロイするとよい。

2.2 Azure Migrate

・オンプレミスで稼働しているVMware上の仮想マシンを、Azureに移行した場合の
　「構成」や「費用」の確認ができるサービス（らしい）
・あくまでレポート情報を作成するだけであり、移行はASRで行う。
・VMware環境の情報収集に利用できる。（現在はHyper-Vも利用できる？）
　OVAファイル経由で収集用VMをデプロイし、収集結果をAzureへ送信し、その結果をレポートにまとめる、という流れか。
　（参考）https://www.cloudou.net/azure-migrate/mig001/

2.3 Data Migration Assistant

SQL Serverの移行などに利用。割愛。（おそらくAZ-103の範囲外）

2.4 ASRを利用しない移行

長期間のダウンタイムが許されるのであれば、下記方法もある。
①Hypre-VのVHDファイルをアップロードして使う
②Azure DataBoxでVHDファイルを移送して使う

3. カスタムスクリプト拡張、PowerShell DSC

Azureのカスタムスクリプト拡張機能と、DSCを使って、
デプロイした直後のVM 構成（エージェントやアプリ導入）を整理しましょう、という話のはず…（自信ない）

3.1 カスタムスクリプト拡張

・仮想マシンを作成したタイミングで、スクリプトを流せる機能。
・Win2008R2以上で利用可能。

3.2 PowerShell DSC拡張

・（Azureは直接関係ない）
・構成管理用の拡張機能。
・役割の有効化や環境変数の設定、ソフトウェアインストールなど構成に関することが色々できる。
・参考サイト：https://www.slideshare.net/kazukitakai/dsc-88799528

3.3 組み合わせてできること

・VMを作成した直後にウィルスソフトウェアインストール
・VM作成後のエージェント導入状態を同じくなるように管理
・その他いろいろ

4. 所感

・カスタムスクリプト拡張、PowerShell DSC あたりがPlurasightになかったので独学。
　⇒内容および範囲があっているのかどうか不安。
・ASRは業務で抑えていたのでおさらいレベル。
・スケールセットは可用性セットのことかな、と完全に勘違いをしていたので、把握できてよかった。

Azure Administratorへの道（３回：ストレージ関連）

2020-12-26T12:58:15+09:00

Qrunchからお引越しした記事です : created_at: 2019-08-24 15:55:30 +0900

備忘録的に覚えておきたい箇所を列挙メモ。

スキルの評価対応

ストレージの作成と管理

Azure バックアップの実装

・Recovery Service Vault ⇒　日本語だとリカバリーサービス「コンテナ」になる。
　（日本語もボルトに統一してくれよ…最初Valutって書かれていてピンとこなかったよ…）
・File単位のリストア
　⇒リストア結果をディスクとして一時マウントする仕組み。
・Azure Backup Agent（MARS：Microsoft Azure Recovery Services）
　オンプレ側のマシンに導入。ファイルなどのバックアップができる。
　こちらもリストア時は一時マウントになる。
・Azure Backup Server （MABS：Microsoft Azure Backup Server）
　MARSでカバーできない範囲をバックアップしたいときに導入が必要。
　マシン全体のバックアップやアプリケーションのバックアップなど。

ストレージアカウント

・レプリケーション
　LRS（ローカル冗長）、ZRS（ゾーン冗長）、GRS（地理冗長）に加えて、「RA-GRS」（読み取り可能な地理冗長）がある。
　GRSは通常、レプリケート先のサイトの情報はMSしかアクセスできない（MSが復旧処理するまで使えない）が、
　RA-GRSは平常時でもアクセス可能。
・アカウントの種類
　BLOB、Storage（V1）、StorageV2がある。
　①BLOB：BLOBしか使えない。
　②V1：ページ、キュー、テーブル、BLOB全部使える。クラシックのリソース管理用。
　③V2：ページ、キュー、テーブル、BLOB全部使える。リソースマネージャでの管理。
　通常、V2一択。
・アクセスキー
　このキーを渡すとストレージに対してフルアクセスできる。
　（何でもできるので取り扱い注意）
　キーの値はリフレッシュ（更新）でき、定期的な更新が推奨される。
・SAS：Shared Access Signature
　アクセスキーとは違い、アクセス内容を制限できるアクセス署名。
　読み取りのみ許可、アクセス元IPレンジの制限、プロトコルの制限、期間の制限、などなど。
・Stored Access Policy
　期間を決めてアクセス許可を設定できるポリシー。
　SASより大雑把なサービス（BLOB、キュー、テーブル、Files）レベルの制御。
・Azure Key Vault
　日本語だと「キーコンテナ」。
　色々なキーを管理するサービスだが、ストレージアカウントキーの自動管理もやろうと思えばできるらしい。
・AzureAD&RBACを利用したアクセス制御
　BLOBとキューのみ制御可能。
　AureAppServiceからストレージコンテナへのログファイル書き出し、などに有効。
　IAM制御にてAppServiceに対して必要なロールを割り当ててやればいい。
　（IAM制御でユーザだけでなくAppにも権限を割り当てできるのは初耳だった）
・暗号化
　デフォルトでMSのキーによって暗号化されている。
　独自のキーで暗号化することも可能。その場合、暗号化のキーをAzure Key Vaultで管理する必要がある。
・ネットワークアクセス
　デフォルトでインターネット上のどこからでも接近できる。
　設定変更によりアクセス可能なバプリックIPを指定したり、VNet内からアクセス可能にできる。
　⇒Vnet側のほうにもサービスエンドポイントの設定が必要。
・StorageExplorer
　ストレージの中身を参照するツール。Desktop版とWeb版があり、Web版はPortalから使える。
・診断ログ
　診断設定をオンにしている場合は「$logs」というBLOBコンテナにログが格納される。
　StorageExplorerでファイルを取得できるらしい（が、WEB版のStorageExplorerで参照しても該当コンテナが無かった）
　取得したログはMicrosoft Message Analyzerで解析すると見やすい。
・メトリック
　メトリックも診断設定をオンにしているとテーブルに出力される模様。
　メトリック情報からアラートを作成したりできる。

BLOB Storage

・ストレージアカウントのうち、「BLOB」に該当する箇所の補足追記。
・BLOBの形式は３種類。
　①Block Blob
　　複数ブロックに分けられたBLOB。ファイル追加、削除など普通に使う場合はこれ。4.7TBまで。
　②Append Blob
　　追加のみのBLOB。ログ保管など、ファイルの変更や削除をしない場合に使う。
　③Page Blob
　　VMのディスク（VHD）を置く。最大8TBまで。
・ストレージ層
　StorageV2のアカウントでのみサポート。次の３種類。
　①ホット：データ保存のコストが高く、データアクセスのコストが低い（頻繁に更新する場合に推奨）
　②クール：データ保存のコストが低く、データアクセスのコストが高い（保管メインの場合に推奨）
　③アーカイブ：最もデータ保存のコストが低いが、データ取り出しに数時間単位でかかる（長期保管用）
　※注意：ストレージ層を変更（移動）するとその移動量に対して課金される。（データアクセス分の課金がかかる）
　既定でホットにするかクールにするかをストレージアカウントで設定できる。
・コンテナ
　BLOBサービス内に無制限に作成できる。
　外部からのアクセスレベルを設定できる。
　①Private Access Level（デフォルト）
　　認証が必要。匿名アクセス不可。
　②Blob Access Level
　　BLOBへ読み取りアクセスはできるが、コンテナの内容をリスト化して閲覧することはできない。
　　⇒URLを知っている特定ファイルにしかアクセスできない
　③Container Access Level
　　指定のコンテナの内容をリスト化して閲覧できる。
・コンテナには不変ストレージの設定ができる。(WORM：Write Once Read Many　ともいう）
　この設定をするとアップロードしたデータの更新・削除ができない。
　⇒更新してはならないケース（金融、医療、法律、保険分野など）で利用する。
　一定期間は削除不可、またはホールド（Legal Hold）解除するまでは削除不可のどちらかを指定できる。
・Lifecycle Management
　ファイルのライフサイクルを指定できる。
　N日経過後にクール層へ移動、M日経過後にアーカイブ層へ移動、X日経過後に削除、のような指定ができる。
　⇒削除のポリシーはBLOBスナップショットごと削除してくれる。
・静的Webサイトホスティング
　有効にし、HTMLやCSS、Javascript、画像ファイルなどをアップロードするとWEBサイトとして使える。
　カスタムドメインの設定も可能。
・AzCopy
　BLOBにファイルをアップロードするコマンドラインツール。バッチ処理向き。
　どことなくrobocopyチック。指定オプションも沢山ある。
・ストレージ操作の.NETのライブラリもあるため、PGに組み込みで使える。
・Azure Search
　Azure Searchでストレージ内検索ができる。
　Azure Search自体はAzureのクラウド検索システム。
　前文検索的な動きをして、呼び出しもとに結果を返してくれる。
　プログラムに組み込んで使う。コグニティブのオプションで画像内検索とかもできるらしい。
　BLOB内のファイルにメタデータをつけていればメタデータでの検索も可能。

Azure CDN

・ユーザにコンテンツを分散して配信するサービス。（書いててもよく分からない…）
・BLOBストレージに置いて展開したいファイルへのアクセスについて、
　ユーザは世界中に存在するエッジサーバからファイルを取得できるようになる。
・なので「ゲームの新作トレーラーを0時に世界同時公開！」とかそういう時に利用することで、
　ユーザがすばやくアクセスできたり、中央サーバへの負荷やトラフィックが抑えられる、という感じか。
　（現状、業務で使うことはなさそうだな…）
・製品（価格帯）が４つある。
　Azure CDN Standard from Microsoft
　Azure CDN Standard from Akamai
　Azure CDN Standard from Verizon
　Azure CDN Premium from Verizon
・プロファイルを作成し、ストレージアカウントに割り当てる。
　その際にエンドポイント名称（グローバルで一意）を決める。
・CDNには次のURLでアクセスする。
　http://(EndpointName).azureedge.net/(myPublicContainer)/(BlobName)
・基本、CDNを使うときBLOBストレージのアクセスレベルはBLOBかContainer（外部アクセス可）である。
　これをPrivateのままにしたい場合はSASトークンを利用してアクセスする。
　この場合、URLの後ろにSASトークンを付与する。
・「URLの後ろにSASトークンつけると結局SASトークンが公開されていることになる！困る！」と言うときは
　「Premium from Verizon」であればURL書き換え機能で対応できる。
　これで、指定のURLにアクセスした際に自動でURL末尾にSASトークンを付与するようにできる。
・利用の際、CORS（クロスオリジンリソース共有）を考慮する必要があるらしい。（何だそれは…）
　通常下記の通りらしい。

クロスサイトスクリプティング攻撃の可能性を低減させるために、すべての最新の Web ブラウザーには
同一オリジンポリシーと呼ばれるセキュリティ制限が実装されています。
これにより、Web ページは他のドメイン内の API を呼び出すことができません。

　これをなんとかするための話らしい。

CORS (クロスオリジンリソース共有) は、あるドメインで実行されている Web アプリケーションが
別のドメイン内にあるリソースにアクセスできるようにする HTTP 機能です。

　CSNのCORSの欄で設定可能。

Azure Files

・ストレージアカウントのうち、「File」に該当する箇所の補足追記。
・SMBプロトコルを介してアクセスできるのがBLOBとの最大の違い。
　⇒ファイル共有をクライアントPCでマウントできる。
・ファイル共有で利用する場合、SMB（2.1 or 3.0）でやりとりする。3.0は通信が暗号化されている。
・クライアントが445ポート(SMB)が空いていてインターネットと疎通できないと使えない。
　⇒REST API経由でやりとりする分にはHTTPS(443)で通信できればよい。
　　なのでPowershell経由やCLI経由であれば443でいける。
・クライアントのOSがSMB3.0をサポートしていないと使えない。（Win8.1以降）
　⇒ストレージアカウントと同一リージョン内のAzure VMならWin2008R2でも接近できる模様。
　　（おそらく：同一リージョン内の通信はイントラ扱いになっているから○という感じか）
・AzureAD認証をサポート。
　…しているが、アクセスするにはクライアントマシンがAzureAD DomainService（AADDS）に参加している必要がある。
　また、ADDSドメイン（オンプレやVMのドメコン）に参加しているマシンはAADDSに参加できないため使えない。
　AADDSに参加できるのはAzureのマシンなので、オンプレにいるクライアントPCでも使えない。（使える範囲が狭すぎるよ…）
　⇒後述のAzure File Syncを使え、とのこと。
　⇒また、完全な管理者権限が必要な場合はアクセスキーでアクセスする。（AADDSで管理者権限を割り振っても完全でない）
・ファイル共有の最大割り当てサイズは5TBまで。（ストレージアカウント全体では500TB）
　最大ファイルサイズは1TB。
・スナップショットバックアップの取得が可能。
　取得している場合、ファイル共有でファイルのプロパティ「以前のバージョン」より過去ファイルの閲覧・取得が可能。
・AzureBackupを利用した定期的なスナップショット取得もできる。
　⇒1日1個までらしい。

Azure File Sync

・以下、参考サイト。
　https://cloud.nissho-ele.co.jp/blog/azure-file-sharing/
・Azure Filesとファイルサーバの内容を同期するサービス。
　ファイルサーバは複数台立てることができるため、複数のファイルサーバがAzure Filesを通してファイル内容を同期することができる。
・ファイルサーバを「サーバエンドポイント」、Azure Fileを「クラウドエンドポイント」と呼ぶ。
　１つの同期グループにおいて、クラウンドエンドポイントとサーバエンドポイントは1:Nの関係。
・Azure FilesのバックアップがAzureBackupでできるため、それをもってファイルバックアップとすることができる。
・障害発生時もAzure Filesからファイル復旧できる。
・実ファイルはFilesに保持させ、ファイルサーバ上ではポインタ（ショートカットのようなもの）のみ配置することもできる。
　これをすることによりファイルサーバのディスク容量を節約できる。
・ファイルサーバにエージェントを導入する必要がある。
・Azure File Syncはストレージアカウントと同一リージョンにデプロイする必要がある。
・同期で帯域を食う場合にはQoSをかけられる。（powershell経由）
・ファイルサーバはAzure Filesのファイル共有の要件（SMBのバージョン、ポート445解放）を満たす必要がある。
・ファイルサーバ側にファイルを置くと速やかにAzure Filesに連携される。
　が、Azure Filesに直接ファイルを置くとファイルサーバへの連携に1日かかることもある。（らしい）
・DFS名前空間と組み合わせて使うことができる。

インポートジョブ

・HDDの内容をBLOBコンテナに移動することができる。
・最初に、対象HDDをNTFSフォーマットした後、BitLockerで暗号化する。
・その後、waimportexportツールを使用し、インポート準備ファイル(jrnファイル)を作成する。
　⇒V1とV2がある。ストレージアカウントがStorageV1、V2の時はV2ツール、BLOBストレージの時はV1を使う。
　⇒V2では定義（対象ファイルやドライブ情報）などをCSVに記載して管理する。
　　Dataset用CSVに対象ファイルを列挙すれば、自動で対象HDDにファイルを収集してくれる。
・その後、AzurePortalからインポートジョブを作成。
　この際、作成したjrnファイルやインポート先のストレージアカウントを指定する。また、配送に関する情報もあわせて入力する。
・ジョブ作成後、ディスクを指定の住所に発送する。だいたいMSの準備が済むまで7～10日くらいかかる。（SLAはない）
　⇒すぐインポートしなければならない、という要件がある場合はマッチしない。
・発送後、追跡情報の更新（おそらく発送連絡）をする必要がある。
　これを2週間以内に実施しないと自動的にジョブがキャンセルになってしまう。
・到着後、自動的にストレージアカウント内にファイルが追加されている。

エクスポートジョブ

・Azureストレージの内容をHDDに移すことができる。
・まず、エクスポートジョブを作成する。（配送会社や住所の設定、対象ストレージアカウントの設定）
・NTFSフォーマットしたHDDを発送。
　⇒返送時はBitLockerで暗号化された状態で帰ってくる。
・インポートと同様に配送状況の更新は必須。
・届いたディスクを接続し、BitLockerのキーを入力しデータにアクセスできることを確認。

Azure Data Box

・こちらはAzure側でデータ格納デバイスを用意してくれるデータインポートサービス。
・注文⇒デバイスが届く⇒データを入れる⇒返送⇒データが反映される

所感

・全然業務で使わないような箇所も勉強できて、いい機会にはなった。
・ストレージアカウント周辺は「なんとなく」から「ややしっかり」の理解になった。よかった。
・インポート、エクスポート、DataBoxは仕組みを把握しておくと将来役に立つ日がくるかもしれない。
・Filesは便利だけど使う日がくるかな…
・CDNはたぶう使う日はこない。（転職か異動がないかぎり）

Azure Administratorへの道（２回：Azure MFA）

2020-12-26T12:56:04+09:00

Qrunchからお引越しした記事です : created_at: 2019-07-13 16:30:22 +0900

スキルの評価対応

アイデンティティの管理
　> Multi-Factor Authentication (MFA) の実装

MFAとは

Multi-Factor Authentication
多要素認証のこと。

「アカウント + パスワード」より強固なセキュリティを担保しないといけない時に使う。

適用範囲

AzureのSaaS
AzureのPaaS
AzureのIaaS上に構築したアプリケーション
Azureとつながっているオンプレミス上のアプリケーション
Office 365

などなど

認証方法

電話
電話がかかってくるので、それに出て「#」をプッシュ。
PINの入力を要求するモードもあり。
SMS
1Way：SMSで通知したパスワードを画面に入力。
2Way：SMSでパスワードが通知されるので、同じ番号をSMSで返答する。
どちらもPINコードの追記を要求するモードあり。
アプリ認証
MSのアプリを起動して、アプリから認証する。
PINコードの追記を要求するモードあり。
OATH
MSのアプリから発行されるセキュリティトークン（6桁数字）を求められる。
MSのアプリでないOATHトークンアプリ（Googleのやつとか）でも利用できる。

認証情報の保管

Azure Active Directoryに保管。なのでAADがある環境が前提。

MFA Server

・認証方法によっては必要。
・オンプレミス上のアプリからMFAを利用する際に必要？
・オンプレミス上のサーバに構築する。
・オンプレミスのADやLDAPなどとユーザ情報を同期できる。
　AzureMFA⇔MFA Server⇔オンプレのドメコン
・複数台構築し、内容を同期することが可能。
　⇒冗長性担保。
・ドメコンにインストールするのは不可。

所感、感想

・多要素認証。7 Payの事件で一躍有名になったね。
・今の仕事だと使わなそうだなー。
・銀行系（ネットバンキング）とかだと必須ですね。

Azure Administratorへの道（１回：Azure Policy）

2020-12-26T12:53:17+09:00

Qrunchからお引越しした記事です : created_at: 2019-07-03 22:35:48 +0900

スキルの評価対応

Azure サブスクリプションおよびリソースを管理する。
タグでできることはなんとなくわかるので、使ったことの無いAzure Policyを勉強。

Azure Policyとは

・Azureの利用者にできることを制限する統制の仕組み。
・RBACによる権限制御はあくまでリソースへのアクセスレベルの話だが、Policyはもっと細かい制御ができる。
　⇒たとえば、「タグ付けのルール」、「LinuxのVMはデプロイさせない」、「Win2008R2は使わせない」などなど。
・制御する以外にも、ルールが守られているかのチェックにも使える。
　⇒「ルール」に大して「守られているかチェックする」、「ルールを強制する」などのレベルが選べる。

定義と割り当て

・イニシアチブ定義とポリシー定義がある。
・ポリシー定義は１つのルール。イニシアチブ定義はポリシー定義を束ねたもの。グループみたいなものか。
・割り当てのスコープも指定できる。
　⇒リソースグループ単位や、サブスクリプション単位、管理グループ（サブスクリプションの集まり）単位、など。
・割り当てたスコープについて、ある特定リソースやリソースグループは除外することができる。

ポリシーの作り方

・デフォルトで使えるビルトインの定義がある。
・ビルトインの定義でやりたいことができない場合は自分で定義を作成する。
・定義はJSON形式で記述。
・GitHubに色々ポリシーが公開されている。
・定めたルールが守られない場合に実施される効果を次の中から選べる。

Deny はアクティビティログでイベントを生成し、要求は失敗します
Audit: アクティビティログ内に警告イベントを生成しますが、要求は失敗しません。
append は定義済みのフィールドセットを要求に追加します。
AuditIfNotExists: リソースが存在しない場合に監査を有効にします。
DeployIfNotExists: リソースが存在しない場合にリソースをデプロイします。
Disabled: リソースがポリシー規則に準拠しているかどうかを評価しません。

引用元

実践

デプロイしたリソースにタグ付けをするPolicyを作ってみる。

・ビルトインポリシー「タグとその既定値の追加」の割り当てを実行。
　リソースグループに対して割り当て。
・タグ「env:test」を付与するように設定。
・VNetをデプロイ。
・デプロイされたVNetにタグ「env:test」が付与されていることを確認。

所感

・タグの強制は便利。タグでのコスト管理を実施する際に活かしたい。
・大きい組織でAzureの利用者が沢山いるときにはとても有用そうな機能。

Azure Administratorへの道（０回：受験申し込み）

2020-12-26T12:52:04+09:00

Qrunchからお引越しした記事です : created_at: 2019-06-27 22:52:22 +0900

経緯

遠まわしにAzureの資格を取るように上司に言われたので頑張って取る。

取得する資格の選定

とりあえず基礎知識はある（はず）なので、Azure Administratorの取得を目指す。
AZ-103

参考にした情報

こちらの方のSlideshare
https://www.slideshare.net/AkiraMidouchi/azure-142750519

申し込み

Microsoftの資格試験初申し込み。

ExamReplayという落ちても１回だけ再受験できる制度があるらしい。
mindhubでバウチャーを購入し、そのコードで申し込み。
⇒最初良く制度が分からなく、バウチャーなしで申し込みしてしまった。
　１回で受かる自身がないので、キャンセルしてバウチャー購入⇒再申し込みした。

今後の勉強方針

Pluralsightでスキルチェック⇒動画視聴⇒再スキルチェック
azure環境で実際に操作してみる
Qrunchで学習内容をまとめる。（アウトプット）

所感（と言う名の愚痴）

・Azureの試験は頻繁に更新されていて、正直あまり取る気がしない…
　⇒取得してもまた資格体系が更新されたりするのでは
・9月までに合格するように目標をたてたが、正直受かる気がしない。がんばろ。
・ベンダ資格は費用が高いなぁ…自腹はきつい。

Dockerの学習 #5 （Wordpressを使おう　その２：Wordpressセットアップ）

2020-12-26T12:48:40+09:00

Qrunchからお引越しした記事です : created_at: 2019-05-19 15:22:58 +0900

前回MySQLをセットアップしたので、今回はWordpress本体の設定をしていく。
Web公開するのであればApacheも必要だが、今回は割愛。

成功するまでだいぶ試行錯誤したので、その流れを記載。

Wordpressセットアップ

１回目の失敗：ポートフォワーディング設定漏れ

コマンド実行してコンテナ作成。（最初はこれだけで終わると思っていた）
docker run --name wp_con01 wordpress

作成自体は正常に終了。psコマンドで確認するとポートは80番。
http://192.168.99.100（DockerのIP）へブラウザから接続。
⇒接続できない。

色々調べてみると、ホスト側とコンテナ側でポートフォワーディングの設定を実施しないと接続できない様子。

というわけで、stopでコンテナ停止、rmでコンテナ削除を実施した後に、再度コンテナ作成。
docker run --name -p 8080:80　wp_con01 wordpress

これでホスト側の8080番ポートとコンテナ側の80番ポートのフォワーディング設定が実施された。
psで参照するとこんな感じ。

CONTAINER ID        IMAGE               COMMAND                  CREATED        STATUS              PORTS                               NAMES
eb276daaee38        wordpress           "docker-entrypoint.s"    3 hours ago    Up 3 hours          0.0.0.0:8080->80/tcp                wp_con01

この状態でhttp://192.168.99.100（Docker VMのIP）:8080へブラウザから接続。
⇒無事接続完了！

2回目の失敗：コンテナ間のネットワーク設定

無事Wordpressの設定も完了したので、ブラウザから設定を進める。
が、MySQLの設定内容を埋めて先に進もうとするとDB接続エラーが発生する。

「そもそもコンテナとコンテナってNW接続って許可されているんだろうか？」
と、思い色々調査すると、接続させるには設定が必要なことが判明。

方法としては--linkでつなげるか、ネットワークを作成しそのネットワークにコンテナを所属させるか、の２通り。
--linkは今後使われなくなる非推奨オプションらしいので、ネットワーク参加の方で設定を実施。

まず、ネットワークを作成。
docker network create my_network
作成後、確認。

$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
83102481c8be        bridge              bridge              local
0568528ca361        host                host                local
ef68ec9b2ee9        my_network          bridge              local
d00080a53d5d        none                null                local
$

基本、何も指定していないとデフォルトの「bridge」ネットワークに所属するらしいのだが、
このネットワークはDNSの設定がなく、コンテナ名で名前解決ができないらしい。

ネットワークを作成したので、そのネットワークに所属させる形でコンテナ再作成。
前回作成したMySQLのコンテナも作り直す。

また、接続に必要な情報を全部環境変数指定してやる方向に変更した。
docker run --name mysql -p 3306:3306 --network my_network -e MYSQL_ROOT_PASSWORD=password -e MYSQL_USER=wp_user -e MYSQL_PASSWORD=password -e MYSQL_DATABASE=wordpress mysql

--networkで所属ネットワークを作成したmy_networkに指定。

（環境変数の補足）
・MYSQL_ROOT_PASSWORD：管理者パスワード
・MYSQL_USER：ユーザ名
・MYSQL_PASSWORD：ユーザのパスワード
・MYSQL_DATABASE：データベース名

続けてWordpressのコンテナ。こちらも接続に必要な情報を環境変数で指定。
docker run --name wp_con01 --link mysql_con01:mysql -p 8080:80 -e WORDPRESS_DB_USER=wp_user -e WORDPRESS_DB_PASSWORD=password wordpress

こちらも所属ネットワークをmy_networkに指定。

（環境変数の補足）
・WORDPRESS_DB_USER：接続ユーザ
・WORDPRESS_DB_PASSWORD：接続ユーザのパスワード

これでうまくいくはず、と思いきや、再度エラー。

3回目の失敗：MySQLのコンテナ名

Wordpress側で次のエラーが発生。mysqlのサービスがない旨のメッセージ。
MySQL Connection Error: (2002) php_network_getaddresses: getaddrinfo failed: Name or service not known

ネットで調査してみると「コンテナ名をmysqlにしないとエラーになる」旨の情報あり。

※--linkで（--link test-mysql:mysql）と指定すれば問題なさそうだった。
　ただし、今回は--linkを利用しない方向にしたので、コンテナ名を泣く泣くmysqlに変更。
　また、docker-composeでの構築であればコンテナ名はmysqlでなくとも問題なさそう？
　ほかに何かよい方法があるのかもしれない。

この状態で再度Wordpressのコンテナを作成したところ、再度エラー。（orz）

4回目の失敗：MySQLの認証設定

Wordpress側で次のエラーが発生。どうも認証周りで失敗している模様。
MySQL Connection Error: (2054) The server requested authentication method unknown to the client

エラーメッセージで調べてみると、MySQL内ユーザの認証方式を弄ってやらないといけなそうなことが判明。
EXECでMySQLのコンテナに接近し、ALTER文を発行。

$ docker exec -it mysql mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 18
Server version: 8.0.16 MySQL Community Server - GPL

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> alter user wp_user identified WITH mysql_native_password by 'password';
Query OK, 0 rows affected (0.13 sec)

※ALTER文：alter user [wordpress接続ユーザ] identified WITH mysql_native_password by '[wordpress接続ユーザのパスワード]';

実行後、再度Wordpressコンテナ作成。
⇒今度はエラーなし！！！！！！

http://192.168.99.100:8080から、ようやく初期設定画面に遷移できた。（つかれた・・・）

まとめ

まとめると、次の流れが必要だった。
- １．ネットワークの作成
docker network create my_network
・コンテナを所属させるネットワークの作成。

２．MySQLコンテナの作成
docker run --name mysql -p 3306:3306 --network my_network -e MYSQL_ROOT_PASSWORD=password -e MYSQL_USER=wp_user -e MYSQL_PASSWORD=password -e MYSQL_DATABASE=wordpress mysql
・名前は「mysql」で作成。
・作成したネットワークに所属させる。
・環境変数にてユーザやデータベース情報の設定もしてしまう。
３．MySQLの設定変更
docker exec -it mysql mysql -u root -p
mysql> alter user wp_user identified WITH mysql_native_password by 'password';
・MySQLにて、Wordpress用のユーザの認証方式をNativeに変更してやる。
４．Wordpressコンテナの作成
docker run --name wp --network my_network -p 8080:80 -e WORDPRESS_DB_USER=wp_user -e WORDPRESS_DB_PASSWORD=password wordpress
・ホストからアクセスするにはポートフォワーディングの設定が必要。
・作成したネットワークに所属させる。
・環境変数にて接続情報の設定もしてしまう。

所感

・すごい苦労したが、ネットワーク等含めてコンテナの考え方を学べてよかった。
・実際に手を動かすのがやっぱり大事。
・途中で心が折れそうだったけど、無事作成できてよかった。
・ネット上はだいたい「--link」でつなげてる情報ばっかりだった。
・Dockerに限らずそうだけど、問題が基盤（コンテナ）、ミドルウェア、アプリのどれにあるのかの切り分けが大事、かつ難しい。

Dockerの学習 #4 （Wordpressを使おう　その１：Mysqlセットアップ）

2020-12-26T12:46:08+09:00

Qrunchからお引越しした記事です : created_at: 2019-05-19 15:15:39 +0900

今回から実際に手を動かして行こうと思う。
とりあえず小さな目標として、ローカル環境でWordpressの利用ができるところまでをやってみる。

参考URL

https://qiita.com/ymstshinichiro/items/01f6a4c299fdb4b832a2
MYSQLへのログイン。

MySqlのセットアップ

Wordpress自体あまり詳しくないが、どうやらMySQLが必要みたいとの情報をどこかでみた。
MySQLのセットアップをやっていく。

まずイメージファイルの有無を確認。

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED
SIZE
mysql               5.7                 2f52e94d8acb        3 weeks ago
373MB
mysql               latest              d72169616e20        3 weeks ago
443MB
wordpress           latest              837092bc87de        5 weeks ago
421MB
php                 latest              750fb3e3d6ef        6 weeks ago
367MB
httpd               latest              d4a07e6ce470        6 weeks ago
132MB
hello-world         latest              fce289e99eb9        4 months ago
1.84kB
php                 7.0-apache          aa67a9c9814f        4 months ago
368MB
docker/whalesay     latest              6b362a9f73eb        3 years ago
247MB

以前落としていたのがあるっぽい。
なければそのまま次でRUNを実行すれば自動でイメージも取得してくるはず。

ではrunを実行。コンテナに「--name」オプションで名前をつけて実行。

$ docker run --name mysql_con01 mysql
error: database is uninitialized and password option is not specified
  You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and
 MYSQL_RANDOM_ROOT_PASSWORD

「MYSQL_ROOT_PASSWORD」、「MYSQL_ALLOW_EMPTY_PASSWORD 」、「MYSQL_RANDOM_ROOT_PASSWORD」
のどれかを指定しろとのこと。環境変数を「-e」で指定。

$ docker run --name mysql_con01 -e MYSQL_ROOT_PASSWORD=password mysql
F:\Docker Toolbox\docker.exe: Error response from daemon: Conflict. The containe
r name "/mysql_con01" is already in use by container "a72e4d4a02636be1f3c73722e8
9b0a1d2ab66a55abffb31b3c18a87de5586b4f". You have to remove (or rename) that con
tainer to be able to reuse that name.
See 'F:\Docker Toolbox\docker.exe run --help'.

・・・どうやらERRORが発生していてもコンテナ自体は作成されているようで、
同一名称が存在する旨のエラーが表示された。削除していく。

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED
STATUS              PORTS               NAMES

psコマンドで見てもコンテナは出てこないな・・・。
あ、オプションは無しだと実行中のコンテナしか出ないからか。

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED
     STATUS                     PORTS               NAMES
a72e4d4a0263        mysql               "docker-entrypoint.s"   3 minutes ago
    Exited (1) 3 minutes ago                       mysql_con01
8adaae58b85c        docker/whalesay     "cowsay Hello World!"    2 weeks ago
     Exited (0) 2 weeks ago                         heuristic_torvalds
e2d544b0e813        docker/whalesay     "Hello-World!"           2 weeks ago
     Created                                        hardcore_pasteur
64cc887485f4        docker/whalesay     "Hello World!"           2 weeks ago
     Created                                        gifted_robinson
223951c34db3        hello-world         "/hello"                 2 weeks ago
     Exited (0) 2 weeks ago                         laughing_antonelli

やはりあるみたいね。消します。

$ docker rm mysql_con01
mysql_con01

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                 CREATED
    STATUS                   PORTS               NAMES
8adaae58b85c        docker/whalesay     "cowsay Hello World!"   2 weeks ago
    Exited (0) 2 weeks ago                       heuristic_torvalds
e2d544b0e813        docker/whalesay     "Hello-World!"          2 weeks ago
    Created                                      hardcore_pasteur
64cc887485f4        docker/whalesay     "Hello World!"          2 weeks ago
    Created                                      gifted_robinson
223951c34db3        hello-world         "/hello"                2 weeks ago
    Exited (0) 2 weeks ago                       laughing_antonelli

無事消えました。気を取り直して再実行。

$ docker run --name mysql_con01 -e MYSQL_ROOT_PASSWORD=password mysql
Initializing database
2019-05-19T05:39:10.121840Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic
 links using --skip-symbolic-links (or equivalent) is the default. Consider not
using this option as it' is deprecated and will be removed in a future release.
2019-05-19T05:39:10.122801Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (my
sqld 8.0.16) initializing of server in progress as process 27
2019-05-19T05:39:59.746085Z 5 [Warning] [MY-010453] [Server] root@localhost is c
reated with an empty password ! Please consider switching off the --initialize-i
nsecure option.
2019-05-19T05:40:25.020508Z 0 [System] [MY-013170] [Server] /usr/sbin/mysqld (my
sqld 8.0.16) initializing of server has completed
Database initialized
MySQL init process in progress...
MySQL init process in progress...
MySQL init process in progress...
2019-05-19T05:40:29.693459Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic
 links using --skip-symbolic-links (or equivalent) is the default. Consider not
using this option as it' is deprecated and will be removed in a future release.
2019-05-19T05:40:29.693540Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (my
sqld 8.0.16) starting as process 78
2019-05-19T05:40:32.312165Z 0 [Warning] [MY-010068] [Server] CA certificate ca.p
em is self signed.
2019-05-19T05:40:32.389363Z 0 [Warning] [MY-011810] [Server] Insecure configurat
ion for --pid-file: Location '/var/run/mysqld' in the path is accessible to all
OS users. Consider choosing a different directory.
2019-05-19T05:40:32.432437Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: re
ady for connections. Version: '8.0.16'  socket: '/var/run/mysqld/mysqld.sock'  p
ort: 0  MySQL Community Server - GPL.
2019-05-19T05:40:32.713605Z 0 [System] [MY-011323] [Server] X Plugin ready for c
onnections. Socket: '/var/run/mysqld/mysqlx.sock'
Warning: Unable to load '/usr/share/zoneinfo/iso3166.tab' as time zone. Skipping
 it.
Warning: Unable to load '/usr/share/zoneinfo/leap-seconds.list' as time zone. Sk
ipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it
.
Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skippin
g it.

2019-05-19T05:40:49.327025Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Sh
utdown complete (mysqld 8.0.16)  MySQL Community Server - GPL.

MySQL init process done. Ready for start up.

2019-05-19T05:40:49.617494Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic
 links using --skip-symbolic-links (or equivalent) is the default. Consider not
using this option as it' is deprecated and will be removed in a future release.
2019-05-19T05:40:49.617603Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (my
sqld 8.0.16) starting as process 1
2019-05-19T05:40:52.265763Z 0 [Warning] [MY-010068] [Server] CA certificate ca.p
em is self signed.
2019-05-19T05:40:53.604994Z 0 [Warning] [MY-011810] [Server] Insecure configurat
ion for --pid-file: Location '/var/run/mysqld' in the path is accessible to all
OS users. Consider choosing a different directory.
2019-05-19T05:40:53.648528Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: re
ady for connections. Version: '8.0.16'  socket: '/var/run/mysqld/mysqld.sock'  p
ort: 3306  MySQL Community Server - GPL.
2019-05-19T05:40:53.921685Z 0 [System] [MY-011323] [Server] X Plugin ready for c
onnections. Socket: '/var/run/mysqld/mysqlx.sock' bind-address: '::' port: 33060

ここで出力がStop。どうやら、この状態で待機し続けるらしい。
Ctrl + Cで一度抜ける。

MySQLへの接続を別プロセスで試行する。というわけでEXECコマンドを使用。

$  docker exec -it mysql_con01 mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.16 MySQL Community Server - GPL

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

無事接続できた！せっかくなので適当にSQL発行をして動作確認。

mysql> select Host,User from mysql.user;
+-----------+------------------+
| Host      | User             |
+-----------+------------------+
| %         | root             |
| localhost | mysql.infoschema |
| localhost | mysql.session    |
| localhost | mysql.sys        |
| localhost | root             |
+-----------+------------------+
5 rows in set (0.00 sec)

mysql> exit
Bye

問題なさそう。

まとめ

長々と記載したが、以下コマンドでコンテナ作っただけである。
docker run --name [コンテナ名] -e MYSQL_ROOT_PASSWORD=[パスワード] mysql

Dockerの学習 #3 （PS、IMAGES、COMMIT、PUSH、RM、RMI、(BUILD)）

2020-12-26T12:44:43+09:00

Qrunchからお引越しした記事です : created_at: 2019-05-14 22:08:42 +0900

ゴールデンウィークが終わり仕事が始まったため、ログを書く習慣が消えてしまった・・・
あわせて学習も止まってしまいそうだった。危ない危ない。
ちょっとずつでも前に進めていきたい。

今回は基本コマンドで学習してないとこの残りをさらっていく。

参考URL

1.とても分かりやすいサイト
https://morizyun.github.io/docker/about-docker-command.html
2.ドキュメント日本語化プロジェクト（主にコマンドリファレンスを参照）
http://docs.docker.jp/index.html
3.イメージのレイヤ構造について
http://enakai00.hatenablog.com/entry/20140802/1406958412

PS

コンテナの状況確認。

コマンド
docker ps [オプション]
表示例

$ docker ps
CONTAINER ID        IMAGE                        COMMAND                CREATED              STATUS              PORTS               NAMES
4c01db0b339c        ubuntu:12.04                 bash                   17 seconds ago       Up 16 seconds       3300-3310/tcp       webapp
d7886598dbe2        crosbymichael/redis:latest   /redis-server --dir    33 minutes ago       Up 33 minutes       6379/tcp            redis,webapp/db

例１：実行中のコンテナのみ表示
docker ps
オプション無しで実行中のみ表示。
例２：全コンテナ表示
docker ps -a
例３：条件を満たすもののみ表示
docker ps --filter "name=nostalgic"
"key=value"の形式で条件指定する。
この例の場合、コンテナ名にnostalgicを含むものを表示する。
keyに指定できるのは次の通り。コマンドリファレンスより引用。
> id（コンテナの ID）
> label（ label= か label== ）
> name（コンテナの名前）
> exited（整数値 - コンテナの終了コード。実用的なのは --all）
> status（created|restarting|running|paused|exited|dead）
> ancestor（ [:] 、、） - 特定のイメージから作られた子コンテナを作成します。
> before（コンテナ ID か名前） - 指定した ID か名前よりも前に作成したコンテナでフィルタ
> since（コンテナ ID か名前） - 指定した ID か名前よりも後に作成したコンテナでフィルタ
> isolation （default|process|hyperv）（Windows デーモンのみ）
> volume（ボリューム名かマウントポイント） - コンテナがマウントしているボリュームでフィルタ
> network（ネットワーク ID か名前）- コンテナが接続しているネットワークでフィルタ
例４：GOテンプレートを利用した整形
docker ps --format "table {{.ID}}\t{{.Labels}}"
（GO言語のテンプレートのことらしいが、使い道がよく分からない・・・）

IMAGES

イメージの一覧を表示。
Dockerのイメージファイルは元のイメージから修正箇所を層（レイヤ）として重ねていくようなものらしい。
オプション指定でそのレイヤ構造を把握することもできる模様。
基本的な使い方をする場合はあまり気にしなくてよいところか。
（レイヤの確認はdocker historyでもできる？）

コマンド
docker images [オプション] [リポジトリ[:タグ]]
表示例

$ docker images
REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
                                  77af4d6b9913        19 hours ago        1.089 GB
committ                   latest              b6fa739cedf5        19 hours ago        1.089 GB
                                  78a85c484f71        19 hours ago        1.089 GB
docker                    latest              30557a29d5ab        20 hours ago        1.089 GB
                                  5ed6274db6ce        24 hours ago        1.089 GB
postgres                  9                   746b819f315e        4 days ago          213.4 MB
postgres                  9.3                 746b819f315e        4 days ago          213.4 MB
postgres                  9.3.5               746b819f315e        4 days ago          213.4 MB
postgres                  latest              746b819f315e        4 days ago          213.4 MB

例１：イメージファイルを表示
docker images
何も指定しない場合。この場合、中間レイヤと呼ばれる細かいイメージの内容は表示されない。
例２：中間レイヤを含めてイメージ表示
docker images -a
例３：ダイジェスト値を表示
docker images -digest
例４：javaリポジトリのイメージを表示
docker images java
リポジトリ名称は完全一致。javとかでは×。

COMMIT

停止させたコンテナをイメージファイルにする。
基本、イメージファイルの管理はDockerfileを利用するのが望ましいため、
COMMITはデバッグやサーバ移動などの時に使うものらしい。
- コマンド
docker commit [オプション] コンテナ [リポジトリ[:タグ]]
- 例：コンテナ「c3f279d17e0a」をコミット
docker commit c3f279d17e0a svendowideit/testimage:version3

PUSH

レジストリへイメージへ送信する。PULLの逆。
- コマンド
docker push [オプション] 名前[:タグ]

RM

コンテナの削除。
- コマンド
docker rm [オプション] コンテナ [コンテナ...]
- 例１：コンテナ「redis」の削除
docker rm redis
- 例２：コンテナを強制停止させ削除
docker rm --force redis
SIGKILLシグナルを送信し、強制停止させる。

RMI

イメージの削除。
ショート ID かロング ID、タグ、digest を指定。
- コマンド
docker rmi [オプション] イメージ [イメージ...]
- 例１：test1の削除
docker rmi test1
- 例２：イメージIDが「fd484f19954f」のものを強制削除
docker rmi -f fd484f19954f
削除時にコンフリクトを起こす場合は-fか--force指定で強制削除できる。

BUILD

指定したソースコードからのコンテナ作成。
Dockerfileからの作成などで使う。
DockerfileおよびBUILDについてはその存在のみ確認して、今回は割愛。
（調査していると深みにはまりそうなので）

コマンド
docker build [オプション] パス | URL | -

所感

・これで一通り基本的なものはおさえた（はず）。
・DockerFileとBUILDに関しては後でしっかり時間を割いて理解する必要あり。
　ただ、DockerFileからは深い沼の香りがする・・・
・次回こそ色々触ってみるぞ！！！

Dockerの学習 #2 （コンテナの起動・操作コマンド　RUN、EXEC、ATTACH、STOP・KILL・START）

2020-12-26T12:43:06+09:00

Qrunchからお引越しした記事です : created_at: 2019-05-04 19:00:26 +0900

前回イメージファイルの取得まで勉強したので、今回は起動・操作・停止系の基本コマンドを勉強していく。

参考URL

1.とても分かりやすいサイト
https://morizyun.github.io/docker/about-docker-command.html
2.ドキュメント日本語化プロジェクト（主にコマンドリファレンスを参照）
http://docs.docker.jp/index.html
3.シグナルについて
https://qiita.com/hoto17296/items/07206f25d8cdfad4d358

RUN

イメージファイルを元にコンテナを起動する。
このコマンドでコンテナのディスク作成・メインプロセス（アプリケーションのプロセス）開始が実行される。
（RUNというコマンドなのに起動だけでなくMAKEまでするのか・・・）

コマンド
docker run [オプション] イメージ[:タグ|@ダイジェスト値] [コマンド] [引数...]
例１：イメージファイル「mysql」を元にコンテナ起動
docker run mysql
イメージファイルが無いときはイメージのダウンロードも自動実行される。
例2：イメージファイル・タグ指定でコンテナ起動
docker run ubuntu:14.04
タグの指定、ダイジェスト値の指定も可能な様子。
例３：コンテナに名前を付ける
docker run --name sql01 mysql
「--name」で任意の名前を付与。
付けない場合は自動で命名される。
例４：ポートのひも付け（ホスト⇔コンテナ）
docker run -p 8080:80 nginx
「-p ホストのポート:コンテナのポート」で指定。
上の例の場合、ホストの8080ポートへの通信はコンテナの80ポートへつながっている。
（NAPTみたいな動きをしてくれるってことかな？）
例５：起動したコンテナでBashを使う（既定のアプリでなくBashを起動する）
docker run -it --entrypoint /bin/bash mysql
Bashを使いたい今回のケースでは「--entrypoint」を指定する必要がある。
イメージファイルには「ENTRYPOINT」という「起動後に一番最初に実行するコマンド」が
定義されており、通常はそれが実行される。
⇒メインプロセスの実行コマンド、という解釈でよいはず。
このケースでは、まずBashを使いたいので、ENTRYPOINTをBashの実行（/bin/bash）で上書きしてやる。
⇒メインプロセスをBashにしてやる。
「-i」が「ホストの入力をコンテナの標準出力へつなげる」、
「-t」が「コンテナの標準出力とホストの出力をつなげる」。
大抵の場合IO両方を指定すると思うので「-it」とセットで使う模様。
「アプリケーションのプロセスは起動するけど、それとは別にBashを使いたい」というケースは
後述のEXECコマンドを使う。
例６：終了時にコンテナ削除
docker run -rm mysql
「-rm」でコンテナの終了時にコンテナを自動で削除してくれる。
補足
リファレンスによると、イメージファイルに定義された次の情報をRUN実行時に上書きできるとのこと。

・デタッチドあるいはフォアグラウンドで実行
・コンテナの識別
・ネットワーク設定
・実行時の CPU とメモリの制限
・権限と LXC 設定

　コンテナのリソース設定やネットワーク周りの詳細設定もできる模様。
　このあたりまで深く理解しようとすると頭がパンクしそうなので、後回し。
　⇒ただ、実運用するとなったら避けては通れなそう。

EXEC

コンテナに追加のプロセス（メインプロセスとは別のプロセス）を実行させる。
ターミナルアクセスなどに使う。

コマンド
docker exec [オプション] コンテナ名コマンド [引数...]
例１：メインプロセスとは別にBashプロセスを起動
docker exec -it web01 /bin/bash
「web01」というコンテナのBashを起動。
RUNの時と同様に「-it」をオプションにつける。
「-i」は「標準入力(STDIN)を開いたままにする」
「-t」は「擬似デバイス（ディスプレイ）へ接続」みたいな感じ。

ATTACH

実行中のコンテナのメインプロセスの標準入力、標準出力へ接続する。
ちなみに、接続後「exit」でメインプロセスを終了するとコンテナが停止する模様。

なお、コマンドの定義としては
「メインプロセス」=「PIDが1のプロセス」として扱っているらしい。

コマンド
docker attach [オプション] コンテナ名
例１：コンテナ「web01」のプロセスへ接近
docker attach web01

STOP・KILL・START

コンテナの停止と開始ができる。
「コンテナの停止」⇒「コンテナのメインプロセスの停止」
「コンテナの開始」⇒「コンテナのメインプロセスの開始」
という感じか。

コマンド
docker stop [オプション] コンテナ名
docker kill [オプション] コンテナ名
docker start [オプション] コンテナ名
STOPとKILLの違い
STOPは終了信号（SIGTERM）を送信し、一定時間経過後に強制終了信号（SIGKILL）を送信する。
KILLは強制終了信号（SIGKILL）を送信する。
強制停止の要否によって使い分けか。（シャットダウンとパワーオフ（電源オフ）の関係な様なものか）
例１：コンテナ「web01」を通常停止
docker stop web01
オプションなしでstopコマンドを利用した場合、
終了信号を送って10秒（デフォルト値）経過した後に、強制終了信号を送信する。
例２：コンテナ「web01」を通常停止、ただし強制停止までに1分まつ
docker stop -t 60 web01
「-t」または「--time」で強制終了信号送信までの時間を秒単位で指定することも可能。
例３：コンテナ「web01」を強制停止
docker kill web01
メインプロセスの強制終了時はKILL。
例４：コンテナ「web01」を開始
docker start web01
メインプロセスの開始。

所感

・RUNは奥が深そうだ・・・
　イメージファイルに定義されていることと違うことがしたい！って
　時は色々指定してやらないといけない、って感じか。
・今回の勉強内容でDockerの概念がだいぶ分かってきた。
　参考URL1に記載されているイメージ、コンテナ、プロセスの関係性の図が大分理解できた（気がする）。
・色んなサイトを見たときのコマンド例で、RUN時にポート番号指定している意味が全然分からなかった。
　けど、やっとわかった。
・次は残りの基本コマンドをサラッとさらって、その次は色々実践してみよう。

Dockerの学習 #1 （イメージファイルとPULLコマンド）

2020-12-26T12:39:59+09:00

Qrunchからお引越しした記事です : created_at: 2019-05-01 17:22:36 +0900

はじめに

Dockerコマンドの考え方がぼんやりしているので、簡単にまとめておく。
今回は「そもそもイメージファイルとは」という点とイメージファイルの取得（PULL）についてまとめる。

参考

https://morizyun.github.io/docker/about-docker-command.html
↑分かりやすい図がついている分かりやすいサイト。
https://hkdnet.hatenablog.com/entry/2017/06/18/190000#fn:1
↑イメージとタグの関係性について。
http://docs.docker.jp/index.html
↑ドキュメント日本語化プロジェクト（主にコマンドリファレンスを参照）

イメージファイルについて

・イメージファイル⇒コンテナを作るもと（みたいな解釈であってるはず・・・）
・イメージファイルはDocker Hub上で名前とタグで管理する。
・イメージファイル名は次のように管理されることが多い。（参考URLから引用）

例: nginx → Docker Hub にある nginx という公式イメージ
例: hkdnet/app → Docker Hub にある hkdnet さんの app というイメージ
例: hkdnet.net/nginx → hkdnet.net という Docker registry の nginx# PULL

・タグはイメージファイル１つにつき複数保持できる。
　ただし、イメージ内で一意である必要があり。大体バージョンや作成タイムスタンプなどを保持する様子。
・公開されているイメージファイルの中身は変動することがある。
　⇒バージョン値しか書いていないものなどはイメージ内容が変動することがあるらしい。
　そのため、当時のイメージ内容がほしい場合はタイムスタンプ指定、細かいリビジョン指定、
　または後述のダイジェスト値指定での取得をする必要がある。

PULL

レポジトリからイメージを持ってくる。
イメージファイルのダウンロードみたいな感じ。

コマンド
docker pull [オプション] 名前[:タグ] | [レジストリ・ホスト[:レジストリ・ポート]/]名前[:タグ]
例１：mysqlのイメージを取得
docker pull mysql
タグ指定がなしで最新版の公式イメージを取得。
例２：タグによるバージョン指定
docker pull ubuntu:14.04
前述の通り、バージョン14.04の最新リビジョンを取得する様子。
リビジョン単位で取得内容を固定したいのであれば、別のタグを使うほうが良さそう。
例３：関連するタグすべて取得
docker -a pull mysql
-a の代わりに --all-tagsでも良いとのこと。
例４：ダイジェスト値指定
そもそもダイジェスト値とは？
⇒Dockerイメージをリポジトリに登録（PUSH）したときに表示されるキーの様なもの。
PULLした時にも表示されるので、「以前PULLした時とまったく同じイメージがほしい！」というときは、
ダイジェスト値を控えておくとよいのでは。
docker pull ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
⇒「sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2」がDigest値
レポジトリ
何も指定しないとDocker Hubから取得する。
⇒なのでインターネットに接続できるように考慮が必要。プロキシ設定とか。
自分で管理しているレポジトリから取得する場合は、ホスト名やポート番号などを指定。
docker pull myregistry.local:5000/testing/test-image
⇒myregistry.localから5000番ポート経由でtest-imageファイルを取得
レポジトリの指定についてはプロトコルの指示（https://）は不要。
なお、認証が必要な場合はDocker Loginコマンドにて指定が必要な様子。

所感

・PULLの勉強だけで数時間つかってしまった・・・
・イメージファイルの概念が漠然としていたので、良い勉強にはなった。
・ローカルレポジトリも指定できるのは勉強になった。
　実際に企業で運用するときはどうしているのかが気になる。GitLab管理とかなのだろうか。

AzureFirewall [SNI TLS extension was missing]の理由

2020-12-26T12:13:58+09:00

前提

この記事は2019/6/4時点の内容です。（かつ、Qrunchからの移管記事です）
筆者の知識不足が著しいため、内容に誤り等ありましたらコメント欄にて指摘お願いします。

記事の目的

AzureFirewallのログを参照して
「[SNI TLS extension was missing]のメッセージとともに通信が拒否されている！
だけど何のことだかよくわからない！」という感じになっている人向けの内容です。
「メッセージの通りじゃん」となる有知識者はお帰りください。

結論

AzureFirewallを介するTLSで暗号された通信については、
Client Hello時にTLS拡張「server_name」が存在しない場合、通信が許可されない。
これはAzureFirewallの意図的な動作であり、仕様である。

経緯

Azure上のVMにソフトウェアをインストールし、そのソフトウェアのライセンス認証を
オンラインで実施しようとしたところ失敗した。
↓
VMがインターネットへでる際は
「VM⇒AzureFirewall⇒インターネット」の経路を通るため、AzureFirewallのログを確認。
↓
ライセンスサーバとの通信が拒否されたログを確認。
そこに[SNI TLS extension was missing]のメッセージが出力されているが、よくわからない。
（意味もよく分からないし、何で出ているのかもよく分からない）
↓
問い合わせした結果、上述の通り仕様であることが判明。
解決策としては「ライセンス認証に関するクライアント⇔サーバ間の通信内容の設定を変える」か、
「AzureFirewallを介さないで通信する」かのどちらかになる、とのこと。

ソフトウェアのサポートと話をしたところ、
「IPアドレス単位でFirewallの許可設定をしても同事象が発生するか確認してほしい」
といわれたのでNetworkRuleコレクションのほうで認証サーバのIPアドレスを許可したところ、
事象が解消しました。
（ApplicationRuleのみ発生する事象なのだろうか）

SNI、TLS拡張「server_name」とは

SNI（Server Name Indication）
1つのグローバルIPアドレスで、複数の証明書を利用できるようにする仕組み。
server_name
SNIを実現するためにのTLS拡張。
TLS通信を行う際のクライアント⇔サーバ間の手続き（TLSハンドシェイク）において、
最初にクライアント⇒サーバへ「Client Hello」の要求をした際、クライアントが希望するドメイン名を平文で伝える。
それによってサーバがドメインに対応する証明書を使えるようになる。
今回AzureFirewallは、クライアントからのリクエストについて、宛先ドメイン名をTLS拡張「server_name」で指定していない場合、その通信はAzureFirewallで破棄します、と言っているわけですね。
詳細はWikipedia参照
https://ja.wikipedia.org/wiki/Server_Name_Indication

所感

そもそもSSL/TLS周りの知識が無さすぎて、何のことだか全然分からなかった。
問い合わせまでしてしまった。
知識がある人ならログを見ただけで「そういうことね」となる事象なのでしょう・・・
勉強が足りないなぁ・・・

EXCEL VBAからSendGrid WebAPI経由でメール送信

2020-12-26T12:11:54+09:00

はじめに

（Qrunch からの移管記事です）

タイトルの通り、EXCEL VBAからSendGridのWebAPI経由でメール送信をする方法を記載。
「WebAPIとか全然わからない」の状態から頑張って送信までできるようにしました。

普通はCDO.MessageでSendGridへSMTP通信すればいいだけですが、
ネットワーク構成の都合上「外部へのSMTP通信は不許可、HTTP/HTTPSはOK（ただし認証プロキシあり）」という環境化だったので、WebAPIを利用せざるをえませんでした。
⇒むしろSendGridにWebAPIがあってよかった。

同じような境遇の人がいたら参考にしてください。（いるか？）

参考URL

１．VBAでのWEB API
https://qiita.com/haseshin/items/4acf31db9a672ed691df
２．VBAでのWEB API & JSON
https://qiita.com/MakotoIshikawa/items/be902e6bd3fa2e5c5fe5
３．SendGridのリファレンス
https://sendgrid.kke.co.jp/docs/API_Reference/index.html

事前作業（SendGridの認証について）

「SendGirdのユーザ名とパスワードをどこかで指定するんだろうなぁ」
と思ってたのですが、不要でした。

SendGridのポータルサイトからAPIキーを発行してください。
発行したAPIキーが認証情報になります。

実装コード

Sample

Private Sub SendMail() 

    Dim objHTTP As Object
    Dim json As Variant

    json = "{""personalizations"":" _
              "[{""to"": [{""email"": ""[email protected]""}],""subject"": ""Mail Title""}]," _
              """from"": {""email"": ""[email protected]""}," _
              """content"": [{""type"": ""text/plain"",""value"": ""Mail Body""}]}"

    Set objHTTP = CreateObject("MSXML2.ServerXMLHTTP.6.0")

    With objHTTP
        .Open "POST", "https://api.sendgrid.com/v3/mail/send", False
        .setRequestHeader "Content-Type", "application/json; charset=UTF-8"
        .setRequestHeader "Authorization", "Bearer xxxxYourApiKeyxxxxxxxxxxxxxx"
        .setProxy 2, "proxyhost.com:9293"
        .setProxyCredentials "proxyUser", "ProxyPassword"
        .setOption 2, 13056
        .send json

        If .ResponseText <> "" Then
            MsgBox .ResponseText
        Else
            MsgBox "OK"
        End If
    End With

End Sub

流れ
・JSON形式でメール設定を定義（細かい内容はリファレンスの「V3 Mail Send API概要」参照）
・MSXML2.ServerXMLHTTP.6.0オブジェクトの生成
・POSTメソッドでSendGridのMail Send APIをオープン
・ヘッダ設定。Content-TypeにJsonの指定。
　AuthorizationヘッダにAPIキーをセット。Bearerの指定をお忘れなく。
・プロキシ設定。setOptionの記述はSSL認証に関するエラー回避。
・送信。エラーの際にはResponseTextにエラー内容が入っているはず。
補足
・「xxxxYourApiKeyxxxxxxxxxxxxxx」がAPIキーです。
・プロキシを経由しない環境であれば「setProxy」、「setProxyCredentials」、「setOption」は省略してください。

VBAでのJSONファイルの取り扱い

JSONファイルをVBAでまじめに取り扱うのであれば「VBA-JSON」の利用なども検討してください。
⇒参考URL３の記事に詳しく記載されています。

所感

・VBAでのWebAPI利用なんてサッパリだ、の状態からなんとか実現できました。
・以外にVBA&REST APIの情報がネットに転がっていて助かった…

Docker Toolbox 導入手順メモ（Windows 7 64bit版）

2020-12-26T12:08:41+09:00

はじめに

Qiita記事からQrunchへ移管したものを、Crieit に移管。
自己学習用にWindows 7へDocker toolboxをインストールした際の構築メモ。

参考記事

インストールまで
https://qiita.com/witchy/items/99235291a6bd5fdee054

環境

Windows 7 Professional Edition (64bit)

事前作業

BIOSの仮想化支援機構を有効にしておく。
BIOS⇒CPU⇒intel virtualization technology

最初から有効になっているのであれば問題なし。

VirtualBoxを使う前の事前準備。
（これを設定しなかったため、後続作業でエラーになりました・・・）

ダウンロード

ダウンロード
https://docs.docker.com/toolbox/overview/#ready-to-get-started

Windows用のインストーラを取得

インストール

１．DockerToolbox.exeを起動
２．すべて初期設定のままインストールまで実行
　　このあたりはお好みで設定変更もOK。
　　VirtualBox環境もなかったのでFULLインストール。
３．参考記事の内容にしたがって、VMDKファイルの移動
　　および、vboxファイル内のVMDK参照先修正。
４．正常終了

起動

Docker Quickstart Terminalを起動
⇒正常に起動したらOK

HELLO WORLD

通常版
$ docker run hello-world
くじらに言わせる版
$ docker run docker/whalesay cowsay Hello World!

それぞれimageのダウンロード⇒実行まで実施

詰まったところ、操作ログ

・Docker Quickstart Terminalを起動したが、エラー
　⇒64bit版のCPUがみあたらない、みたいな感じの内容
・Virtual Boxを起動して再度試行
　⇒VERR_VD_IMAGE_READ_ONLYのエラーが出る。
　⇒ログの内容的には「VMDKファイルへの更新権限が無い」みたいな感じなのに、
　　フォルダのアクセス権変更等でも上手くいかない
・BIOSの仮想化支援機構をオン、GUI(kitematic)経由でVM作り直し
　⇒うまくいった！

所感

・インストールからつまづいたなぁ…
・エラー「VERR_VD_IMAGE_READ_ONLY」が出る理由がよくわからない。
　⇒色々検索してみたらVMの展開にそもそも失敗していると出力されたりするらしい。
・VirtualBoxを始めてみたけど、良さそうな仮想化ソフトですね。
　（今までVMware、Hyper-Vあたりしか触ってなかったので新鮮）

ANAの投稿 - Crieit

Azure Administratorへの道（6回：AzureAD周辺）

Azure Administratorへの道（5回：Load Balancer）

Azure Administratorへの道（4回：仮想マシン）

Azure Administratorへの道（３回：ストレージ関連）

Azure Administratorへの道（２回：Azure MFA）

Azure Administratorへの道（１回：Azure Policy）

Azure Administratorへの道（０回：受験申し込み）

Dockerの学習 #5 （Wordpressを使おう その２：Wordpressセットアップ）

Dockerの学習 #4 （Wordpressを使おう その１：Mysqlセットアップ）

Dockerの学習 #3 （PS、IMAGES、COMMIT、PUSH、RM、RMI、(BUILD)）

Dockerの学習 #2 （コンテナの起動・操作コマンド RUN、EXEC、ATTACH、STOP・KILL・START）

Dockerの学習 #1 （イメージファイルとPULLコマンド）

AzureFirewall [SNI TLS extension was missing]の理由

EXCEL VBAからSendGrid WebAPI経由でメール送信

Docker Toolbox 導入手順メモ（Windows 7 64bit版）

Dockerの学習 #5 （Wordpressを使おう　その２：Wordpressセットアップ）

Dockerの学習 #4 （Wordpressを使おう　その１：Mysqlセットアップ）

Dockerの学習 #2 （コンテナの起動・操作コマンド　RUN、EXEC、ATTACH、STOP・KILL・START）