Tip
To deploy this project using GUI-based flow, navigate to console
- Example Docker container deployed as a web service.
- This project includes a pre-configured stacktape.yml configuration. The configured infrastructure is described in the stack description section
- The infrastructure required for this application uses exclusively "serverless", pay-per-use infrastructure. If your load won't get high, these costs will be close to $0.
-
AWS account. If you don't have one, create new account here.
-
Stacktape account. If you don't have one, create new account here.
-
Stacktape installed.
Install on Windows (Powershell)
iwr https://installs.stacktape.com/windows.ps1 -useb | iexInstall on Linux
curl -L https://installs.stacktape.com/linux.sh | shInstall on MacOS
curl -L https://installs.stacktape.com/macos.sh | shInstall on MacOS ARM (Apple silicon)
curl -L https://installs.stacktape.com/macos-arm.sh | shTo initialize the project, use
stacktape init --starterId tensorflow-image-classification- Install your projects dependencies. The recommended way is to use Virtual environment.
The deployment will take ~5-15 minutes. Subsequent deploys will be significantly faster.
Deploy from local machine
The deployment from local machine will build and deploy the application from your system. This means you also need to have:
- Docker. To install Docker on your system, you can follow this guide.- Python version > 3.9 and Poetry package manager installed.
To perform the deployment, use the following command:
stacktape deploy --stage <<stage>> --region <<region>>stage is an arbitrary name of your environment (for example staging, production or dev-john)
region is the AWS region, where your stack will be deployed to. All the available regions are listed below.
| Region name & Location | code |
|---|---|
| Europe (Ireland) | eu-west-1 |
| Europe (London) | eu-west-2 |
| Europe (Frankfurt) | eu-central-1 |
| Europe (Milan) | eu-south-1 |
| Europe (Paris) | eu-west-3 |
| Europe (Stockholm) | eu-north-1 |
| US East (Ohio) | us-east-2 |
| US East (N. Virginia) | us-east-1 |
| US West (N. California) | us-west-1 |
| US West (Oregon) | us-west-2 |
| Canada (Central) | ca-central-1 |
| Africa (Cape Town) | af-south-1 |
| Asia Pacific (Hong Kong) | ap-east-1 |
| Asia Pacific (Mumbai) | ap-south-1 |
| Asia Pacific (Osaka-Local) | ap-northeast-3 |
| Asia Pacific (Seoul) | ap-northeast-2 |
| Asia Pacific (Singapore) | ap-southeast-1 |
| Asia Pacific (Sydney) | ap-southeast-2 |
| Asia Pacific (Tokyo) | ap-northeast-1 |
| China (Beijing) | cn-north-1 |
| China (Ningxia) | cn-northwest-1 |
| Middle East (Bahrain) | me-south-1 |
| South America (São Paulo) | sa-east-1 |
Deploy using AWS CodeBuild pipeline
Deployment using AWS CodeBuild will build and deploy your application inside AWS CodeBuild pipeline. To perform the deployment, use
stacktape codebuild:deploy --stage <<stage>> --region <<region>>stage is an arbitrary name of your environment (for example staging, production or dev-john)
region is the AWS region, where your stack will be deployed to. All the available regions are listed below.
| Region name & Location | code |
|---|---|
| Europe (Ireland) | eu-west-1 |
| Europe (London) | eu-west-2 |
| Europe (Frankfurt) | eu-central-1 |
| Europe (Milan) | eu-south-1 |
| Europe (Paris) | eu-west-3 |
| Europe (Stockholm) | eu-north-1 |
| US East (Ohio) | us-east-2 |
| US East (N. Virginia) | us-east-1 |
| US West (N. California) | us-west-1 |
| US West (Oregon) | us-west-2 |
| Canada (Central) | ca-central-1 |
| Africa (Cape Town) | af-south-1 |
| Asia Pacific (Hong Kong) | ap-east-1 |
| Asia Pacific (Mumbai) | ap-south-1 |
| Asia Pacific (Osaka-Local) | ap-northeast-3 |
| Asia Pacific (Seoul) | ap-northeast-2 |
| Asia Pacific (Singapore) | ap-southeast-1 |
| Asia Pacific (Sydney) | ap-southeast-2 |
| Asia Pacific (Tokyo) | ap-northeast-1 |
| China (Beijing) | cn-north-1 |
| China (Ningxia) | cn-northwest-1 |
| Middle East (Bahrain) | me-south-1 |
| South America (São Paulo) | sa-east-1 |
Deploy using Github actions CI/CD pipeline
- If you don't have one, create a new repository at https://github.com/new
- Create Github repository secrets: https://docs.stacktape.com/user-guides/ci-cd/#2-create-github-repository-secrets
- Replace
<<stage>>and<<region>>in the .github/workflows/deploy.yml file. git init --initial-branch=maingit add .git commit -m "setup stacktape project"git remote add origin git@github.com:<<namespace-name>>/<<repo-name>>.gitgit push -u origin main- To monitor the deployment progress, navigate to your github project and select the Actions tab
stage is an arbitrary name of your environment (for example staging, production or dev-john)
region is the AWS region, where your stack will be deployed to. All the available regions are listed below.
| Region name & Location | code |
|---|---|
| Europe (Ireland) | eu-west-1 |
| Europe (London) | eu-west-2 |
| Europe (Frankfurt) | eu-central-1 |
| Europe (Milan) | eu-south-1 |
| Europe (Paris) | eu-west-3 |
| Europe (Stockholm) | eu-north-1 |
| US East (Ohio) | us-east-2 |
| US East (N. Virginia) | us-east-1 |
| US West (N. California) | us-west-1 |
| US West (Oregon) | us-west-2 |
| Canada (Central) | ca-central-1 |
| Africa (Cape Town) | af-south-1 |
| Asia Pacific (Hong Kong) | ap-east-1 |
| Asia Pacific (Mumbai) | ap-south-1 |
| Asia Pacific (Osaka-Local) | ap-northeast-3 |
| Asia Pacific (Seoul) | ap-northeast-2 |
| Asia Pacific (Singapore) | ap-southeast-1 |
| Asia Pacific (Sydney) | ap-southeast-2 |
| Asia Pacific (Tokyo) | ap-northeast-1 |
| China (Beijing) | cn-north-1 |
| China (Ningxia) | cn-northwest-1 |
| Middle East (Bahrain) | me-south-1 |
| South America (São Paulo) | sa-east-1 |
Deploy using Gitlab CI pipeline
- If you don't have one, create a new repository at https://gitlab.com/projects/new
- Create Gitlab repository secrets: https://docs.stacktape.com/user-guides/ci-cd/#2-create-gitlab-repository-secrets
- replace
<<stage>>and<<region>>in the .gitlab-ci.yml file. git init --initial-branch=maingit add .git commit -m "setup stacktape project"git remote add origin git@gitlab.com:<<namespace-name>>/<<repo-name>>.gitgit push -u origin mainTo monitor the deployment progress, navigate to your gitlab project and select CI/CD->jobs
stage is an arbitrary name of your environment (for example staging, production or dev-john)
region is the AWS region, where your stack will be deployed to. All the available regions are listed below.
| Region name & Location | code |
|---|---|
| Europe (Ireland) | eu-west-1 |
| Europe (London) | eu-west-2 |
| Europe (Frankfurt) | eu-central-1 |
| Europe (Milan) | eu-south-1 |
| Europe (Paris) | eu-west-3 |
| Europe (Stockholm) | eu-north-1 |
| US East (Ohio) | us-east-2 |
| US East (N. Virginia) | us-east-1 |
| US West (N. California) | us-west-1 |
| US West (Oregon) | us-west-2 |
| Canada (Central) | ca-central-1 |
| Africa (Cape Town) | af-south-1 |
| Asia Pacific (Hong Kong) | ap-east-1 |
| Asia Pacific (Mumbai) | ap-south-1 |
| Asia Pacific (Osaka-Local) | ap-northeast-3 |
| Asia Pacific (Seoul) | ap-northeast-2 |
| Asia Pacific (Singapore) | ap-southeast-1 |
| Asia Pacific (Sydney) | ap-southeast-2 |
| Asia Pacific (Tokyo) | ap-northeast-1 |
| China (Beijing) | cn-north-1 |
| China (Ningxia) | cn-northwest-1 |
| Middle East (Bahrain) | me-south-1 |
| South America (São Paulo) | sa-east-1 |
After a successful deployment, some information about the stack will be printed to the terminal (URLs of the deployed services, links to logs, metrics, etc.).
- Explore your application at app URL. The URL is printed to the terminal.
-
Stacktape deployments use AWS CloudFormation under the hood. It brings a lot of guarantees and convenience, but can be slow for certain use-cases.
-
To speed up the deployment, you can use the
--hotSwapflag that avoids Cloudformation. -
Hotswap deployments work only for source code changes (for lambda function, containers and batch jobs) and for content uploads to buckets.
-
If the update deployment is not hot-swappable, Stacktape will automatically fall back to using a Cloudformation deployment.
stacktape deploy --hotSwap --stage <<stage>> --region <<region>>- If you no longer want to use your stack, you can delete it.
- Stacktape will automatically delete every infrastructure resource and deployment artifact associated with your stack.
stacktape delete --stage <<stage>> --region <<region>>Stacktape uses a simple stacktape.yml configuration file to describe infrastructure resources, packaging, deployment
pipeline and other aspects of your project.
You can deploy your project to multiple environments (stages) - for
example production, staging or dev-john. A stack is a running instance of an project. It consists of your application
code (if any) and the infrastructure resources required to run it.
The configuration for this project is described below.
- Every resource must have an arbitrary, alphanumeric name (A-z0-9).
- Stacktape resources consist of multiple underlying AWS or 3rd party resources.
Buckets offer persistent, scalable storage for any type of object(files).
In this project we use two buckets:
- inputBucket - used for uploading
.zipfile(s) containing pictures that we wish to classify(categorize) - outputBucket - used by apps batch job to output images categorized into classes.
You can configure multiple properties on the bucket. In this case, we are using the default setup.
inputBucket:
type: bucket
outputBucket:
type: bucketThe classifier application runs in a batch job.
The batch job is configured as follows:
- Container section specifies details of our job
container
- Packaging - determines how the Docker container image is built. In this example, we are using our custom
Dockerfilebased of tensorflow image. Stacktape builds the Docker image and pushes it to a pre-created image repository on AWS. You can also use other types of packaging.
- Packaging - determines how the Docker container image is built. In this example, we are using our custom
- ConnectTo list - we are adding buckets
inputBucketandoutputBucketintoconnectTolist. By doing this, Stacktape will automatically setup necessary IAM permissions for the batch job's role as well as inject relevant environment variables into the runtime (such as AWS names of the buckets). - Resources assigned to the job. We are providing the number
of cpus and the amount of memory the job needs. When job is triggered AWS will automatically spin-up an instance with
the required resources on which the job will run. We are also using the
useSpotInstancesproperty, which configures job to use cheaper spot instances. - Access control - Since our job
reads from
inputBucketand writes tooutputBucket, it needs permissions to access these resources. We are granting the permissions by listing them inconnectTolist. To see other ways of controlling access to resources refer to the docs - We are configuring events that trigger the job. In this case, we are triggering the batch job if a
zipfile is uploaded to (created in) theinputBucket.
classifierJob:
type: batch-job
properties:
container:
packaging:
type: custom-dockerfile
properties:
buildContextPath: ./
resources:
cpu: 2
memory: 14000
useSpotInstances: true
connectTo:
- inputBucket
- outputBucket
events:
- type: s3
properties:
bucketArn: $ResourceParam('inputBucket', 'arn')
s3EventType: s3:ObjectCreated:*
filterRule:
suffix: .zip