よろしい.私はコードを計装して、それをコンパイルしました.今では、ターゲット環境でアプリケーションを展開する時間です.

展開

私はこのコマンドを使います

cloudcc up --work-dir compiledAWS/ --stackname klothofirstrun

意味は簡単です.up 配備のパラメータです.--work-dir コンパイルされたプロジェクトの場所と--stackname はアプリケーションの名前です(コンパイルステップ中に与えられます).
を、大きな瞬間.私は入力ヒット!

エラー

さて、最初の実行中にエラーがあります.短い調査の後、それは明白でした.私には思いがけないもの

'FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

それで、私はEC 2のサイズを速く変えて、再び配備を実行します.
さて、今回は別のエラーです.

aws:cloudwatch:EventRuleEventSubscription (qrender-2de26_scheduledCleanup_act):
    error: Duplicate resource URN 'urn:pulumi:klothofirstrun::klothofirstrun::aws:cloudwatch:EventRuleEventSubscription::qrender-2de26_scheduledCleanup_act'; try giving it a unique name

何もしなかったので、全く奇妙です.
を、私はスタック(成功)を破壊しようとし、それを再現します.まだ何も同じエラーです.
…私は考えた.ちょうど始めましたね.のMS Windowsモードで-それをしましょうcompiledAWS and dist ディレクトリ、コンパイルしたプロジェクトを再度コンパイルし、新しくコンパイルされたスタックを展開します.そして


出力を調べて、私は複数のIAM役割と方針を見ます.それは完璧であり、少なくとも特権の原則に向かって良い動きである.CloudWatchロググループは、各リソースに対しても作成されます.APIゲートウェイ、子午線とダイナモもそこにあります.この瞬間驚くべきことは、私が以前に提示したダイアグラムに含まれていないSQSを見ます.私も心配します、1つのECRだけがつくられるでしょう.それがどのように見えるかについて見ます.
私は以前の問題をトラブルシューティングするのに時間を費やしていなかった.Klothoのようなルックスは、十分なメモリがないため失敗しました.しかし、私はそれをプルミに関連した「問題」と理解します.
よく、配備は失敗しました.問題は簡単です、マシンを再起動した後に覚えていますか?実際の展開プロセスが始まる前に、すべての依存関係がklothoによってチェックされるなら、それは非常によいでしょう.
私はDockerを始め、プロジェクトを再適用しました.
そしてそれはおかしい:Dエラー、再びこの原因は異なる-デバイス上のスペースはありません.心配しないでください.

lsblk
growpart /dev/nvme0n1 1
lsblk
xfs_growfs -d /
df -h

そして、私は戻っています.また配備する
今回はもっと重大なエラーを見つけました.コンパイル中にカスタムディレクトリを使いました.そして、私は罰されました.

Error exporting Error: ENOENT: no such file or directory, open '/home/ec2-user/tutorial-starters/webapi/compiled/klothofirstrun-spec.json'
    at Object.openSync (fs.js:458:3)
    at Object.writeFileSync (fs.js:1283:35)
    at /usr/local/bin/out/cloudcc.js:242515:8
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5) {
  errno: -2,
  syscall: 'open',
  code: 'ENOENT',
  path: '/home/ec2-user/tutorial-starters/webapi/compiled/klothofirstrun-spec.json'

これは確かにクリエイターによってチェックされる何かです.
OK、スタックを再びストールし、ディレクトリをクリアしました(例では)、コンパイルを開始し、再度展開を開始しました.compiled .
そして最後に成功!

私は出力のAPIにURLを受け取ったので、私はそれをテストする準備ができています!
もちろん、Klothoドキュメントの例を使用します.

curl https://uq5xlogu5k.execute-api.us-east-1.amazonaws.com/stage/v1/users
["Zendaya","Remi","Nadira"]

だから、それは動作!しかし、私が予想通りに.コールドスタートは非常に大きいです.

回る

現実のインフラを通して行きましょう.
最初のポイントは、ECR(エラスティックコンテナレジストリ).唯一のECRが作成され、すべての画像がカスタムタグでそこに格納されます.私はそれが好きではない.私は、もちろん、なぜそれを知っています.Klothoの創造者の考えでは、誰もそこには見ないだろう.しかし、私はします:D

脆弱性スキャンをデフォルトとして有効にすることを強く推奨したい.そして、私はイメージと適当なタグ付けにつきECRで最高の実行アプローチを見るのを好みます.第2のものはマイナーです.
私は次のCloudWatchチェックします.非常に貴重な可能性がある場合は可能性がX線や洞察力を有効にすることができます.CloudWatchログはデフォルトで1日に設定された保持を持っています.非常に良い.
私はコールドスタートを見せるためにここに行きました.下の画面を見てください.

ColdStartが8秒と実際の実行を2秒以上取ったのが見える.ラムダが暖かくなると,すべては9 milesecondsで閉じられた.差分は巨大であり、ラッカーの上でDockerを実行することによって引き起こされます.これはklotho側では何が改善されないのかということです.ここでコールドスタート問題には入りません.Serverlessで動作する人たちはあまりにもよく知っています.
ラムダサービスはよく見えます.
APIゲートウェイを見てみましょう.

名前app 私は1つのステージだけを持っています、何が多分多段セットアップに改善されるべきですか、しかし、それは大したことではありません、klothoは経路を通して異なるバージョンを管理します.Rootlingは有効になります( nice ).ここで改善を見たい.
sqsが作成されます.私は図の上でそれを見ませんでした、しかし、そこにあります:構成はかなり標準に見えます.実際、すべての関数はこのSQSで動作する許可を持っていますが、キューで何が行われているかをチェックしませんでした.
DynamoDBは、プロビジョニング容量モードで作成されます.
IAMは非常にきれいに準備されます.構成は可能な限り狭くなります、許可と資源は必要であるものに制限されます.私は本当にそれが好きです.
S 3は1つの例外でかなり標準に見えます.見たいblock all public access 有効にする.

ファイナルアクション

私の遊び場の終わりに、私はスタックを削除しました.procesは(コンパイルと展開よりも確実に速い)、すべてのリソースが予想通りに削除されました.

cloudcc destroy --work-dir compiled --stackname klothofirstrun

最後に、Pulumiを削除して、歴史と関連データを削除しました.

pulumi stack rm klothofirstrun

それはKlothoと私の基本的な経験の要約のための時間です.