更新を安全にデプロイするためのベストプラクティス
Amazon Linux 2023 (AL2023) には、オペレーティングシステムの更新を安全にデプロイし、更新間で何が変更されたかを把握したうえで、必要に応じて簡単に以前のバージョンに戻せるように設計されたいくつかの機能があります。このセクションでは、AWS が Amazon Linux を社内外で 10 年以上運用してきた中で得られた教訓について説明します。
警告
dnf --releasever=latest update を実行することはベストプラクティスではありません。これを実行すると、OS の更新が最初に本番環境でテストされる結果を招く可能性があります。
latest を使用する代わりに、特定の AL2023 リリースバージョンを使用してください。これにより、以前にテストしたのと同じ変更を本稼働インスタンスにデプロイできます。例えば、dnf --releasever=2023.9.20250929 update を使用すると必ず 2023.9.20250929 リリースに更新されます。
詳細については、「AL2023 ユーザーガイド」の「AL2023 の更新」を参照してください。
OS 更新のデプロイの安全性を計画しない場合、アプリケーションやサービスと OS 更新の間で想定外のマイナスの相互作用が発生した際の影響が大幅に大きくなり、最悪の場合、全面的なサービス停止に至る可能性があります。ソフトウェアの問題と同様に、問題が検出されるのが早いほど、エンドユーザーへの影響が少なくなります。
OS 更新について、根本的に誤っている 2 つの思い込みに陥らないことが重要です。
OS ベンダーが OS の更新においてミスをすることはない。
ユーザーが依存する OS の特定の動作またはインターフェイスが、OS ベンダーが依存対象と見なす動作とインターフェイスと一致している。
つまり、OS ベンダーとユーザーが、更新に問題があったと同意できる。
善意に頼らず、あらゆる OS の更新において、デプロイの安全性を確保できるシステムを構築する必要があります。
本番環境にデプロイして、新しい OS 更新をテストすることはお勧めしません。ベストプラクティスは、OS をデプロイの構成要素の 1 つと見なし、本番環境への他の変更に適していると思われるものと同様のデプロイ安全メカニズムの適用を検討することです。
ベストプラクティスは、本番環境システムにデプロイする前に、すべての OS 更新をテストすることです。デプロイ時は、段階的なロールアウトと適切なモニタリングの併用をお勧めします。段階的なロールアウトにより、問題が発生した場合でも、即時ではないにしても影響をフリートのサブセットに限定できます。また、調査と影響の軽減を実施する間、その後の更新のデプロイを停止できます。
OS の更新による悪影響の軽減は、問題がどこにあっても、多くの場合において最優先事項であり、その次が問題の解決になります。OS 更新の導入が悪影響と相関する場合に、正常動作が確認されている以前の OS のバージョンにロールバックできる機能は強力なツールとなります。
Amazon Linux 2023 では、OS (または個々のパッケージ) のバージョンへの変更が繰り返し可能になる強力な新機能の バージョン管理されたリポジトリを介した確定的なアップグレード が導入されています。そのため、ある OS バージョンから次の OS バージョンへの移行時に問題が発生した場合でも、問題の解決策を検討しながら、既知の正常動作バージョンの使用を継続するため簡単なメカニズムが利用できます。
AL2023 では、新しいパッケージ更新をリリースするたびに、ロックする新しいバージョンと、そのバージョンにロックされる新しい AMI があります。AL2023 リリースノートでは、各リリースの変更と、パッケージの更新で対処されたセキュリティ上の問題AL2023 に関する Amazon Linux セキュリティアドバイザリについて説明します。
例えば、2023.6.20241028 リリースに存在する問題の影響を受けた場合、AMI とコンテナ イメージを使用して、以前の 2023.6.20241010 リリースに素早く戻すことができます。この場合、後続の 2023.6.20241031 リリースでパッケージのバグが修正されましたが、バージョン管理されたリポジトリを介した確定的なアップグレード により、影響を受けるすべてのユーザーが以前のイメージを使用するだけで、即座に即座に影響を緩和するための簡単な措置を取ることができました。
また、バージョン管理されたリポジトリを介した確定的なアップグレード は、進行中の OS 更新のデプロイが、現在の環境での更新または新たなAMIまたはコンテナイメージの起動によって、後続としてリリースされる OS 更新の影響を受けないことを保証します。
この最初の例では、フリート A は 2023.5.20241001 から 2023.6.20241010 リリースへの更新デプロイ途中の大規模なフリートです。ここで、2023.6.20241028 リリースが公開されました。バージョン管理されたリポジトリを介した確定的なアップグレード は、フリート A のデプロイが適用される更新内容に変更なく継続されることを意味します。
最初にフリートの 1% にデプロイし、次に 5%、10%、20%、40% を 100% に達するまでデプロイするといった段階的なデプロイ戦略の目的は、より広範囲に展開する前に、限られた方法で変更をテストできるようにすることです。このタイプのデプロイ戦略は、本番環境の変更をデプロイするためのベストプラクティスであると一般的に考えられています。
段階的なデプロイ戦略とフリート A の2023.6.20241010 への更新は、一度に多くのホストにデプロイされるステージにあり、2023.6.20241028 がリリースされたという事実は、バージョン管理されたリポジトリを介した確定的なアップグレード を使用しているため、進行中のデプロイには影響しません。
フリート B が古いバージョンである 2023.5.20240708 を実行中で、2023.6.20241028 への更新のデプロイを開始しており、フリート B がそのバージョンの問題の影響を受けた場合、デプロイの早い段階でこの問題に気付くでしょう。その時点で、当該問題の修正が利用可能になるまでロールアウトを一時停止するか、または同じバージョンである 2023.6.20241010 のデプロイを開始し、フリート B が 2023.5.20240708~2023.6.20241010 間のすべての更新をフリート B が取得できるようにするかどうかについて、判断することができます。
OS の更新をすぐに適用しない問題が発生する可能性があることに注意してください。新しい更新には、環境に関連するバグやセキュリティの修正が含まれている可能性があります。詳細については、「Amazon Linux 2023 でのセキュリティおよびコンプライアンス」および「AL2023 のパッケージとオペレーティングシステムとの更新を管理する」を参照してください。
新しい OS 更新を簡単に取得し、本番環境へのデプロイ前にテストできるよう、デプロイシステムを適切に構成することが重要です。また、段階的なデプロイなどの仕組みを利用して、悪影響を最小限に抑えることも重要です。OS 更新による悪影響を軽減するために、デプロイ システムに正常動作が確認されている OS の以前のバージョンへ切り替える方法を知っておくことが重要です。問題の解決後は、当該旧バージョンの使用を継続するのではなく、新しく、正常動作が確認されているバージョンに移行します。
マイナーな更新のための準備
OS の小規模な更新 (AL2023 の新しいポイントリリースなど) に向けた準備は、ゼロに近い手間で済むように設計されています。今後の変更については、AL2023 リリース ノートを必ずお読みください。
パッケージのサポート期間が終了すると、言語ランタイムの新しいバージョン (AL2023 での PHP など) への移行が必要になる場合があります。ベストプラクティスは、サポート期間が終了する前に、新しい言語ランタイム バージョンに快適に移行することで、事前にこれに備えることです。
pcre バージョン 1 などのパッケージの場合、事前に計画し、コードのいずれかを代替バージョンに移行する機会もあります。この場合、コードはpcreバージョン 2 です。万一の遅滞に備えて、できるだけ速やかに行うのがベストプラクティスです。
Berkeley DB (libdb) などに直接置き換えられない場合は、ユースケースに基づいた選択が必要になる場合があります。
メジャーな更新の準備
オペレーティング システムの新しいメジャー バージョンへの更新は、ほぼ普遍的に計画が必要とし、変更または廃止された機能に適応し、デプロイ前にテストを行う必要があります。Amazon Linux 2023 の次のメジャー バージョンへの移行準備を段階的に進めることは珍しいことではありません。廃止された機能や削除された機能の使用に対応してから、次のメジャー バージョンへの移行を進めるといった方法をとることができます。
例えば、AL2 から AL2023 に移行する場合、AL2 で廃止され、AL2023 で削除された機能 セクションを参照すると、AL2 を継続使用しながら AL2023 の準備をしている間に、安全で小さなステップでの段階的な移行が可能になります。例えば、yum パッケージ マネージャーなどの OS 使用以外のあらゆる Python 2.7 は Python 3 に置き換えられました の使用は、AL2023 の Python の使用に備えて Python 3 に移行できます。PHP を使用する場合、AL2 (PHP 8.2 AL2 Extra 経由) と AL2023 の両方が PHP 8.2 を搭載しているため、PHP バージョン移行と OS 移行の両方を同時に行う必要はありません。
AL2023 の使用中は、AL2023 を使用しながら、Amazon Linux 2023 の次のメジャー バージョンへの準備を今から行うこともできます。AL2023 で廃止 セクションでは、AL2023 で廃止され、削除される予定の機能とパッケージについて説明します。
例えば、init スクリプトなどの残存する System V init (sysvinit) の使用をsystemd に対応した同等のものに移行することで、将来へ備えるとともに、systemd 機能の全セットを使用して、サービスの監視、再起動の方法とその必要性、必要な他のサービス、リソースやアクセス許可の制限を適用する必要性の有無を判断できるようになります。
32 ビット サポートなどの機能の場合、廃止が OS の複数のメジャー バージョンにまたがる可能性があります。32 ビット版の場合、Amazon Linux 1 (AL1) は 32 ビット x86 (i686) AMI、Amazon Linux 2 は 32 ビット x86 (i686) パッケージ、Amazon Linux 2023 は 32bit x86 (i686) ランタイムのサポート をそれぞれ廃止します。IMDSv1 からの移行は、OS の複数のメジャー バージョンにも及びます。これらのタイプの変更については、一部のユーザーにおいて適応に長時間を要することが認識されているため、Amazon Linux 2023 で当該機能が利用できなくなるまで、十分な猶予期間が設定されています。
廃止機能のリストは OS のライフサイクルを通じて更新されるため、その最新の変更内容を常に把握されることをお勧めします。