Dissecting Serverless Stacks (III)

Dissecting Serverless Stacks (III)

The third post of this series showed how to make IAM statements an external file, so we can deploy that one but still work with the sls command. It still involved commenting out things in the configuration, so this post will show how to solve that issue.

When we are thinking about writing a Serverless project which can be deployed “all-in-one” or in some two-step process, we are basically discussion an “if/then/else” scenario. If we use the sls deploy command normally, it should work like any other SLS project. But if we add some option, it should react differently (like skipping the external IAM stack). On a first glance, SLS does not offer such a mechanic. But let’s see how we can make it work nonetheless

Command line options

You can define your own command line switches, which are called “options” in the Serverless Framework. These switches can then be referenced via a $(opt:name) statement:

  deployment_option: $(opt:deployment, 'standard')

If we include this block in our serverless.yml file, we define a command line option and its standard value. So basically this could be sls deploy or sls deploy --deployment standard. Or we could supply a different value. During the previous blog post of this series, we also learned that we can use references like $(custom.deployment_option) in our file to reference parts of the file.

So how can we implement different cases? The answer lies in something which can be considered a mapping and then a “double-reference”:

  deployment_option: $(opt:deployment, 'standard')
    standard: $(file:iam.yaml)
    no_includes: ""
# ... other parts of the file ...

  - ${self:custom.imports.${self:custom.deployment_option}}
  - Description: ${self:functions.fancy.description}

This looks confusing at first, so let us have a closer look:

  • When we supply no --deployment option, the $(custom.deployment_option) reference will be standard. In that case, our reference will equal ${self.custom.imports.standard) and the content of this is the content of $(file:iam.yaml) - so our IAM stack.

  • But if we pass --deployment no_includes instead, the reference will equal ${self.custom.imports.no_includes}, which is just an empty string. While sls deploy will throw a warning about that, it will still result in the IAM stack not being included.

So in short: with sls deploy we have the IAM stack included, with sls deploy --deployment no_includes we will not have it included.

Similar Posts You Might Enjoy

Dissecting Serverless Stacks (IV)

Dissecting Serverless Stacks (IV) After we figured out how to implement a sls command line option to switch between the usual behaviour and a way to conditionally omit IAM in our deployments, we will get deeper into it and build a small hack on how we could hand over all artefacts of our project to somebody who does not even know SLS at all. - by Thomas Heinen

Dissecting Serverless Stacks (II)

Dissecting Serverless Stacks (II) With the output of the last post of this series, we established the base to be able to deliver a Serverless application independent of its needed IAM privileges. So let’s see how this will work out. - by Thomas Heinen

Dissecting Serverless Stacks (I)

Dissecting Serverless Stacks (I) This post establishes the base for a small series on how to create Serverless based Lambdas which can be deployed in environments without IAM privileges or where the sls command cannot be used at all. - by Thomas Heinen