こういう bosyu をしています！
背景
- Frontend / Backend をやる Engineer の方が、副業でインフラを含めすべて1人で構築するシーンで苦労しているので壁打ち相手になってほしい
- 特にインフラに苦手意識があるため、どうやってキャッチアップしていくかを悩んでいる
ということで、このあたりの勘所はなかなか経験ないと厳しいところだと思うので、壁になるだけでも十分貢献できたようです。
いくつかトピックを紹介します。
実践 Terraform をみて動かしてみるが、コピペ Terraform エンジニアになってしまっている
実践 Terraform すばらしいですよね。
このままでは力がつかないのでは、あるいはちょっとした構成変更をするのに苦労してしまったとのこと。
これはめちゃくちゃいいところに気づいていて、Terraform 自体は最低限の内容だけ抑えておけば対して難しくないんですよね。大事なのは中身のクラウドのことを知ること。
以前書いた記事を紹介しつつ、そもそもクラウドの中身を知ることのほうが大事という話をしたり
IaC はインフラの API のラッパーである API でできることを宣言的に書けるように Provider がしているものにすぎない 結局対象のリソースが何で、それを API でどう扱えるかを知る必要がある
実際に IaC 化するところで、いきなり HCL を書き始めているとのことなので、「僕たちだってよく知らないリソースに関してはドキュメント読んで、まずはマネジメントコンソールで作って動かして最低限の疎通を得たりしながら勘所を得て、それを Import しますよ」という話をしました。
SRE は自由自在に最終的な HCL を間違いなくエレガントにかけると思われてたようなので、そんなことないですと（笑）
クラウドリソースってものによっては作るのに時間かかったり、Terraform だとパラメータによっては作り直しになってしまったりするので、フィードバックをはやく得るには最初はコンソールでいじり倒した方がフィードバックが早く得られるので、取り組む順番を変えてみては、という話をしました。
あと上記に関連して、Terraform の基本的な事項についておさらいしました
- state とは何か：実際のクラウドリソースの状態をあらわしているもの
- Import: state にないものを state に取り込む
- refresh: 実際のリソースに state を同期させる
ECS の Scheduled Task で動かしているもののログが出ない
awslogs Log Driver を使って、ログを出すようにしているが、Scheduled のもののログが出ない。そうでない Task のログは出ている、という具体的な問題について、画面共有しながら調査しました。
非常に申し訳ないことに、僕自身が ECS の経験が豊富でないこともあり、限られた時間で解決はできませんでしたが、方向性としては
- このコンテナは本当に動いてるのか？
- rails env prodcution で、ローカルで動かしてみては？
- 同じイメージで scheduled じゃなく通常の Task として動かしてみては？
という話をしました。Task Definition を見る限りログの設定は問題なさそうでした。
ちょっと僕も昔 ECS 少しすぶったぐらいなのであらためて触りなおそうと思えたいい機会でした。
ペアデバッグ、ペアオペみたいなことも、解決できる保証はないんですが、積極的にやっていきたいですね。
はやくフィードバックを得ること、はやく失敗すること、安全に失敗すること
これは Quipper に入って学んだことでもっとも重要なことの1つでもあり、今でも向き合い続けていることです。
上記のデバッグをして、Task かな？を作り直そうとしていたときに、項目を見直して、ご自身で悩まれていたので、「これやってしまったら何か壊れますか？壊れたら困りますか？」という問いをして、失敗を恐れる傾向があるのかな？、という話をしました。
個人の性格によるんですが、大丈夫かな、と石橋を叩いて壊す（w）タイプのひともいれば、やっちゃえやっちゃえでぶっ壊すひともいて、どちらも極端なんですが、重要なのは「はやくフィードバックを得ること」そして「安全に失敗すること」なんですよね。
だからステージングとプロダクションでネットワークレベルで分離するし、Terraform state も分けるし。ステージングなら最悪大丈夫、って言えるのは「安全に失敗する」ため。
特にクラウドリソースなんて中身は見えないわけで、ドキュメントも完璧じゃないわけで、動くか動かないか、それをまず先に突き詰めてためにはたくさん失敗する必要があります。フィードバックループをできるだけ早くすることはソフトウェアエンジニアリングのいろんな場面で重要です。
僕も全然得意ではないですが、意識するようになって少しずつですが変わってきました。
今回のようにメンタリング的なアプローチができたのは思わぬ副産物だったと思います。
応募者からのフィードバック
聞けてよかったこと、話せてよかったこと、印象に残っていることががあれば教えてください
- ECS+Fargate環境における具体的な困りごとを一緒に画面見るなどして、切り分ける考え方を教えてくれた
- Terraformのツールの使い方を超えて、ツールを使うにあたっての心構えを聞けた
- 「早く失敗することを意識したほうがいい」というアドバイスをもらえた(これはマジで心に響いた)
ということで、意味のある時間になったようで何よりです。
おわりに
引き続き bosyu しています！
今回のように一緒にデバッグしたり、ぼんやりとした状態から悩みを具体化したり、もしかしたら考え方に関する話もできるかもしれません。曖昧な状態で大丈夫です。気軽に応募してください。それでは！
