LOLIPOP! マネージドクラウド触ってみた

昨日オープンβとしてリリースしたロリポップ！マネージドクラウド、まだまだどなたでも無料でしばらくご利用可能ですので、お気軽にお試し下さい。βのフィードバックも継続的に改善していきますのでご要望もどしどし頂けると幸いです。ひとまずアプリをシュッと試すなど是非。 https://t.co/LhKq9v9mn4
— 松本亮介 / まつもとりー (@matsumotory) 2017年12月1日

↑を見たので触ってみました。

マネージドクラウドの特徴としては以下の3つが挙げられています。

自動セットアップ
- いろいろプリセットが用意されてて選んだらポチで立ち上がる
- 数秒で立ち上がるらしい
いつでもサイト表示
- オートスケールのことっぽい
常にセキュアな環境
- セキュリティアップデートとかが自動だという意味

コンテナという単語が出てきているのでLXCをベースにしたなにかなのでしょう。

とりあえずメールアドレスとパスワードをいれて登録していきます。
登録するとプロジェクト作成画面に進みます。

f:id:hkdnet:20171202013320p:plain

そういえば登録した覚えがないけどアイコンついてますね。gravatar かな。
どうも下部を見ると Rails 推しっぽいので Rails にしておきます。

f:id:hkdnet:20171202013443p:plain

まだ灰色で選択できませんが hubot とかあって適当に chatbot をデプロイするのにもよさそうです。
プロジェクトURLがあるのでうれしいですね(って書いたけど heroku も OpenShift もあったわ)
ベータ期間なので無料だしクレカ登録もなく使えるのは嬉しいのですが、ベータが終わったらどんくらいのコスト感なのかは気になるところですね。

さて、プロジェクトを作成するとプロジェクトのダッシュボードにいきなり放り出されます。
ここたぶん何をどうすればいいのかわからなくなる人が多そうですね……。

とりあえず ssh するために ssh 公開鍵を追加しておきましょう。画面が単純なので割愛します。

というわけでプロジェクトトップに書いてある ssh コマンドを叩いてみるのだ

$ ssh -p XXX YYY@ZZZ
Last login: Fri Dec  1 17:02:43 2017 from 10.1.1.1
  __  __  ____   _          _ _
 |  \/  |/ ___| | |    ___ | (_)_ __   ___  _ __
 | |\/| | |     | |   / _ \| | | '_ \ / _ \| '_ \
 | |  | | |___ _| |__| (_) | | | |_) | (_) | |_) |
 |_|  |_|\____(_)_____\___/|_|_| .__/ \___/| .__/
                               |_|         |_|

******* Welcome to Lolipop! Managed Cloud *******

YYY@WWW:~$ pwd
/var/app
YYY@WWW:~$ ls
0000000000000000  current  shared  user_command.sh.sample
YYY@WWW:~$ ls current
Gemfile  Gemfile.lock  README.md  Rakefile  app  bin  config  config.ru  db  lib  log  package.json  public  test  tmp  vendor

普通にはいれますね。

オートスケールの設定はこんな感じ。

f:id:hkdnet:20171202233545p:plain

rails だとイメージ1個しかないんですね。nginx はさもうとかしたときにどこで何すればいいかはよくわからず。
とはいえたぶんそのへんってマネージドクラウドのサービス側でラウンドロビンとかはしてくれるんだろうなー。
static file の配信をうんぬんというのはいまんところ難しそう？CDN使えって感じかな。
ラウンドロビンするって考えると sticky な設定とかがあるのか気になります¹

デプロイとかは medium にあるヘルプから察するに push すればよさそうです。
でも remote add したあとに push するだけだと --force いるんじゃないかなあ……。
という気持ちをもとにとりあえず git init して remote を追加した状態で fetch してみましょう

# local
$ git init
$ git remote add lolipop xxx # 表示されているやつをうつ
$ git fetch lolipop
fatal: '/var/lib/lolipop/projrepo/.git' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

実はまだリモートレポジトリは存在していなかったようです。
念のためマネージドクラウド側のコンソールでも確認

# managed cloud
$ ls /var/lib/lolipop/projrepo/
ls: cannot access /var/lib/lolipop/projrepo/: No such file or directory

仕方ないので rails new しておきましょう。
データベースを選んだ記憶はありませんがホスト名が mysql なのでおそらく mysql なのでしょう。

# local
$ bundle init
# Gemfile を適当に編集
$ bundle install --path vendor/bundle
$ bundle exec rails new --database=mysql .

database.yml もなんかいい感じに編集すればいいんじゃないでしょうか
記載内容はダッシュボードから拾ってきてください。

diff --git a/config/database.yml b/config/database.yml
index 0c61325..1a636b9 100644
--- a/config/database.yml
+++ b/config/database.yml
@@ -49,6 +49,7 @@ test:
 #
 production:
   <<: *default
-  database: tmp-rails_production
-  username: tmp-rails
-  password: <%= ENV['TMP-RAILS_DATABASE_PASSWORD'] %>
+  database: your_database
+  username: your_username
+  password: your_password
+  host: mysql-1.mc.lolipop.lan

password はベタ書きせずに環境変数にいれたくなりますがどーもその機構はない気がするので強い気持ちでコミットします

dbつかえるか確かめたいので適当に scaffold しておきましょう

$ bin/rails g scaffold Comment text:text
$ git commit -m 'comment'
$ git push lolipop master

と、これは別に意図してなかったのですがうっかり db:create, db:migrate を打つのを忘れてました。てへぺろ
なので db/scheam.rb は更新がない状態でデプロイされましたが db:create, db:migrate されたログが残って普通に起動しましたね

$ git push lolipop master
(中略)
remote: Database 'XXX' already exists
remote: == 20171202150523 CreateComments: migrating ===================================
remote: -- create_table(:comments)
remote:    -> 0.0046s
remote: == 20171202150523 CreateComments: migrated (0.0047s) ==========================
remote:

普通にアクセスできますね。

f:id:hkdnet:20171203004551p:plain

最初は、レスポンスが返ってくるまでに13秒くらいかかってましたが、dev tool開いたあたりからいきなり早くなりました。なぞい。
謎いなーと思いながらダッシュボードを見てたらコンテナ数が増えてたみたいです。

f:id:hkdnet:20171203005200p:plain

うんうん、そしたらはやくなるかもねって思ったのですが、コンテナの数が増えたからって1ユーザーのリクエストがそんな早くなるわけないですよね。
うーん、増えたコンテナに性能の善し悪しがあるのでしょうか？

あと適当にさわってるとときたま落ちます。落ちたときに ssh してログをみてみましょう。
適当にエスパーして $HOME/current/ が現在のアプリケーションだと考えるとその先の $HOME/current/log/production.log を見ればよさそうです。
vim が入ってるので適当にひらいておきます(less はなかった)

I, [2017-12-02T15:56:45.157297 #4]  INFO -- : [de41a671-8b69-4771-8c0e-83187b2c6456] Started POST "/comments" for x.x.x.x at 2017-12-02 15:56:45 +0000
(略)
W, [2017-12-02T15:56:45.159596 #4]  WARN -- : [de41a671-8b69-4771-8c0e-83187b2c6456] Can't verify CSRF token authenticity.
I, [2017-12-02T15:56:45.159979 #4]  INFO -- : [de41a671-8b69-4771-8c0e-83187b2c6456] Completed 422 Unprocessable Entity in 1ms (ActiveRecord: 0.0ms)
F, [2017-12-02T15:56:45.161589 #4] FATAL -- : [de41a671-8b69-4771-8c0e-83187b2c6456]
F, [2017-12-02T15:56:45.161650 #4] FATAL -- : [de41a671-8b69-4771-8c0e-83187b2c6456] ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):

うーん、CSRF対策のトークンの検証で死んでますね。
たぶんなんですけど画面をレンダリングしたコンテナと違うところにいったら死ぬのかな……。

まとめ

現状での懸念点は以下でしょうか

環境変数を管理するクチがない？
プロジェクトに対してミドルウェアを挟む余地が今のところなさそう
- いずれちゃんと対応されそう
コンテナベースなんだけどライフサイクルがわからない
- テクニカルなドキュメントが充実すれば……
デプロイ時に何が起きるのかブラックボックス過ぎて気になる
- 知りたいし変更したい
そもそも ssh してる先ってどこなんだろ？
- コンテナの中なの？コンテナのホストなの？
- これもまあドキュメントが充実すれば
ssh先のディレクトリ構成がよくわからん
- cap っぽい雰囲気を感じたけど
ログみたいときにいまのところ ssh するしかない
- いずれちゃんと対応され……るのだろうか？
- 他サービスに流しちゃうほうが楽かも
どんくらいのコスト感なのか知りたい
- 有料化が決まる頃にはわかるので待つだけ

正直、いまのところはお手軽感よりブラックボックス感がつよい印象です。今後に期待ということで。

追記: つかったプロジェクト削除しようとしたらできなくて困っている……
削除確認用にプロジェクト名をいれたあとパスワードをいれても削除に失敗しました、と出てしまう。
変な文字列いれるとパスワードが違うと言われるので認証はできてるみたいなんだけど。
時間課金とかになるだろうから、削除リクエスト自体はこの時間で受けてほしいなーとおもいつつリソースはまだ使えちゃうからどうなんだろうなと思っている

(フラグ↩