モヤモヤを吐き出しただけで答えはまだ出てないです。
最近はGCPを触っている。Cloud Functions(Gen1)をデプロイするときに何かすごい違和感がある。
Cloud Functions(Gen1)をデプロイする方法は２つあり、ソースコードをGCSに上げて参照させるか、Cloud Source Repositoryのブランチを参照させるか。
どちらも結局はデプロイ時点のコードがCloud Functionsのビルド用のGCSコピーされ、Cloud Buildでビルドされ、Artifact Registry(もしくはContainer Registry)にイメージができあがり、それを参照したCloud Functionsが動き始める流れは変わらなさそう。
最初はすごい違和感があったけど、まぁコードを用意したら良しなにやってくれるというのはそういう感じなのかなと思った（Cloud Source RepositoryとCloud Functionsでプロジェクトが跨いだ時の権限周りが面倒だったけど）
最近考えてるのはCloud Functionsのリソースとその上で動くアプリのそれぞれのCI/CDのこと。
まずCloud Functionsのリソース自体はインフラ側の領分なんだからterraformで、その上で動くアプリはアプリのCI/CD(アプリのCI/CDでgcloudコマンドでデプロイ)でいいんじゃないか、と思った。terraformでリソースを定義しないと、インフラの状態をコードで表現できない。その状態は良くないはずと思った。
しかし、terraformでCloud Functionsをデプロイするにはアプリのコードが無いといけない。インフラの準備でさえもアプリに依存する。さらにソースコードを取得するためにSource Repositoryに依存する。それにterraformは別にSource Repositoryで参照しているブランチのコミットが変化したからといって、それを検知してデプロイ操作を行ってくれるような造りにはなってない。（ソースコードをGCSから参照させるやり方ならハッシュ値が変わりできるようになるが、それもterraformを動かさないといけない）
では、アプリのCI/CDでgcloudコマンドでCloud Functionsのリソースを作りつつデプロイもするとかだと、terraformの管理下に無い状態のリソースができあがる。それっていいことなんだっけ？使われなくなった時に削除して問題ないか困らないか？とか不安がある。それにCloud Functionsのリソースに依存するリソースはどうなる。例えばCloud Scheduler経由でCloud Functionsを呼び出したい時のURL。dataリソースで頑張って参照するかハードコードしたりすることとなる。
Source Repositoryが相性良くないのか、と思い、ソースコードをGCSから参照させるやり方だったらどうか考えた。が、動作確認環境で動作を確認したら本番反映するためにブランチ戦略を取りたい時にソースコードをGCSから参照させるやり方はちょっと複雑になってしまう。
アプリのCI/CDをするときはブランチ戦略を合わせて考える事が多い。stagingブランチで動作確認環境にデプロイ、mainブランチで本番環境にデプロイ、といった感じの複数ブランチを使ったCI/CDパイプラインを組む。これは分かりやすいと思う。仮に開発環境用の機能を追加するにしてもアプリ内でif文をかけばよいだけであり、アプリのCI/CDには関係ないようにもできる。
しかしインフラのCI/CDで複数ブランチを運用するやり方は私はうまくいかないと思っている。それは動作確認環境と本番環境は完全に一致しない事のほうが多い。グローバルでユニークにならないリソースはもちろん、経費削減とかでプランを下げたり、一般からはアクセスできないようにするとか色々やる。terraformではcountをif分の代用に使えるみたいなハックがあり頑張ればできてしまう。そんな感じに一致しなくなる（動作確認環境とは）
そもそもコードで管理してるんだから必要な時に作って不要になったら潰せばいい、という考えはよく言われる。しかし（私の作りが悪いせいもあるかもしれないが）無から1発で作れたことはそれなりの規模では1度もない。だいたいIAMの権限の反映が時間差で起きるせいで失敗したりする。だから成功するまでリトライしたりする。結果整合性は提供側には都合がいいが、利用側は整合性が取れたことを何らかの方法で知るか、冪等な操作でリトライしつづけないといけない。あと単純に時間がかかる。10分かかりますとかだと（それでも早いけど）集中力をそぎ落とすには充分な時間。
「TerraformでCloud Functionsをデプロイしてみた」みたいな記事はよくみるが、それは実用的なのか。ちょっとしたツール、例えばCloud Source RepositoryからPubSubを受けてSlackに通知するためのFunctionsをデプロイしたいときとか、DBを定期的に落とすFunctionsをデプロイしたい時には使えるのかもしれないけど、業務ロジックで使うには耐えれない気がした。
インフラのCI/CDでもデプロイし、アプリのCI/CDでもデプロイしてよいとしたらどうか？インフラの状態をコードで管理できるし、アプリのCI/CDのライフサイクルで考える事ができるようになる。しかし、インフラCI/CDを動かすには最低限でもアプリの実装が必要だし、インフラのCI/CDでデプロイしたアプリとアプリのCI/CDでデプロイしたアプリは一致しない。（たいていは後者が正となる。参照先のブランチを一緒にしておけば酷い乖離は生まないはず。）
Cloud Functions(Gen1)のデプロイはインフラCI/CDとアプリCI/CDのどちらで行うべきか考えている。
ここまで書いて何となく思ったのは、インフラの状態とコードを一致させようとし過ぎている気がした。サーバ毎の個性で苦しんだあの頃を思い出すと例外を認めたくない強い気持ちがあった。 でも何となく「インフラの状態をそこまで厳密に管理しなくてもいいのでは？」と思った。いやクラウドでも同じで開発はメモリ1GBなのに本番は256MBで動いてるせいで性能が出てませんでしたみたいなことはあったので、それなりに必要。
だがCloud Functionsはどちらかと言えばアプリが肝なのだからアプリのライフサイクルにあう、アプリのCI/CDで明示すればよいのでは？とちょっと思った。それに定期的にアプリのコードを見て使われていないFunctionsの棚卸をすればいいのでは？それならアプリのCI/CDでやってしまって良い気が・・・？でもアプリ側のCI/CDにサービスアカウントをハードコードするんか？
そんなこんなでどうすべきか全然わからない状態になっている。みんなこの辺りの意思決定をどうやっているのか。
俺はこんなことで悩まずアプリを動かしたいだけなのに。 ちょっと自分が偏った思い込みをしているせいで、ただ勝手に疲弊しているだけなのかもしれないけど。
このtogetterに影響された。ITエンジニアとして尊敬している人が言うんだから間違いないと思って2/16ぐらいにサンワサプライの700-TAP044W を買った。
その後、この記事がTwitterのTLに流れてきて見た。作りが様々だったのを見て驚いた。内部がどうなっているか全く知らなかった。 1mm程度の細い銅線で繋がってるだけのやつだと嫌だなと思って、サンワサプライの700-TAP044Wをバラして写真を撮っていた。
この記事がホッテントリに入ってた。 部分的にフラックスが炭化していたらしいが、それが経年劣化なのかわからなさそうだった。
なので参考までに手元にちょうどあった写真を載せておきます。未使用品です。
2枚目とか見てもらうと分かるが、部分的にフラックスが炭化している。が、元の記事と比べると比較的キレイに見える。 でもそんなに発熱するとも思えないから個体差なような気も。
サンプル数が必要なのでみんなも電源タップを分解して写真を載せあおう。電源タップ分解ブームこいこい
なお、普通に使う分には何の問題もないのではと思っているので使う予定です。
