The Overview walked through a simple “Hello World” example. In this section we’ll cover how Sparta works in preparation for moving on to more advanced usages. Most development will use the
provision command line argument, so this section will outline exactly what that entails.
The provisioning workflow is defined in provision.go, with a singular goal of encapsulating all AWS mutations into a CloudFormation template. Where CloudFormation does not support a given service, Sparta injects Lambda-backed Custom Resources into the template definition.
At a high level, provisioning uses the flow below. We’ll dive a bit deeper into each stage in the following sections.
NewLambda function accepts either a
string or a
sparta.IAMRoleDefinition value type. In the event that a string is passed, this function verifies that the IAM role exists and builds up a cache of IAM role information that can be shared and referenced during template generation. Specifically, a pre-existing IAM Role ARN is cached to minimize AWS calls during template generation.
The next step is to cross compile the application to a binary that can be executed on an AWS Lambda instance. The compile flags are:
The binary is built in the current directory with a .lambda.amd64 suffix.
The end result of the package phase is a ZIP archive containing everything needed to deploy your service.
This includes the NodeJS proxy entries that forward AWS Lambda requests to your Go binary HTTP-based handler. The packaging step also includes NodeJS code to support CloudFormation custom resources for services such as
API Gateway configuration and S3 push source configuration. Finally, a known version of the AWS SDK is included (that’s the node-modules copying you’ll see if you enable
debug verbosity) that’s likely newer than the one included in the AWS Lambda runtime.
Over time it’s expected that CloudFormation grows to support additional services and capabilities, at which point much of the NodeJS code can be eliminated.
Everything is ZIP’d up and ready for S3 upload.
Uploads the archive to S3. There’s not much else to see here.
Once the archive is uploaded and the S3 Item key is available, the CloudFormation template is generated by marshaling the
sparta.LambdaAWSInfo objects into CloudFormation JSON representations.
The AWS Lambda marshaling is automatically handled. This is also the point at which the optional TemplateDecorator functions are called to annotate the automatically generated template with additional resources.
Uploads the template to S3 to maximize template size. There’s not much else to see here.
Finally, the provisioning workflow determines whether the Sparta
serviceName exists and either creates or updates as appropriate.
Now that we’ve covered how Sparta handles provisioning your stack, we’re ready to expand functionality to leverge more of the AWS ecosystem in the next section.