Ubuntu Weekly Recipe

第647回 Ubuntu CoreなRaspberry PiをUbuntuサーバーとして使う

この記事を読むのに必要な時間:およそ 10 分

システムの自動アップデートの無効化

Ubuntu Coreは組み込み向けという扱いなので,サーバーとして使うためにはいくつか気をつけるべきことがあります。そのひとつが「自動アップデート機能(auto refresh機能⁠⁠」です。

セキュリティの観点に立つと,一般的にはアップデートは常に適用されているほうが望ましい状態となります。Ubuntu Coreはカジュアルな組み込み向け用途を想定しているため,できるだけメンテナンスフリーとなるべく,自動アップデート機能が有効化されています。具体的には6時間に一度,更新をチェックしアップデートを適用します。

しかしながらサーバーとして使う場合は,アップデート中のダウンタイムを考慮しなくてはなりません。特にsnapシステムにおいてベースシステムやカーネルのsnapパッケージが更新された場合は,自動的に再起動します。そこでsnapパッケージのアップデート機構の設定を見直しましょう。

自動アップデートのスケジュールについての詳細はsnapパッケージのドキュメントにあるManaging updatesの項目を参照してください。残念ながら現在のsnapシステムは,完全に自動アップデートを無効化する公式の方法は存在しません※6⁠。できるのは,最大60日遅らせるだけです。

※6
なぜできないかとか,何が必要かとか,歴史的経緯とかをどうしても知りたくて,なおかつ時間が十分に余っている人はこのあたりスレッドをたどると何か情報を掴める可能性があるかもしれませんし,ないかもしれません。

前回のアップデートと次のアップデート予定の日時は次の方法で確認可能です。

$ snap refresh --time
timer: 00:00~24:00/4
last: today at 17:01 JST
next: today at 22:53 JST

これを,次のように「60日遅らせ」ます。

$ sudo snap set system refresh.hold="$(date --date=+60days +%Y-%m-%dT%H:%M:%S%:z)"
$ sudo snap get system refresh.hold
2021-02-18T20:31:17+09:00

再度確認してみると,⁠次のアップデートはホールドされる」予定であることがわかります。

$ snap refresh --time
timer: 00:00~24:00/4
last: today at 17:01 JST
hold: in 60 days, at 17:01 JST
next: today at 22:53 JST (but held)

今の段階では,定期的にホールド期間を増やす方向でしか対応できなさそうです。このあたりはsystemdのタイマーユニットを使って自動化するというのもひとつの手でしょう。ちなみにsnap refreshを実行すれば手動でアップデートを実施できます。

なお,アプリが動いている間はアップデートさせない設定も現在実装中のようです。

Ubuntu Coreをサーバーとして使用するメリット

ここまでRaspberry Pi上のUbuntu Coreを普通のUbuntuサーバー化する方法を説明してきました。それではUbuntu Coreそのものはどんな用途で採用すべきでしょうか。最後にその可能性について考えてみましょう※7

※7
ここからはただの御託で,コマンド等は出てきません。やり方だけわかれば良いのであれば,今回の記事はこの手前までで読み終えても問題ありません。

利便性よりもセキュリティを重視する場合

あらゆるものがネットワークに繋がる時代において,⁠セキュリティ」が最も注力すべき項目であることに異論はないでしょう。

セキュリティは利便性とのトレードオフな関係になることが多々あります。つまりよりセキュアな環境にしようと思ったら,どこかで利便性を下げざるを得ません。よくある例がAppArmorをはじめとする,強制アクセス制御(MAC)でしょう。MACでガチガチに固めた環境を作ればセキュアになりますが,いろいろなものが動かなくなります。逆にゆるくしすぎると安全性が下がります。このあたりはディストリビューターやシステム管理者のバランス感覚にかかっているのです。

AppArmorの場合,サーバー版のUbuntuは可もなく不可もなくという無難な設定のみを有効化し,残りはユーザーに任せるというスタンスです。それに対して,Ubuntu Coreではよりきめ細かく設定しているため,⁠従来のツールが動かない」ということも多々あります。そもそもシステム管理者がインストールするソフトウェアは,原則としてsnapパッケージであるため,AppArmorやsecccomp等を活用してさらに厳しい制約がかけられています。たとえばsnapパッケージの中からは,基本的にルートファイルシステム上のほとんどのファイルにアクセスできないですし,ホームディレクトリすら明示的な権限の許可が必要です。

このように「基本的に禁止し,本当に必要なときだけ許可する」というスタイルで運用したいのであれば,Ubuntu Coreも選択肢となりえます。

さらにUbuntu Coreは,第646回でも紹介したように「物理的なセキュリティ」に対しても配慮しています。サーバーを誰でもアクセスできる場所に配置することは一般的にはあまりないものの,Raspberry Piのように小型デバイスであれば,小型であるがゆえの配置の自由度を活用するためにも,セキュアでない場所に置く可能性はあるでしょう。それを考えると,Ubuntu Coreのような「簡単にはログインできない」仕組みは有用となるはずです。

ちなみにUbuntu Coreのサイトでは「サポート期間が10年」を謳っていますが,Ubuntu Weekly Topicsの2019年1月25日号「注4」でも考察されているように,これは「UbuntuのLTSと同じで5年サポートし,残りの5年は有償サポート」という扱いだと思われます。このあたり公の場ではっきりと言明されることがないため,おそらく事実が判明するのは18.04の最初の5年サポートが終了する,2023年以降になるでしょう。

サーバーの上で動かすものがコンテナだけである場合

Dockerの登場以降「サーバーのアプリケーションはコンテナの中で動かす」手法がいろいろなサービスで当たり前に使われるようになってきました。

コンテナベースで運用する場合,必要なツールやライブラリは個々のコンテナの中に閉じ込めることが一般的です。そうなるとホストシステム自体は「最低限,コンテナシステムが動けば良い」になってきます。コンテナに関わらない余計なツールは極力省いたほうがセキュアになりますし,そもそも複雑なパッケージ管理システム自体不要になるかもしれません。実際,コンテナを動かすためのクラスタリングシステムの構築に特化した「Container Linux」なんてLinuxシステムも作られました。このContainer Linuxは最終的にRed Hatに買収され,その成果はFedora CoreOS/RHEL CoreOS(RHCOS)として活用されていることからも,その有用性はわかるでしょう。

Ubuntu Coreは「Ubuntu版のRHCOS」のような使い方が可能です※8⁠。つまりターゲットシステムに「ハイパーバイザーのような薄い管理層」としてインストールし,その上でコンテナを管理するという使い方です。コンテナのハイパーバイザーを自称するLXDや,Dockerツールはもちろんのこと,プロダクション用途でコンテナを使う上で外せないKubernetesに至るまで,そのソフトウェアや構築ツールがsnapパッケージ化されているために,Ubuntu Core上でも簡単に導入可能なのです。

※8
ちなみにRHCOSのベースになっているFedora CoreOSが700MB強のイメージなのに対して,Ubuntu Coreはその半分以下の300MB弱です。中身や機能の比較をしたわけではないので,この数字に意味があるかは不明ですが,Ubuntu Core「も」十分に小さいことがわかるかと思います。

コンテナ化による利便性のひとつが,アップデートプランの建てやすさです。一般的なOSの場合,主要なライブラリはさまざまなソフトウェアで共有されています。あるソフトウェアを更新しようとすると,特定のライブラリの更新も必要で,そうするとそれに依存する他のソフトウェアも更新しなければならず……という「依存関係地獄」に陥った結果,⁠何もしないのがベスト」に落ち着く経験をした人もたくさんいることでしょう。snap化やコンテナ化は,⁠特定のソフトウェアに必要なものは,そのソフトウェアの専用領域で提供する」スタイルのため,ソフトウェアごとに独立してアップデート可能です※9⁠。

※9
もちろん,主要なライブラリに深刻な脆弱性が見つかった場合,⁠全部のコンテナを個別にアップデートしなくてはならない」という別の地獄の作業が発生します。ただし依存関係地獄に比べると個々の作業を細分化しやすいため,⁠まだましな地獄」ではあるはずです。

つまりUbuntu Core自体は小さく作られているものの,snapという仕組みを介してモジューラブルかつセキュアに機能拡張でき,さらに必要なものはコンテナの中で管理できるということです。うまく動けば。

停電等の突然の障害時に対する耐久性がほしい場合

現代人にとって電気は空気と同じくらい重要です。空気を読むのは苦手だけれども,電気ならその流れも含めてすべて把握できる,という読者も多いでしょう。

商用のサーバーなら,安定的に電気が供給される環境に設置され,万が一のときも無停電電源装置(UPS)等によって適切にシャットダウンされるのが普通です。しかしながら個人用のサーバーで,そこまでするのはコスト的になかなか厳しいでしょう。Raspberry Piをサーバーとして使うなら,パススルー給電できるモバイルバッテリーをUPSとして使うという手はあるものの,通常のUPSのように「給電モードが切り替わったのでシャットダウンする」みたいな対応は難しいです。

また,Raspberry Pi固有の話として,ルートファイルシステムの冗長性を確保するのが難しいという制約もあります。もちろんSDブートは諦めて,USBやネットワーク経由のブートにすることで対応はできるものの,システムが複雑になりがちです。

Ubuntu Coreはシステムの基本部分を読み込み専用で用意し,書き込みできる領域は別パーティションに分離することで,不意の電源断にもある程度耐えられる作りになっています。あくまで,ある程度,です。システムが起動しなくなることはそうそうないものの,書き込み領域の不整合によりサービスが立ち上がらなくなる可能性は依然として残っています。⁠システムが起動しないからリモート経由でのリカバリーもできない」という問題は起きにくい作りになっている,程度の安心感だと思っておいてください。

とにかく,ここまでの話をまとめると,Ubuntu Coreを使えば「最初から何もしなくてもある程度セキュア」で,「コンテナを動かすために必要十分な小さなシステム」の,「多少雑に扱っても壊れにくい」サーバーを構築できるというわけです※10⁠。

※10
それはつまり「初期設定だとできることが少なく」⁠コンテナ以外の用途には使いづらく」⁠壊れるときは結局壊れる」サーバーであるとも言えます。

なお,逆に次のような用途だとUbuntu Coreよりは普通のサーバー版のほうがおすすめです。

  • Linuxサーバーの学習用途
  • システムをかなり細かくカスタマイズ・チューニングしたい
  • パッケージ化されていない独自バイナリ・PPAを多用したい
  • DKMSを利用したい

また,何度も言うようにあくまでUbuntu Coreのシステムは「壊れにくい」であって「壊れるときは壊れる」ことに変わりはありません。商用サーバーほどでもないものの「できる範囲で高耐性化」することで,おうちサーバーでもそれなりにメンテナンスフリーにしようというのが,本記事の主な目的です。

出来合いのものをそのまま使いたいもしくはカーネルのビルドから含めて全部自分でシステムを構築したい,という両極端なケースならUbuntu Coreを,その間に位置する用途なら普通のサーバー版を選ぶと良いでしょう。このようにサーバーとしてのUbuntu Coreの用途は限定されるものの,マッチすればとても便利な仕組みなのです。

著者プロフィール

柴田充也(しばたみつや)

Ubuntu Japanese Team Member株式会社 創夢所属。数年前にLaunchpad上でStellariumの翻訳をしたことがきっかけで,Ubuntuの翻訳にも関わるようになりました。