TL;DR
- docker-compose をリモートで実行するための開発フェーズ向けのサービス
- ローカルマシンへ負荷をかけずに開発できる
- URL を発行してくれるため第三者への公開も可能
概要
blimpup はざっくりいうと「docker-compose をリモートで実行する」ためのサービスです。
用途としては本番環境としてではなく開発フェーズでの利用を想定されており、docker-compose を使用した開発の効率化を行ってくれます（k8s のtelepresence に近いイメージです）。
従来開発フェーズで使用していたdocker-compose をローカルで直接コンテナを動かすのではなく、blimp の提供するインフラ上で動かし、ローカルマシンに負荷をかけることなく開発が可能になります。ローカルのファイルと同期を行ってくれるためファイルの更新を行った場合も自動的にリモートに反映してくれます。
開発フェーズが進むにつれてサービスが使用するリソースが増え、起動するコンテナの数が増え、起動するdocker-compose の数が増え、、、ローカルマシンの処理が遅くなることは多くのエンジニアに経験があるとおもいます。blimp はそんなローカル開発を救うための1つの方法として一考すると良いでしょう。
また、実行したコンテナはlocalhost 経由でアクセスすることが可能で、必要に応じてパブリックなエンドポイントを発行することが可能です。
一時的にエンドポイント発行し、エンジニア以外の職種の方にそのエンドポイントへアクセスしてもらい実際に追加した機能の確認をしてもらう際などに便利です。
Blimp の機能
blimp はローカルにインストールした bimp コマンドを実行し、ローカルとリモートの同期を行いながら開発を行います。
実行するためには blimp コマンドをインストールするだけで実行可能です。blimp を実行するためにDocker やコンテナランタイムのインストールは不要です。
専用の設定やDSL は不要で、もしいままで使用してきた docker-compose.yml があればそのまま実行可能です（ docker-compose.yml は必要です）。
ファイルの同期はもちろん、blimp 上で実行中のコンテナへログインすることも可能です。
例えば、サービスの起動時にDB のマイグレーションが必要なケースでも問題なくblimp を使用できます。
blimp を k8s 上でセルフホスト することも可能なため、将来的にk8s を活用する場合にもblimp を使用し続けることが可能です。
DEMO
環境
- macOS
- 10.15.7
- blimp
- 0.14.3
公式のexample リポジトリを動かしてみる
公式ドキュメントのQuickStart に則ってexample リポジトリで動作確認をしてみます。
Quickstart - Introduction | Blimp
1. blimp コマンドのインストール
今回はローカルへcurl でインストールを行います。
$ curl -fsSL 'https://kelda.io/get-blimp.sh' | sh
Homebrew 経由でのインストールも可能で、blimp コマンドにはセルフアップデート機能が備わっていないためこちらのほうが良いかもしれません。
$ brew install kelda/tools/blimp
Windows の場合はWSL・ネイティブバイナリのどちらかを選択可能（若干設定が必要かつDocker Desktop も必要？普段からWindows に関わらない未確認）。
Blimp on Windows - Introduction | Blimp
2. blimp へログイン
以下のコマンドを実行するとブラウザが起動し、blimp のろグイン画面が表示されます。
GitHub でのログインの場合ワンクリックで、フォームの入力等なく、登録を行えます。
$ blimp login
3. blimp でアプリケーションの実行
QuickStart に則って公式のデモ用リポジトリをclone する
$ git clone ssh://git@github.com/kelda/node-todo.git
blimp の起動
$ cd /path/to/node-todo $ blimp up
localhost:8080 へアクセスし、起動できているか確認します。
リポジトリ名の通り、todo アプリケーションが起動します。
4. datasource の永続化
昨今の開発ではMySQL やMongoDB など、なんらかの永続的なデータを使用している場合がほとんどだとおもいます。
blimp で永続的なデータを扱いたい場合は特別なことは不要です。
ホストマシンとコンテナ間に指定したが同期されるため、 blimp up で起動を行うたびにmigration の実行のような初期化処理は不要です。
試しに公式リポジトリのdocker-compose.yml のmongo に以下のようにディレクトリを同期するよう記載して、何度か起動しデータを入れて落としてを繰り返してみてください。
mongo: image: "mongo" ports: - "27017:27017" volumes: - "./tmp/mongo-db:/data/db:delegated" - "./tmp/mongo-config:/data/configdb:delegated"
5. 公開
blimp で起動したサーバーからアクセスを受け付けるにはexpose コマンドを使用します。
https をサポートしてくれていて地味に嬉しいですね。
$ blimp expose web 8080 Blimp will be shutting on Dec 15, 2020. Migrate to the self-hosted version (https://blimpup.io/docs/#/cluster-setup) to keep using it. The port was successfully exposed. You can access it at: https://4230b65xxxxxxxxxxxxxxxxxxxc786c6d9b441.blimp.dev/
6. お片付け
blimp down で立てたsandbox サーバーを落とすことができます。
$ blimp down Are you sure you want to continue, even though things might break? (y/N) y Sandbox deletion successfully started Note that `blimp up` won't work until the previous sandbox is completely deleted Waiting for sandbox deletion to complete
所感
bimp は「シンプルな開発環境」を手に入れるためにぴったりなサービスです。
特別な設定やわずらわしいユーザー登録やインフラのセットアップ等が必要なく、blimp コマンドをインストールするだけで既存のdocker-compose の定義をそのまま動かすことができ、 開発者の体験を向上させられるシンプル・イズ・ベストそのものなサービス です。
「k8s ほどリッチな環境は要らないけど、本番でコンテナを動かす」プロダクトを作る開発フェーズにとりあえず採用しておくと良いのではないでしょうか？
他にも、「誰かに動作確認をしてもらいたい」ような場合、プロダクトの初期開発フェーズのようなPO に機能の確認をカジュアルにしてもらいようなケース・ブランチをマージする前に動作確認をしたいケースに使いたいケースなどなど、にもカジュアルにURL を発行して確認してもらえるため開発スピードの向上に繋がります。
個人的に、昨今のプロダクト開発は外部のサービス（S3・Auth0・Firebase・自社のマイクロサービスなどなど）に依存してローカルで完結させることが難しくなっており、最初からクラウド上に置いて開発することは合理的だと想います。外部への依存をモックを使用してテストを書くような開発を行っていたとしても、実際にデプロイしてみたら動かないようなことは多々あります。そもそも、モックを作成する以前に外部サービスとの連携が動いているかどうか実際にデプロイして動かしたいはずです（僕はしたいです）。
そのため、クラウド上で動かすことを前提としたローカル開発環境を構築するより、最初から開発環境をクラウド上で動かしてしまう方がローカルマシンの設定に依存しないため挙動を確認しやすいはずだと思っています（僕はよくIAM のプロファイルを間違えます）。
最後に、コンテナの周辺ツール・サービスはCNCF のランドスケープに乗っていないものも増えており、blimp もCNCF のランドスケープにのっていないサービスの1つです。
コンテナを利用する場合にはCNCF 以外のキャッチアップを意識的に行ってみると意外なツール・サービスが見つかるかもしれません。
