Amazon Web Services API gateway and Lambda are great tools for building and deploying "serverless" applications. But using them to deploy more than a couple functions/endpoints involves an excessive amount of manual work such as zipping files, uploading via the web UI, configuring paths and function names, etc. Shep is built to automate as many of these tasks as possible, giving you the ability to deploy an entire API and suite of lambda functions with one CLI command.
It will be helpful to have some existing experience with API gateway and Lambda. If you have never used either of these tools before, it is recommended to setup a function manually to see how things are done. Please refer to Amazon's own getting started guide
Shep will require your amazon credentials and will load them using the same methods as the AWS CLI tool meaning you must have setup the AWS CLI tool before using shep. Consult Amazon's CLI documentation for instructions.
Shep stores build artifacts on S3 so it can skip the upload step when your functions don't change. By default, Lambda won't update the version of an alias unless the function has changed - so this will come into effect for deploys of config changes. This isn't enabled by default, to enable it add the name of the S3 bucket to the "bucket" field in the shep version of your package.json.
npm install -g shep
// Optionally install shep in your project. The global shep will run the project's shep
npm install --save-dev shepAdd a few lines to your package.json. Your account id can be found on the billing page of your aws account.
{
"name": "my-great-package",
"shep": {
"accountId": "XXXXX",
"region": "us-east-1",
"bucket": "my-great-bucket", // optional upload builds to s3 instead of directly to lambda
"dist": "dist" // optional, customize the dist folder location
}
}Environments for a shep project are defined by the aliases on the functions associated with a project. Environments are created through shep deploy --env new_env and managed by using the shep config commands. Shep takes a strong stance against having different environments for different functions within a project. If you attempt a command which requires the listing of environments and there is a mismatch detected, then shep will throw a EnvironmentMistmach error until you remedy the issue. Most issues can be automatically fixed by using shep config sync, the only issues this can't solve are conflicting environment variable values. Conflicting value issues can be solved by using shep config set my_env CONFLICT_VARIABLE=value.
By default shep builds all your functions using webpack. If your project requires a different build process, then edit your package.json. Before running your build command, shep populates the PATTERN environment variable which can be accessed as process.env.PATTERN in your build command. Be aware that using your own build process will break pattern matching for shep build unless your build command respects the PATTERN variable.
{
"shep": {
"buildCommand": "custom-build --with-flag"
}
}Since Shep uses the same credentials as the AWS CLI, all you need to do is configure the cli. This can be accomplished via aws configure.
Run shep new my-project
This will create and configure a Shep project called 'my-project' in the my-project directory. Change into this directory.
Run shep generate endpoint /hello and follow the prompts.
This creates a new endpoint as well as a new function for that endpoint. Specifically, it adds a path to api.json that is configured to trigger the newly created function.
Run shep deploy --env development
This command does a couple things in order to deploy your project:
- Uses webpack to build your functions. This is equivalent to running
shep build. - Creates or updates the Lambda functions associated with your project. This includes creating a new version of the function as well as updating the alias such that
developmentwill point to the version you just created. For more on versioning please consult Amazon's own documentation. - Creates or updates the API Gateway associated with your project and deploys it to the specified stage,
developmentin this case.
You can test your endpoint by visiting the API URL printed out after the project is deployed. Visiting the /hello endpoint which should show success!.
CLI documentation can be found in DOCS.md
Read the migration docs for information on upgrading major version changes
It was called 'shepherd' at first because it was helpful for dealing with lambda but everyone kept shortening it to 'shep' so we changed the name
Serverless Apex Gordon DEEP Claudia.js
Pull requests welcome!
Test: npm test
Rebuild on file change: npm run compile -- -w
Publish: npm run pub "publish" is reserved by npm