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