Dify の開発は GitHub 上で行われているので、リリースされていない開発中の新機能も、開発中のブランチを手元で何やかやすると動かして試せます。
というわけで、開発が進んでいる機能の中から、おもしろそうなヤツを 3 つさらっと紹介です。
いずれも開発中のものを勝手に動かしているだけなので、最終的にリリースされるモノとは大きく異なる可能性があります（さらにいえば、リリースされることも保証されていません）。
とはいえ、Human in the Loop（HITL）は、おそらくまもなく（今日明日にでも）リリースされるでしょう。
続きを読む
Dify の 1.10.0-rc.1 で、新しい トリガー機能 がリリースされました。
これは、簡単にいえば、指定したスケジュール や Webhook の受信、SaaS 上での何らかの動き などを契機に、イベントドリブンなワークフローの実行 ができるようになる機能です。
先日リリースされた ナレッジパイプライン とあわせて今年の目玉機能のひとつとされていたもので、開発目線では 実装へのコントリビューションが積極的に募集され進捗も公開されていた 点がめずらしいケースでした。
それはそれとして、1.10.0-rc.1 時点 の情報を、主に SaaS との連携 を中心にまとめます。リリース名の通り現時点では RC 版 であり、正式版では仕様が変わる可能性はもちろんあるので、その点はご了承ください。
続きを読む
Dify の今年の目玉機能のひとつ、ナレッジパイプライン（Knowledge Pipeline）が、昨日、Dify の 2.0.0 のベータ版（beta.1）の機能のひとつとしてリリースされました。
この機能、ベータ版の公開前から勝手に興味をもって個人的に実際に動かして触ったりバグをちょこっと直したり機能をちょこっと足したりしていたので、ベータ版の公開に合わせて、簡単に紹介します。
ただし、以下の点、ご了承ください。
Dify には有償の Enterprise 版があります。動かすにはライセンスが必要ですし、OSS ではないのでソースコードも見られないのですが、一方で、Enterprise 版のドキュメントや、デプロイに必要なアセット一式は、インタネットで公開されています。
で、Enterprise 版で動く Dify のバージョンが 0.x だった頃に、そういう公開されているいろいろを探索してフムフムと技術的な好奇心を満たしていたのですが、最近、Enterprise 版の Dify が 1.x に引き上げられ、プラグインに対応しました。そんなわけで、改めてちょっとだけ中身を探ったので、簡単に紹介です。Community 版へのコントリビューションを続けるなかで、とくに Enterprise 版でのプラグイン周辺のアーキテクチャが気になっていたのでした。
ドキュメントでも細かくは説明されていない部分なので、Enterprise 版の導入や、導入済みの Enterprise 版のアップグレード（プラグインアーキテクチャへのマイグレーション）を検討している場合は、参考になる…… かも…… しれません。
続きを読む
Dify がすこぶる便利でおもしろいので、もりもりと使ったりちまちまとコントリビューションをしたりしています。
今回、Dify の 運用管理系 の操作、たとえば、
などを、PowerShell のコマンドレットで行える ようにするモジュール PSDify をリリースしたので、かんたんに使い方などを紹介します。
これは Dify Advent Calendar の 1 日目 です。
続きを読む
Ansible のプレイブックの実行結果にめちゃくちゃシンプルなタイムスタンプを表示するだけのコールバックプラグイン community.general.timestamp をリリースしました。
簡単に使い方を紹介します。
続きを読む
前回のエントリ で、vSphere に古くから実装されている API である vSphere Web Services API（SOAP API）の触り方を紹介しました。その中で、Virtual Infrastructure JSON API にひとことだけ触れています。
SOAP API を（広義の）REST API のように触れる Virtual Infrastructure JSON API も vCenter Server 8.0 U1 以降が必要で、まだまだ一般的ではありません。
vSphere Web Services API（SOAP API）の触り方 | kurokobo.com
Virtual Infrastructure JSON API（VI/JSON API）は、vCenter Server 8.0 U1 で追加された新しい API で、ひとことで雑に表現するなら、従来の SOAP API の REST API 版 です。
本エントリでは、まだ日本語ではほとんど情報がないこの新しい API について、実例とともに簡単に紹介します。
なお、vSphere の REST API といえば vSphere Automation API が一般的ですが、VI/JSON API はこれとはまったく別物 です。
続きを読む
vSphere 環境をコマンドライン環境や何らかのスクリプトから操作するとき、典型的には PowerCLI や govmomi、pyVmomi、VMware vSphere Automation SDK などのツールがよく利用されますが、こうしたツールを使わずに API を直接触れる と、vSphere に実装された新機能をリリースと同時に使い始められ てたいへん便利です。実際、vSphere vMotion Notifications がリリースされたときも、ツールが更新されるまでは、API を直接触る 以外にそれを試す手段がありませんでした。
vSphere の API には、古くからある SOAP API（vSphere Web Services API）と新しい REST API（vSphere Automation API）の大きく二つがあります。操作が簡単なのは間違いなく REST API ですが、SOAP API でしか行えない操作もたくさんあり、また、SOAP API を（広義の）REST API のように触れる Virtual Infrastructure JSON API も vCenter Server 8.0 U1 以降が必要で、まだまだ一般的ではありません。
したがって現状では、昔ながらの SOAP API こそ が、極論、大抵のことはどうにかできる API であると言えます。そこでこのエントリでは、SOAP API（vSphere Web Services API）を直接触る方法 を実例と共に紹介します。
なお、コマンド例は curl と PowerShell で紹介 していますが、結局は HTTP で XML をやりとりするだけなので、お作法さえわかれば他の HTTP クライアントでももちろん利用できます。また、SOAP API は Managed Object Browser（MOB）でも操作できますが、Web ブラウザでの操作であり自動化には向かないため、今回は取り上げません。
続きを読む
AWX の Automation Mesh を構成する機能として、過去に紹介した Execution Node に加えて、Hop Node と Mesh Ingress が最近のリリースで追加されました。
関連する情報は AWX のドキュメント や AWX Operator のドキュメント にもまとまっていますが、本エントリでは Mesh Ingress を中心にこれらの新機能を簡単に紹介します。
続きを読む
Ansible でよくある困りごとのひとつとして、タスクのログに複数行の文字列が含まれるとき、以下のように人間の眼にはやさしくない表示になることが挙げられます。改行がエスケープシーケンスとして表示されるためです。
...
TASK [Referring undefined variable] ********************************************
fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an unde
fined variable. The error was: 'undefined_variable' is undefined. 'undefined_var
iable' is undefined\n\nThe error appears to be in '/runner/project/demo.yaml': l
ine 20, column 7, but may\nbe elsewhere in the file depending on the exact synta
x problem.\n\nThe offending line appears to be:\n\n\n - name: Referring undef
ined variable\n ^ here\n"}
...
この対策として、改行が改行として表示されるように 出力を YAML 形式にする 方法がよく知られています。本エントリ公開時点では、次の二つの方法が一般的です。
ansible.cfg の callback_result_format（または環境変数 ANSIBLE_CALLBACK_RESULT_FORMAT）に yaml を指定するcommunity.genral のコールバックプラグイン yaml を利用する
ansible.cfg の stdout_callback（または環境変数 ANSIBLE_STDOUT_CALLBACK）に community.general.yaml を指定する一方で、同じ困りごとは AWX でも発生しますが、AWX で同じ対策を試みても意外と素直にいきません。
先日、これに関する質問が Ansible Community Forum に寄せられ ました。フォーラムでもぼくから回答済みですが、本エントリでは、AWX でジョブのログを YAML 形式で出力させる方法を改めて日本語で簡単に紹介します。
続きを読む