Mocking Local Deploys and other experiments

[solar walrus]

Quoting my inquiry from the general channel!

Hey y'all! We use serverless framework to deploy our projects. I'm curious if anyone's been able to build projects using serverless framework with dagger.

Second half

We use serverless framework to deploy all our infra. I'm doing some experimentation at the moment. I am hoping to see if I can make something that does mock deploys. Looking to avoid permission and validation errors in our CI by running local mock deploys.

Some more context:
We use serverless framework to build out all our infra. We deploy using GitHub actions on a merge to production. This GH Action then sends our code over to AWS Codebuild to set up everything.

[kindred frost]

👋 . Ok, what are you trying to achieve? How do you think Dagger can be useful?

trying to understand what's in your head when you refer to "mock local deploys"

[solar walrus]

Makes total sense. So, the specific use case I'm wondering about is this:

We deploy using serverless framework (https://www.serverless.com/) to build out and deploy our infra. We merge to prod, GitHub actions pick up the project, which sends it over to AWS Codebuild, which deploys everything into AWS.

More often than I would like, we run into CI issues that cause the deploys to fail. Missing permissions for the AWS role doing the deployment. Issues with CloudFormation validation. And plenty more. So I'm experimenting with the ability to run a "mock deploy" where we start up a local docker container and build the entire project (api stack, data stack, etc) locally and test for any failures. Someday, I'd like to see that as part of the automated testing steps.

Does all that make sense?

[kindred frost]

Yes that makes sense. Dagger can definitely help here. I have to leave now but let's keep chatting more tomorrow about how this would look like

[solar walrus]

I’ll be paying attention tomorrow as well. Any help would be great. Thanks a ton in advanced!

[solar walrus]

@kindred frost good morning. Was curious if you had any more thoughts on this. Not at all an urgent thing. Just asking. I'm trying to get more into the dagger docs to see if I can understand it a bit more to try and achieve what I'm talking about.

[kindred frost]

hey @solar walrus I got sick this week so haven't had much time to get back into this. Will take a look today 🙌

[solar walrus]

Ah that sucks. Sorry to hear that. Don't rush on my behalf lol. I appreciate anything that you can do to help but there is def no rush!

This is a side project I'm trying to work on for downtime at work.

[strong pike]

Copying @ebon juniper who did a lot of AWS+Dagger - thought you might be interested in this one 🙂

[kindred frost]

More often than I would like, we run into CI issues that cause the deploys to fail. Missing permissions for the AWS role doing the deployment. Issues with CloudFormation validation. And plenty more. So I'm experimenting with the ability to run a "mock deploy" where we start up a local docker container and build the entire project (api stack, data stack, etc) locally and test for any failures. Someday, I'd like to see that as part of the automated testing steps.

hey @solar walrus I was thinking more about this today and wanted to ask you more about the above parragraph particularly.

Seems like the biggest paint points you have today is mostly around vendor (AWS) specific configurations IIUC. I'm trying to visualize how running a "mock deploy" is something that could help you and your team minimize these vendor specific dependencies since the mocking part happens locally in your team's machine instead of in the cloud

do your teams currently have a way to start the stack locally to test things? or they mostly go by the "push and pray" approach given that lifting the whole stack locally currently seems inviable?

[solar walrus]

Hey @kindred frost usually we end up deploying to a staging environment in aws. We use serverless framework for that and the times that we do boot up something locally we use a plugin for serverless framework called serverless offline. https://www.serverless.com/plugins/serverless-offline

This is usually due to needing to call other services to test whatever it is we're doing and it just being easier to do it within aws

And yeah our bu=iggest pain point in so far as CI/CD are concerned is that we run into issues with configuration and issues with AWS resource permissions.

[kindred frost]

gotcha, when you're saying this:

So I'm experimenting with the ability to run a "mock deploy" where we start up a local docker container and build the entire project (api stack, data stack, etc) locally and test for any failures. Someday, I'd like to see that as part of the automated testing steps.

does that include the serverless offline thing? Or this is a new approach you're trying? How do you think this mock deploy can help to reduce this AWS specific config errors and how do you envision Dagger helping there?

Asking all these questions to make sure that:

1. Dagger is effectively a good tool to help here
2. We're not over engineering something that might be solved better differently

[solar walrus]

All makes sense

[solar walrus]

This is more of a new approach. Serverless offline is what we use to try things locally. However, it is not involved in deployments. The core serverless library is what we use to deploy. We run a bash script that sets all the needed env vars and then use the serverless deploy command

[kindred frost]

instead of using serverless offline have you explored the idea of using something like local stack to make the local development workflow a bit more similar to your stag / prod environments?

I'm thinking that it might be interesting to explore lifting localstack with dagger and then configuration your application so the same serverless deploy can work both locally and in your stag/prod envs.

[solar walrus]

Sounds like an interesting idea. Does the localstack include some kind of aws environment?

[kindred frost]

yep, exactly

they're an AWS API compatible environment

you could use Dagger to "lift" this localstack environment and orchestrate all the pipeline to build and serverless deploy your app against it

looks like a fun idea to try

we're even using localstack ourselves in Dagger to run some lambda / event bridge integration testing

https://www.serverless.com/plugins/serverless-localstack

well.. seems like serverless supports as a plugin... so you might not even need to use Dagger for that

we're not using the serverless.com framework oursleves, that's why we have a Dagger pipline that takes care of the localstack provisioning

[solar walrus]

That does look interesting. I've never used localstack. So would I have to have an instance of localstack running?

[kindred frost]

yes, but looks like the serverless-localstack plugin takes care of all the heavylifting for you

[solar walrus]

This does seem to require localstack to be running. So yeah I could probably use dagger to run something like that.

[kindred frost]

ok, great. In that case yes, dagger would be an awesome fit there

happy to help you out getting started if you need some guidance 🙌

[solar walrus]

Totally. I appreciate the help. I think I'm gonna take some time tomorrow to start hacking away at a solution. I'll probably start with setting up a local dagger solution for local stack. If it's easy enough to get started then I can probably look more into the local stack serverless plugin

[kindred frost]

sounds great! In that case, happy hacking and we're around if you need us!