解決策 1:
おそらく、サーバー オペレーティング システムとしての Arch の最大の問題は、アップグレード後にアプリケーションがどこでいつ壊れるかが明確でないことです。多くの場合、何らかのアップグレードを行う前に、wiki やフォーラムで起こっていることを把握しておく必要があります。 Debian と CentOS を使用すると、多くの場合、STABLE ブランチで行われるアップグレードはセキュリティ/バグ修正になるため、アップグレードによってアプリケーションが破損することはありません。
解決策 2:
arch は大好きですが、本番環境では使用しません。まず第一に、本番環境では、安定した十分にテストされたものが必要です。さらに、かなり簡素化されているため、カスタム スクリプトを作成するか、手動でセットアップする必要があります (システムで何が実行されているかを正確に把握できるので良い場合もありますが、構成に時間がかかりすぎるため非常に悪いこともあります)。それに加えて、本番環境で広く使用されていないため、問題が発生した場合、Debian や Fedora を使用していた場合に提供されるサポートを見つけることができません (Arch コミュニティは素晴らしいですが、正直なところ、それほど大きくはありません。 Debian や Fedora など)
要約すると、デスクトップでの使用には優れていると思いますが、本番環境には適していません
解決策 3:
はい。
長所:
-
箱から出してすぐに使える本当に最小限のシステムで、特にローエンドのマシン/VPS でのパフォーマンスに優れています。不要なサービスはありません - CentOS 7 ではいくつかの VM 関連のサービスが開始されましたが、ベアメタルで実行していた私には適用できませんでした。
-
最新のソフトウェアと大きなリポジトリ。リポジトリに何かがなく、ソースからコンパイルするか、サードパーティの RPM/リポジトリをインストールすることを余儀なくされたときに、CentOS でかなりの時間を失いました。これらのサードパーティの RPM は、公式リポジトリからのアップグレードと競合しています。
-
ただし、他のディストリビューション (Ubuntu でさえも) は systemd に切り替えているため、プロではありませんが、適切なディストリビューションから期待されるものです。
-
理にかなったネットワーク構成ツール。デスクトップ グレードの Networkmanager も firewalld もありません (CentOS/RHEL を参照)。
-
缶に書かれていることを実行するパッケージマネージャー。パッケージ マネージャーは、インストールしたばかりのサービスを自動的に構成または開始することによって、ユーザーを「支援」しようとしません (Ubuntu/Debian を参照)。また、
yumよりも高速です。 、おそらくapt-getよりも少し速い . -
デフォルトの使用を強制せず、カスタマイズのための多くの余地を提供するインストール プロセス - LVM とスワップの使用を強制する CentOS/RHEL と比較してください。>
-
/usr/bin/python実際には、先史時代の Python 2.7 ではなく、最新の Python 3 です。これは、他のほとんどのディストリビューションでは常に問題であり、それに依存している多くのアプリが機能しなくなるため、(少なくともシステム全体では) 簡単に変更することはできません。
短所:
-
一部のアップグレードは手動の介入が必要であり、破損する可能性があります。 VM に実稼働環境のレプリカを用意し、そこでアップグレードをテストしてから実サーバーに展開することをお勧めします。
-
デフォルトの作業構成はありません。 apt-get を実行してデフォルトの安全でない LAMP スタックをインストールし、安っぽい脆弱な PHP アプリをデプロイしてインターネットを汚染したいだけの人には適していません。もちろん、サービスを開始する前に構成ファイルを確認する必要があるため、これは真剣な人にとっては利点です。
-
SELinux サポートなし。 GRSecurity とその RBAC がありますが、慣れて微調整するには少し時間が必要です。
サポートが少ないという事実には同意しません。確かにそうです。それは不利ですか？いいえ、私の意見ではありません。 Arch には壊れる可能性があり、Arch に詳しい人のサポートが必要な部分はほとんどありません。通常、サポートが必要な場合は、特定のソフトウェアに対してサポートが必要になります。その場合、その開発者に尋ねると、Arch を実行しているという事実は関係なくなります。
私にとって、Arch を使用することは、CentOS とその Networkmanager、firewalld、およびその他の不要なサービスを使用するよりもはるかに簡単で、時間もかかりません (それらは無効にすることができますが、それはすでに時間の無駄です)。さらに、システムをインストールしたことがあるから、システム上で実行されるすべてのサービスを知っています。システムをインストールしたばかりなのに、バグについて私を悩ませ、家に電話をかけたがる卑劣なソフトウェアはありません。
解決策 4:
私は常に次のいずれかをお勧めします:
-
CentOS。これは無料の RHEL クローンです。つまり、非常に長いサポート サイクル (7 年間) が得られ、その間は ちょうど セキュリティの修正とマイナーな機能強化により、システムにパッチを適用し続けることは非常に簡単です。また、多くの「商用」ソフトウェアは RHEL を対象としているため、CentOS に簡単にインストールできます。欠点:私は yum/rpm よりも apt/dpkg を好みます。最先端のソフトウェアを実行するのは簡単ではありません。やや質素なソフトウェアの選択
-
Ubuntu LTS.実はまだ使っていませんが、サポートサイクルも長く、Debianishです
-
Debian のテスト。 Debian の私のお気に入りのディストリビューションは、非常にうまく機能し、非常によくまとめられた愚かなほど多くのパッケージを選択できます。パッチを適用し続けるには多少時間がかかりますが、ソフトウェアをインストールするのは簡単です (つまり、より多くのものを簡単にパッケージ化できます)。
これら 3 つのうちの 1 つに Arch Linux を使用するプロを検討し、その価値があるかどうかを確認することをお勧めします。
解決策 5:
私は 2013 年以来、いくつかの Archlinux サーバーを実稼働環境で実行していますが、それは魅力的に機能します。
更新を頻繁に実行して、更新がうまくいっていることを確認し、アップグレードする前に常に archlinux ページをチェックする必要があります。
しかし、それだけです。最終的には、RedHat/CentOS を 6 から 7 にアップグレードする (ほとんど不可能です)、または SLES/SLED を 11 から 12 にアップグレードするなど、さらに多くの問題が発生します。
あなたは常に小さな更新を行っており、それが時折何らかのアクションを引き起こしますが、私は過去 5 年間で何か大きなことをしたことはありません.
また、カーネル、openssl、bash などにセキュリティ リークがあった場合でも、常に最新の状態に保たれます。更新は数日から数か月ではなく、数時間で完了します。
たとえば、私のサーバーは完全にアップグレードされており、スペクター v1、スペクター v2、およびメルトダウンから保護されています。ここに投稿する人の 1% だけが、3 つすべてに対してサーバーを保護していると確信しています。
高速で、安全で、安定しており (!)、多くの問題から解放される最新のソフトウェアがあります。
サーバーで Archlinux を使用することを強くお勧めします。 LFS システムを少なくとも 1 回はインストールして、Linux ディストリビューションの構築方法と動作方法の基本を理解する必要があります。
サーバー環境でArchlinuxよりも堅実な唯一のサーバーシステムはGentooでした。 1 つの Gentoo システムが 700 日間更新されていませんでしたが、1 時間後にこのシステムは最新の状態になり、ダウンタイムは 1 回の再起動のみで実行されました。
しかし、Debian/Ubuntu、RedHat、SUSE などの他のシステムは、ディストリビューションのアップグレードがあると完全に台無しになります。 RedHat は、ディストリビューションのアップグレードを積極的に思いとどまらせ、再インストールを推奨しています (公式ドキュメントによると)。
そうです、RedHat は Archlinux よりも安定してアップグレードされますが、それは大きなアップグレードが得られないからです。そして、あなたがそれらを手に入れたとき、あなたはめちゃくちゃです.