オープンソースCMS Zope+Plone3.2.x をアップグレードする


Plone3.0ではじまったPython eggの導入がPlone3.2で完了した。これにより、Plone3.2以降のヴァージョン間のアップグレードがとても簡単になったが、不安も残った。

神経質だったPloneのメジャー/ミドル・アップグレード作業

従来、Ploneのアップグレードは、特にミドルバージョンやメジャーヴァージョンが異なる場合は、神経質な作業だった。
Plone3.0から始まったPython eggの導入がPlone3.2で完了し、すべてのコンポーネントはPython eggベースとなった。Python eggは、javaのMaven、phpのPearのように、オンラインでライブラリをダウンロード、組み込むことができる仕組みだ。Plone3.2は、Plone自身やバンドルされたZopeも含め、すべてのコンポーネントをbuildout機能によりオンラインで管理できるよう構成されている。

今回、Plone3.2.2からPlone3.2.3へのアップグレードに際して、buildoutで行ってみることにした。

buildoutでPloneをアップグレードする

buildout.cfgの変更

インスタンスディレクトリ直下(デフォルトでは/usr/local/Plone/zinstance)に、「versions.cfg」という設定ファイルがある。このファイルには、そのインスタンスを構成するすべてのegg、プロダクトのヴァージョンが記載されている。以下は、Plone3.2.2付属のversions.cfgの冒頭部分。buildout機能そのものやZope2, Ploneも定義されている。

[versions]
# Buildout infrastructure
buildout.eggtractor = 0.6
plone.recipe.zope2install = 2.6
plone.recipe.zope2instance = 2.7
setuptools = 0.6c9
zc.buildout = 1.1.1
zc.recipe.egg = 1.1.0
zope2-url = http://www.zope.org/Products/Zope/2.10.7/Zope-2.10.7-final.tgz
# Plone release
Plone = 3.2.2
Products.ATContentTypes = 1.2.7
Products.ATReferenceBrowserWidget = 2.0.3
………

Ploneをインストールした直後は、このファイルを参照してインスタンスの起動が行われる(インターネットに接続されていない状態でbuildoutを可能にすることが目的)。一方、このローカルファイルではなく、インターネットに公開されたversion.cfgを参照して起動するように設定すると、Zope、Ploneのヴァージョンアップも可能になる。この指定は、以下の手順で行う。

/usr/local/Plone/zinstance/buildout.cfg (デフォルト)

[buildout]
############################################
# Plone Component Versions
# ————————
# This version of the Unified Installer has the components
# of Plone 3.2.2 preloaded so that it can install without
# an Internet connection.
# If you want to update, uncomment the “extends = http://…” below,
# edit it to point to the current version URL,
# comment out the “extends = versions.cfg” line
# and run bin/buildout -n
# while attached to the Internet.
#
#extends = http://dist.plone.org/release/3.2.2/versions.cfg (←公開版version.cfgのURL)
extends = versions.cfg
versions = versions

変更手順は以下のとおり。

「extends=version.cfg」の行の先頭に「#」を挿入し、コメントアウトする。
「extends=http://dist.plone.org/release/3.2.2/versions.cfg」の先頭の「#」を削除し、この行を活かす。
「extends=http://..」の行内の「3.2.2」をアップグレードする目的のヴァージョン「3.2.3」に変更する。

extends = http://dist.plone.org/release/3.2.3/versions.cfg
# extends = versions.cfg
versions = versions

buildoutする

グレードアップを目的としたbuildoutは以下のように「-n」パラメータを付加して実行する。

# cd /usr/local/Plone/zinstance/
# bin/buildout -n

buildoutの実行が始まると、まずbuildoutそのもののダウンロード/ビルドが行われ、最初に起動したbuildoutのインスタンスが更新ヴァージョンに切り替えられ、その後のbuildout工程が継続される。

途中、多数のSyntax Errorが表示されるが、大半は「関数定義の外側にreturnがある」というもので、無視可能。

一方、versions.cfgに基づく各eggのダウンロード/ビルドが最終局面に差し掛かったあたりで、「セッションタイムアウト。ダウンロードが完了しなかった」旨のエラーメッセージが表示された。だが、buildout工程はエラー終了されず結局、最後まで実行されたがログを精査しても原因不明だった。

ダウンロードされたeggの場所

buildout の実行によりダウンロード/ビルドされたeggは以下のディレクトリに収容されている。

ダウンロードされたファイル /usr/local/Plone/buildout-cache/downloads/dist/
展開・ビルドされたegg /usr/local/Plone/buildout-cache/eggs/
Plone3.2.3のversions.cfgファイル(http://dist.plone.org/release/3.2.3/versions.cfg)と、各eggのダウンロードファイル、ビルド結果を比較精査したが、異常が認められないので、試しにZopeインスタンスを起動した。インスタンスは正常動作し、一連の動作テストについても異常は見られない。エラーメッセージの原因は不明。

もしビルドに失敗したeggがあったとしたら

万一ビルドアウト作業途中にeggのダウンロード/ビルドアウトに失敗した場合、再度buildoutを実行すれば、不足しているeggがあれば、再度ダウンロード/ビルドは行われる。もし、当該eggのエントリがbuildout-cache内にある場合は、downloads, eggsディレクトリ両方で削除してからbuildoutを実行すれば良い。利用開始後に誤っていずれかのeggの内容を壊してしまったというような場合にもこの方法で再生が可能だ。

サイトマイグレーション

buildoutが完了したら、既存のPloneサイトのマイグレーションを行わなければならない。

Webブラウザでhttp://<ホスト名>/manageをアクセスしZMI画面を表示。マイグレートするサイトを選択し、表示された画面でplone_migrationsを実行。

「instance version」「filesystem versioin」ともに正しいことを確認し、dryrunを実行する。dryrunはテスト実行であって更新は反映されない。dryrunが成功したら、今度は本当に実行し、サイトをマイグレートする。

終了したら、「instance versioin」と「filesystem version」を比較し、いずれも目的のヴァージョンになっていれば成功。

感想

buildoutが便利だといっても、アップグレード作業の前のバックアップが必須であることは言うまでもない。インストールディレクトリごと、rsyncやcp -aで安全な場所にコピーしておけばすむことだ。

buildoutによるアップグレードは簡単で便利だが、途中過程で問題が発生したのかしないのか、出力されるメッセージからいまひとつ確証が持てなかった。特に、「セッションのタイムアウト、ダウンロード未完」の件については、本当にダウンロードできなかったeggがあるのか、あるいは、スプリアス的表示なのかわからない。本当にダウンロードできないeggがあったのであれば、インストールの中断/継続を選択ようなステップがあったほうが良い。

すべてのオンラインアップデートについて言えることだが、人気のある製品ほどアップデートファイルを提供するサーバは相当な負荷耐力が要求される。Ploneの場合、アップグレード用サーバやネットワークのバンドワイズがどのくらいあるのか知らないが、buildout -nを実行した印象では、十分な応答速度であった。

JavaのException以上に饒舌なPythonのメッセージが、buildout -nでは大量に吐き出される。その中から核心に触れるメッセージが発見できるとは限らない。今回のような異常の発生が通報されながら一方buildoutが完了してしまうと不安は残るが、疑いのあるeggをbuildout-cacheから削除しbuildoutを再度実行すれば、eggそのもののバグでない限り、やりなおしは効く。

eggでない旧態のZope Productが実装されている場合、そのproductの内容によっては、バックアップ- 新規インストール – 調整 – Data.fsの復旧という従来の手順を踏む必要があるかも知れない。