GitHub Action for deploying Serverless (Lambda)

[tafelnl]

Hi there!

First of all, thanks a lot for the effort you put into the Serverless community.

I was wondering what GitHub Action you use for deploying a serverless application. Specifically I am interested in a Lambda one. But any help is welcome really.

[neverendingqs]

Hmm I'm not sure what stage you're at, but I recommend focusing on deployment first vs. the CI/CD system.

If this is your first time playing with AWS Lambda, I recommend checking out the Serverless Framework. The Serverless Framework takes care of everything you need to deploy Lambda functions (packaging, etc) while giving you the flexibility to add other AWS resources via CloudFormation syntax. It is Node-focused (serverless is written in Node.js), but can also deploy functions of other languages. I recommend Node.js though if you know it.

They also have a handy comparison page that shows what other options are out there. My personal preference after the Serverless Framework (although I am not very experienced with it) is Terraform, because you can use it to give you a report of what is in your environment (terraform plan) before you apply those changes.

Any of these tools should have a one-liner for deploying your Lambda function(s) (e.g. serverless deploy), which makes it easy to use in a workflow. E.g.

on:
  push:
    branches:
      - main

jobs:
  build-deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '14'
      # Could also consider https://github.com/serverless/github-action
      - run: npm i -g serverless
      - run: serverless deploy

[tafelnl]

Thanks a lot for the elaborate answer.

I actually have played with serverless quite a bit and even use it in production already. I have setup a (simple) boilerplate here: https://github.com/DutchConcepts/serverless-boilerplate

The only thing I am missing is a good GitHub Action to deploy the application to AWS with all the environment variables etc.

Right now I have this:

name: Deploy Something to Production

env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
  AWS_DEFAULT_REGION: eu-central-1

on:
  release:
    types: [published]

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v1
        with:
          node-version: '12.x'
      - name: Make envfile
        uses: SpicyPizza/create-envfile@v1
        with:
          envkey_FOOBAR: ${{secrets..FOOBAR}}
          file_name: .env
      - name: Install NPM dependencies
        run: npm install
      - name: Install Serverless Framework
        run: npm install -g serverless
      - name: Serverless AWS authentication
        run: sls config credentials --provider aws --key ${{ secrets.AWS_ACCESS_KEY_ID }} --secret ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      - name: Deploy to Development Environment
        run: sls deploy --stage=prod

It gets the variables from the built-in secrets manager in GitHub. It gets triggered on creating a release.

It works, but I feel like this is not the best way. But I am not very experienced with this kind of stuff.

[tafelnl]

So I guess the real question would be: How does one handle environment variables in a GitHub Action for Serverless Lambda deployment

[neverendingqs]

Unfortunately, you have to declare every secret you want to use. This is to adhere to the principle of least privilege within a GitHub action workflow. Otherwise, a malicious action can read secrets its not allowed to. In your example above, I would only make your AWS env vars available in the Serverless AWS authentication step by removing the top level env property. Aside from that, your GitHub workflow looks good to me.

Alternatively, you can declare your secrets in AWS Secrets Manager, and have your Lambda function pull values from there on startup.

If you have environment variables that are not secrets, you can store them in your repository directly. Each stage can have its own file, and you can use --stage to decide which file to read from. E.g. the neverendingqs/serverless-dotenv-example here, but with the following configs.js file:

const dotenv = require('dotenv');

module.exports = async ({ options, resolveConfigurationProperty }) => {
  // If `--stage=prod`, looks for `.env.prod`
  const stageVars = dotenv.config({ path: `.env.${options.stage}` });
  // If found, return them
  if(!stageVars.error) {
    return stageVars.parsed;
  }

  // If not found, use `.env` (fails silently if `.env` is not found)
  const envVars = dotenv.config({ path: '.env' }).parsed;
  return envVars;
};