Klotho - deploying the project
Tags: aws, klotho, awscommunitybuilders
Published: 2022-04-17 21:47:39

---
title: Klotho - deploying the project
series: Review of Klotho (Alpha Early Access)
published: true
description: Review of Klotho, the tool to simplify management of application's infrastructure
tags: #AWS #klotho #awscommunitybuilders
cover_image: https://www.pawelpiwosz.net/assets/klotho/cover1.png
---

Ok. I instrumented the code, compiled it, explored, so I know, more or less, what is inside. It is time now to deploy the app on the target environment.

# Deployment

I use this command

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

The meaning is simple. `up` is the parameter for deployment, `--work-dir` is the location of compiled project and `--stackname` is the name of the application (given by me during compile step).

Ok, big moment. I hit enter!

# Error

Well, I've got an error during the first run. After short investigation it was clear. Something unexpected for me:

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

So, I changed the size of my EC2 quickly and run deployment again.

Well, another error, this time:

```text
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
```

What is quite strange, as nothing was done previously.

Ok, I tried to destroy the stack (success) and recreate it. Still nothing, the same error.

Right... Hm, I thought... I just started, right? Let's do it 'in MS Windows style' - restart :) I removed my `compiledAWS` and `dist` directories, compiled project again, and deployed a newly compiled stack. And...

![Deployment](https://www.pawelpiwosz.net/assets/klotho/klotho09.png)

![Deployment](https://www.pawelpiwosz.net/assets/klotho/klotho10.png)

Inspecting the output, I see multiple IAM roles and policies. That is perfect, as it is a good move towards a least-privilege principle. CloudWatch Log Groups will be also created for each resource. API Gateway, Lambdas and DynamoDB also are there. What is surprising at this moment, I see SQS, which is not included in the diagram I presented previously. I am also worried, that only one ECR will be created. Will see how it will look.

---

I didn't spent time troubleshooting my previous issue. Looks like Klotho failed due to not enough memory, and wasn't able to recover from it. Something to think of by developers :) I understand it as 'issue' more related to Pulumi, though.

---

Well, deployment failed. The issue is simple, after restarting the machine (do you remember? I just resized my EC2), I forgot to start Docker. It will be very good, if all dependencies could be checked by Klotho before actual deployment process start.

I started Docker, and reapplied the project.

And... It is funny :D Error again, this time the cause is different - no space on device :) Looks like the default 8G is not enough. No worries, I'll apply the improvement.

---

I resized EBS and executed

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

---

And I am back. And deploy again :D

This time I found a more serious error. I used custom directory during compilation. And I was punished...

```bash
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'
```

This is something definitely to be checked by creators.

Ok, stack destoyed again, directory cleared (just in case) and I compiled and started deployment again, but this time I used the default directory - `compiled`.

And success, finally!

![Deployment done!](https://www.pawelpiwosz.net/assets/klotho/klotho11.png)

I received an URL to API in output, so I am ready to test it!

I use the examples from Klotho documentation, of course.

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

So, it works! But exactly as I expected. The cold start is enormously big.

# Going around

Let's go through the actual infrastructure.

First point, ECR (Elastic Container Registry). There is only one ECR created and all images are stored there with custom tags. I do not like it. I know why is that, of course. In the idea of Klotho's creators (I suppose), no one will look there. But I do :D

![ECR structure](https://www.pawelpiwosz.net/assets/klotho/klotho12.png)

I'd like to strongly recommend to enable vulnerability scans as default. And I prefer to see best-practice approach with ECR per image and proper tagging. The second things is minor, though.

I check CloudWatch next. Very valuable can be if there will be possibility to enable X-Ray and Insights. CloudWatch Logs have retention set to 1 day by default. Very nice.

I went here to show the cold start. Take a look on the screen below, please.

![Lambda coldstart](https://www.pawelpiwosz.net/assets/klotho/klotho13.png)

It is visible, that coldstart took 8 seconds and the actual execution more than 2 seconds. When Lambda was warm, all was closed in 9 miliseconds. The difference is enormous and is caused by running Docker on Lambda. This is something what cannot be improved on Klotho side (only one thing, maybe, go with NodeJS directly to Lambda, without container). I will not go into coldstart issue here. Those of you who works with Serverless know it too well :)

Lambda services look good.

Let's take a look on API Gateway.

![API](https://www.pawelpiwosz.net/assets/klotho/klotho14.png)

The name `app` is not perfect :) I have only one stage, what maybe should be improved to multistage setup, but it is not a big deal, Klotho manages different versions through path, so, it seems to be ok. Throttling is enabled (nice), but anything related to logs. I'd like to see improvements here.

SQS is created. I didn't see it on the diagram, but it is there :) Configuration looks pretty standard. In fact, all functions have permissions to work with this SQS, but I didn't check the code what is done with the queue. 

DynamoDB is created in provisioned capacity mode, with no backups configuration.

IAM policies are very nicely prepared. Configuration is narrowed as much as possible, permissions and resources are limited to what is needed. I really like it.

S3 looks pretty standard, with one exception. I'd prefer to see `block all public access` set to enabled.

# Final action

On the end of my playground I deleted the stack. The proces is quick (definitely faster than compilation and deployment), and all resources were removed as expected.

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

Finally, I cleared Pulumi, to remove history and associated configuration data.

```bash
pulumi stack rm klothofirstrun
```

It is time for the summary of my basic experience with Klotho.