「今回のプロジェクトでは、マネージドのKubernetesは使えません」このような状況に直面したことはないでしょうか。Kubernetesが提供する宣言的デプロイメントや自動化の恩恵を受けたいが、コストや複雑さの面で導入が難しいケースは少なくありません。このような環境で活用できるOSSツール「Dewy」について紹介します。

Dewyとは何か

Dewyは各ホストに常駐し、CIによって作られたアプリケーションやデータ、コンテナを、ホスト上のプロセスとして常に最新となるようにします。いわゆる継続的なデプロイメントを可能にします。継続的なデプロイメントは、Kubernetesを使っているとエコシステムであるArgo CDのようなGitOps ソフトウェアによって、当然のこととして実現できますが、Kubernetesが使えない環境だと既存のデプロイツールで頑張るしかありません。ひょっとすると、SSHで手動デプロイだったり、SCPやSFTPを使った趣のあるshellの実行になるかもしれません。あまり考えたくないですね…

こんな時におすすめ

• 小〜中規模サービスで、常時数台〜数十台のサーバーを運用している
• マネージドKubernetesを使うほどではないが、手作業デプロイからは卒業したい
• 社内ルールやコスト制約で GKE / EKS / Cloud Run などを使えない
• 既存の CI /CDはあるが、その中の本番反映でSSHしていてセキュリティが気になる
• Kubernetesをセルフホストするにはハードルが高い

Dewyによる恩恵

Dewyを使うことで得られる恩恵は大きく3つあります。

ゼロダウンタイムの継続的なデプロイメント

Dewyは、ユーザーが設定したレジストリーによって、新しいリリースを自動検出し、ゼロダウンタイムでデプロイを実行します。アプリがサーバであれば、シグナルを受け取って終了するといったグレースフルリスタートに対応する必要があります。アプリがコンテナであれば、Dewyがリバースプロキシとなり、古いバージョンのコンテナプロセスをDrainします（既存コネクションを捌ききってから古いプロセスを止め、新規トラフィックを新バージョンに流します）。さらに、Dewyはマルチポート構成や同一ホストの複数Dewy構成にも対応しています。

セキュアなシステム構成

Dewyプロセスが新しいリリースを取得しに行くので、従来のように、中央から各ホストへリリースをアップロードする必要がありません。インバウンド接続が不要になるので、本番ホストへの接続権限を外部に付与せずに済み、アタックサーフェスを減らせます。Dewyのデプロイはプル型で人が全く介入しないため、セキュアな構成を取りやすくなります。

低いインフラコスト、低い運用コスト

マネージドのコンテナオーケストレーションプラットフォームは不要です。国内のVPSやサーバインスタンスであれば為替変動の影響を受けにくく、安価に抑えられます。すでに物理サーバーがあれば、そのまま活用することもできます。Dewyはリアクティブなスケーラビリティこそ持ちませんが、セキュアなデプロイ自動化に特化しているため構成がシンプルになり、運用負荷を小さくできます。また、新しいバージョンが正常に起動しない場合は、通知だけ行い、古いバージョンのまま正常稼働し、通知も必要以上に発生しないような仕組みがあります。

何が必要か

Dewyを使用するには、いくつか必要な環境やルールがあります。

環境としては、デプロイ対象（アーティファクト）をホストするサービスです。GitHub ReleasesのAssetsや、オブジェクトストレージのAWS S3やGCloudのCloud Storageなどです。コンテナであれば、コンテナレジストリーなどです。CIを使ってビルド済みアプリをオブジェクトストレージやコンテナレジストリーに配置しましょう。

そして、ルールとしては、Dewyがアーティファクトの最新バージョンを判別するために、セマンティックバージョニング形式である必要があります（ステージング環境では、セマンティックバージョニングの pre-releaseを利用します）。

あとは、必要に応じて通知のためのSlack Appやメールアドレスを準備することぐらいです。

開発背景と進化

Dewyは2018年に開発を開始したOSSで、当初は Go がワンバイナリでデプロイしやすいにも関わらず、デファクトなデプロイツールが存在しないから自作するというところから始まっています。前職のマネージドコンテナサービスを支えるAPIのデプロイをいい感じにしたいということで、年末年始の休みを使ってガッと書いて、春前に本番導入したのを憶えています。最近会ったマネージドコンテナサービスを運用している元同僚曰く、今も元気よく稼働しているということでした。

現職でも、クラウドコンポーネントを支えるミドルウェアのデプロイにDewyが便利！ということで数多くのサービスでDewyが使われています。そのために、2024年はデプロイアーティファクトの置き場にオブジェクトストレージを使えるようにしたり、今年はデプロイ対象をコンテナイメージに対応したり、追加開発を行いました。これにより、VPS、リソース不足の仮想サーバ、スペック不足の物理サーバーなど、シンプルな環境でもKubernetesスタイルの自動デプロイメントが実現可能になりました。

また、各DewyレジストリごとにEnd-to-endのデプロイテストをCIでやっていますので、品質担保はバッチリです。なお、E2Eは拙作のワークフローツールのProbeを使っています。

まとめ

Kubernetesは強力なツールですが、すべてのプロジェクトに適しているわけではありません。予算、チームの規模、技術的な複雑さなどの制約により、Kubernetesの導入が難しい環境は多く存在します。Dewyは、そのような環境で宣言的デプロイメントを実現するための実用的な選択肢を提供します。ゼロダウンタイムデプロイ、自動化、セキュリティ、コスト効率を、シンプルなアーキテクチャで実現できます。Kubernetesを使えない環境でも、デプロイメント自動化は可能で、Dewyが、その実現をサポートします。当然、Dewy は Kubernetes の代替ではなく、クラスタスケジューラやオートスケールの機能は持っていません。

DewyはMITライセンスで、個人商用問わず無償で使用できます。ソースコードはGitHub dewy で公開しており、バグ報告、機能リクエストがあれば気軽にIssueを作ってください。プルリクエスト大歓迎。

仕様の詳細については、ドキュメントサイトをご覧ください！