ステージング 環境。 ステージング環境とは?構築の際に気を付けるべき点を解説!|ITトレンド

さくらのバックアップ&ステージング機能の使い方(Snapup)

ステージング 環境

Azure App Service でステージング環境を設定する Set up staging environments in Azure App Service• この記事の内容 実行している App Service プランのサービス レベルが Standard、 Premium、または Isolated である場合は、Web アプリ、Linux 上の Web アプリ、モバイル バック エンド、または API アプリを にデプロイするときに、既定の運用スロットではなく別個のデプロイ スロットを使用できます。 When you deploy your web app, web app on Linux, mobile back end, or API app to , you can use a separate deployment slot instead of the default production slot when you're running in the Standard, Premium, or Isolated App Service plan tier. デプロイ スロットは、固有のホスト名を持つライブ アプリです。 Deployment slots are live apps with their own host names. アプリのコンテンツと構成の各要素は、 運用スロットを含む 2 つのデプロイ スロットの間でスワップすることができます。 App content and configurations elements can be swapped between two deployment slots, including the production slot. 非運用スロットにアプリケーションをデプロイすることには、次のメリットがあります。 Deploying your application to a non-production slot has the following benefits:• ステージング デプロイ スロットでアプリの変更を検証した後に、運用スロットにスワップできます。 You can validate app changes in a staging deployment slot before swapping it with the production slot. スロットにアプリをデプロイした後に運用サイトにスワップすると、運用サイトへのスワップ前にスロットのすべてのインスタンスが準備されます。 Deploying an app to a slot first and swapping it into production makes sure that all instances of the slot are warmed up before being swapped into production. これにより、アプリをデプロイする際のダウンタイムがなくなります。 This eliminates downtime when you deploy your app. トラフィックのリダイレクトはシームレスであるため、スワップ操作によって破棄される要求はありません。 The traffic redirection is seamless, and no requests are dropped because of swap operations. スワップ前の検証が必要ない場合は、を構成することで、このワークフロー全体を自動化できます。 You can automate this entire workflow by configuring when pre-swap validation isn't needed. スワップ後も、以前のステージング アプリ スロットに元の運用アプリが残っているため、 After a swap, the slot with previously staged app now has the previous production app. 運用スロットにスワップした変更が想定どおりでない場合は、適切な動作が確認されている元のサイトにすぐに戻すことができます。 If the changes swapped into the production slot aren't as you expect, you can perform the same swap immediately to get your "last known good site" back. サポートされるデプロイ スロット数は、App Service プラン レベルごとに異なります。 Each App Service plan tier supports a different number of deployment slots. デプロイ スロットは追加料金なしでご利用いただけます。 There's no additional charge for using deployment slots. 使用しているアプリのサービス レベルでサポートされるスロット数を確認するには、「」をご覧ください。 To find out the number of slots your app's tier supports, see. アプリを別のサービス レベルにスケールするには、アプリが既に使用しているスロット数がターゲット レベルによってサポートされていることを確認します。 To scale your app to a different tier, make sure that the target tier supports the number of slots your app already uses. たとえば、 Standard レベルではサポートされるデプロイ スロット数は 5 つのみなので、アプリのスロット数が 5 つより多い場合は、 Standard レベルにスケール ダウンできません。 For example, if your app has more than five slots, you can't scale it down to the Standard tier, because the Standard tier supports only five deployment slots. スロットを追加する Add a slot 複数のデプロイ スロットを有効にするには、アプリが Standard、 Premium、 Isolated のいずれかのレベルで実行されている必要があります。 The app must be running in the Standard, Premium, or Isolated tier in order for you to enable multiple deployment slots. で、 [App Services] を探して選択し、アプリを選択します。 in the , search for and select App Services and select your app. 注意 アプリのサービス レベルがまだ Standard、 Premium、または Isolated でない場合は、ステージングされた発行を有効にすることがサポートされているレベルを示すメッセージが表示されます。 If the app isn't already in the Standard, Premium, or Isolated tier, you receive a message that indicates the supported tiers for enabling staged publishing. この時点で、操作を続行する前に、 [アップグレード] を選択してアプリの [スケール] タブに移動するオプションが用意されています。 At this point, you have the option to select Upgrade and go to the Scale tab of your app before continuing. [スロットの追加] ダイアログ ボックスで、スロット名を指定し、別のデプロイ スロットからアプリ構成を複製するかどうかを選択します。 In the Add a slot dialog box, give the slot a name, and select whether to clone an app configuration from another deployment slot. [追加] を選択して続行します。 Select Add to continue. 構成は、既存のどのスロットからも複製できます。 You can clone a configuration from any existing slot. 複製できる設定には、アプリの設定、接続文字列、言語フレームワークのバージョン、Web ソケット、HTTP のバージョン、プラットフォームのビット数などがあります。 Settings that can be cloned include app settings, connection strings, language framework versions, web sockets, HTTP version, and platform bitness. スロットを追加した後、 [閉じる] を選択してダイアログ ボックスを閉じます。 After the slot is added, select Close to close the dialog box. これで新しいスロットが [デプロイ スロット] ページに表示されます。 The new slot is now shown on the Deployment slots page. 新しいデプロイ スロットを選択して、そのスロットのリソース ページを開きます。 Select the new deployment slot to open that slot's resource page. ステージング スロットには、他の App Service アプリと同様に管理ページがあります。 The staging slot has a management page just like any other App Service app. スロットの構成を変更することができます。 You can change the slot's configuration. また、同じ指定先を使用して、リソース グループ内の別のアプリとしてスロットを表示することもできます。 You can also see the slot as a separate app in your resource group, with the same designations. スロットのリソース ページで、アプリの URL を選択します。 Select the app URL on the slot's resource page. デプロイ スロットは独自のホスト名を持ち、ライブ アプリでもあります。 The deployment slot has its own host name and is also a live app. デプロイ スロットへのパブリック アクセスを制限するには、に関するページをご覧ください。 To limit public access to the deployment slot, see. 別のスロットから設定を複製した場合でも、新しいデプロイ スロットには内容がありません。 The new deployment slot has no content, even if you clone the settings from a different slot. たとえば、ことができます。 For example, you can. スロットには、異なるリポジトリ分岐、または異なるリポジトリからデプロイできます。 You can deploy to the slot from a different repository branch or a different repository. スワップ中の動作 What happens during a swap スワップ操作の手順 Swap operation steps 2 つのスロットを 通常はステージング スロットから運用スロットに スワップするときには、ターゲット スロットでダウンタイムが発生しないようにするため、App Service が以下のことを行います。 When you swap two slots usually from a staging slot into the production slot , App Service does the following to ensure that the target slot doesn't experience downtime:• ターゲット スロット たとえば運用スロット からソース スロットのすべてのインスタンスに対して、以下の設定を適用します。 Apply the following settings from the target slot for example, the production slot to all instances of the source slot:• のアプリ設定と接続文字列 該当する場合。 app settings and connection strings, if applicable. の設定 有効になっている場合。 settings, if enabled. の設定 有効になっている場合。 settings, if enabled. これらのどの場合も、ソース スロット内のすべてのインスタンスがトリガーされます。 Any of these cases trigger all instances in the source slot to restart. 時には、これは最初のフェーズが終了したことを示します。 During , this marks the end of the first phase. スワップ操作が一時停止されると、ソース スロットが、ターゲット スロットの設定で正しく動作していることを検証できます。 The swap operation is paused, and you can validate that the source slot works correctly with the target slot's settings. ソース スロット内のすべてのインスタンスが再起動を完了するまで待機します。 Wait for every instance in the source slot to complete its restart. いずれかのインスタンスが再起動に失敗した場合、スワップ操作ではすべての変更がソース スロットに戻されて、操作が停止されます。 If any instance fails to restart, the swap operation reverts all changes to the source slot and stops the operation. 各インスタンスが何らかの HTTP 応答を返すまで待機します。 Wait until each instance returns any HTTP response. ローカル キャッシュの初期化により、各インスタンスでもう一度再起動が発生します。 Local cache initialization causes another restart on each instance. applicationInitialization が指定されていない場合は、各インスタンスのソース スロットのアプリケーション ルートへの HTTP 要求をトリガーします。 If applicationInitialization isn't specified, trigger an HTTP request to the application root of the source slot on each instance. インスタンスが任意の HTTP 応答を返すと、ウォームアップされたと見なされます。 If an instance returns any HTTP response, it's considered to be warmed up. ソース スロットのすべてのインスタンスが正常にウォームアップされたら、2 つのスロットのルーティング規則を入れ換えることで 2 つのスロットをスワップします。 If all instances on the source slot are warmed up successfully, swap the two slots by switching the routing rules for the two slots. この手順の後は、前にソース スロットでウォーム アップされたアプリはターゲット スロット 運用スロットなど に存在します。 After this step, the target slot for example, the production slot has the app that's previously warmed up in the source slot. この時点でソース スロットには、スワップ以前にはターゲット スロットにあったアプリがあるため、すべての設定を適用してインスタンスを再起動することで、同じ操作を実行します。 Now that the source slot has the pre-swap app previously in the target slot, perform the same operation by applying all settings and restarting the instances. スワップ操作のどの時点でも、スワップされるアプリを初期化するすべての作業はソース スロットで発生しています。 At any point of the swap operation, all work of initializing the swapped apps happens on the source slot. ソース スロットが準備され、ウォームアップされている間、スワップがどこで成功するか失敗するかに関わらず、ターゲット スロットはオンライン状態に留まります。 The target slot remains online while the source slot is being prepared and warmed up, regardless of where the swap succeeds or fails. ステージング スロットと運用スロットを入れ換える場合は常に、運用スロットがターゲット スロットであるようにします。 To swap a staging slot with the production slot, make sure that the production slot is always the target slot. こうすることで、スワップ操作が運用アプリに影響を及ぼしません。 This way, the swap operation doesn't affect your production app. スワップされる設定 Which settings are swapped? 別のデプロイ スロットから構成を複製する場合、複製された構成を編集することができます。 When you clone configuration from another deployment slot, the cloned configuration is editable. 構成要素には、スワップを経ても内容が反映される スロット固有でない ものもあれば、スワップ後に同じスロットに残されている スロット固有の ものもあります。 Some configuration elements follow the content across a swap not slot specific , whereas other configuration elements stay in the same slot after a swap slot specific. 次の一覧では、スロットのスワップ時に変更される設定を示します。 The following lists show the settings that change when you swap slots. スワップされる設定: Settings that are swapped:• アプリ設定 スロット固有として構成可能 App settings can be configured to stick to a slot• 接続文字列 スロット固有として構成可能 Connection strings can be configured to stick to a slot• ハンドラー マッピング Handler mappings• パブリック証明書 Public certificates• Web ジョブ コンテンツ WebJobs content• スワップされない設定: Settings that aren't swapped:• 発行エンドポイント Publishing endpoints• カスタム ドメイン名 Custom domain names• スケールの設定 Scale settings• Web ジョブ スケジューラ WebJobs schedulers• IP 制限 IP restrictions• 常時接続 Always On• 診断設定 Diagnostic settings• クロスオリジン リソース共有 CORS Cross-origin resource sharing CORS 注意 スワップされていない設定に適用されている特定のアプリ設定もスワップされません。 Certain app settings that apply to unswapped settings are also not swapped. これは、スロット設定として表示されない場合でも同様です。 特定のスロットに固有の スワップされない アプリ設定や接続文字列を構成するには、そのスロットの [構成] ページに移動します。 To configure an app setting or connection string to stick to a specific slot not swapped , go to the Configuration page for that slot. 設定を追加または編集し、 [deployment slot setting] スロット設定のデプロイ を選択します。 Add or edit a setting, and then select deployment slot setting. このチェック ボックスを選択して、設定がスワップ可能ではないことを App Service に指示します。 Selecting this check box tells App Service that the setting is not swappable. 2 つのスロットをスワップする Swap two slots アプリの [デプロイ スロット] ページと [概要] ページで、デプロイ スロットをスワップできます。 You can swap deployment slots on your app's Deployment slots page and the Overview page. スロットのスワップに関する技術的詳細については、「」を参照してください。 For technical details on the slot swap, see. 重要 アプリをデプロイ スロットから運用環境にスワップする前に、運用環境がターゲット スロットになっていること、およびソース スロットのすべての設定が、運用環境に反映させたい内容で正確に構成されていることを確認してください。 Before you swap an app from a deployment slot into production, make sure that production is your target slot and that all settings in the source slot are configured exactly as you want to have them in production. デプロイ スロットをスワップするには: To swap deployment slots:• アプリの [デプロイ スロット] ページに移動し、 [スワップ] を選択します。 Go to your app's Deployment slots page and select Swap. [スワップ] ダイアログ ボックスに、選択したソース スロットとターゲット スロットの変更される設定が表示されます。 The Swap dialog box shows settings in the selected source and target slots that will be changed. 目的の [ソース] および [ターゲット] スロットを選択します。 Select the desired Source and Target slots. 通常、ターゲットは運用スロットになります。 Usually, the target is the production slot. また、 [ソースの変更] タブと [ターゲットの変更] タブを選択して、構成の変更が予定されてることを確認します。 Also, select the Source Changes and Target Changes tabs and verify that the configuration changes are expected. 完了したら、 [スワップ] を選択することで直ちにスロットをスワップできます。 When you're finished, you can swap the slots immediately by selecting Swap. スワップを実際に行う前に、新しい設定でのターゲット スロットの動作を確認するには、 [スワップ] を選択しないで、「」の指示に従います。 To see how your target slot would run with the new settings before the swap actually happens, don't select Swap, but follow the instructions in. 完了したら、 [閉じる] を選択してダイアログ ボックスを閉じます。 When you're finished, close the dialog box by selecting Close. 問題がある場合は、「」を参照してください。 If you have any problems, see. プレビューでのスワップ 複数フェーズのスワップ Swap with preview multi-phase swap ターゲット スロットとしての運用環境にスワップする前に、スワップ後の設定でアプリの実行を検証します。 Before you swap into production as the target slot, validate that the app runs with the swapped settings. ソース スロットは、スワップの完了前にウォームアップもされているため、ミッション クリティカルなアプリケーションに適しています。 The source slot is also warmed up before the swap completion, which is desirable for mission-critical applications. プレビューでのスワップを実行すると、App Service は同じを実行しますが、最初の手順の後に、一時停止します。 When you perform a swap with preview, App Service performs the same but pauses after the first step. その後、スワップを完了する前にステージング スロットでの結果を検証できます。 You can then verify the result on the staging slot before completing the swap. スワップをキャンセルすると、構成要素がソース スロットに再適用されます。 If you cancel the swap, App Service reapplies configuration elements to the source slot. プレビューでのスワップを行うには: To swap with preview:• 「」の手順に従いますが、 [プレビューでスワップを実行] を選択します。 Follow the steps in but select Perform swap with preview. ダイアログ ボックスに、フェーズ 1 でソース スロットの構成がどのように変わり、フェーズ 2 でソース スロットとターゲット スロットがどのように変わるかが表示されます。 The dialog box shows you how the configuration in the source slot changes in phase 1, and how the source and target slot change in phase 2. スワップを開始する準備ができたら、 [スワップの開始] を選択します。 When you're ready to start the swap, select Start Swap. フェーズ 1 が終了すると、ダイアログ ボックスで通知されます。 When phase 1 finishes, you're notified in the dialog box. azurewebsites. net に移動して、ソース スロットでのスワップをプレビューします。 azurewebsites. net. 保留中のスワップを完了する準備ができたら、 [スワップ アクション] で [スワップの完了] を選択し、 [スワップの完了] を選択します。 When you're ready to complete the pending swap, select Complete Swap in Swap action and select Complete Swap. 保留中のスワップを取り消すには、代わりに [スワップの取り消し] を選択します。 To cancel a pending swap, select Cancel Swap instead. 完了したら、 [閉じる] を選択してダイアログ ボックスを閉じます。 When you're finished, close the dialog box by selecting Close. 問題がある場合は、「」を参照してください。 If you have any problems, see. 複数フェーズのスワップを自動化するには、「」をご覧ください。 To automate a multi-phase swap, see. スワップをロールバックする Roll back a swap スロットのスワップ後にターゲット スロット 運用スロットなど でエラーが発生する場合は、同じ 2 つのスロットをすぐにスワップして、スロットをスワップ前の状態に復元します。 If any errors occur in the target slot for example, the production slot after a slot swap, restore the slots to their pre-swap states by swapping the same two slots immediately. 自動スワップを構成する Configure auto swap 注意 自動スワップは、Linux 上の Web アプリではサポートされていません。 Auto swap isn't supported in web apps on Linux. 自動スワップを使うと、アプリのユーザーにコールド スタートを課したりダウンタイムを生じさせたりすることなく、アプリを連続的にデプロイする効率的な Azure DevOps シナリオを実現できます。 Auto swap streamlines Azure DevOps scenarios where you want to deploy your app continuously with zero cold starts and zero downtime for customers of the app. あるスロットから運用環境への自動スワップが有効になっていると、コードの変更をそのスロットにプッシュするたびに、ソース スロットでウォームアップされた後、App Service によって自動的に、されます。 When auto swap is enabled from a slot into production, every time you push your code changes to that slot, App Service automatically after it's warmed up in the source slot. 注意 運用スロットの自動スワップを構成する前に、非運用環境のターゲット スロットで自動スワップをテストすることを検討してください。 Before you configure auto swap for the production slot, consider testing auto swap on a non-production target slot. 自動スワップを構成するには: To configure auto swap:• アプリのリソース ページに移動します。 Go to your app's resource page. [Auto swap enabled] 自動スワップ有効化 で、 [オン] を選択します。 For Auto swap enabled, select On. [Auto swap deployment slot] 自動スワップのデプロイ スロット で目的のターゲット スロットを選択し、コマンド バーで [保存] を選択します。 Then select the desired target slot for Auto swap deployment slot, and select Save on the command bar. ソース スロットへのコードのプッシュを実行します。 Execute a code push to the source slot. しばらくすると自動スワップが実行され、更新がターゲット スロットの URL に反映されます。 Auto swap happens after a short time, and the update is reflected at your target slot's URL. 問題がある場合は、「」を参照してください。 If you have any problems, see. カスタム ウォームアップを指定する Specify custom warm-up 一部のアプリでは、スワップ前のカスタム ウォームアップ アクションが必要な場合があります。 Some apps might require custom warm-up actions before the swap. web. config の applicationInitialization 構成要素を使用して、カスタム初期化アクションを指定できます。 The applicationInitialization configuration element in web. config lets you specify custom initialization actions. では、このカスタム ウォームアップの終了を待ってから、ターゲット スロットとのスワップが行われます。 The waits for this custom warm-up to finish before swapping with the target slot. 以下に、サンプルの web. config フラグメントを示します。 Here's a sample web. config fragment. applicationInitialization 要素のカスタマイズの詳細については、「」を参照してください。 For more information on customizing the applicationInitialization element, see. 次のの 1 つまたは両方を使用して、ウォームアップの動作をカスタマイズすることもできます。 You can also customize the warm-up behavior with one or both of the following :• このアプリ設定を追加するには、値としてスラッシュで始まるカスタム パスを指定します。 Add this app setting by specifying a custom path that begins with a slash as the value. HTTP コードのコンマ区切りの一覧で、このアプリ設定を追加します。 Add this app setting with a comma-separated list of HTTP codes. たとえば 200,202 とします。 An example is 200,202. 返された状態コードが一覧にない場合、ウォームアップとスワップの操作が停止されます。 If the returned status code isn't in the list, the warmup and swap operations are stopped. 既定で、すべての応答コードは有効です。 By default, all response codes are valid. 注意 構成要素は各アプリの起動に含まれますが、2 つのウォームアップの動作を行うアプリの設定はスロット スワップにのみ適用されます。 The configuration element is part of each app start-up, whereas the two warm-up behavior app settings apply only to slot swaps. 問題がある場合は、「」を参照してください。 If you have any problems, see. スワップを監視する Monitor a swap が完了するまで長い時間がかかる場合、でスワップ操作に関する情報を取得できます。 If the takes a long time to complete, you can get information on the swap operation in the. ポータルのアプリのリソース ページで、左側のウィンドウの [アクティビティ ログ] を選択します。 On your app's resource page in the portal, in the left pane, select Activity log. スワップ操作がログ クエリに Swap Web App Slots として表示されます。 A swap operation appears in the log query as Swap Web App Slots. これを展開し、副操作やエラーの 1 つを選択して詳細を表示できます。 You can expand it and select one of the suboperations or errors to see the details. azurewebsites. net に対するすべてのクライアント要求は、運用スロットにルーティングされます。 azurewebsites. net are routed to the production slot. トラフィックの一部を、別のスロットにルーティングできます。 You can route a portion of the traffic to another slot. この機能は、新しい更新についてのユーザーのフィードバックが必要であっても、運用環境にリリースできる状態ではない場合に便利です。 This feature is useful if you need user feedback for a new update, but you're not ready to release it to production. 運用トラフィックを自動的にルーティングする Route production traffic automatically 運用トラフィックを自動的にルーティングするには: To route production traffic automatically:• アプリのリソース ページに移動し、 [デプロイ スロット] を選択します。 Go to your app's resource page and select Deployment slots. [保存] を選択します。 Select Save. 設定の保存後は、指定した割合のクライアントが、非運用スロットにランダムにルーティングされます。 After the setting is saved, the specified percentage of clients is randomly routed to the non-production slot. クライアントは、特定のスロットに自動的にルーティングされると、そのクライアント セッションの有効期間中はそのスロットに "固定" されます。 After a client is automatically routed to a specific slot, it's "pinned" to that slot for the life of that client session. クライアントのブラウザーで、HTTP ヘッダー内の x-ms-routing-name Cookie を調べることにより、セッションが固定されているスロットを確認できます。 On the client browser, you can see which slot your session is pinned to by looking at the x-ms-routing-name cookie in your HTTP headers. 運用トラフィックを手動でルーティングする Route production traffic manually App Service では、トラフィックの自動ルーティングだけでなく、特定のスロットに要求をルーティングすることもできます。 In addition to automatic traffic routing, App Service can route requests to a specific slot. この方法は、ユーザーがベータ版アプリの利用を選択または拒否できるようにしたい場合に便利です。 This is useful when you want your users to be able to opt in to or opt out of your beta app. 運用トラフィックを手動でルーティングするには、 x-ms-routing-name クエリ パラメーターを使用します。 To route production traffic manually, you use the x-ms-routing-name query parameter. ベータ版アプリの利用をユーザーが拒否できるようにするには、たとえば次のようなリンクを Web ページに配置します。 To let users opt out of your beta app, for example, you can put this link on your webpage:. azurewebsites. クライアント ブラウザーは、リンクにアクセスすると、運用スロットにリダイレクトされます。 After the client browser accesses the link, it's redirected to the production slot. ベータ版アプリの利用をユーザーが選択できるようにするには、同じクエリ パラメーターを、非運用スロットの名前に設定します。 To let users opt in to your beta app, set the same query parameter to the name of the non-production slot. 次に例を示します。 Here's an example:. azurewebsites. しかし、ルーティングの割合は 0 に設定されているため、ユーザーはスロットに自動的にルーティングされません。 But they won't be routed to the slot automatically because the routing percentage is set to 0. これは、内部チームにスロットでの変更のテストを許可する一方で、ステージング スロットをパブリックから "非表示" にできる高度なシナリオです。 This is an advanced scenario where you can "hide" your staging slot from the public while allowing internal teams to test changes on the slot. スロットを削除する Delete a slot アプリを検索して選択します。 Search for and select your app. アプリの種類は App Service スロット として表示され、デプロイ スロットが表示されていることを知らせます。 The app type is shown as App Service Slot to remind you that you're viewing a deployment slot. コマンド バーの [削除] を選択します。 Select Delete on the command bar. PowerShell で自動化する Automate with PowerShell 注意 この記事は、新しい Azure PowerShell Az モジュールを使用するために更新されました。 This article has been updated to use the new Azure PowerShell Az module. AzureRM モジュールはまだ使用でき、少なくとも 2020 年 12 月までは引き続きバグ修正が行われます。 You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Az モジュールと AzureRM の互換性の詳細については、「」を参照してください。 To learn more about the new Az module and AzureRM compatibility, see. Az モジュールのインストール手順については、を参照してください。 For Az module installation instructions, see. Azure PowerShell は、Windows PowerShell から Azure を管理するためのコマンドレットを提供するモジュールです Azure App Service のデプロイ スロットを管理するためのサポートなど。 Azure PowerShell is a module that provides cmdlets to manage Azure through Windows PowerShell, including support for managing deployment slots in Azure App Service. Azure PowerShell のインストールと構成、Azure サブスクリプションを使用した Azure PowerShell の認証については、「 」を参照してください。 For information on installing and configuring Azure PowerShell, and on authenticating Azure PowerShell with your Azure subscription, see. are declarative JSON files used to automate the deployment and configuration of Azure resources. Resource Manager テンプレートを使用してスロットをスワップするには、 Microsoft. To swap slots by using Resource Manager templates, you will set two properties on the Microsoft. buildVersion: これは、スロットにデプロイされているアプリの現在のバージョンを表す文字列プロパティです。 buildVersion: this is a string property which represents the current version of the app deployed in the slot. たとえば、"v1"、"1. 1"、または "2019-09-20T11:53:25. 2887393-07:00" のようになります。 For example: "v1", "1. 1", or "2019-09-20T11:53:25. 2887393-07:00". targetBuildVersion: これは、スロットに必要な buildVersion を指定する文字列プロパティです。 targetBuildVersion: this is a string property that specifies what buildVersion the slot should have. targetBuildVersion が現在の buildVersion と等しくない場合は、指定された buildVersion を持つスロットを検索することによってスワップ操作がトリガーされます。 If the targetBuildVersion does not equal the current buildVersion, then this will trigger the swap operation by finding the slot which has the specified buildVersion. Resource Manager テンプレートの例 Example Resource Manager template 次の Resource Manager テンプレートでは、ステージング スロットの buildVersion が更新され、運用スロットで targetBuildVersion が設定されます。 The following Resource Manager template will update the buildVersion of the staging slot and set the targetBuildVersion on the production slot. これにより、2 つのスロットがスワップされます。 This will swap the two slots. このテンプレートは、"staging" という名前のスロットを持つ Web アプリが既に作成されていることを前提としています。 The template assumes you already have a webapp created with a slot named "staging". management. azure. json ", "contentVersion": "1. つまり、繰り返し実行して、スロットの同じ状態を生成することができます。 This Resource Manager template is idempotent, meaning that it can be executed repeatedly and produce the same state of the slots. 最初の実行後、 targetBuildVersion は現在の buildVersion と一致するため、スワップはトリガーされません。 After the first execution, targetBuildVersion will match the current buildVersion, so a swap will not be triggered. CLI で自動化する Automate with the CLI デプロイ スロット用の コマンドについては、「」をご覧ください。 For commands for deployment slots, see. xml にログ記録されます。 xml. アプリケーション固有のエラー ログにも記録されます。 It's also logged in the application-specific error log. 以下に、スワップの一般的なエラーをいくつか示します。 Here are some common swap errors:• アプリケーション ルートへの HTTP 要求には時間枠が設けられています。 An HTTP request to the application root is timed. スワップ操作は、HTTP 要求ごとに 90 秒間待機し、最大 5 回再試行します。 The swap operation waits for 90 seconds for each HTTP request, and retries up to 5 times. すべての再試行がタイムアウトになると、スワップ操作は停止されます。 If all retries are timed out, the swap operation is stopped. アプリのコンテンツがローカル キャッシュ用に指定されたローカル ディスクのクォータを超過すると、ローカル キャッシュの初期化が失敗することがあります。 Local cache initialization might fail when the app content exceeds the local disk quota specified for the local cache. 詳細については、に関するページを参照してください。 For more information, see. 時には、HTTP 要求は 外部 URL を経由することなく 内部的に作成されます。 During , the HTTP requests are made internally without going through the external URL. Web. config 内に特定の URL 書き換えルールがあると、それらが失敗する可能性があります。 たとえば、ドメイン名をリダイレクトするルールや HTTPS を適用するルールは、ウォームアップ要求がアプリ コードに到達するのを妨げることがあります。 They can fail with certain URL rewrite rules in Web. config. For example, rules for redirecting domain names or enforcing HTTPS can prevent warm-up requests from reaching the app code. この問題を回避するには、以下のように 2 つの条件を追加して、書き換えルールを変更します。 To work around this issue, modify your rewrite rules by adding the following two conditions:... カスタム ウォームアップを行わなくても、URL 書き換えルールが HTTP 要求をブロックする場合があります。 Without a custom warm-up, the URL rewrite rules can still block HTTP requests. この問題を回避するには、以下のように条件を追加して、書き換えルールを変更します。 To work around this issue, modify your rewrite rules by adding the following condition:... 一部の により、スワップ操作でのアプリへの HTTP 要求の送信が妨げられる可能性があります。 Some might prevent the swap operation from sending HTTP requests to your app. および 100. で始まる IPv4 アドレスの範囲は、デプロイに対して内側です。 IPv4 address ranges that start with 10. and 100. are internal to your deployment. これらにアプリへの接続を許可する必要があります。 You should allow them to connect to your app. スロットをスワップした後、アプリが予期せず再起動する可能性があります。 After slot swaps, the app may experience unexpected restarts. これは、スワップ後にホスト名のバインド構成の同期が切れ、単体では再起動を行うことができないためです。 This is because after a swap, the hostname binding configuration goes out of sync, which by itself doesn't cause restarts. ただし、基盤となる特定のストレージ イベント 記憶域ボリュームのフェールオーバーなど によってこれらの不一致が検出され、すべてのワーカー プロセスが強制的に再起動される可能性があります。 However, certain underlying storage events such as storage volume failovers may detect these discrepancies and force all worker processes to restart. このような再起動を最小限に抑えるには、 すべてのスロットでを設定します。 To minimize these types of restarts, set the on all slots. ただし、このアプリケーション設定は Windows Communication Foundation WCF アプリでは動作 しません。 However, this app setting does not work with Windows Communication Foundation WCF apps. 次のステップ Next steps 関連記事.

次の

ステージング環境とは結局なんなのか。

ステージング 環境

ステージング環境とは ステージング環境とは、システム開発における最終的なテストを行う環境のことで、本番環境とほぼ同じ状態であることが特徴です。 大きなくくりで見るとテスト環境の一部ですが、リリースに向けて本番を想定した環境となっています。 システム開発の現場では、テスト環境では正常に動いてもリリース直後に不具合が起きるケースは少なくありません。 このステージング環境は、サービスの提供後に不具合が発生するリスクを下げるという点で必要です。 また、ステージング環境はWebサービスが稼働した後でも使います。 基本的には、サービスをストップさせて修正する場合にステージング環境が必要です。 例えば、WordPressのようなコンテンツ管理システムの場合だと、モジュールのアップデートを行う際に必要です。 開発で失敗しないためには、このようなステージング環境の特徴と必要性を押さえておくことが大切です。 サービス公開までの基本的な流れ ステージング環境は具体的にシステム環境のどの段階で使われるのでしょうか。 サービス公開までの基本の流れと一緒に見ていきましょう。 1.開発環境でコードを記述 開発環境とは、ソフトウェア開発において、エンジニアがコーディングを行うための環境のことです。 具体的には、開発に必要なプログラミング言語やコンパイラ、デバッガなどを表す言葉です。 基本的に開発環境は、エンジニア個人のローカル環境(使用している端末)を利用しています。 エンジニアが複数人いる場合は、各々が記述したコードを結合する必要があるでしょう。 開発環境では、記述したコードが動くかどうかの動作確認まで行えることが求められます。 2.検証環境で機能テストを実施 検証環境とは一般的にテスト環境とも呼ばれ、エンジニアが開発した機能の動作を検証する環境のことです。 開発環境と検証環境は分離されていることが多く、分けることでテストを行いながら別の案件の開発を進められます。 特に小規模開発やアジャイル開発であれば、このようにテストと開発を同時に行うことも多いです。 開発の規模が大きい場合は検証環境が複数用意され、複数の担当者がテストを行うこともあります。 3.ステージング環境で本番動作を確認 検証環境まで問題なく進んだらステージング環境に移り、本番動作の確認を実施します。 実際に本番と同じ設定、同じソフトウェアを使って検証しなければなりません。 もしステージング環境のテストで問題が発生すれば、再度開発環境・検証環境に戻って修正します。 近年ではクラウドや仮想化技術の向上により、同一の環境を構築するのが容易になりました。 検証環境でのテストだけでは不安があり、リスクを極限まで下げたい場合はステージング環境を活用してください。 4.本番環境でサービスを公開 本番環境とは、システムがサービスとして稼働している環境のことです。 すべてのテストが完了した後に移行する環境であり、問題なく動作できるかどうかが求められます。 開発のゴールは本番環境で利用できるようにすることであるため、実現するためには最初の要件定義の段階から考えなければなりません。 例えば、バックアップなどの運用体制は構成の段階から検討する必要があります。 Webサービスの開発であれば、サービスを公開してユーザーが使える状態にします。 ステージング環境の構築で気を付けること 最後に、ステージング環境を構築するときに注意すべきことを見ていきましょう。 本番環境に近い状況を用意する ステージング環境は、本番前の最終的な検証段階です。 そのため、本番環境で失敗しないようにするため、ほぼ同じ環境を用意しなければなりません。 もし本番環境と全く違う環境で検証を行って本番環境に移行した場合、本番で不具合が発生するリスクが生まれるでしょう。 本番環境で使えるディレクトリ構成にする ステージング環境を構築する際には本番環境にできる限り近づけるため、そのままコピーして使えるディレクトリ構成にします。 そのためには、本番環境とステージング環境の差分を少なくする必要があるでしょう。 ミスをなくすためにも、テスト環境用のフォルダを本番環境のフォルダに上書きできるような状態が望ましいです。 絶対パスと相対パスの使い分けをする Webサービスを開発している場合、HTMLコードのパスを使い分ける必要があります。 このパスには大きく分けて「絶対パス」と「相対パス」の2種類があります。 絶対パスはファイルをすべて記述する方法であり、相対パスは対象のファイルのみを記述する方法です。 例えば、絶対パスはWebサーバに繋がるコードの記述になるためローカル環境ではテストを行えません。 テストをするときには相対パスを使い、本番化する前に絶対パスに切り替える必要があるでしょう。 ステージング環境について理解し、開発を進めよう! ステージング環境は、本番に限りなく近い検証環境の最終段階のことです。 テスト環境で動作していても本番環境で不具合が発生することも少なくありません。 ステージング環境があれば、リリース後に不具合が発生するリスクを抑えられます。 本番で失敗しないためにも、ステージング環境の特徴を押さえて開発を進めましょう。 適切な開発環境を構築するためには、効率化を図れる開発ツールの導入も検討してください。 新着記事• クラウドファースト時代の到来とともに普及してき... システム開発・アプリケーション開発を支援し、開... GoogleやFacebookが採用するWebスケールITが、拡張... 開発ツールとは、ソフトウェアやアプリケーション... 開発ツールは企業の活動を助けてくれる重要な製品... 今回は、開発ツールの導入においてよくある失敗例... 工程を反復するシステム開発手法に「スパイラル開... アジャイルは小規模開発向けとされる手法です。 エクストリームプログラミングはアジャイル開発手... オートエンコーダとはニューラルネットワークの仕...

次の

Azure Web Apps の ステージングスロット

ステージング 環境

WordPressステージング環境 今回、最も本番環境に近いテスト環境」として、 本番のデータベースを直接参照しながら、新しく変更を加えたテーマのソースコードをさくっとテストできる環境を用意します。 そもそも、「ステージング環境って?」という方はまず「」をご覧下さい。 設置する環境の概念図 ワードプレス開発において、多くの場合はワードプレスの「テーマ」を開発していると思います。 いまから作るのは「テーマ開発」におけるステージング環境です。 具体的には、以下のような環境です。 今回、このテスト環境を「本番と同じサーバーに」作ってしまいます。 大前提としては、「開発したテーマを、本番データを直接使ってテストする」ですね。 本番に反映する本当に直前の確認です。 いくつかの注意点があります。 注意1:開発が終わった更新のみ反映させる ただし、 いけてないテーマのコードを上記のステージング環境にアップすると、サーバー自体がダウンしたり、本番データを壊してしまったりするので、適していません。 できるだけ深刻なバグがない状態で、テストを開始しましょう。 注意2:データベースへの影響を考慮する また、今回のような環境設定では、データに依存する機能をテストしにくい場合があります。 開発している新しい機能に必要なデータが、本番の振る舞いに影響を与えてしまうようなケースがあり得るからです。 実際の更新内容のリリース時には、そのような自体を迂回するために、開発中にわざとデータの後方互換を保つようにデータ構造の変更を設計する事もできます。 先に新機能用のデータを本番に作成し(でも、本番の振る舞いに一切影響を与えない)その後、新しいテーマの機能をテストできるという見込みで、データ、その後、テーマコード、という2段階で本番に更新を行う事もできます(話が細かくなるので、今回はこれ以上は割愛します・・) 注意3:データベースを分けたほうが良い時は、素直に分ける。 今回の方法では、参照するデータベース名を指定するファイルwp-config. phpを独立で持つことができますので、データを分けたほうが良い場合は、wp-config. phpを書き換えて、完全にDBを別に持ってしまったほうがよいでしょう。 データベースのデータ(SQL)はSQLインポートすることで、比較的容易に同期できるはずです(後述)。 また、そもそも「ステージング環境」ではなく、大きくデータに依存するような機能を開発する場合は、本番環境とは別のサーバーにテスト用の環境を作り、」などのアプローチのほうが適切だと思います。 え、そもそも「ステージング」って何なの?って人はどうかこちらをお読みください: ではさっそく、ステージング環境を作っておいて、簡単にテストできるようにしましょう。 まずは手順のサマリから。 WordPressステージング環境の作り方サマリー まずはサマリーから。 (1)本番サーバーで、本番のWordPressとは別のディレクトリに、もう一つWordPressをインストールする。 (これをステージング環境にします) (2)適当にサブドメイン(完全に別ドメインでもOK)を登録して、そのドメインが、1でWordpressを配置したディレクトリを指すように設定。 (バーチャルホスト設定) (3)wp-config. phpを書きかえて、本番と同じDBを参照するにする。 (本番のwp-config. phpを複製でもOK)。 (4)wp-config. phpに、DB内に登録されたサイトURLの値(home, siteurlの値)を参照しないよう設定を書き込む。 あっても動くけどね。 プラグインと本番と同じものを展開しておいて。 (1)Wordpressディレクトリ構成 私は、個人的には、このような構成でワードプレスを作る事が多いです。 筆者オススメの、さくらレンタルサーバーを例にとってすすめていきます。 my-website. com」は本番のURLなのですが、わかりやすいように、ディレクトリ名にも同じ文字列を使います。 今回、ステージング環境なので「staging. my-website. com」というサブドメイン&ディクレトリ名でいきます。 実際はなんでもいいので、自分でわかり易い名前をつけて下さい。 ちなみに、さくらインターネットのコンパネからWordPressインストーるを利用素する場合は、下記のように. sakura. my-website と入力して、インストールしてくださいね。 このコンパネでは、何かフォルダ名フィールドに文字列を指定しないと、なぜか怒られてしまう仕様のようです。 DBは本番と同じものを選択してください。 ただ、レンタルサーバー業者によっては、インストール時にDBレコードが書きかえられてしまう事があるかもしれないので、 かならず事前にSQLのバックアップ取ってから、お試しください。 こわい人はいったん、仮のデータベースを新規作成してインストールして、あとで、wp-config. phpで参照するデータベース設定を書き換える手順のほうがよいでしょう。 さて、さくらレンタルなら、これで、さっき指定した名前で自動的にフォルダを掘ってくれて、そこにワードプレスファイル群が展開されるはずです。 確か、Xサーバーレンタルだと、コンパネからサブドメインを追加する操作をすると、強制的に同じ名前でサブディレクトリを掘られて、そこがルートディレクトリになるような動きをしていた気がします。 まあ、いろいろですね。 (2)ステージング環境を指すドメインを設定 ステージング環境に使うドメインも、実際はなんでもいいのですが、だいたいサブドメイン使うのが無難じゃないでしょうか。 下記はさくらレンタルの例です。 サブドメインを登録して・・・ さっき作ったステージング用のディレクトリを、アクセス時のルートディレクトリに指定する。 以上です。 簡単ですね。 (3)wp-config. phpで、本番と同じDBを参照する設定 さくらの、WPクイックインストールで、最初から本番のDBを向けた機能を使った人は、この手順は不要です。 そうでない場合は、wp-config. phpを本番のWPからファイルごとコピペすれば大丈夫です。 (4)DBの「サイトURL」の値を強制上書きさせる設定 これ、ポイントです。 これをwp-config. phpに書き込んでおくとDBのhome, siteurlの値を、そのままにしておいても、WordPressの振る舞いを変えられる、というわけです。 最後のバックスラッシュも不要です。 DBを書き換えなくても、あたかもDBの値が書き換わったように振舞う、ということですね。 この設定により、まれーにうまく動作しない関数がありますので、なにかURL周りで問題が発生したときは、そのことを念頭に置いて下さい。 筆者の経験では、WordPressインストール時に実行される「」関数が動作しなかった経験があります。 今回は、もうインストール終わっているので・・、気にしていません。 (5)テーマとプラグインを展開 WordPressディレクトリの所定の場所に、テーマと、本番と同じプラグインを配置します。 ここは説明不要でしょう。 (6)ベーシック認証などで蓋をする このままだと、インターネットに公開されて、誰でも観れる&重複サイト認定されてしまいますので、ベーシック認証などで、蓋をするのを忘れずに。 参考:ベーシック認証のやりかた、さくらレンタルの方はこちら: まとめ 以上です。 できましたね。 phpで、おなじDBを参照するように設定しても、別々のワードプレスが、おなじデータで動くきました。 やった〜。 最近はコマンドで1撃できるツールもあるようですが・・、やはり、気持ち的にめんどくさくて辛かったです。 「そうだ、ステージング環境を(いいかげん)作ろう」そう思っては後回しにして、3回目くらいでようやく重い腰をあげました。 いろいろぐぐって、適切そうな環境の用意を仕方を調べましたので、それを今回まとめてみました。 ちなみに・・、別のおなじWPコアファイル(プラグインも)を利用して、themeディレクトリ配下の、テーマだけをテストする方法もあります。 テーマ以外を本番と同一の条件でテストできます。 これは、もうすこしコンパクトな環境と言えるでしょう。 より本番環境への影響度、依存度が大きくなり、意図せず本番に影響を与えてしまう場合が多いです。 なにがどのような影響を与えるか、理解した上で利用したいですね。 (こちらはまた次回ご紹介します) [補足] ワードプレス豆知識 蛇足ですが、siteurlとhomeという値は、名前が紛らわしいことで有名です。 siteurlは、ワードプレスのルートディレクトリ、一方で、homeは、ユーザがブラウザのアドレスバーに見ることになる、いわゆるトップページのURLを入力する場所だ。 参考 wp-config. php の編集.

次の