AWS OutpostsとAzure Stackの比較

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年後半を予定)、オンプレミスでも「クラウド」を利用する機運が高まってくれると良いなとあらためて思います。

May 9, 2019 · 1 min · 胡田昌彦

「組織(=顧客、会社)」と「テナント」の関係

皆さんこんにちは。胡田です。もう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のサブスクリプションを指しての言葉なのか等、しっかりとその意図するところを確認する必要があるでしょう。 「テナント」という言葉は注意して使いましょう というわけで、今回はなんだか締まらない内容になってしまいました。それだけ曖昧な言葉であるということです。話し手、書き手の意図をきちんと確認し、思い込みで誤解を生まないようにしていただければと思います。

January 16, 2019 · 1 min · 胡田昌彦

AWS OutpostsとMicrosoft Azure Stackに関して本質的に大事だと思うこと

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の普及も進んでほしいと思っています。「個別の無駄な苦労」はしなくて済むならそれでいいと思うのです。 #ちょっと極論を強い口調で書きすぎたかもしれません。気分を害された方ごめんなさい。

December 18, 2018 · 1 min · 胡田昌彦

MS最新VDIを知る

10月27日に行われたWindows Server Community Meetup #02で使ったスライドをSlideshareにアップロードしてあります。このブログで紹介するのを忘れていました。 [slideshare id=120926030&doc=windowsvirtualdesktopandremotedesktopservices2019-181027083515] 特にWindows Virtual DesktopはMicrosoft系で固めている企業なら「もうライセンス持ってるしどこで使おうか?」というレベルで使うことを前提に話ができるサービスだと思います。 登場は少し先になるのだと思いますが、しっかりと抑えておいてもらうと良いかと思います。

November 21, 2018 · 1 min · 胡田昌彦

アカウントの種類は何を使うべきか? - チャットでいただいた質問への回答

継続的にチャットにて質問をいただいております。結構会話が弾むこともありなかなか楽しいです。 私には会話相手が誰だかわからない状態から会話が始まり、継続的にフォローを希望する方はメールアドレスを登録してもらう事で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を選びます。迷わないです。

October 5, 2018 · 1 min · 胡田昌彦

Networld.next 2018 DXにて登壇 - 日本のIT業界の未来について思う

今日は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などにすごく力を入れている」など日本の大手企業も変わりだしているという話を結構聞けました。それはすごく良かったです。

September 11, 2018 · 1 min · 胡田昌彦

Azure Migrateのラボを体験

皆さんこんにちは。胡田です。 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のステップに進みます。 はい。次に進みます! ...

September 5, 2018 · 1 min · 胡田昌彦

AnsibleでWindows VMの構成

今日は先日作った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のトレーニングです!楽しみです。

July 18, 2018 · 1 min · 胡田昌彦

ansibleが使えるコンテナイメージ

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を自動構成する予定です。明日時間取れる予定…! 業務時間にこうやって自分がやりたい領域のことを勉強しながら作業できるのは本当にありがたいです。(注意:遊んでいるわけではありません。仕事です。)

July 17, 2018 · 1 min · 胡田昌彦

Terraformで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)

July 17, 2018 · 1 min · 胡田昌彦

Azure AD B2Bでユーザーを招待し、Azureサブスクリプション上で単一RGにのみ権限を付与する

最近ある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) 外部テナントのユーザーを招待した直後に権限を割り当てて大丈夫なのかちょっと不安でしたが、どうやら意図したとおりにうまく動いているようです。

July 13, 2018 · 1 min · 胡田昌彦

TerraformをつかってAzureにLinuxVMを作成してみました。

先日に引き続き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

May 23, 2018 · 1 min · 胡田昌彦

TerraformでAzureをいじってみました。

TerraformでAzureをいじってみたい、ということで超簡単なところから触ってみています。 - [Download Terraform - Terraform by HashiCorp](https://www.terraform.io/downloads.html) よりバイナリダウンロード。とりあえずWindows版の64bitのバイナリをダウンロードしました。 - パスの設定。exeファイル1つだけなので、どこからでも使えるように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 ...

May 22, 2018 · 3 min · 胡田昌彦

(主にインフラ系エンジニアから見た)コーディングやスクリプティングに関しての流れ

主にインフラエンジニアからみて、過去から現在までの流れ…のようなものを私が見えている範囲で記載してみました。昨今はクラウド化の流れと相まって非常に高度な自動化やインフラのコード化まで実現可能となっており例えば「スクリプトも書いたことありません」という人に対してどの領域から飛び込んでもらうのが効率的か…をちょっと悩んでいます。 もうコーディングレスでLogic Appとかそういうところに飛び込んでもらった方がはやいのかもしれないし、仮想基盤のことやWindows, Linuxの中の事はすっ飛ばしてTerraformとかコンテナとかそこに注力するところから入って必要が出たところで仮想マシン内部の処理に入ったほうがいいのかもしれません。でも、現実的にはシェルスクリプトとかPowerShellスクリプトの基礎とかは抑えておかないとだめかもしれないし・・・。結構悩ましい所です。 - 昔はバッチファイルやシェルスクリプトで繰り返し実施する作業の効率化がありました。 - その後Windows的にはWSHの時代があり、vbscriptでスクリプトを書いたひとも多かったと思います。 - その後Microsoft的にはコマンド毎にオプションが違ったりコマンドがなかったりすることを解決し、全て統一するものとしてPowerShellを生み出しました。(私の大好きな[Jeffery Snover](https://twitter.com/jsnover)さんの仕事です。) - これでMicrosoft系はPowerShellで全てオブジェクト指向の管理となりました。(バックグラウンドにあるのは.net framework) - 一方UNIX系は当初からなんでもかんでもテキストであるという思想でした。 - MicrosoftはPowerShellを標準として様々な製品を開発しました。GUIではできないことでもPowerShellでなら操作できる。GUIで操作しても裏ではPowerShellコマンドが自動生成されてそれが実行されている…というものも多くありました。(結果、仕方がなくPowerShellを使うようになった方も多いと思います。) - Microsoftはクラウドサービスにもその流れを取り入れました。PowerShellにてクラウドサービスの管理も行うことになりました。 - Chef, Puppetなどに代表されるような冪等性を備えた仕組みが登場してきました。(Infrastructure as code, Configuration as code) 何度実行しても「記載した望むべき状態になる」ことを特徴とします。 - これ以前は「これを実行したらこうなる、やって見る前に状態を確認して、やってみて、やった結果を確認する」というような作業の流れを記述するようなイメージでした。 - MicrosoftもPowerShell DSCにて冪等性を持つフレームワークを提供しました。 - Microsoftのオープンソース指向が進む中でよりマルチプラットフォーム化を意識した取り組みがなされるようになっていきます。 - PowerShellの継続開発が打ち切られ、PowerShellCoreに舵がきられます。PowerShellCoreはWindowsだけではなく、Linux, Mac等でも動作するマルチプラットフォームなPowerShellです。(バックグラウンドにあるのは.net core) - AzureにもCloudShellの機能がつき、ポータル上でもコードで制御できるようになります。これまでのAzure PowerShellよりも先にAzure CLI(UNIX系の文化)の方が先に搭載されました。Azure管理はPowerShellよりもCLIの方が優先されるようになってきています。 - クラウドサービスも普及する中で、大規模な環境ではもう個別に1台づつターミナルで作業するなり、RDPではいってGUIで操作するなりすることが現実的に不可能な規模になりました。このような環境ではコードで全てを制御可能な環境にすることは必須条件となりました。 - WindowsもWindows Server Coreが出てGUIがなくなり、さらにNano Serverにてどんどん軽量化していきます。 - Windows Server 2016, 2019となると継続的に進化するモデルはGUIが利用できなくなりました。 - 更に軽量化を推し進める中で仮想マシンではなく、コンテナに大きくトレンドが傾きます。 - コンテナの標準であるDockerはDockerfileというコンテナをコードで定義できる機構を備えています。 - クラウドサービスも冪等性をもったテンプレートにて展開可能な構造となります。AzureであればARMテンプレート、AWSであればCloud formationなど。 - ARMテンプレート、Cloud formationによるInfrastructre as Codeと仮想マシンの内部を構成するChef, Puppet, AnsibleのようなConfiguration as Codeによって仮想マシンベースの環境構築の完全自動化が可能となりました。 - ARMテンプレート、Cloud formationによるInfrastructre as CodeとDockerによるコンテナコントロールで完全自動化が可能となりました。 - 複数のコンテナプラットフォーム自体のコントロールという観点ではKubernetesが標準化してきています。 - AWSLambda, Azure Fuctionsのようなインフラ自体を意識せずアプリケーションロジックのみを記載すればそれでおしまいとなるようなサービスも出てきました。ここではInfrastructure as CodeやConfiguration as Codeすら必要ない世界があります。(これですべてまかなえるわけでもないですが) - DevOpsという流れもありますが、NoOpsに向かう流れの方が強そうに感じています。(私の感想) ※NoOpsはインフラ管理者がいらないという意味ではなく、極力インフラの面倒を見なくていいアーキテクチャを採用する、くらいの意味で捉えています。 ...

May 16, 2018 · 1 min · 胡田昌彦

クラウド時代のマイクロソフト系インフラ管理者はまずAzure Active Directoryを理解し活用しましょう

オンプレミスのActive Directory クラウドのAzure Active Directory マイクロソフト系のインフラ管理者にとってオンプレミスの時代に特に重要だったのはActive Directory(以下AD)でした。拙著(Windowsインフラ管理者入門)でも触れたところです。Windowsのドメインという仕組みがあり、そのドメインの中でIDを司るADがあり、アプリケーションはADに対応し、ADに参加したWindowsクライアントからアプリケーションを利用していたのです。 クラウド時代においても依然としてADは重要です。ですが、様々なクラウドサービスを利用し、他の企業とも連携していく必要性が高まる中で、企業内ネットワークに閉じてADのIDのみを利用したシステムだけを利用していればよい時代はとっくに終わりました。 オンプレミスのADをActive Directory Federation Services(以下ADFS)を介して外部とフェデレーションで結ぶという形態での社外ネットワークへの対応もありますが、現在向かっている方向は明らかにAD + ADFSという構成ではなく、クラウド上のIDaaSであるAzure Active Directory(以下AAD)です。AADをID基盤として利用する形態を中心に進化しています。 AADはマイクロソフトが提供するクラウドサービス(Office 365, Azure, Dynamics 365等)のほぼ全てのID基盤となっています。マイクロソフトのクラウドサービスを使っているユーザーは特に意識していなくてもすでにAADを利用しており、クラウド上にIDを保持しています。しかもAADは基本料金無料で提供されています。 また、オンプレミスにADを持つ企業が簡単にAAD上にIDを保持できるように、IDを同期、連携する仕組みも完全に無料で提供されています。 マイクロソフト系のインフラ管理者にとってオンプレミス時代にはADを、クラウド時代にはAADを軸にIDを管理し、そのIDを軸に様々なアプリケーション利用をコントロールすることはほぼ必然であり、まずはじめに抑えておく必要がある部分です。 AADでサービス連携、企業関連系、コンシューマーID連携 AADにはSAML 2.0, WSFederation, OpenConnectID、OAuth 2.0等の業界標準のプロトコルも採用され、マイクロソフトが提供するクラウドサービスにとどまらずインターネット上の様々なサービスと業界標準のプロトコルで連携可能になっています。AzureAD B2B, AzureAD B2C等、企業間の連携やtwitter, facebook等のコンシューマー向けのIDとの連携機能も備えています。 過去、ADを中心としたIDシステムにおいて企業間、グループ企業間でシームレスに連携させることは非常に困難でした。単純にネットワーク的につながっていないものを接続する所から苦労は始まり、個別にシステム毎に連携方法を模索し、ロジックを作り込んでいるケースが多くありました。 クラウド時代には過去と同じような苦労をする必要はありません。IDはインターネット上に存在しており、自由に標準的なプロトコルで連携可能となるのです。 セキュリティ対策 クラウド上にIDシステムが存在することでセキュリティ面の心配をする人も多くいると思います。ですがそれは逆です。むしろクラウド上にIDを保持することの方がセキュリティ面で有利である時代になっています。 クラウドサービスを全く使わずにIDもシステムも完全に社内ネットワークで閉じている状況であれば確かに外部からの攻撃に対しては非常に強いでしょう。入り口も出口も無く、窓を全て締め切っていれば外界から攻撃する手段はありません。それは事実です。ですが、このようにインターネットと分離した環境であったはずの環境においても利便性を求めた結果本来の設計とは異なる構成となってしまい、大規模なセキュリティ事故が起きた実例があります。 このクラウド時代に外部から完全に閉ざした鎖国状態のシステムを作っても生産性高く活動を行えるはずがありません。そうなるとインターネットとの接続をどうしてももつ必要があります。その段階でクラウド上にIDをもつか、オンプレミス上にあるIDに対しての認証の窓口を開かなくてはいけません。 インターネット上に常に存在し、多数の攻撃にさらされながらそれに耐え、しっかりとした運用体制やセキュリティ対策の取られているクラウド上のIDaaSを利用するのと、オンプレミスで自分たちで面倒を見ているシステムとでどちらがセキュリティが高いでしょうか。クラウド上のIDaaSには大量のIDをさばきながら取得できる情報を活用した高付加価値のセキュリティ対策サービスが多数備わっているという現実もあります。ここは人によって意見が分かれる場所かもしれませんが、私見ではあきらかにクラウド上にIDをおいたほうがセキュリティが高くできる現実がすでにあり、今後もその傾向はどんどん強まっていくと考えられます。 むしろ積極的にクラウド上にIDを置き、IDaaSが継続的に進化し続ける機能を把握し、それを有効に活用すべき時代になっていると考えます。 まずAzure Active Directoryの活用から マイクロソフト系のインフラ管理者がクラウドに足を踏み出す際には、個人的なおすすめとして是非AADの活用から考えてもらいたいと思います。AD+ADFSではなく、他社のIDaaSサービスではなくAADを利用してほしいです。 AADはマイクロソフトのクラウドサービスの根幹となり、全てのシステム、全ての仕組みに関連するものだからです。 そして、AADは無料でありいくつでも作成できるものなのですが、「本番AAD」を1つ作成し、基本的に全てのものをそこに紐付ける形にすることをお勧めします。つまりそれはシステム毎にID、Passwordを別々に作成して分割する…ということをしないようにするということです。私のおすすめは全て、例外なくです。他社製のクラウドサービスを利用するときですらです。 この構成をお勧めするのには様々な理由があり簡単に言い表すことは難しいのですが「1つのIDを利用して全てのものを利用可能とするのが最も便利でセキュアで運用コストが低いから」です。この点はもっと説明が必要ですのでまた今後のブログエントリで解説していきたいと思います。

April 22, 2018 · 1 min · 胡田昌彦

マイクロソフトアカウントを新規に作成すると対応するAADテナントと組織アカウントも作成されていた!

このあたり追いかけていない人には何のことかわからないと思いますが、個人的に衝撃だったので簡単にブログにポストします。 - マイクロソフトアカウントを作成すると、そのユーザー名とメールドメインに紐付いて自動的にAADテナントが作成されるようになっていました! - しかも、そのAADテナントには**マイクロソフトアカウントに紐づけたメールアドレスがユーザー名である組織アカウント**が自動作成されています! 上記がその証拠画像です。 いつからこうなってたんでしょうか?マイクロソフトアカウントを作成するときにAADにすでに登録済みのドメインのメールアドレスは使えないようになったのはずいぶん前ですが、この条件であればこうできるのかな?という感じではありますが。 マイクロソフトアカウントはAzureからみると以前はAADには紐付かない宙ぶらりんなアカウントでしたが、今はAzure利用という観点でみるとしっかりとAADにも紐づく存在になってきているようです。 もっとも、新規作成のマイクロソフトアカウントはこの状態だとしても、以前から存在しているマイクロソフトアカウントはまた違うようですが。 それにしても、AADに追加した確認済みのドメイン名ではないドメインの組織アカウントがディレクトリ内に存在する状態にしてしまって、ほかとの整合性は大丈夫なんでしょうか?ちょっと心配な部分もありますが、うまくさばいてくれることを期待しながら…。 なお、このようにマイクロソフトアカウントもAADに紐付いたので、サブスクリプション転送時にもディレクトリの切り替えが発生するパターンが増えていますね。このあたり諸々注意が必要です。 個人的にはもうマイクロソフトアカウントも全部完全にAADのアカウントです、という形で整理してくれた方がスッキリする気がしますが…。

April 12, 2018 · 1 min · 胡田昌彦

このサイトの構造について(Web App for Containers)

このサイトはWordpressで構築されています。Azure上のサービスであるWeb App for ContainersにDocker Hub上の「wordpress」コンテナイメージを元にカスタマイズしたコンテナイメージを展開して動作させています。 Web App for Containersは本記事執筆時点の2018年3月現在では相対的に新しいサービスであり、これを使ったWordpressサイトの構築手法に関してはまだあまり情報がなかったため、備忘録も兼ねて構造を書き残しておきます。 全体像 下図がシステムの全体像です。 実行環境は全てAzure上にあり、1つのリソースグループに格納されています。 App Service on Linuxにより環境が定義され、その上でWeb App for Containerが可動しています。 Wordpressはコンテナ上で実行されています。 データベースとしてはAzure Database for MySQLを利用しています。 App Serviceドメインにて独自のドメイン(ebisuda.net)を取得、割当しており、DNSもAzure DNSを利用しています。 Web App for Containersに展開するコンテナイメージはDocker Hub上のカスタムイメージとして公開されています。 https://hub.docker.com/r/ebibibi/appservice-wordpress/ Web App for Containerにてこのコンテナイメージを利用するように設定を行っています。 Docker Hub上のこのコンテナイメージは、Git Hub上のレポジトリがソースに指定されています。 具体的には下記のレポジトリがソースです。 https://github.com/ebibibi/appservice-wordpress このレポジトリ内にDockerfileが記載されており、このDockerfileの記載内容に従ってコンテナイメージがビルドされます。 このGitHub上のレポジトリを手元のPCにクローンしVSCodeにて編集している状況です。 コンテナイメージ更新の流れ なにか設定を変更したい場合には手元のVSCodeにてDockerfileを編集することであとは全自動でWeb App for Containerまで展開されるようにしています。流れは以下となります。 - VSCodeにてDockerfile編集 - VSCodeからGitHubレポジトリへgit push - GitHubレポジトリとDocker Hubの連携機能によりpushが検知される - Docker Hub上でコンテナイメージの自動ビルド - Docker Hub上でのビルド完了時にWeb App for ContainerのWeb Hook URLに対してPostが実行される - Web App for ContainerがDocker Hubからビルド完了済みの最新イメージを取得 - 更新された最新イメージが実行される 体験としては、手元のVSCodeで必要な編集を行い、コミット、プッシュするのみであとは全自動のため非常に快適です。 ...

March 24, 2018 · 3 min · 胡田昌彦

Azure MigrateがGAしています

Source: Confidently plan your cloud migration: Azure Migrate is now generally available! | Blog | Microsoft Azure Azure MigrateがGAしてますね。 システム間の依存関係を可視化するServiceMap(OMSに入ってるやつ)が無料で使えるそうです。 No charge for dependency visualization: Visualize network dependencies of your multi-tier application without getting charged for Service Map. 一歩進んだアセスメントサービスをするのには非常に有用なツールになってると思います。 さらにVMWareの対応が先でHyper-V環境は今後対応する、というのが生々しくて良いですね!今のMicrosoftらしさが出ていると思います。 It enables discovery of VMware-virtualized Windows and Linux VMs today and will enable discovery of Hyper-V environments in the future.

March 1, 2018 · 1 min · 胡田昌彦

Azureのコスト最適化とセルフサービス

最近仕事の一つとしてAzure利用の無駄を調べて利用料金を最適化する事をしています。 Azure自体種類が沢山ありますし利用料金の取得はそれぞれ色々な手法がありますが、料金の無駄を省く…という観点だとEA契約を対象にすることが多く、まずはAzure EAポータルからAPIキーを使って利用料金を取得する手法であれこれするのが良さそうです。 個人的に一番やりやすいと思っているのはPowerBIと連携してレポートを作成する手法です。データ連携は簡単にできますし、あとはPowerBIの豊かな表現力を使って自由にさまざまな切り口で利用状況を可視化する事ができます。 EA Azure自体で適切に部署、アカウント、サブスクリプションの構造を作成するのがまず必須事項で、その上でその切り口で情報を可視化するのが良いです。 さらにリソースグループやタグを使った構造を採用しているならその切り口でもみられるようにするビューも必要ですね。 もちろんこの辺りはcloudyn(Azure Cost Management)を利用するのでも良いです。 で、ここまではいいのですが、「本当にこのVMのサイズは適切なのか?」というようなところまで踏み込もうとするとAzureのサブスクリプション自体に権限を持たないといけません。権限を持てば CPU, Netwotk, Storageがどの程度実際に使われているか(使われてなければサイズを下げるべきかも)- アタッチされていないVHDファイルなども見えてきます。 この辺りの情報を元にAzure Cost Management では最適化候補をレポーティングしてくれます。(もちろん全てそのまますぐに指示に従ってやればいいとはならないのですが) が、このAzureサブスクリプションに対して権限を付与する操作周りがとても大変です。 そもそもAzureはセルフサービスでバンバンサブスクリプションを作って各種サービスを使ってシステムを作っていくことができます。その自由さやスピードが1番の良いところだと私は思っています。 が、多くの人がそれぞれバラバラに作成したサブスクリプションに対して管理者が漏れなく権限を持つ、それによってサブスクリプション内部まで情報を取得して無駄を発見する…ということができないのです。 組織の管理者であっても、誰であっても、サブスクリプションの所有者によって明示的に権限を付与されなければ何もできない構造になっています。 利用者が全員技術的にしっかりと理解した人なのであれば完全に任せておくだけで良いのでしょうけれども、現実的にはなかなか難しく。コストを支払う部署なり、人なりがきちんとその責任でもって使っているのだからこれでいいのだ!というように割り切ればそれでおしまいですが、やはりこのあたりはコントロールしたくなる人の気持がわかります。 で、よく考えるとCSPではこのようなことが発生しない構造になってるんですよね。サービスプロバイダーは全ての顧客の全ての環境に権限を持つことができます。 さて、Azure EAにおいても管理者が全てのサブスクリプションに対して監視のための権限はもちつつ、セルフサービスのスピード感も損ないたくない…という時にそれが可能なのかというと…別途System Center Service Managerですとか、もう一枚仕組みを噛ませば簡単に実現できますね。 ユーザーは申請を出して、全自動でサブスクリプションが発行されるけれども、同時に組織の管理者にも権限がわりあたっている…そんな状況が理想なのかもしれません。 と、思いながら今日も権限くださーい。あるいは、サービスに権限つけてくださーい。とお願いして回るのでした。

January 26, 2018 · 1 min · 胡田昌彦

VMWare on Azure周り

MicrosoftからVMWareのベアメタルソリューションをAzureにて提供する、という話があって驚きました。 Transforming your VMware environment with Microsoft Azure | ブログ | Microsoft Azure 私の理解ではMicrosoftの戦略の中心は「クラウド化」にあるのであり、VMWare(Hyper-Vも同じ位置づけ)によるものは「仮想化」であってそもそも注力する領域ではない…と思っていましたのでこの発表には「え?そこやっちゃうの?」という驚きがありました。 もちろん、現場からのニーズはそこに強くあるとは思うのですけどね。 以下は私なりのMicrosoftさんのクラウド化戦略に関しての解釈です。 と、思ったらVMWareさんから「お勧めしないし、サポートもしないよ」というコメントが出てました。 Article Detail - VMware Blog VMWareと組んでVMWare on Azureを実現するという話なのかと誤解していましたが、そうではないようですね。ある意味納得です。

November 28, 2017 · 1 min · 胡田昌彦

AI・テクノロジーの情報を発信しています

YouTube

AI・テクノロジーの最新トレンドを動画で配信中

note

技術コラム・深掘り記事を公開中