Skip to content

Latest commit

 

History

History
249 lines (180 loc) · 11.9 KB

README.ja.md

File metadata and controls

249 lines (180 loc) · 11.9 KB

English | 日本語







Dewy





Dewy enables declarative deployment of applications in non-Kubernetes environments.

GitHub Workflow Status GitHub Release Go Documentation

Dewyは、主にGoで作られたアプリケーションを非コンテナ環境において宣言的にデプロイするソフトウェアです。 Dewyは、アプリケーションのSupervisor的な役割をし、Dewyがメインプロセスとなり、子プロセスとしてアプリケーションを起動させます。 Dewyのスケジューラーは、指定する「レジストリ」をポーリングし、セマンティックバージョニングで管理された最新のバージョンを検知すると、指定する「アーティファクト」ストアからデプロイを行います。 Dewyは、いわゆるプル型のデプロイを実現します。Dewyは、レジストリ、アーティファクトストア、キャッシュストア、通知の４つのインターフェースから構成されています。 以下はDewyのデプロイプロセスと構成を図にしたものです。

Dewyのデプロイプロセスとアーキテクチャ

主な機能

  • 宣言的プル型デプロイメント
  • グレースフルリスタート
  • 選択可能なレジストリとアーティファクトストア
  • デプロイ状況の通知
  • オーディットログ

使いかた

次のServerコマンドは、registryにgithub releasesを使い、8000番ポートでサーバ起動し、ログレベルをinfoに設定し、slackに通知する例です。

$ dewy server --registry ghr://linyows/myapp \
  --notify slack://general?title=myapp -p 8000 -l info -- /opt/myapp/current/myapp

レジストリと通知の指定はurlを模擬した構成になっています。urlのschemeにあたる箇所はレジストリや通知の名前です。レジストリの項目で詳しく解説します。

コマンド

Dewyには、ServerとAssetsコマンドがあります。 ServerはServer Application用でApplicationのプロセス管理を行い、Applicationのバージョンを最新に維持します。 Assetsはhtmlやcssやjsなど、静的ファイルのバージョンを最新に維持します。

  • server
  • assets

インターフェース

Dewyにはいくつかのインターフェースがあり、それぞれ選択可能な実装を持っています。以下、各インターフェースの説明をします。（もしインターフェースで欲しい実装があればissueを作ってください）

  • Registry
  • Artifact
  • Cache
  • Notify

Registry

レジストリは、アプリケーションやファイルのバージョンを管理するインターフェースです。 レジストリは、Github Releases、AWS S3、GRPCから選択できます。

共通オプション

共通オプションは以下の2つです。

Option　　　　　　　　　　 Type Description
pre-release bool セマンティックバージョニングにおけるプレリリースバージョンを含める場合は true を設定します
artifact string アーティファクトのファイル名が name_os_arch.ext のようなフォーマットであれば Dewy パターンマッチすることができますが、そうでない場合は明示的に指定してください

Github Releases

Github Releasesをレジストリに使う場合は以下の設定をします。また、Github APIを利用するために必要な環境変数の設定が必要です。

# 構造
ghr://<owner-name>/<repo-name>?<options: pre-release, artifact>

# 例
$ export GITHUB_TOKEN=****.....
$ dewy --registry ghr://linyows/myapp?pre-release=true&artifact=dewy.tar ...

AWS S3

AWS S3をレジストリに使う場合は以下の設定をします。 オプションとしては、regionの指定とendpointの指定があります。endpointは、S3互換サービスの場合に指定してください。 また、AWS APIを利用するために必要な環境変数の設定が必要です。

# 構造
s3://<region-name>/<bucket-name>/<path-prefix>?<options: endpoint, pre-release, artifact>

# 例
$ export AWS_ACCESS_KEY_ID=****.....
$ export AWS_SECRET_ACCESS_KEY=****.....
$ dewy --registry s3://jp-north-1/dewy/foo/bar/myapp?endpoint=https://s3.isk01.sakurastorage.jp ...

S3でのオブジェクトのパスは、<prefix>/<semver>/<artifact> の順になるようにしてください。例えば次の通り。

# <prefix>/<semver>/<artifact>
foo/bar/baz/v1.2.4-rc/dewy-testapp_linux_x86_64.tar.gz
                   /dewy-testapp_linux_arm64.tar.gz
                   /dewy-testapp_darwin_arm64.tar.gz
foo/bar/baz/v1.2.3/dewy-testapp_linux_x86_64.tar.gz
                  /dewy-testapp_linux_arm64.tar.gz
                  /dewy-testapp_darwin_arm64.tar.gz
foo/bar/baz/v1.2.2/dewy-testapp_linux_x86_64.tar.gz
                  /dewy-testapp_linux_arm64.tar.gz
                  /dewy-testapp_darwin_arm64.tar.gz

Dewyは、 aws-sdk-go-v2 を使っているので regionやendpointも環境変数で指定することもできます。

$ export AWS_ENDPOINT_URL="http://localhost:9000"

GRPC

GRPCをレギストリに使う場合は以下の設定をします。GRPCを使う場合、アーティファクトのURLをユーザが用意するGRPCサーバ側が決めるので、pre-releaseやartifactを指定できません。 GRPCは、インターフェースを満たすサーバを自作することができ、動的にアーティファクトのURLやレポートをコントロールしたい場合にこのレジストリを使います。

# 構造
grpc://<server-host>?<options: no-tls>

# 例
$ dewy grpc://localhost:9000?no-tls=true

Artifact

アーティファクトは、アプリケーションやファイルそのものを管理するインターフェースです。 アーティファクトの実装には、Github ReleaseとAWS S3とGoogle Cloud Storageがありますが、レジストリをGRPCに選択しなければ、自動的にレジストリと同じになります。

Cache

キャッシュは、現在のバージョンやアーティファクトをDewyが保持するためのインターフェースです。キャッシュの実装には、ファイルシステムとメモリとHashicorp ConsulとRedisがあります。

Notify

通知は、デプロイの状態を通知するインターフェースです。通知は、Slack、SMTPから選択できます。

Slack

Slackを通知に使う場合は以下の設定をします。オプションには、通知に付加する title と そのリンクである url が設定できます。リポジトリ名やそのURLを設定すると良いでしょう。 また、Slack APIを利用するために必要な環境変数の設定が必要です。 Slack Appを作成し、 OAuth Tokenを発行して設定してください。OAuthのScopeは channels:join と chat:write が必要です。

# 構造
slack://<channel-name>?<options: title, url>

# 例
$ export SLACK_TOKEN=****.....
$ dewy --notify slack://dewy?title=myapp&url=https://dewy.liny.ws ...

セマンティックバージョニング

Dewyは、セマンティックバージョニングに基づいてバージョンのアーティファクトの新しい古いを判別しています。 そのため、ソフトウェアのバージョンをセマンティックバージョニングで管理しなければなりません。

詳しくは https://semver.org/lang/ja/

# Pre release versions：
v1.2.3-rc
v1.2.3-beta.2

ステージング

セマンティックバージョニングには、プレリリースという考え方があります。バージョンに対してハイフンをつけてsuffixを付加したものが プレリリースバージョンになります。ステージング環境では、registryのオプションに pre-release=trueを追加することで、プレリリースバージョンがデプロイされるようになります。

プロビジョニング

Dewy用のプロビジョニングは、ChefとPuppetがあります。Ansibleがないので誰か作ってくれると嬉しいです。

背景

Goはコードを各環境に合わせたひとつのバイナリにコンパイルすることができます。 Kubernetesのようなオーケストレーターのある分散システムでは、Goで作られたアプリケーションのデプロイに困ることはないでしょう。 一方で、コンテナではない単一の物理ホストや仮想マシン環境において、Goのバイナリをどうやってデプロイするかの明確な答えはないように思います。 手元からscpやrsyncするshellを書いて使うのか、サーバ構成管理のansibleを使うのか、rubyのcapistranoを使うのか、方法は色々あります。 しかし、複数人のチームで誰がどこにデプロイしたといったオーディットログや情報共有を考えると、そのようなユースケースにマッチするツールがない気がします。

FAQ

質問されそうなことを次にまとめました。

  • Latestバージョンをレジストリから削除するとどうなりますか？

    Dewyは削除後のLatestバージョンに変更します。リリースしたバージョンを削除したり上書きするのは望ましくありませんが、セキュリティの問題などやむを得ず削除するケースはあるかもしれません。

  • オーディットログはどこにありますか？

    オーディットログはアーティファクトがホストされてるところにテキストファイルのファイル名として保存されます。現状は検索性がないです。何かいい方法が思いついたら変更するでしょう。 オーディットとは別で通知としてOTELなどのオブザーバービリティプロダクトに送ることも必要かもしれません。

  • 複数Dewyからのポーリングによってレジストリのレートリミットにかかるのはどう対処できますか？

    キャッシュコンポーネントにHashicorp Consul やredisを使うと複数Dewyでキャッシュを共有出来るため、レジストリへの総リクエスト数は減るでしょう。その際は、レジストリTTLを適切な時間に設定するのがよいです。 なお、ポーリング間隔を長くするにはコマンドのオプションで指定できます。

作者

@linyows