いちはじCDK第2回 構成を考える編

では!

第2回です。今回は今後どうして行くかを書いていこうと思います。

StackとConstruct

改めてStackとConstructについて書いてみます。

Stack(スタック)
Constructの集まりですね。
(´・ω・)・・・えっ?

Construct(コンストラクタ)
EC2とか、ALBとかそー言った個々のリソースになります。
(´・ω・)・・・手ぇ抜くなよ・・・
Constructはまだ続きありますよ。
まず、種類がL1、L2、L3と3種類あります。
L1は、Cloud Formationと1対1の関係にあり、コーディングの際に一番手間がかかります。
L2は、L1を手間がかからないようにしたものです。
L3は、更に便利に手間がかからないようにしたもの。
(´・ω・)・・・雑だな・・・説明が・・・
という感じです。

L2を使うのがメジャーなのかなと・・・。L2は知らなくても、裏で色々やってくれるので楽です。
ただ、細かい部分が見えにくくなります。L2が便利なんですけど、本ブログでは、L1を扱います。
手間がかかるんですけど、苦労がある分なにか良いこともあるのでは?って思うんですよね。
(´・ω・)えー・・・ないだろ~

L1のConstructの使い方を調べる。

これは「地道に仕様書を確認する」のが一番確実かなと思います。
英語で書いてありますが、ひとつづつ訳して内容を確認していきます。
読んでも感じがつかめない場合は、AWSのコンソールと比較したり、ネットで検索して使い方の例を調べたりしながら真実に近づいていく・・・そんな作業です・・・ただ、そもそもL1は例が少ないので、この辺も苦労しますね。
仕様書は以下のリンクになります。
CDKにはV1とV2のバージョンがあります。V2を見るようにしましょう。V1は使われなくなります。
https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib-readme.html
L1のConstructはCFnから始まります。以下はECSのタスク定義のConstructの例です。

試しに、PythonのConstruct仕様書を見てみると以下の感じです。

まあ、英語ですね。注目すべきはSeeのところに、対応するCloud Formationのリンク先が書いてあります。パラメータの詳細設定値なんか調べるときに、CDKの仕様書には書いてないけど、Cloud Formation側には書いてあったりするので合わせてチェックするのが良いです。
Example:の下にパラメータ設定例が書いてありますが、これはあまり役に立たないです。
実際に設定する値が書いてないので…イメージをつかめる程度・・・といった感じなります。
でパラメターの説明をみると以下の感じです。

これ見たら「むッ」って感じますよね…まぁ拒否的反応になるかなと思います。
それが言いたいだけでこれを張り付けました。
ともかくパラメータが多いですね。で、どれが必要なのか?自分が使いたいケースではどれが必要なのか?そんなことを考えるのが非常に大変だし、見ているとだんだん混乱していきますね・・・
(´・ω・)では?どうしましょう?

ではどうしましょう!

あ、どう使うのかというのは、やはりやってみるのが一番はやいですね。トライ and エラーを乗り越えて・・・分かったことを整理していく・・・の繰り返しです。
(・´з`・)え?この流れで無策?

・・・ええ、まぁ・・・(´・ω・)。

でも、コーディングの方は工夫していきたいですね。。。ということで・・・
・メインの処理は、全体的流れが見やすい。
・各Constructのパラメータは、パラメータファイルにまとめて整理する。
みたいなことを目標にしていきたいと思います。

違いが伝わるように、ベタ書きと、未来的構想を描いてみます。
まずはベタ書き…あまりに長いので少し省略していますが…以下の感じです。

from aws_cdk import aws_ecs as ecs

cfn_task_definition = ecs.CfnTaskDefinition(self, "MyCfnTaskDefinition",
    container_definitions=[aaaa,bbbb,cccc],
    cpu="cpu",
    ephemeral_storage=ecs.CfnTaskDefinition.EphemeralStorageProperty(size_in_gi_b=123),
    execution_role_arn="executionRoleArn",
    family="family",
    inference_accelerators=[ecs.CfnTaskDefinition.InferenceAcceleratorProperty(
        device_name="deviceName",
        device_type="deviceType"
    )],
    ipc_mode="ipcMode",
    memory="memory",
    network_mode="networkMode",
    pid_mode="pidMode",
    placement_constraints=[ecs.CfnTaskDefinition.TaskDefinitionPlacementConstraintProperty(
        type="type",
        expression="expression"
    )],
    proxy_configuration=ecs.CfnTaskDefinition.ProxyConfigurationProperty(
        container_name="containerName",
        proxy_configuration_properties=[ecs.CfnTaskDefinition.KeyValuePairProperty(
            name="name",
            value="value"
        )],
        type="type"
    ),
    requires_compatibilities=["requiresCompatibilities"],
    runtime_platform=ecs.CfnTaskDefinition.RuntimePlatformProperty(
        cpu_architecture="cpuArchitecture",
        operating_system_family="operatingSystemFamily"
    ),
    tags=[CfnTag(key="key",value="value")],
    task_role_arn="taskRoleArn",
    volumes=[aaa,bbb,ccc]
)

次に未来的構成です。上記の記載が2行くらいに圧縮されます。

from construct_base.mycfntaskdefinition import MyCfnTaskDefinition

MyCfnTaskDefinition(self,config=task_config,containers=containers)

随分スッキリしたように見えますね・・・まぁスッキリしたように見えるだけですけどね・・・
(´・ω・)まぁパラメータが消えるわけじゃないからね・・・
そうですね。パラメータは、パラメータリストにまとめて書いて、まとめて渡すようにする事で、こんな感じになっています。
(´・ω・)結局パラメータリストは書かんとあかんのやろぉ・・・
メイン処理はスッキリするので、全体の流れは読み取りやすくなるでしょう。
細かく見たければ、パラメータを見ればよいと思うので・・・良くなるのでは?と期待!?
以下に「こんな感じ」的なイメージをペタって張ります。

パラメータリストをclassのデータに被せるところは、ひと昔前のCOBOLのコピー句みたいな感じですね・・・pythonは型を意識しなくていい言語だけど結局型を意識することが多いのは・・・気のせいか?
(´・ω・)裏でパラメータリストとか、ラッパー関数作ったり、するのがメンドクサソウだが!?
面倒でしょうけど、一度作れば使いまわしが効くので、面倒なのは最初のだけになるかなと…

改めてプロジェクト構成

ここまで、色々グダグダと書いて来ましたが、これを踏まえて改めてプロジェクト構成を考えてみようかと思います。欲しいのは・・・
・各Constructはラッパー関数を作るので、それをまとめておくディレクトリが欲しい。
・pydanticを使ってデータ構成を定義するので、それをまとめておくディレクトリが欲しい。
・yamlファイルにパラメータ書いおくので、それをまとめておくディレクトリが欲しい。
・自分のサービスを提供するためのデータ構成を格納するディレクトリが欲しい。
というあたりになりますね。

cdk_core_project/
├ .venv/
├ core/ → cdk_core_project/が長いのでcoreにしました。python的には異端ですかね…
│├ myconstructs/
│├ basetypes/
│├ servicetypes/
│└ parameters/
├ tests/
├ app.py
├ cdk.json
├ README.md
├ requirements-dev.txt
└ requirements.txt

細かいファイルは省略してますが、赤字のディレクトリを追加してそこに必要なものを格納してく感じです。pythonのプロジェクト構成的には、「core/」の下に収めるのが一般的?らしいのでこんな感じにしてみました。
中身については、実際にモノを作りながら少しづつ増やしていくつもりです。
この続きは第3回以降でーーーーーーーーーー。「いちはじCDK第3回 VPCとサブネット①編

コメント

タイトルとURLをコピーしました