#dd6e6e}ikapblogITおおめ、忘れそうなことを書き留めますホームdocker上で動かすwordpressのサイトヘルスを改善する2020.01.24wordpressのサイトヘルスを改善した。レンタルサーバとかでなく、dockerで運用中なので、資料が少なくて難儀した。他にも更新関係があるが、テーマやプラグインの更新などは、特別な理由がなければ、通知の度に更新しておきたい。APIでエラーが発生しました2は同じ原因で発生しているため、ひとまとめとした。unreachable。PHPバージョンの対処docker環境なので、wordpressのイメージをpullすればいい。Hubにて、イメージの確認をしておいた。確認が済んだら、イメージをpullする。wordpress:<tag><tag>は、適切なものを指定する。基本的には、これまで使ってきたイメージのタグを同じになるはず。自分の今回の場合は、fpm-alpine。イメージサイズが大きくなった。あとは、走らせているコンテナで最新イメージを使うようにすればいい。-dとするだけでOK。あとは、使わなくなった古いイメージが不要なら削除する。イメージのリストから、不要なイメージのIDを探す。<old_image_id>これで、PHPのバージョンは新しくなっているはず。ついでに、他のPHPが原因となりそうなサイトヘルスの問題も直ったりする。unreachableの対処これは結構面倒だった。問題の切り分け自環境では、リバースプロキシと他のサービスを別のdocker-composeで運用している。https://<domain>.tldのようなことを行うようだ。これはサイトヘルスの項目詳細のところから類推したもの。unreachableとなり、到達できない。そこで、dockerのホストのログをみてみることにした。/var/log/messagesなどでログを閲覧可能だが、エラーログの設定をfirewall-cmdで行う必要がある。..`を行いエラーを記録する。/var/log/messages...エラーがある。(後述)エラーは次のようなものだった。URGP=0SRCはwordpressコンテナのIPアドレスだった。INは、docker-composeのymlファイルでコンテナ(というかサービス)に当てたネットワークに対応して、dockerによって生成された仮想ブリッジだった。)以上から、原因は、ホストのbr-************インターフェースに到達したパケットが破棄されてしまうためだとわかった。破棄されないようにすればいい。Overflowが、参考になった。本来は、docker内部からのパケットは、docker0インターフェースをデフォルトゲートウェイとするはずだが、別の内部へのパケットだから、デフォルトゲートウェイを経由しないのかもしれない。話を戻して、破棄されないようにするには、dockerのホストで設定を行えばいい。centos7で行っているので、firewall-cmdを使用。参考にあるdocker0だけでは解決しなかった。--reloadこれで、解決。open到達可能になっていることが分かる。修正完了これにて、作業が面倒なサイトヘルスの問題はすべて解決できた。仮想ブリッジ関連のホストの設定は、ネットワークのIDが変わったら再び設定する必要がある懸念が存在している。そのため、br-***のIDの発見方法も記しておく。...この、<network_id>がbr-の後ろに続くようだ。これで、ネットワーク設定が再生成された場合でも、設定し直せるはずだ。課題dockerのnetworkingについて勉強不足が実感された。ネットワークについての資料はあまり探していなかったので、今後時間を見つけて探して熟読していくようにしたい。volumeにデータの追加ができない問題。記事のタイトルは全角でもOK。冗長になりすぎないようにする。タイトルは公開の直前の入力でいい。その後パーマリンクを修正すること。パーマリンクは半角英数字のみにする。lxmlのインストールでエラーが起きるDockerのalpine上でのpipenvでlxmlのインストール時に以下のエラーがでる。自由でないと感じるFC2ブログからwordpressへ移行した。その手順を残しておく。wordpressの方は始め検索エンジンによるインデックス化をしないようにしている。python:3.7-alpine3.8でpsycopg2のインストールに失敗するDockerのpython:3.7-alpine3.8で、postgresqlのドライバpsycopg2をインストールする。そのままでは失敗する。Analyticsのスクリプトを埋め込むため。タイトルとURLをコピーしました。