Hyper.sh - Clusterless Docker Hosting
Hyper.sh の特徴とメリット
個人的にはクラスタ不要で Docker が使えるというだけでかなりのメリットになるのですが、それ以外にもいろいろと特徴とメリットがあったので少しだけ書いておきます。
Docker と同じコマンド体系で利用できる
Hyper.sh が提供している CLI は Docker とほぼ同じコマンドが使えるようになっています。具体的には docker を hyper に置き換えるだけで使い始めることが出来ます。
# docker の場合 docker pull shibayan/decode-demo:v5 docker run -d -p 80:80 -it shibayan/decode-demo:v5 # hyper の場合 hyper pull shibayan/decode-demo:v5 hyper run -d -p 80:80 -it shibayan/decode-demo:v5
Floating IP や Service など Hyper 固有の機能に関してはコマンドが用意されていますが、一貫性のあるコマンドが提供されているので使いやすいです。
ちゃんと CLI は Windows 版もベータですが提供されているので、ダウンロードするだけで使えます。
各コンテナがハイパーバイザで分離されている
Hyper-V Container のように各コンテナで高度に分離された環境が提供されています。ノイジーネイバーの影響を抑えつつ安定した環境を得ることが出来そうです。
What is Hyper.sh | Hyper.sh User Guide
元々、ハイパーバイザ上でコンテナを動かすというソリューションを提供していたみたいで、それを利用してサービスを立ち上げたようです。
秒単位での課金でコストを最適化出来る
クラスタが必要ないので、実質固定費みたいなインスタンスの費用は掛かってきません。その代わりにコンテナが起動していた秒単位で課金が行われます。
CPU コア数とメモリ量の組み合わせで S1 から L3 まで用意されています。
必要な時にコンテナを立ち上げて、要らなくなったら削除という具合に、気軽に使うことが出来ます。
ちなみにネットワークの In / Out は無料となっています。パブリッククラウドでは Out のみ課金対象になったりしますが、Hyper では無料で使い放題というわけです。
手っ取り早く試す
サクッと試してみたいので、わかりやすく使える Azure CLI 2.0 の Docker Image を使ってみます。hyper の設定が終わっていれば、hyper run を叩けば数秒でコンテナが立ち上がります。
hyper run -it azuresdk/azure-cli-python
そのままターミナルが起動するので、az コマンドを使って操作が行えます。
上のコマンドだとコンテナが終了した後も残骸が残り続けてしまうので、コンテナの起動時に --rm オプションを指定しておく方が良いですね。
hyper run --rm -it azuresdk/azure-cli-python
これでコンテナを抜けた後に自動で削除が行われます。
コンテナサイズを指定する
デフォルトでは S4 でコンテナが起動しますが、起動時に --size オプションを付けるとサイズを指定することが出来ます。以下の例では S2 で起動するようになります。
hyper run --rm --size=s2 -it azuresdk/azure-cli-python
起動後にダッシュボードで確認すると、ちゃんと S2 になっていることが分かります。
ちなみに ASP.NET Core アプリケーションの場合はメモリが 256MB 以上ないと辛そうでした。
インターネットに公開する
外部からコンテナにアクセス可能にするためには、コンテナに Floating IP を割り当てる必要があります。早い話がパブリック IP アドレスで、1 IP あたり $1 で利用できます。
# 新しく nginx コンテナを立ち上げる hyper run -d -p 80:80 --restart=always -it nginx # FIP を 1 つ確保して、作成したコンテナに割り当てる hyper fip allocate -y 1 hyper fip attach x.x.x.x CONTAINERID
コンテナを作成して、Floating IP を割り当てると、それだけでアクセス可能になります。非常に簡単です。
Floating IP の割り当てを別コンテナに変更すると Blue-Green Deployment も簡単に実現できそうです。
コンテナに割り当てた Floating IP が Inbound / Outbound 両方の IP アドレスとして使われるようになっているみたいです。どのくらい 1 IP でスケールするのかはわかりませんが、基本的には問題ないと思います。
Compose を使う
Hyper.sh では Docker Compose と同じような機能も提供されています。異なっている部分としては fip という設定が追加されているぐらいで、それ以外は全く変わっていないです。
例えば ASP.NET Core アプリケーションと同時に Redis を立ち上げる場合には以下のように書きます。
version: '2' services: web: image: shibayan/decode-demo:v5 fip: x.x.x.x links: - cache:redis depends_on: - cache ports: - "80:80" cache: image: redis:alpine ports: - "6379"
コマンド体系も Docker と全く同じなので compose up を実行するとコンテナが起動します。今回はあえて -p を使って名前を指定しましたが、デフォルトではディレクトリ名になるので無くても良いです。
hyper compose up -d -p aspnetcore_redis
ダッシュボードで確認すると、指定した 2 つのコンテナが実行されていることが分かります。
Floating IP も ASP.NET Core アプリケーション側にちゃんと割り当てられています。スケーリングも hyper から行うことも出来るのが便利です。
作成したコンテナを落とすのも compose down を実行するだけで完了です。
hyper compose down -p aspnetcore_redis
Docker Compose を使っていれば新しく覚えることはほぼありません。
Service を使う
Hyper.sh に固有の機能として Service というものがあります。これまで hyper run や hyper compose でコンテナを立ち上げてきましたが、一般的な Web アプリケーションの場合は Service を使う方が便利です。
Web アプリケーションに今は必須ともいえる HTTPS への対応も、LB 側で対応が出来るようですし、何よりもローリングアップデートが簡単に行えるという点が重要です。
とりあえず、実際に新しく Service を作成して、外部からアクセス可能にしてみます。
# レプリカを 2 つ持つ Service を作成 hyper service create --service-port=80 --label=web --name=aspnetcore --replicas=2 shibayan/decode-demo:v5 # Service に対して FIP を割り当てる hyper service attach-fip --fip x.x.x.x aspnetcore
作成が完了するとダッシュボードから Service の状態を確認できます。レプリカが 2 つと Floating IP が設定済みなのと、スケーリングが完了していることも分かります。
この状態で Floating IP にアクセスすると、ちゃんと指定したイメージが立ち上がっています。
作成してからコンテナにアクセスが可能になるまで、本当に数秒しかかからないのが凄いです。
Docker なので当然ながら ASP.NET Core アプリケーションもすんなり動作します。ポータビリティ抜群。
スケーリングを実行する
レプリカ数を 2 つで起動しましたが、後から hyper service scale を実行するとレプリカ数を変更することが出来ます。下の例では aspnetcore という Service のレプリカを 4 つに増やしています。
hyper service scale aspnetcore=4
スケーリングも非常に高速なので、数秒で指定したレプリカ数で起動します。
当然ながら減らすのも数秒で完了します。ダウンタイムは発生しません。
イメージのアップデートを実行する
Service を使うと CLI で Docker Image のローリングアップデートが簡単に行えます。ドキュメントを読むと 1 コンテナずつアップデートが行われる仕様のようです。
hyper service rolling-update --image shibayan/decode-demo:v6 aspnetcore
ローリングアップデートを実行すると、数秒で Docker Image の入れ替えが完了します。ダッシュボードのメッセージでもローリングアップデートが完了したことを確認することが出来ます。
関連付けた Floating IP にアクセスすると、新しいイメージのアプリケーションが表示されます。
アプリケーションの運用に必要な機能は Service を使うと、大体満たせることが分かってきました。アップデートが非常に早いのでリリースも安心して行えそうです。
Floating IP の付け替えを制御することで Blue-Green Deployment も可能だと思います。
課金上の注意点
実行したコンテナに関しては秒単位での課金になるみたいなので、非常に安く Docker のホスティングが行えますが、Floating IP だけは確保した瞬間に $1 かかるようになってます。
実際に適当に Floating IP の確保を行っていたら、きっちりと 1 月分が課金されてました。
Floating IP に関しても時間単位ぐらいでの課金になってくれると嬉しいのですが、難しいのかもしれません。とはいえ、プールしておけば済む話なので便利に Hyper.sh を使っていけると思います。
惜しむべきはデータセンターがロサンゼルスにしか存在しないことですが、利用していると思われるデータセンター自体は世界中に存在しているみたいなので、アジアへの追加を期待してます。
