Configuring a CI/CD Pipeline with CloudBees CodeShip and the Epsagon Serverless Monitoring Tool

Editor’s Note: This is a guest tutorial blog post contributed by Gal Bashan, software engineer at Epsagon.

Continuous delivery is an essential part of building a successful product. Being able to ship quickly and with confidence becomes an important edge for companies from all industries.

When we think of continuous delivery, we consider several stages along the development pipeline including:

• Continuous Integration (CI)

• Continuous Delivery (CD)

• Continuous Monitoring (CM)

When using a serverless architecture (which is often a highly-distributed microservices architecture), the first and second stages become easier. Each deployed component is smaller, which makes integration (via unit/system tests) simpler. Also, as services tend to be loosely coupled, we can deploy services more frequently. However, one of the big challenges of running a serverless architecture is the monitoring stage.

Monitoring has always been an integral part of product development. We use it to make sure our product is functional, fix errors when they occur and optimize our system. In serverless monitoring, it becomes even more important as most services’ pricing model is pay-per-use. In serverless, time (and API calls) is money.

Serverless systems have several key differences from traditional monolithic systems which makes them harder to monitor:

• Highly distributed. A serverless application is usually composed of many small services, which communicate via asynchronous channels. This poses a real problem for root-cause-analysis of errors, performance optimization (both user experience and cost) and system observability (a.k.a “seeing the big picture”).

• Lack of infrastructure control. While not having to manage servers is absolutely delightful, it can also become a challenge. Traditional monitoring agents and tools don’t fit the serverless environment - there are simply no servers to deploy them on!

• Environment restrictions. Serverless environments have new restrictions: timeouts, low memory limits and cold starts. This means our serverless applications must be monitored for new types of possible failures.

In the CI/CD/CM world, integrating CloudBees CodeShip’s CI/CD platform with Epsagon’s serverless monitoring platform enables developers to set up a CI/CD/CM pipeline for building a serverless application. In this tutorial, we will use CodeShip’s GitHub SCM Integration to trigger a build and deploy our application to production. We will then use Epsagon’s dashboard to monitor failures in the production environment.

For this tutorial, we will use a simple example service and for our deployment tool, we will use the Serverless Framework, a popular framework for deploying serverless services. Epsagon also integrates seamlessly with the Serverless Framework to enable tracing to your functions with no code change whatsoever!

First, clone the repository and configure CodeShip to connect to your GitHub repository.

Then, select your project type. Since this example is pretty small, we will use Codeship Basic.

Next, we will configure our setup commands. First, we set the node version to 8.10 using nvm install 8.10. Then, since Epsagon integrates with the serverless framework, our setup commands are as simple as npm install.

Finally, we configure our test command (npm run test) and our deploy commands (installing the Serverless Framework and deploying) to deploy on a merge to the controller branch.

And our CI/CD is ready! Now let's add Epsagon to our service, and deploy by merging the code change to the controller branch. First, install Epsagon’s library and the Serverless Framework:

npm install epsagon --save

Then, add Epsagon’s serverless plugin to automatically enable tracing for all of your functions: serverless plugin install --name serverless-plugin-epsagon

Now, configure the plugin with your Epsagon token, which you can find on the settings page in the dashboard.

To configure the plugin, simply add the token to the custom section of your serverless.yml:

 custom:
  epsagon:
    token: <your token here>
    appName: epsagon-codeship-example-${self:provider.stage}

And that’s it! You can also add an optional appName to separate between different applications. We will add the stage to our appName to distinguish between different deploy stages. Now let’s push our code. The change in the controller branch should trigger a build and deployment to production.

Success! Our CI/CD is set up, and in fact, our CM is set up as well. Next, we will see how to use Epsagon to monitor our system.

For our example, we will use a simple application, which has an API gateway interface that reads arguments via the query string of the request. Let’s trigger it and use Epsagon to visualize and understand our architecture.

We can see that our architecture is composed of two Lambda functions, communicating via an SNS asynchronous channel. Let’s dive into the execution of our application, via the transactions view.

There is only one transaction in our architecture so let’s check the execution detail. We can see any detail on any resource that was involved in this transaction, from the CloudWatch log of the Lambda to the actual item that was stored in the DynamoDB.

Epsagon has an alerting system which provides monitoring out-of-the-box. Using Epsagon’s custom alerts, you can easily create alerts on different components in your system, configure events which will trigger an alert, and choose your preferred channel to receive the alert in. By default, alerting Is enabled on any errors, timeouts or out of memory your functions may experience.

Next, we will see an example of an error root cause analysis we can perform using Epsagon’s system. First, we receive an alert email from Epsagon.

Clicking on the “explore” link will lead us directly to the transaction on which the error occurred.

The error is that we are missing the RecordId primary key on the DynamoDB PutItem operation. But our second Lambda is very simple. It inserts to the DynamoDB whatever was received from the SNS! Lucky, we can also see the data that was sent via the SNS:

We can see that the RecordId field is missing In the data. Our first Lambda is also quite simple - It reads the query string of the HTTP request from the API gateway. We can also see the exact HTTP request to further understand the source of the problem:

Now the problem is clear: our application received a request without the RequestId field, and no verification that the field exists was done along the way! We were able to find get to the bottom of the issue quickly and effectively. Great success!

Monitoring is an integral part of developing a serverless product. While serverless environments can be hard to monitor, with the right tooling you can make monitoring a piece of cake. Using the CloudBees CodeShip CI/CD platform and Epsagon’s monitoring tool, developers can build a simple and reliable deployment pipeline. You can automate the integration, deployment, and monitoring of your serverless applications and get back to focusing on what really matters.

• How event notifications work with CloudWatch using AWS Lambda

• Read more about secure serverless CI/CD

• Learn about your options for function as a service