問題タブ [azure-deployment-slots]

短い: Visual Studio でデプロイ スロットと運用スロットをデプロイする発行プロファイルを作成するにはどうすればよいですか?

長時間: 本番環境が停止したことを示す Sev1 コールを受け取り、統合デプロイ スロットへのデプロイを開始する数分前にそのことを知っている瞬間。ええ、それが私に起こったことであり、私の人生では説明できません。

そのため、"Int" という名前の Azure Function アプリ用のデプロイ スロットが 1 つあります。公開プロファイルを作成するときは、Visual Studio の [新しいプロファイルの作成] ウィザードを使用し、[既存のものを選択] Azure App Service を選択してから、[Int] デプロイ スロットを掘り下げました。かなり簡単に見えました。そうすることで、Int と Production の両方が展開されます。これは確かに予想外であり、明らかに壊滅的でした。

Azure 関数アプリの [概要] セクションで見つけたポータルを掘り下げた後、[発行プロファイルのダウンロード] ボタンがあります。Production と INT の両方でクリックすると、destinationAppUrls など、ユーザーが異なる 2 つの個別のファイルが生成されます。この 2 つの間で唯一同じだったのは FTP の publishUrl でしたが、サーバーはそれに基づいて適切なルートにルーティングされると思います。資格情報が渡されました。

1 つは prod 用、もう 1 つは int 用の 2 つの固有の発行プロファイルがあるという事実にもかかわらず、いずれかをデプロイすると、運用とデプロイ スロットの両方が更新されます。

これは、私がこれを自分で修正しようとしたことのリストです。

1. Visual Studio から両方の発行プロファイルを削除し、ウィザードを使用して再作成しました。
2. Visual Studio から両方の公開プロファイルを削除し、ポータルからダウンロードしたプロファイルを介してそれらを再作成しました。
3. INT パブリッシング プロファイルを削除し、ポータルで INT デプロイ スロット用の新しい FTP ユーザーを作成し、ダウンロードした INT のプロファイルを更新してから、それを Visual Studio にインポートしました。<== 正直なところ、VS が FTP を使用して展開しているとは思わないので、これはばかげていると思います。私は間違っているかもしれません。
4. AutoSwapがオフになっていることを確認。
5. FTP クライアントを使用して、発行資格情報で手動でログインしました。Production と Int では、同じ場所でどちらかのポイントとしてログインしている「FTP 展開ユーザー」が異なります。（これは最終的に問題のようです）
6. デプロイ スロットで [発行プロファイルのリセット] をクリックし、プロファイルを再ダウンロードしました。

私が失っていない自動スワップ機能を失う以外に、これを回避する1つの方法は、完全に別のアプリを作成して、正しく動作させることだと思います. できれば避けたいところですが。

ここで助けてくれてありがとう。

2017 年 11 月に作成した Azure App Service があります。App Service は ManifestAPI と呼ばれます。

ManifestAPI-QA と呼ばれるアプリ サービスの QA デプロイ スロットを作成し、それ以来、API のコード更新を QA スロットに喜んでデプロイしています。Kudu zipdeploy API を使用して、Bamboo デプロイ サーバーから Azure QA デプロイ スロットにデプロイしています。エラーはなく、すべてのエンドポイントが正常に動作しています。

現在、製品を運用環境に移行する準備をしており、ベースの App Service である ManifestAPI にデプロイしようとしています。そこで、QA スロットにデプロイするのとまったく同じリリース コードを使用して Bamboo でデプロイを作成し、それを ManifestAPI URL にデプロイしました。ただし、ベース アプリ サービスで API を実行しようとすると、502.5 エラーが発生します。

同じコード ベースとベースの ManifestAPI App Service からの公開プロファイルを使用して、VisualStudio 2017 内から直接公開しようとしましたが、Bamboo の展開に問題があると考えました。しかし、同じ 502.5 エラーが発生します。

eventlog.xml ファイルの LogFiles フォルダーにある Kudu サイトを見ると、次のように表示されます。

Google でエラーを確認すると、IIS 自体にインストールされている .Net Core DLL に問題があることがわかりました。

さらに、API は QA 展開スロットの IIS インスタンスで正常に動作しているため、コードが適切であることを意味すると思います。したがって、Microsoft が提供している IIS インスタンスと .NET Core ファイルに何らかの問題があるに違いないと考えています。

ManifestApi と ManifestAPI-QA インスタンスの拡張機能を比較すると、両方のインスタンスで同じです。

作業中の QA スロットから Production (ベース App Service ) スロットにスワップしようとしたところ、同じ 502.5 エラーが発生しました。

ManifestAPI-qa インスタンスのクローンを作成して、ManifestAPI-Prod という新しいデプロイ スロットを作成し、デプロイ パッケージをそのスロットにデプロイし、接続文字列とアプリケーション設定を、ベース アプリ サービスの [アプリケーション設定] セクションにあるものと正確に一致するように設定しました。ManifestAPI-Prod デプロイ スロットは問題なく機能しました。

そこで、Azure で Microsoft にサポート ケースをオープンしました。これまでのところ、これを理解しようとする技術者と 2 日以上やり取りしてきました。私のコードの問題である必要があると彼らは言い続けていますが、まったく同じ展開パッケージが QA スロットと現在の Prod スロットで機能するため、それは私には意味がありません。ある技術者は、私が正しく展開していないとさえ言いました。ただし、VS2017 で dotnet publish を使用してから、ファイルの結果のディレクトリを圧縮し、zipdeploy API を介して Kudu にプッシュしています。これは、デプロイ スロットに対してうまく機能していますが、どのように間違ってデプロイしているのか理解できません。

この時点で、API を運用 (ベース) スロットにデプロイする方法について途方に暮れています。

ここで何が欠けていますか？

UPDATE 6/27/18 これは、Azure 運用スロット インスタンスのすべての拡張機能をアンインストールすることで解決されました。次に、Microsoft Core 拡張機能を再インストールします。Extensions ブレードにはまだ ASP.NET Core Extensions 2.1.0-preview2-final と表示されていましたが、そのインスタンスの Azure コンソールに移動して dotnet --info と入力すると、次のように表示されました。

2.1.0-preview2-final のリストが、 dotnet --info によって表示されるファイルのリストに含まれなくなったことに注意してください。

私のアプリには、styles.css があります。現在、開発、テスト、本番のスロットがあるチームのスロットを設定しています。

開発用に別の styles.css を作成し、テスト用に別の style.css を作成するにはどうすればよいですか? 私がやりたいことは、開発とテストを上部のナビゲーションに別の色で表示して、これが本番環境ではないことを示すことです (間違った場所にいるので、色を付けないでください)。

アプリケーションの設定を確認しましたが、.css ファイルで設定を適用する方法がわかりません。おそらく答えは、仮想ディレクトリで、styles.css へのパスを dev スロットの styles-dev.css に「上書き」することでしょうか。仮想ディレクトリは、スワップされたときにスロットに残りますか?

これを行う他の方法はありますか？

Azure App Service にデプロイする ASP.NET Core 2.1 API があります。バッキング データベースに Azure SQL Server を使用しています。

以下は、App Service (ベース) アプリケーション設定ブレードのスクリーンショットです。これは、.Net Framework のバージョンが 4.7 に設定されていることを示しています。

デプロイ スロットを使用して App Service をセットアップしました。

デプロイ スロットごとに、[アプリケーションの設定] ブレードに、そのスロット データベースに固有の値を持つ接続文字列があります (スロットごとに 3 つの異なるデータベースがあり、3 つのスロットがあります)。

QA スロットと DEV スロットは数か月間問題なく動作していましたが、現在、運用スロット (App Service ベース) を使用して API をベータ サイトにロールアウトしています。信頼できる読み取りではありません。具体的には、2 番目と 3 番目の接続文字列が確実に読み取られていないようです。

これは、App Service --> [アプリケーション設定] ブレードのスクリーンショットで、接続文字列が表示されています。

ご覧のとおり、それぞれのスロット設定にチェックを入れています。HangfireDbConnectioinString は常に読み取りに失敗し、UspsReferenceDbConnectionString は不安定に見えますが、これは Hangfire データベースがセットアップされておらず、例外がスローされていることが原因である可能性があります。

QA スロットと DEV スロットに同じセットアップを使用すると、問題なく動作します。この問題は、運用スロット (ベース App Service) 設定でのみ発生します。

API の AppSettings.json ファイルに実際の接続文字列を含めて、それを Production スロットに再デプロイすると、API はデータベースに正しくアクセスできます。もちろん、これは接続文字列をソース管理に置くため、望ましい解決策ではありません。

重要な場合に備えて、ベースの App Service Extensions ブレードのスクリーンショットを次に示します。

以下は、データベースを設定している Startup.cs のコード セクションです。

ご覧のとおり、Configuration.GetConnectionString("HangfireDbConnectionString") を使用して Configuration から接続文字列を取得しています。

何か案は？