Configuration doesn't stick in AWS

[johncurrier]

Up front: thanks for creating this project. It's exactly what's needed for starting a well-structured, enterprise-level Lambda. Kudos for doing this.

Some of the configuration files, however, have me confused.

Copying .env.example to .env and making changes to it (change ENVIRONMENT to develop and MESSAGE_QUEUE_URL to my queue in AWS) seems to work when running locally. When I deploy that to AWS, however, MESSAGE_QUEUE_URL gets set to [myId]/serverless-express-typescript-sqs-develop-MessagesQueue-[someGUID}, which gets created for me. I'm not sure how to fix that other than changing that env var after the lambda gets created.

I would have expected multiple .env files to be available and switch between them depending on what I wanted to deploy, but I don't think that that's going on here. Maybe it is? It seems like we have to configure that file, then deploy with a command that matches the environment specified in .env. I'm thinking that I'm missing something here.

secrets.yml doesn't seem to be the place to store secrets, right? It seems to be a mapping of environment names. That's confusing.

Typos in your readme:

• secrects should be secrets
• there's a trailing \s on one of your aws lambda invoke lines

Also note that your region is hardcoded in serverless.yml.

Thanks again for creating this. Awesome work that's helped dramatically.

[Teppichseite]

Hey @johncurrier, thank you very much for your comment.
The .env file is only for local development. So there you can store all your secrets you need for your local development.
In the secrets.yaml file you have to store secrets which are the real secrets for your remote environments on AWS.
Each section in this file reprents a different environment/stage you want to deploy for. ENVIRONMENT was just an example here.
Note that you should store them only temporarily in this file.

For example you could create the secrects.yml like this:

1. Create the secrets.yml file and fill in all the secrets you need
2. Store this file in a safe place (e.g. GitLab Protected Variables Storage)
3. When you deploy your project via a Container (e.g. GitLab Pipelines), pull that file from the secret storage on and store it in the deployment container by creating the secrets file

If you deploy to AWS directly from your machine, you have to create the secrets.yaml file by hand.

About the Message Queue Env Variable: The idea of this Serverless configuration is that the Serverless file will create the full stack for you.
So it will also create a new SQS Queue and will set the url env variable for this new queue automatically.
If you want to use an already existing SQS Queue you probably have to reference it under the resources section in the serverless.yml file.

Thank you also for the hints about the small errors. We will fix them as soon as possible.

Was this comment helpful to you?