ExporterとPrometheusを使って、室内環境の監視をした。Providerがこの世になかったので、Terraformへの理解を深めるついでに自分で作ることにした。Registryに公開できるのは嬉しいものがある。https://registry.terraform.io/providers/aiwasaki126/natureremo/latest/docsGitHubにポートフォリオっぽく見えるのはいいことだ。APIクライアントを使わせてもらっていた。このクライアントの開発後に多少OpenAPIが更新されのか、微妙に食い違う部分が出てきたりしたので、最終的に自作することになった。APIクライアントを自作する上でだいぶ参考にさせていただいたので頭があがらない。Providerは粗く言ってしまえばAPIクライアントのラッパーなので、当然APIへリクエストを投げ、レスポンスをもらう。APIの挙動如何で作りやすさが変わってくる。APIがOpenAPI通りの挙動をしない実際にリクエストをAPIに送ると受け付けてくれないことがあった。/1/uses/meを利用する。fのいずれかで、それ以外の値を投げるとエラーレスポンスになる。fと表す、というような記述は見つからなかったので試行錯誤で突き止めた。いうフィールドがいくつかあり、その度に試行錯誤で受け付ける値を割り出していった。試行錯誤で割り出した対応表はガイドに書かれている。Remoは物理的なデバイスなので、勝手にRemoの追加もできないし、ネットワークに載せるにしても実機での操作が必要になる。対応する家電によってRemo内部の設定値がだいぶ変わるようで、Remoが操作する家電の作成、更新は不可能だった。Remoの設定値くらいしかTerraform制御下におけそうになかった。当初の見込みだと、Appliance(家電)、Homeくらいはやれるとしていたが想定が甘かった。日々使っているGCPやAWSが、いかにハードウェアを抽象化してソフトウェアに近づけているか実感する機会にもなった。開発の概要Providerの作り方は多くの場所で説明されているし、公式チュートリアルも分かりやすいので詳細は省く。Providerを作る上での要点をまとめる。Frameworkは優秀だ公式に推奨されているフレームワークを元に開発をすると、自分で書くコードをだいぶ減らせる。APIクライアント開発以外はこのフレームワークに乗っかればいいので、楽をできる。APIクライアントから自作のAPIクライアントに乗り換える際に、APIクライアントの生成はoapi-codegenを利用した。前述のようにAPIがOpenAPI通りの挙動を示さないので、どこかに見つけ出した実際の仕様を残しておく必要がある。加えて、それをクライアントに反映する必要がある(そうでないとリクエストが通らない)。実際の仕様をOpenAPIの形で残しつつ、そこからクライアントコードのベースを生成すれば、仕様が散らばることもないし、仕様とコードの乖離が減る。開発は徐々に進んでいくので実際の仕様が徐々に判明していく側面があり、随時OpenAPIを更新してクライアントコードに新たに分かった事実を反映できるのが便利だった。クライアントはドメイン駆動設計を意識internal/client/以下のディレクトリ構成を見れば雰囲気は掴めるのではないかと思う。Remoの管理は階層的で、リソースの使い回しがされることが分かっていた。Remoの世界観を形成している。数種類のメインオブジェクトをおさえればクライアントのユースケースを網羅できそうだったので、ドメイン駆動で構成した。実際のところ、前述の通りあまりTerraform化できるものがなかったので、やり過ぎだったかもしれない。Remoのアプリなどでリソースを作成し、そのリソースをimportすることで使う。importする場合、そのリソースのIDを把握するために最初にデータソースからIDを把握する必要があり、面倒なステップを踏む必要がある。RemoデバイスをTF制御下におくやり方を例示する。Startedに書いた。アクセストークンを取得する。下記のようにTF環境変数を定義する。terraform.tfvarsaccess_token="XXX"データソースを定義する。initで初期化する。IDが表示されるので、それを記録しておく。リソースの記述を追加する。IDを元にリソースのimportをする。$DEVICE_ID不要であればデータソースの記述を消す。aiwasaki126スタートアップのインフラ〜バックエンドエンジニア。昔は機械学習にハマっていた。バッジを贈って著者を応援しようバッジを受け取った著者にはZennから現金やAmazonギフトカードが還元されます。バッジを贈るDiscussionaiwasaki126スタートアップのインフラ〜バックエンドエンジニア。昔は機械学習にハマっていた。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。