Today we’ll take a look at how to deploy a Lambda function to AWS with Clarive 7.1.
In this example there is also some interesting ideas that you can implement in your .clarive.yml
files to manage your application deployments, such as variables that can be parsed by Clarive.
Setup
Add the following items to your Clarive instance:
- A Slack Incoming Webhook pointing to your Slack account defined webhook URL (check https://api.slack.com/incoming-webhooks)
- 2 variables with your aws credentials :
aws_key
(type: text) andaws_secret
(type: secret)
Slack is actually not mandatory to run this example, so you can just skip it. You can also just hardcode variables into the .clarive.yml
file but you would be missing some of Clarive’s nicest features: variable management 😉
Create your 2 AWS variables in Clarive
Head over to the Admin Variables menu to setup the aws_key
and aws_secret
variables:
As the variable type field indicates, secret variables are encrypted into the Clarive database.
.clarive
directory contents
As you can see in the following .clarive.yml
file, we’ll be using a rulebook operation to parse the contents of a file:
- aws_vars = parse:
file: "{{ ctx.job('project') }}/{{ ctx.job('repository') }}/.clarive/vars.yml"
In this case we’ll load a file called vars.yml
from the .clarive
directory in your repository and the variables will be available in the aws_vars
structure for later use, i.e. {{ aws_vars.region }}
.
If you have a look at that directory, there is one vars.yml
for each environment. Clarive will use the correct file depending on the target environment of the deployment job.
The .clarive.yml
file
The .clarive.yml
file in your project’s repository is used to define the pipeline rule that will execute during CI/CD, building and deploying your Lambda function to AWS.
This pipeline rule will:
- replace variables in the Serverless repository files with contents stored in Clarive
- run the
serverless
command to build and deploy your Lambda function - notify users in a Slack channel with info from the version and branch being built/deployed
Slack plugin operation in use
For posting updates of our rule execution to your Slack chat, we’ll use the slack_post
operation available in our slack plugin here. With Clarive’s templating features we’ll be able to generate a more self-descriptive Slack message (also called a payload):
text =: |
Version:
{{ ctx.job('change_version') }}
Branch:
{{ ctx.job('branch') }}
User:
{{ ctx.job('user') }}
Items modified:
{{ ctx.job('items').map(function(item){ return '- (' + `${item.status}` + ') ' + `${item.item}`}).join('\n') }}
- slack_post:
webhook: SlackIncomingWebhook-1
payload:
attachments:
- title: "Starting deployment {{ ctx.job('name') }} for project {{ ctx.job('project') }}"
text: "{{ text }}"
mrkdwn_in: ["text"]You can play around with it to experiment with different formats and adding or removing contents to the payload at will.
Replacing variables in your source code
We use the sed
operation in the build step:
- sed [Replace variables]:
path: "{{ ctx.job('project') }}/{{ ctx.job('repository') }}"
excludes:
- \.clarive
- \.git
- \.serverless
This will parse all files in the specified path:
and replace all {{}}
and ${}
variables found. You can find a couple of examples in the handler.js
file in the repository.
Docker image
Our rule uses an image from https://hub.docker.com that has the Serverless framework already installed:
- image:
name: laardee/serverless
environment:
AWS_ACCESS_KEY_ID: "{{ ctx.var('aws_key') }}"
AWS_SECRET_ACCESS_KEY: "{{ ctx.var('aws_secret') }}"
See that we set the environment variables needed for the Serverless commands to point to the correct AWS account.
Operation decorators
Some of the operations you can find in the sample .clarive.yml
file are using decorators such as: [Test deployed application]
.
Decorators are used in the job log inside Clarive instead of the name of the operation. It makes it easier for the user to read the job log if operations have textual information describing what it is doing. This is specially true with longer pipelines and complex rules.
You can actually also use variables in decorators to make them more intuitive for the user!
The full .clarive.yml
file is available on our Github instance:
https://github.com/clarive/example-app-serverless/blob/master/.clarive.yml
Building and deploying your Serverless app
- First, use this Github repository cloned into a new or an existing project (i.e project: serverless, repository: serverless)
Clone the new clarive repository from your git client:
git clone http[s]://<your_clarive_instance_URL>/git/serverless/serverless
Create a new topic branch. Here we’ll be tying our branch to a User Story in Clarive:
cd serverless
git branch -b story/to_github
Now commit and push some changes to the remote repository and go to Clarive monitor. It should have created a new user story topic for you and automatically launched the CI build:
From here forward, you can start the build and deploy lifecycle, including deploying to other environments (ie. Production or QA) and other deployment workflow. Just setup different variable values for each environment, so that the CI/CD pipeline will deploy to the corresponding environment when the time comes.
Enjoy!!!
Get an early start and try Clarive now. Get your custom cloud instance for free.
Originally published at clarive.com on January 9, 2018.