Fess 13.11.2をリリースしました。13.11系のリリースをする予定はなかったのですが、13.11でdataformatプラグインを取り除いたら、バックアップ用のバルクファイルを出力する際にインデックス名が間違っていて、バルクファイルが正しくないという問題があり、リリースした感じです。それ以外は特に変更はないです。
Fess 13.12のリリース
Fess 13.12をリリースしました。
今回は依存関係の更新をメインに実施しました。順に見ていくと、
まず、依存関係更新まわりを見ていくと、ここにも書いたけど、JAFの依存関係が混沌としているので、整理しました。あとは、minioを更新していなかったので、最新化しました。その他にもTikaとか、細々とバージョンを上げたけど、細かいので省略。
データストアのパラメータ設定で、環境変数から渡す方法がほしいということで、追加しました。フォーラムで言われた話なのだけど、Kubernetes時代を考えると、その要望はわかる気がするので…。（でも、あまり動作確認してないので、問題があれば追加で修正すると思います…）
これまた、フォーラムでpruned tagの設定で、ハイフンが指定できない、という感じだったので、修正しました。
あとは、SonarCloudで指摘されるような内容を修正した感じです。
という感じで、特に目新しい改善はないですが、何かあれば、フォーラムとかに投げてください。
JAFの依存関係問題
Fessは依存しているJarファイルに含まれているクラスが重複しているかどうかをチェックしているだけど、JavaBeans Activation Framework(JAF)の依存関係が混沌としており、困っている。
ここに差分とかはまとめたけど、JAFは現状だと以下のものがある。
1) activation-1.1.1.jar
2) javax.activation-api-1.2.0.jar
3) jakarta.activation-api-1.2.2.jar
4) jakarta.activation-api-2.0.1.jar
今の世の中だと、jakartaのものがここでメンテされているので、これを使うべきなのだが、昔からあるライブラリなどは、activationを使っていたり、そんな簡単な話ではない…。
問題になるのは、依存しているライブラリがそれらのどれかに依存しているケースである。
2と3はほぼ同じと考えて良さそうなので、どちらもある場合は、2を依存関係から除外すれば良い。1と2を見ると、1にはcom.sunパッケージがあるので、これらを期待する場合は1を残す必要がある。3と4はパッケージ名が異なるので、3と4にそれぞれ依存関係が必要なライブラリがある場合は、2を追加しておくとか…。あまりにも混沌としている。
わかりにくすぎる感じがあるが、1〜4まですべてが必要な場合は、1と4だけがあれば、多くの場合で問題ないかなという感じがする。まぁ、できれば1でなく、3を使いたい気もするのが、4に打ち消されたりもするので…。
追記：jakarta.activationという-apiでなく、1のcom.sunパッケージが含んだものもあり、これを使えば、3とcom.sun.activationのjakarta.activation-2.0.1.jarを利用するパターンもあるらしい。なので、1と4より、このパターンのほうが良いかもしれない…。
Fess 13.11.1のリリース
Fess 13.11.1をリリースしました。
特に大きな変更点はないのですが、変更点を順に見ていくと、
まず、-Dfess.config.* や -Dfess.system.* でJavaのシステムプロパティに渡してあげると、fess_config.propertiesとsystem.propertiesの設定を上書きできる機能があるのですが、クローラーなどのジョブまで渡せていなかったので、渡すようにしました。Dockerとかで実行するときに、fess_config.propertiesを用意してマウントして実行するのも面倒なので、環境変数FESS_JVM_OPTSで必要なものだけ渡してあげると便利に使える機能です。
次に、/etc/default/fessからFESS_CONTEXT_PATHを削除しました。ここで指定していると、Dockerの実行時にコンテキストパスを変更することができないようなので…。とはいえ、コンテキストパスを変更する機能は、現時点で積極的にサポートする機能ではないので、動くかどうかは怪しいところではあります。
そして、このリリースからElastic CloudとAWS Elasticsearch Serviceの対応をはじめました。辞書編集など一部の機能が利用できませんが、Fessを手軽に利用することができる手段が一つ追加された感じだと思います。
という感じではありますが、何かあれば、フォーラムなどをご利用ください。
FessでAWS Elasticsearch Serviceの利用方法
FessがElastic Cloudに対応した話は前回書いたけど、今回は、AWSのElasticsearch Serviceにも対応したので、それについて書いておきます。
AWSのElasticsearch ServiceはElastic Cloudと違い、プラグインを変更することなどはできないので、Elastic Cloudの設定では動かないので、ES_TYPEにawsを追加して対応しました。それ以外は、Elastic Cloudと同じ感じです。
Elasticsearch Serviceを試すために、AWSコンソールに入り、Elasticsearch Serviceのドメインを作成して、試してみます。今回はローカル環境にFessのインスタンスだけを起動して、Elasticsearch Serviceに繋ぎにいく状態で説明します。AWS環境で実際に利用する場合には、FessのインスタンスはECSやEKSに置いて利用することになると思います。ですので、実際に運用する場合には、適切なAWSの権限設定をおこなってください。
AWSコンソールからElasticsearch Serviceにいき、ドメインの作成を押下すると、デプロイタイプの選択が表示されます。
今回は、テスト用に構築するだけなので、「開発およびテスト」を選択します。Elasticsearchのバージョンは、7.9を選択し、次へを押下します。
次に、ドメインの設定が表示され、ドメイン名を設定します。カスタムエンドポイントを利用しなければ、ドメイン名が含まれたURLになります。今回はただの検証が目的なので、自動調整は向こうにします。
データノードは想定する利用状況に適したものを選択します。今回はデフォルトのインスタンスタイプを選択します。t系のインスタンスでは動かないため、注意してください。その他のElasticsearchのノード設定も利用する状況に合わせて、設定してください。
設定ができたら、次へボタンを押下します。
アクセス関連の設定をします。今回はローカル環境から接続しにいくため、VPCでなく、パブリックなアクセスにして、マスターユーザー名とパスワードを設定します。このユーザー名とパスワードがFessからのアクセスで必要になります。アクセスポリシーには、アクセス元のIPを設定しておきます。このアクセス権限まわりの設定は、ご利用の環境に合わせて設定してください。
タグの追加は必要に応じて、設定して、次へボタンを押下します。
最後に設定した内容の確認が表示され、問題がなければ、確認ボタンを押下してください。10分くらいするとElasticsearchクラスタが利用可能になります。
Elasticsearchが利用可能になったら、DockerでFessを起動します。
docker run -p 8080:8080 -it \ -e ES_HTTP_URL=https://search-〜.es.amazonaws.com \ -e ES_TYPE=aws \ -e ES_USERNAME=〜ユーザー名〜 \ -e ES_PASSWORD=〜パスワード〜 \ ghcr.io/codelibs/fess:snapshot
ElasticsearchのエンドポイントはAWSコンソール上で確認してください。ユーザー名とパスワードはElasticsearch Serviceでドメイン作成時に設定したものになります。
起動できたら、http://localhost:8080/ にアクセスして確認してください。