黒井工房 - kurokobo.com

MkDocs の見出しを Font Awesome で装飾する

2020 年 4 月 3 日2020 年 8 月 14 日 @kurokobo コメントをする

Font Awesome のアイコンが見出しの頭にくっつくようにして、なんとなくかわいい感じにします。

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

2020 年 3 月 16 日2020 年 8 月 14 日 @kurokobo コメントをする

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

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

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

全自動在宅勤務めっちゃはかどり機

2020 年 3 月 7 日2020 年 8 月 14 日 @kurokobo コメントをする

昨今の情勢を受けて、家庭内の在宅勤務者の割合が 100 % になったので、在宅勤務中の QoL 的なのを上げようとしています。

で、前から購入を計画していたデロンギの全自動コーヒーメーカを買いました。

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

2020 年 3 月 1 日2020 年 8 月 14 日 @kurokobo コメントをする

EdgeX Foundry 関連エントリ

EdgeX Foundry と Kubernetes

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

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

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

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

Logicool MX Anywhere 2S（MX1600s）購入

2020 年 2 月 13 日2020 年 8 月 14 日 @kurokobo コメントをする

マウスを買ったので写真を撮りました。というエントリです。

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

2020 年 2 月 12 日2020 年 8 月 14 日 @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 ボットをもう少し賢くする

2020 年 2 月 10 日2020 年 8 月 14 日 @kurokobo コメントをする

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

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

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

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

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

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

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