ThinkPad X121eの修理

長年使っていた自宅の PC、ThinkPad X121e が故障して何年放置しただろうか。

故障したと言っても機械的な故障ではなく、単にディスプレイのヒンジ部分(ネジ穴を固定するプラスティック部分)が割れて、ディスプレイの開け閉めに問題があるというだけで、ディスプレイの開け閉めさえしなければ普通に使えていたし、特に大きな問題は無かった。

それでも暫く使わなくなると、やはり古い分、HDD のアクセス速度など気になる部分はどうしても目立ってくるわけで、徐々に使用する間隔が開き、ついには電源を入れないまま放置するようになってしまった。

それでも捨てられずにいたのは、代わりとなる後継の ThinkPad、11インチの ThinkPad がその後一切発売されていない状況があったからだ。(僅かな差だが12インチで妥協するか悩んだ時期もあった)

それが最近、仕事で使っている PC の見直しがあったのだが、その中で現在も現役で使っている MacBook Air が既に5年も使い続けている事に気が付いた。5年前の製品だが、特に不満に感じる部分はなく、未だに現役だ。

そう考えると ThinkPad X121e もヒンジを修理して、HDD を SSD に換装すれば、まだまだ現役で使えるのではないか? と思い、修理する事にした。

まずは SSD に換装すれば本当に現役でも使えるのか確認するため、容量は少ないが 240GB の SSD を新たに購入して、Windows 10 を再インストール。メモリは元々 8GB に増設済みなので、これだけで随分と快適に。

そうなると頑張ってヒンジ部分を修理したいが、一番の問題は故障部分のネジとネジ穴の両方の金具を既に捨ててしまっていた事。

しかし、現代ならメルカリやヤフオク等のネットで探せば、それなりに中古部品も揃う。ネジはサイズ(規格)が一致するものを探すだけだし、プラスティック修理用の工具(溶剤等)も楽天やアマゾン等で探せば売っている。

そうやって修理道具や代替パーツを買いそろえて、ThinkPad X121e を修理してみた。修理に要した金額は全部で約3,000円。その約半分が修理道具の値段で、代替パーツは1割強、ネジが2種類に送料入れて約1,000円だった事を考えると、ネジとネジ穴を捨てる前だったら今回のおよそ半値で修理できていたのが悔やまれる。

修理は筐体の内側なので、表面に目立った跡はなく、初めての修理だったので壊れたプラスティックの補強で若干隙間はできたが、それほど目立たないので、及第点と言ったところか。

修理箇所に負担をかけないためにもディスプレイの開け閉めは極力控える使い方を考えよう。それか修理品だが普通に使えるからメルカリ等で売ってしまうのも良いか。

Share

Container Stationの限界か

docker の使い方にも慣れてきて、docker の仕組みも何となく分かるようになってきたので、前回 qbus の利用を諦めて、docker だけでアプリケーションを作成しようと思ったので、これまで実験的に作成してきた QNAP 用のアプリを docker + QDK で記述し直してみたのだが、Container Station にまた別の問題がある事が発覚した。

私の使っている QNAP は CPU が arm32v7 なので、最初はアプリのインストール時に Dockerfile から QNAP 上で直接ビルドしていたのだが、docker 本来の使い方から考えれば、開発は別の PC で出来た方が良いというか自然な流れだよな〜と思って、Docker Desktop を使って PC 上で行うように変更してみた。

しかし、そうすると作成したイメージを QNAP 上へどうやって持っていくのか?という問題が発生する。一番素直な方法は docker hub を利用する事だろうが、今後仕事で docker hub が使えない環境だってあるかも知れないと思って、独自に docker の registry を QNAP 上で立ち上げ、そこを経由する方法を検討してみた。

ネットの情報を参考に、PC 上で docker buildx を使ってマルチ・アーキテクチャのイメージをビルドして、QNAP 上で立ち上げた独自の registry に push するところまでは問題なく動作した。

ところが、QDK のインストーラ内で docker pull を行うと独自レジストリの認証が正しく利用されないという問題が発生。QNAP では ssh でログインできるのは admin アカウントのみ。しかし WebUI の App Center を admin 以外の管理者アカウントで実行すると admin アカウント保存した認証情報は使用されない。

流石に ID/PW を QDK のインストールスクリプト内に直接記述する訳にもいかないので、イメージの管理や docker pull の方法については別の方法を考える必要がありそうだ。

Share

qbusコマンドにも限界か!?

今回は結論から書こうかと思います。Container Sation の WebUI 機能を使った処理を諦める方向で軌道修正する事になりそうです。Container Sation の WebUI 機能はバグが多過ぎます。

前の投稿にも書きましたが qbus コマンドを使ってアプリケーションの作成を行う方法は「バックグラウンドタスク」の非公開機能で実現できました。

それじゃ通常のコンテナ作成も「バックグラウンドタスク」で…と思ったのだが何故か正常に動作しない!ボリュームのホスト側のバインド先の指定に絶対パスを指定しているにも関わらず、パスの先頭に勝手に /share が追加されてしまったのだ!

通常のコンテナ作成では問題なかったので、「バックグラウンドタスク」の不具合だと思われる。元々 WebUI を使った操作でも Advanced Settings の内容が正常に反映されない問題があるなど、Container Station の不具合は目に余る状態だったので qbus にも同じような問題が存在している事が証明されたようなものだ。

ここ数日の docker 及び Container Station を使った実験で、docker の仕組みをより深く考察する事もできた影響か、docker 本来の使い方をするためにも、qbus コマンドなどの QNAP 独自コマンドを使わずに、docker コマンドだけでコンテナ開発を行っていく方が良いように思えてきた。

Container Station の WebUI 機能が使えない事さえ我慢すれば(苦笑)

ただ作成したアプリのインストールには QDK を利用したいなぁ〜とは思っているので、docker コマンドと QDK とのいいとこ取りができればベストなんだけど、はてさてそうなる事か。

Share

Container Stationの非公開機能!?

前の投稿でも書きましたが、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の道も候補になり得るのか…と考え始めている。

Share

Container Stationコマンド

Container Stationをインストールするとbinディレクトリにdockerやdocker-composeを含む様々なツールがインストールされるが、その中でキモになると思われるコマンドが、qbusである。

Container StationのWebUI機能をCLIからでも利用できるようにするためにのインターフェース(API)へのアクセスをqbusから行うからである。

https://qnap-dev.github.io/container-station-api/index.html

Container Stationのインターフェース(API)の仕様については、上記ページにまとめられているので、基本的にはこちらを参照して実装していく事になるのだが、問題は記載されているサンプルが全てcurlで書かれており、しかも、認証(セッション)情報をCookieに保存して利用するWebUI専用になっており、QNAPのCLI環境(ssh)からは使えない…

そこで活躍するのがqbusコマンドである。例えば、Inspect a containerの

curl -sq -XGET -b cookies.txt http://${QIP}:${QPORT}/containerstation/api/v1/container/docker/<container_id>/inspect

という処理が、qbusだと

qbus get com.qnap.container/api/v1/container/docker/<container_id>/inspect

というコマンドで実行できるのだ!!

qbusについてはネット上で情報を探しているのだが、詳しい情報・説明は未だ見つかっていない。とりあえず、Container Stationの最低限の機能(コンテナ一覧の取得、コンテナの作成、削除、開始、停止、コンテナ情報の取得など)が問題なく使える事は確認できた。

当然、Container SationのWebUIに存在しない機能、例えば、Dockerfileのビルドなどはqbusで実行する事はできないので、これらの機能を使い方い場合には相変わらずdockerコマンドを利用する事になる。

まだ未調査のdocker-composeに相当する機能がqbusだとどうなるのか、qbusにビルド機能はないと思われるので、おそらくビルドしない形のyamlにのみ対応しているのだろうとは思うが…

Share

Docker vs Container Station

QNAPのNASに搭載されているのは正確にはDockerではなくContainer Stationだと言う事を忘れては行けない!!

sshでTS-431Pにログインできるのはadminアカウントのみ(≠管理者権限のアカウント)だし、dockerやdocker-composeなどのコマンドは存在しているが、ssh上でこれらのコマンドを使って作成したイメージやコンテナをContainer Stationから操作できないパターンがあったりして互換性に問題が山積みだ。

更にTS-431PはCPUがarm32系なので普通にDockerfileやdocker-compose.ymlにOfficialなイメージを指定すると存在しないために使えない事も多い。

これらの問題を解決するために、

  • コンテナ作成コマンドにdocker/docker-composeを使用せず、Container Stationのqbusコマンドで代用する。
  • arm32v7のOfficial互換イメージで使えそうなイメージに、Officialと同じtagをローカルでだけ付与する前処理を入れる形で誤魔化す。

という対策を行う事で何とかDocker Desktopで開発したアプリをTS-431P上にインストールしても使えそうな雰囲気になってきた。

ついでに、アプリをQDKでqpkg形式にする事で、QNAP上のApp Centerからインストールする事もできるようになって便利かな〜と思っている。

これまで実験してきた内容は整理できた段階で、一度ブログに記載しようとは思っているけど、今は未解決状態のmariadbのarm32v7イメージ作成をどう解決するかを考え中…

Share