Tilt - 開発環境をコードとして管理する

• Kubernetes ベースのマイクロサービス開発向け無料オープンソース開発環境自動化ツール
• コード変更 → ファイル監視 → イメージビルド → デプロイ更新の流れを自動化し、tilt up コマンドで環境全体を起動できる
• Kubernetes を中心としているが、docker-compose や ローカルコマンド ベースのワークフローにも対応
• 2022年に Docker に買収されたが、独立したオープンソースプロジェクトとして維持・発展している
• マイクロサービスの複雑さを管理するため、モダンな開発環境の統合管理を目指している

---

Tiltとは何か

• 現代のアプリは単一バイナリではなく、複数のサービスやデータベース、フロントエンドサーバーなどが HTTP で相互にやり取りする構造になっている
• Tilt は、このような複雑な構成要素を一度に理解し管理できるマイクロサービス開発環境ツールである
• ファイル修正、イメージビルド、サーバー更新の過程をすべて自動化し、開発速度を高める

Tiltを使うべきチーム

• マイクロサービスベースのアプリを開発するチームに適している
• 多数のターミナルウィンドウを開いてサーバーログを管理したり、複雑なシェルスクリプトで開発環境をセットアップしているチームに特に有用
• tilt up コマンド1つで、誰でも同じ開発環境を簡単に構築できる

なぜ Kubernetes を中心にするのか

• Kubernetes は、コンテナ、Pod、Service などの標準化されたサーバー実行ブロックを提供する
• 開発環境でもこの標準を使えば、本番環境と開発環境の差を減らせる
• Tilt は Kubernetes 以外にも docker-compose やローカルコマンドをサポートしているが、最終的には Kubernetes 中心へ収束していくと期待している

Tiltの開発と未来

• Tilt はもともと独立したスタートアップだったが、2022年に Docker に買収された
• 現在もオープンソースとして維持され、Docker Compose や Docker Desktop などとも連携しながら改善が進められている
• 新しいプロジェクトも開発中で、Tilt のアイデアをより広い開発者エコシステムへ広げようとしている

名前の意味

• "Tilt" は、ドン・キホーテが風車に突撃する物語から着想を得ている
• デモアプリ名は Servantes で、ドン・キホーテの作者セルバンテスを参照している

[GN⁺]

Hacker Newsの意見

• ここでこの話題を見るのは興味深い。私はTiltを何年も使ってきたが、Dockerに買収されてから開発速度が落ちたように思う

  • Tiltはローカル開発環境を構築し、サービスが本番、テスト、開発で同じように動くようにしてくれる
  • サービスコードは大幅に単純化され、品質も向上した
  • 特にCRDを扱う部分では改善が必要だ（k8s_yamlがCRDに依存していることを示す方法がなく、tilt upの呼び出しがよく壊れる）
  • 新しいプロジェクトを始めるときに最初にやることは、tilt upを動かすことだ
  • 試したものとしては、セキュリティとオブザーバビリティ向けのeBPFベースのコレクター、データパイプライン、Helmチャート開発、Kubernetesコントローラーなどがある
  • 非常に柔軟で、さまざまな開発に対して強力だ

• この売り文句は私には少し滑稽に感じる

  • 現代のアプリはあまりにも多くのサービスで構成されている。そうしたサービスは至る所に存在し、絶えず通信している
  • だから、さらに多くのサービスを簡単に作れるようにするツールを作った

• 速度と正確さの間には常にトレードオフが必要だ

  • ローカル統合環境を維持しようとすると、遅すぎてコストもかかりすぎるようになる
  • 問題はKubernetesそのものではなく、依存関係が増えるにつれて、ローカルで世界のコピーを動かそうとするとますます遅くなることだ
  • 私はdocker-composeのようなものを使った、速くて簡潔な開発環境が好きだ。これは速度を保つために一部の依存関係をモック化できる。ローカルテストが通ったら、他の環境ではKubernetesを使う

• 「開発環境」というものは、本来その言語のネイティブなツールで直接テストを実行できるべきだと思う。たとえば cargo test、bundle exec rspec など

  • Kubernetesを動かすVMを起動し、そのVMがDockerコンテナを動かしてテストを実行するようなことをされたら、とても腹が立つだろう
  • これをきちんと、しかも信頼性高く実現するには、今でもかなりの作業が必要だ。Dockerを使わないことが目標なら、さらに作業が増えるかもしれない（macOSでネイティブ実行するにはそれが必須だ）
  • この分野にはたくさんのツールがあるようだ。これらを「開発環境」のためのツールとは呼ばないでほしい。むしろ「ローカルマシンにアプリをデプロイする」ためのツールに近い

• nix-shellに触れないわけにはいかない: nix-shellリンク

• Tiltを実際に見てみたいなら、私たちのChromaオープンソースリポジトリでは、開発とCIのためにデータベースの分散バージョンを動かすのに使っている。とてもクールだ。クローンして tilt up を実行すれば動く

  • Chromaリンク

• ローカル環境のセットアップが問題だったことはない

  • 単一クラスターへのデプロイはとても簡単だ
  • 問題は、本番で管理しているサービスが複数のリージョン（またはk8sクラスター）にまたがってデプロイされていることだ
  • 問題なのは、分散アプリケーションのデバッグだ

• Tiltは「skaffold dev」と比べてどうなのか？ 私たちはその目的のためにskaffoldを使っている。クラスター内で開発するために使っている

• 少し前にTiltをしばらく使ってみた。Tilt、Garden、たぶん他にもいくつか試して、最終的にDevSpaceに落ち着いた

  • 記憶では、既存の本番インフラに最もうまく適合した。すべてを別のやり方で書き直す必要がなかった
  • つまり、既存のkustomize+k8s構成とうまく噛み合った。ポートフォワーディングと、実行中のコンテナへの高速なファイル同期を追加する。私が本当に欲しいのはそれだけだ。変更のたびにイメージを再ビルドするのは嫌だ

• これは本質的に開発コンテナではないのか？