前の投稿でも書きましたが、Dockerコマンドではなく、qbusコマンドを使ったContainer Stationのコンテナ操作は問題なく行える事が分かりました。しかし、アプリケーション（docker-composeに相当するContainer Stationの機能）については一番最初の「作成」に関するドキュメントが全くない！
アプリケーションの情報取得や開始・停止・削除などのコマンドは存在するが、肝心の「作成」だけがドキュメントに存在しないのだ。
そこでドキュメントを隅々まで読んでいくと「コンテナの作成」や「イメージのダウンロード」などの機能を同期的に行う通常の機能以外に「バックグラウンドタスク」という非同期で行う機能が存在している事に気がついた。
この「バックグラウンドタスク」の中に「アプリケーションの作成」に相当すると思われる機能の記載は存在するのだが、説明文のパラメータにはdocker-compose.ymlを指定する方法が記載されていない。
説明文に合わせる形で適当にパラメータを指定して、実行してみるとが、CLI（qbusの実行結果）では成功するのが、実際にアプリケーションが作成される事がなかった。
しかも良く見れば、WebUI側のタスク一覧に「エラーが発生した」という実行結果が残っていたのを発見！
そこで、WebUI側でアプリケーションを作成してみて作成中の「バックグラウンドタスク」の情報を取得してみたり、WebUIで作成したアプリケーションの情報を取得してみて、ドキュメントの情報と何が違うのか詳しく比較してみたところ、WebUIで作成したアプリケーションのタスク・カテゴリは “application” ではなく “application_cutstom” になっている！！
そこで、qbusのURIをapplicationからapplication_customへ変更して、パラメータもWebUIで実行した時の情報を参考に修正して実行したところ、CLIの実行結果がエラーに、しかもエラー内容が具体的になった！！
実行パラメータの正しくない部分を微調整して、qbusを実行したらWebUI側のタスク一覧に「作成中」の表示が出た！！！そして暫く待つと無事にアプリケーションが作成されたのだ！！！
これが、その時のコマンドの抜粋だ！
qbus post com.qnap.container/api/v1/background/application_custom '{"name":"sshclientx","yml":"version:'"'"'3'"'"'\n\nservices:\n〜"}'最初単純に”yml”の値の部分にdocker-compose.ymlの内容をコピペしていただけだったものだから「version: ‘3’」の部分が正しく認識されていなかったようで、引用符の処理を修正する事で、無事認識してアプリケーションの作成に成功した。
それでも問題があるとすれば、この機能が非同期でのアプリケーション作成なので、同期的な処理にするのが面倒な事かな。
さて、ここまで来ると本当にこのままqbusコマンドでのContainer StationのWebUI機能を十分に利用できる形にするのか、dockerコマンドでContainer StationのWebUIでの操作を諦めるか、それとも第3の道を探すのか…悩むところだ。
特にdockerの勉強が進んで、イメージ・コンテナ・レジストリの正しい(?)扱い方と今後の仕事への応用や実運用と、composeや将来的にはswarmやkubernetesまで視野に入れると自前でレジストリを立ち上げる第3の道も候補になり得るのか…と考え始めている。
