データベース技術調査ブログ

LinuxやPostgreSQL、Oracleデータベース、AWSの知識をアウトプットしていきます

【AWS CDK】cdk initするディレクトリ名でハマった件

最近、専らPostgreSQLAWSの勉強ばかりしています。
この本を読んでAWSの勉強をさせてもらっていますが、本に記載されている演習でAWS CDKを触ったので、python版(本だとAWS CDKの親玉のtypescriptでした)のCDKの方が自分には理解しやすいぞということで、VirtualBoxUbuntu上にAWS CDKの環境を作ってPycharmでいろいろいじってみようと環境を作ろうとしました。

環境の説明

以下の環境です。
ホストPC:Windows 10 Home
仮想化SW:VirtualBox 6.0
ゲストOS:Ubuntu 18.04

Ubuntu上での環境
※anyenvでnodenvとpyenv(+ virutalenv)を管理

  • node.jsのバージョン: 12.16.3
  • pythonのバージョン: 3.7.7
  • AWS CDKのバージョン: 1.38.0
$ node -v
v12.16.3
$ 
$ python -V
Python 3.7.7
$ 
$ cdk --version
1.38.0 (build d5fa31f)
$ 

遭遇したエラー

上記の環境で意気揚々と cdk init --language python を実行し、
source .env/bin/activate を実行して仮想環境に入って、
pip list で確認したらpipが最新じゃないぞって怒られたので、
pip install --upgrade pip を実行してから
pip install -r requirements.txt で必要なライブラリをインストールしました。


これで準備完了ということで試しにcdk ls を実行したら、以下のエラーが出ました。

$ cdk ls
Traceback (most recent call last):
  File "app.py", line 3, in <module>
    from aws_cdk import core
ImportError: cannot import name 'core' from 'aws_cdk' (/home/jimatomo/PycharmProjects/aws-cdk/aws_cdk/__init__.py)
Subprocess exited with error 1
$


たぶん、見る人が見たらこれだけでなるほど!となるのでしょうが、自分は何のことやら?と思っていろいろ試行錯誤してしまいました(´・ω・)


結論からいうと、ここ(赤字)が問題でした。

/home/jimatomo/PycharmProjects/aws-cdk/aws_cdk/__init__.py

エラー原因の特定

まずは、エラーの原因を追うために「app.py」を確認してみましょう。

$ cat app.py 
#!/usr/bin/env python3

from aws_cdk import core

from aws_cdk.aws_cdk_stack import AwsCdkStack


app = core.App()
AwsCdkStack(app, "aws-cdk", env={'region': 'us-west-2'})

app.synth()
$ 


エラーが出ているこの行をご覧ください!

from aws_cdk import core

「あれ、cdk initで作ってもらったモジュール名と同じじゃん!」って気づくはずなんです。
だがしかし、この時点で知らなかったのです、cdk initで作成されるプロジェクトの中でできるモジュール名は実行するディレクトリ名が利用されるという仕様を。

この仕様の影響で、何も考えず作ったディレクトリ名「aws-cdk」が悪さをしてしまったのです。


落ちは…

つまり、本来呼び出したいライブラリの名前とcdk initで作成されたモジュール名がもろかぶりだったことが原因でした。
aws_cdkというpipで入れたaws-cdkライブラリとcdk initで作成されたモジュール名がもろかぶりだったので、ほぼほぼすっからかんのaws_cdkモジュール側からcore機能をインポートしようとしていたので、エラーが発生したという落ちでした。


このcdk initの仕様は、以下のワークショップを見ていて気付きました。
cdkworkshop.com

「あれ、モジュール名ってaws_cdkじゃないの…?」( ̄▽ ̄)


最後に

やっぱり基礎がしっかりしていないトラブルシューティングで明後日の方向に調査の手を出してしまっていけないですね、というのが今回の感想です。