x64 な Windows で ARM アーキテクチャのコンテナイメージをビルドする

@kurokobo コメントをする

Docker は マルチ CPU アーキテクチャ をサポートしているので、docker image pull すると、イメージ側が対応していれば、同じイメージの同じタグを指定しても、環境（OS や CPU アーキテクチャ）に応じて適切なイメージが勝手に取得されます。

で、今回、マルチ CPU アーキテクチャに対応したイメージを、実際に x64 な Windows 環境だけで意外とサクッとビルドできたので、そのお話。

続きを読む

ASUS Chromebook Flip C302CA を chrx で GalliumOS とのデュアルブートにする

@kurokobo コメントをする

Chromebook、便利ですね。ここ何年かずっと愛用しています。持ち歩く場合はだいたいこれです。

そしてこれを使っているときに、たまにさくっとした Linux 環境が欲しくなることがあり、その目的でこれまでは crouton で chroot した xubuntu が動くようにしていたのですが、ハードウェアの制御（特にグラフィック）まわりでどうも不都合なシーンがちらほら出てくるようになりました。

そんなわけで、とりあえず別のものを、ということで、chrx を使って GalliumOS をデュアルブートな感じで動かすことにしました。

続きを読む
Rapsberry Pi

冬休みの自由研究： EdgeX Foundry (7) Kubernetes 上で Fuji リリースを動かす

@kurokobo コメントをする

EdgeX Foundry 関連エントリ

EdgeX Foundry と Kubernetes

これまでの EdgeX Foundry 関連エントリでは、一貫してその動作を Docker Compose に任せていました。公式でも Docker Compose や Snaps を利用して動作させる手順が紹介されています。

が、最近よく Kubernetes（や OpenShift）を触っていることもあり、コンテナなら Kubernetes でも動かせるよね！ という気持ちになったので、やってみました。

なお、現段階では、Kubernetes 上で動作させるためのマニフェストファイルは、公式には用意されていません。また、そもそも EdgeX Foundry は HA 構成を明確にはサポートしておらず、実装上も考慮されていないようです。つまり、仮に Kubernetes で動作させられたとしても、レプリカを増やしてロードバランスするような状態での正常な動作は何の保証もないことになります。

というわけで、現状ではあくまで実験程度に捉えておくのがよいと思います。

続きを読む

Cluster API で vSphere 上の Kubernetes クラスタを管理する

@kurokobo コメントをする

きっかけ

実験したいことが出てきてしまい、自宅で Kubernetes を触りたくなりました。

これまで Kubernetes を触る場合は Google Kubernetes Engine（GKE）ばかりを使っていたのですが、 今回実験したいのは IoT の世界でいうエッジ側の話なので、できればオンプレミス相当の Kuberentes クラスタが欲しいところです。

そんなわけで、これ幸いと自宅の vSphere 環境で Cluster API を叩いてゲストクラスタを作ることにしました。Cluster API は、2019 年に VMware から発表された VMware Tanzu や Project Pacific の実装でも使われているそうで、そういう意味でも興味のあるところです。

VMware Tanzu や Project Pacific は、エントリの本筋ではないので細かくは書きませんが、めっちゃ雑に書くと、vSphere と Kubernetes がイケてる感じにくっついたヤツです。

続きを読む

おうち IoT 用の LINE ボットをもう少し賢くする

@kurokobo コメントをする

これまでの LINE ボットの課題

2018 年に、家のエアコンを操作してくれる LINE ボットを作って以来、すでに一年半くらい運用しています。概要は 当時のエントリでも紹介しています が、LINE での会話を元に自宅のエアコンを操作してくれるものです。

これ、作った当初に想定していた以上にたいへん便利で、外出先で家族と『そろそろロボくんにお願いしておこう』などの会話が発生する程度には実際に活用されていました。この手の『作ってみた』系は、長期的な運用が定着する前に使わなくなることが多い印象もあり、これは小規模ではあるもののうまくいった例と言えるかと思います。

当時の LINE ボットの様子

一方で、作りが甘い部分もあって、

  • Lambda の Node.js のランタイムで EoL が迫っていた
    • そもそも Node.js のランタイム側の更新に追従していくことに将来的にけっこう体力を使いそうな印象がある
    • 当時 Node.js を選んだ理由は『とりあえずいちど触ってみたかった』からというだけで、すでにその目的は達成できた
  • ひとつの Lambda に全機能を詰め込んでいて、どう考えてもイケてないアーキテクチャだ
  • 機能が足りない
    • エアコンのオンオフと温度の変更はできたが、冷房と暖房の切り替え機能を実装していない

など、長期的な運用に耐えられるよう全体を作り直したいモチベーションも強くなってきていました。

そんな中、あるイベントに参加して、『Raspberry Pi とセンサとクラウドサービスを使って何でもいいから個人で何かを作る』という活動をすることになり、タイミングもよかったので、この LINE ボットの作り直しを進めることにしました。

続きを読む