Microsoft Ignite 2019はじまりましたね。私は現地で参加しております。 いつもどおりIgniteに合わせて沢山のアナウンスがなされていますね。主要なものがすべてまとまったPDFがMicrosoftさんから出てますのでそちらを紹介です。 https://news.microsoft.com/wp-content/uploads/prod/sites/563/2019/11/Ignite-2019-Book-of-News.pdf 去年はこれをざっくりと全部日本語に訳して記事にしたのですが、数十時間かけてものすごく苦労して翻訳した割に全然見に来る人もいなかったので、今年はオリジナルのリンクをはるだけでおしまいにします！ 個人的にはAzure Arcが大変素敵だなと思います。今すぐできる表面的な機能だけをみて「大したこと無い」という評価をする人も多く出そうですが、きちんとARMの世界にAzure外のリソースを取り込んでいこうという姿勢はすごいなと思います。さすがMicrosoft。構想が壮大です。
前回の記事「 Azure Portalにアクセスする際の動きをFiddlerで確認 – その１ クラウドIDを使った一番シンプルなパターン | Microsoft Cloud Administrators 」の続きです。 今度はクラウドIDが別AzureADテナントに招待されその別Azure ADテナントに紐付いているAzureサブスクリプションにアクセスする際の動きを確認してみます。 注意：このエントリの内容は「正確さ」に関しては保証しません。自分で実際に試してみて、挙動をみて、考えて、自分の既存の知識や経験、他のドキュメント等と照らし合わせた上で自分の現段階の考えを書いています。ご注意ください。 クラウドIDがテナントをまたいで招待されているパターン 今回は前回と同じwindowsadmin.onmicrosoft.comというAADに紐づくAzureサブスクリプションに対して別AzureADテナントwindowsadmin2.onmicrosoft.com上に存在するaccesstest2@windowsadmin2.onmicrosoft.comからアクセスをしたときの挙動を見てみます。 サブスクリプションは前回利用したものと同じです。紐付いているディレクトリはwindowsadmin.onmicrosoft.comです。 新規に別のAzure ADを作成しました。ディレクトリ名はwindowsadmin2.onmicrosoft.comです。 ユーザーとしてaccesstest2@windowsadmin2.onmicrosoft.comを作成しています。 accesstest2@windowsadmin2.onmicrosoft.comはwindowsadmin.onmicrosoft.comに招待してあります。 サブスクリプションへの権限も付与してあります。 実際の挙動 https://portal.azure.com/にアクセスします。 サインインを求められます。 アカウント名を入力します。 パスワードの入力を求められます。 サインインの状態を維持するかどうかを質問されます。 windowsadmin2.onmicrosoft.comディレクトリを利用してAzure管理ポータルにアクセスしました。サブスクリプションが該当ディレクトリには存在していないと表示されています。 ディレクトリをWindowsadmin.onmicrosoft.comに切り替えます。 Azure管理ポータルへのアクセスが完了しました。 Fiddlerに記録されたデータを含めた挙動 Fiddlerで動きを見ると、はじめの方の挙動は完全に同一になっています。その後、Azure管理ポータルにアクセスしたあとでAADテナントを明示した認証、認可が走っていることがわかります。 何度もAzure管理ポータル上でディレクトリの切り替えを行うと、そのたびにlogin.microsoftonline.comへのAADテナントを明示したアクセス(認証～トークン取得)が行われていることが確認できます。
皆さんこんにちは。胡田です。毎日暑いですね。みなさんお体にお気をつけください。 さて、今回はAzure Portalにアクセスする際の動きをFiddlerで確認してみようと思います。 Azure Portalにアクセスするためには皆さん御存知の通りAzure ADで認証される必要があります。マイクロソフトアカウント利用する場合には「Azure ADで認証」と書いてしまうのは少々正確ではないかもしれませんが、ここでは組織アカウントのみ考えることにします。 このとき、ユーザーとしてはAzure PortalのURL(https://portal.azure.com/)を入力してAzure Portalにアクセスするわけですが、Azure ADで認証する必要があるためリダイレクトされる動きになります。さらに、アクセスしようとしているAzure Subscriptionの紐付いているAzure ADが、ユーザーが存在しているAzure ADとは異なる構成もとれます。このようなときにどのようにブラウザが遷移しているのかをきちんと確認しようというのがこのエントリの趣旨です。 Fiddlerを使うことでHTTP/HTTPSの通信を生で記録、確認することができますので、テストした時点での正確な動きを確認することが可能です。 構成パターンはかなり多数ありますので相当複雑にもなりうるのですが、まずはシンプルなところから何パターンか見ていきたいと思います。 注意：このエントリの内容は「正確さ」に関しては保証しません。自分で実際に試してみて、挙動をみて、考えて、自分の既存の知識や経験、他のドキュメント等と照らし合わせた上で自分の現段階の考えを書いています。ご注意ください。 クラウドIDを使った一番シンプルなパターン まずは下記のような一番シンプルなパターンを見ていきましょう。 AADとしてwindowsadmin.onmicrosoft.comが存在します。 windowsadmin.onmicrosoft.com上にaccesstest@windowsadmin.onmicrosoft.comというアカウントを作成します。このアカウントはクラウド上に存在するアカウントであり、フェデレーション等は構成されていません。 windowsadmin.onmicrosoft.comをディレクトリとして構成された「MVP特典(Visual Studio Ultimate with MSDN)」というAzureサブスクリプションが存在します。 #なんだかひどいサブスクリプション名ですが、管理しているサブスクリプションが大量にあるのできちんと区別しやすい愚直な名前にしております…。 「MVP特典(Visual Studio Ultimate with MSDN)」 上でaccesstest@windowsadmin.onmicrosoftのアカウントに閲覧権限(Reader)を割り当てアクセス可能にしてあります。 実際の挙動 PC上でChromeをシークレットモードで開き、URLにhttps://portal.azure.com/を入力します。 URLがhttps://login.microsoftonline.com/となり認証を求められます。 ユーザー名を入力します。 次にパスワードの入力を求められます。パスワードを入力して「サインイン」をクリックします。 サインインの状態を維持するかどうかを聞かれます。この質問には今後も含めてこの検証内ではすべて「いいえ」で回答します。(テスト目的のため) Azure管理ポータルにアクセスできました。 Fiddlerに記録されたデータを含めた挙動 PC上でChromeをシークレットモードで開き、URLにhttps://portal.azure.com/を入力します。 このときhttps://portal.azure.com/の画面は表示されずすぐに画面が遷移しますがその様子が見て取れます。 1行目ではProxy接続でHTTPSを扱うためにHTTP1.1のCONNECTメソッドが利用されています。 参考URL： Re: Newbie Questions - Google グループ - CONNECT - HTTP | MDN - HTTPSとCONNECTメソッド - ITの窓辺から 2,3行目ではportal.azure.comおよびその配下のJavascriptを取得しています。実際にはJavascriptによってまず認証を行うためのページに遷移させられています。 ...
サブスクリプションを他の人から転送してもらった等の理由で 「自分はサブスクリプションのアカウント所有者だが、Azureサブスクリプションには何も権限を持っていない」という状況が生まれることがあります。 この場合、自分で自分をサービス管理者として設定することでAzureの権限を保持することができます。 https://account.azure.com/Subscriptionsに移動します。 自分が保持しているアカウントに紐づくサブスクリプションの一覧が表示されます。 Azure管理ポータルからは権限がなく見えない状態のサブスクリプションをクリックします。 「サブスクリプション詳細の編集」をクリックします。 「サービス管理者」を自分のアカウントに設定します。 この操作によりしばらく時間がたつとAzure管理ポータル上でもサブスクリプションを管理可能となります。
先日HCCJPにてハンズオンイベントを開催しました。ハンズオン資料作成、ハンズオン講師等務めさせてもらいました。 ざくっと概要を理解するものとしてはそんなに悪く無いできだと思いますのでよろしければ参考にしてみてください。 ※Azureの理解という観点でみると「Azure, Azure Stackで同じ概念、操作でできるもの」に引っ張られすぎている感は否定できませんけれども。 https://gitpitch.com/hccjp/hybridcloudhandson1
#この投稿は下記３つのブログにクロスポストしています。 https://diary.ebisuda.net/- https://windowsadmin.ebisuda.net/- https://cloud.ebisuda.net/ 今日はお休みの日ですが、Interact 2019にて登壇させてもらってきました。 休日のコミュニティイベントへの参加も解禁しましたが、今回はさらに長男と次女をつれていきました。そして私と一緒に登壇させました。 長男はきちんと自己紹介できましたが、次女は恥ずかしがって私の後ろに隠れてしまいました。そして結局、事前にはなにも教えておかずにその場で「こうやって」って操作をさせて、MinecraftのサーバーをAzure上に展開してもらいました。 どうやら結局なんだかよくわかっていなかったようですが、それでも楽しかったようなので良かったです。 セッションは参加してくれた人に何度も笑ってもらいました。それがよかったです。笑いもなにもない真面目なITのセッションって本当にくらーい感じになってしまうのでそういうのは好きじゃないんです。なんでも楽しいのがいいですよね！ 資料はSlideshareにアップロードしておきましたので、よろしければご覧くださいませ。 ** あなたも「違いが分かる人」になりましょう！ ～ Azure, AzureStack, AzureStack HCI ～ ** from Masahiko Ebisuda
#この投稿は下記３つのブログにクロスポストしています。 - [https://diary.ebisuda.net/](https://diary.ebisuda.net/) - [https://windowsadmin.ebisuda.net/](https://windowsadmin.ebisuda.net/) - [https://cloud.ebisuda.net/](https://cloud.ebisuda.net/) 今日はお休みの日ですが、Interact 2019にて登壇させてもらってきました。 休日のコミュニティイベントへの参加も解禁しましたが、今回はさらに長男と次女をつれていきました。そして私と一緒に登壇させました。 長男はきちんと自己紹介できましたが、次女は恥ずかしがって私の後ろに隠れてしまいました。そして結局、事前にはなにも教えておかずにその場で「こうやって」って操作をさせて、MinecraftのサーバーをAzure上に展開してもらいました。 どうやら結局なんだかよくわかっていなかったようですが、それでも楽しかったようなので良かったです。 セッションは参加してくれた人に何度も笑ってもらいました。それがよかったです。笑いもなにもない真面目なITのセッションって本当にくらーい感じになってしまうのでそういうのは好きじゃないんです。なんでも楽しいのがいいですよね！ 資料はSlideshareにアップロードしておきましたので、よろしければご覧くださいませ。 ** あなたも「違いが分かる人」になりましょう！ ～ Azure, AzureStack, AzureStack HCI ～ ** from Masahiko Ebisuda
AWS Outpostsの発表はずいぶん前(re:invent 2018)になされ、私もブログでも言及していました https://cloud.ebisuda.net/aws-outposts%E3%81%A8microsoft-azure-stack%E3%81%AB%E9%96%A2%E3%81%97%E3%81%A6%E6%9C%AC%E8%B3%AA%E7%9A%84%E3%81%AB%E5%A4%A7%E4%BA%8B%E3%81%A0%E3%81%A8%E6%80%9D%E3%81%86%E3%81%93%E3%81%A8/ まだOutpostsは市場には登場していませんが、Youtube上で解説動画が見られることを教えてもらいました。 https://youtu.be/Cnn3BYsE6ug?fbclid=IwAR0FbjkR0wjh3lIUMPbMm9zqeJwV1mO4RzkRIPAZH3nEZEhht1yJ-whPjm4 このような形でしっかりと解説を聞くのは初めてだったので、聞きながらTwitterで感想をつぶやいてみました。 AWS OutpostsとAzure Stack - Togetter Outpostsが予定どおり出荷されて(2019年後半を予定)、オンプレミスでも「クラウド」を利用する機運が高まってくれると良いなとあらためて思います。
皆さんこんにちは。胡田です。もう2019年ですしもうすぐ平成も終わりますね。私は最近あまりこのブログに記事をかけていませんが元気にやってます。将棋ウォーズがいつまでたっても2級のまま昇級でず苦しんでいます。将棋難しい…。 さて、マイクロソフトのクラウドサービスを利用しているといたるところで「テナント」という言葉を目にします。この「テナント」という言葉は結構曖昧に理解されていることが多く会話の中で様々な誤解を生んでしまう原因にもなっています。 このエントリでは「組織(＝顧客、会社)」と「テナント」の関係について整理しておきたいと思います。 Office 365の「テナント」 例えばOffice 365の契約を考えます。組織としての本番利用を考えるときには「組織」につき1つのOffice 365の環境を作成することが多いです。この時「組織」と「テナント」は1対1の関係となります。 「テナント」というのはサービスの1つの論理的なまとまりです。IDがあり、サービスがあり、データがあります。明示的な許可がなければ「テナント」の中にあるデータは「テナント」内で共有され、外部の「テナント」とは共有されません。 検証用の完全に独立したOffice 365の環境を本番環境とは別で保持したいという組織もあるでしょう。この時1つの組織に対して複数の「テナント」が存在することになります。 このブログでも繰り返し言及していますが、マイクロソフトのクラウドサービスの根幹はAzure Active Directoryにあります。事実上「テナント」というときには「Azure Active Directory」とそれに紐づく各種サービスという意味になります。ですので、「テナント」を指し示すのにはAzure ADのテナント名(xxxxx.onmicrosoft.com)やGUIDを使用します。 例えば私が管理しているhccjp.orgという「テナント」を見てみましょう。下記はAzure管理ポータルからアクセスしたAzure Active Directoryの管理画面です。 このAADはもともと「ebisuda.onmicrosoft.com」というテナント名で取得しました。その後hccjp.orgというドメイン名を追加し、プライマリに変更しています。 このテナントにはOffice 365も連携されています。エンタープライズアプリケーションの一覧を見てもらうとそれがわかります。 HCCJPは個人管理ではありますが、「テナント」としてAADとOffice 365がある状況がおわかりになりますでしょうか。 Azureの「テナント」 Azureに関してはOffice365と異なり、Azureサブスクリプションに対して「ディレクトリの変更」という操作すら行えてしまいますのでAADを軸として1つの「テナント」として考えることはできません。 契約の単位で管理されて入るのですが、サブスクリプションを契約間でコンバートすることもできてしまいます。 Azureに関しては実際のところ「テナント」という表現はほぼ使われないだろうと思います。Azureに関して会話をしている中で「テナント」という言葉が出てきたらそれがAzure Active Directory(＋Office 365, Dynamics 365等)を指しての言葉なのか、Azureのサブスクリプションを指しての言葉なのか等、しっかりとその意図するところを確認する必要があるでしょう。 「テナント」という言葉は注意して使いましょう というわけで、今回はなんだか締まらない内容になってしまいました。それだけ曖昧な言葉であるということです。話し手、書き手の意図をきちんと確認し、思い込みで誤解を生まないようにしていただければと思います。
AWS Outpostsが発表され、Microsoft Azure Stackとの比較論が出ていたりもします。どちらがいいか…を直接比較…とか比較するのはちょっと違う…とかいろいろ話も意見もありますが、そんなことよりもずっと本質的に大事だと私が思っていることがあります。それは「そのインフラが設計、構築、維持運用されるためにどれだけのコストが払われているのか」ということが大事なんじゃないかということです。 私はインフラエンジニアとして単一システムのための個別の環境を構築したり、統合仮想基盤を構築したりした経験があるのでよくわかっているつもりなのですが、「個別にものすごい労力を割いてシステム、プラットフォームを構築、維持管理している」状況があちこちにあります。そして個別最適化されているので知識の属人化が進み下記のような状況が当たり前のようにあります。 - XXさんじゃないとどうなっているかわからない - システムに変更加えようと思うとどこで何が起きるかわからない - 変更加えるためには徹底的なテストが必要 - でもそもそも全く同じテスト環境は構築できない - 『触らぬ神に祟りなし』なので何も更新しない - 脆弱性があっても修正しない - パッチ当てるにしても人間が一つづつ手作業で目視確認しながら作業する - プラットフォームが古いので新しいOS等に更新もできない - でも、よく考えると単に仮想基盤があって仮想マシンが動いているだけ… - 個別に最適化してしまっているので他社で培われたノウハウも展開できない 結果、あるシステム、プラットフォームにかかっている「コスト」はものすごいことになっているケースが多いです。それはハードウェアの話もありますが、むしろ人的コスト、消費されている時間の方が圧倒的に「やばい」と思っています。 一方、パブリッククラウドに目を向けると…、かなりの部分が隠蔽されているので不明な部分も大きいですが下記のような状況があります。 - 一般的なオンプレミスのシステムの規模は比較にならないような圧倒的なスケールで標準化されている(はず) - 通常のオペレーションも大規模に自動化されてなされている(はず) - セキュリティ対策も一般的なオンプレミスの環境とは比較にならないレベルで徹底、統一化されている(はず) - 世界トップのエンジニアたちのノウハウが投入され続けている - 最新のサービスを提供するように更新され続ける 例えば同じスペックの仮想マシンを1台動かすことを考えます。そのときにその基盤となる環境にかかっている人的コスト、消費されている時間はオンプレミスの方がパブリッククラウドの何倍、何百倍、何千倍、下手したら何万倍のオーダーでかかっているだろうと思います。1人のエンジニアが何台動かせる基盤の面倒を見ているか、何人が使えるシステムの面倒をみているかという尺度でも良いと思いますが、正しいデータが出せずに申し訳ないですがもう圧倒的であることは火を見るよりも明らかです。 かけたコストの分だけオンプレミスのシステムにて特別な差別要素のあることをしているなら意味もあるのでしょうけれども、結局やっているのは「サーバーを塩漬けで動かしてます」という話だとそれって単純に貴重なリソースの無駄遣い…ですよね。 その観点からすると、「差別化する必要があるものに関してはオンプレミスで自分たちで手をかけてやる」「差別化する要素がない部分はもっともコストが低いコモディティ化したもので良い」ということになります。 で、やっとAWS OutpostsやMicrosoft Azure Stackの話になるのですがこれらは究極的に「標準化」されているものなんです。個別に設計するのではなく世界規模で標準化されています。そしてパブリッククラウドのノウハウで標準化されているんです。更新だって勝手にやってくれたり、ボタン一発だったりします。テンプレートやコードだって世界で共通のものが動いちゃいます。これってインフラ構築で個別に苦労したことのあるエンジニアがみんな思う「共通化できたらみんな幸せになるのに」というシステムの1つの形だと思います。それを個別の組織レベルではなく、世界規模で行っているわけです。 そして、どのくらい時間がかかるかはわかりませんが「そういえば昔は個別に基盤構築していたよね」という時代が来ると私は確信しています。それはコンピューター製造に共通企画がなかった所から共通規格ができたように。標準的な通信プロトコルがなくて独自プロトコルが乱立していたところから共通規格ができたように。もちろんニッチな所、本質的に標準化できないところではそれはいつまでも残るのですが「全部まかせといていいよね」という話になります。これは「クラウド時代に「買って済ますべきもの」と「自分たちですべきもの」 | Microsoft Cloud Administrators」で書いたことと基本的に同じ考え方です。 結局何が言いたいのかというと、「自分たちでいちいち個別にプラットフォームを構築、維持管理する必要が本当にあるのですか？よく考えたほうが良いですよ」ということです。そうだね、って気がついた人はパブリッククラウドを利用するのでしょうし、どうしてもオンプレミスという場所にシステムを置く必要があるのであればOutpostsやAzure Stackを利用するようになっていくと思います。むしろそうならなければ行けないと思っています。 とはいえ、Outpostsが登場するのはまだ先ですし、Azure Stackも(組織サイズが大きくないと)値段が高すぎるし…ということでまだまだだと言うことには現時点では同意します。でも、きちんと先をみて、「世界標準のプラットフォームへの対応」を組織としても、エンジニアのスキルセットとしてもしておくべきだと強く思うところです。 この文脈においてOutpostsもすごく人気がでて普及してほしいですし、私が個人的に多くの時間を投資しているAzure Stackの普及も進んでほしいと思っています。「個別の無駄な苦労」はしなくて済むならそれでいいと思うのです。 #ちょっと極論を強い口調で書きすぎたかもしれません。気分を害された方ごめんなさい。
10月27日に行われたWindows Server Community Meetup #02で使ったスライドをSlideshareにアップロードしてあります。このブログで紹介するのを忘れていました。 [slideshare id=120926030&doc=windowsvirtualdesktopandremotedesktopservices2019-181027083515] 特にWindows Virtual DesktopはMicrosoft系で固めている企業なら「もうライセンス持ってるしどこで使おうか？」というレベルで使うことを前提に話ができるサービスだと思います。 登場は少し先になるのだと思いますが、しっかりと抑えておいてもらうと良いかと思います。
継続的にチャットにて質問をいただいております。結構会話が弾むこともありなかなか楽しいです。 私には会話相手が誰だかわからない状態から会話が始まり、継続的にフォローを希望する方はメールアドレスを登録してもらう事でIDの認証と継続的に同じスレッドで会話ができるようになる仕組みです。メールは一時的に取得したフリーのアドレスでも大丈夫です。 よければお気軽にお声がけ下さいませ！ Q. これからAzureを導入しようとしている。Windows10クライアントも利用している。アカウントは何を使うべきか？ 特に、個人アカウント(マイクロソフトアカウント)と組織アカウント(Azure Active Directoryのアカウント)のどちらを使うべきか、という観点での質問をいただきました。 前提としては下記ブログエントリを読んでいただくとして… - [個人アカウントと組織アカウント](http://cloud.ebisuda.net/%e5%80%8b%e4%ba%ba%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e3%81%a8%e7%b5%84%e7%b9%94%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88/) まず、明確にOffice 365を利用するなら組織アカウントを使うようになるのは仕様です。そして、Azureの管理に関しては全て組織アカウントを使うようにするのが超おすすめです。 つまり、Office 365で使うアカウントで、Azureの管理も行えるようにするという事です。 さらに、自社で作成するアプリケーションも、その他のSaaSも全て同じアカウントでの利用をお勧めします。これは以下で述べたことと同じです。 - [クラウド時代のマイクロソフト系インフラ管理者はまず](http://cloud.ebisuda.net/%e3%82%af%e3%83%a9%e3%82%a6%e3%83%89%e6%99%82%e4%bb%a3%e3%81%ae%e3%83%9e%e3%82%a4%e3%82%af%e3%83%ad%e3%82%bd%e3%83%95%e3%83%88%e7%b3%bb%e3%82%a4%e3%83%b3%e3%83%95%e3%83%a9%e7%ae%a1%e7%90%86%e8%80%85/)[Azure Active Directory](http://cloud.ebisuda.net/%e3%82%af%e3%83%a9%e3%82%a6%e3%83%89%e6%99%82%e4%bb%a3%e3%81%ae%e3%83%9e%e3%82%a4%e3%82%af%e3%83%ad%e3%82%bd%e3%83%95%e3%83%88%e7%b3%bb%e3%82%a4%e3%83%b3%e3%83%95%e3%83%a9%e7%ae%a1%e7%90%86%e8%80%85/)[を理解し活用しましょう](http://cloud.ebisuda.net/%e3%82%af%e3%83%a9%e3%82%a6%e3%83%89%e6%99%82%e4%bb%a3%e3%81%ae%e3%83%9e%e3%82%a4%e3%82%af%e3%83%ad%e3%82%bd%e3%83%95%e3%83%88%e7%b3%bb%e3%82%a4%e3%83%b3%e3%83%95%e3%83%a9%e7%ae%a1%e7%90%86%e8%80%85/) ここまではいいのですが、Windows 10にログインするときのアカウントをどうするかはちょっと私でも思案します。 選択肢としては大きく以下があります。 - ローカルアカウント - Active Directory のドメインアカウント - 個人アカウント(マイクロソフトアカウント) - 組織アカウント 自宅で使う個人のPCなら3で良いでしょう。1は特に使わなくていいと思います。 企業で使うPCの場合、多いのはそもそも今まで2で運用していたのでそのまま2というケースが圧倒的に多いと思います。これはこれで現実的ですし、Active Directory のアカウントとAzure Active Directory のアカウントを同期し、スムーズに認証連携させる方法も複数あるので問題ありません。 むしろ現実的にオンプレミスに既存のAD統合認証で利用するさまざまなシステムがあればこうならざるを得ません。 そして、これから新規に環境を整えていく段階の組織であれば4を選択してフルクラウドの環境にしてしまうことをお勧めしますし、それが現実的に可能な状況になっています。 ここまではいいのですが、2にすべきか、4にすべきか微妙な状況の組織が多くあります。4に振り切ってしまおうとして色々と困るケースも考えられますし、2で構成したときの無駄やオーバーヘッドも無視できません。 折衷案的なAzure Active Directory Domain Servicesはかなり良い解決策に思えますが、Azureまでのセットワーク接続を安定的に確保するコストが組織に見合うかどうか…。 と、なかなか難しい話題です。 決定にはよくその組織を理解して今後の方向性も含めての決定が必要だよなと思います。曖昧な回答でごめんなさい。 なお、自分に全部決定権があるならもちろん4を選びます。迷わないです。
今日はNetworld.next 2018 DXにて - 【Networld】3大メガクラウド構築ベンダーがガチンコ対決！ - 【Networld】メガクラウド vs HCI ガチンコ頂上決戦！ というセッションにて登壇させていただきました。 対決形式、ということで今まで経験のない形式でしたが、私はAzureでのシステム構築をするベンダーという立場でAzure推進の立場で楽しくやらせてもらいました。 今回はNutanixさんが投票で1位になりました。私は1つめが1位,2つめが3位でした。どれも結局そのクラウドや製品の良し悪し…というよりは、登壇している人の口の旨さ的なところと、その場で会場にいた人の感覚に依存した話にはなっているのですが。 いや、でも、私正直なところAWS, GCP, AzureとオンプレミスのHCIを比較するなんて「このクラウドファーストの時代にそもそも比較する対象としておかしい」くらいの感覚でした。そもそも比較対象ですらないでしょと。AWSとGCPとAzureのどれかが一番になって当たり前と思ってました。 なので、結果を見て結構本当に驚いてしまいました。 いや、もちろん私の力不足というのはあります。特に2つ目のセッションはQ&Aのみであり、そもそも話したいこと、伝えたいポイントについてほとんど話せなかった…というのはあります。ですが、それにしても日本のオンプレ思考の強さってのはちょっと本当にまずいんじゃないかと改めて思ってしまいました。 いや、Nutanixさんがクラウド思考だったり、パブリッククラウドとの連携を強めてたりするのはわかってるんですけどね。いや、それにしても。 私が感じている「当たり前」というのは別に私がそう感じるからとかそういう話ではなくて、ガートナーだってそう言ってます。タイミングよくレポート記事を目にしたので画像を引用しつつリンクします。 引用元：OpenStack Days Tokyo：ガートナーが予測する消えるエンタープライズデータセンターの衝撃 | Think IT（シンクイット） 様々なデータをもとに未来を予測するGartnerはもう「エンタープライズのデータセンターは消える」くらいのことを言ってるんです。ポイントは「コンテナ」「サーバーレス」だと。(※私はその先にもう一回(コンテナやサーバーレスの良いところも取り込んだ)PaaSが重要になると思ってるのですが) この世界の流れと、日本のお客さんとの会話の乖離や、このようなイベントでの結果というのはどうしてなのか、どうにかならないのか…そういう思いで「ハイブリッドクラウド研究会」をやってますので、今日のもやもやはそちらの活動にぶつけようと思ってます。 …で、まぁ、本当はなんでなのかというのはわかってるんですよね。記事にも言及があるのと、こちらもタイムリーに業界の解説記事が出ていたのでそちらもリンクしてしまいます。 - [IT業界の仕組みと偽装請負の闇を分かりやすく解説しよう (1/3)：「多重下請け＋客先常駐＋偽装請負」のコンボで業火に包まれるな - ＠IT](http://www.atmarkit.co.jp/ait/articles/1809/11/news006.html) 詳しくは記事を読んでほしいのですがこういう構造の中では「クラウドを使ってビジネスに貢献するシステムづくりを！開発速度を上げて市場の変化に迅速に対応を！」…っていう発想にならないです。 - クラウドになってしまったら自分たちの仕事がなくなってしまうじゃないか - 早くシステムが作れちゃったら、もらえるお金がすくなくなってしまうじゃないか こういう発想にどうしてもなりやすい構造が業界としてあります。 エンドユーザー企業自体が優秀なエンジニアを高給で抱えて、自社のサービスを継続的に改善していく…こういう枠組みのなかでクラウドを使ったシステムづくりの良さが活きてきます。 日本は業界構造の改善が進まなければ、本当に世界からますます取り残されてしまう…という危機感を私はもう何年もずっと抱えてますが、はてさて。 でも、今日は一緒に登壇した方から、「最近はXXX系でもクラウドの話が多い」「XXX業界はIoTなどにすごく力を入れている」など日本の大手企業も変わりだしているという話を結構聞けました。それはすごく良かったです。
皆さんこんにちは。胡田です。 Windows Server 2008, 2008 R2のサポート終了が間近に迫る中、皆様いかがお過ごしでしょうか？ Azureへの移行にはAzure migrateが良い感じに使えます。スクリーンショットがほしい状況がありましたのでAzure Migrateのラボの手順をなぞりましたので簡単にスクリーンショット含めて共有しておきます。 Azure Migrateこれでまずは無料で使えちゃうっていうんですからすごいですよね～。 スタートはこちら - [Azure Migrate - VM 移行ソフトウェア | Microsoft Azure](https://azure.microsoft.com/ja-jp/services/azure-migrate/) ハンズオン ラボで Azure Migrate を試すという素敵なリンクがありますのでクリックします。 環境が自動作成されます。素敵ですよねぇ、こういうの。 環境ができました。目的が明示されます。Azure MigrateではオンプレミスのVMWare環境をアセスメントしてAzureにマイグレーションできるのか、パフォーマンスの状況からのサイジングの提示、コスト見積もりなどができる、ということですね。 地味に、VMWare環境のみが対象なのが現時点の弱点です。Hyper-Vへの拡張も普通に考えてありますよね！ マイグレーションプロジェクトを作成します。 Ctrl + Alt + Deleteを押してスタートです。パスワード等は下の説明に書かれています。 Azureにアクセスしていきます。 クレデンシャルは「Resources」にまとまってますね。 クリックするだけで入力してくれるのですが、キーボードレイアウトの影響でしょうか。記号が…。このあたりはパスワードも含めてがんばって対応します。 Azure管理ポータルにはいれました！ Azure Migrateを検索、選択します。 指示通りにMigration projectを作成します。ちなみにリソースグループを新規に作ろうとしたら権限がないと怒られました。デモ環境としてよくできていますね。 作成にはちょっと時間がかかります。そんなことまで教えてくれるUIが素敵です。 Migration projectに移動します。プレビューはもうとれてますね。 今作成したものをクリックします。 できたばかりの新品のプロジェクトです。まず、仮想マシンを探していきます。 正規の手順では情報収集のためのアプライアンスをダウンロードし、VMWare環境上に作成するのですが、それはもう終わっているそうです。素敵！3, 4のステップに進みます。 はい。次に進みます！ ...
今日は先日作ったTerraformファイルで作成したAzure上のVMに対して、先日作成したAnsibleが動作するコンテナ上でAnsibleのPlaybookを書いて、VMを構成してました。 - ドメインコントローラーに昇格(新規フォレスト作成) - 必要に応じて再起動 - StandAloneRootCAに構成 - 必要に応じて再起動 - サブジェクトの別名を利用可能に構成 - Azure Stackに必要な証明書のためのCSRを作成 というところまで自動化しました。 変な所で色々とハマりましたが、結局目的のところまではできたので良かったです。VMをAzure上にイチから作成するところから含めて全部やり直しても構築時間で15分もかからない感じに収まってます。 他にもDocker for WindowsをつかってLinuxコンテナを利用したり、実PCのファイルシステムをマウントしたり、Dockerfileを使ってのビルドをローカルPCとGitHub連携したDockerHub上でおこなったりというところもずいぶん慣れました。 ansibleでPSCredentialを渡す所でxxxx_username, xxxxx_passwordという形で表記しておけばよいだけとマニュアル上で読んだのですが、実はxxxxの部分に使う文字列によって挙動が異なるように見える部分があってかなり時間を無駄に消費しました。一部スペルミスもあったりなどもあり。よくわからないエラーが出たときには一度クリーンなところまで戻ってから文字をコピペせずに慎重に打ち直そう…と思ったのでした。 ansibleからPoweShellDSCを利用する部分も理解しましたし、昨日、今日で結構Terrafrom + ansible(+ PowerShell DSC)の組み合わせには慣れた気がします。 というわけで今日の成果はこちら。 - [https://github.com/ebibibi/hccjp/tree/master/VMConfigure](https://github.com/ebibibi/hccjp/tree/master/VMConfigure) 明日と明後日は贅沢に丸々2日間Puppetのトレーニングです！楽しみです。
TerraformでWindowsVMを展開した後はansibleで構成を自動化しようと考え中です。 Windowsからの管理は現実的に無理みたいなので、仕方なくDocker for Windows上のLinuxコンテナで管理しようとかんがえています。 ansibleの公式イメージをpullすれば瞬殺だろうと思ったのですが以下のあたりはもう公式ではイメージメンテナンスされてません、ということだったのでそのままの利用を躊躇してしまいました。 - [ansible/ubuntu14.04-ansible - Docker Hub](https://hub.docker.com/r/ansible/ubuntu14.04-ansible/) - [ansible/centos7-ansible - Docker Hub](https://hub.docker.com/r/ansible/centos7-ansible/) で、勉強も兼ねて自分でDockerfileを書きました。(あまり根本的解決になっていない気もしますが) - [ubuntu_ansible/Dockerfile at master · ebibibi/ubuntu_ansible](https://github.com/ebibibi/ubuntu_ansible/blob/master/Dockerfile) Dockerfile作成中には「pip install –upgrade pip」というコマンドも入れていたのですがこちらはpipの9と10のバージョン違いによるトラブルが発生してしまいうまく行かず。結局pipのアップグレードはやらないことにしました(逃げ)。 このあたりは下記ブログに解説されていました。 - [pip install --upgrade pip (10.0.0) 後の奇妙な挙動について - 雑記](http://icchy.hatenablog.jp/entry/2018/04/17/064443) 助かりました。ありがとうございます。 というわけで、Dockerイメージも準備できました。 - [ebibibi/ubuntu_ansible - Docker Hub](https://hub.docker.com/r/ebibibi/ubuntu_ansible/) 次は、このコンテナを利用して、Azure上に展開したWindowsVMを自動構成する予定です。明日時間取れる予定…！ 業務時間にこうやって自分がやりたい領域のことを勉強しながら作業できるのは本当にありがたいです。(注意：遊んでいるわけではありません。仕事です。)
今日はTerraformでWindows VMを作りました。 LinuxVMの作成サンプルとほぼ変わりませんが、一部展開後にAnsibleで管理される準備を自動実行させるぶぶんだけ工夫してみました。Terrafromでブートストラップしてから、ConfigurationはAnsibleで管理…、に自然に移行できるようにしているつもりです。 Ansibleでの構成はこれから試すので、できる想定…なのですが。 Terraformの作成サンプルはLinuxVMばかりでWindowsVMの例があまりないので少しは参考になる部分があるかもしれません。 - [https://github.com/ebibibi/AzureManagement/tree/master/Terraform/CreateWindowsVM](https://github.com/ebibibi/AzureManagement/tree/master/Terraform/CreateWindowsVM)
最近あるAzure Subscriptionに対して個別のユーザーに個別のRGのみ作成して権限を割り当てるということを都度都度行う必要が出てきました。 海よりも深い事情があり、普段利用している組織アカウントにはAzureサブスクリプションを紐付けられない理由があり(EA契約に紐付いているのでEA契約にコンバートされてしまう)、仕方なく別AADに紐づけて作成してあります。 でも、Azure環境は普段利用している組織アカウントを限定的な権限および範囲で使ってほしいため…以下のような作業をすることにしました。 - Azure AD B2Bで別のAADの組織ユーザーを招待する - 招待したユーザー用にリソースグループを1つ作成する - 作成したリソースグループに招待したユーザーを共同作成者としてアサインする 手作業だとちょっと時間かかりすぎるのと、繰り返し何人も都度都度対応する必要があるので、PowerShellスクリプトを書きました。 - [https://github.com/ebibibi/AzureManagement/blob/master/AAD/InviteUserWithAADB2B.ps1](https://github.com/ebibibi/AzureManagement/blob/master/AAD/InviteUserWithAADB2B.ps1) 外部テナントのユーザーを招待した直後に権限を割り当てて大丈夫なのかちょっと不安でしたが、どうやら意図したとおりにうまく動いているようです。
先日に引き続きTerraformで遊んでみました。とはいえ、まだWebにあるチュートリアルをそのままやってみているだけですが。 - [Use Terraform to create a complete Linux VM in Azure | Microsoft Docs](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/terraform-create-complete-vm) VSCode上で"Open Bash in Cloud Shell"を使って実行しています。 ほぼサンプルそのままで試したのですが、SSHの公開鍵の部分は自分のものにする必要がありました。 VSCode上のCloudShellでsshの鍵を生成する方法は以下を参照しました。 - [Azure での Linux VM 用の SSH キー ペアの作成と使用 | Microsoft Docs](https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/mac-create-ssh-keys) ssh-keygen -t rsa -b 2048 でキーペアを作成して、生成された公開鍵/home/mebisuda/.ssh/id_rsa.pubを指定しました。 あとは、いつものように、terraform init, plan, applyを実行すればOK。 今回は配置場所を東日本リージョンに変更していたのですが、編集を一部間違えて存在していないリージョン名を指定してしまいました。それでファイルを編集後にAzure Terraform: pushコマンドをVSCode上で実行しておらず、「なんで修正したのに反映されないんだろう？」とちょっと悩んでしまいました。 cloudshellの概念をきちんと抑えないといけないですね。 VSCode上で使っているCloudShellもAzureポータル上から使うcloudshellも同じものであり、リモートの環境である、ということを理解しました。(実装の理解としては間違ってるかもしれませんが、概念としてはあってると思います。) というわけで、仮想マシンを無事作成して、SSHで接続することができました。 最終的に利用したテンプレートは以下です。 - https://github.com/ebibibi/AzureManagement/blob/master/Terraform/Demos/CreateLinuxVM/createlinuxvm.tf とりあえずTerraform on Azure(っていう表現でいいのかな？)の基本は理解したと思います。あとは、ドキュメントを参照しながら試行錯誤でテンプレートを作成できるところまでは来ました。 次はいくつかサンプルを読み込んでみようと思います。 Terraform examples for Azure
TerraformでAzureをいじってみたい、ということで超簡単なところから触ってみています。 - [Download Terraform - Terraform by HashiCorp](https://www.terraform.io/downloads.html) よりバイナリダウンロード。とりあえずWindows版の64bitのバイナリをダウンロードしました。 - パスの設定。exeファイル１つだけなので、どこからでも使えるようにDropbox上に格納してそこにPATHを通しました。 - 環境を整える際のサンプルスクリプトがAzure CLIなのでAzure CLIの環境を整えます。 - Install the Azure CLI for Windows | Microsoft Docs よりMSIでAzure CLIをインストール - Visual Studio Code上で色々やろうと思うので、Azure CLI系やTerraform系の拡張を言われるがままに入れる。 Azure CLI Tools - Azure Resource Manager Tools - Azure Terraform - Terraform - 単純にリソースグループを作成するだけのtest.tfで試してみる provider “azurerm” { } resource “azurerm_resource_group” “rg” { name = “testResourceGroup” location = “westus” } テキストファイルを用意しておいて terraform init, plan, applyコマンドをそれぞれ投入するだけできちんと意図した状態になることを確認できました。素敵ですね。コンフィグファイルが読みやすくわかりやすいのが素敵です。そして、Visual Studio Codeがずいぶん素敵ですね、言われるがままに操作するだけで勝手に環境が整ってしまいました。 mebisuda@Azure:/clouddrive/AzureManagement/Terraform/Demos$ az group list [] mebisuda@Azure:/clouddrive/AzureManagement/Terraform/Demos$ terraform init ...