問題タブ [production-environment]

私は現在Erlangを学んでいます

SOユーザーはErlangアプリケーションのデプロイメントの興味深い例を挙げられますか？

私は、Erlangが過去のテレコムを使用する一般的なもの、および開発/展開中にErlangがもたらした問題や予期しない利点についての洞察を得たいと思います。

これがより広い文脈を与え、私自身と他の誰かがErlangに飛び込むための笛を吹くことを願っています！

前もって感謝します！

おそらく 20 人の同時ユーザーを受け入れるサイトの運用データベースとして SQLite を使用することを検討していますが、ピークがその数倍になる可能性があります (サイトはオープンなインターネットでアクセスでき、常に誰かがどこかにリンクを投稿して、多くの人を一度にサイトに誘導する可能性があります)。

SQLite は可能性がありますか?

理想的な生産シナリオではないことはわかっています。これが現実的な可能性の範囲内であるかどうかを尋ねているだけです。

適切なステージング環境がないため、本番システムで問題をデバッグする必要があることがよくあります。Web サーバー、アプリケーション サーバー、データベース サーバーがあります。

これを行うときに、本番環境に意図しない変更を誤って加えないようにするために、どのような保護手段を使用していますか?

編集：

このアプリケーションは、非常に複雑な B2B 垂直 Web アプリケーションです。関連するデータはたくさんあります。一部のテーブルには、1 億近くのレコードがあります。

編集：

私たちが用意しているステージング環境には、本番環境をミラーリングする能力がありません。実際のデータベース データ以外にも、数百ギガバイトのデータ ファイルが含まれます。

編集：

コードにはソース管理を使用しますが、ストアド プロシージャには使用しません。ソース管理には古いストアド プロシージャがいくつかありますが、それを最新の状態に保つ人はいません。

主な懸念事項は、ファイル システム上のデータベースとデータです。

ところで、私はこの会社のコンサルタントであり、実際の従業員ではありません。

私たちの会社は「稼働」日が近づいています（そしてQA部門の日付を取得しています）。私はこれをサポートするための適切な運用プロセスを定義しようとしています。私の大きな考慮事項は、必然的に発生した展開/構成の地獄を回避する方法です。QA、ステージング、および実稼働環境でビルドを正常にインストールおよび構成できるように、プログラマー以外のユーザーにビルドを渡すための優れたソリューションを見つけた人はいますか？

私たちの完全な環境は、異種のスケジュールされたタスク、Windowsサービス、およびWebサイトの混合で構成されており、これらはすべて、並列展開によってスケールアウトできます。ありがたいことに、構成の手段は一貫しています。残念ながら、すべて.NET web/app.configファイルを介して管理されています。私の経験では、QAと運用担当者は、それらを変更しようとすると常に混乱します（XMLは、ほとんどの人にとって驚くほど扱いにくいです！）

これが私が検討しているオプションです：

machine.configファイルの使用

これは私が実際に行ったことのないことですが、有望に見えます。環境によって異なる可能性のあるすべてのアプリケーションのすべての設定を含むmachine.configテンプレートを作成すると、管理者は1つのファイルにすべての変更を加えて、環境内の各マシンにデプロイできます。

長所：

これにより、システムの展開に必要な手順の数が減る可能性があります

短所：

構成スキーマの変更を何らかの方法で文書化する必要がある

不明：

カスタム構成セクションおよびアセンブリを参照するその他の構成拡張機能を利用します。これには、マシンのGACに.NETアセンブリをインストールする必要がありますか？

ビルドプロセスで設定ファイルの操作を実行します

QA、ステージング、および本番環境をソフトウェア（仮想サーバーやLANなど）と同じように設定すると、QAは、構成を変更せずに、すぐに使用できるソフトウェアをステージング環境に直接移行し、ステージングを本番環境に移行できるはずです。 。この設定により、理論的には、誰も触れる必要のないQAの事前構成されたfoo.configファイルを渡すことができます。

長所：

エンジニアリングは、構成ファイルが有効であることを確認するのにより熟達しています。

短所：

エンジニアリングが本番構成を認識することは、セキュリティ慣行としては不十分であると見なされる場合があります（不十分な議論、IMHO）

ネットワークに一元化された設定リポジトリを用意する

これは私には魅力的ではありません。これは、最終的に失敗した3つの方法で試したためです。

1. 以前の会社では、データベースに構成設定がありましたが、そのデータベースへの接続文字列を構成する必要があるため、もちろんすべてをそこに入れることはできません。また、展開前にデータベースが適切に更新されていることを確認することも同様に困難でした。
2. 私たちが試したもう1つのアプローチは、一種の集中型レジストリとして機能するネットワークサービスを用意することでした。これはほぼ機能しましたが、ローカルキャッシュ、構成サーバーへのURLが適切に構成されていることの確認、そしてもちろん構成サーバーの構成には常に問題がありました。
3. Active Directory？えっ！もっと言う必要がありますか？

考え？

私が検討しているオプションの使用にどの程度成功しましたか？あなたのためにうまくいったこれらの代替案はありますか？

私が使用する場合：

結果は「2.0.50727.3053」

3.5 は互換性があり、IIS では 2.0 として識別されることは知っています。

インストールされている正確な .net バージョンと、ASP.NET MVC などの別のリソースがインストールされているかどうかを知りたいです。問題は、Web サイトが共有ホスティングにインストールされていることです。そのリソースについて技術サポートに問い合わせることができます。しかし、プログラムで知っていれば、はるかに優れています。

よろしく

私はRoR開発者ですが、現在、サーバーを微調整できないプロジェクトでCakePHPを使用しています。私のRails本番サーバーでは、Passengerは「本番」環境を自動的に使用するように設定されており、ローカルアプリの設定を上書きします。同じことをするようにcakephpアプリをセットアップしたいと思います。通常、CakePHPでそれをどのように達成しますか？ドメインパーサーを設定しますか、それともcore.phpとdatabase.phpをバージョン管理の対象外にしますか？よろしくお願いします、Davide

Perlを使用して、さまざまな開発ライブラリと本番ライブラリのパスを処理する簡単な方法は何ですか？テストにローカルボックスパスを使用したいのですが、起動時に本番ライブラリパスを自動的に指すようにします。

VB6 で書かれた古いアプリケーションを維持しています。クライアントの環境では、デバッガーで再現できないランタイム エラーが発生します。スタックトレースまたはエラーの場所を取得する方法はありますか?

つまり、 hereのようにコード全体にトレース ステートメントを配置したり、 hereのようにすべてのプロシージャにログを記録するためのエラー ハンドラーを追加したりしません。

簡単な質問のようです。ごめん。私はVB6をよく知りません。そして、それがどれほど広く使われているか (または以前は使われていたか) を考えると、情報をグーグルで検索するのは驚くほど困難です。

現在、実稼働環境で使用されている C# .NET で記述されたアプリケーションがあります。明らかにリリース ビルドが使用されます。

残念ながら、特定の条件下でアプリケーションが誤動作することがありますが、その理由はわかりません。社内で問題を再現することはできません。はい、より多くのトレースが役立ちますが、多くの場合、より多くのトレースを配置する必要があることに気付いたのは事後です。

通常の行ごとの Visual Studio プロセスへのアタッチ タイプのデバッグを使用して、そのインストールをデバッグする最良の方法は何ですか。顧客のマシンに VS のエクスプレス エディションをインストールし、DLL をデバッグ バージョンに置き換えますか? PDB と特定のソース ファイルを送信するだけで十分ですか? より良い方法はありますか？最終的な目標は、問題をデバッグするための環境のような開発を行うことです。

Tomcat アプリケーション サーバーの複数のインスタンスにまたがる JNDI リソースの維持を、人々がどのように管理しているのか疑問に思っています。たとえば、私のデータベース JNDI リソースを見てみましょう。/conf/context.xml ファイル内で宣言され、アプリの web.xml ファイルから参照されます。

その JNDI リソースは、開発ボックス、ステージング ボックス、および実動ボックスで個別に定義する必要があります。開発者/ステージング/プロダクション ボックスの新しいインスタンスをセットアップしたい場合はどうすればよいですか? つまり、起動する新しいインスタンスごとに、context.xml 内でリソース名を再作成する必要があるということですか? セットアップの観点からすると、これは、アプリ サーバーが間違った DB を指し始める原因となる人為的エラーが発生する可能性がある場所です。

プロジェクトの開発者の数と、最終的には使用する本番サーバーの数の両方をスケールアップするため、これは面倒で混乱を招くものであることがわかりました。

Tomcatを再インストールしてボックスをセットアップするたびに、セットアップの一部にするか、これを処理するセットアップスクリプトを作成しますか? または、これを簡単にする他のレベルの間接化がありますか?