こんにちは。サイボウズ株式会社 生産性向上チームの平木場です。
僕たち生産性向上チームは毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催しています。
本記事はその時のネタをまとめたものです。
2023-01-25 号から、基本的に隔週で連載することとしました。たまに単独でも投稿するかもしれません。
今週は 2024-01-17 単独号です。
今回が第 139 回目です。過去の記事はこちら。
news 📺
OpenTofu Announces General Availability
HashiCorp 社のプロダクト Terraform をフォークした OSS、OpenTofu がついに正式リリースされました 🎉
半年前に HashiCorp が Terraform などの主要 OSS プロダクトを BUSL に変更する発表をして以来、OpenTofu を取り巻くさまざまな動きがありました。僕もだんだんいつ何があったか怪しくなってきたので雑に時系列でトピックをまとめました。（日付は時差とか考慮してない）
- 2023/08/10 HashiCorp 社が主要 OSS 製品のライセンスを BUSL に変更すると発表
- 2023/08/16 OpenTF Foundation 爆誕。HashiCorp 社に対して OSS を継続するよう要求
- 2023/08/25 BUSL になる前の Terraform からフォークした OSS 版 Terraform こと OpenTF の開発開始を OpenTF Foundation が発表
- 2023/09/05 OpenTF のリポジトリが Public になる
- 2023/09/20 OpenTF Foundation が OpenTofu Foundation に改名、OSS としての OpenTF も OpenTofu に
- 2023/09/20 OpenTofu が Linux Foundation 傘下に
- 2023/12/19 OpenTofu のリリース候補（RC）がリリース
- 2024/01/10 OpenTofu が正式リリース（GA）🎉
- 2024/03/19 CNCF[1] 主催の KubeCon + CloudNativeCon Europe 2024 で OpenTofu Day を開催予定
なお、OpenTofu の意義や目指すところ、さまざまな経緯は minamijoyo さんの記事が大変参考になります。僕はこれを読む前は OpenTofu にそこまで前向きではなかったのですが、読んでみると OpenTofu の必要性が見え、ワクワクする未来を感じて考えを改めました。
Terraform v1.7 から BUSL に変更されているため、Terraform 最後の MPL 2.0 は v1.6 となります。そのため、OpenTofu は MPL 2.0 ライセンスで v1.6 から GA となっています。
Linux Foundation の記事ではコミュニティ主導のアプローチ＆オープンソースの価値が強調されています。OpenTofu 1.6 では早く・安定したリリースを可能にすることを目的にしているとのことですが、OpenTofu 1.7 では Terraform で利用できない、かつ、コミュニティで求められてきた多くの機能を導入する予定とのことです。
さらに詳しい内容は冒頭 2 つ目のリンクである OpenTofu のブログ記事をご覧ください。
GA とはなりましたがまだまだ OpenTofu を Terraform の代わりに使っていけるかは知見が少ない気はします。ぜひ試してみてバグ報告をやっていきましょう[2]。
本項の執筆者: @korosuke613
Our move to generated SDKs - The GitHub Blog
OpenAPI の定義から Kiota を用いて自動生成された GitHub の Go と .NET の SDK が公開されました（現在はまだ unstable）。
自分も今まで Kiota の名前は聞いたことがなかったのですが、Microsoft が OSS で開発している OpenAPI の定義ファイルから様々な言語のコードを生成するジェネレータのようです。興味がある方は Kiota のドキュメントを見てみると雰囲気が掴めるかもしれません。自分は QUICKSTART で自分が使えるいくつかの言語のコードを見てみましたが、それぞれの言語ごとに API クライアントとして違和感のない使い方ができる印象でした。
今回の GitHub の記事では、OpenAPI から SDK を生成することで REST API のカバレッジをほぼ 100%にでき、今後は SDK をさらに良くすることに注力できると述べられています。
今のところ Go と.NET にだけしか言及されておらず、他の言語の SDK が今後どうなるのかなどは全く触れられていませんでした。Go と.NET もそれぞれのリポジトリの README にはまだ"alpha"バージョンや stable ではないと書かれているので、それらも含めて今後に期待ですね。
本項の執筆者: @Kesin11
know-how 🎓
GitHub Actionsのcomposite actionを使ってinternalリポジトリのファイルを配布する - Cybozu Inside Out | サイボウズエンジニアのブログ
composite action を利用することで本来はデフォルトの GITHUB_TOKEN ではアクセスできない Internal リポジトリのファイルを配布する方法を紹介されている記事です。
GitHub Actions では通常デフォルトの GITHUB_TOKEN の権限で git clone を行うため、他のリポジトリも Public リポジトリであれば clone できますが、Private リポジトリを clone できません。ここまでは通常の感覚通りですが、GitHub Enterprise Cloud の場合はさらに Internal リポジトリという種類もあり、これは同じ Enterprise に所属するユーザーであれば誰でも READ 権限を持っています。いわば Enterprise 限定の Public と言えるため、例えば会社の全員に利用してもらいたいようなソースコードの置き場として便利なのですが、実は GitHub Actions のデフォルトの GITHUB_TOKEN では Private 同様にアクセスはできません。
この記事では GITHUB_TOKEN を使用する以外の方法の検討もしつつ、最終的に共有したいリポジトリを composite action として呼び出せるようにすることで他のリポジトリの GitHub Actions から GITHUB_TOKEN だけで必要なファイルにアクセスを可能にする方法を紹介しています。トリッキーな方法だとは思いますが、特にリポジトリを Public にしにくい業務用途では便利な場面がありそうです。
本項の執筆者: @Kesin11
AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
AWS コンテナサービスに関するアーキテクチャ選択の最適化について解説している記事です。
インスタンスとコンテナ、ECS と EKS、EC2 上の ECS/EKS と Fargate という基盤選択の大きめなところから、ロードバランサーやデプロイ戦略、ログと監視などの運用上のトピックまで幅広く解説しています。
記事内では筆者の方が過去に調査した結果やリファレンスをもとに、意見が述べられており、説得力がある内容です。
個人的には Fargate の CPU 性能と特徴についての記事が各 CPU の特徴を比較と整理されていてわかりやすかったし学びでした。これは Arm 一択ですね。
記事内のリファレンスもすべて目を通したら、書籍並みのボリュームになりそうですが、それだけ読む価値があると思います。(自分も全ては読めてないので、少しずつ読み進めます...！)
タイトルには AWS とありますが、クラウドネイティブなアーキテクチャの選択について考える上で、AWS 以外のクラウドでも参考になると思います！
本項の執筆者: @r4mimu
AWS側の目線から理解する、Google Cloud ロードバランサの世界 - How elegant the tech world is...!
Google Cloud のロードバランサーの種類と特徴について解説している記事です。
Google Cloud のロードバランサーは AWS のロードバランサーと比べて種類が多く、一見複雑です。
そこでまず、 Google Cloud のネットワークについての思想を確認し、ネットワーク設計の思想を踏まえたうえで、ステップ・バイ・ステップで各ロードバランサーの種類を解説しています。
各ステップ、図を提示しているので、ロードバランサーの種類を理解するのに役立ちます。
結局のところ、L7/L4 、内部/外部、グローバル/リージョン、プロキシ/パススルー といった区別が理解できれば、ロードバランサーの種類を理解できるということがわかりました。
記事の最後の図がわかりやすいので、そこだけでも見てみる価値があります。
自分自身、これまでは主に AWS を使っていましたが Google Cloud を使う場面がありました。
その際、AWS と異なり、VPC がグローバルリソースという所から、ロードバランサー含めネットワーク周りの理解が難しかったのですが、こちらの記事のおかげで理解が深まりました。
本項の執筆者: @r4mimu
テストプロセスが自走するチーム体制をめざして QA が取り組んでいること - Techtouch Developers Blog
Four Keys の Elite チーム[3]に向かうためには...？という目線で、チーム体制が刻々と変化するという固有の事情も踏まえて、E2E テスト改善をしていくために QA チームがチームトポロジーの用語で言うイネーブリングチームとして機能するようになるための取り組みが語られています。
Four Keys の文脈では CI/CD 高速化等のビルドパイプラインの改善の話が出てくることが多いので、品質保証観点からの記事は珍しいと感じました。組織の話、テストマネジメントツールの導入など取り組みの全体像が見えて面白かったです。
本項の執筆者: @uta8a
実録レガシーコード改善 / Working with Legacy Code: the True Record - Speaker Deck
初回：https://findy.connpass.com/event/304101/
再放送：https://findy.connpass.com/event/307431/
t-wada さんが過去に実際に経験された開発案件において、最初にどのようにテストコードを追加し、その後に立て続けにやってくる新規要件を TDD で実装していったかという内容でした。
今回の題材は Lambda + Alexa スキルでしたが、利用するインフラや SDK からどのように疎結合にしてテストコードを書いていくかの考え方は他の開発にも通ずるはずです。
個人的には多機能なテストフレームワークやツールを使うのではなく、コードの設計側を見直すことでシンプルにテストコードを書きやすくする今回のアプローチはとても同意できました。Productivity Weekly ではむしろそのようなツールを紹介する機会が多いですが、何でもそのようなツールで解決するのではなく基本に立ち戻ることも大事だと改めて感じました。
スライドだけでも十分な情報量があるのですが、自分は生放送で見ていたのでやはりスライドでは伝わりきれない部分もあると感じました。アーカイブ動画が公開されるかはまだ不明ですが、もし公開されたらぜひ動画で見てほしいと思います。
本項の執筆者: @Kesin11
雰囲気でbuildx/BuildKitを使っていたので調べました
buildx, BuildKit, build driver, ... といった Docker のビルドプラグイン周りの用語を整理してくださっている記事。docker は普段 build, run といったコマンドを叩くだけなので裏側まで意識したことがあまりなく、この記事で違いを理解できました。
個人的には BuildKit に多くの Key feature があるというのを知らなくて探究してみたいと思いました。Extendable frontend formats の項目で、LLB のフロントエンドに Nix が使えたりするというのは初耳でした。また、Build cache import/export の項目にある cache exporter の gha(GitHub Actions)や S3 はよく聞くので活用してコンテナのビルド時間を短縮していきたいですね！
本項の執筆者: @uta8a
tool 🔨
eBPFを使った自動テストツール「Keploy」がすごい
eBPF という、カーネルに手を加えることなくカーネルランドで安全に処理を実行できる仮想マシンを用いたアイデアは近年いくつか登場しています。主に Observability や Security 用途が有名ですが、この記事では eBPF を用いた自動テストツール Keploy の紹介がされています。
元記事を書かれた方が epli2/keploy-minimal-example: A sample project for Keploy というミニマルな構成のサンプルを用意してくださっていたので、私も Ubuntu マシン上でなぞってみました。
実際に Keploy を立ち上げて curl でエンドポイントを叩くだけで録画されたかのようにリクエストが YAML に記録されて、それを元にテストを行うことができます。動作確認用の curl 集のようなものがある場合は、Keploy を使えばコードを書くことなくテストケース化できるので、テストを追加する際のハードルが低くなって良いと感じました。
本項の執筆者: @uta8a
read more 🍘
Productivity Weekly で出たネタを全て紹介したいけど紹介する体力が持たなかったネタを一言程度で書くコーナーです。
-
news 📺
-
Amazon ECS and AWS Fargate now integrate with Amazon EBS
- Amazon ECS、AWS Fargate で簡単に Amazon EBS ボリュームをアタッチできるようになりました
- ストレージやデータを大量に利用するアプリケーションにおいて、コンテナとストレージを切り離せるのは嬉しそうです
-
Amazon ECS and AWS Fargate now integrate with Amazon EBS
本項の執筆者: @korosuke613
あとがき
今週号でした。今週号は個人的にも興味深いネタが多くて楽しかったです。最近なかなか探求時間を取れていないので、今回自分が書いたネタは一個だけでした。チームメンバが意欲的に紹介を書いてくれるのでめちゃ助かってます。チームワークを感じるねぇ...
サイボウズの生産性向上チームでは社内エンジニアの開発生産性を上げるための活動を行なっています。そんな生産性向上チームが気になる方は下のリンクをクリック！
-
Cloud Native Computing Foundation の略。クラウドネイティブを推進するために色々やってるでかいコミュニティで Linux Foundation 傘下（雑）。 ↩︎
-
ちなみに僕はここ数ヶ月 kintone 開発チームで新機能開発を体験しているので、3 ヶ月くらい Terraform を触ってないです。生産性向上チームに戻ったら OpenTofu に置き換えて色々試したい。 ↩︎
-
平木場注: DORA のレポートによると Four Keys ではチームのパフォーマンスによって Elite、High、Medium、Low の 4 つのグループに分類できる。もっともパフォーマンスの高いチーム群が Elite とされる。2023 年の State of DevOps Report においては、変更のリードタイムが 1 日以内、デプロイの頻度がオンデマンド（毎日複数回）、変更のエラー率が 5% 以下、デプロイ失敗の復旧までの時間が 1 時間以内のチームが Elite とされている。https://cloud.google.com/blog/ja/products/devops-sre/announcing-the-2023-state-of-devops-report ↩︎
Discussion