ローカルサーバーをより細かく制御
ローカルネットワーク（10人の開発者からなる小さな会社）でclearOSサーバーを実行している場合、それを開発サーバーとして使用して作業をテストし、テストプロセスでクライアントに表示します。各開発者はftp/http /にアクセスするための一意のユーザー名とパスワードを持っています。 smb。問題は、開発者の1人が無限ループを実行するような安全でないコード（phpコードであると仮定します）を実行する場合です！サーバーは完全にクラッシュし、障害のある開発者を特定できません。どうすればそれを解決できますか？前もって感謝します
私のサーバーの情報
- clearOSサーバー
- RAM 16GB
- SSD 1TB（2パーティション）
インストールされているアプリ：
- proftpd、
- gitlab、
- Apache、
- mariadb
ユーザー：
- 物理rootユーザーと
- 10仮想ユーザー（LDAPを使用）各ユーザーは一意のパスワードを持っています
あなたの問題
あなたはあなたの主な問題を次のように述べました
開発者の1人が無限ループを実行するような安全でないコード（phpコードであると仮定しましょう）を実行するとき！サーバーは完全にクラッシュし、障害のある開発者を特定できません。
開発コードは常にクラッシュまたはハングする可能性があるため、2つの異なる問題に効果的に対処しています。
- 異なるユーザーのプロセスは、互いに干渉したり、すべてのリソースを使用したり、他のユーザーを飢えさせたり、サーバーをクラッシュさせたりしてはなりません。
- 「それをした」ユーザーを特定する。
2番目の問題を解決する場合でも、最初の問題を解決する必要があります。しかし、最初の問題を解決すれば、もう2番目の問題を解決する必要がなくなるので、ここでは最初の問題を解決することに焦点を当てます（また、悪いことについて人々に立ち向かわずに問題を解決する方が常に簡単で、対立が少なくなります）。
可能な解決策
ユーザーアクションを相互に分離する場合、3つの主要なパスから選択できます。
- プロセスとファイルシステム：最も簡単で最も古い分離方法は、マルチユーザーUNIXシステム上の異なるユーザーごとにリソースを提供することです。
- uptime365はすでに
ulimitの提案をしましたが、アプリケーションが（各サービスの汎用デーモンユーザーではなく）それらのユーザーも使用し、プロセスを開始したくないことを確認する必要があることを付け加えたいと思います他のユーザーアカウントで。この欠点のため、継続的デリバリーインフラストラクチャのないスクリプトのビルドなどの単純なものを除いて、このアプローチは今日ほとんど使用されていません。 - ストレージは依然として主要なリソースであり、ほぼすべてのアプリケーションで機能するため、ファイルシステムのクォータは今日ではより便利です。
- uptime365はすでに
- アプリケーション：アクセスするソフトウェアのほとんどには、ユーザーとクォータの管理が組み込まれていますが、個別に管理/構成する必要があります。たとえば、データベースは各ユーザーにクォータとアクセス許可を設定でき、 ユーザーが実行できることを制限します 。異なる構成（スクリプトまたはアプリケーションによって統合される可能性がある）以外の欠点は、すべてのソフトウェアが同等に十分に装備されているわけではないことです。たとえば、GitLabはまだ ディスククォータをサポートしていません のようです。エラーの原因を評価し、特定の機能がケースに十分適しているかどうかを確認する必要があります。
- コンテナとVM：仮想化の活用（KVMまたはESXiのような完全仮想化、またはSolarisゾーン、FreeBSD Jailsのようなコンテナ化） 、Linux LXC、またはDocker et al。のようなアプリケーションベース）を使用すると、各ユーザーに完全仮想システムを提示して、許可したことをすべて実行できますが、他のユーザーの邪魔にならないようにリソースを制限できます。は最も高度な分離形式です。基本的に各ユーザーは独自のマシンを持っており、まったく干渉しないため（正しく構成されている場合）、さまざまな構成とランタイムオプション、さまざまなネットワーク、さまざまなハードドライブなどもあります。欠点このソリューションの利点は、これら3つのソリューションの構成とリソース使用量のオーバーヘッドが最も高いことです。
もちろん、アプローチは異なるレイヤーで機能するため、組み合わせは常に可能です。たとえば、コンテナを使用して全員が独自のWebサーバーを持つようにし、すべてのユーザーが同じデータベースを使用してリソースを節約できるようにすることができます（データベースへのアクセスは、複数の異なるデータベースよりも高速です）。
あなたの場合はどうしますか？
ご覧のとおり、可能性は多く、それぞれを実装するのにかなりの労力がかかるため、以下を絞り込む必要があります。
- まず、発生している問題を正確に分析します。プロセスを確認し（プロセスがない場合は、同僚にどのように作業するかを尋ねます）、発生する問題を特定します（テストケースの実行時にディスク容量が不足する、無限ループがメモリを予約しすぎる、Webサーバーキャッチされない例外や不適切なアーキテクチャなどが原因でクラッシュします）。
- 何に反対しているのかがわかったら、問題を単純に保ちながら軽減する方法を考えてください。 10台のPCの構成には100台の場合とほぼ同じ時間がかかるため、最初に簡単なものを試す必要があります（ほとんどの場合、それで十分です）。ディスク容量はユーザーの割り当てによって制限される可能性がありますが、無限ループやメモリの過剰消費は、ユニットテストによって時期尚早に捕捉される可能性があります（Webサーバーではなくローカルユーザーとして実行されます）。
- これだけでは不十分な場合は、コンテナーなど、より大きく、より優れたソリューションの実装を検討できます。最初は時間を失うことになりますが、長期的には、もちろん、特定の状況によっては、それが報われる可能性があります。
予防策として、ユーザーに特定の制限セットを設定する場合は、ulimitを調べる必要があります。プロセス/ CPU /メモリの制限を設定できます。
参照してください このリンク
もう1つの方法は、外部監視ツール（最も一般的な例：nagios/nrpe）を使用してシステムのリソース使用量を監視することです。このツールは、リソースのしきい値を超えた場合に警告を発します。