Ubuntu20.04サーバーを最新の状態に保つ方法

投稿日: 2022-04-20 2022-04-20
タグ: Automated Setups, Ubuntu 20.04

序章

このチュートリアルでは、Ubuntu20.04サーバースタックを最新の状態に保つためのいくつかのベストプラクティスについて説明します。ネットワークセキュリティ強化と同様に、サーバーが将来の介入なしに安全に動作し続けることを保証するために実行できる多くの手順があります。

自動的に構成されたもの以外にも、ほとんどのUbuntuサーバーに適用できるツールと構成がいくつかあります。独自のサーバー管理を行っている場合、すべての環境に手動でパッチを適用すると、非常に混乱し、エラーが発生しやすくなります。

このチュートリアルの内容は次のとおりです。アプリケーション管理のベストプラクティスに従って正常な再起動をテストし、メンテナンスの更新による問題を最小限に抑えます。マシンで実行されているほとんどのパッケージとライブラリの自動更新の構成ライブカーネルパッチ、およびカーネル更新に関するその他のベストプラクティス

前提条件

Ubuntu20.04サーバーとsudo権限を持つroot以外のユーザー。これらの権限を持つユーザーを設定する方法の詳細については、 Ubuntu20.04を使用したサーバーの初期設定ガイドをご覧ください。

ブラウザのインタラクティブ端末を使用してこのチュートリアルのコマンドを試してみたい場合は、下のインタラクティブ端末の起動！ボタンをクリックしてください。

ステップ1-アプリケーション管理のベストプラクティスに従う

自動アップグレード用にサーバーを構成する基本的な部分は、サーバーで実行されているすべてのアプリケーションが、計画外のダウンタイムまたは再起動後に正しく再起動できるようにすることです。 Linuxパッケージマネージャーは、バックグラウンドで無停止で実行されるように設計されているため、必要なメンテナンスに追加のオーバーヘッドが発生することはありません。それにもかかわらず、適切な更新戦略が実施されていない最も一般的な理由の1つは、再起動後のサーバーの動作に関する懸念です。

可能な限り、スタック内のアプリケーションはサーバーのinitシステムによって管理する必要があります。これは、Ubuntuを含むほとんどの最新のLinuxディストリビューションではsystemdです。 Systemdは、実行中のサービスと対話し、必要に応じてサービスを自動的に再起動するためのsystemctlコマンドを提供します。パッケージマネージャーを介してインストールされ、バックグラウンドで実行するように設計された実質的にすべてのソフトウェアは、ベストプラクティスとしてsystemdサービスと構成ユニットファイルを自動的に提供する必要があります。

独自のソフトウェア、またはGitリポジトリからデプロイされたソフトウェアを実行する場合、systemdと統合するために独自のユニットファイルを作成することは悪い考えではありません。軽量の代替手段として、スーパーバイザーのようなツールを使用することをお勧めします。システムのcronスケジューラーを@reboot構文で使用することもできます。

構成が完了したら、必ず再起動してテストしてください。 sudo shutdown now -rを実行すると再起動できます。これにより、実行中のプロセスが完全に停止し、すぐに再起動します。将来の再起動をスケジュールするために、nowの代わりに、 hh：mm で時刻、または今からの分数を指定することもできます。通常、本番環境の展開では、計画外の停止後に注意を払う必要はなく、必要なすべてのサービスとエンドポイントが自動的に復旧する必要があります。

メンテナンスの再起動によって環境が問題なく持続することを確認したので、次のステップでは、自動更新をスケジュールする方法を学習します。

ステップ2–無人アップグレードの構成

Ubuntuのパッケージマネージャーaptには、システム全体のアップグレードを実行するための確立されたワークフローがあります。まず、apt updateを実行してパッケージリストを更新し、次にパッケージを指定せずにapt upgradeを実行して、システム上のすべてのパッケージをアップグレードします。サードパーティのパッケージとバージョンの競合がある場合、または一部のパッケージを意図的にアップグレードせずに保持している場合、このワークフローはわずかに異なる可能性がありますが、コアコマンドは同じです。

Ubuntuは、サーバーのセキュリティパッチやその他の重要なアップグレードを自動的に取得してインストールするために、unattended-upgradesと呼ばれる独自のツールを提供しています。ほとんどのUbuntuサーバーには、このツールが自動的にインストールおよび構成されていますが、次のaptコマンドを使用してインストールできます。

sudo apt update
sudo apt install unattended-upgrades

インストール後、systemctlを使用してunattended-upgradesサービスが実行されていることを確認できます。

sudo systemctl status unattended-upgrades.service

Output● unattended-upgrades.service - Unattended Upgrades Shutdown
     Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2022-02-14 17:51:49 UTC; 3h 4min ago
       Docs: man:unattended-upgrade(8)
   Main PID: 829 (unattended-upgr)
      Tasks: 2 (limit: 1137)
     Memory: 10.6M
     CGroup: /system.slice/unattended-upgrades.service

unattended-upgradesのデフォルト設定では、Ubuntuリポジトリに含まれるほとんどのパッケージのバグ修正とセキュリティアップデートが自動的に取得されます。ただし、アップストリームの変更を回避するために一部のパッケージの古いバージョンを使用している場合、またはサーバーがUbuntuに加えてサードパーティのパッケージリポジトリを使用している場合は、unattended-upgradesサービスをさらに構成できます。

その構成は/etc/apt/apt.conf.d/50unattended-upgradesに保存されます。 nanoまたはお気に入りのテキストエディタを使用して、このファイルを開きます。

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

このファイルには適切な注釈が付けられており、その機能を説明する多くのコードコメント（//で始まる）を見ることができます。最初の構成ブロックは、Ubuntuパッケージリポジトリ名のテンプレートと一致して、自動的に更新されるパッケージを処理します。コアリポジトリと-securityリポジトリ内のファイルはデフォルトで更新されますが、-updates、-proposed、および-backportsリポジトリを含む行はコメント化されますデフォルトでアウト。

これらのリポジトリは、インストールされているパッケージに重大な変更が含まれている可能性が高いため、デフォルトで無効になっています。無人アップグレードを手動で有効にするために、これらの行から//コメント記号を削除できます。

/etc/apt/apt.conf.d/50unattended-upgrades

// Automatically upgrade packages from these (origin:archive) pairs
//
// Note that in Ubuntu security updates may pull in new dependencies
// from non-security sources (e.g. chromium). By allowing the release
// pocket these get automatically pulled in.
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
        // Extended Security Maintenance; doesn't necessarily exist for
        // every release and this system may not have it installed, but if
        // available, the policy for updates is such that unattended-upgrades
        // should also install from here by default.
        "${distro_id}ESMApps:${distro_codename}-apps-security";
        "${distro_id}ESM:${distro_codename}-infra-security";
//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};
…

ファイルのさらに下には、true /false構成の切り替えを伴ういくつかのオプションがあります。たとえば、有効にするために再起動が必要なパッケージのインストール後に自動的に再起動するトグルがあります。このオプションを有効にするには、//コメント記号を削除し、falseをtrueに変更します。ただし、そうすると、予測できない間隔でサーバーが使用できなくなります。このオプションを有効にする場合は、アプリケーションまたはユーザーがダウンタイムに耐えられることを確認してください。

/etc/apt/apt.conf.d/50unattended-upgrades

// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

編集が完了したら、ファイルを保存して閉じます。 nanoを使用している場合は、Ctrl+Xを押し、プロンプトが表示されたらYを押して、Enterキーを押します。

構成を変更した場合は、unattended-upgradesサービスをリロードして有効にします。

sudo systemctl reload unattended-upgrades.service

これで、サーバー上のすべてのパッケージが追加の介入なしに重要なセキュリティ更新プログラムを確実に受信できるようにするためのソリューションが用意されているはずです。最後のステップでは、カーネルを最新の状態に保つ方法と、必要なときにサーバーの再起動を処理する最善の方法を学習します。

ステップ3–カーネルの更新とライブパッチ

他のパッケージよりも少ない頻度で、システムのカーネルを更新する必要があります。 Linuxカーネルには、（ほぼ）実行中のすべてのハードウェアドライバーが含まれており、ほとんどの低レベルのシステム相互作用を担当します。カーネルの更新は通常、対処すべき注目度の高い脆弱性がある場合、公開されている新しいカーネル機能を利用する必要がある場合、またはカーネルが古くなりすぎてバグや脆弱性が蓄積するリスクが高くなる場合にのみ必要です。あなたは気づいていないかもしれません。

Linuxカーネルの更新を自動的にスケジュールする普遍的な方法はありません。これは、カーネルの更新にはこれまでシステム全体の再起動が必要であり、環境を想定せずに再起動をスケジュールすることは不可能であるためです。多くのサーバーは、可能な限り24時間年中無休の可用性を提供することが期待されており、再起動には不明な時間がかかるか、手動による介入が必要になる場合があります。

ある程度のダウンタイムを許容する場合は、カーネルの更新は簡単です。無人のapt更新は、他のパッケージと一緒に新しいカーネルをインストールして準備するように構成でき、再起動後、サーバーは自動的に新しいカーネルを使用する必要があります。ほとんどの本番環境では、サービスの可用性を確保するために、このような再起動に関してさらに複雑にする必要があります。たとえば、ロードバランサーを使用して、トラフィックをサーバーに自動的にリダイレクトします。サーバーは、目に見えるダウンタイムを回避するために、水平方向にスケーリングされた展開で、サーバーを個別に順番に再起動しながら、同じ機能を提供できます。

Livepatchを有効にして、カーネルの更新中にサーバーの稼働時間を確保する

カーネルのアップグレード中のダウンタイムを回避するために、ライブパッチと呼ばれるLinuxカーネルの機能を使用できます。この機能により、再起動せずにカーネルの更新を実装できます。カーネルライブパッチには、2つの主要なメンテナがあります。Ubuntu用に独自の Livepatch Service を提供するCanonicalと、他のほとんどの主要なLinuxディストリビューションに加えてUbuntuをサポートするKernelCareです。どちらも使用するには登録が必要であり、Canonicalのサービスのみが個人使用のために無料です。

Livepatchキーは、https://auth.livepatch.canonical.com/で登録できます。登録後、canonical-livepatchスナップパッケージをインストールできます。 Snapは、aptと一緒に実行されるもう1つのUbuntuパッケージマネージャーです。

このページでインタラクティブ端末を使用している場合、テスト環境の制限により、このセクションのコマンドを実行できないことに注意してください。

sudo snap install canonical-livepatch

canonical-livepatchは、次のWebサイトのキーを使用して1行のコマンドで有効にできます。

sudo canonical-livepatch enable your-key

出力にはメッセージSuccessfully enabled device.が含まれている必要があります。サービスは今後、これ以上介入することなくバックグラウンドで実行され、canonical-livepatch statusを使用してそのステータスを確認できます。

sudo canonical-livepatch status

Outputlast check: 55 seconds ago
kernel: 5.4.0-26.30-generic
server check-in: succeeded
patch state: ✓ all applicable livepatch modules inserted
patch version: 84.1
tier: updates (Free usage; This machine beta tests new patches.)
machine id: d56589e7fa994005a266d4caf9b9dcf7

これで、サーバーの自動カーネル更新が構成されました。つまり、安全で最新の環境を維持するために再起動する必要はありません。

結論

このチュートリアルでは、Ubuntuサーバーを自動的に更新するための複数の戦略について説明しました。また、パッケージリポジトリ、カーネルの更新、サーバーの再起動の処理の微妙な違いについても学びました。これらはすべて、DevOpsとサーバーをより広範に操作するための重要な基本であり、ほぼすべての本番構成はこれらのコアコンセプトに基づいています。

次に、Ubuntuのパッケージ管理について詳しく知りたいと思うかもしれません。 Snapパッケージ形式の詳細については、チュートリアル Ubuntu18.04でSnapアプリケーションをパッケージ化して公開する方法をご覧ください。

getdocs

13036