github.com/mweagle/Sparta@v1.15.0/docs_source/content/example_service/step2.md (about) 1 --- 2 date: 2016-03-09T19:56:50+01:00 3 title: Details 4 weight: 20 5 --- 6 7 The [Overview](/sample_service/step1/) walked through a simple "Hello World" example. In this section we'll cover how Sparta works in preparation for moving on to more advanced use. Most development will use the `provision` command line argument, so this section will outline exactly what that entails. 8 9 # Provisioning Flow 10 11 The provisioning workflow is defined in [provision.go](https://github.com/mweagle/Sparta/blob/master/provision.go), with a goal of marshalling all AWS operations into a [CloudFormation](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) template. Where CloudFormation does not support a given service, Sparta falls back to using [Lambda-backed Custom Resources](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources-lambda.html) in the template definition. 12 13 At a high level, provisioning uses the flow below. We'll dive a bit deeper into each stage in the following sections. 14 15 {{< spartaflow >}} 16 17 ## Verify Static IAM Roles 18 19 The `NewAWSLambda` 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](http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) is cached to minimize AWS calls during template generation. 20 21 ## Compile 22 23 The next step is to cross compile the application to a binary that can be executed on an AWS Lambda instance. The default compile flags are: 24 25 * **TAGS**: `-tags lambdabinary` 26 * **ENVIRONMENT**: `GOOS=linux GOARCH=amd64` 27 28 The build output is created in the _./.sparta/ working directory. The full set of build flags is available by running the provision workflow with the `--level debug` option. 29 30 ## Package 31 32 The end result of the package phase is a ZIP archive of your application. You can inspect this archive, as well as any other Sparta artifacts in the _./.sparta_ directory by supplying the `--noop` argument during a provision operation. 33 34 ## Upload Archive To S3 35 36 Uploads the archive to S3. There's not much else to see here. 37 38 ## Generate CloudFormation Template 39 40 Uploading the archive produces a valid [CodeURI](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html#cfn-lambda-function-code) value that can be used for Lambda function creation. The CloudFormation template is generated by marshaling the `sparta.LambdaAWSInfo` objects into CloudFormation JSON representations. 41 42 The AWS Lambda marshaling is automatically handled. This is also the point at which the optional [TemplateDecorator](https://godoc.org/github.com/mweagle/Sparta#TemplateDecorator) functions are called to annocate the automatically generated template with additional resources. 43 44 ## Upload CloudFormation Template to S3 45 46 Uploads the template to S3 to maximize [template size](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cloudformation-limits.html). There's not much else to see here. 47 48 ## Create/Update Stack 49 50 Finally, the provisioning workflow determines whether the Sparta `serviceName` exists and either creates or updates as appropriate using CloudFormation APIs. 51 52 # Next Steps 53 54 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](/reference/eventsources/).