概要
Arch
。
個人的には一番使いやすいLinuxディストロだと思うのですが、2014年現在、世間的にはUbuntuやCentOS、Debianなどの後塵を拝し、Gentooなどと共にキワモノ的なカテゴリに分けられることが多いと感じています。 ここでは、特にサーバ用途として考えた際に、なぜArchが選ばれないのか、調べてみることにしました。 (といっても主にネットの声だけで)
Archが選ばれない理由8個
その1。Updateで既存環境がいつどこで壊れるか予想がつかない
Archは主要ディストロと異なり、メジャーバージョンというものがありません。つまりCentOS 5から6へのアップデートといったものはなく、常にどこかしこのパッケージがアップデートされています。(いわゆるローリングリリースモデル)
また、公式サイトでは約1ヶ月おきごとに、配布バイナリが更新されます。 これは一見良さそうです。何しろ世間には
- Ubuntu 14.04へ移行したらXXが動かなくなった
- CentOS 6を導入したけど、XXXパッケージが古すぎる
といった阿鼻叫喚が飛び交っています。Archならこういった問題とは大抵の場合無縁です。
しかし常にどこかしこでアップデートが起こっているということは、各パッケージの依存関係の問題で今動いているサービスが動かなくなるということもあり得るということです。 この問題に対するArch利用者側のよくある反応については、以下の記事に素晴らしい例があったので、引用します。
しかし、ローリングリリースは壊れやすいとからかうと、Arch上級者様は皆、まるで申し合わせたかのように言う。 「何? 壊れる? まさか? ちゃんと公式から発行される変更情報や注意点を確認していれば、壊れるなどということはない。よしんばブート不可能なほど壊れたにせよだ。復旧用のArchを入れたUSBドライブからブートしてchrootとしてpackman -Syuすればたいてい直る。問題ない。設定ファイルもプレインテキストで書かれていて、とても簡単だ。恐れることなど何もない。むしろUbuntuのようなどうやって直していいのかわからない複雑なシステムの方が怖いわ」と。
いや、ほんとコレなんですけどね。他ディストロのような
- バージョンXXからあの機能が廃止になって、新機能が追加された
- バージョンXXXにあるこの機能はバグだ。違うパッケージで対応しよう
みたいな方が個人的には恐ろしいし、そういったノウハウがやがて秘伝のタレ化していくんじゃないのかなという印象を受けます。
その2。俺達はOSを弄りまわしたいんじゃない。サービスを立ち上げたいだけなんだ
ぐぅの音も出ません。
しかし、自分も割りと同様の理由でArchを採用しています。こうした意見はおそらくローリングリリースに関しての意見だと思いますが、良い所もあります。 それは、メンテナのいるパッケージであれば大抵すぐに最新版が利用可能になるということです。 nginxやvimのバージョンが上がったらしい。 じゃ、ビルドするか。。とならないのは1つのメリットかなと思います。Archならすぐにパッケージマネージャから更新可能です。
もちろん、デフォルトで提供されているパッケージの設定では不満が出ることもありますし、そういう場合にはソースコードからビルドします。その辺りは他のディストロと同じです。
また、Archの公式Wikiは情報量が豊富で、一部は日本語に翻訳もされています。 よく使われるようなものについてはここで導入方法やオプション、注意点などについての知見を得ることができるでしょう。
その3。我々は長期の安定稼働を求めている。再現性も重要だ。
バージョンがきちんと振られるディストロでは、関係者が増えても共通の環境を整備しやすく、また後々になってその環境を再現しなくならなければいけない状況になった場合でも、割りと楽に目的のイメージファイルなりを見つけることができます。
逆にArchの場合、導入タイミングなどで各サーバのパッケージが異なっているといった事態は容易に起こり得ますし、これがサポートの手間になるということもあるでしょう。(実際にDigitalOcean
がそんな感じの理由でサポートを廃止予定)
ですので、Archを導入する場合にはどのパッケージをどのバージョンで採用するか、といった調整は必要になります。
一見面倒くさいですし、他のディストロではやらなかった作業ですので、現場の不満は貯まるかもしれないですね。。
しかし、視点を数年後にずらして考えると、逆にバージョンごとに区切られていることが問題となることがあります。というか個人的にはよく見かけます。特に元プロジェクトから数度にわたって改良されてきたプロジェクトでは、改良の度に最小限の修正しか行われないことがあります。 よくあるのは
- 使うパッケージが古いもので固定されてしまう(脆弱性や非互換の問題は黙殺)
- 5年後くらいに唐突に納入物の更新要望が来るが、もちろんパッケージなどは更新できない
などといったもので、よく考えずとも明らかにお客さんと現場双方で不幸になっています。こうした事例は一般的ではないのかもしれませんが、官公庁でいまだにStruts1で構築されたサービスが動いているという話を見ても、決してレアケースではないと思います。
サービスの長期的なメンテナンスを考えると、ぱっと見のとっつきやすさが全体のためになるかどうかは別問題ではないでしょうか。
その4。systemdなんてよくわからない代物は使えない。
よくあるLinuxの入門書ではCentOSやDebianを対象ディストロとしているものが多く、initやUpstartに慣れ親しんだ人が多いでしょう。しかしArchは2012年よりsystemd
を採用しています。
そのため、既存のLinuxサーバ管理者からすると、Archを利用する場合には「余計な」学習コストが発生します。「今すでに動いているものがあるのに、何故わざわざ違うものを勉強し直す必要があるんだ」といった感じの意見は割りとよく聞きますし、個人的には色々とツッコミを入れたい考え方でもありますが、そのお気持ち自体はわかります。
しかし、時代は変わっていきます。systemdは
- Arch以外でもFedoraやopenSUSEなどで導入済
- RHEL(つまるところCentOSも)でもVersion 7から導入予定
- Debianも次期メジャーリリースであるJessieから採用
といったように、次の時代のサービス管理ツールとしてほぼ絶対的な位置にいます。 Ubuntuは依然Upstartを採用していますが、移行を提案する人も出ているようですし、次のLTSまでにsystemdを採用するかもしれません。
最近はsystemdに関する日本語の資料も増えてきていますし、そろそろ触っておいても良いのではないかと思います。
その5。インストールが大変
公式Wikiには日本語でも丁寧な導入ガイドがあり、それに従えば何ら問題なくインストールできます。 が、CentOSやDebianなどのインストールのしやすさに比べれば、色々と設定しなくてはいけない部分が多い気がします。
しかし、そういった部分にもきちんと触れることで、Linuxユーザとしても成長しますし、OSへの深い理解も得られるのではないでしょうか。
本音ベースですと、やっぱり面倒くさいです。ですが、実際問題としては気になりません。というのも
- インストール直後の状態を仮想イメージで持っておけば良い
- 最近ではchefやansibleがある
- docker用コンテナのイメージもdocker側で用意されている
ので、今後いちから人が手動でインストーラを叩いて設定するなんてことは減っていくからです。むしろ、現状そうした環境になっていない場合は猛省して、速やかに環境整備して自動化へと移行すべきかと思います。
100台近いサーバを日々手作業でOSインストールして 構築するお仕事、というのを実際に聞いたことがありますが、それは人のやる仕事ではありません。。
その6。pacmanなんて独自ツールは覚えたくない
そんなことより、個人的には商標権とか大丈夫なのかなって思ったりしています。これがmicky
ていう名前だったら間違いなく訴えられていると思います。
pacman、たしかにaptitudeとかと比べて最初は良くわかりませんし、できることも多いですが、個人的には好きです。
その7。Haskellを簡単に導入できない
サーバサイドHaskellとか胸熱ですが、完全に門外漢です。Archにはユーザが独自に作成、登録したパッケージを導入する仕組みがあり、そこにHaskellの各種ライブラリも登録されています。
が、これは罠です。実際にpandoc
を入れようとしてかなりハマりました。諦めてHaskell公式からソースコードを入手し、手動でセットアップしましょう。
その8。そもそもArchなんて誰も使っていない
(´・ω:;.:…
まとめ
ここまで見てきて、ArchをサーバOSにしないのは、単に趣味や主義主張の問題か、あとは単に担当者や責任者の理解不足であるような気がしてきました。
ArchはGentoo同様、とっつきづらいイメージがありますが、最初のインストールさえ乗り越えられれば、比較的メンテナンスのしやすいディストロだと思います。 ネット上を探せば、仮想環境向けにも色々とイメージファイルが公開されているので、そうしたものを使えばインストールさえ不要です。
何より軽量軽快で、ディスクサイズやメモリサイズも主要ディストロに比べて小さくて済みます。
ぜひ、気軽に触ってもらいたいと思います。
参考になった記事など
記事で言及したもの、しなかったもの含めて。最後のやつはネタですね。
Is Arch Linux suitable for server environment? - Server Fault
2014年2月21日号 systemdへの移行、Ubuntu Phoneの採用状況、UWN#355:Ubuntu Weekly Topics - gihyo.jp … 技術評論社
Why does Haskell suck on Arch? : archlinux