最近、ある教会で新しいウェブサイトを制作していたところ、最適とは言えない状況に遭遇した。彼らのインフラはもともと、開発用のウェブ・サーバーが本番用のRockインスタンスと同じVM上にあるように構成されていました。
VMに設置されていました。同じパターンを考えている人がいるかもしれないので、なぜこれが良くないのか、時間をかけて議論したいと思います。
開発環境と本番環境を分けたくなる理由は、リソースの共有と複雑な設定の2つに分類される。それぞれについて詳しく見ていきましょう。
共有リソース
本番環境と開発環境の両方を1台のサーバーで稼働させる場合の最大の懸念は、サーバー・リソースの問題である。開発環境は、本番環境ではやりたくないことを
開発環境は、本番環境ではしたくないことをしたいから作られる。一方、本番環境は、組織の日々の運営に欠かせないものです。この2つのミッションは基本的に相反するものだ。
ウェブサイトのプロジェクトでは、現在の環境が新しいサイトの負荷をサポートするのに十分な容量を持っているかどうかを検討するステップを含みます。なぜなら、現在のパートナーは
というのも、現在のパートナーは教会のアーキテクチャー・マップを管理していないため、このアンチ・プラクティスが実施されているという兆候はなかったからだ。
週末のチェックイン・パフォーマンスについては、現在懸念があると聞いている。
最後の点を考えてみよう。チェックインのパフォーマンスを中心にスケーリングに関する質問がある。1台のVMが2つの役割を担っていることを知ると、現状と可能な修正の評価はより難しくなる。
1つのVMが2つの役割を担っていることを知ることで、現状と可能な修正の評価はより難しくなる。Azureのパフォーマンスログに戻り、チェックイン期間中のCPUとメモリの使用量を見ても、負荷が本番用IISインスタンスから来たものなのか、開発用インスタンスから来たものなのかを知る方法はありません。
を知る方法はありません。おそらく、誰かが同時に開発マシン上で何かを使用またはテストしていたのでしょう。
複雑な構成
リソースの共有だけでは十分でないとすれば、同じVM上でRockの2つのインスタンスを実行するために必要な構成も見ておく必要がある。これは主に
これは主に、1つのIPアドレスで入ってくるトラフィックを2つ以上のIISインスタンスで処理するために必要なIISバインディングに起因する。この構成では、各ホスト名に
には2つのバインディング（HTTP用とHTTPS用）が必要です。
通常のIISインストールでは、すべてのトラフィックは単一のIISインスタンスに送信されます。このため、新しいホスト名（たとえば、追加したばかりの新しいマイクロサイト用）を簡単に追加できます。DNSを調整するだけです。
を調整するだけで、ロックがそのトラフィックを取得することが保証されます。複数のインスタンスを実行する場合、IISの本番インスタンスに2つの新しいバインディングルールを追加する必要があります。
これらの設定はロケット・サイエンスではないが、想定外のことでもあり、失敗のもう一つの原因となる。
結論
本番環境と開発環境を分割することは、安定した予測可能なロック環境にとって非常に重要である。開発環境を実行できるAzureのバースト可能なVM
開発環境を実行できるAzureのバースト可能なVMが、月額30ドル程度で手に入ることを考えると、特にそうだ。
トライアンフでは、常にベストプラクティスを念頭に置いて物事を行うことに情熱を注いでいます。また、これらのベストプラクティスをロック・コミュニティと共有することにも同様に情熱を注いでいます。
また、このようなベストプラクティスをロック・コミュニティと共有することにも同様に情熱を注いでいます。