Alternative Architecture DOJO

オルターブースのクラウドネイティブ特化型ブログです。

Hacobune(β)に乗ってみた

こんにちわ。あんなにいたクマゼミが一瞬でいなくなりツクツクボウシが出来てきて秋だなーと感じている今日この頃です。 オルターブースの小島です。

さて、今日はちょっとご紹介兼ねて検証レポートを送ります。 f:id:koji_kchc:20210908171557j:plain

Hacobune(β)

Hacobuneはさくらインターネットが提供する次世代PaaSでして、前身のArukasとサービス思想は近しいものとなります。 8月12日にβ版としてリリースされました。

www.sakura.ad.jp

元々ArukasのファンだったのでまたPaaSサービスに再チャレンジしたさくらインターネットさんの漢気を感じざるを得ませんw 僕の期待値は和製Herokuなのですが、同様のサービスでいうとAzure App ServiceやAWS Beanstalkあたりと機能比較をする意味はないと思っています。 何故ならば。。。。。

さくらのクラウドの1機能として存在するからです!!!

要は単一の機能で比較するよりも、その利用ニーズやターゲットなど踏まえて考えたほうが良いと思っています。

プレシードスタートアップの現状

私はG'sアカデミーでメンターをやっておりまして、様々なサポートを行っております。中でも一番サポートすることが多いのが「デプロイ」です。 この「デプロイ」なのですが、熟練技術者から見ると別に難しいことなんてありません。 しかしここにいるのは技術者ではなくスタートアップの卵なんですよね。 毎回デプロイで色々な問題が起こります。

いつも思うのはもっと手軽にデプロイできる環境があればサクッとプロトタイプを公開してフィードバックを得られるのになって思うわけです。

いやいや、AWSやAzure使えばかんたんでしょう?っていうこともあるんですが、そこまで正直知識スキルが回らないことも事実なのです。

そこでこの現状をある程度解決してくれるサービスとして、まずはHacobuneに期待しているところでございます。

ワンタッチデプロイで超簡単に公開できる

さて、一通りHacobuneを触ってみました。 Azure Web Site(現App Services)を彷彿させるわかりやすいUIなので、ちょっとITやっている人なら簡単にデプロイできると思います。

ちょっと画面を見てみましょう。

f:id:koji_kchc:20210908164246p:plain

デプロイ方法としては今のところ3つです。

  • Docker Hub
  • GitHub
  • 任意のコンテナレジストリ

今回は簡単にDocker Hubからapacheのコンテナをデプロイしてみます。 設定項目としてはほかにも環境変数や起動引数、設定ファイルなんかの指定もできます。 ちゃんと動かすならここら辺のコンフィグ周りもどのように受け渡されるのか内部アーキテクチャーを理解する必要がありますが、今は一旦置いておきましょう。

f:id:koji_kchc:20210908164902p:plain

外部に公開するときは、今はHacobuneが用意したドメインで公開することが可能です。 多分ここはそのうちカスタムドメインなんかできるようになるし、フロントにはL7レベルでのGWが付くかと思っています。(思っています

ベースがコンテナですからエフェメラルディスクとなりますので揮発性です。永続化データが必要な場合、通常のDockerと同じくホストからマウントする必要があります。 それも簡単にできます。

f:id:koji_kchc:20210908165431p:plain

DBも一応あります。 これはアドオンとして提供されています。 f:id:koji_kchc:20210908165555p:plain

まあ、こんな感じであとはジョブスケジューラーがついていたりと、今のところとてもシンプルな構成になっています。 凄い簡単なので触ってみるといいと思います。

どう活用しようか?

実はここが一番重要で、かつ僕からのHacobuneに対してのフィードバックとして受け取ってくれると非常に嬉しいです。(おこがましいのですが) まず僕の感覚でいうとコンテナ1台ですべてが集約しているサービスなんて言うものはないわけです。 とは言いつつ、今の段階ではプロトタイプの外部レビュー用としてはちょうどいいなと思います。

ここからは希望的な話です。

まずHacobune自体をIaaSのように扱うのための要望が多く出るかと思います。

例えば既存のネットワーク内に入れないといけないとか。

どうやって同じネットワークアドレスにいれるかっていう視点で機能が作られてしまうと、結局Hacobuneというよりもコンテナの良さがIaaSに消されてしまいレガシーシステムのリビルドになってしまいます。 ここでぼくとしては同じネットワークというよりも、そのネットワークからしか参照できないコンテナ、という考え方がベストだと思っています。 コンテナという独立性を活かしつつ既存のネットワークからセキュアに接続させるって感じですよね。

まあ、これはHacobuneについてるFQDNを内部DNS参照にするということをやればいいわけで是非その機能を実装してほしいです。(まず最初に)

そうすればさくらのクラウドに構築しているIaaSから特にリファクタリングなしにHacobuneへシームレスに繋がると思います。(そして簡単)

あとコンテナは先にも書きましたがエフェメラルディスクですからステートレス構成にする必要があります。 現在ステートを保管するためにRedisが提供されていますが、それ以外にも忘れがちなのがログです。 是非ログ管理できる仕組みを入れてほしいです。

最後にコンテナのパイプラインについて。 BuildーShipーRunって言いますが、Shipの部分です。 ここにさくらのクラウドの中で提供されるレジストリが欲しいです。 理由はShipーRunのパイプラインが近ければ近いほどリードタイムが効率化するからです。 一昔前にDevOpsの指標として10 deploy per dayなんて言葉ありましたけど、リードタイムも非常に重要な指標です。

と書いて気が付いたのですがHacobuneではなくさくらのクラウドのほうにコンテナレジストリがありました!! f:id:koji_kchc:20210908173014p:plain

ということで期待しかないこのHacobune(β)をうまく乗りこなしたいので正式リリースが待ち遠しい限りでございます。