AZ-900を2回受験した話
はじめに
先日AZ-900を取得しました。
1回目は落ちて、2回目で取得しました。
そんなに難易度の高くない、入門編といわれている資格なので落ちた話をするのは大変恥ずかしいのですが、
どなたかの励ましになれば幸いです。
1回目と2回目でどういう勉強をしたのかを中心に書いていきます。
AZ-900とは
MCP試験(マイクロソフト認定プロフェッショナル試験)のひとつです。
その中でも、AZ-900はMicrosoft Azureの基礎編となる位置付けです。
Exam AZ-900: Microsoft Azure Fundamentals - Learn | Microsoft Docs
前提Azureスペック
・業務でAzureを触った経験は少しある。
・興味の向くまま自由に触ることがほとんど。
1回目の受験
勉強方法
Microsoftが提供している無料のFundamentals向けウェビナーを受講しました。
スケジュールが合わず、2日間のうち後半1日のみ受講しました。
MS Learnの下記モジュールをさらっと一周しました。
点数
667点/(合格700点)
全然惜しくない
普通に落ちてますね。
この時の習熟度としては、ワードを聞いたことがある、どのジャンルか、くらいのものでした。
上記レベルの理解度では全然ダメで、ちゃんと各サービスや機能がどういう特徴でどんな目的に合ったものなのかというのを理解していないといけませんでした。
2回目の受験
1回目の試験から日がたたないほうが良いと思い、2週間後に再受験しました。
再受験ポリシー的には24時間後には受けられたようです。
certification-exam-policies | Microsoft Docs
勉強方法
己の頭の足らなさは課金で補う主義なので、1回目の試験直後に下記テキストを買いました。
MS Learnの内容がより分かりやすくかみ砕かれているような感じで、とても良かったです。
これを毎晩寝る前に1章ずつ読みました。
4章くらいしかないので、何周か出来ました。
試験当日に巻末の模擬試験をやりました。
1回目の試験の問題で正解が気になったものや書籍で解説されている機能の動きが知りたいときは実機を触って確認しました。
点数
780点/(合格700点)
めっちゃぎりぎりです。
2回目の受験で、出題形式もわかっているのにぎりぎりって…恥ずかしい!!
それでも2回目で何とか合格できてよかったです。。。
感想
確かに内容の難易度はそこまで高くない印象でしたが、
Azureのコアサービスについて網羅的に把握しておく必要がありました。
業務でAzureを触っていても、全く関わらない分野の内容は特に確認しておいたほうがよさそうです。
本来であれば、無料のウェビナーをしっかり受講しておけば、それだけでも十分合格できると思います。
試験対策用に勉強をして初めて知ることも多く、今までよりもAzure関連のドキュメントが読みやすくなったような気がします。
ようやくAzureに入門できたような気持ちです。
Microsoft認定資格としてはまだまだ上がありますので、入門編でこんなに躓いていては先が思いやられるのですが、機会があったら頑張ってみようと思います。
ローカルフォルダ配下のファイルをBLOBに一括アップロードするbatファイルを作る
はじめに
BLOBストレージにファイルを一括アップロードできるbatファイルが必要になったので、作りました。
今回作るもの
特定のローカルフォルダ配下にある複数のファイルを、一括でBLOBストレージにアップロードするPowerShellスクリプトを作ります。
また、それを起動させるbatファイルまで作ります。
用意するもの
アップロード先のBLOBストレージ
Azure CLIが使用できるWindows環境
参照サイト様
Windows での Azure CLI のインストール | Microsoft Docs
az storage blob | Microsoft Docs
PowerShell のエラーコード処理 | netplanetes log
作成
ログインスクリプト
Azureにアクセスするためのログインスクリプトを作ります。
PowerShellからのログイン自体は下記コマンドでできます。
az login -u ユーザー名 -p パスワード
このコマンドを.ps1ファイルに記載します。
また、ユーザ名とパスワードは入力形式にしたいので変数化します。
パスワードは入力しているときに平文を表示したくないので、[-AsSecureString]のオプションを付けます。
$username = Read-Host "Azureアカウント"
$password = Read-Host "パスワード" -AsSecureStringaz login -u $username -p $password
これにより、スクリプト実行時には下記のような表示になります。
以上でログイン用のスクリプトはできました。
最終的なスクリプトの形は下記のGitHubを参照ください。
blob_upload_bat/login.ps1 at master · kgnk-hkr/blob_upload_bat · GitHub
アップロードのためのスクリプト
次に指定したファイルを指定したBLOBストレージにアップロードするスクリプトを作ります。
BLOBへのアップロード自体は下記コマンドでできます。
az storage blob upload-batch --account-name ストレージアカウント名 -d アップロード先のコンテナ名 --destination-path アップロード先のパス -s アップロード元のローカルフォルダパス
[アップロード元のローカルフォルダパス]を指定すると、そのフォルダ配下のファイルすべてがアップロードされます。
ログインスクリプト同様、アップロードに必要な情報は変数化します。
今回は、デフォルト値も利用したいため、デフォルト値のオプションも利用します。
Read-Hostを付けることで、対話的になるためよりユーザーに分かりやすくできます。
$defaultaccountname = 'defaultaccountname' ←これがデフォルト値
$accountname = Read-Host "ストレージアカウント名[デフォルト値:$($defaultaccountname)]"
$accountname = ($defaultaccountname,$accountname)[[bool]$accountname]$defaultcontainername = '$web' ←これがデフォルト値
$containername = Read-Host "コンテナ名[デフォルト値:$($defaultcontainername)]"
$containername = ($defaultcontainername,$containername)[[bool]$containername]$defaultdestinationpath = '/images/' ←これがデフォルト値
$destinationpath = Read-Host "アップロード先のパス[デフォルト値:$($defaultdestinationpath)]"
$destinationpath = ($defaultdestinationpath,$destinationpath)[[bool]$destinationpath]$sourcepath = Read-Host "アップロード元のフォルダーパス"
az storage blob upload-batch --account-name $accountname -d $containername --destination-path $destinationpath -s $sourcepath
このスクリプトを実行すると下記のようになります。
アップロードに最低限必要なのは以上ですが、
きちんとアップロードされたかを実行の前後で確認できるようにアップロード先のファイル一覧を取得するコマンドも追加します。
$date = (Get-Date -F G).Replace('/','').Replace(' ','_').Replace(':','');
$destbefore = $date + "_before_upload_list.txt"
$destafter = $date + "_after_upload_list.txt"az storage blob list --account-name $accountname --container-name $containername --output table --prefix $destinationpath > $destbefore
az storage blob list --account-name $accountname --container-name $containername --output table --prefix $destinationpath > $destafter
以上でファイルアップロード用のスクリプトはできました。
最終的なスクリプトの形は下記のGitHubを参照ください。
blob_upload_bat/FileUpload.ps1 at master · kgnk-hkr/blob_upload_bat · GitHub
2つのスクリプトを実行するためのbatファイル
上記2つのPowerShellスクリプトを実行するためのbatファイルを作ります。
2つのPowerShellスクリプトはbatファイルと同じ階層のフォルダに格納されていることとします。
スクリプトが失敗したときにはエラーメッセージを返すようにします。
少し長くなるので、コード自体はGitHubにて参照ください。
blob_upload_bat/Upload.bat at master · kgnk-hkr/blob_upload_bat · GitHub
このbatファイルを実行し、すべてのスクリプトが成功すると下記のようになります。
ちなみに、スクリプトが失敗すると下記のようになります。
Azureへのログインが失敗した場合
アップロード情報が間違っていてアップロードに失敗した場合
詰まったところ
スクリプトのエラー検出
上記で説明したようなコマンドをそのままスクリプトにした状態では、アップロードスクリプトが失敗していても、エラーとして検出されずに終えられてしまいました。
下記記事を参考にして、1処理ごとにデータが返されているかを確認するようにしました。
Using Azure CLI with PowerShell: error handling explained
フォルダ名に記号が入っている場合
コマンドでアップロードする場合に、アップロード先のコンテナ名に記号($など)が入っていると、ダブルクォーテーションで囲うとコマンドが通らない事象がありました。
下記の記事を参考に、シングルクォーテーションで囲ったらうまくいきました。
おわりに
エラー処理の部分などは結構苦労したのですが、細かなところは端折ってしまったので、完成形のものをご覧いただければと思います。
気力があればちゃんと書き起こします。
作成したスクリプトとbatファイルはGitHubにまとめてアップしています。
Azureでマイクラサーバーをたてる
はじめに
ずっとマイクラPEで一人で遊んでいたのですが、
マルチプレイもしてみたくなったので
Azureの勉強がてら、マイクラサーバーをAzureにたててみようと思います。
今回作るもの
準備するもの
参考サイト様
作り方
テンプレートから仮想マシンを作る
足りなくなったら拡張します。
難易度とかシード値とかですね。
ここはサーバーを立てた後でも修正できます。
ポートを設定する
ソフトウェアを展開する
sudo su -
サーバの起動方法や設定などの使い方が書いてあります。
zipファイルの中にあった、[server.properties]を編集して、アクセスするポートを設定します。
ここで設定するポートはAzureの仮想マシン上で設定したポートです。
デフォルト19132を使う場合は変更はいらないはずです。
vi server.properties
サーバーを起動させる
コンソールを分けておくことで、マイクラサーバーを起動しっぱなしにすることができて便利です。
screen
解凍したzipの中身があるところで下記のコマンドを実行し、サーバーを起動します。
LD_LIBRARY_PATH=. ./bedrock_server
[Server started.]が表示されたらOKです。
アクセスする
私はスマフォで遊んでいるのでPE版です。
コスト
起動させっぱなしとして、大体3000円/月くらいになりそうな見込みです。
おわりに
クラウドコンピューティングの基礎知識
はじめに
先日、クラウドの基礎とメリットについてお話する機会がありました。
改めて勉強し、今さらながら初めて知るようなこともあったので簡単にまとめました。
参照サイト様
総務省 ICTスキル総合習得教材
https://www.soumu.go.jp/ict_skill/pdf/ict_skill_2_2.pdf
NISTによるクラウドコンピューティングの定義
https://www.ipa.go.jp/files/000025366.pdf
クラウドの定義とは
クラウドには多様な形態があり、簡潔な定義が困難であるとされています。
そこで、NIST(米国国立標準技術研究所)が下記の5つの特徴を満たすものをクラウドとすると挙げました。
オンデマンドセルフサービス
いつでもだれでも触れる状態であること。
各サービスの提供者に連絡することなく、利用者が必要に応じて自分の意志で始められる環境であること。
この特徴により、「早く価値を生み出す環境」が実現できます。
幅広いネットワークアクセス
どこからでもアクセスができる状態であること。
インターネットがつながる環境であれば、場所は問わず、デバイスも自由となる。
この特徴により、どこでも同じ環境が使えるため、テレワークのような働き方改革にも向いています。
リソースの共有
クラウドサービスで提供しているリソースは、マルチテナントモデルとして集積されている。
そのリソースをユーザーの需要によって割り当てる。
ユーザーはリソースが物理的にどこにあるかを意識することはない。
スピーディーな拡張性
クラウドのリソースは、ユーザーの要求によって即座に拡張や縮小ができる。
場合によっては割り当てや提供サイズを自動化することもできる。
この特徴により、リソースの確保に対して工数を取らないため
オンデマンドセルフサービス同様、「早く価値を生み出す環境」が実現できます。
サービスが測定可能
ユーザーとクラウド提供者の双方にとって重要な、サービスの品質保証にかかわる特徴。
ユーザーは誰が何をどれくらい使用していたか、
クラウド提供者はいかにダウンタイムなくサービスを提供できたか、を知る必要がある。
それを明示するために各サービスに対する正確な測定が必要になる。
SLAの認識は以前からありましたが、
クラウドの特徴(スピーディーな拡張性等)によってさらに意識されるものとなりました。
クラウドの実装モデル
クラウドの実装モデルはクラウドサービスの利用機会の開かれ方によって、4種に分類されます。
今回は主に使われることが多い3つのモデルについて記載します。
パブリッククラウド
クラウド事業者が所有していて、一般公開されているクラウド。
誰でも利用することができる。
インターネットを経由してWebブラウザでアクセスできる。
プライベートクラウド
クラウドリソースを使用する組織が所有と運営をする。
ハードウェアの購入、保守、管理が必要になる。
単一の組織に所属する者のみが使用できる。
パブリックアクセスは許可しない。
物理サーバーの設置場所は、利用組織の敷地内に設置するケースもあれば、
クラウド事業者のデータセンターなどに設置するケースもあります。
ハイブリットクラウド
複数のクラウドモデルを組み合わせたもの。
コストや効率面でいいとこどりができる。
部分的な管理が必要。(プライベートクラウド部分)
複雑なカスタマイズが必要な部分はプライベートクラウドで構築し、
定型的なサービスで対応できる部分はパブリッククラウドで構築するケースが考えられます。
Azure+AWSというような、複数のパブリッククラウドの組み合わせはマルチクラウドと言います。
クラウドのサービスモデル
クラウドにはたくさんのサービスがあります。
各サービスをクラウド事業者とユーザーの間の管理責任ごとに分類したとき
下記の3つのケースが考えられます。
IaaS(Infrastructure as a Service)
サービスとして提供されるインフラストラクチャー
ストレージやサーバーといったパソコンの中枢機能を利用できるクラウドサービスです。
従来は、インフラというと大規模な装置や保守人員が必要でしたが、IaaSを利用することでデバイスさえあればすぐに利用可能となります。
スケールアップ/ダウンも迅速にできます。
Azure内のサービス例)Virtual Machines
PaaS(Platform as a Service)
サービスとして提供されるプラットフォーム
OS、ネットワーク、フレームワークといったプラットフォームを開発するためのミドルウェアを利用できるクラウドサービスです。
環境設定に工数を取られないので、アプリケーションやサービスの開発に注力することができます。
Azure内のサービス例)Functions、Web Apps、Logic Apps
SaaS(Software as a Service)
サービスとして提供されるソフトウェア
物理的な部分からアプリまで担います。
これらはユーザー側が構築管理することはなく、ブラウザなどで接続して利用するだけになります。
一般的なサービス例)Microsoft Office 365、Gmail、Dropbox
コストとカスタマイズの自由度は下記のようなイメージです。
ユーザーが管理する範囲が広いほど、カスタマイズの自由度は上がりますが、
その分コストもかかります。
また、これらをわかりやすく例えたのが車の例になります。
IaaS: カーディーラーで車を買うようなもの。車検や駐車場の確保などが必要になる。
PaaS: レンタカーで借りるようなもの。実際には使っていない間もお金がかかる。
SaaS: タクシーを利用するようなもの。乗っている時間にだけ払う。
スライド資料
おわりに
クラウドの本当に最初の部分について改めてまとめてみました。
もう少し先についても機会があったらまとめてみます。
Azure Web Apps×Azure Active Direstoryでブログを作る
はじめに
社内への情報共有の手段が確立されていないと、
いくら外部の勉強会などで情報を得てきても、あまり活かせないのです…
要件
・指定した人しかアクセスできないようにする。
・誰でも参加がしやすいように一般的なブログの形式を選ぶ。
・いいねができる。
構成
Azure Web Apps(Freeプラン)(WordPress)
Azure Database for MySQL(Basicプラン)
Azure Active Directory
参考サイト様
Azure AD 認証を構成する | Microsoft Docs
GitHub - psignoret/aad-sso-wordpress: Single Sign-on with Azure Active Directory (for WordPress)
手順
以下、Azure Active Directoryで同じディレクトリの人だけがアクセスできるブログサイトの作成手順になります。
WordPressの新規作成
Azureで新規リソース作成をします。
「WordPress」で検索、作成します。
パラメータを設定します。
とりあえず一番安いものにします。
利用状況によってスケールアップしていきます。
ちなみに、この時点でのMySQLの見積もりはこのくらい。
リソースが作成されると、App ServiceからサイトURLに飛べます。
WordPressの初期設定をします。
ひとまず、WordPressが使える状態になりました。
Azure Active Directoryの設定
Azure Active Directory>[アプリの登録]を開きます。
[新規登録]をクリックし、新規アプリを追加します。
作成したら、[概要]にて各種IDが確認できるので、コピペして控えておきます。
この後の設定でよく使います。
各種設定をしていきます。
まず、[ブランド]で対象のサイトURLを登録します。
[認証]でリダイレクトURIとその他設定をします。
2種類のリダイレクトURIを登録します。
https://サイトURL/.auth/login/aad/callback
https://サイトURL/wp-login.php
[暗黙の付与]で[IDトークン]にチェックを入れます。
[既定のクライアントの種類]で[任意の組織ディレクトリ内のアカウント]にチェックを入れます。
[保存]します。
[証明書とシークレット]で新しいクライアントシークレットを発行します。
発行した直後しかキーを確認できないので、忘れずにコピーしましょう。
このキーはWordPress側の設定で使います。
[APIのアクセス許可]で[アクセス許可の追加]をします。
[Microsoft Graph]>[委任されたアクセス許可]>[Directory.Read.All]を選択します。
追加したら、[既定のディレクトリに管理者の同意を与えます]をクリックします。
[所有者]でサイトへのアクセスを許可するユーザーを追加します。
この所有者がアクセスできるユーザーの設定になるかと思ったのですが、そうではなさそうです。同じディレクトリのユーザーであればアクセスできるようになります。
AAD認証の設定
App Service側にAAD認証設定をします。
これを設定することで、サイトURLにアクセスすると認証画面がでてくるようになります。
App Serviceの[認証承認]を開きます。
[App Service認証]を[オン]にします。
[要求が認証されない場合に実行するアクション]を[Azure Active Direstoryでのログイン]にします。
認証プロパイダーの[Azure Active Direstory]をクリックします。
[詳細]にAADの概要で表示された各種IDを入力します。
クライアントID:アプリケーション(クライアント)ID
発行者のURL:http://login.microsoftonline.com/ディレクトリ(テナント)ID
許可されるトークン対象ユーザー:api://アプリケーション(クライアント)ID
設定ができたら、サイトURLにアクセスしてみます。
アクセス直後にMSのアカウント認証画面が出てきます。
WordPress側のAAD設定
WordPress側にもAADの設定を入れることで、記事の投稿のときに必要になるWordPress側のサインインにSingle Sign-Onが適用されて、ログイン情報入力の手間が省けます。
下記サイトよりプラグインをダウンロードします。
GitHub - psignoret/aad-sso-wordpress: Single Sign-on with Azure Active Directory (for WordPress)
管理者アカウントで作成したサイトにアクセスします。
[ダッシュボード]>[プラグイン]>[新規追加] >[プラグインのアップロード]にて上記でダウンロードしたzipファイルをアップロードします。
アップロードおよびインストールが完了したら、
プラグインを有効化します。
[設定]>[Azure AD]にてAADの設定を入れていきます。
入力する必要があるのは下記です。
クライアントID
クライアントシークレット
オブジェクトID
チェックボックスの項目は必要に応じて有効にします。
以上の設定が完了すると、サイトのサインインにシングルサインオンが適用されます。
おわりに
以上の手順で「指定した人しかアクセスできないようにする。」という要件を満たすための設定ができました。
他の要件を満たす、あったらいいなの機能をもう少し追加しているのですが、AzureではなくWordPressのお話なのでおまけ程度に別記事で書きます。
運用開始ができたら、コストについてもちゃんとまとめたいです。
※2020/02/01追記
Office365アカウントでの認証ができれば、一回のサインイン入力でさえも省けるようなのでもう少し試行錯誤してみる余地がでました。
Translator TextのWPFアプリ作成チュートリアルを触ってみた
QiitaのAzure AI Advent Calendar 2019 15日目の記事です。
動機
チーム内に外国籍の方が数名おり、日本語のみでのコミュニケーションに限界があるときがあります。
そこで、Cognitive ServicesのTranslator Textを使って少しでもコミュニケーションに役立つものが作れたらいいなと思い、まずはチュートリアルを触ってみました。
触ったもの
GitHubにもサンプルコードがあります。
GitHub - MicrosoftTranslator/Text-Translation-API-V3-C-Sharp-Tutorial
触ってみた
マルチサービスリソースにします。
リージョンは米国西部がおすすめらしいので米国西部です。
実行します。
【レポ】Microsoft Ignite The Tour Tokyo Day2に参加してきました
Microsoft Ignite The Tour Tokyo Day2に参加したレポート記事になります。
概要
2019年12月5,6日でMicrosoft Ignite The Tour Tokyoというテクニカルカンファレンスが開催されました。
今回はIgniteの最新情報というよりも入門編が多めの印象でした。
目的
現在業務でAzure Container Instancesを利用しています。
その利用方法を見直す必要が生じたため、コンテナについての情報を収集し社内に展開するというのが私の今回の目標のひとつでした。
ということで、参加セッションはコンテナ周りが中心となっています。
参加セッション
1つ目のセッション
アプリ開発者がコードに専念するためのもの。
隔離された環境で同じように使うことができる。→生産性の向上につながる。
特徴として動作が軽い。
Dockerfileのデプロイ。
細かいコマンドとオプションの説明もありました。
シングルコマンドでコンテナ実行ができるお手軽さ。
一秒単位での課金となり、実行中のみ換算される。
仮想マシンの管理はAzureがする。
バッチ的な処理が向いている。
LogicAppsを使うようなアプリに向いている。
AKSの追加リソースとして使える。
プライベートなレジストリ。
全てのタイプのコンテナイメージの管理ができる。
地理冗長もできる。
ACRの作成。
コンテナ化されたアプリの実行が簡単。
デモがよかったです。
実際に動いているAPIとかが確認できました。
見よう見まねでやっていたことが間違いでなかったことが確認できて安心しました。
ただし、ACIを常時利用の構成にしていたのでこれは見直さなければいけないとわかりました!
2つ目のセッション
AKSについて、基礎的なお話から活用方法までのお話でした。
本当に今の構成にAKSは必要なのか?
頻繁にアップデートされるサービスか?
どんどん更新を追加していくものか?
⇒上記がYesならばAKS向きだそう。
永続化したいデータは別DBにちゃんと保管しておいて、クラスタ自体はすぐに捨てられるようにしておく。
k8sは流行っていてよく聞くワードではあるが、
難しいのも事実なので、最初はシンプルな構成から挑戦するのがいい。
資料が公開されると嬉しいです。
会場にはスピーカーQ&Aというブースが設けてあり、
セッションを終えたスピーカーの方々と直接お話ができました。
今の業務の構成について、原さんに直接ご相談させていただき、解決策をご指南いただきました。
今回の参加で最も有益な機会でした。
3つ目セッション
TeamsとPower Platformで業務を効率化するお話でした。
ただのビジネスチャットじゃない。
ハブとして使ったときに真価が発揮される。
Teamsだけでも業務が完結するくらいになってきている。
データ入力:Power Apps
繋げる:Power Automate
可視化:Power BI
bot:Power Virtual Automate
Teams×Power Platformでの業務効率化の一例として
訪問販売のシミュレーションのお話をされていました。
効果を数字で表されると本当に圧倒的でした。
Power Platformと組み合わせてさらに効果的に使えたらいいなと思いました。
すべてはアイデア次第…
4つ目のセッション
本当は別のセッションを聞きに行く予定だったのですが、
前のセッションがあまりに面白かったので連続で参加することにしました。
・Teamsへの愛
・ユーザー仲間への愛
・会社への愛
愛のある人が使い倒して、説得することで響くものがある。
・今までの働き方や考え方を変える必要がある。
(メールの置き換えやコミュニケーションツールの追加ではない
・会社を変えるレベルの話
・経営層、力のある人を巻き込む必要がある
・好きな会社だから変えようという本気の人たちじゃないと成し遂げられない
個人のやる気を会社がどれだけ活かしてあげられるかが肝である。
全体的にマーケティング寄りのお話でした。
何かに愛を持って活動されている人は輝いているなと常々思っていたので
愛を持って行動することの重要性を再認識しました。
私もそれくらい愛を持てるものが早く見つかるといいなぁ
感想
ちゃんと社内に情報共有します。
セッションそのものも有益ですが、スピーカーQ&Aやエキスパートブースがかなり重要だったと思います。
普段ならばなかなか聞くことができない技術的な悩みをその道のエキスパートさんたちに直接伺えるというのは最高に贅沢でした。
大阪にもあるかと思いますので、参加される方は是非ご活用ください。