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

投稿日: 2022-10-11 2022-10-11
タグ: 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、実行中のプロセスを完全に停止し、すぐに再起動します。代わりに、 hh：mm で時刻、または今からの分数を指定することもできます now 将来の再起動をスケジュールするため。計画外の停止後は、通常、本番環境への展開に注意を払う必要はなく、必要なすべてのサービスとエンドポイントが自動的に復旧する必要があります。

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

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

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

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

sudo apt update
sudo apt install unattended-upgrades

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

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は、一緒に実行されるもう1つのUbuntuパッケージマネージャーです。 apt.

sudo snap install canonical-livepatch

有効にすることができます canonical-livepatch 彼らのウェブサイトからのキーを使用して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