こんにちは。蜜蜂の館のリメイク度合いが楽しみなgamenechangeです。今回は、AWS Elastic Beanstalk（以下、EB）に対して、サブモジュールを使用しているプロジェクトを$ eb deployする際にハマってしまったことを書かせて頂きます。

以下の内容では、Railsアプリをデプロイすることを前提としています。

$ eb deploy した後にサブモジュールのディレクトリの中身が空っぽになる事象が発生

先日、普段のように Railsアプリを$ eb deployし、特にエラーもなくデプロイが終了しました。しかしながら、Webブラウザで動作を確認すると500エラーが出て正常に動作していませんでした。

慌てて原因を調査したところ、サブモジュールを用いる部分の処理が理由で500エラーになっていることが分かりました。具体的に調査すべく$ eb sshを行い、当該サブモジュールのディレクトリの中身を確認してみました。

……空っぽでした。ファイルやディレクトリが何も存在していませんでした。

サブモジュールが正しく $ git submodule update できていない

ローカル開発環境では、当該サブモジュールのディレクトリには期待通りのファイルが存在しています。つまり、EB上ではサブモジュールが正しく$ git submodule update（以下、update）できていないことが分かりました。

確認したこと

サブモジュールが正しくupdateできていないため、まずは.gitmodulesの内容を確認します。さらに.gitmodulesが正しくデプロイされているか（例えば、.ebignoreの中で.gitmodulesを除外ファイルとして指定してしまっていないか）を確かめました*1。

……いずれも問題ありませんでした。

原因はサブモジュールにアクセスするための権限の設定にあった

さらに調査を進め、今度は$ eb sshを経てEBの環境内でサブモジュールをupdateしようとしました。すると「アクセス権がない」旨のエラー表示が出て正しくupdateできませんでした。

アクセス権の問題とのことで、改めて.gitmodulesを確認しました。すると以下のように、url:の箇所に、git@github.com:foobar/hogehoge.gitという書式でサブモジュールのURLが記述されていました。

[submodule "fuga/hogehoge"]
    path = fuga/hogehoge
    url = git@github.com:foobar/hogehoge.git

ここで重要なことは「サブモジュールをupdateする主体はEBのCLIを実行したユーザになる」ということです*2。したがって、「$ eb deployのコマンドを実行したユーザ*3」がこのリポジトリにアクセスできる権限を持っていなければなりません。

このことに気づき、ローカル開発環境の自分のアカウントの~/.ssh/configを確かめてみたところ、当該サブモジュールへアクセスするための鍵の指定が適切ではないことが分かりました。そして正しい鍵を設定した後に$ eb deployを改めて実行したところ、サブモジュールが正しくupdateされました。一件落着です。

aws-elastic-beanstalk-cli のコードを読んで具体的な動作を確認する

上記の内容の具体的な動作をaws-elastic-beanstalk-cliのコードを読んで確認してみましょう。

まず、ebcli/objects/sourcecontrol.py の中の do_zip メソッドの中で、サブモジュールを$ git submodule foreach --recursiveしています。

※ここで、Railsプロジェクト内に存在する.elasticbeanstalk/config.ymlに記載されているglobal: include_git_submodules:のtrue/falseを判別している箇所があり、ここにfalseを設定すればsubmoduleをupdateしない挙動にすることが可能です

            must_zip_submodules = fileoperations.get_config_setting('global', 'include_git_submodules')

            if must_zip_submodules:
                stdout, stderr, exitcode = self._run_cmd(['git', 'submodule', 'foreach', '--recursive'])

                for index, line in enumerate(stdout.splitlines()):
                    submodule_dir = line.split(' ')[1].strip('\'')
                    os.chdir(os.path.join(project_root, submodule_dir))
                    self.do_zip_submodule(
                        location,
                        "{0}_{1}".format(
                            location,
                            str(index)
                        ),
                        staged=staged,
                        submodule_dir=submodule_dir
                    )

次に上記のコードにあるdo_zip_submodule メソッドを見てみます。すると、submoduleを$ git archiveしてzipファイルに固めていることが分かります。

        # individually zip submodules if there are any
        stdout, stderr, exitcode = self._run_cmd(['git', 'archive', '-v', '--format=zip',
                                                  '--prefix', os.path.join(submodule_dir, ''),
                                                  '-o', sub_location, commit_id])

この一連の「$ git submodule foreach --recursiveを実行して$ git archiveを実行する」という流れは、EBのCLIを実行した時の流れです。したがってこの流れより、「CLI実行ユーザがsubmoduleへのアクセス権限を持つ必要がある」という結論を導くことができます。

図解

これまでの説明を簡単に図解すると下の図のようになります。

$ eb deployするユーザ（下図ではenechange_user）は内部的に$ git submoduleコマンドを実行します。そしてそれにより取得できたファイルを$ git archiveコマンドで zipファイルに固めて、それをEBへデプロイするという流れになります。EB側では$ git submoduleコマンドは実行されません。

f:id:gamenechange:20200408164253p:plain

ハマりどころ

今回ハマった理由の一つは、たとえsubmoduleのgitリポジトリの権限の設定が不適切であったとしても $ eb deploy 自体は成功することです*4。以下がそのときのターミナルのログです。

$ eb deploy
Creating application version archive "app-foo-bar".
Uploading: [##################################################] 100% Done...
2020-04-05 23:38:51    INFO    Environment update is starting.
2020-04-05 23:39:01    INFO    Deploying new version to instance(s).
2020-04-05 23:40:36    INFO    New application version was deployed to running EC2 instances.
2020-04-05 23:40:36    INFO    Environment update completed successfully.

このログが表示されたため、サブモジュールや、そのサブモジュールをupdateするための権限が不適切であることがエラーの原因だとは直ちに思いつきませんでした。