問題タブ [canary-deployment]

私たちのプロジェクトでは CD を使用しています。このアプリケーションは世界中で使用されているため、複数のデータ センター (地域ごとに 1 つ) を使用しています。各データ センターは、アプリケーションの分離されたインスタンスをホストします (各地域の展開は、独自の DB、アプリケーション サーバーなどを使用します)。データはデータセンター間で共有されません。

私たちが取ることができる2つの異なるアプローチがあります：

1. すべてのテストが実行される統合サーバー (I) にデプロイしてから、最初のデータ・センター A にデプロイし、次に (A へのデプロイが完了したら) データ・センター B にデプロイします。

2. リージョン A のユーザー ベースは小さく、統合サーバー (I) で捕捉されなかったソフトウェア バグが原因で A と B の両方が機能停止するのを防ぐには、統合サーバーにデプロイしてからコードを "焼き付ける" 方法があります。リージョン A に 24 時間配置し、本番環境で 24 時間テストした後にのみ、アプリケーションをデータ センター B にデプロイします。この場合、「継続的な」展開がないため、この代替案は CI のベスト プラクティスに反しますか?

カナリア リリースとは、スティッキー セッションがオンになっている本番ノードのサブセットへの部分的なリリースであると私は理解しています。そうすれば、悪いバグをリリースした場合に影響を受けるユーザー/顧客の数を制御および最小限に抑えることができます。

Blue/Green リリースについての私の理解では、2 つのミラー化された本番環境 ("blue" と "green") があり、変更を一度に blue または green のすべてのノードにプッシュし、ネットワーク マジックを使用して制御します。ユーザーが DNS 経由でルーティングされる環境。

ですから、始める前に、これまでに言ったことに誤りがある場合は、まず訂正してください。

私が多かれ少なかれ順調に進んでいると仮定すると、2 つの戦略に関するいくつかの質問があります。

• ブルー/グリーンよりもカナリアが好まれるシナリオ、またはその逆のシナリオはありますか?
• 展開モデルで両方の戦略を同時に実装できるシナリオはありますか?

Blue/Green デプロイに関するこの記事を調べた後、さらにグーグルでカナリア リリースに関するこの記事を紹介されました。私はこのあいまいさを持っています: データベースはどうなりますか? それらをどのように同期させるべきですか？私は2つの可能なシナリオを念頭に置いています:

• 青がアクティブなときに環境ごとに 1 つずつ (緑と青) 2 つの別個のデータベースがあると想像してください
  。新しいレコードがそのデータベースに挿入され
  、トリガーのようなメカニズム (またはその他のメカニズム) を提供しない限り、緑はこれらの変更を認識しません。グリーンデータベースを更新します。
• 
  2 番目のシナリオは、2 つの環境間で下位互換性のあるデータベースを共有することを示唆していますが、データベースを扱う場合、下位互換性はそれほど簡単ではありません
  。アプリケーションを公開する前に、データベースの変更を公開する必要があります。

3 番目のシナリオとして、メインの Blue/Green デプロイメント内のデータベースに Blue/Green デプロイメントを実装する場合があります。

より良い解決策は何だと思いますか、またその理由は何ですか? 他のプラクティスやよく知られているパターンを提案しますか?

ありがとうございました

私は Eureka と Zuul を使用して Spring Cloud を使い始めており、Blue/Green と Canary デプロイメントの構造化についていくつか質問がありました。これまでのところ、基本的な作業は完了しており、Eureka、Zuul、および構成サーバーが期待どおりに機能しています。私が達成しようとしているのは、1.0 と 1.1 などの 2 つのバージョンを持つサービスをセットアップすることです。特定のユーザーのサブセットについては、1.1 バージョンにルーティングし、それ以外のユーザーは 1.0 バージョンに移行する必要があります。

Zuul フィルター API はドキュメンテーションがやや浅く、いくつかの概念を理解するのに少し苦労しているので、ここでいくつか質問したいと思います。また、いくつかの基本的なフィルターを実行していますが、プリンシパルの ID とそれらが要求しているサービスを取得する以外には、ほとんど何もしません。私が壁にぶつかっているのは、同じサービスの 2 つの異なるバージョンを Eureka と Zuul に公開する方法を理解することです。私が興味を持っているいくつかのこと：

• ドキュメント、投稿、およびその他のスタック オーバーフローの間で、「サービス」と「クラスター」という用語は同じ意味で使用されているようです。これは正しいです？
• そうは言っても、という名前のサービスがある場合、/simpleservice2 つの異なるサービス ID (つまりsimpleserviceとsimpleservice-1.1) を公開しますか? そうすれば、ターゲット ユーザーの 1 人が をリクエストすると/simpleservice、Zuul に送信してもらうことになります。/simpleservice-1.1
• または、既存のサービス ID に別のノードを追加し、Zuul がバージョン 1.0 と 1.1 を区別できるように、各ノードに追加のメタデータを追加しますか?
• 正解は「上記のすべて」ですか？:)

Android Studio NDK プロジェクトであるプロジェクトにネイティブ デバッグを追加しようとしています。以前は、gradle を使用してシェル スクリプトを開始し、NDK ライブラリをビルドしました。現在、gradle-experimental プラグインを使用するように移行しようとしています。

NDK で gradle-experimental を使用することについて、わずかな情報 (ほとんどの場合、ここではAndroid Tools Site - Gradle Experimental ) をネットで探し、プレビュー NDK を使用しているこの build.gradle ファイルをまとめました。 Java ビルドとインラインで NDK ビルドを実行するためのサポート。

断片的な情報から最終的にこれをまとめた後、NDK 部分のビルドを取得することができましたが、依存関係に明確に含まれている httpmime-4.4-beta1.jar ファイルを含めることができませんでした。次のように、さまざまな順列を試しました。

ただし、Jar ファイルから欠落しているシンボルのエラーは引き続き表示されます。

build.gradle ソース

欲求不満から、実験的ではないブランチに戻しましたが、古い build.gradle ファイルを使用しても、同じ jar ファイルを見つけることができません。Android Studio 2.0 Preview 6 の問題でしょうか?

他の誰かがこれを経験したことがありますか、それとも解決策がありますか? 最終的に NDK デバッグが Android Studio で正しく機能するようになると非常に便利です。この最後のハードルがなければ、私はそこにいると思います。

そのjarファイルに依存するコードを書き直す以外に、私は他に何を試すべきか途方に暮れています。また、上記の build.gradle ファイルの形式に関する提案も受け付けています。これらの新機能のドキュメントはまだ非常にまばらであり、サンプルの一部は適切な構文に関して既に古くなっているようです。

何が足りないの?

C および Cpp (mobile:compileNativeArmeabiDebugArmSharedLibraryNativeMainCpp) の手順は正常に行われていることがわかりますが、Javac は失敗します。このjarファイルのアプローチは、Apacheのhttp-mime libで過去2年ほどうまく機能しているので、なぜ突然これが問題になるのかわかりません。

はい、Apache ライブラリが非推奨であることは知っていますが、これはレガシー コードであり、その事実にもかかわらず機能するはずであり、将来的に更新される予定です。