このCasaOS WordPressスレッドが示すこと
元の投稿では、BigBearCasaOSのWordPressインストールチュートリアルが紹介されていました。最も重要な続報はCPUアーキテクチャに関するものでした。Raspberry Pi 4のユーザーは当初、ARM64の非互換メッセージを確認しましたが、その後アプリのメンテナーがARM64対応を追加したと説明しました。一方で、別のユーザーは依然としてno matching manifest for linux/arm/v8エラーを報告しており、コンテナイメージのアーキテクチャを推測せず、確認する必要があることを示しています。
現在のZimaハードウェア環境では、選択したイメージがホストのアーキテクチャに対応していれば、ZimaBoard 2やZimaBladeなどのプラットフォーム上で、WordPressをコンテナ化されたWebスタックとして実行できます。
インストール前にアーキテクチャを確認する
CasaOSホストでは、マシンがamd64、arm64、または別のアーキテクチャのどれに該当するかを確認してください。必要なすべてのイメージに互換性のあるマニフェストがなければ、コンテナは起動できません。Dockerの公式マルチプラットフォームガイダンスでは、イメージマニフェストとプラットフォーム選択の仕組みがDockerのマルチプラットフォームドキュメントで説明されています。
現在のWordPressに対応したイメージを使う
公式のWordPressコンテナイメージでは、対応タグと一般的なデータベースの組み合わせが説明されています。過去のアプリストアテンプレートに頼らず、現在のイメージを確認してください。公式WordPress Dockerイメージ。
通常のWordPressデプロイメントでは、WordPressコンテンツ用の永続ストレージと、MariaDBやMySQLなどのデータベースも必要です。アプリテンプレートをアップグレードまたは置き換える前に、コンテンツボリュームとデータベースの両方をバックアップしてください。
CasaOSアプリストアと手動Compose
アプリストアのパッケージは、ポート、ボリューム、環境変数があらかじめ定義されているため便利です。手動でDocker Composeを使ってデプロイすると、イメージタグ、データベースのバージョン、ストレージの場所、アーキテクチャの選択をより細かく制御できます。コミュニティ製パッケージが古い場合や、ARM64対応タグが公開されていない場合は、対応済みの上流イメージを使った手動のComposeスタックのほうが適切な選択になることがあります。
インストール後に確認すること
- WordPressコンテナとデータベースコンテナが両方とも正常な状態であることを確認します。
- 外部公開する前に、ローカルでサイトを開きます。
- WordPressのコンテンツディレクトリとデータベースが永続ストレージ上にあることを確認します。
- 強力な管理者認証情報を設定し、プラグインとテーマを最新の状態に保ちます。
- イメージタグやデータベースのバージョンを変更する前にバックアップを作成します。
FAQ
なぜno matching manifest for linux/arm/v8と表示されるのですか？
選択したイメージタグに互換性のあるARM64マニフェストがないか、スタック内の依存関係の1つが依然としてアーキテクチャに制限されているためです。
CasaOS自体でx86専用イメージをARM上で動かせますか？
いいえ。アプリプラットフォームが、上流イメージに存在しないアーキテクチャを作り出すことはできません。
2023年のBigBearテンプレートをそのままコピーすべきですか？
現在のイメージタグ、環境変数、アーキテクチャ対応を確認せずに使うべきではありません。元のスレッドは過去のインストール状況として参照し、現在の上流イメージに照らして検証してください。
