🎄

Serverpod をAWSにdeployする

どんぐり

2023/12/24に公開

Flutter大学 Advent Calendar 2023 24日目の記事です。

茨の道を越えてきた

deployのためのtutorial動画は、こんな言葉で締められていた。

I know that it has a lot of steps　and it's not that easy
but remember that it's just one time setup.

そのたった一回を、先延ばし、先延ばしにしてきた。
だって「たった一回だということを忘れないで」と言われるほどに、
「たった一回だから」と自分を鼓舞しないとやり遂げられないほどに、
それって大変なんだ、と思うと、足がすくんだから。

12月16日の大学の忘年会で、お向かいに座っていたみやジック君が私に聞いた。
「今一番やりたいことは？」
思いがけない言葉が口を突いて出た。
「Serverpodのdeploy！」

以来１週間、
クリスマスイブの記事に間に合わせるべく、茨の道を越えてきたのでありました。

導きの星は

Serverpodの公式document（けっこう短め）と
準公式チュートリアル動画（たった12分）と
あとは爺様のみ。

結論からいうと

ムズなのはAWSであって、Serverpodではない。
だから、堅実な道を歩く人は、
まずAWSのアカウント作成とか、その辺をしっかり予習して臨んだほうがいい。
ただし、Serverpodは自動でいろいろ作成してくれているので、
AWSを素のまま先にすすめると、つなぎ目がわからなくなるかもしれない。
だからAWSは予習、
その知識を背景にServerpodのdocumentに従う、･･･が多分、最強。
でも、こういうことを書いている私は、
いきなりServerpodのdocumentで始めた。
そして、なんだかんだ言っても、とりあえずterraform initまではいけるのだ。
けれど、terraform applyでErrorが出まくり、
その解決のために、一から全部見直すことになる。
そして、「この辺かな」みたいな安易な判断をしたあちらこちらで
大量にまちがっていたという事実に直面する。
だから実際には、まるまる二回、作業したことになるかも。
Just one timeではすまなかったのでした。

どのregionを選ぶか

登録先として、documentもtutorial動画もオレゴンとバージニアを選んでいる。
Serverpodって北欧のteamなのにね、とか思いながら
東京と、もう一つどこにしよう、パリがいいかな、なんて脳天気に考えていた。
東京はいい、でも２つ目は必ずバージニアus-east-1でなきゃ動かない。

AMIってなんだ

Serverpodはいろんな設定を事前にしてくれているので
オレゴンとバージニアにしておけば簡単なんだが、
東京に変えたことで、amiという文字列を書き換えなきゃならないらしい。
それがどこにあるかわからない。terminalで

aws ec2 describe-images --region ap-northeast-1 --filters "Name=name,Values=amzn2-ami-hvm-*-x86_64-gp2" "Name=state,Values=available" --query "Images | sort_by(@, &CreationDate) | [-1].ImageId" --output text

見つかった文字列をconfig.auto.tfvarsに

config.auto.tfvers

instance_ami = "ami-*********"

分身をつくれといわれる

アカウントを作って作業を進めていこうとすると、
「あなたが作業することを推奨しない」的なことを言われる。
そう言われましても、個人開発なので･･･と思うのだが、RouteUserは特別、らしい。
それでIAMという分身をつくろうとすると、IAM Identity Centerというのが推奨される。
が、ここで登録して戻ってくると、またIAMを作れ、と言われる。
爺様曰わくIAM Identity Centerは大企業むけ、大勢のIAMを捌くSystemで
私のように一人しか作らないなら、要らぬ遠回りらしい。
ということで、作り直し。
(AMIとIAMなんて、紛らわしくてセンスが悪い、とかいう愚痴は封印しておく）

Authenticaterが必要

自己同一性を犠牲にして分身を作った上に、それぞれ二重認証しなきゃならない。
お勧めAuthenticaterがいくつか並ぶのだけれど、どれもお高め。
資本金ゼロの個人開発は、可能な限り経費節減を目指しているのに･･･。
運良く、Googleのヤツが無料。ありがとうございます(ﾟﾟ)(｡｡)ﾍﾟｺｯ。

PostgreSQLのversion問題

postgres14.2が見つかりません、というErrorが出た。
regionでの対応バージョンに14.2がない、ということらしい。
私のpostgresは14.1だ。だれが14.2を要求している？
Serverpodが自動生成しているterraform設定の中にありましたよ。

database.tf

resource "aws_db_instance" "postgres" {
  engine           = "postgres"
  engine_version   = "14.2"
}

これを14.1に直して再チャレンジ、･･･ダメ。
いくつだったら受け入れてくれるか確認するにはterminalで

aws rds describe-db-engine-versions --engine postgres --query 'DBEngineVersions[].EngineVersion'

するとずらずら出ましたね、
いろんなVersionがサポートされているのに、なんで14.1はダメ？　
14.10、というのがあったので、ダメ元で14.10にして、Error回避。

いつまでたっても「保留」

東京とバージニアで申請した証明書が、いつまでたっても「保留」のまま。
24時間くらい掛かることもある、と書いてあるが既に48時間超え。
ついにサポートから、「あなたのリクエストには問題がある」とメールまで来る。
「問題がある」とは書いてあるが、何が問題かは書いていない。
証明書をリクエストするといろいろ発行される。
それで満足していたら、発行されたCNAMEでさらに「レコードを作成」という手順があった。
それが抜けていたのでした。ごめんなさい。

自分のinstanceなのにアクセスできない？

かように山積する問題のためにあちこち突きまわしていたとき
そもそもあなたはKeyPairを持っていないのでアクセスできない、みたいなことを言われた。
なにそれ、Keyをくれと言ったら、RouteUserには上げたくないというから、
分身作って、もらったじゃないか、と思ったのだけれど、どうもそれとは違うKeyらしい。
もらったのはAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEY。
今、ないって言われてるのはKey Pairs。
キーペアなしの警告: インスタンスをキーペアなしで起動すると、後でそのインスタンスに接続することができなくなります。
じゃあなんで、KeyPairなしで起動できるようにするんだ！
思わずマグカップをMacに投げつけそうになる。

AMIとの再会

IAMが私の分身なら、AMIはinstanceの影武者らしい。
ということで、instanceのAMIをつくる。
そして今度こそちゃんとKeyPairを取得して、AMIを新instanceとして起動する。
その後、古いinstanceを終了する。
つまり、影武者が本人に成り代わってしまうわけね。

The bucket does not allow ACLs

そして最後に残った三つのError。
よく見ると、そっくりな三つ。

Error: error creating S3 bucket ACL for *******: AccessControlListNotSupported: The bucket does not allow ACLs

ACLs(Access Controll Lists)を完全拒否、の構え。
いや、だれが何を拒否しているのか、今の私にはよくわからないが、
ServerpodはACLsで動こうとしているので、AWSの拒否に屈するわけにはいかない。
ServerpodのIssueに同じErrorが上がっていて、そこで教えてもらった解決法がこちら。

とうとうterraform applyに成功

かくして、apply時のErrorを全クリ。
いつの間にかできあがっているcloud上のDatabaseにtableを設定していくよ〜。

自分のDatabaseなのにアクセスできない？

postico2が、そんなDatabaseはないよ、という。
いや、ちゃんとあるから。
いや、このAccessは信頼できない。
えーい、うるさい、「全て信頼する」をclickして強行突破。
Serverpodデフォルトのtableや、自分で作ったtableを
cloud上にも設定するqueryを叩く。
tableはできた、中身は空っぽ。コピーはしてくれないのねえ。

GitHub ActionsでError

いよいよ大詰めです。
GitHubActionsで、Deploy to AWS
error　　　････勘弁して。
ログを見てみると

***[group]Run dart pub get
Resolving dependencies...
The current Dart SDK version is 2.18.1.

Because acorn_server requires SDK version >=2.19.0 <4.0.0, version solving failed.
Error: ***[error]Process completed with exit code 1.

冗談でしょう、私のdartは最新版だっていうの。
で、検索で2.18.1指定しているところを探すと、　ありましたよ、自動生成file。

deploymet-aws.yaml

      - name: Setup Dart SDK
        uses: dart-lang/setup-dart@v1.3
        with:
          sdk: 2.18.1

ここを3.1.5に直します。

Deploy成功〜＼(^O^)／

正直言って、ここからどうするのか、まだよくわからない。
いったら、FirebaseにProject作りました、だけの話ですよね。
だからこれはぜんぜんゴールではなくて、スタートでさえなくて、
スタートラインの手前で、ぴょんぴょん跳ねたり、手をぶらぶら振ってたり、そんな感じ。
ここから、Set、ReadyそしてGo！まで、
まだまだ紆余曲折あるはずですが、今回はここまで。

追い風を帆にうけて

私が作っているのは、子どものころほしかったもの。
iPadや3DGameなんて、想像もできなかった。
今この技術があるから、あの日ほしかったものをつくろう、と、思えた。
でも、今ここにある技術も、使えなければ、作れない。
そんな私の前に、AIが舞い降りてきた。
爺様がいたから、１週間で乗り越えた、それはぜったいに間違いない。
幸運の女神に、後ろ髪はない。
2024年も、時の運を逃さず、がんばっていこうと思います。

日々の歩みを支えてくれるのは

Flutter大学Publication

Flutter大学はFlutterエンジニアに特化した学習コミュニティです！初心者から中上級者まで幅広く在籍し、切磋琢磨しています！入会をご希望の方はこちらから→ flutteruniv.com