diff --git a/docs/framework/configure-apps/file-schema/wcf/service.md b/docs/framework/configure-apps/file-schema/wcf/service.md index a760bdd84a3..5ce270f7f68 100644 --- a/docs/framework/configure-apps/file-schema/wcf/service.md +++ b/docs/framework/configure-apps/file-schema/wcf/service.md @@ -2,11 +2,11 @@ title: '<サービス>' ms.date: 03/30/2017 ms.assetid: 13123dd6-c4a9-4a04-a984-df184b851788 -ms.openlocfilehash: a73e4699e0998338f09e1ed0504f5b1cfd73b225 -ms.sourcegitcommit: 11f11ca6cefe555972b3a5c99729d1a7523d8f50 +ms.openlocfilehash: 6e83e988920d24c6fe7615e40334919caf21652e +ms.sourcegitcommit: ff1d40507b3eb6e2185478e37c66c66be6de46f1 ms.translationtype: MT ms.contentlocale: ja-JP -ms.lasthandoff: 05/03/2018 +ms.lasthandoff: 05/11/2018 --- # <サービス> `service` 要素には Windows Communication Foundation (WCF) サービスの設定が含まれます。 また、サービスを公開するエンドポイントも含まれます。 @@ -19,7 +19,7 @@ ms.lasthandoff: 05/03/2018 ```xml ``` diff --git a/docs/framework/wcf/feature-details/configuring-http-and-https.md b/docs/framework/wcf/feature-details/configuring-http-and-https.md index 8a0d865c663..68a208400ab 100644 --- a/docs/framework/wcf/feature-details/configuring-http-and-https.md +++ b/docs/framework/wcf/feature-details/configuring-http-and-https.md @@ -4,11 +4,11 @@ ms.date: 03/30/2017 helpviewer_keywords: - configuring HTTP [WCF] ms.assetid: b0c29a86-bc0c-41b3-bc1e-4eb5bb5714d4 -ms.openlocfilehash: 70c947724abf8da68ec8f7e6d858e26fec62dce5 -ms.sourcegitcommit: 3d5d33f384eeba41b2dff79d096f47ccc8d8f03d +ms.openlocfilehash: ed9c7a444018e7c5e9ac00de82133cce633fac93 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 ms.translationtype: MT ms.contentlocale: ja-JP -ms.lasthandoff: 05/04/2018 +ms.lasthandoff: 05/10/2018 --- # HTTP および HTTPS の構成 WCF サービスと WCF クライアントは、HTTP および HTTPS を介して通信できます。 HTTP または HTTPS の設定は、インターネット インフォメーション サービス (IIS) またはコマンド ライン ツールを使用して構成します。 WCF サービスが IIS でホストされている場合は、IIS 内で HTTP または HTTPS の設定を構成できます (inetmgr.exe ツールを使用)。 WCF サービスが自己ホスト型の場合は、コマンド ライン ツールを使用して HTTP または HTTPS の設定を構成します。 @@ -19,7 +19,7 @@ WCF サービスと WCF クライアントは、HTTP および HTTPS を介し 実行しているときに[!INCLUDE[ws2003](../../../../includes/ws2003-md.md)]または[!INCLUDE[wxp](../../../../includes/wxp-md.md)]、HttpCfg.exe ツールを使用します。 [!INCLUDE[ws2003](../../../../includes/ws2003-md.md)] ではこのツールが自動的にインストールされます。 実行しているときに[!INCLUDE[wxp](../../../../includes/wxp-md.md)]、ツールをダウンロードする[Windows XP Service Pack 2 サポート ツール](http://go.microsoft.com/fwlink/?LinkId=88606)です。 詳細については、次を参照してください。 [Httpcfg の概要](http://go.microsoft.com/fwlink/?LinkId=88605)です。 - [!INCLUDE[wv](../../../../includes/wv-md.md)] または Windows 7 を実行している場合は、Netsh.exe ツールを使用してこれらの設定を構成します。 + 実行しているときに[!INCLUDE[wv](../../../../includes/wv-md.md)]Windows 7、Netsh.exe ツールを使用してこれらの設定を構成することもできます。 ## 名前空間予約の構成 名前空間予約では、HTTP URL 名前空間の一部に対する権限を特定のユーザー グループに割り当てます。 予約によって、名前空間のその部分でリッスンするサービスを作成する権限をユーザーに与えます。 予約は URL プレフィックスを使用します。つまり、予約は予約パスのすべてのサブパスを範囲とします。 名前空間予約では、2 つの方法でワイルドカードを使用できます。 HTTP サーバー API のドキュメントについて説明します、[ワイルドカードを含む名前空間クレーム間の解決順序](http://go.microsoft.com/fwlink/?LinkId=94841)です。 diff --git a/docs/framework/wcf/feature-details/duplex-services.md b/docs/framework/wcf/feature-details/duplex-services.md index c7448ca9a6c..d2b04a9e947 100644 --- a/docs/framework/wcf/feature-details/duplex-services.md +++ b/docs/framework/wcf/feature-details/duplex-services.md @@ -1,15 +1,15 @@ --- title: 双方向サービス -ms.date: 03/30/2017 +ms.date: 05/09/2018 dev_langs: - csharp - vb ms.assetid: 396b875a-d203-4ebe-a3a1-6a330d962e95 -ms.openlocfilehash: afe72b01fe3ec38cc34b0a7ff4d28ff714cf3dd2 -ms.sourcegitcommit: 3d5d33f384eeba41b2dff79d096f47ccc8d8f03d +ms.openlocfilehash: da92b8f2d1223f582677a93a8ff6fd697512d297 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 ms.translationtype: MT ms.contentlocale: ja-JP -ms.lasthandoff: 05/04/2018 +ms.lasthandoff: 05/10/2018 --- # 双方向サービス 双方向サービス コントラクトは、両方のエンドポイントが互いに独立してメッセージを送信できるメッセージ交換パターンです。 双方向サービスでは、クライアントのエンドポイントにメッセージを返信できるため、イベントのような動作を実現できます。 双方向通信は、クライアントがサービスに接続し、サービスからクライアントにメッセージを返信できるチャネルがサービスに提供されると発生します。 双方向サービスにおけるイベントのような動作は、セッション内でのみ機能することに注意してください。 @@ -52,14 +52,19 @@ HTTP could not register URL htp://+:80/Temporary_Listen_Addresses/ because TCP port 80 is being used by another application. ``` - 次のサンプル コードは、コードでクライアントのエンドポイント アドレスを指定する方法を示しています。 + 次のサンプル コード方法を示します、クライアントを指定するエンドポイント アドレス プログラム。 -``` +```csharp WSDualHttpBinding binding = new WSDualHttpBinding(); EndpointAddress endptadr = new EndpointAddress("http://localhost:12000/DuplexTestUsingCode/Server"); binding.ClientBaseAddress = new Uri("http://localhost:8000/DuplexTestUsingCode/Client/"); ``` - +```vb +Dim binding As New WSDualHttpBinding() +Dim endptadr As New EndpointAddress("http://localhost:12000/DuplexTestUsingCode/Server") +binding.ClientBaseAddress = New Uri("http://localhost:8000/DuplexTestUsingCode/Client/") +``` + 次のサンプル コードは、構成でクライアントのエンドポイント アドレスを指定する方法を示しています。 ```xml diff --git a/docs/fsharp/language-reference/interfaces.md b/docs/fsharp/language-reference/interfaces.md index 7d7cc51664f..b76958d1605 100644 --- a/docs/fsharp/language-reference/interfaces.md +++ b/docs/fsharp/language-reference/interfaces.md @@ -2,11 +2,11 @@ title: インターフェイス (F#) description: F# でインターフェイスが他のクラスを実装する関連するメンバーのセットを指定する方法について説明します。 ms.date: 05/16/2016 -ms.openlocfilehash: 174e30c03cd555d2d9c89c88bd80e06a2cdcef46 -ms.sourcegitcommit: 3d5d33f384eeba41b2dff79d096f47ccc8d8f03d +ms.openlocfilehash: 54ae8a2840ce26814be25f08c3ed02e12df6b7c0 +ms.sourcegitcommit: ff1d40507b3eb6e2185478e37c66c66be6de46f1 ms.translationtype: MT ms.contentlocale: ja-JP -ms.lasthandoff: 05/04/2018 +ms.lasthandoff: 05/11/2018 --- # インターフェイス @@ -17,7 +17,7 @@ ms.lasthandoff: 05/04/2018 ```fsharp // Interface declaration: [ attributes ] -type interface-name = +type [accessibility-modifier] interface-name = [ interface ] [ inherit base-interface-name ...] abstract member1 : [ argument-types1 -> ] return-type1 abstract member2 : [ argument-types2 -> ] return-type2 @@ -43,6 +43,8 @@ let class-name (argument-list) = ## コメント インターフェイスの宣言では、メンバーを実装していないする点を除いて、クラス宣言が似ています。 代わりに、すべてのメンバーが、抽象キーワードによって示される`abstract`です。 抽象メソッドのメソッド本体を指定しません。 ただしもと共にメソッドとして、メンバーの個別の定義を含めることで、既定の実装を用意することができます、`default`キーワード。 これは、他の .NET 言語の基本クラスでの仮想メソッドの作成と同じです。 このような仮想メソッドは、インターフェイスを実装するクラスでオーバーライドできます。 +インターフェイスの既定のアクセシビリティが`public`です。 + 各メソッドのパラメーターに f# の通常の構文を使用して名前を付けることができます必要に応じて。 [!code-fsharp[Main](../../../samples/snippets/fsharp/lang-ref-1/snippet24032.fs)] diff --git a/docs/fsharp/language-reference/modules.md b/docs/fsharp/language-reference/modules.md index 6cb10696fb4..820bd5742ba 100644 --- a/docs/fsharp/language-reference/modules.md +++ b/docs/fsharp/language-reference/modules.md @@ -2,11 +2,11 @@ title: モジュール (F#) description: F# モジュールは、f# コード、値、型、および f# プログラムでは、関数の値などのグループ化方法について説明します。 ms.date: 04/24/2017 -ms.openlocfilehash: b503a78abed34cbb56a7a1ceaba61f851a125831 -ms.sourcegitcommit: 3d5d33f384eeba41b2dff79d096f47ccc8d8f03d -ms.translationtype: HT +ms.openlocfilehash: ddb6a0762171f8acc94f0ba0cf29c4b6b3e4990e +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT ms.contentlocale: ja-JP -ms.lasthandoff: 05/04/2018 +ms.lasthandoff: 05/10/2018 --- # モジュール @@ -101,23 +101,24 @@ module rec RecursiveModule = member val IsPeeled = false with get, set member val Orientation = orientation with get, set member val Sides: PeelState list = [ Unpeeled; Unpeeled; Unpeeled; Unpeeled] with get, set - + member self.Peel() = BananaHelpers.peel self // Note the dependency on the BananaHelpers module. member self.SqueezeJuiceOut() = raise (DontSqueezeTheBananaException self) // This member depends on the exception above. - module private BananaHelpers = - let peel (b : Banana) = - let flip banana = + module BananaHelpers = + let peel (b: Banana) = + let flip (banana: Banana) = match banana.Orientation with | Up -> banana.Orientation <- Down banana | Down -> banana - let peelSides banana = - for side in banana.Sides do - if side = Unpeeled then - side <- Peeled + let peelSides (banana: Banana) = + banana.Sides + |> List.map (function + | Unpeeled -> Peeled + | Peeled -> Peeled) match b.Orientation with | Up -> b |> flip |> peelSides diff --git a/docs/fsharp/language-reference/namespaces.md b/docs/fsharp/language-reference/namespaces.md index 8df7dc82bed..5f9d9b01f8e 100644 --- a/docs/fsharp/language-reference/namespaces.md +++ b/docs/fsharp/language-reference/namespaces.md @@ -2,11 +2,11 @@ title: 名前空間 (F#) description: F# で名前空間を使用できるプログラム要素のグループに名前をアタッチするようにすることによって関連する機能の領域にコードを整理する方法について説明します。 ms.date: 04/24/2017 -ms.openlocfilehash: 81d1648dbdc111984ddeb77d11b2bd81cbca57cf -ms.sourcegitcommit: 3d5d33f384eeba41b2dff79d096f47ccc8d8f03d +ms.openlocfilehash: 151079864f18fff79dac108889b68b3acf1566a1 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 ms.translationtype: MT ms.contentlocale: ja-JP -ms.lasthandoff: 05/04/2018 +ms.lasthandoff: 05/10/2018 --- # 名前空間 @@ -88,23 +88,24 @@ type Banana(orientation : Orientation) = member val IsPeeled = false with get, set member val Orientation = orientation with get, set member val Sides: PeelState list = [ Unpeeled; Unpeeled; Unpeeled; Unpeeled] with get, set - + member self.Peel() = BananaHelpers.peel self // Note the dependency on the BananaHelpers module. member self.SqueezeJuiceOut() = raise (DontSqueezeTheBananaException self) // This member depends on the exception above. module BananaHelpers = - let peel (b : Banana) = - let flip banana = + let peel (b: Banana) = + let flip (banana: Banana) = match banana.Orientation with | Up -> banana.Orientation <- Down banana | Down -> banana - let peelSides banana = - for side in banana.Sides do - if side = Unpeeled then - side <- Peeled + let peelSides (banana: Banana) = + banana.Sides + |> List.map (function + | Unpeeled -> Peeled + | Peeled -> Peeled) match b.Orientation with | Up -> b |> flip |> peelSides diff --git a/docs/fsharp/language-reference/type-abbreviations.md b/docs/fsharp/language-reference/type-abbreviations.md index 94c228316c8..fd628ed7309 100644 --- a/docs/fsharp/language-reference/type-abbreviations.md +++ b/docs/fsharp/language-reference/type-abbreviations.md @@ -2,11 +2,11 @@ title: 型略称 (F#) description: F# 型の省略形型に名前を付けるより意味のあるコードを読みやすくためにについて説明します。 ms.date: 05/16/2016 -ms.openlocfilehash: cd0b2365aecc5d5b73df95a4b94ae4dd8327446d -ms.sourcegitcommit: 3d5d33f384eeba41b2dff79d096f47ccc8d8f03d +ms.openlocfilehash: e222caa41a20a64071c94cffea6ea7b2bec8eb22 +ms.sourcegitcommit: ff1d40507b3eb6e2185478e37c66c66be6de46f1 ms.translationtype: MT ms.contentlocale: ja-JP -ms.lasthandoff: 05/04/2018 +ms.lasthandoff: 05/11/2018 --- # 型略称 @@ -15,12 +15,14 @@ A*型略称*エイリアスまたは型の代替名です。 ## 構文 ```fsharp -type type-abbreviation = type-name +type [accessibility-modifier] type-abbreviation = type-name ``` ## コメント 型の省略形を使用すると、コードを読みやすくために、型、わかりやすい名前を付けます。 種類が書き込みに面倒なを使いやすい名を作成するのにも使用できます。さらに、型を使用するすべてのコードを変更しなくても、基になる型を変更しやすく型の省略形を使用することができます。 単純型の省略形を次に示します。 +型の省略形のユーザー補助機能が既定で`public`です。 + [!code-fsharp[Main](../../../samples/snippets/fsharp/lang-ref-1/snippet2301.fs)] 型の省略形は、次のコードのように、ジェネリック パラメーターを含めることができます。 diff --git a/docs/standard/modernize-with-azure-and-containers/index.md b/docs/standard/modernize-with-azure-and-containers/index.md index 4a6ed7425b7..c97a0a77a7e 100644 --- a/docs/standard/modernize-with-azure-and-containers/index.md +++ b/docs/standard/modernize-with-azure-and-containers/index.md @@ -1,16 +1,16 @@ --- -title: Azure クラウドおよび Windows コンテナーで既存の .NET アプリケーションを最新化する -description: リフト アンド シフト既存のアプリケーションを Azure クラウドおよび電子書籍とコンテナーを説明します。 +title: 既存 .NET アプリケーションで Azure のクラウドと Windows コンテナーを最新化 (第 2 版) +description: リフトしシフトし、既存のアプリケーションを Azure クラウドおよび電子書籍とコンテナーを最新化する方法を学習します。 author: CESARDELATORRE ms.author: wiwagn -ms.date: 10/26/2017 -ms.openlocfilehash: 3109cac1bd64587bb096a057f6f4ae99b055352a -ms.sourcegitcommit: 3d5d33f384eeba41b2dff79d096f47ccc8d8f03d +ms.date: 4/28/2018 +ms.openlocfilehash: 3fcfdca68e05494785148cbbe149cdc2f812c577 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 ms.translationtype: MT ms.contentlocale: ja-JP -ms.lasthandoff: 05/04/2018 +ms.lasthandoff: 05/10/2018 --- -# Azure クラウドおよび Windows コンテナー (v1.0) で既存の .NET アプリケーションを最新化する +# Azure のクラウドと Windows コンテナーの既存の .NET アプリケーションを最新化 (第 2 版) ![カバーの画像](./media/cover.png) @@ -20,7 +20,7 @@ Divisions of Microsoft Corporation One Microsoft Way Redmond, Washington 98052-6399 -Copyright © 2017 by Microsoft Corporation +Copyright © by Microsoft Corporation 2018 All rights reserved. 本書のいかなる部分も、書面による発行者の許可なしに、いかなる形式または方法によっても、複製することを禁じます。 @@ -47,9 +47,9 @@ Microsoft およびに記載されている商標http://www.microsoft.com「商 ## はじめに -Web アプリケーションを最新化し、クラウドに移動すると決定した場合は、アプリを完全に再構築する必要があるとは限りません。 マイクロサービスのような高度なアプローチを使用したアプリケーションの再構築は、コストと時間の制約があるため必ずしも選択肢となりません。 アプリケーションの種類に応じて、アプリの再構築も必要ない場合があります。 組織のクラウドの移行戦略のコストを最適化するには、ビジネスのニーズとアプリの要件を考慮することが重要です。 次のことを決定する必要があります。 +Web アプリケーションまたはサービスを最新化し、クラウドに移動する場合は、アプリを完全に再構築しがないとは限りません。 Microservices のような高度なアプローチを使用してアプリケーションをよう再設計することができません常にコストと時間の制約が原因です。 アプリケーションの種類、によってアプリよう再設計するもは必要ありません。 組織のクラウドの移行戦略のコストを最適化するには、ビジネスのニーズとアプリの要件を考慮することが重要です。 次のことを決定する必要があります。 -- どのアプリの変換と再設計が必要か。 +- どのアプリが変換が必要か、よう再設計します。 - どのアプリの部分的な再構築のみが必要か。 @@ -57,11 +57,9 @@ Web アプリケーションを最新化し、クラウドに移動すると決 ## このガイドについて -このガイドでは、"リフト アンド シフト" シナリオと既存の Microsoft .NET Framework Web アプリケーションまたはサービス指向アプリケーションの初期最新化に主に焦点を当てています。 リフト アンド シフトは、アプリケーションのコードや基本的なアーキテクチャを変更せずに、ワークロードを新しい最新化された環境に移行する作業です。 +このガイド重点的に既存の Microsoft .NET Framework web またはサービス指向アプリケーションの初期近代化新しいまたは最新の環境にアプリケーションのコードを大幅に変更することがなく、ワークロードを移動アクションの意味で基本的なアーキテクチャ。 -このガイドでは、アプリケーション全体を最構築または再コーディングせずに、特定の領域を最新化することによって、既存の.NET Framework サーバー アプリケーションを直接クラウドに移行する方法について説明します。 - -このガイドでは、アプリをクラウドに移動し、Windows のコンテナーや Azure のオーケストレーターなどの新しいテクノロジやアプローチの特定のセットを使用してアプリを部分的に最新化する場合のメリットも説明します。 +このガイドでは、アプリをクラウドに移動し、新しいテクノロジおよび Windows コンテナーと Windows コンテナーをサポートする Azure のコンピューティング プラットフォームで関連するなどの方法の特定のセットを使用してアプリを部分的に刷新の利点も強調表示されます。 ## 既存の .NET アプリケーションのクラウドへのパス @@ -69,7 +67,7 @@ Web アプリケーションを最新化し、クラウドに移動すると決 アプリケーションをクラウドに移行するための 1 つの万能型の戦略はありません。 右側の移行の戦略は、組織のニーズと優先度、および移行するアプリケーションの種類によって異なります。 すべてのアプリケーションがサービスとしてのプラットフォーム ([PaaS](https://azure.microsoft.com/overview/what-is-paas/)) モデルへの移行や[クラウド ネイティブ](https://www.gartner.com/doc/3181919/architect-design-cloudnative-applications) アプリケーション モデルの開発の投資を保証するわけではありません。 多くの場合は、ビジネス ニーズに基づいて、資産をクラウドに移行する際に段階的なまたは増分アプローチで投資を実行できます。 -最適な長期的機敏性と組織のための価値を持つ最新のアプリケーションの場合、*クラウドに向けて最適化された**クラウド ネイティブ*のアプリケーション アーキテクチャに投資するとメリットが得られることがあります。 ただし、既存のアプリケーションまたは従来の資産にとって重要なのは、クラウドに移行するときにかかる時間とコストを最小限に抑えながら (再設計やコード変更なしで)、大きなメリットを実現することです。 +最適な長期的な機敏性と組織の値を持つモダン アプリケーションの場合への投資からメリットがある*クラウド ネイティブ*アプリケーション アーキテクチャ。 、既存のアプリケーションまたは従来の資産は、キーが大きなメリットを実現する、クラウドに移動しながら、最小限の時間とコスト (よう再設計するか、コード変更なし) を費やすです。 図 1-1 は、既存の .NET アプリケーションを段階的なフェーズでクラウドに移動する場合に実行できる可能性のあるパスを示しています。 @@ -79,28 +77,29 @@ Web アプリケーションを最新化し、クラウドに移動すると決 各移行アプローチには、さまざまな利点とそれを使用する理由があります。 アプリをクラウドに移行するときには単一のアプローチを選択することも、複数のアプローチから特定のコンポーネントを選択することもできます。 個々 のアプリケーションは、1 つのアプローチまたは成熟度の状態に制限されません。 たとえば、一般的なハイブリッド アプローチには、オンプレミスのコンポーネントに加えてその他のコンポーネントがクラウドにあります。 -最初の 2 つの移行レベルで、アプリケーションのリフト アンド シフトのみを実行できます。 +次の定義と各アプリケーションの成熟度レベルの簡単な説明を示します。 -**Level 1: クラウド インフラストラクチャの準備完了**: この移行アプローチでは、単純に現在のオンプレミス アプリケーションをサービスとしてのインフラストラクチャ ([IaaS](https://azure.microsoft.com/overview/what-is-iaas/)) プラットフォームに再ホストまたは移動します。 アプリの構成は前とほとんど変わりませんが、クラウド内の VM に展開します。 +**Level 1: クラウド インフラストラクチャの準備完了**アプリケーション: この移行の方法では、単に移行またはするサービスとしてのインフラストラクチャを現在の内部設置型アプリケーションを再ホスト ([IaaS](https://azure.microsoft.com/overview/what-is-iaas/)) プラットフォームです。 アプリの構成は前とほとんど変わりませんが、クラウド内の VM に展開します。 +この単純な種類の移行は、"リフト & シフト"として業界で通常呼びます -**レベル 2: クラウド DevOps 対応**: このレベルでは、初期リフト アンド シフトの後に、ここでも再設計やコードを変更なしで、クラウドでのアプリの実行による多くの利点を得られます。 エンタープライズ開発操作 (DevOps) プロセスが調整され、すばやく出荷するためのアプリケーションの機敏性が向上します。 これを実現するには、Docker エンジンに基づく Windows コンテナーなどのテクノロジを使用します。 コンテナーは、複数の段階的で展開するときに、アプリケーションの依存関係によって引き起こされる摩擦を取り除きます。 コンテナーは、データ、監視、および継続的な統合/継続的な展開 (CI/CD) パイプラインに関連するその他のクラウドで管理されたサービスにも使用します。 +**レベル 2: クラウドの最適化された**アプリケーション: このレベルで、または重要なコードを変更するよう再設計することがなく引き続きクラウド内のコンテナーと同様に、追加の最新テクノロジのアプリを実行してからその他の利点をすることができますクラウドで管理されたサービス。 エンタープライズ開発操作 (DevOps) プロセスが調整され、すばやく出荷するためのアプリケーションの機敏性が向上します。 これを実現するには、Docker エンジンに基づく Windows コンテナーと同様のテクノロジを使用します。 コンテナーは、複数の段階的に展開するときに、アプリケーションの依存関係によって引き起こされる摩擦を削除します。 この成熟度モデルでは IaaS 上のコンテナーを展開することができます。 またはその他の使用中に PaaS サービス、監視、および継続的な統合/継続的なデプロイとして (CI/CD) パイプラインとのキャッシュのクラウドで管理されたサービスが、データベースに関連します。 3 番目の成熟度レベルは、クラウドの最終的な目標ですが、多くのアプリでは省略可能であり、このガイドの主な焦点ではありません。 -**レベル 3: クラウド最適化**: この移行アプローチは、一般的にビジネス ニーズによって推進され、ミッション クリティカルなアプリケーションの刷新を目標とします。 このレベルでは、PaaS サービスを使用してアプリを PaaS コンピューティング インフラストラクチャに移行します。 [クラウド ネイティブ](https://www.gartner.com/doc/3181919/architect-design-cloudnative-applications) アプリケーションおよびマイクロサービス アーキテクチャを実装して長期的な機敏性を持つようにアプリケーションを発展させ、新しい制限にスケールを設定します。 このタイプの最新化は、通常、クラウド用の特別な構築が必要です。 多くの場合、新しいコードを書き込まれなければなりません、特にクラウド ネイティブ アプリケーションとマイクロ サービスに基づくモデルに移動する場合に必要です。 このアプローチは、モノリシックなオンプレミス アプリケーション環境では実現することが困難なメリットを得ることができます。 +**Level 3: クラウド ネイティブ**アプリケーション: 通常この移行方法がビジネス ニーズと、ミッション クリティカルなアプリケーションを刷新ターゲットによって実行ができます。 このレベルでは、PaaS サービスを使用してアプリを PaaS コンピューティング インフラストラクチャに移行します。 [クラウド ネイティブ](https://www.gartner.com/doc/3181919/architect-design-cloudnative-applications) アプリケーションおよびマイクロサービス アーキテクチャを実装して長期的な機敏性を持つようにアプリケーションを発展させ、新しい制限にスケールを設定します。 このタイプの最新化は、通常、クラウド用の特別な構築が必要です。 多くの場合、新しいコードを書き込まれなければなりません、特にクラウド ネイティブ アプリケーションとマイクロ サービスに基づくモデルに移動する場合に必要です。 このアプローチは、モノリシックなオンプレミス アプリケーション環境では実現することが困難なメリットを得ることができます。 表 1-1 は、各移行または最新化アプローチを選択する理由との主な利点を説明しています。 -| **クラウド インフラストラクチャの準備完了**
*リフト アンド シフト* | **クラウド DevOps の準備完了**
*リフト アンド シフト* | **クラウド最適化** *最新化/リファクター/書き換え* | +| **クラウド インフラストラクチャの準備完了**
*リフト アンド シフト* | **クラウドに最適化されました。**
*最新化します。* | **クラウド ネイティブ**
*最新化、再構築およびを書き換える* | |---|---|---| | **アプリケーションの計算対象** | -| Azure の VM にデプロイされたアプリケーション | VM、Azure Service Fabric、または Azure Container Service (つまり Kubernetes) にデプロイされたコンテナー化されたモノリシックまたは N 層アプリケーション | Azure App Service、Azure Service Fabric、または Azure Container Service (つまり Kubernetes) 上の PaaS に基づくコンテナー化されたマイクロサービスまたは通常のアプリケーション | +| Azure の VM にデプロイされたアプリケーション | モノリシックまたはコンテナー、Azure Service Fabric または AKS (Azure Kubernetes サービス) と Azure App Service、Azure コンテナー インスタンス (ACI)、Vm に展開された N 層アプリケーション | Azure Kubernetes サービス (AKS)、Service Fabric Azure 関数に基づいてサーバーなしの microservices にコンテナー化 microservices です。 | | **データの対象** | -| SQL または VM 上の任意のリレーショナル データベース | Azure SQL データベースのマネージ インスタンス | Azure SQL データベース、Azure Cosmos DB、またはその他の NoSQL | +| SQL または VM 上の任意のリレーショナル データベース | Azure SQL データベースのマネージ インスタンスまたはクラウドで管理されている別のデータベースです。 | マイクロ サービス、Azure SQL Database、Azure Cosmos DB、またはクラウド内の別の管理対象データベースに基づくごとの粒度が罰金データベース | | **長所**| -|
  • 再設計や新しいコードがない
  • 最小限の労力による迅速な移行
  • Azure でサポートされる最小公倍数
  • 基本的な可用性の保証
  • クラウドへの移行後にする方が簡単な最新化 |
  • 再設計や新しいコードがない
  • コンテナーは、VM よりも小さな増分の作業を提供する
  • コンテナーに展開とリリースのための DevOps の機敏性の改善
  • 密度の増大と展開コストの削減
  • アプリとの依存関係の移植性
  • Azure Container Service (または Kubernetes) および Azure Service Fabric の使用により高可用性とオーケストレーションを提供
  • Service Fabric でのノード/VM の修正プログラムの適用
  • ホストのターゲットの柔軟性: Azure の仮想マシンまたはバーチャル マシンのスケール設定すると、Azure コンテナー サービス (または Kubernetes)、Service Fabric と将来のコンテナーに基づく選択 |
  • クラウド、リファクター、必要な新しいコードの設計
  • マイクロサービス クラウドネイティブ アプローチ
  • 新しい Web アプリ、モノリシック、N 層、クラウドの回復力、クラウド最適化
  • 完全に管理されたサービス
  • 自動修正プログラム適用
  • スケールに最適化
  • サブシステムによる自律的な機敏性に最適化
  • 展開と DevOps 上の構築
  • スロットや展開戦略などの DevOps の機能強化
  • PaaS とオーケストレーターの対象: Azure App Service、Azure Container Service (または Kubernetes)、Azure Service Fabric、および将来のコンテナー ベースの PaaS | +|
  • よう再設計する、新しいコードはありません。
  • 最小限の労力による迅速な移行
  • Azure でサポートされる最小公倍数
  • 基本的な可用性の保証
  • クラウドへの移行後にする方が簡単な最新化 |
  • ないよう再設計します。
  • 最小限のコードと構成の変更
  • コンテナーに展開とリリースのための DevOps の機敏性の改善
  • 密度の増大と展開コストの削減
  • アプリとの依存関係の移植性
  • ホストのターゲットの柔軟性: PaaS アプローチまたは IaaS |
  • 設計者、クラウドのクラウドから最大のメリットを取得するが、新しいコードが必要
  • マイクロサービス クラウドネイティブ アプローチ
  • クラウドの回復力のある、最新のミッション クリティカルなアプリケーションで拡張性の高いハイパー
  • 完全に管理されたサービス
  • スケールに最適化
  • サブシステムによる自律的な機敏性に最適化
  • 展開と DevOps 上の構築 | | **課題** | -|
  • 運用費のシフトまたはデータセンターの閉鎖以外の小さなクラウドの価値
  • 管理対象がほとんどない: OS またはミドルウェア修正プログラムの適用がない、Terraform、Spinnaker、Puppet などのインフラストラクチャ ソリューション |
  • コンテナー化は学習カーブの追加の手順で不変である必要がある |
  • 重要なコードのリファクタリングまたは書き換えが必要な可能税がある (時間および予算の増加) | +|
  • 運用費のシフトまたはデータセンターの閉鎖以外の小さなクラウドの価値
  • ほとんどは管理: なし、OS またはミドルウェア修正プログラムを適用します。Terraform、Spinnaker、Puppet などのインフラストラクチャ ソリューションの使用可能性があります。 |
  • 開発者と IT 運用の習得期間で、追加の手順は、containerizing
  • DevOps と CI/CD のパイプラインは、'必須' この方法では通常です。 しない場合、現在のカルチャ、組織の存在、かもしれませんが、追加の課題|
  • クラウドのネイティブ アプリやマイクロ サービス アーキテクチャの見直しと通常 重要なコードのリファクタリングまたは書き換え刷新するとき (時間が長くおよび予算) が必要です。
  • DevOps と CI/CD のパイプラインは、'必須' この方法では通常です。 しない場合、現在のカルチャ、組織の存在、かもしれませんが、追加の課題| > **表 1-1** 既存の .NET アプリケーションとサービスの最新化パスのメリットと課題 ### 成熟度レベル別の主要なテクノロジおよびアーキテクチャ @@ -115,15 +114,15 @@ Web アプリケーションを最新化し、クラウドに移動すると決 > **図 1-2** 既存の .NET Web アプリケーションの最新化のための成熟度レベルごとの主要なテクノロジ -図 1-2 では、最も一般的なシナリオが強調表示されていますが、アーキテクチャについては多くハイブリッドと混在のバリエーションが使用可能です。 たとえば、成熟度モデルは、既存の Web アプリのモノリシック アーキテクチャだけでなく、サービス指向、N 層、およびその他のアーキテクチャのスタイルのバリエーションにも適用されます。 +図 1-2 では、最も一般的なシナリオが強調表示されていますが、アーキテクチャについては多くハイブリッドと混在のバリエーションが使用可能です。 たとえば、成熟度モデルは、既存の Web アプリのモノリシック アーキテクチャだけでなく、サービス指向、N 層、およびその他のアーキテクチャのスタイルのバリエーションにも適用されます。 高いフォーカスまたは 1 つまたは別のアーキテクチャの種類と関連技術上の比率は、アプリケーションの全体的な成熟度レベルを決定します。 最新化プロセス内の各成熟度レベルは、次の主要なテクノロジおよびアプローチに関連付けられています。 -- **クラウド インフラストラクチャ準備完了** (再ホストまたは基本的なリフト アンド シフト): 最初のステップとして、多くの組織はクラウド移行戦略を迅速に実行することのみを希望します。 この場合、アプリケーションは単純に再ホストされます。 [Azure Site Recovery](https://azure.microsoft.com/services/site-recovery/)、[Azure Database Migration Service](https://azure.microsoft.com/campaigns/database-migration/) などのクラウドツールを基にした Azure への移行を支援するために必要なガイダンス、洞察、メカニズムを提供するサービスである [Azure Migrate](https://aka.ms/azuremigrate) を使用することで、ほとんどの再ホストは自動化することができます。 レガシ アプリケーションをクラウドに移動するときに、資産についてインフラストラクチャの詳細を確認することができるように、再ホストを手動で変更を設定することもできます。 たとえば、ほとんど変更せずに (おそらく少しの構成変更だけで) Azure の VM にアプリケーションを移動することができます。 特に Azure で仮想ネットワークを作成する場合、このケースでのネットワークは、オンプレミス環境に似ています。 +- **クラウド インフラストラクチャの準備完了**(再ホストまたは basic リフト & シフト): まず、多くの組織のみが必要なクラウド移行戦略を迅速に実行します。 この場合、アプリケーションが再ホストされました。 [Azure Site Recovery](https://azure.microsoft.com/services/site-recovery/)、[Azure Database Migration Service](https://azure.microsoft.com/campaigns/database-migration/) などのクラウドツールを基にした Azure への移行を支援するために必要なガイダンス、洞察、メカニズムを提供するサービスである [Azure Migrate](https://aka.ms/azuremigrate) を使用することで、ほとんどの再ホストは自動化することができます。 レガシ アプリケーションをクラウドに移動するときに、資産についてインフラストラクチャの詳細を確認することができるように、再ホストを手動で変更を設定することもできます。 ほとんどの Azure で Vm にアプリケーションを移行するなど、構成の変更だけで変更の可能性があります。 特に Azure で仮想ネットワークを作成する場合、このケースでのネットワークは、オンプレミス環境に似ています。 -- **クラウド DevOps 準備完了** (改善されたリフト アンド シフト): このモデルでは、アプリケーションの主要なアーキテクチャを変更することなく、クラウドからのいくつかの重要な利点を取得するために、いくつかの重要な展開の最適化を行います。 ここでの基本的な手順は、[Windows コンテナー](https://docs.microsoft.com/virtualization/windowscontainers/about/) サポートを既存の .NET Framework アプリケーションに追加することです。 この重要な手順 (コンテナー化) は、コードを操作しないので、全体的なリフト アンド シフトの作業が非常に少なくなります。 [Image2Docker](https://github.com/docker/communitytools-image2docker-win) や Visual Studio などのツールと、[Docker](https://www.docker.com/) 用のツールを使用できます。 Visual Studio は、ASP.NET アプリケーションおよび Windows コンテナー イメージ用のスマート有効な既定値を自動的に選択します。 これらのツールは、迅速な内側のループと Azure へのコンテナーを取得する高速なパスの両方を提供します。 複数の環境に展開するときの機敏性が向上します。 次に、実稼働環境に移動し、Windows コンテナーを [Azure Service Fabric](https://azure.microsoft.com/services/service-fabric/) または [Azure Container Service](https://azure.microsoft.com/services/container-service/) (Kubernetes、DC/OS、または Swarm) などのオーケストレーターに展開します。 この初期最新化中に、[Azure Application Insights](https://docs.microsoft.com/azure/application-insights/app-insights-overview) などのツールによる監視、[Visual Studio Team Services](https://www.visualstudio.com/team-services/) を使用したアプリ ライフサイクルの CI/CD パイプライン、および Azure で使用可能な多数のデータ リソース サービスなどのクラウドの資産を追加することもできます。 たとえば、従来の [ASP.NET Web Forms](https://www.asp.net/web-forms) や [ASP.NET MVC](https://www.asp.net/mvc) を使用して最初に開発され、しかし現在は Windows コンテナーを使用して展開されるモノリシック Web アプリを変更することができます。 Windows コンテナーを使用するときには、データも [Azure SQL Database マネージ インスタンス](https://docs.microsoft.com/azure/sql-database/)のデータベースに移行する必要があります。アプリケーションの主要なアーキテクチャを変更せずにすべてを移行できます。 +- **クラウドに最適化された**(管理されたサービスと Windows コンテナー): このモデルでは、アプリケーションの主要なアーキテクチャを変更することがなく、クラウドからのいくつかの重要な利点を取得するために、いくつかの重要な展開の最適化を行うについて説明します。 ここでの基本的な手順は、[Windows コンテナー](https://docs.microsoft.com/virtualization/windowscontainers/about/) サポートを既存の .NET Framework アプリケーションに追加することです。 この重要な手順 (コンテナリゼーション) は、リフト アンド シフトの全体的な労力がライトであるため、コードと接触している必要はありません。 [Image2Docker](https://github.com/docker/communitytools-image2docker-win) や Visual Studio などのツールと、[Docker](https://www.docker.com/) 用のツールを使用できます。 Visual Studio は、ASP.NET アプリケーションおよび Windows コンテナー イメージ用のスマート有効な既定値を自動的に選択します。 これらのツールは、迅速な内側のループと Azure へのコンテナーを取得する高速なパスの両方を提供します。 複数の環境に展開するときの機敏性が向上します。 次に、実稼働環境に移動、することができます、Windows コンテナーの展開に[コンテナー用の Azure Web アプリ](https://azure.microsoft.com/en-us/services/app-service/containers/)、[Azure のコンテナー インスタンス (ACI) と Azure Vm で Windows Server 2016 とコンテナー IaaS アプローチしたい場合。 少し複雑なマルチ コンテナー アプリケーションの場合と同様に orchestrators に[Azure Service Fabric](https://azure.microsoft.com/services/service-fabric/)または[Azure Kubernetes Service (AKS/ACS)](https://azure.microsoft.com/en-us/services/container-service/)です。 この初期最新化中に、[Azure Application Insights](https://docs.microsoft.com/azure/application-insights/app-insights-overview) などのツールによる監視、[Visual Studio Team Services](https://www.visualstudio.com/team-services/) を使用したアプリ ライフサイクルの CI/CD パイプライン、および Azure で使用可能な多数のデータ リソース サービスなどのクラウドの資産を追加することもできます。 たとえば、従来の [ASP.NET Web Forms](https://www.asp.net/web-forms) や [ASP.NET MVC](https://www.asp.net/mvc) を使用して最初に開発され、しかし現在は Windows コンテナーを使用して展開されるモノリシック Web アプリを変更することができます。 Windows コンテナーを使用するときには、データも [Azure SQL Database マネージ インスタンス](https://docs.microsoft.com/azure/sql-database/)のデータベースに移行する必要があります。アプリケーションの主要なアーキテクチャを変更せずにすべてを移行できます。 -- **クラウド最適化**: 前に述べたように、クラウドでアプリケーションを最新化するときにの最終的な目標は、[Azure App Service](https://azure.microsoft.com/services/app-service/) のような PaaS プラットフォームをシステムの基盤にすることです。 最新の Web アプリケーションを重視した PaaS プラットフォーム、および[サーバーレス コンピューティング](https://azure.microsoft.com/overview/serverless-computing/)とのようなプラットフォームと [Azure Functions](https://azure.microsoft.com/services/functions/) のようなプラットフォームを基にした新しいサービスでアプリを拡張します。 この成熟度モデルの 2 番目のより高度なシナリオは、マイクロサービス アーキテクチャと[クラウド ネイティブ](https://www.gartner.com/doc/3181919/architect-design-cloudnative-applications)なアプリケーションです。これらは一般的に、[Azure Service Fabric](https://azure.microsoft.com/services/service-fabric/) や [Azure Container Service](https://azure.microsoft.com/services/container-service/) (Kubernetes、DC/OS、Swarm) などのオーケストレーターを使用します。 これらのオーケストレーターは、マイクロサービスとマルチコンテナー アプリケーション向けに特別に作成されています。 これらのすべてのアプローチ (マイクロサービスと PaaS など) は、一般的に、特定の PaaS プラットフォームに適合される新しいコードを作成するか、マイクロサービスなどの特定のアーキテクチャに適合するコードを作成する必要があります。 +- **クラウド ネイティブ**: 導入際に、設計に関する考慮[クラウド ネイティブ](https://www.gartner.com/doc/3181919/architect-design-cloudnative-applications)大規模で複雑なアプリケーションを対象と複数の独立した開発チームで作業しているときに、アプリケーション開発および自律的に展開できるさまざまな microservices します。 マイクロ サービスあたり granularized と独立したスケーラビリティまた、原因です。 これらアーキテクチャの方法は非常に重要な課題と複雑さに直面していますが、PaaS クラウドを使用して、大幅に簡略化および orchestrators like [Azure Kubernetes Service (AKS/ACS)](https://azure.microsoft.com/en-us/services/container-service/) (マネージ Kubernetes)、[Azure サービスファブリックと[Azure 関数](https://azure.microsoft.com/services/functions/)サーバーなしのアプローチです。 これら (microservices およびサーバーなし) と同様の方法はすべて通常必要とすると、クラウドの構築し、新しいコードを記述-特定の PaaS プラットフォームに適用されるコードまたは microservices と同様に、特定のアーキテクチャに合うコード。 図 1-3 は、成熟度レベルごとに使用できる内部のテクノロジを示しています。 @@ -131,7 +130,7 @@ Web アプリケーションを最新化し、クラウドに移動すると決 > **図 1-3** 各最新化成熟度レベルの内部のテクノロジ -## リフト アンド シフトのシナリオ +## リフト アンド シフトのシナリオ リフト アンド シフトの移行では、アプリケーションのシナリオでリフト アンド シフトの多くの異なるバリエーションを使用できることに注意してください。 アプリケーションの再ホストのみを行う場合は、図 1-4 に示すようなシナリオを使用することがあります。この場合、アプリケーションおよびデータベース サーバー用にのみクラウドで VM を使用します。 @@ -139,32 +138,34 @@ Web アプリケーションを最新化し、クラウドに移動すると決 > **図 1-4** クラウドの純粋な IaaS シナリオの例 -さらに進めて、その成熟度レベルからのみの要素を使用する純粋なクラウド DevOps 対応アプリケーションを使用する場合があります。 また、図 1-5 のようにクラウド インフラストラクチャ準備完了からのいくつかの要素、およびクラウド DevOps 準備完了からの他の要素を含む中間的な状態のアプリケーションもあります ("選択" または混在モデル)。 +## 近代化シナリオ + +近代化のシナリオでは、成熟度レベルからのみ要素を使用する純粋なクラウドに向けて最適化されたアプリケーションがあります。 また、クラウド インフラストラクチャの準備完了してからクラウドに向けて最適化されたその他の要素からいくつかの要素で中間状態のアプリケーションもあります (「選択」、または混合モデル)、図 1-5 と同様にします。 ![IaaS 上のデータベース、DevOps、およびコンテナー化資産を含む "選択" シナリオの例](./media/image1-5.png) > **図 1-5** IaaS 上のデータベース、DevOps、およびコンテナー化資産を含む "選択" シナリオの例 -次に、移行を既存の .NET Framework アプリケーションを多くのシナリオとしては理想的処理量が少ないからメリットを取得する、クラウド DevOps 対応アプリケーションを移行することができます。 このアプローチは、将来的に実行可能なステップとしてクラウドの最適化もセットアップします。 図 1-6 に例を示します。 +次に、移行を既存の .NET Framework アプリケーションを多くのシナリオとしては理想的処理量が少ないからメリットを取得する、クラウドに最適化されたアプリケーションを移行することができます。 このアプローチもセットをネイティブでクラウド用に考えられる今後進化として。 図 1-6 に例を示します。 -![Windows コンテナーと管理サービスを使用するクラウド DevOps 準備完了アプリ シナリオの例](./media/image1-6.png) +![Windows コンテナーと管理サービスのサンプル アプリをクラウドに最適化されたシナリオ](./media/image1-6.png) -> **図 1-6** Windows コンテナーと管理サービスを使用するクラウド DevOps 準備完了アプリ シナリオの例 +> **図 1-6** Windows コンテナーと管理サービスのサンプル アプリをクラウドに最適化されたシナリオ -さらに進んで、特定のシナリオ用のいくつかのマイクロサービスを追加することで、既存のクラウド DevOps 準備完了アプリケーションを拡張することができます。 これは、クラウド最適化モデル内で部分的にクラウド ネイティブのレベルに移動しますが、現在のガイダンスの重点ではありません。 +さらに進んで、特定のシナリオのいくつかの microservices を追加することで、既存のクラウドに最適化されたアプリケーションを拡張する可能性があります。 これは、部分的に移動存在ガイダンスの主題ではないネイティブ クラウド モデルのレベル。 ## このガイドに含まれないもの -このガイドでは、図 1-7 に示すように、サンプル シナリオの特定のサブセットについて説明します。 このガイドでは、リフト アンド シフトのシナリオおよび最終的にクラウド DevOps 準備完了モデルにのみ焦点を当てています。 クラウド DevOps 準備完了モデルでは、Windows コンテナーと、監視や CI/CD パイプラインなどの追加のコンポーネントを使用して.NET Framework アプリケーションを最新化します。 各コンポーネントは、クラウドに迅速かつ機敏に展開するための基礎です。 +このガイドでは、図 1-7 に示すように、サンプル シナリオの特定のサブセットについて説明します。 このガイドでは、リフト アンド シフトのシナリオでのみ、最終的に、クラウドに最適化されたモデルに焦点を当てています。 モデルでは、クラウドに最適化された、Windows コンテナーと監視などの追加コンポーネントを使用して、.NET Framework のアプリケーションが最新化され、CI/CD パイプラインします。 各コンポーネントは、クラウドに迅速かつ機敏に展開するための基礎です。 -![クラウド DevOps 準備完了アプリケーションへのリフト アンド シフトおよび初期最新化](./media/image1-7.png) +![クラウド ネイティブは、このガイドで説明されていません。](./media/image1-7.png) -> **図 1-7** クラウド DevOps 準備完了アプリケーションへのリフト アンド シフトおよび初期最新化 +> **図 1-7** クラウド ネイティブは、このガイドで説明されていません。 -このガイドの目的は固有です。 再設計なしでコードを変更しないでをリフト アンド シフト、既存の .NET アプリケーションを実現するためのパスを示します。 最終的には、方法を示しますクラウド DevOps 対応アプリケーションにします。 +このガイドの目的は固有です。 あり/なしよう再設計する、コードを変更しないで、リフト アンド シフト、既存の .NET アプリケーションを実現するためのパスを示します。 最終的には、方法を示します、アプリケーションをクラウドに最適化されました。 -このガイドでは、microservices アーキテクチャに発展させる方法などのクラウド ネイティブ アプリケーションを操作する方法を示します。 アプリケーションを再構築するかマイクロサービスに基づく新しいアプリケーションを作成するには、電子ブック『[.NET Microservices: Architecture for containerized .NET applications](https://aka.ms/microservicesebook)』(.NET マイクロサービス: コンテナー化された .NET アプリケーションのアーキテクチャ) を参照してください。 +このガイドでは、microservices アーキテクチャに発展させる方法などのクラウド ネイティブ アプリケーションを作成する方法を示します。 アプリケーションを再構築または microservices に基づくまったく新しいアプリケーションを作成するには、電子書籍を参照してください。 [.NET Microservices: コンテナーの .NET アプリケーションのアーキテクチャ](https://aka.ms/microservicesebook)です。 ### その他の技術情報 @@ -176,7 +177,7 @@ Web アプリケーションを最新化し、クラウドに移動すると決 ## 対象読者 -このガイドは、開発者および配布し、アプリケーションを解放するの機敏性の向上の .NET Framework に基づく既存の ASP.NET アプリケーションを最新化するソリューション設計者向けに記述されています。 +このガイドは、開発者や既存の ASP.NET web アプリケーションや出荷、アプリケーションを開放することで機敏性の向上の .NET Framework に基づいた WCF サービスを最新化を必要とするソリューション設計者向けに記述されています。 Microsoft Azure を使用するときに Windows コンテナーを使用し、クラウドに展開することによって得られるメリットの概要が知りたいだけのエンタープライズ アーキテクトや開発担当者などの技術的な意思決定者の場合にもこのガイドが役に立つことがあります。 @@ -188,9 +189,9 @@ Microsoft Azure を使用するときに Windows コンテナーを使用し、 ## レガシ アプリケーションの最新化のためのアプリのサンプル: eShopModernizing -GitHub の [EShopModernizing](https://github.com/dotnet-architecture/eShopModernizing) リポジトリは、レガシ モノリシックな Web アプリケーションをシミュレートする 2 つのサンプル アプリケーションを提供します。 1 つ目の Web アプリは ASP.NET MVC を使用して開発され、2 つ目の Web アプリは、ASP.NET Web フォームを使用して開発されています。 両方の Web アプリは、従来の .NET Framework に基づいています。 これらのサンプル アプリでは .NET Core または ASP.NET Core は使用しません。これは、これらが最新化される既存の/レガシ .NET Framework アプリケーションと見なされるためです。 +GitHub の [EShopModernizing](https://github.com/dotnet-architecture/eShopModernizing) リポジトリは、レガシ モノリシックな Web アプリケーションをシミュレートする 2 つのサンプル アプリケーションを提供します。 ASP.NET MVC; を使用して、1 つの web アプリは開発します。ASP.NET Web フォームを使用して、2 番目の web アプリを開発し、3 番目のアプリは、WCF サービスのバックエンドを消費して WinForms クライアント デスクトップ アプリで N 層アプリ。 これらすべてのアプリは、従来の .NET Framework に基づいています。 これらのサンプル アプリでは .NET Core または ASP.NET Core は使用しません。これは、これらが最新化される既存の/レガシ .NET Framework アプリケーションと見なされるためです。 -両方のサンプル アプリで、最新化されたコードを持つ、単純な 2 つ目のバージョンを使用します。 アプリのバージョン間で最も重要な違いは、2 つ目のバージョンでは Windows コンテナーを展開の選択肢として使用することです。 2 つ目のバージョンには、イメージ管理のための Azure Storage Blobs、セキュリティ管理のための Azure Active Directory、アプリケーションの監視と監査のための Azure Application Insights などのいくつかの追加機能もあります。 +これらのサンプル アプリを最新のコードの 2 つ目のバージョンであるか、非常に簡単です。 アプリのバージョン間で最も重要な違いは、2 つ目のバージョンでは Windows コンテナーを展開の選択肢として使用することです。 2 つ目のバージョンには、イメージ管理のための Azure Storage Blobs、セキュリティ管理のための Azure Active Directory、アプリケーションの監視と監査のための Azure Application Insights などのいくつかの追加機能もあります。 ## お客様のフィードバックを送信します。 diff --git a/docs/standard/modernize-with-azure-and-containers/lift-and-shift-existing-apps-azure-iaas.md b/docs/standard/modernize-with-azure-and-containers/lift-and-shift-existing-apps-azure-iaas.md index 8392ab8745a..ff64932f6f8 100644 --- a/docs/standard/modernize-with-azure-and-containers/lift-and-shift-existing-apps-azure-iaas.md +++ b/docs/standard/modernize-with-azure-and-containers/lift-and-shift-existing-apps-azure-iaas.md @@ -1,22 +1,22 @@ --- -title: リフト アンド シフト Azure IaaS の既存のアプリ +title: リフトし、既存の .NET アプリケーションを Azure IaaS (クラウド インフラストラクチャの準備完了) にシフト description: 既存の .NET アプリケーションと Azure のクラウドと Windows コンテナーを開放します。 author: CESARDELATORRE ms.author: wiwagn -ms.date: 10/26/2017 -ms.openlocfilehash: b844373d4ea995b553d9a32ea51997fd664064bd -ms.sourcegitcommit: 3d5d33f384eeba41b2dff79d096f47ccc8d8f03d +ms.date: 04/28/2018 +ms.openlocfilehash: 458b1bd1fc9fc24ce43d0926655fe0767aabc43c +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 ms.translationtype: MT ms.contentlocale: ja-JP -ms.lasthandoff: 05/04/2018 +ms.lasthandoff: 05/10/2018 --- -# リフト アンド シフト Azure IaaS の既存のアプリ +# リフトし、既存の .NET アプリケーションを Azure IaaS (クラウド インフラストラクチャの準備完了) にシフト > ビジョン: 最初の手順としてをハードウェアの内部設置型への投資と総コストを削減し、クラウド内の既存のアプリケーションを再ホスト ネットワークのメンテナンス、単純にします。 入る前に*方法*Azure infrastructure as a service (IaaS) プラットフォームを既存のアプリケーションを移行することが理由を分析する重要*理由*IaaS に直接移行します。azure です。 この近代化成熟度レベルのシナリオでは引き続き、現在、内部設置型インフラストラクチャを使用してではなく、クラウド内の Vm の使用を開始を本質的にします。 -分析に別のポイントが*理由*詳細設定で、Azure 管理サービスを追加するだけではなく純粋な IaaS クラウドへ移行する場合があります。 場合がありますかを調べる必要 IaaS を最初の場所が必要です。 +分析に別のポイントが*理由*詳細設定で、Azure 管理サービスを追加するだけではなく純粋な IaaS クラウドへ移行する場合があります。 確認の場合があります最初の場所に IaaS を必要とします。 図 2-1 では、クラウド インフラストラクチャの準備完了のアプリケーションを配置近代化成熟度レベルで。 @@ -30,17 +30,17 @@ ms.lasthandoff: 05/04/2018 アプリをクラウドに移動する意思決定を行うと、選択する理由が IaaS PaaS は単純にするようより高度なオプションではなく、IaaS 環境主な理由は、他の一般的なになります。 現在次のような環境への移動、オンプレミス環境には、低い習得、これにより、クラウドが最速のパスを提供します。 -ただし、クラウドに移行する最も簡単な方法を選ぶわけでは、アプリケーション、クラウドで実行する必要がなくなりますほとんどの利益を得ることがあります。 任意の組織には、既に導入クラウド DevOps 対応および PaaS (クラウドに最適化された) の成熟度レベルでのクラウド移行から最も重要な利点が獲得できません。 +ただし、クラウドに移行する最も簡単な方法を選ぶわけでは、アプリケーション、クラウドで実行する必要がなくなりますほとんどの利益を得ることがあります。 任意の組織には、既に導入された、クラウドに最適化されたとクラウド ネイティブの成熟度レベルでのクラウド移行から最も重要な利点が獲得できません。 -これもが明らかになりますアプリケーションが簡単に最新化および再 IaaS 上であっても、クラウドで既に実行されている場合、今後設計います。 部分的にアプリケーション データの移行が実現されて既にため true です。 また、組織が、クラウドでの作業に必要なスキルを獲得しようし、shift キーを押し"クラウド culture"で動作しています。 +これもが明らかになりますアプリケーションは改革し、IaaS 上であっても、クラウドで既に実行されている場合、後で再構築しやすくします。 アプリケーション データの移行は既に実現されています。 また、組織が、クラウドでの作業に必要なスキルを獲得しようし、shift キーを押し"クラウド culture"で動作しています。 ## 代わりに PaaS に IaaS に移行するときに -次のセクションでは、クラウド DevOps 対応は、ほとんどの場合に基づくアプリケーションの PaaS プラットフォームおよびサービスについて説明します。 これらのアプリによって、クラウドへの移行からほとんどの利点がわかります。 +次のセクションでは、クラウドに最適化されたは、ほとんどの場合に基づくアプリケーションの PaaS プラットフォームおよびサービスについて説明します。 これらのアプリによって、クラウドへの移行からほとんどの利点がわかります。 -目標は、既存のアプリケーションをクラウドに移動することだけが場合、は、最初に、Azure App Service で実行するに大幅な変更が必要になる既存のアプリケーションを特定します。 これらのアプリは、最初の候補にする必要があります。 +目標は、既存のアプリケーションをクラウドに移動することだけが場合、は、最初に、Azure App Service で実行するに大幅な変更を必要とせず、既存のアプリケーションを特定します。 これらのアプリでの最初の候補をする必要がありますクラウドに向けて最適化されました。 -次に、したくないまたは Azure Service Fabric など Kubernetes orchestrators やと Windows コンテナーに移動できません、まだ、しではプレーンな Vm (IaaS) を使用する場合。 +次に、アプリを引き続きに移動できません Windows コンテナーと PaaS App Service または Azure Service Fabric のような orchestrators を移行できる単純なプレーンな vm (IaaS) など。 しかし、正しく構成、セキュリティ保護、および Vm の維持が必要である多くの時間と azure PaaS サービスを使用する場合に比べて IT 専門知識に注意してください。 Azure の仮想マシンを検討している場合は、更新プログラム、更新、および VM 環境の管理に必要な継続的な保守作業を考慮するを確認します。 Azure の仮想マシンは、IaaS です。 @@ -54,7 +54,7 @@ ms.lasthandoff: 05/04/2018 - 多階層アプリケーションの信頼性の高い検出用の組み込みの依存関係のマッピング -- Azure の仮想マシンをインテリジェント適正 +- Azure の仮想マシンをインテリジェント右側のサイズ変更 - 潜在的な問題を修復するためのガイドラインとレポートの互換性 diff --git a/docs/standard/modernize-with-azure-and-containers/migrate-your-relational-databases-to-azure.md b/docs/standard/modernize-with-azure-and-containers/migrate-your-relational-databases-to-azure.md index ba1231c10b0..a79db1f77d7 100644 --- a/docs/standard/modernize-with-azure-and-containers/migrate-your-relational-databases-to-azure.md +++ b/docs/standard/modernize-with-azure-and-containers/migrate-your-relational-databases-to-azure.md @@ -3,12 +3,12 @@ title: リレーショナル データベースを azure に移行します。 description: Azure のクラウドと Windows コンテナーの既存の .NET アプリケーションを最新化 |リレーショナル データベースを azure に移行します。 author: CESARDELATORRE ms.author: wiwagn -ms.date: 10/26/2017 -ms.openlocfilehash: efc558115d184ed53a963eab2acdd847a12dbb3c -ms.sourcegitcommit: 3d5d33f384eeba41b2dff79d096f47ccc8d8f03d +ms.date: 04/28/2018 +ms.openlocfilehash: fe1bf5820c2306beb380749b34d5a56964e016e4 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 ms.translationtype: MT ms.contentlocale: ja-JP -ms.lasthandoff: 05/04/2018 +ms.lasthandoff: 05/10/2018 --- # リレーショナル データベースを azure に移行します。 @@ -26,7 +26,7 @@ Azure では、(純粋なリフト アンド シフト) の IaaS Vm に直接、 Azure SQL データベースのマネージ インスタンスは、SQL Server インスタンス レベルの機能の追加要件または標準の Azure SQL データベース (1 つのデータベース モデル) で提供される機能以外の分離の要件がある場合に最適なオプションです。 この最後の 1 つは、最も PaaS 指向の選択は、従来の SQL server のと同じ機能を提供していません。 移行では、frictions を表面化可能性があります。 -たとえば、インスタンス レベルの SQL Server 機能の詳細な投資を行ってきましたする組織は恩恵をマネージ インスタンスの SQL への移行します。 例としてインスタンス レベルの SQL Server 機能の SQL 共通言語ランタイム (CLR) 統合、SQL Server エージェントやデータベースにまたがるクエリを実行します。 これらの機能のサポートは、標準の Azure SQL データベース (単一データベース モデル) でご利用いただけません。 +たとえば、インスタンス レベルの SQL Server 機能の詳細な投資を行ってきましたする組織は恩恵をマネージ インスタンスの SQL への移行します。 例としてインスタンス レベルの SQL Server 機能の SQL 共通言語ランタイム (CLR) 統合、SQL Server エージェントやデータベースにまたがるクエリを実行します。 これらの機能のサポートでは、標準の Azure SQL データベース (単一データベース モデル) で使用できません。 厳しくの業界で動作して、セキュリティのための分離を維持する必要がある組織もメリットがあるマネージ インスタンスの SQL モデルを選択します。 @@ -56,9 +56,9 @@ Azure SQL データベースでのマネージ インスタンスには、次の 前述のように、標準の Azure SQL Database は、完全に管理されたリレーショナル DBaaS がします。 現在、SQL データベースは、世界中の 38 データ センター間で何百万もの実稼働データベースを管理します。 これは、さまざまなアプリケーションや世界規模での高度なデータ処理を必要とするデータが集中する、ミッション クリティカルなアプリケーションにするために、簡単なトランザクション データの管理からのワークロードをサポートします。 -その完全 PaaS 機能によるものであり、効率的料金の最終的なコストの削減と -に移行する標準の Azure SQL Database、「既定の選択肢」としてそのは basic、standard SQL データベース、および追加のインスタンスの機能がないアプリケーションがある場合。 SQL CLR 統合、SQL Server エージェント、およびデータベースにまたがるクエリを実行するように SQL Server の機能は標準の Azure SQL データベースではサポートされていません。 これらの機能が、Azure SQL データベースのマネージ インスタンス モデルでのみ使用できます。 +その完全 PaaS 機能のための価格よりの最終的なコストの削減と -に移行する標準の Azure SQL Database、「既定の選択肢」としてそのは basic、standard SQL データベース、および追加のインスタンスの機能がないアプリケーションがある場合。 SQL CLR 統合、SQL Server エージェント、およびデータベースにまたがるクエリを実行するように SQL Server の機能は標準の Azure SQL データベースではサポートされていません。 これらの機能が、Azure SQL データベースのマネージ インスタンス モデルでのみ使用できます。 -Azure SQL データベースは、アプリの開発者に組み込まれているのみインテリジェント クラウド データベース サービスです。 場で、マルチ テナント アプリケーションを効率的に配信するため、ダウンタイムなしのスケールを設定するだけのクラウド データベース サービスです。 最終的には、Azure SQL データベース状態のままに導入するより多くの時間とに要する時間、高速化します。 セキュリティで保護されたアプリケーションをビルドし、言語と使用するプラットフォームを使用して、SQL データベースに接続できます。 +Azure SQL データベースは、アプリの開発者に組み込まれているのみインテリジェント クラウド データベース サービスです。 場で、マルチ テナント アプリケーションを効率的に配信するため、ダウンタイムなしのスケールを設定するだけのクラウド データベース サービスです。 最終的には、Azure SQL データベース状態のままに導入するより多くの時間とに要する時間、高速化します。 セキュリティで保護されたアプリをビルドし、言語と使用するプラットフォームを使用して、SQL データベースに接続できます。 Azure SQL Database には次の利点があります。 @@ -76,13 +76,13 @@ Azure SQL Database には次の利点があります。 - ハイブリッドおよび移行を含む、SQL Server 2016 との互換性 -標準の Azure SQL データベースでは、Azure SQL データベースのマネージ インスタンスよりは、PaaS に近づきます。 マネージ クラウドから複数のメリットになるため、使用可能な場合に試してください。 しかし、Azure SQL データベースは正規の主な相違点あり、内部設置型 SQL Server インスタンス。 、、、既存のアプリケーションのデータベースの要件、および企業の要件とポリシーに応じて、できない可能性があります最善の選択、クラウドへの移行を計画するときにします。 +標準の Azure SQL データベースでは、Azure SQL データベースのマネージ インスタンスよりは、PaaS に近づきます。 管理対象のクラウドから多くのメリットになるために、標準の Azure SQL データベースを選びます。 しかし、Azure SQL データベースは正規の主な相違点あり、内部設置型 SQL Server インスタンス。 、、、既存のアプリケーションのデータベースの要件、および企業の要件とポリシーに応じて、できない可能性があります最善の選択、クラウドへの移行を計画するときにします。 ## 場合に、元の RDBMS を VM (IaaS) に移動するには 移行オプションの 1 つは、元のリレーショナル データベース管理システム (RDBMS)、Oracle、IBM DB2、MySQL、PostgreSQL、または SQL Server を含む Azure VM で実行されているようなサーバーを移動します。 最小限の変更、またはまったく変更せずにクラウドへの移行を最も高速をまったく必要とする既存のアプリケーションがある場合は、IaaS クラウドへの移行を直接が正当なオプションにあります。 クラウドのすべての利点を活用する最善の方法ができない可能性がありますが、最も高速な初期パスである可能性があります。 -現在、Microsoft Azure サポートされている最大[331 の別のデータベース サーバー](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/category/databases?page=1&subcategories=databases-all) IaaS Vm としてデプロイします。 SQL Server、Oracle、MySQL、PostgreSQL、および IBM DB2 の場合のような一般的な Rdbms および Cloudera したり MariaDB、DataStax、MongoDB、Cassandra などその他の多くの NoSQL データベースが含まれます。 +現在、Microsoft Azure サポートされている最大[331 の別のデータベース サーバー](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/category/databases?page=1&subcategories=databases-all) IaaS Vm としてデプロイします。 これらには、SQL Server、Oracle、MySQL、PostgreSQL、および IBM DB2 の場合のような一般的な RDBMS および Cloudera したり MariaDB、DataStax、MongoDB、Cassandra などその他の多くの NoSQL データベースが含まれます。 > [!NOTE] > 移動するは、Azure VM に、RDBMS 可能性があります (であるため IaaS) クラウドにデータを移行する最も簡単な方法は、この方法には、IT チーム (データベース管理者および IT 担当者向け) で多大な投資が必要があります。 企業内のチームを設定して高可用性、災害復旧、および SQL Server の修正プログラムの適用を管理できるようにする必要があります。 このコンテキストでは、カスタマイズされた環境に、完全な管理者権限も必要です。 @@ -127,4 +127,4 @@ Azure データベースの移行サービスを使用してデータベース >[!div class="step-by-step"] [前へ](lift-and-shift-existing-apps-azure-iaas.md) -[次へ](lift-and-shift-existing-apps-devops/index.md) \ No newline at end of file +[次へ](modernize-existing-apps-to-cloud-optimized/index.md) \ No newline at end of file diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/build-resilient-services-ready-for-the-cloud-embrace-transient-failures-in-the-cloud.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/build-resilient-services-ready-for-the-cloud-embrace-transient-failures-in-the-cloud.md new file mode 100644 index 00000000000..b5e6c63546f --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/build-resilient-services-ready-for-the-cloud-embrace-transient-failures-in-the-cloud.md @@ -0,0 +1,63 @@ +--- +title: 回復力のあるサービス、クラウドの準備ができてをビルドします。 クラウド内の一時的な障害を受け入れる +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |回復力のあるサービス、クラウドの準備ができてをビルドします。 クラウド内の一時的な障害を受け入れる +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/30/2018 +ms.openlocfilehash: 1df21d0f647b96c315686921276be3526f66bbc8 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# クラウドの準備が整って回復力のあるサービスを構築しますクラウド内の一時的な障害を受け入れる。 + +回復性は、障害から回復し、引き続き機能する能力です。 回復性エラーを回避するが、エラーが発生するという事実を受信し、ダウンタイムやデータの損失を回避するように後で対応するのではありません。 回復性の目的は、障害発生後にアプリケーションを完全に機能する状態に戻すことです。 + +アプリケーションには、少なくともは、ハードウェア ベースのモデルではなく、回復性のソフトウェア ベースのモデルに実装すると、クラウドの準備ができてです。 クラウド アプリケーションには、確実に発生する部分的な障害を採用する必要があります。 デザインまたは部分的に予想される部分的な障害回復性を実現するために、アプリケーションをリファクターします。 これは、一時的なネットワークの停止とノード、または Vm クラウドでクラッシュしたのと同様に、部分的な障害に対処を設計する必要があります。 Orchestrator クラスター内の別のノードに移動するものコンテナーには、アプリケーション内での断続的な短いエラー可能性があります。 + +## 部分的なエラーの処理 + +クラウド ベースのアプリケーションでは、一部の障害のリスクがないです。 たとえば、1 つの web サイト インスタンスまたはコンテナーが失敗すると、または使用できなくなったり、短い時間があります。 または、1 つの VM またはサーバーがクラッシュする可能性があります。 + +クライアントとサービスは別のプロセスであるためサービスできないことがあります、クライアントの要求に適切なタイミングで応答します。 サービス可能性オーバー ロードがあり、要求に応答が遅くなるまたはにアクセスできない可能性が短時間ネットワークの問題があるためです。 + +たとえば、Azure SQL データベースでデータベースにアクセスするモノリシックな .NET アプリケーションがあるとします。 Azure SQL データベースやその他のサード パーティのサービスは、簡単な場合に、応答がない場合 (Azure SQL データベースは、別のノードやサーバーに移動される可能性し、数秒応答していない) に、ユーザーは、操作を行う際に、アプリケーションがクラッシュする可能性がありますと表示w 同時例外。 + +同様のシナリオは、HTTP サービスを使用するアプリで発生する可能性があります。 ネットワークまたはサービス自体できない可能性があります、クラウドで短い、一時的なエラーの際にします。 + +図 4-9 に示すような回復力のあるアプリケーションでは、アプリケーション リソースの一時的なエラーを処理する機会を提供する「指数バックオフによる再試行」のような技法を実装する必要があります。 また、「ブレーカー」をアプリケーションで使用することも必要があります。 遮断器は、実際には長期的な障害があるときにリソースにアクセスしようとしてからアプリケーションを停止します。 遮断器を使用すると、アプリケーションでは、それ自体にサービス拒否攻撃に富んだで回避できます。 + +![指数バックオフによる再試行によって処理される部分的な障害](./media/image9.png) + +> **図 4-9 です。** 指数バックオフによる再試行によって処理される部分的な障害 + +HTTP リソースとデータベース リソースの両方には、これらの手法を使用することができます。 図 4-9 では、アプリケーションに基づきます 3 層アーキテクチャでは、これらの手法は、サービス レベル (HTTP) と、データ層のレベル (TCP) 必要があります。 (その他のサービスまたは microservices) は、データベース以外の単一のアプリケーション層のみを使用しているモノリシックなアプリケーション、データベース レベルの接続の一時的なエラー処理があるのに十分な。 このシナリオでは、特定のデータベース接続の構成のみが必要です。 + +を使用している .NET のバージョンによっては、データベースにアクセスする回復力のある通信を実装するときに簡単なできます (たとえば、 [Entity Framework 6 以降](https://msdn.microsoft.com/library/dn456835(v=vs.113).aspx)、構成するだけで済みますが、データベース接続の場合)。 またはのような追加のライブラリを使用する必要があります、 [Transient Fault Handling Application Block](https://msdn.microsoft.com/library/hh680934(v=pandp.50).aspx) (以前のバージョンの .NET)、またはでも独自のライブラリを実装します。 + +使用する、.NET の推奨事項は、HTTP 再試行の回数とブレーカーを実装する場合、[ポリー](https://github.com/App-vNext/Polly)ライブラリで、.NET Framework 4.0、.NET Framework 4.5 と .NET Core のサポートが含まれる .NET 標準 1.1 を対象とします。 + +クラウドでの部分的な障害を処理するための戦略を実装する方法については、次の参照を参照してください。 + +### その他の技術情報 + +- **部分的な障害に対処する回復力のある通信を実装します。** + + [https://docs.microsoft.com/dotnet/standard/microservices-architecture/implement-resilient-applications/partial-failure-strategies](../../microservices-architecture/implement-resilient-applications/partial-failure-strategies.md) + +- **Entity Framework 接続回復性と再試行ロジック (バージョン 6 以降)** + + [https://msdn.microsoft.com/library/dn456835(v=vs.113).aspx](https://msdn.microsoft.com/library/dn456835(v=vs.113).aspx) + +- **Transient Fault Handling Application Block** + +- [https://msdn.microsoft.com/library/hh680934(v=pandp.50).aspx](https://msdn.microsoft.com/library/hh680934(v=pandp.50).aspx) + +- **回復力のある HTTP 通信のポリー ライブラリ** + + https://github.com/App-vNext/Polly + +>[!div class="step-by-step"] +[前へ](when-to-deploy-windows-containers-to-azure-container-service-kubernetes.md) +[次へ](modernize-your-apps-with-monitoring-and-telemetry.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/choosing-azure-compute-options-for-container-based-applications.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/choosing-azure-compute-options-for-container-based-applications.md new file mode 100644 index 00000000000..20889a16951 --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/choosing-azure-compute-options-for-container-based-applications.md @@ -0,0 +1,41 @@ +--- +title: コンテナー ベース アプリケーション用の Azure のコンピューティング プラットフォームを選択します。 +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |コンテナー ベース アプリケーション用の Azure のコンピューティング プラットフォームを選択します。 +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 05/04/2018 +ms.openlocfilehash: ebf022a52aaaf95ae335976f5e097921b0ac8006 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# コンテナー ベース アプリケーション用の Azure のコンピューティング プラットフォームを選択します。 + +お気付きに前のセクションを読んだ後、Azure は複数の選択肢を提供する、開いているクラウドです。 ニーズに最適値を使用するもには、コンテナー化アプリケーションを使用する製品/テクノロジに関する質問を明らかにただし、します。 + +として、*既定*このガイドで推奨されている主な条件、推奨事項を次に示します。 + + - **1 つのモノリシック アプリ:** Azure App Service の選択 + - **N 層アプリケーション:** orchestrators Azure Kubernetes サービス (AKS)、Service Fabric (SF) またはアプリ サービスなどを選択して、1 つまたはいくつかのバックエンド サービスがある場合 + - **Linux microservices:** AKS/Kubernetes の選択 + - **Windows microservices:** Service Fabric の選択 + - **サーバーなしの関数とイベント ハンドラー:** Azure 関数の選択 + - **大規模なバッチ:** Azure Batch の選択 + +ただし、製品の選択は、特定のアプリケーションのニーズと特性に依存するの salt、ピンチ操作でこの推奨事項を実行してください。 すべてのアプリケーションは、最初に類似した種類を検索する場合があるときでも同じです。 + +アプリケーションのニーズの詳細な分析の後は、選択されている製品が異なる可能性があります。 開始点としてお勧めして、初期のガイダンスの評価を開始することができ、特定の優先順位に基づくテストします。 + +次の図に、詳細な意思決定テーブル中にグローバルよりを分析できます。 + +![](./media/image8.5.png) + +通知方法 (Windows と OS の基になります。Linux) では、いくつか orchestrators が成熟 Linux コンテナーと Windows コンテナーの その他、決定要因こともできます。 たとえば、Linux コンテナーは、小さい Service Fabric で完成度の高い、非常に成熟 Kubernetes (Azure で AKS) です。 その一方で、Windows コンテナーは、(2017 年 1 月リリース) Service Fabric で完成度の高い小さい AKS で完成度の高い。 + +ただし、成熟度の OS でそれらの相違点は自動的に後で複数のプラットフォームは比較可能な OS 成熟度および意思決定が、アプリケーションが必要になるまたは各プラットフォームのエコシステムに基づく特定の機能に基づいた環境設定でさらにレイアウト理由があります。 + + +>[!div class="step-by-step"] +[前へ](when-to-deploy-windows-containers-to-azure-container-service-kubernetes.md) +[次へ](build-resilient-services-ready-for-the-cloud-embrace-transient-failures-in-the-cloud.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/deploy-existing-net-apps-as-windows-containers.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/deploy-existing-net-apps-as-windows-containers.md new file mode 100644 index 00000000000..53e126418c0 --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/deploy-existing-net-apps-as-windows-containers.md @@ -0,0 +1,170 @@ +--- +title: Windows コンテナーとして既存の .NET アプリを展開します。 +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |Windows コンテナーとして既存の .NET アプリを展開します。 +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/29/2018 +ms.openlocfilehash: 829f33aba14d79d7d9003d1ac7472a19060d401a +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# Windows コンテナーとして既存の .NET アプリを展開します。 + +Windows コンテナーに基づいた展開は、クラウドに最適化されたアプリケーションやクラウド ネイティブ アプリケーションに適用されます。 + +ただし、このガイドで、次のセクションでは、特にでほとんどの場合に焦点を Windows コンテナーを使用して*クラウドに向けて最適化された*アプリケーションを再構築する必要のないアプリケーションです。 + +## コンテナーとは? (Linux または Windows) + +コンテナーは、分離された独自のパッケージにアプリケーションをラップする方法です。 アプリケーションは、そのコンテナーに、コンテナーの外部に存在するアプリケーションまたはプロセスによって影響はありません。 すべてのアプリケーションに依存実行が正常に、プロセスが、コンテナー内にあるとします。 任意の場所のコンテナーが移動する可能性があります、アプリケーションの要件が常に満たされる直接的な依存関係の観点から (ライブラリの依存関係、ランタイム、およびなど) を実行する必要があるすべてのものが、バンドルされているためです。 + +コンテナーの主な特性をしやすくなる環境同じ別の展開全体でため、コンテナー自体が付属して必要なすべての依存関係です。 コンピューターにアプリケーションをデバッグし、別のコンピューターに保証される同じ環境に展開できます。 + +コンテナーは、コンテナー イメージのインスタンスです。 コンテナー イメージは、アプリや (snapshot) などのサービスをパッケージ化し、信頼性が高く、再現可能な方法で展開する方法です。 Docker ではないことのみ、テクノロジのも理念およびプロセスとする可能性があります。 + +業界全体「の配置単位です」になっているコンテナーが毎日より一般的になると、 + +## コンテナー (Linux または Windows 上の Docker エンジン) の利点 + +コンテナーのどちらを使用してアプリケーションを構築する可能性がありますもとして定義されている軽量のビルド ブロックは大幅に増加アジリティ構築、配布、および、インフラストラクチャ全体にわたって、すべてのアプリケーションを実行しているのためです。 + +コンテナーでは、すべてのアプリの開発から運用環境にほとんどまたはまったくないコード変更により、Microsoft 開発者ツール、オペレーティング システムとクラウド間の Docker 統合感謝を実行できます。 + +普通の Vm を展開するときに既に ASP.NET アプリケーションの Vm を展開するためにメソッドがあります。 ただし、メソッドに含まれている複数の手動手順や複雑な自動プロセス、Puppet などの展開ツールまたは同様のツールを使用して、可能性があります。 構成項目の変更、サーバー間でのアプリケーションのコンテンツをコピーおよびテスト後に、.msi 設定に基づいて対話形式のセットアップ プログラムを実行するようにタスクを実行する必要があります。 展開内のこれらのすべての手順は、展開する時間およびリスクを追加します。 依存関係が、ターゲット環境に存在しないときにエラーが表示されます。 + +Windows コンテナーでアプリケーションのパッケージ化のプロセスが完全に自動化されます。 Windows コンテナーは、自動更新、およびコンテナーの展開のロールバックを提供する Docker プラットフォームに基づいています。 Docker エンジンを使用してから取得するメインの向上は、すべての依存関係と、アプリケーションのスナップショットは、イメージを作成することです。 イメージは、Docker イメージ (Windows コンテナー イメージ、ここでは) です。 イメージは、ソース コードに戻されることがなく、コンテナーでは、ASP.NET アプリを実行します。 コンテナーのスナップショットでは、配置の単位になります。 + +多くの組織では、次の理由でモノリシックな既存のアプリケーションを containerizing は。 + +- **クラウドに改善された展開をリリース**です。 コンテナーは、開発と運用の間で一貫性のある展開のコントラクトを提供します。 コンテナーを使用するときと開発者が聞こえません () で"、私のコンピューターでは、しないのはなぜ実稼働環境でですか?" 言った、"、"として実行されます、コンテナー、実稼働環境で実行するためです。 およびすべての依存関係のパッケージ化されたアプリケーションは、サポートされているコンテナー ベース環境で実行できます。 すべての配置対象 (dev、QA、ステージング、実稼働) で実行する意図された方法で実行されます。 1 つの段階から次に、展開を大幅に向上させるに移動する、コンテナーがほとんど frictions を排除し、高速化を出荷することができます。 + +- **コスト削減**です。 コンテナーは、統合と既存のハードウェア、またはハードウェアの単位あたり高密度でアプリケーションを実行してから削除するか、コスト削減につながります。 + +- **移植性**です。 コンテナーは、モジュール形式およびポータブルです。 Docker コンテナーは、任意のサーバー オペレーティング システム (Linux と Windows) のメジャーのパブリック クラウド (Microsoft Azure、Amazon AWS、Google、IBM) は、オンプレミスおよびプライベートまたはハイブリッド クラウド環境でサポートされます。 + +- **コントロール**です。 コンテナーは、コンテナー レベルで制御される柔軟かつセキュリティで保護された環境を提供します。 コンテナーのセキュリティで保護された、分離、およびコンテナーの実行ポリシーの制約を設定しても制限されます。 Windows コンテナーに関するセクションで詳細なとしては、Windows Server 2016 と HYPER-V コンテナーは、その他のエンタープライズ サポート オプションを提供します。 + +アジリティ、移植性、およびコントロールでの大きな改善点最終的に発生するコストを大幅に削減開発およびアプリケーションを管理するコンテナーを使用する場合。 + +## Docker について + +[Docker](https://www.docker.com/)は、[オープン ソース プロジェクト](https://github.com/docker/docker)クラウドまたは内部設置型で実行でき、移植可能で自分のコンテナーとしてのアプリケーションの展開を自動化します。 Docker は、このテクノロジを促進および進化させる[会社](https://www.docker.com/)でもあります。 会社は、クラウド、Linux、およびなどの Microsoft Windows ベンダーと共同で動作します。 + +![](./media/image6.png) + +> **図 4 ~ 6 です。** Docker は、ハイブリッド クラウドのすべてのレイヤーでコンテナーを展開します。 + +他の人に、仮想マシンを使い慣れてコンテナーする可能性がありますよく似ています。 コンテナーは、オペレーティング システムを実行、なファイル システムおよび物理または仮想コンピューターのシステムと同じように、ネットワーク経由でアクセスできます。 ただし、テクノロジ、およびコンテナーの背後にある概念は、仮想マシンから大幅に異なるです。 開発者の観点からコンテナー扱う必要があるより 1 つのプロセスと同様にします。 実際には、コンテナーは、1 つのプロセスの 1 つのエントリ ポイントがします。 + +Docker コンテナー (わかりやすくするため、*コンテナー*) Linux と Windows 上でネイティブに実行できます。 Windows コンテナーを Windows ホスト (ホスト サーバーまたは VM) でのみ実行できます正規のコンテナーを実行する場合と、Linux コンテナーは、Linux ホストでのみ実行できます。 ただし、最近のバージョンの Windows Server と HYPER-V コンテナーでは、Linux コンテナーも実行できますネイティブ Windows Server では現在、Windows Server コンテナーでのみ使用する HYPER-V の分離テクノロジを使用しています。 + +近い将来、Linux と Windows の両方のコンテナーが存在する混在環境には、可能であり、一般的なでもがなります。 + +## 既存の .NET アプリケーションの Windows コンテナーの利点 + +Windows コンテナーを使用する利点は基本的には同様の利点が一般にコンテナーから取得します。 Windows コンテナーを使用するには、アジリティ、移植性、および制御が大幅に向上に関するです。 + +既存の .NET アプリケーションでは、.NET Framework を使用して作成されたこれらのアプリケーションを参照してください。 たとえば、従来の ASP.NET web アプリケーションがあります-新しいしてプラットフォーム間を実行する .NET Core を使用していない Linux、Windows、および MacOS にします。 + +.NET Framework の主要な依存関係は、Windows です。 従来の ASP.NET では、IIS、および System.Web のように、セカンダリの依存関係もあります。 + +.NET Framework アプリケーションを Windows では、期間実行する必要があります。 既存の .NET Framework アプリケーションを containerize するかどうかとできないか、.NET Core への移行に投資する必要のない唯一の選択肢でのコンテナーがある場合は、Windows コンテナーを使用する ("場合は正常に動作しないこと") を移行します。 + +したがって、Windows コンテナーの主な利点の 1 つを発揮するコンテナリゼーション Windows 経由で実行されている既存の .NET Framework アプリケーションを最新化する方法です。 最終的には、Windows コンテナーを取得するコンテナー アジリティ、移植性、および制御を強化を使用して、探している利点です。 + +## ターゲットに OS を選択します。NET ベースのコンテナー + +.NET Framework と .NET Core の違いと同様に Docker、によってサポートされているオペレーティング システムの多様性を指定するには、特定の OS とを使用しているフレームワークに基づいて特定のバージョンをターゲットする必要があります。 + +Windows の場合、Windows Server Core または Windows Nano Server を使用できます。 これらのバージョンの Windows には、.NET Framework または .NET Core アプリケーションによって必要になる可能性があります (Kestrel と同様に、自己ホスト型の web サーバーと IIS) などの別の特性が実現します。 + +Linux の場合、複数のディストリビューションを利用できます。また、Linux は公式の .NET Docker イメージ (Debian など) でサポートされています。 + +図 4-7 は、.NET Framework のアプリのバージョンによっては、対象できます OS バージョンを示しています。 + +![](./media/image7.png) + +> **図 4 ~ 7 です。** .NET Framework のバージョンに基づき、ターゲットのオペレーティング システム + +.NET Framework アプリケーションに基づく既存または従来のアプリケーションの移行のシナリオでは、メインの依存関係が、Windows と IIS でします。 唯一のオプションでは、Windows Server Core と .NET Framework に基づいた Docker イメージを使用します。 + +Dockerfile は、ファイルをイメージ名を追加する場合は、.NET Framework ベースの Windows コンテナー イメージの次の例のように、タグを使用して、オペレーティング システムとバージョンを選択できます。 + +> | **タグ** | **システムとバージョン** | +> |---|---| +> | **microsoft/dotnet-framework:4.x-windowsservercore** | .NET framework 4.x を Windows Server Core | +> | **microsoft/aspnet:4.x-windowsservercore** | .NET framework 4.x で Windows Server Core での他の ASP.NET カスタマイズ | + +.NET core (Linux と Windows はクロス プラットフォーム)、タグは、次のようになります。 + +> | **タグ** | **システムとバージョン** +> |---|---| +> | **microsoft/dotnet:2.0.0-runtime** | .NET core 2.0 Linux 上のランタイムのみ | +> | **microsoft/dotnet:2.0.0-runtime-nanoserver** | .NET core 2.0 Windows Nano Server でのランタイムのみ | + +### マルチ arch イメージ + +2017 中旬以降、使うこともできます、新しい機能と呼ばれる Docker で[マルチ arch](https://github.com/moby/moby/issues/15866)イメージ。 .NET core Docker イメージは、マルチ arch タグを使用できます。 Dockerfile ファイルを対象となるオペレーティング システムを定義する必要が不要になった。 マルチ arch 機能は、複数コンピューター構成で使用する 1 つのタグを使用します。 たとえば、複数のアーキテクチャでは、1 つの共通タグ使用できます: **microsoft/dotnet:2.0.0-runtime**です。 Linux コンテナー環境からそのタグをプルする場合は、Debian ベースのイメージを取得します。 Windows コンテナー環境からそのタグをプルする場合は、Nano Server ベースのイメージを取得します。 + +.NET Framework のイメージ、従来の .NET Framework は、Windows のみをサポートしているためには、マルチ arch 機能を使用することはできません。 + +## Windows コンテナーの種類 + +Linux コンテナーと同様に Windows Server コンテナーは、Docker エンジンを使用して管理されます。 Linux コンテナーとは異なりは、Windows コンテナーは、次の 2 つの異なるコンテナー型を含めるか、回数-Windows Server コンテナーと HYPER-V の分離を実行します。 + +**Windows Server コンテナー**: プロセスと名前空間の分離テクノロジを使用してアプリケーションの分離を提供します。 Windows Server コンテナーは、コンテナー ホストとホストで実行されているすべてのコンテナーとカーネルを共有します。 これらのコンテナーでは、悪意のあるセキュリティの境界を指定しないと、信頼されていないコードを分離は使用できません。 これらのコンテナーでは、共有カーネル領域がないため、同じカーネルのバージョンと構成が必要です。 + +**HYPER-V 分離**: 各コンテナーを大幅に最適化された VM で実行して Windows Server コンテナーによって提供される分離を展開します。 この構成では、コンテナー ホストのカーネルは、同じホスト上の他のコンテナーとは共有されません。 これらのコンテナーは、悪意のあるマルチ テナントをホストするため、VM の同様のセキュリティ保証と設計されています。 これらのコンテナーは、ホストまたはホスト上の他のコンテナーで、カーネルを共有しないするためのカーネル異なるバージョン (サポートされているバージョン) の構成を実行できます。 たとえば、Windows 10 上のすべての Windows コンテナーは、Windows Server カーネルのバージョンと構成を利用するのに HYPER-V 分離を使用します。 + +HYPER-V 分離の有無は、windows コンテナーを実行すると、実行時の意思決定です。 最初に、HYPER-V の分離を使用したコンテナーの作成を選択し、実行時に、代わりに、Windows Server のコンテナーとして実行を選択する可能性があります。 + +### その他の技術情報 + +- **Windows コンテナーのドキュメント** + + [https://docs.microsoft.com/virtualization/windowscontainers/](https://docs.microsoft.com/virtualization/windowscontainers/) + +- **Windows コンテナーの基礎** + + [https://docs.microsoft.com/virtualization/windowscontainers/about/](https://docs.microsoft.com/virtualization/windowscontainers/about/) + +- **インフォ グラフィック: Microsoft とコンテナー** + + [https://info.microsoft.com/rs/157-GQE-382/images/Container%20infographic%201.4.17.pdf](https://info.microsoft.com/rs/157-GQE-382/images/Container%20infographic%201.4.17.pdf) + + +## Azure でコンテナーのエコシステム + +前のセクションで説明しましただけでなく、特定のコンテナー イメージは、.NET アプリケーションの詳細については Docker コンテナーの利点があります。 すべての一般的な情報については、開発またはアプリケーションを containerize するために不可欠です。 +ただし、運用配置環境または QA および開発/テスト環境であっても、検討するとき、Microsoft Azure は、開かれていて、広範なさまざまな選択肢、(次の図に示すように) クラウドで完全コンテナーのエコシステムを提供します。 特定のアプリケーションのニーズに応じて、1 つまたは別の Azure 製品を選択してください。 + +![](./media/image7.5.png) + +> **図 4-7.5 です。** Azure でコンテナーのエコシステム + +Azure では、次の製品のインフラストラクチャと見なされるコンテナーをサポートするコンテナーのエコシステム: から +- **Azure のコンテナー インスタンス (ACI)** +- **Azure の仮想マシン**(のコンテナーのサポート) +- **Azure の仮想マシン スケール セット**(のコンテナーのサポート) + +これら 3 つから ACI は非常に大きな利点、これは、基になる OS をする必要もありませんアップグレード/修正プログラムなどを維持する必要はありませんが、ACI まだが配置されているより適切にこのブックの今後のセクションで説明されていると、インフラストラクチャ レベルのファクトを提供します。 + +レベルは、PaaS (サービスとしてのプラットフォーム) 内で複数の配置、同時に Azure のサポートのコンテナーでは、製品は次のとおりです。 + +- **Azure App Service** +- **Azure の Kubernetes サービス (AKS と ACS)** +- **Azure Service Fabric** +- **Azure Batch** + +次に、Azure コンテナー レジストリは、すべての以前の製品を登録して、カスタム コンテナー イメージを展開するときに使用できる Azure でホストされる高のスケーラブルなコンテナー レジストリがします。 + +さらに、コンテナーから使用できる他のマネージ サービスなどの Azure SQL Database、Azure Redis キャッシュでは、Azure Cosmos DB などの Azure でします。 さらに、サード パーティ製のソリューション/プラットフォームでは Azure Marketplace クラウド Foundry など OpenShift Azure 内のコンテナーも使用できます。 + +次のセクションでは、特に Windows コンテナーを対象とするときに、それらの Azure の製品やソリューションの各を使用する場合の Microsoft の推奨事項を調べることができます。 + + +>[!div class="step-by-step"] +[前へ](what-about-cloud-native-applications.md) +[次へ](when-not-to-deploy-to-windows-containers.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/index.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/index.md new file mode 100644 index 00000000000..854322918e7 --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/index.md @@ -0,0 +1,27 @@ +--- +title: クラウドに最適化されたアプリケーションへの既存の .NET アプリケーションを最新化します。 +description: Azure クラウドおよび Windows コンテナーで既存の .NET アプリケーションを最新化する +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/28/2018 +ms.openlocfilehash: ba4610e7f5276f6c033a53ea78fb30bce50bc304 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# クラウドに最適化されたアプリケーションへの既存の .NET アプリケーションを最新化します。 + +> ビジョン: は、出荷を高速およびアプリケーションの配信のコストを削減できるように、展開の機敏性を大幅に向上させるためにアプリケーションをクラウドに最適化された既存の .NET Framework アプリケーションを開放します。 + +クラウドやコンテナーなどの新しいテクノロジのメリットを活用するために、既存の .NET アプリケーションを少なくとも部分的に最新化する必要があります。 最終的に、エンタープライズ アプリケーションを最新化すると、総保有コストが低下します。 + +アプリを部分的に刷新いって、必ずしも見直し、完全に移行します。 重要ですが、簡単に近代化を行うと、既存のアプリケーションを最初に最新化できます。 Windows および IIS の依存関係がある既存の .NET Framework のバージョンで作成された現在のコード ベースを保守することができます。 図 4-1: アプリをクラウドに最適化された方法を強調表示は、Azure アプリケーション近代化成熟度モデル内に配置します。 + +![クラウドに最適化されたアプリケーションの配置](./media/image1.png) + +> **図 4-1** クラウドに最適化されたアプリケーションの配置 + +>[!div class="step-by-step"] +[前へ](../migrate-your-relational-databases-to-azure.md) +[次へ](reasons-to-modernize-existing-net-apps-to-cloud-optimized-applications.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/microsoft-technologies-in-cloud-optimized-applications.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/microsoft-technologies-in-cloud-optimized-applications.md new file mode 100644 index 00000000000..8e1b1b74846 --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/microsoft-technologies-in-cloud-optimized-applications.md @@ -0,0 +1,41 @@ +--- +title: クラウドに最適化されたアプリケーションで Microsoft のテクノロジ +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |クラウドに最適化されたアプリケーションで Microsoft のテクノロジ +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/28/2018 +ms.openlocfilehash: ece366ee3918124bb60e367d3c7447c1d4555c72 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# クラウドに最適化されたアプリケーションで Microsoft のテクノロジ + +次の一覧は、ツール、テクノロジ、およびはクラウドに最適化されたアプリの要件として認識されるソリューションについて説明します。 優先度の高いに応じて選択的にまたは段階的に、クラウドに最適化された要素を導入できます。 + +- **クラウド インフラストラクチャ**: コンピューティング プラットフォーム、オペレーティング システム、ネットワーク、および記憶域を提供するインフラストラクチャ。 Microsoft Azure は、このレベルに配置されます。 + +- **ランタイム**: この層は、アプリケーションを実行する環境を提供します。 コンテナーを使用している場合は、このレイヤー通常はに基づいて[Docker エンジン](https://docs.docker.com/engine/)、Linux ホスト上または Windows ホストで実行中です。 ([Windows コンテナー](https://docs.microsoft.com/virtualization/windowscontainers/about/) Windows Server 2016 以降ではサポートされています。 Windows コンテナーは Windows で実行される既存の .NET Framework アプリケーションに最適な選択肢です。) + +- **クラウドの管理**: 管理されたクラウド オプションを選択するときに、コストと複雑さを管理して、基になるインフラストラクチャ、Vm、OS パッチをサポートするネットワーク構成を回避できます。 IaaS を使用して、移行する場合は、これらすべてのタスク、および関連するコストを担当しています。 管理されたクラウド オプションでは、アプリケーションとサービスを開発のみを管理します。 通常、クラウド サービス プロバイダーでは、他のすべてを管理します。 Azure で管理されたクラウド サービスの例として、 [Azure SQL Database](https://azure.microsoft.com/services/sql-database)、 [Azure Redis Cache](https://azure.microsoft.com/services/cache/)、 [Azure Cosmos DB](https://azure.microsoft.com/services/cosmos-db/)、 [Azure Storage](https://azure.microsoft.com/services/storage/)、[For MySQL データベースを azure](https://azure.microsoft.com/services/mysql/)、 [PostgreSQL の Azure データベース](https://azure.microsoft.com/services/postgresql/)、 [Azure Active Directory](https://azure.microsoft.com/services/active-directory/)のようなコンピューティング サービスを管理および[VM スケール設定](https://azure.microsoft.com/services/virtual-machine-scale-sets/)、 [Azure Service Fabric](https://azure.microsoft.com/services/service-fabric/)、 [Azure App Service](https://azure.microsoft.com/services/app-service/)、および[Azure Kubernetes サービス](https://azure.microsoft.com/services/container-service/)です。 + +- **アプリケーションの開発**: コンテナーで実行されるアプリケーションをビルドするときに多くの言語から選択できます。 このガイドの焦点[.NET](https://www.microsoft.com/net)が、Node.js、Python、Spring/Java と同様に、他の言語を使用して、コンテナー ベースのアプリを開発したり、移動できます。 + +- **製品利用統計情報ログ、および監査関連の監視、**: 監視および監査のアプリケーションとクラウドで実行されているコンテナーに機能は、クラウドに最適化されたアプリケーションにとって不可欠です。 [Azure の Application Insights](https://azure.microsoft.com/services/application-insights/)と[Microsoft Operations Management Suite](https://www.microsoft.com/cloud-platform/operations-management-suite)クラウドに向けて最適化されたアプリの監視、および監査を提供する Microsoft 製品の主なツールです。 + +- **プロビジョニング**: オートメーション ツールのヘルプ、インフラストラクチャをプロビジョニングし、複数の環境 (運用、テスト、ステージング) にアプリケーションを展開します。 Chef、Puppet などのツールを使用して、アプリケーションの構成および環境を管理することができます。 このレイヤーも簡単かつ直接的なアプローチを使用して実装することができます。 たとえば、展開ツールで Azure コマンド ライン インターフェイス (Azure CLI) を使用して直接とし、継続的なデプロイを使用でき、リリース管理パイプラインに[Visual Studio Team Services](https://www.visualstudio.com/team-services/)です。 + +- **アプリケーションのライフ サイクル**: [Visual Studio Team Services](https://www.visualstudio.com/team-services/) Jenkins など、他のツールは、するのに役立つ組み込みのオートメーション サーバー実装 CI/CD パイプライン、リリース管理を含むとします。 + +この章で、関連のチュートリアルの次のセクションでは、ランタイム層 (Windows コンテナー) に関する詳細情報について重点的に説明します。 このガイダンスでは、Windows Server 2016 (とそれ以降のバージョン) で Windows コンテナーの Vm と Azure のコンテナー インスタンスを展開する方法について説明します。 Azure App Service などのより高度な PaaS プラットフォームおよび Azure Service Fabric および Azure Kubernetes サービスと同様に orchestrator についても説明します。 + +## モノリシック アプリケーション*できます*するクラウドに最適化されました。 + +そのモノリシック アプリケーション (microservices に基づいていないこと) を強調表示することが重要*できます*クラウドに向けて最適化されたアプリケーションします。 構築し、コンテナー、継続的な配信、および DevOps の組み合わせを使用してモデルをコンピューティング クラウド利用モノリシックのアプリケーションを操作できます。 モノリシックな既存のアプリケーションがビジネスの目標の適切な場合は、その改革し、ようにクラウドに最適化されました。 + +同様に、モノリシック アプリケーションできますが、アプリケーションをクラウドに最適化された場合 N 層アプリケーションと同様に、他のより複雑なアーキテクチャことができますもする最新化されたアプリケーションをクラウドに最適化されたとします。 + +>[!div class="step-by-step"] +[前へ](reasons-to-modernize-existing-net-apps-to-cloud-optimized-applications.md) +[次へ](what-about-cloud-native-applications.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/migrate-to-hybrid-cloud-scenarios.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/migrate-to-hybrid-cloud-scenarios.md new file mode 100644 index 00000000000..ab82f793c78 --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/migrate-to-hybrid-cloud-scenarios.md @@ -0,0 +1,71 @@ +--- +title: ハイブリッド クラウド シナリオへの移行します。 +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |ハイブリッド クラウド シナリオへの移行します。 +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/30/2018 +ms.openlocfilehash: 8885ee8fce4f8c11c14ee8936f3ee0ffd89ece04 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# ハイブリッド クラウド シナリオへの移行します。 + +組織や企業によっては、Microsoft Azure などのパブリック クラウドに、アプリケーションの一部または規制や独自のポリシーのための他の任意のパブリック クラウドに移行できません。 ただし、どのような組織は、パブリック クラウドおよびその他のアプリケーション、オンプレミスでのアプリケーションの一部がなくなりますメリットがある可能性がありますです。 混在する環境がさまざまなプラットフォームと内部設置型環境とパブリック クラウドで使用されているテクノロジのための環境での複雑度が高くを招くことができます。 + +Microsoft では、最適なハイブリッド クラウド ソリューションを提供する、既存の資産を最適化できますいずれか、オンプレミスと Azure のハイブリッド クラウド内の一貫性を確保するときに、パブリック クラウドでします。 既存のスキルを最大化し、クラウドまたはオンプレミスで Azure スタック (オンプレミス) と Azure (パブリック クラウド) のおかげで実行できるアプリを構築するための柔軟で、統一されたアプローチを取得できます。 + +セキュリティに関しては、ときに、ハイブリッド クラウドの間で管理およびセキュリティを一元化できます。 内部設置型へのシングル サインオンを指定して、クラウド データ センターからすべての資産の制御を取得し、クラウド アプリできます。 ためには、Active Directory のハイブリッド クラウドに拡張および id 管理を使用しています。 + +最後に、配布しシームレスにデータを分析、クラウドとオンプレミスの資産に同じクエリ言語を使用し、適用できます分析と深いをその元に関係なく、データを強化する Azure で学習します。 + +## Azure のスタック + +Azure のスタックは、ハイブリッド クラウド プラットフォームできるように、組織のデータ センターから Azure サービスを提供します。 Azure のスタックは、エッジと接続されていない環境では、または特定のセキュリティとコンプライアンス要件を満たすように、主要なシナリオで、最新のアプリケーション用の新しいオプションをサポートするために設計されています。 + +図 4-13 では、Microsoft が提供する場合は true。 ハイブリッド クラウド プラットフォームの概要を示します。 + +![Azure のスタックは、Azure で Microsoft ハイブリッド クラウド プラットフォーム](./media/image13.jpg) + +> **図 4-13。** Azure のスタックは、Azure で Microsoft ハイブリッド クラウド プラットフォーム + +Azure のスタックは、ニーズに合わせて、展開の 2 つのオプションで提供されています。 + +- Azure のスタックは、システムを統合 + +- Azure のスタック開発キット + +### Azure のスタックは、システムを統合 + +Microsoft とハードウェア パートナーのパートナーシップでは、azure スタック統合システムが提供します。 パートナーシップでは、わかりやすくするための管理の分散クラウド ペース革新性を実現するソリューションを作成します。 ハードウェアとソフトウェアの統合システムとして、Azure のスタックが提供されるため、まだクラウドから革新を採用しているときに柔軟性と制御、適切な量を取得します。 Azure 統合スタック システムでは、12 のノードに 4 からサイズの範囲し、ハードウェア パートナーと Microsoft によって共同でサポートされます。 Azure スタック統合システムを使用すると、実稼働ワークロードの新しいシナリオを実装します。 + +### Azure のスタック開発キット + +Microsoft Azure スタック Development Kit では、評価し、Azure の履歴に関する学習を行うこともできる Azure スタックの単一ノード展開です。 またするツールと一貫性がある Azure して Api を使用して開発できます。 ここで、開発環境として Azure スタック開発キットを使用することができます。 Azure スタック Development Kit は、実稼働環境として使用するものではありません。 + +### その他の技術情報 + +- **Azure のハイブリッド クラウド** + + [https://www.microsoft.com/cloud-platform/hybrid-cloud](https://www.microsoft.com/cloud-platform/hybrid-cloud) + +- **Azure Stack** + + [https://azure.microsoft.com/overview/azure-stack/](https://azure.microsoft.com/overview/azure-stack/) + +- **Windows コンテナーの active Directory のサービス アカウントします。** + + [https://docs.microsoft.com/virtualization/windowscontainers/manage-containers/manage-serviceaccounts](https://docs.microsoft.com/virtualization/windowscontainers/manage-containers/manage-serviceaccounts) + +- **サポートが Active Directory コンテナーを作成します。** + + [https://blogs.msdn.microsoft.com/containerstuff/2017/01/30/create-a-container-with-active-directory-support/](https://blogs.msdn.microsoft.com/containerstuff/2017/01/30/create-a-container-with-active-directory-support/) + +- **Azure のハイブリッド特典ライセンス** + + [https://azure.microsoft.com/pricing/hybrid-use-benefit/](https://azure.microsoft.com/pricing/hybrid-use-benefit/) + +>[!div class="step-by-step"] +[前へ](modernize-your-apps-lifecycle-with-ci-cd-pipelines-and-devops-tools-in-the-cloud.md) +[次へ](../walkthroughs-technical-get-started-overview.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/modernize-your-apps-lifecycle-with-ci-cd-pipelines-and-devops-tools-in-the-cloud.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/modernize-your-apps-lifecycle-with-ci-cd-pipelines-and-devops-tools-in-the-cloud.md new file mode 100644 index 00000000000..22ad9a979e5 --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/modernize-your-apps-lifecycle-with-ci-cd-pipelines-and-devops-tools-in-the-cloud.md @@ -0,0 +1,39 @@ +--- +title: CI/CD パイプラインや DevOps ツール、クラウドでアプリのライフ サイクルを最新化します。 +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |CI/CD パイプラインや DevOps ツール、クラウドでアプリのライフ サイクルを最新化します。 +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/30/2018 +ms.openlocfilehash: 63907a1911b4c95f0dbecb2af33964225cf3e7b1 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# CI/CD パイプラインや DevOps ツール、クラウドでアプリのライフ サイクルを最新化します。 + +今日の企業は、marketplace に競合する迅速なペースで導入する必要があります。 高品質を提供するには、最新のアプリケーションには、DevOps ツールや技術革新の定数このサイクルの実装に不可欠なプロセスが必要です。 適切な DevOps ツールは、開発者は継続的なデプロイを効率化し、ユーザーの手に革新的なアプリケーションを迅速に取得します。 + +継続的な統合とデプロイのプラクティスは定評が、複数のコンテナー アプリケーションで作業するときに特にコンテナーの概要新しいの考慮事項について説明します。 + +Visual Studio Team Services には、継続的インテグレーションとさまざまな公式 Team Services の展開タスクを環境に複数のコンテナー アプリケーションの展開がサポートされています。 + +- [スタンドアロンでの Docker ホストの VM 展開](https://docs.microsoft.com/vsts/build-release/apps/cd/deploy-docker-windowsvm)(Linux または Windows Server 2016 以降) + +- [Service Fabric に展開します。](https://docs.microsoft.com/azure/service-fabric/service-fabric-tutorial-deploy-app-with-cicd-vsts) + +- [Azure のコンテナー サービス – Kubernetes に展開します。](https://docs.microsoft.com/vsts/build-release/apps/cd/azure/deploy-container-kubernetes) + +展開できますが、 [Docker Swarm](https://blogs.msdn.microsoft.com/jcorioland/2016/11/29/full-ci-cd-pipeline-to-deploy-multi-containers-application-on-azure-container-service-docker-swarm-using-visual-studio-team-services/)または DC/OS Team Services のスクリプトを使用したタスクを使用しています。 + +続けるには展開の機敏性を促進することは、これらのツールは、優れた開発用のテスト-運用デプロイのエクスペリエンスに開発および CI/CD ソリューションの選択肢を備えた、コンテナーのワークロードを提供します。 + +図 4-12 には、Azure コンテナー サービスで Kubernetes クラスターに展開する継続的なデプロイ パイプラインが表示されます。 + +![Visual Studio Team Services 継続的なデプロイのパイプライン、Kubernetes クラスターに展開します。](./media/image12.png) + +> **図 4-12 です。** Visual Studio Team Services 継続的なデプロイのパイプライン、Kubernetes クラスターに展開します。 + +>[!div class="step-by-step"] +[前へ](modernize-your-apps-with-monitoring-and-telemetry.md) +[次へ](migrate-to-hybrid-cloud-scenarios.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/modernize-your-apps-with-monitoring-and-telemetry.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/modernize-your-apps-with-monitoring-and-telemetry.md new file mode 100644 index 00000000000..588b3fd46e2 --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/modernize-your-apps-with-monitoring-and-telemetry.md @@ -0,0 +1,99 @@ +--- +title: 監視と遠隔測定でアプリを最新化します。 +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |監視と遠隔測定でアプリを最新化します。 +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/30/2018 +ms.openlocfilehash: 8f5f9bfebf46db7b98bedc4b5b8204d23357c72e +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# 監視と遠隔測定でアプリを最新化します。 + +実稼働環境でアプリケーションを実行するときに、アプリケーションの実行方法に関する詳細情報があることが重要です。 高レベルのパフォーマンス ユーザーが、エラーを取得するか、安定性と信頼性の高いアプリケーションは、ですか。 豊富なパフォーマンスの監視、強力なアラート、およびダッシュ ボード、アプリケーションが使用できると期待どおりに実行することを確認する必要があります。 問題があるかどうかをすばやく確認を顧客の数が、影響を受けるし、を見つけて、問題を修正する根本原因分析の実行を決定できる必要があります。 + +## Application Insights を使用してアプリケーションを監視します。 + +Application Insights は、複数のプラットフォームで作業を行う web 開発者の拡張可能なアプリケーション パフォーマンス管理 (APM) サービスです。 これを使用して、ライブ web アプリケーションを監視します。 Application Insights は、パフォーマンス上の問題を自動的に検出します。 ユーザーはどの機能実際にアプリを理解するため、問題の診断に役立つ強力な分析ツールが含まれています。 Application Insights はパフォーマンスと使いやすさを継続的に改善するために設計されています。 アプリのプラットフォームでは、.NET、Node.js、J2EE をするかどうかなどのさまざまなでうまく動作オンプレミスにホストまたはクラウドにします。 Application Insights は、DevOps プロセスと統合され、さまざまな開発ツールに接続ポイントを持ちます。 + +図 4-10 では、Application Insights でアプリを監視する方法と、ダッシュ ボードにこれらの分析の表示の例を示します。 + +![Application Insights の監視ダッシュ ボード](./media/image10.png) + +> **図 4-10 です。** Application Insights の監視ダッシュ ボード + +## ログ分析とそのコンテナーの監視ソリューションを使用して Docker インフラストラクチャを監視します。 + +[Azure ログ分析](https://docs.microsoft.com/azure/log-analytics/log-analytics-overview)の一部である、[全体的な監視ソリューションの Microsoft Azure](https://docs.microsoft.com/azure/monitoring-and-diagnostics/monitoring-overview)です。 サービスに[Operations Management Suite (OMS)](https://docs.microsoft.com/azure/operations-management-suite/operations-management-suite-overview)です。 ログ分析クラウドを監視し、内部設置型環境 (内部設置型用の OMS) の可用性とパフォーマンスを維持するためにします。 リソースがクラウドとオンプレミスの環境で、複数のソースで分析を行うために他の監視ツールから生成されたデータを収集します。 + +Azure インフラストラクチャ ログとの関連ログ分析、Azure サービスとして取り込み、他の Azure サービスからのログとメトリック データ (を介して[Azure モニター](https://docs.microsoft.com/azure/monitoring-and-diagnostics/monitoring-overview-azure-monitor))、Azure Vm、Docker コンテナー、および内部設置型またはその他のクラウド インフラストラクチャ。 ログ分析は、柔軟なログ検索とこのデータの上にボックス外の分析を提供します。 指定した条件に基づいて、豊富なことソース間でデータの分析に使用することができます、ツールにより、複雑なクエリ、すべてのログを事前にアラートが通知を提供します。 カスタム リポジトリにデータを中央ログ分析、クエリし、視覚的に表現できますも収集できます。 すぐに洞察を得る、セキュリティ ログ分析の組み込みのソリューションの利点と、インフラストラクチャの機能を実行することができますも。 + +ログ分析を OMS ポータルまたは任意のブラウザーで実行して、Azure ポータルを介してアクセスし、構成設定にアクセスして複数のツールを分析し、収集したデータの動作を提供できます。 + +[コンテナー監視ソリューション](https://docs.microsoft.com/azure/log-analytics/log-analytics-containers)ではログ分析、表示および 1 つの場所で、Docker と Windows コンテナー ホストを管理します。 ソリューションは、どのコンテナーを示しています。 実行して、どのようなコンテナー イメージを実行していると、コンテナーが実行されています。 コンテナーで使用されているコマンドを含む、詳細な監査情報を表示することができます。 また、コンテナーを表示し、Docker または Windows のホストをリモートで表示することがなく一元的なログを検索トラブルシューティングすることもできます。 ホスト上のノイズの多いと使用の余分なリソースがあるコンテナーを検索できます。 さらに、一元的な CPU、メモリ、記憶域、およびネットワーク使用率およびパフォーマンスについては、コンテナーを表示することができます。 Windows を実行するコンピューター上には、集中管理し、Windows Server からログを比較することができます、HYPER-V と Docker のコンテナーです。 ソリューションには、次のコンテナー orchestrators がサポートされています。 + +- Docker Swarm + +- DC OS/ + +- Kubernetes + +- Service Fabric + +- Red Hat OpenShift + +図 4-11 は、さまざまなコンテナー ホストのエージェントと OMS との間の関係を示しています。 + +![ログ分析コンテナー監視ソリューション](./media/image11.png) + +> **図 4-11。** ログ分析コンテナー監視ソリューション + +ログ分析のコンテナーの監視ソリューションを使用できます。 + +- 1 つの場所のすべてのコンテナー ホストに関する情報を参照してください。 + +- 対象のコンテナを実行しているどのようなイメージを実行して、実行しています。 + +- コンテナーにおけるアクションの監査証跡を参照してください。 + +- 表示して、Docker ホストへのリモート ログインに関係なく一元的なログを検索してトラブルシューティングを行います。 + +- 「ノイズの多い近隣」場合があり、ホスト上余分なリソースを消費するコンテナーを検索します。 + +- 一元的な CPU、メモリ、記憶域、およびネットワーク使用率およびパフォーマンスについては、コンテナーを表示します。 + +### その他の技術情報 + +- **Microsoft Azure での監視の概要** + +[https://docs.microsoft.com/azure/monitoring-and-diagnostics/monitoring-overview](https://docs.microsoft.com/azure/monitoring-and-diagnostics/monitoring-overview) + +- **Application Insights とは何ですか。** + +[https://docs.microsoft.com/azure/application-insights/app-insights-overview](https://docs.microsoft.com/azure/application-insights/app-insights-overview) + +- **ログ分析は何ですか。** + +[https://docs.microsoft.com/azure/log-analytics/log-analytics-overview](https://docs.microsoft.com/azure/log-analytics/log-analytics-overview) + +- **ログ分析でコンテナー監視ソリューション** + +[https://docs.microsoft.com/azure/log-analytics/log-analytics-containers](https://docs.microsoft.com/azure/log-analytics/log-analytics-containers) + +- **Azure のモニターの概要** + +[https://docs.microsoft.com/azure/monitoring-and-diagnostics/monitoring-overview-azure-monitor](https://docs.microsoft.com/azure/monitoring-and-diagnostics/monitoring-overview-azure-monitor) + +- **Operations Management Suite (OMS) とは何ですか。** + +[https://docs.microsoft.com/azure/operations-management-suite/operations-management-suite-overview](https://docs.microsoft.com/azure/operations-management-suite/operations-management-suite-overview) + +- **OMS を使用して Service Fabric で Windows Server コンテナーの監視** + +[https://docs.microsoft.com/azure/service-fabric/service-fabric-diagnostics-containers-windowsserver](https://docs.microsoft.com/azure/service-fabric/service-fabric-diagnostics-containers-windowsserver) + +>[!div class="step-by-step"] +[前へ](build-resilient-services-ready-for-the-cloud-embrace-transient-failures-in-the-cloud.md) +[次へ](modernize-your-apps-lifecycle-with-ci-cd-pipelines-and-devops-tools-in-the-cloud.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/reasons-to-modernize-existing-net-apps-to-cloud-optimized-applications.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/reasons-to-modernize-existing-net-apps-to-cloud-optimized-applications.md new file mode 100644 index 00000000000..c3304411663 --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/reasons-to-modernize-existing-net-apps-to-cloud-optimized-applications.md @@ -0,0 +1,71 @@ +--- +title: クラウドに最適化されたアプリケーションへの既存の .NET アプリケーションを最新化する理由 +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |クラウドに最適化されたアプリケーションへの既存の .NET アプリケーションを最新化する理由 +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/28/2018 +ms.openlocfilehash: a874a742f6a5b32e15040ad0a237f0e0fa7908dc +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# クラウドに最適化されたアプリケーションへの既存の .NET アプリケーションを最新化する理由 + +クラウドに最適化されたアプリケーションでは、短時間でおよび繰り返しを配信できますを顧客に信頼性の高いアプリケーション。 プラットフォーム、アプリの運用の複雑さの多くを遅らせることで重要な機敏性と信頼性を取得します。 + +アプリを出荷する時点で、すばやく市場にアプリケーションを取得できない場合が対象とする、市場が進化してきました。 アプリケーションを設計またはエンジニア リングどの程度に関係なく、遅すぎますする必要があります。 か可能性が失敗して、市場のニーズを持つアプリの配信を同期することはできませんので、最大限に到達しません。 + +ビジネスの継続的な技術革新の必要性は、制限を開発および運用チームをプッシュします。 ビジネスの継続的な技術革新に必要な機敏性を実現する唯一の方法では、コンテナーと特定のクラウドに最適化されたアプリケーションの基本原則のようなテクノロジを使用してアプリケーションを刷新してです。 + +一番下の行はこと組織では、ビルドし、クラウドに最適化されたは、アプリケーションを管理、そのことができます早く顧客の手にソリューションを配置市場で、該当するときに新しいアイデアです。 + +## クラウドに最適化されたアプリケーションの基本原則と基本思想 + +クラウドの機能強化は次の 2 つの目標を達成に焦点を合わせた: コストを削減し、ビジネスの成長の機敏性を向上させることによって向上します。 これらの目標は、プロセスを簡略化し、リリースのアプリケーションの出荷すると、摩擦を減らすことによって実現されます。 + +で、アジャイル方法-自律的に他の内部設置型アプリからアプリを開発および解放しを展開する場合、自動スケールをクラウドに最適化されたアプリケーションは、監視、およびクラウドでアプリをトラブルシューティングします。 + +キーが*アジリティ*です。 任意の展開の運用を最小限に減らす場合を除き、機敏性と出荷することはできませんの問題と開発/テスト環境の問題です。 コンテナー (具体的には、Docker、事実上の標準として) と管理サービスは、この目的のために設計されました。 + +機敏性を実現するためには、クラウドでのスケーラブルなプラットフォームにリリースされる CI/CD パイプラインに基づく自動の DevOps プロセスも必要です。 (Azure App Service、Azure Service Fabric Azure Kubernetes サービスなど) の拡張性の高い回復力のクラウド プラットフォームに展開する (Visual Studio Team Services や Jenkins) などの CI/CD プラットフォームは、クラウド内の機敏性を実現するためのキー テクノロジです。 + +次の一覧は、メインの基本思想またはクラウドに最適化されたアプリケーションに関するヒントについて説明します。 これらの原則、プログレッシブまたは増分アプローチの一部のみまたはすべてを採用することができますに注意してください。 + +- **コンテナー**です。 コンテナーでは、アプリケーション自体にアプリケーションの依存関係を含める機能を提供します。 コンテナリゼーションは、実稼働環境に展開またはステージング環境でテストするときに発生する可能性が問題の数を大幅に短縮します。 最終的には、コンテナーには、アプリケーションの配信の機敏性が向上します。 + +- **復元力と拡張性の高いクラウド**です。 クラウドは、管理されている、弾力性、拡張性が高く、および回復力のあるであるプラットフォームを提供します。 これらの特性は、コストの機能強化を取得し、アプリケーションの出荷を高可用性と信頼性を継続的配信のための基本です。 管理サービスなどのマネージ データベース、管理サービス (CaaS)、および管理される記憶域は、アプリケーションのメンテナンス コストの軽減に根本的な部分をキャッシュします。 + +- **監視**です。 信頼性の高いアプリケーションは、しなくても検出および例外とアプリケーションのパフォーマンスの問題を診断することをお勧めはできません。 アプリケーション パフォーマンスの管理およびインスタント分析を使用して実用的な洞察を取得する必要があります。 + +- **DevOps カルチャと継続的な配信**です。 DevOps プラクティスを採用するには、チームが不要になった独立サイロで作業するカルチャの変更が必要です。 CI/CD パイプラインが、開発チームと IT 運用チーム、コンテナーと CI/CD ツールでサポートされている間の向上の共同作業がある場合にのみ可能です。 + +図 4-2 は、クラウドに最適化されたアプリケーションのメインの省略可能な柱を示しています。 以上柱を実装する、readier、アプリケーションは、顧客の期待を満たすで成功します。 + +> ![クラウドに最適化されたアプリケーションのメインの柱](./media/image2.png) +> +> **図 4-2** クラウドに最適化されたアプリケーションのメインの柱 + +要約すると、クラウドに最適化されたアプリケーションは、クラウド コンテナー、管理されたクラウド インフラストラクチャ、回復力のあるアプリケーション手法の組み合わせを使用しているときに、モデルをコンピューティングを活用したを構築し、アプリケーションを管理する方法監視、継続的な配信、および DevOps をすべて再構築し、既存のアプリケーションを書き直す必要はありません。 + +組織は、徐々 にこれらのテクノロジおよびアプローチ採用できます。 一度にすべての問題をすべてを採用する必要はありません。 導入できますにインクリメント方式でエンタープライズの優先度とユーザーのニーズによって異なります。 + +## クラウドに最適化されたアプリケーションの利点 + +(よう再設計するコーディングなし) をクラウドに最適化されたアプリケーションに既存のアプリケーションを変換することで、次の利点を取得できます。 + +- **管理されたインフラストラクチャはクラウド プロバイダーによって処理されるため、コストを削減**です。 クラウドに最適化されたアプリケーションは、クラウドの既定の柔軟性、autoscale、および高可用性を使用して、クラウドの利点を取得します。 利点はコンピューティング機能 (Vm とコンテナー) するだけでなく関連しますが、クラウド内のリソースにも依存 DBaaS、CaaS、および任意のインフラストラクチャと同様に、アプリケーションがありますが必要です。 + +- **回復力のあるアプリケーションとインフラストラクチャ**です。 クラウドに移行する場合は、; 一時的な障害を受け入れる必要があります。クラウド内の障害が発生します。 また、クラウド インフラストラクチャとハードウェアは「置換、」が一時的なダウンタイムの機会を向上できます。 同時に、内部クラウド機能と回復性を実装し、復旧を自動化する特定のアプリケーション開発の手法やすくはるか、クラウド内の予期しない障害から復旧します。 + +- **アプリケーションのパフォーマンスがさらに深い洞察**です。 クラウドの監視ツールを Azure Application Insights の正常性の管理、ログ、および通知のビジュアル化を提供するようにします。 監査ログは、簡単にデバッグし、監査、信頼性の高いクラウド アプリケーションの基本的なアプリケーションをできるようにします。 + +- **アジャイルの展開でのアプリケーションの移植性**です。 コンテナー (Linux または Windows のいずれかのコンテナーが Docker エンジンに基づく) では、クラウドがロックされているアプリケーションを防ぐに最適なソリューションを提供します。 コンテナー、Docker ホスト、および複数のクラウド orchestrators を使用すると、簡単に 1 つの環境から移動したり、別のクラウドできます。 コンテナーは、通常のどの環境でも (ステージ/テスト/運用) への展開で発生する競合を排除します。 + +すべてこれらの利点の最終的なエンド ツー エンドのアプリケーションのライフ サイクルのキーのコストの削減を提供します。 + +次のセクションでは、これらの利点はさらに詳しく説明し、特定のテクノロジにリンクされています。 + +>[!div class="step-by-step"] +[前へ](index.md) +[次へ](microsoft-technologies-in-cloud-optimized-applications.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/what-about-cloud-native-applications.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/what-about-cloud-native-applications.md new file mode 100644 index 00000000000..38b8d57fd2c --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/what-about-cloud-native-applications.md @@ -0,0 +1,72 @@ +--- +title: クラウド ネイティブ アプリケーションについて説明します。 +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |クラウド ネイティブ アプリケーションについて説明します。 +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/28/2018 +ms.openlocfilehash: 0e880689001ece2b770811cfbe3fea43aa425b32 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# クラウド ネイティブ アプリケーションについて説明します。 + +[クラウド ネイティブ](https://www.gartner.com/doc/3738117/comparing-leading-cloudnative-application-platforms)アプリケーションは、主な作業ではありません、このガイドのこの近代化成熟度レベルの理解しておくと、クラウドに最適化されたアプリケーションから区別するためと便利です。 + +図 4-3 は、アプリケーション近代化成熟度レベルでネイティブでクラウド アプリを配置します。 + +![クラウド ネイティブ アプリケーションの配置](./media/image3.png) + +> **図 4-3。** クラウド ネイティブ アプリケーションの配置 + +通常、クラウド ネイティブ近代化成熟度レベルには、新しい開発への投資が必要です。 通常、クラウドからネイティブ レベルへの移動が展開可能な自律的なサブシステム (microservices) を作成することで大規模なアプリケーションで小数点以下桁数と小数点以下桁数を大幅に向上させるためにできるだけ多くのアプリケーションを最新化するビジネス ニーズによって、独立して動作します。長い用語および増加の進化機敏性は、提供する、自律的なアプリのパートのコストを削減しながら、アプリケーションの他の領域から重要なは、利点を競合します。 + +メインの柱[クラウド ネイティブ](https://www.gartner.com/doc/3181919/architect-design-cloudnative-applications)機敏性と発展でき、いずれかに展開されているモノリシックなアーキテクチャを実現するが困難になる制限にスケール microservices アーキテクチャ アプローチに基づくアプリケーション内部設置型またはクラウドの環境。 + +図 4-4 は、ネイティブでクラウド モデルの主な特徴を示しています。 + +> ![クラウド固有の特性が Microservices、コンテナー、クラウドの回復力のある、orchestrators および serverles です。](./media/image4.png) +> +> **図 4-4 です。** クラウド固有の特性 + +さらに、人工知能 (AI)、機械学習 (ML) IoT など、他のサービスを追加することで基本的な最新の web アプリとクラウド ネイティブ アプリを拡張することができます。 これらのサービスを使用して、拡張可能なクラウドに向けて最適化されたアプローチのいずれかの可能性があります。 + +クラウド ネイティブ レベルでのアプリケーションでの基本的な違いは、アプリケーションのアーキテクチャです。 [クラウド ネイティブ](https://www.gartner.com/doc/3738117/comparing-leading-cloudnative-application-platforms)定義上、microservices に基づくアプリケーション、アプリケーションは、します。 特殊なアーキテクチャ、テクノロジ、およびプラットフォームでは、単一の web アプリケーションまたは従来の N 層アプリケーションと比較して、ネイティブでクラウド アプリが必要です。 + +## クラウド ネイティブ アプリケーションの詳細 + +[クラウド ネイティブ](https://www.gartner.com/doc/3181919/architect-design-cloudnative-applications)大規模でミッションクリティカルなアプリケーションのより高度なまたは完成度の高い状態です。 クラウド ネイティブ アプリケーションは、通常、アーキテクチャと既存のアプリケーションを刷新しての代わりに最初から作成した設計が必要です。 クラウド ネイティブ アプリケーションと簡単なクラウドに向けて最適化された web アプリケーションの重要な違いは、クラウド固有のアプローチで microservices アーキテクチャを使用することを推奨します。 モノリシック web アプリまたは N 層アプリ、アプリをクラウドに最適化されたことができます。 + +[12 係数アプリ](https://12factor.net/)(microservices アプローチに密接に関連するパターンのコレクション) は必須と見なされますも[クラウド ネイティブ](https://www.gartner.com/doc/3738117/comparing-leading-cloudnative-application-platforms)アプリケーション アーキテクチャ。 + +[クラウド ネイティブ コンピューティング Foundation (CNCF)](https://www.cncf.io/)クラウド ネイティブ原則のプライマリ プロモーターがします。 Microsoft では、 [、CNCF のメンバー](https://azure.microsoft.com/blog/announcing-cncf/)です。 + +サンプルの定義とクラウド ネイティブ アプリケーションの特性の詳細については、Gartner の記事を参照してください。[構築およびクラウド ネイティブ アプリケーションを設計する方法](https://www.gartner.com/doc/3181919/architect-design-cloudnative-applications)です。 クラウド ネイティブ アプリケーションを実装する方法に関する Microsoft の詳細については、次を参照してください。 [.NET microservices: コンテナーの .NET アプリケーションのアーキテクチャ](https://aka.ms/microservicesebook)です。 + +最も重要な考慮事項に完全なアプリケーションを移行するかどうか、[クラウド ネイティブ](https://www.gartner.com/doc/3738117/comparing-leading-cloudnative-application-platforms)モデルは microservices ベースのアーキテクチャを再構築し必要があります。 これで、大きなリファクタリング プロセスにより開発に多大な投資が明確に必要です。 通常このオプションを新しいレベルのスケーラビリティと長期的な機敏性を必要とするミッション クリティカルなアプリケーションを選択します。 いくつかの新しいシナリオの microservices を追加することによってクラウドからネイティブへの移動を開始し、最終的に microservices として完全にアプリケーションをリファクターすることができます。 これは、いくつかのシナリオに最適なオプションである増分アプローチです。 + +## Microservices について説明します。 + +組織のクラウド ネイティブ アプリケーションを考慮する場合は、microservices および動作のしくみを理解することが重要です。 + +Microservices アーキテクチャは、最初から、またはクラウド ネイティブ アプリケーションへの既存のアプリケーションを展開するときに作成されたアプリケーションを使用できる高度なアプローチです。 既存のアプリケーションを新しい microservices パラダイムについて説明するいくつかの microservices を追加することで開始することができます。 明らかに、設計者および特にこの種類のアーキテクチャ アプローチ用のコードにする必要があります。 + +ただし、microservices は、新規または最近のアプリケーションに必須ではありません。 Microservices は、「マジックの行頭文字」ではなく、すべてのアプリケーションを作成する 1 つ、最適な方法はありません。 Microservices を使用する方法とタイミングを構築する必要のあるアプリケーションの種類によって異なります。 + +Microservices アーキテクチャには、自律的なサービスの形式で、複数の独立したサブシステムに基づく分散し、大規模または複雑なミッションクリティカルなアプリケーションの推奨できるアプローチが高まっています。 Microservices ベースのアーキテクチャでは、アプリケーションができるサービスを独自に開発、テスト、バージョン管理、配置と拡張のコレクションとして構築されます。 マイクロ サービスごとに、関連する、自律的なデータベースでもかまいません。 + +.NET Core を使用して実装できる microservices アーキテクチャの詳細については、表示、ダウンロード可能な PDF 電子書籍[.NET microservices: コンテナーの .NET アプリケーションのアーキテクチャ](https://aka.ms/microservicesebook)です。 このガイドもは[オンライン](../../microservices-architecture/index.md)です。 + +強力な機能に依存しない展開、強力なサブシステム境界、およびテクノロジの多様性に提供して microservices シナリオにおいてさえ-も、多くの新しい課題が発生します。 断片化されていない、独立したデータ モデルなどの分散アプリケーションの開発に関連する課題に対処します。microservices; 間の回復力のある通信を実現します。最終的整合性; の必要性および運用の複雑さです。 Microservices より高度なモノリシック従来のアプリケーションと比較して複雑さを紹介します。 + +Microservices アーキテクチャ、複雑な特定のシナリオと特定のアプリケーションの種類だけは、マイクロ サービス ベースのアプリケーションに適しています。 複数ある大規模で複雑なアプリケーションは、これらのサブシステムを発展します。 このような場合は、長期的な増加の機敏性とアプリケーションの保守をより効率的より複雑なソフトウェア アーキテクチャを購入する価値はします。 小さい複雑なシナリオは、単体のアプリケーションのアプローチを続行する方がよい場合があります。 または単純な N 層のアプローチです。 + +これについては、繰り返し発生する可能性があっても、最後の注意点としてはならないを確認する「オールインワンまたは nothing すべて」として、アプリケーションで microservices を使用します。 拡張し、新しい microservices に基づいて小規模のシナリオを追加することによってモノリシックな既存のアプリケーションの進化できます。 Microservices アーキテクチャ アプローチで作業を開始する最初から開始する必要はありません。 実際には、新しいシナリオを追加することで既存のモノリシックまたは N 層アプリケーションを使用して進化することをお勧めします。 最終的には、自律的なコンポーネントまたは microservices にアプリケーションを中断することができます。 モノリシック microservices 方向、ステップ バイ ステップでアプリケーションの進化を開始することができます。 + +いずれの場合は、存在このガイドの残りの部分は、このガイダンスは近代化を通常モノリシックまたは N 層アーキテクチャを持つ既存のアプリの対象とする主なので、「microservices ベース アプリがありません」上のすべてのほとんどを説明します。 + + +>[!div class="step-by-step"] +[前へ](microsoft-technologies-in-cloud-optimized-applications.md) +[次へ](deploy-existing-net-apps-as-windows-containers.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-not-to-deploy-to-windows-containers.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-not-to-deploy-to-windows-containers.md new file mode 100644 index 00000000000..4af89179ef9 --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-not-to-deploy-to-windows-containers.md @@ -0,0 +1,48 @@ +--- +title: Windows コンテナーを展開しない場合 +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |Windows コンテナーを展開しない場合 +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/28/2018 +ms.openlocfilehash: 819f32955ff019414bef8820d17d272eddc11bf8 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# Windows コンテナーを展開しない場合 + +一部の Windows テクノロジは、Windows コンテナーによってサポートされていません。 ような場合、引き続き、通常は、Windows と IIS だけと共に、標準の Vm に移行する必要があります。 + +ケースが 2018年時点での Windows コンテナーでサポートされていません。 + +- 現在 Microsoft メッセージ キュー (MSMQ) は他の以前のリリースではなく Windows Server v1803 リリースでは、に基づいて Windows コンテナーで使用可能なではのみです。 + + - [UserVoice 要求フォーラム](https://windowsserver.uservoice.com/forums/304624-containers/suggestions/15719031-create-base-container-image-with-msmq-server) + + - [ディスカッション フォーラム](https://social.msdn.microsoft.com/Forums/bce99a7d-aa60-44fa-a348-450855650810/msmqserver-is-it-supported?forum=windowscontainers) + +- Microsoft 分散トランザクション コーディネーター (MSDTC) は、現在、Windows のコンテナーではサポートされません。 + + - [GitHub の問題](https://github.com/MicrosoftDocs/Virtualization-Documentation/issues/494) + +- 現在、Microsoft Office では、コンテナーはサポートしません。 + + - [UserVoice 要求フォーラム](https://windowsserver.uservoice.com/forums/304624-containers/suggestions/19686220-provide-office-support-for-containers) + +- UI アプリ (クライアント visual ユーザー インターフェイスを持つ) はサポートされているシナリオではありません。 + +- Windows インフラストラクチャの役割 (DNS、DHCP、DC、NTP、印刷、ファイル サーバー、IAM など) がサポートされるシナリオではありません。 + + +その他のサポートされないシナリオと、コミュニティからの要求は、Windows コンテナーの UserVoice フォーラムを参照してください:です。 + +### その他の技術情報 + +- **仮想マシンと Azure 内のコンテナー** + + [https://docs.microsoft.com/azure/virtual-machines/windows/containers](https://docs.microsoft.com/azure/virtual-machines/windows/containers) + +>[!div class="step-by-step"] +[前へ](deploy-existing-net-apps-as-windows-containers.md) +[次へ](when-to-deploy-windows-containers-in-your-on-premises-iaas-vm-infrastructure.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-in-your-on-premises-iaas-vm-infrastructure.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-in-your-on-premises-iaas-vm-infrastructure.md new file mode 100644 index 00000000000..310794d72e1 --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-in-your-on-premises-iaas-vm-infrastructure.md @@ -0,0 +1,23 @@ +--- +title: オンプレミスで Windows コンテナーを展開するときに IaaS VM インフラストラクチャ +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |オンプレミスで Windows コンテナーを展開するときに IaaS VM インフラストラクチャ +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/28/2018 +ms.openlocfilehash: 5583386a31b9a76a8413703ec611e8452d452eb1 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# オンプレミスで Windows コンテナーを展開するときに IaaS VM インフラストラクチャ + +- 組織は、クラウドに移動する準備ができていないか、ビジネスの目的で、クラウドに移動することができない可能性があります。 しかし、Windows コンテナーを使用して、独自のデータ センター内のメリットを享受することもできます。 + +- 使用されている内部設置型をしているし、する速度が低下するクラウドに移行しようとすると他の成果物があります。 たとえば、セキュリティまたは認証依存関係の内部設置型 Windows Server Active Directory、またはその他のオンプレミス資産です。 + +- Windows コンテナーを今日使用を開始する場合することができますの段階的移行をクラウドに明日言えますからです。 Windows コンテナーにはロックで使用して、任意のクラウドの配置の単位が高まっていません。 + +>[!div class="step-by-step"] +[前へ](when-not-to-deploy-to-windows-containers.md) +[次へ](when-to-deploy-windows-containers-to-azure-vms-iaas-cloud.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-to-azure-container-instances-ACI.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-to-azure-container-instances-ACI.md new file mode 100644 index 00000000000..b8f2693decb --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-to-azure-container-instances-ACI.md @@ -0,0 +1,40 @@ +--- +title: Azure コンテナー インスタンス (ACI) に Windows コンテナーを展開するタイミング +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |Azure コンテナー インスタンス (ACI) に Windows コンテナーを展開するタイミング +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/29/2018 +ms.openlocfilehash: 3dc23c96543d9611763b571105f52b150dfec06f +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# Azure コンテナー インスタンス (ACI) に Windows コンテナーを展開するタイミング + +Azure のコンテナー インスタンスがメインの価値提案は、すぐにコンテナーを展開することができますされ、その環境を維持する必要はありません、する必要はありません、基本オペレーティング システムまたは仮想マシンすべて透過的なアップグレード/修正プログラムを適用し、展開します。すぐに使用できる環境にコンテナーです。 + +理由と ACI を使用する場合のシナリオは、主なシナリオに似ています基本的にコンテナーでは、Azure Vm を使用すると、Azure のコンテナー インスタンスを使用するための主なシナリオは。 + +- **開発/テストのシナリオ** +- **タスクの自動化** +- **CI/CD エージェント** +- **小さな/スケール バッチ処理** +- **単純な web アプリ** + +単純な web アプリのシナリオは ACI の公平なシナリオが ACI でコンテナー イメージごとの 1 つのコンテナー インスタンスでのみ設定できる、ので高可用性はなくなりますをスケーラビリティが制限を考慮します。 + +ただし、ACI は 1 つのコンテナー インスタンスを提供するだけであるために、インフラストラクチャと見なされます、たとえは、Windows server の正規の Azure Vm と比較して大きなメリットです。 ACI、自己保持型の環境にのみ、コンテナーを展開してこれらのコンテナーに支払うだけです。 場所を使用している Vm のコンテナーのほとんどのシナリオの多くにより優れたプラットフォームであるために管理/更新/パッチ Vm、する必要はありません。 ACI を使用して単純ですが、単にコンテナーを展開する、単にコンテナーを展開する VM 環境を作成する必要はありません。 + +Azure コンテナー インスタンス (ACI) の主な利点は次のとおりです。 + +- サーバーを管理することがなく、コンテナーを実行します。 +- 要求時にコンテナーの機敏性を高める +- かつてないほど簡単かつ迅速にクラウドにコンテナーを展開する — 1 つのコマンドを使用します。 +- ハイパーバイザーの分離を使用したセキュリティで保護されたアプリケーション + +要するに、ACI では、や、仮想マシンを管理し、新しいツールを習得しなくてしなくても高速アプリを開発することができます。 クラウドで実行されている、コンテナーで、アプリケーションだけです。 + +>[!div class="step-by-step"] +[前へ](when-to-deploy-windows-containers-to-azure-vms-iaas-cloud.md) +[次へ](when-to-deploy-windows-containers-to-service-fabric.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-to-azure-container-service-kubernetes.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-to-azure-container-service-kubernetes.md new file mode 100644 index 00000000000..311339a4afd --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-to-azure-container-service-kubernetes.md @@ -0,0 +1,27 @@ +--- +title: Azure コンテナー サービス (つまり、Kubernetes) に Windows コンテナーを展開するタイミング +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |Azure コンテナー サービス (つまり、Kubernetes) に Windows コンテナーを展開するタイミング +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/30/2018 +ms.openlocfilehash: b7f106e2b79a2c6bb24733debf7f4828505d66a6 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# Azure コンテナー サービス (つまり、Kubernetes) に Windows コンテナーを展開するタイミング + +Azure のコンテナー サービスは、Azure の特に人気のオープン ソース ツールとテクノロジの構成を最適化します。 移植性、コンテナーと、アプリケーションの構成の両方を提供する、開いているソリューションが表示されます。 サイズ、ホストの数と、orchestrator ツールを選択します。 Azure のコンテナー サービスは、のインフラストラクチャを処理します。 + +既にしているオープン ソース orchestrators Kubernetes、Docker Swarm、DC/OS など場合、は、コンテナー ワークロードをクラウドに移動する、既存の管理方法を変更する必要はありません。 慣れているアプリケーションの管理ツールを使用し、任意の orchestrator の標準 API エンドポイントを介して接続します。 + +これらすべての orchestrators は、Linux Docker コンテナーを使用しているが、Windows コンテナーのプレビュー状態である可能性がありますのみとお考えの場合、完成度の高い環境です。 + +たとえば、Kubernetes でのサポートのコンテナーはネイティブ (ファーストクラス市民) Kubernetes で Windows コンテナーを使用しても (初期 2018 時点で ACS でのプレビュー) で効果的です。 + +重要な注意事項: 展開し、"複数 PaaS"バージョンの Kubernetes 用 ACS (Azure コンテナー サービス) AKS (Azure Kubernetes サービス)、ただし、Windows コンテナーはまだサポートされていません Q2 2018 時点では近日サポートされます。 + +>[!div class="step-by-step"] +[前へ](when-to-deploy-windows-containers-to-service-fabric.md) +[次へ](choosing-azure-compute-options-for-container-based-applications.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-to-azure-vms-iaas-cloud.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-to-azure-vms-iaas-cloud.md new file mode 100644 index 00000000000..6a4f5595a06 --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-to-azure-vms-iaas-cloud.md @@ -0,0 +1,25 @@ +--- +title: Azure Vm (IaaS クラウド) に Windows コンテナーを展開するタイミング +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |Azure Vm (IaaS クラウド) に Windows コンテナーを展開するタイミング +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/28/2018 +ms.openlocfilehash: 7472745577f414062b460fd71ab45bae85d7a62e +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# Azure Vm (IaaS クラウド) に Windows コンテナーを展開するタイミング + +Windows コンテナーを使用している場合でも、組織は Azure Vm を使用して、IaaS を処理する場合をまだしています。 つまり、インフラストラクチャ操作、VM の OS 修正プログラム、およびインフラストラクチャの複雑さを扱う拡張性の高いアプリケーションの負荷分散インフラストラクチャで複数の Vm を展開する必要がある場合。 Azure VM で Windows コンテナーを使用するための主なシナリオは次のとおりです。 + +- **開発/テスト環境**: A VM クラウドでは、開発とテスト、クラウド内に最適です。 迅速に作成したり、必要に応じて、環境を停止します。 + +- **小規模および中規模のスケーラビリティが必要な**: シナリオでは、実稼働環境の仮想マシンの 2 回だけを必要があります、Vm の数が少ないを管理する場合があります手頃な価格まで orchestrators と同様より高度な PaaS 環境に移動することができます。 + +- **既存の展開ツールを使用して実稼働環境**: Vm または (Puppet などのようなツール) サーバーをベア メタルに複雑な展開を行うためのツールに投資するが、内部設置型環境からを移動する可能性があります。 実稼働環境の展開の手順に最小限の変更で、クラウドに移動するには、これらのツールを使用して、Azure Vm を展開する続行する場合があります。 ただし、配置の単位として配置エクスペリエンスを向上させるために Windows コンテナーを使用します。 + +>[!div class="step-by-step"] +[前へ](when-to-deploy-windows-containers-in-your-on-premises-iaas-vm-infrastructure.md) +[次へ](when-to-deploy-windows-containers-to-azure-container-instances-ACI.md) diff --git a/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-to-service-fabric.md b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-to-service-fabric.md new file mode 100644 index 00000000000..d59442d0c2f --- /dev/null +++ b/docs/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/when-to-deploy-windows-containers-to-service-fabric.md @@ -0,0 +1,39 @@ +--- +title: Service Fabric を Windows コンテナーを展開するタイミング +description: Azure のクラウドと Windows コンテナーでの既存の .NET アプリケーションを最新化 |Service Fabric を Windows コンテナーを展開するタイミング +author: CESARDELATORRE +ms.author: wiwagn +ms.date: 04/30/2018 +ms.openlocfilehash: c41db8b37c883f9369a6b8d1f8bccbc0535f504c +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT +ms.contentlocale: ja-JP +ms.lasthandoff: 05/10/2018 +--- +# Service Fabric を Windows コンテナーを展開するタイミング + +Windows コンテナーのベースとするアプリケーションはすばやく IaaS Vm からしても、さらに移動するプラットフォームを使用する必要があります。 これは、自動の強化されたスケーラビリティと高スケーラビリティ、および展開の場合、完全な管理エクスペリエンスの大きな改善点を取得するためにアップグレード バージョン管理、ロールバック、および正常性の監視します。 Azure Service Fabric、または別のクラウド内で、Microsoft Azure クラウドはでも、オンプレミスで使用できます。 orchestrator とこれらの目標を達成することができます。 + +多くの組織を上げると、2 つの理由をコンテナーに既存のモノリシックなアプリケーションをシフトします。 + +- コストの削減、統合および既存のハードウェア、または高密度で実行中のアプリケーションからの削除が原因のいずれか。 + +- 開発と操作の間で一貫性のある展開コントラクト。 + +わかりやすく、コストの削減を追求していますのすべての組織がその目標を追跡がある可能性があります。 一貫性のある展開は、評価が困難が重要と同様にします。 一貫性のある展開のコントラクトを通知の開発者が自由に、それらに適したテクノロジを使用する選択でき、運用チームは、単一の方法でアプリケーションを展開および管理を取得します。 本ライセンス条項は、多数のさまざまなテクノロジの複雑さを処理する操作、または強制的に特定のテクノロジでのみ機能する開発者による損害を軽減します。 基本的には、各アプリケーションは自己完結型の展開イメージのコンテナーです。 + +一部の組織は、刷新 microservices (クラウド ネイティブ アプリケーション) を追加することで続行されますが、その他の多くの組織はここで停止 (アプリケーションをクラウドに最適化された)。 図 4-8 に示すように、する必要がある可能性がありますいないために、これらの組織が microservices アーキテクチャを移動しません。 いずれの場合は、既に取得したことコンテナー plus Service Fabric を使用して、展開を含む完全な管理を提供、エクスペリエンスのアップグレードの利点があります、バージョン管理、ロールバック、および正常性の監視します。 + +> ![リフト アンド シフト Service Fabric アプリケーション](./media/image8.png) +> +> **図 4-8 です。** リフト アンド シフト Service Fabric アプリケーション + +Service Fabric するキーの方法は、既存のコードを再利用し、リフト アンド シフトします。 そのため、Windows コンテナーを使用して、現在の .NET Framework アプリケーションを移行し、Service Fabric に展開できます。 移動を刷新、最終的には、新しい microservices を追加することで維持しやすくなります。 + +Service Fabric を他の orchestrators を比較するときに、Service Fabric は Windows ベースのアプリケーションとサービスの実行で完成度の高いことを強調表示する必要があります。 Service Fabric が実行されている Windows ベースのサービスとアプリケーション、長年にわたって 1 層、ミッション クリティカルな Microsoft 製品を含むです。 Windows コンテナーの一般提供を持つ最初の orchestrator がありました。 Kubernetes、DC/OS では、Docker Swarm などの他のコンテナーは、Service Fabric の Windows ベースのアプリケーションと Windows コンテナーのよりも小さい完成度の高いが Linux では、完成です。 + +Service Fabric の最終的な目標 microservices のアプローチを使用したアプリケーション構築の複雑な作業を削減することができます。 最終的にする、microservices コストのかかる再設計を避けるために、アプリケーションの特定の種類。 ことができます小規模、拡張必要なときに、サービスを非推奨、新しいサービスは、追加、およびお客様による使用を使用してアプリケーションを展開します。 ほとんどの開発者にとって microservices をよりわかりやすく行うを解決するのには、まだ他の多くの問題があります。 現在は先ほどを持ち上げるし、Windows コンテナーでアプリケーションをシフト、将来のコンテナーに基づく microservices を追加しようと考えている場合は、Service Fabric sweet スポットです。 + +>[!div class="step-by-step"] +[前へ](when-to-deploy-windows-containers-to-azure-vms-iaas-cloud.md) +[次へ](when-to-deploy-windows-containers-to-azure-container-service-kubernetes.md) diff --git a/docs/standard/modernize-with-azure-and-containers/walkthroughs-technical-get-started-overview.md b/docs/standard/modernize-with-azure-and-containers/walkthroughs-technical-get-started-overview.md index a7389b9669a..aad10378809 100644 --- a/docs/standard/modernize-with-azure-and-containers/walkthroughs-technical-get-started-overview.md +++ b/docs/standard/modernize-with-azure-and-containers/walkthroughs-technical-get-started-overview.md @@ -3,12 +3,12 @@ title: チュートリアルと技術は、開始の概要を取得します。 description: Azure のクラウドと Windows コンテナーの既存の .NET アプリケーションを最新化 |チュートリアルと技術は、開始の概要を取得します。 author: CESARDELATORRE ms.author: wiwagn -ms.date: 10/26/2017 -ms.openlocfilehash: b41fe9e8b492b1348cc5615f6254d5fd3ddebf25 -ms.sourcegitcommit: 3d5d33f384eeba41b2dff79d096f47ccc8d8f03d -ms.translationtype: HT +ms.date: 04/28/2018 +ms.openlocfilehash: 27de9d1c5475855a22f2d8a3518982605277f6d9 +ms.sourcegitcommit: 88f251b08bf0718ce119f3d7302f514b74895038 +ms.translationtype: MT ms.contentlocale: ja-JP -ms.lasthandoff: 05/04/2018 +ms.lasthandoff: 05/10/2018 --- # チュートリアルと技術は、開始の概要を取得します。 @@ -22,9 +22,11 @@ ms.lasthandoff: 05/04/2018 次のチュートリアルの各アプリケーションを使用して、新しいサンプル eShopLegacy と eShopModernizing で GitHub で利用可能である[ https://github.com/dotnet-architecture/eShopModernizing](https://github.com/dotnet-architecture/eShopModernizing)です。 -- **EShop レガシ アプリケーションのツアー** +- **EShop レガシ アプリ (基準の最新化) のツアー** -- **Windows コンテナーで、既存の .NET アプリケーションを containerize します。** +- **Windows コンテナーで (WebForms & MVC) 既存の ASP.NET web アプリを containerize します。** + +- **Windows コンテナーで既存の WCF サービス (N 層アプリケーション) を containerize します。** - **Azure Vm を Windows コンテナー ベースのアプリを展開します。** @@ -32,59 +34,61 @@ ms.lasthandoff: 05/04/2018 - **Azure Service Fabric に Windows コンテナー ベースのアプリを展開します。** + ## EShop レガシ アプリケーションのチュートリアル 1: ツアー ### 技術的なチュートリアルの可用性 技術的なチュートリアルは、eShopModernizing GitHub リポジトリの wiki で入手できます。 -[https://github.com/dotnet-architecture/eShopModernizing/wiki/01.-Tour-on-eShopModernizing-apps-implementation-code](https://github.com/dotnet-architecture/eShopModernizing/wiki/01.-Tour-on-eShopModernizing-apps-implementation-code) +[eShopModernizing wiki チュートリアル](https://github.com/dotnet-architecture/eShopModernizing/wiki) + ### 概要 -このチュートリアルでは、次の 2 つのサンプルのレガシ アプリケーションの最初の実装を調べることができます。 両方のサンプル アプリは、モノリシックのアーキテクチャを持ち、従来の ASP.NET を使用して作成されました。 1 つのアプリケーションが ASP.NET に基づく 4.x MVC です。2 番目のアプリケーションは、ASP.NET 4.x Web フォームに基づいています。 両方のアプリケーションが、 [GitHub リポジトリの eShopModernizing](https://github.com/dotnet-architecture/eShopModernizing)です。 +このチュートリアルでは、次の 3 つのサンプルのレガシ アプリケーションの最初の実装を調べることができます。 最初の 2 つのサンプル web アプリケーションは、単体のアーキテクチャを持ち、従来の ASP.NET を使用して作成されました。 1 つのアプリケーションが ASP.NET に基づく 4.x MVC です。2 番目のアプリケーションは、ASP.NET 4.x Web フォームに基づいています。 3 番目のアプリはクライアント WinForms アプリケーションとサーバー側で構成される 3 層アプリ[Windows Communication Foundation (WCF)](../../framework/wcf/whats-wcf.md)サービス。 -両方のサンプル アプリを containerize すると同様の方法を containerize するクラシック[Windows Communication Foundation](../../framework/wcf/whats-wcf.md)をデスクトップ アプリケーションとして使用する (WCF) アプリケーションです。 例については、次を参照してください。 [eShopModernizingWCFWinForms](https://github.com/dotnet-architecture/eShopModernizingWCFWinForms)です。 +これらすべてのアプリケーションは、 [GitHub リポジトリの eShopModernizing](https://github.com/dotnet-architecture/eShopModernizing)です。 ### 目的 このチュートリアルの主な目的は、これらのアプリとそのコードおよび構成について理解するだけです。 テスト目的で SQL データベースを使用せず、モック データを使用して、生成されるように、アプリを構成することができます。 このオプションの構成は、分離された方法で依存関係の挿入に基づいています。 -### シナリオ +### シナリオ 1: ASP.NET Web アプリ -図 5-1 は、元のレガシ アプリケーションの簡単なシナリオを示しています。 +次の図は、元のレガシ ASP.NET web アプリケーションの簡単なシナリオを示します。 -> ![元のレガシ アプリケーションのシナリオを単純なアーキテクチャ](./media/image5-1.png) +> ![元のレガシ ASP.NET web アプリケーションのシナリオを単純なアーキテクチャ](./media/image5-1.png) > -> **図 5-1** 元のレガシ アプリケーションのシナリオを単純なアーキテクチャ -ビジネス ドメインの観点から両方のアプリは管理機能に同じカタログを提供します。 EShop エンタープライズ チームのメンバーは表示および製品カタログを編集するアプリを使用します。 図 5-2 は、最初のアプリのスクリーン ショットを示しています。 +ビジネス ドメインの観点から両方のアプリは管理機能に同じカタログを提供します。 EShop エンタープライズ チームのメンバーは表示および製品カタログを編集するアプリを使用します。 + +次の図は、最初のアプリのスクリーン ショットを示します。 ![ASP.NET MVC と ASP.NET Web フォーム アプリケーション (既存の/レガシ テクノロジ)](./media/image5-2.png) -> **図 5-2** ASP.NET MVC と ASP.NET Web フォーム アプリケーション (既存の/レガシ テクノロジ) +依存関係 ASP.NET 4.x か (いずれかの MVC または Web フォームの) 以前のバージョンは、コードが ASP.NET Core MVC を使用して、完全に記述し直すされない限り、これらのアプリケーションを .NET Core で実行されないことです。 -これらは、参照およびカタログのエントリを変更するために使用する web アプリケーションです。 両方のアプリが同じビジネス/機能の機能を提供するファクトは単に比較のためです。 ASP.NET MVC と ASP.NET Web フォームのフレームワークを使用して作成されたアプリのような近代化プロセスを表示できます。 +### シナリオ 2: WCF サービスと WinForms クライアント アプリ (アプリが 3 層) -依存関係 ASP.NET 4.x か (いずれかの MVC または Web フォームの) 以前のバージョンは、コードが ASP.NET Core MVC を使用して、完全に記述し直すされない限り、これらのアプリケーションを .NET Core で実行されないことです。 これは、ポイントを再構築、またはコードを書き換えるにしない場合することができます、既存のアプリケーションを containerize もを使用して同じ .NET テクノロジと、同じコードを示しています。 コンテナーでは、レガシ コードを変更することがなくこのようなアプリケーションを実行する方法を確認できます。 +次の図は、元の 3 層のレガシ アプリケーションの簡単なシナリオを示します。 + +> ![WCF サービスと元レガシ 3 層アプリケーションおよび WinForms クライアント アプリのシナリオを単純なアーキテクチャ](./media/image5-1.5.png) +> ### 利点 -このチュートリアルのメリットは、単純な: だけに慣れれば、コードとアプリケーションの構成、依存関係の挿入に基づいています。 その後、containerize および今後の複数の環境に展開するときに、この方法で試すことができます。 +このチュートリアルのメリットは、単純な: コードと最初のアプリに精通して表示します。 ### 次の手順 GitHub wiki 上には、このコンテンツをさらに詳しい情報を表示します。 -[https://github.com/dotnet-architecture/eShopModernizing/wiki/01.-Tour-on-eShopModernizing-apps-implementation-code](https://github.com/dotnet-architecture/eShopModernizing/wiki/01.-Tour-on-eShopModernizing-apps-implementation-code) + - [ASP.NET MVC のベースラインをツアーと Web フォーム「レガシ」アプリ](https://github.com/dotnet-architecture/eShopModernizing/wiki/01.-Tour-on-the-ASP.NET-MVC-and-WebForms-apps-implementation-code) + - [WCF サービスの基準と WinForms (3 層)「レガシ」アプリのツアー](https://github.com/dotnet-architecture/eShopModernizing/wiki/21.-Tour-on-the-WCF-service-and-WinForms-apps) -## チュートリアル 2: Windows コンテナーで、既存の .NET アプリケーションを Containerize します。 -### 技術的なチュートリアルの可用性 - -技術的なチュートリアルは、eShopModernizing GitHub リポジトリの wiki で入手できます。 - -[https://github.com/dotnet-architecture/eShopModernizing/wiki/02.-How-to-containerize-the-.NET-Framework-web-apps-with-Windows-Containers-and-Docker](https://github.com/dotnet-architecture/eShopModernizing/wiki/02.-How-to-containerize-the-.NET-Framework-web-apps-with-Windows-Containers-and-Docker) +## チュートリアル 2: Windows コンテナーで、既存の .NET アプリケーションを Containerize します。 ### 概要 @@ -102,13 +106,20 @@ Windows コンテナーの MVC、Web フォーム、または WCF、運用、開 このチュートリアルは、Docker 方法は、Visual Studio 2017 ツールに焦点を当てていますが、他の 2 つのアプローチが Dockerfile を使用してに関して類似しています。 -### シナリオ +### シナリオ 1: コンテナーの ASP.NET web アプリ + +次の図は、コンテナー化 eShop レガシ web アプリのアプリケーションのシナリオを示します。 -図 5-3 は、コンテナー化 eShop レガシ アプリケーションのシナリオを示しています。 +> ![開発環境での ASP.NET アプリケーションのコンテナーの簡略化されたアーキテクチャ図](./media/image5-3.png) +> + + +### シナリオ 2: コンテナーの WCF サービス + +次の図は、コンテナー化の WCF サービスと 3 層アプリケーションのシナリオを示します。 -> ![開発環境でのコンテナー化アプリケーションの簡略化されたアーキテクチャ図](./media/image5-3.png) +> ![開発環境でのコンテナー化の WCF サービスのアーキテクチャ図を簡素化されます。](./media/image5-3.5.png) > -> **図 5-3** 開発環境でのコンテナー化アプリケーションの簡略化されたアーキテクチャ図 ### 利点 @@ -122,15 +133,18 @@ Windows コンテナーの MVC、Web フォーム、または WCF、運用、開 ### 次の手順 -GitHub wiki 上には、このコンテンツをさらに詳しい情報を表示します。 [https://github.com/dotnet-architecture/eShopModernizing/wiki/02.-How-to-containerize-the-.NET-Framework-web-apps-with-Windows-Containers-and-Docker](https://github.com/dotnet-architecture/eShopModernizing/wiki/02.-How-to-containerize-the-.NET-Framework-web-apps-with-Windows-Containers-and-Docker) +GitHub wiki 上には、このコンテンツをさらに詳しい情報を表示します。 + + - [Windows コンテナーと Docker で .NET Framework の web アプリを containerize する方法](https://github.com/dotnet-architecture/eShopModernizing/wiki/02.-How-to-containerize-the-.NET-Framework-web-apps-with-Windows-Containers-and-Docker) + - [WCF サービスに Docker のサポートを追加します。](https://github.com/dotnet-architecture/eShopModernizing/wiki/22.-Adding-Docker-Support) + + ## チュートリアル 3: Azure Vm を Windows コンテナー ベースのアプリを展開します。 ### 技術的なチュートリアルの可用性 -技術的なチュートリアルは、eShopModernizing GitHub リポジトリの wiki で入手できます。 - -[https://github.com/dotnet-architecture/eShopModernizing/wiki/03.-How-to-deploy-your-Windows-Containers-based-app-into-Azure-VMs-(Including-CI-CD)](https://github.com/dotnet-architecture/eShopModernizing/wiki/03.-How-to-deploy-your-Windows-Containers-based-app-into-Azure-VMs-(Including-CI-CD)) +技術的なチュートリアルは、eShopModernizing GitHub リポジトリの wiki で入手できます。 [https://github.com/dotnet-architecture/eShopModernizing/wiki/03.-How-to-deploy-your-Windows-Containers-based-app-into-Azure-VMs-(Including-CI-CD)](https://github.com/dotnet-architecture/eShopModernizing/wiki/03.-How-to-deploy-your-Windows-Containers-based-app-into-Azure-VMs-(Including-CI-CD)) ### 概要 @@ -178,7 +192,46 @@ GitHub wiki 上には、このコンテンツをさらに詳しい情報を表 [https://github.com/dotnet-architecture/eShopModernizing/wiki/03.-How-to-deploy-your-Windows-Containers-based-app-into-Azure-VMs-(Including-CI-CD)](https://github.com/dotnet-architecture/eShopModernizing/wiki/03.-How-to-deploy-your-Windows-Containers-based-app-into-Azure-VMs-(Including-CI-CD)) -## チュートリアル 4: Azure のコンテナー サービスで Kubernetes に Windows コンテナー ベースのアプリを展開します。 +## チュートリアル 4: Azure のコンテナー インスタンス (ACI) に Windows コンテナー ベースのアプリを展開します。 + +### 技術的なチュートリアルの可用性 + +技術的なチュートリアルは、eShopModernizing GitHub リポジトリの wiki で入手できます。 + +[ACI (Azure のコンテナー インスタンス) に、アプリを展開します。](https://github.com/dotnet-architecture/eShopModernizing/wiki/05.-Deploying-the-Apps-to-ACI-(Azure-Container-Instances)) + +### 概要 + +[Azure コンテナー インスタンス (ACI)](https://docs.microsoft.com/en-us/azure/container-instances/)コンテナーの単一のインスタンスを展開するコンテナー開発/テスト/ステージング環境がある最も簡単な方法です。 + +### 目的 + +このチュートリアルは、主なシナリオ Azure コンテナー インスタンス (ACI) と ACI に eShopModernizing アプリを展開する方法に Windows コンテナーを展開するときにします。 + +### シナリオ + +1 つまたはすべて (MVC アプリ、web フォーム アプリケーションまたは WCF サービス) のアプリの展開など ACI に eShopModernizing アプリの展開のバリエーションがあります。 次に示す次のシナリオでことができます、コンテナーとして ACI (Azure のコンテナー インスタンス) に ASP.NET MVC アプリケーションと、これらの両方に展開されている SQL Server のコンテナーを参照します。 + +![開発環境から ACI を展開します。](./media/image5-3.5.6.png) + +### 利点 + +Azure のコンテナー インスタンスでは、簡単に作成し、仮想マシンをプロビジョニングまたは高レベルのサービスを採用することがなく、Azure では、Docker コンテナーを管理します。 ACI で直接 Azure での Windows コンテナーを展開してへの公開インターネット完全修飾ドメイン名 (FQDN) を数秒で (Docker Hub または Azure コンテナーのように Docker レジストリで準備ができて、Windows コンテナー イメージがある場合にレジストリ)。 + +### 注意事項 + +いずれか完全な .NET Framework による Windows コンテナーを展開する/ASP.NET または SQL Server には、Azure コンテナー インスタンス (ACI) が Docker イメージに存在するために (Windows コンテナーでの Windows Server 2016) のような通常の Docker ホストに展開すると非常に高速ではありませんたびに (プル Docker レジストリから) ダウンロードし、SQL コンテナー イメージ (15.1 GB) と ASP.NET のコンテナーのイメージ (13.9 GB) のサイズは大幅に大きなただし、これは、独自の docker ホスト (永続的にオンラインを維持することよりはるかに低コストAzure で Windows コンテナーの VM で Windows Server 2016) であり、その一方で、運用環境の配置の優れた選択肢 (AKS/ACS) を Azure または Azure Service Fabric で Kubernetes と同様に全体の orchestrator を言うまでもありません。 + +メイン最後に、としては、Azure コンテナー インスタンスを使用して開発およびテスト シナリオの場合とパイプラインの CI/CD に非常に説得力のあるオプション。 + +## 次の手順 + +GitHub wiki 上には、このコンテンツをさらに詳しい情報を表示します。 + +[https://github.com/dotnet-architecture/eShopModernizing/wiki/05.-Deploying-the-Apps-to-ACI-(Azure-Container-Instances)](https://github.com/dotnet-architecture/eShopModernizing/wiki/05.-Deploying-the-Apps-to-ACI-(Azure-Container-Instances)TBD) + + +## チュートリアル 5: Azure のコンテナー サービスで Kubernetes に Windows コンテナー ベースのアプリを展開します。 ### 技術的なチュートリアルの可用性 @@ -238,7 +291,7 @@ Kubernetes と開発者は他のユーザー間で、次の機能を容易にす GitHub wiki 上には、このコンテンツをさらに詳しい情報を表示します。 [https://github.com/dotnet-architecture/eShopModernizing/wiki/04.-How-to-deploy-your-Windows-Containers-based-apps-into-Kubernetes-in-Azure-Container-Service-(Including-C-CD)](https://github.com/dotnet-architecture/eShopModernizing/wiki/04.-How-to-deploy-your-Windows-Containers-based-apps-into-Kubernetes-in-Azure-Container-Service-(Including-C-CD)) -## チュートリアル 5: Azure Service Fabric を Windows コンテナー ベースのアプリを展開します。 +## チュートリアル 6: Azure Service Fabric を Windows コンテナー ベースのアプリを展開します。 ### 技術的なチュートリアルの可用性