Fork me on GitHub
#aws
<
2019-12-01
>
cfleming23:12:58

Hi everyone, I’m running some CLJS in AWS Lambda, and I’m keen to automate my deployment using either serverless or AWS SAM. I’ve spent some time looking at them, and they both seem to have problems. My current attempt is using serverless, cljs-lambda (which I was already using) and serverless-cljs-plugin. This seems to work ok, except that serverless-cljs-plugin isn’t invoked when using serverless offline.

cfleming23:12:47

I’ve tried to patch the plugin to make that happen but I can’t make it work, and there’s very little support available for serverless. Their forums and slack channel are very quiet.

cfleming23:12:29

So I looked at AWS SAM, but from what I can tell, sam build is totally non-extensible, so I can’t even figure out how to make it compile CLJS before packaging.

cfleming23:12:43

Has anyone done anything similar and could share some ideas?

steveb8n00:12:48

I’m doing this right now. I’m using the new clj-cdk lib which makes it really easy to upload a shadow-cljs zip as part of a generated cloudformation template. really nice experience

steveb8n00:12:03

happy to talk you through it if you want

steveb8n00:12:24

TLDR; it creates an API gateway with a Lambda proxy automatically attached with all the necessary perms etc. In my case they are deployed into a Datomic VPC as well but maybe you don’t need that

steveb8n00:12:08

I can run this locally using node, no need for SAM

steveb8n00:12:58

I haven’t done CI yet but the sdk CLI “works on my machine” so should go well in a docker container

cfleming00:12:18

@ Thanks, that’s very interesting, I hadn’t heard of CDK. I’ll read up on that and let you know if I have questions.

steveb8n00:12:05

the conj video is a quick way to pick it up

cfleming00:12:17

Ohhh… this is the one with the funky imports

steveb8n00:12:25

yes, that’s the one 🙂

cfleming00:12:41

Haha, your chance of getting support added to Cursive just went way up 🙂

steveb8n00:12:09

there’s a few rough edges but works really well. I owe them a blog post once I get it fully working but, for now, I’m happy to help a fellow Kiwi

cfleming00:12:37

Ok, let me do some reading/watching and playing around, I’ll let you know if I have questions.

jsyrjala05:12:46

Here is a leiningen template I made for creating clojure lambdas with http://serverless.com. You are using clojurescript but it might be helpful anyways: https://github.com/jsyrjala/aws-lambda-serverless with this: https://www.npmjs.com/package/serverless-scriptable-plugin

valtteri06:12:01

clj-sdk looks really cool! However here’s yet another (minimal but simple) example how to use shadow-cljs with Serverless Framework https://github.com/vharmain/serverless-healthcheck

valtteri06:12:14

Basically npm run deploy boils down to just npx shadow-cljs release :lib && npx serverless deploy

viesti07:12:43

I've previously used Terraform to deploy Lambdas, it also has a nice support for uploading the code as zip artifact, based of sha of the file

viesti07:12:52

and you can do other necessary infrastructure configuration with Terraform too (Intelli Idea has nice Terraform support)

viesti07:12:31

of course it depends on how one wants to do things, Terraform is a broad avenue to other IaC too, which might be more than just serverless thing, but comes handy if you end up configuring other infrastructure too :)

lloydshark10:12:02

Hi Colin, This was our experience (from a couple of years ago so things may have changed). Here's a super short summary. We used SAM. We kept our lambda build separate and published direct to S3 using standard clojurescript build tooling. We produced a separate build artefact for the SAM artefacts also published to a well defined S3 location. For the SAM template we parameterised the lambda location in S3 (based on the version number). So then for deployment we wrote some simple scripts to call cloud formation directly and reference the SAM template and the lambdas we had previously published to S3. We were in quite corporate environment so this gave us a good way to control / separate the build, deployment and promotion between environments. This system worked pretty well for us as the pieces were pretty simple. Main drawbacks with SAM was the fact that it is cloudformation so you suffer the normal issue which is needing to split up your stacks to avoid problems if you need to destroy one. ie If your critical data stores are also wrapped up in the same stack then you could be in for some trouble. This might be a lot more than you were after - but hey maybe some of this is of use depending on your context.

lloydshark10:12:28

Tooling for SAM / Cloudformation authoring was also a bit of an issue.

mj_langford20:12:22

@ that's a fascinating stack. Thanks for sharing, and please share with the channel the blog article if you have time to after you write it

cfleming23:12:51

Thanks for the replies everyone, I’ll read through all that. There are tons of different approaches here, and it’s hard to figure out the pros and cons without trying them all.