Arch Linuxはサーバー環境に適していますか？
Arch Linuxはサーバー環境に適していると思いますか？そのローリングリリースモデルとシンプルさは良いことのようです。一度インストールすると、他のディストリビューションのリリースモデルのように再インストールする必要がないためです。
しかし、その絶え間ないアップグレードは安定性の問題を引き起こしませんか？ Edgeの最先端ですが、Arch Linuxは最新のSTABLEバージョンのソフトウェアを使用しています。
おそらく、サーバーオペレーティングシステムとしてのArchの最大の問題は、アップグレード後にアプリケーションがいつどこで壊れるかがはっきりしないことです。たいていの場合、何らかのアップグレードを行う前に、wikiやフォーラムで何が行われているのかを把握する必要があります。 DebianとCentOSを使用すると、アップグレードによってアプリケーションが壊れることはありません。STABLEブランチで行われるアップグレードは、多くの場合、セキュリティ/バグ修正であるためです。
Archは大好きですが、実稼働環境では使用しません。まず、本番環境では、安定した十分にテストされたものが必要です。さらに、完全に削除されているため、カスタムスクリプトを作成したり、手動で設定したりする必要があります（システムで何が実行されているかを正確に把握していると良い場合もありますが、構成に時間がかかりすぎるため非常に悪いです）。その上、本番環境ではあまり使用されていないため、問題が発生した場合、DebianまたはFedoraを使用している場合に見つかるサポートを見つけることができません（Archコミュニティは素晴らしいですが、正直なところ、それほど大きくありませんDebianまたはFedoraとして）
要約すると、それはデスクトップの使用には最適ですが、実稼働環境には適していません
はい。
長所：
箱から出してすぐに最小限のシステム、特にローエンドマシン/ VPSでのパフォーマンスに最適。不要なサービスはありません。CentOS7が、ベアメタルで実行していたために私にも適用されなかったいくつかのVM関連サービスを開始したのと比較して。
最新のソフトウェアと大きなリポジトリ。リポジトリに何かがなかったときにCentOSでかなりの時間を失い、ソースからコンパイルするか、サードパーティのRPM /リポジトリをインストールするよう強制され、これらのサードパーティのRPMが公式リポジトリからのアップグレードと競合しています。
systemd、ただし他のディストリビューション（Ubuntuも含む）がそれに切り替えているため、プロではなく、まともなディストリビューションから期待されるものです。
意味のあるネットワーク構成ツール。デスクトップグレードのNetworkmanagerもFirewalld（CentOS/RHELを参照）もありません。
缶に書かれていることだけを行うパッケージマネージャー。パッケージマネージャーは、（Ubuntu/Debianを見て）インストールしたばかりのサービスを自動的に構成または開始することによって、あなたを「助け」ようとはしません。また、
yumよりも高速で、apt-getよりもわずかに高速です。デフォルトを使用する必要がなく、カスタマイズの余地が大きいインストールプロセス-LVMとスワップを強制的に使用するCentOS/RHELと比較してください。これは、必ずしも必要ではないものです（実際にはほとんどありません）。
/usr/bin/pythonは実際には最新のPython 3であり、先史時代のPython 2.7ではありません。他のほとんどのディストリビューションでは常に問題です。それに依存する多くのアプリを壊してしまうので、（少なくともシステム全体ではなく）簡単に変更することはできません。
短所：
一部のアップグレードは手動による介入を必要とし、中断する可能性があります。実サーバーに展開する前に、VMに運用環境のレプリカを用意し、そこでアップグレードをテストすることをお勧めします。
デフォルトの動作設定はありません。 apt-getを実行して、デフォルトの安全でないLAMPスタックをインストールして、脆弱な脆弱性のあるPHPアプリをデプロイし、インターネットを汚染するだけです。サービスを開始する前に、構成ファイルを確認する必要があります。
sELinuxサポートなし。 GRSecurityとそのRBACがありますが、それに慣れて微調整するには時間が必要です。
サポートが減るという事実には同意しません。確かに、それは本当です。それは不利ですか？いいえ、私の意見ではありません。 Archには壊れる可能性がほとんどなく、Archに詳しい人のサポートが必要になります。通常、サポートが必要な場合は、特定のソフトウェアでサポートが必要になります。その場合、開発者に尋ねると、Archを実行しているという事実は無関係になります。
私にとっては、Archを使用する方が、CentOSとそのNetworkmanager、ファイアウォールなどの不要なサービスを使用するよりもはるかに簡単で時間もかかりません（無効にすることもできますが、すでに時間の無駄です）。さらに、システムで実行するすべてのサービスはわかっているので、インストールしたのですが、 卑劣なソフトウェア はバグについて悩み、システムをインストールしたばかりの家に電話をかけたいと思っています。
私は常に次のいずれかを提案します：
CentOS。これは無料のRHELクローンです。つまり、非常に長いサポートサイクル（7年間）が得られ、その間にjustのセキュリティ修正とマイナーな拡張機能を入手できるため、システムにパッチを適用することは非常に簡単です。また、多くの「商用」ソフトウェアがRHELをターゲットにしているため、CentOSへのインストールが簡単です。欠点：私はapt/dpkgをyum/rpmよりも優先します。出血しているEdgeソフトウェアを実行するのは簡単ではなく、多少質素なソフトウェアを選択します
Ubuntu LTS。実際にはまだ使用していませんが、サポートサイクルが長く、Debianになっています
Debianテスト。 Debianの私のお気に入りのディストリビューションは非常にうまく機能し、非常にうまくまとめられた愚かな巨大なパッケージの選択肢があります。パッチを当てておくと多少時間がかかりますが、ソフトウェアをインストールする方が簡単です（つまり、すぐにパッケージ化できるものが増えます）。
Arch Linuxをこれら3つのうちの1つに使用するプロを検討して、それが価値があるかどうかを確認することをお勧めします。
2013年から運用環境でいくつかのArchlinuxサーバーを実行していますが、それは魅力的なように機能します。
確かに、更新を頻繁に実行して更新が正常に行われていることを確認し、アップグレードする前に常にarchlinuxページを確認する必要があります。
しかし、それで終わりです。結局、RedHat/CentOSを6から7（ほとんど不可能）にアップグレードしたり、SLES/SLEDを11から12にアップグレードしたりするなど、さらに多くの問題が発生します。
あなたは絶えず小さな更新を行っており、時々、何らかの行動を引き起こしますが、私は過去5年間に大きなものはありませんでした。
また、常に最新の状態であり、カーネル、openssl、bashなどにセキュリティリークがある場合、更新は数日から数か月ではなく数時間で行われます。
たとえば私のサーバーは完全にアップグレードされ、妖怪v1、妖怪v2、メルトダウンから保護されています。ここに投稿する人の1％だけが3つすべてに対してサーバーを保護していると確信しています。
その高速、安全、安定（！）で、多くの問題からあなたを救う最新のソフトウェアがあります。
サーバーでArchlinuxを使用することを強くお勧めします。唯一の欠点は、自分が何をしているかを知る必要があることです。 Linuxディストリビューションがどのように構築され、機能するかについての非常に基本を理解するために、少なくとも1回はLFSシステムをインストールしておく必要があります。
サーバー環境でArchlinuxよりも確実なサーバーシステムは、Gentooだけでした。 700日間更新のないGentooシステムが1つあり、1時間後、このシステムは最新で稼働しており、ダウンタイムは1回の再起動のみでした。
しかし、Debian/Ubuntu、RedHat、SUSEなどの他のシステムは、ディストリビューションのアップグレードがあると、完全に台無しにしてしまいます。 RedHatは、ディストリビューションのアップグレードを行うことを積極的に推奨せず、再インストールを推奨します（公式ドキュメントによると）。
つまり、RedHatはArchlinuxよりもアップグレードが安定していますが、大きなアップグレードを取得できないためです。そして、あなたがそれらを手に入れるとき、あなたはねじ込まれています。
確かに、本番サーバーでpacman -Syuを実行しないでください。破損した場合にファイルシステムにロールオーバーできるシステムドライブの差分イメージバックアップを保持しないでください。
Debianテスト/ sidよりはるかに使いやすい（破損ウェブがはるかに少ない）。 Edgeパッケージのカットと最小限のインストールが必要な場合、Archはそのための最良のディストリビューションですが、手動での管理に多くの快適さが必要です。
サーバーディストリビューションの主な違いは、セキュリティアップデートのみを取得することですが、Archではパッケージのメジャーリビジョンも取得するため、問題が発生する可能性があります。
Archをサーバーに適したものにしたい場合は、ミラー（パッケージを取得する場所）を変更するだけです。例えば：
- Archミラー：所有者によってリリースされた後の最初の週に、マイナー/メジャーパッケージの更新を取得します。
- manjaro-unstable： Archミラーと同じですが、一部のパッケージはダブルチェックされます。いくつかの主要なバグはそれを本番環境に入れません。
- manjaro-beta： Archミラーと同じですが、すべてのパッケージがトリプルチェックされます。主要なバグのほとんどは、本番環境にはありません。
- manjaro-stable： Archミラーと同じですが、パッケージは数か月に数回チェックされます。マイナーなバグがほとんどないため、本番環境に移行します。
同様に、サーバー用に特別に設計されたミラーを使用していて、マイナーなリビジョンしか得られない場合は、サーバーでArchを使用しても安全です。