Packaging Lambda functions

Stacktape-lambda-buildpack

• Built-in, zero-config, heavily optimized buildpack that creates a lambda artifact from an entryfile path.

• Your source code is built into a single file with all of its external dependencies. This ensures you are shipping only the minimum required code. Behind the scenes, Stacktape uses esbuild.

• Source-maps are automatically generated and includes in your deployment package. The generated code also includes the source map support library to make them usable.

• If your dependency uses dynamic require() and can't be statically built, it will be copied as-is instead.

• If your dependency is dependent on a binary file, the dependency will be installed in a Docker container (based on the runtime used) and copied to the deployment package. This ensures your binary dependencies are usable even when deploying from a different OS (Windows or Mac).

• Your deployment packages are cached. Stacktape creates a digest (checksum) from all the necessary files (and your package manager lockfiles). If a workload with the same digest is already deployed, the packaging and deployment is skipped.

• Lambda function packages are zipped and uploaded to a pre-created S3 bucket.

• The upload uses S3 transfer acceleration - upload is done to the nearest AWS's edge location, and then routed to the bucket using an Amazon backbone network. This is faster and more secure, but incurs additional transfer costs ($0.04 per GB). To disable this behavior, set (config).deploymentConfig.useS3TransferAcceleration to false.

Custom-artifact

• You supply a path to your own, pre-created artifact.
• If the specified path is a directory or an un-zipped file, Stacktape will zip it.
• The zipped lambda package is then uploaded to a pre-created S3 bucket using S3 transfer acceleration.

Packaging Web services

Stacktape-image-buildpack (web-service)

• Built-in, zero-config, heavily optimized buildpack that creates an image from an entryfile path.
• Your source code is built into a single file with all of its external dependencies. This ensures you are shipping only the minimum required code. Behind the scenes, Stacktape uses esbuild.
• Source-maps are automatically generated and includes in your deployment package. The generated code also includes the source map support library to make them usable.
• If your dependency uses dynamic require() and can't be statically built, it will be copied as-is instead.
• If your dependency is dependent on a binary file, the dependency will be installed in a Docker container using a Docker multi-stage build.
• The base image used is the latest LTS version of node.js.
  • mhart/alpine-node:slim-16 in case your app doesn't require glibc-based binaries.
  • node:16 in case it does.
• The image is uploaded to a pre-created (AWS ECR) container registry.

YAML
Typescript
Copy
resources:
  webService:
    type: web-service
    properties:
      packaging:
        type: stacktape-image-buildpack
        properties:
          entryfilePath: src/main.ts
      resources:
        cpu: 2
        memory: 2048

External-buildpack (web-service)

• The image is built using a zero-config external buildpack.
• You can find a buildpack for almost any language or framework. The default buildpack used is paketobuildpacks/builder:base. You can configure the buildpack used by specifying the buildpack property.
• The buildpack works by scanning the specified source directory and automatically determining how the build the image for a given application.
• The image is uploaded to a pre-created (AWS ECR) container registry.

YAML
Typescript
Copy
resources:
  webService:
    type: web-service
    properties:
      packaging:
        type: external-buildpack
        properties:
          sourceDirectoryPath: ./src
          builder: heroku/buildpacks:20
      resources:
        cpu: 2
        memory: 2048

Custom-dockerfile (web-service)

• The image is built from your own Dockerfile.
• You need to configure buildContextPath. Stacktape will look for a Dockerfile in this directory (or use a Dockerfile specified by dockerfilePath).
• The image is uploaded to a pre-created (AWS ECR) container registry.

YAML
Typescript
Copy
resources:
  webService:
    type: web-service
    properties:
      packaging:
        type: custom-dockerfile
        properties:
          buildContextPath: ./server
          dockerfilePath: Dockerfile
      resources:
        cpu: 2
        memory: 2048

Prebuilt-image (web-service)

• Pre-built image is used.
• To use private images, you need to configure repositoryCredentialsSecretArn. The body of the secret should have the following format: {"username" : "<<privateRegistryUsername>>", "password" : "<<privateRegistryPassword>>"}. Secrets can be managed directly using Stacktape. For more information, refer to secrets docs.

YAML
Typescript
Copy
resources:
  webService:
    type: web-service
    properties:
      packaging:
        type: prebuilt-image
        properties:
          image: httpd:latest
      resources:
        cpu: 2
        memory: 2048

Packaging Private services

Stacktape-image-buildpack (private-service)

• Built-in, zero-config, heavily optimized buildpack that creates an image from an entryfile path.
• Your source code is built into a single file with all of its external dependencies. This ensures you are shipping only the minimum required code. Behind the scenes, Stacktape uses esbuild.
• Source-maps are automatically generated and includes in your deployment package. The generated code also includes the source map support library to make them usable.
• If your dependency uses dynamic require() and can't be statically built, it will be copied as-is instead.
• If your dependency is dependent on a binary file, the dependency will be installed in a Docker container using a Docker multi-stage build.
• The base image used is the latest LTS version of node.js.
  • mhart/alpine-node:slim-16 in case your app doesn't require glibc-based binaries.
  • node:16 in case it does.
• The image is uploaded to a pre-created (AWS ECR) container registry.

YAML
Typescript
Copy
resources:
  myPrivateService:
    type: private-service
    properties:
      packaging:
        type: stacktape-image-buildpack
        properties:
          entryfilePath: src/main.ts
      resources:
        cpu: 2
        memory: 2048

External-buildpack (private-service)

• The image is built using a zero-config external buildpack.
• You can find a buildpack for almost any language or framework. The default buildpack used is paketobuildpacks/builder:base. You can configure the buildpack used by specifying the buildpack property.
• The buildpack works by scanning the specified source directory and automatically determining how the build the image for a given application.
• The image is uploaded to a pre-created (AWS ECR) container registry.

YAML
Typescript
Copy
resources:
  myPrivateService:
    type: private-service
    properties:
      packaging:
        type: external-buildpack
        properties:
          sourceDirectoryPath: ./src
          builder: heroku/buildpacks:20
      resources:
        cpu: 2
        memory: 2048

Custom-dockerfile (private-service)

• The image is built from your own Dockerfile.
• You need to configure buildContextPath. Stacktape will look for a Dockerfile in this directory (or use a Dockerfile specified by dockerfilePath).
• The image is uploaded to a pre-created (AWS ECR) container registry.

YAML
Typescript
Copy
resources:
  myPrivateService:
    type: private-service
    properties:
      packaging:
        type: custom-dockerfile
        properties:
          buildContextPath: ./server
          dockerfilePath: Dockerfile
      resources:
        cpu: 2
        memory: 2048

Prebuilt-image (private-service)

• Pre-built image is used.
• To use private images, you need to configure repositoryCredentialsSecretArn. The body of the secret should have the following format: {"username" : "<<privateRegistryUsername>>", "password" : "<<privateRegistryPassword>>"}. Secrets can be managed directly using Stacktape. For more information, refer to secrets docs.

YAML
Typescript
Copy
resources:
  myPrivateService:
    type: private-service
    properties:
      packaging:
        type: prebuilt-image
        properties:
          image: httpd:latest
      resources:
        cpu: 2
        memory: 2048

Packaging Container workloads

Stacktape-image-buildpack (container-workload)

• Built-in, zero-config, heavily optimized buildpack that creates an image from an entryfile path.
• Your source code is built into a single file with all of its external dependencies. This ensures you are shipping only the minimum required code. Behind the scenes, Stacktape uses esbuild.
• Source-maps are automatically generated and includes in your deployment package. The generated code also includes the source map support library to make them usable.
• If your dependency uses dynamic require() and can't be statically built, it will be copied as-is instead.
• If your dependency is dependent on a binary file, the dependency will be installed in a Docker container using a Docker multi-stage build.
• The base image used is the latest LTS version of node.js.
  • mhart/alpine-node:slim-16 in case your app doesn't require glibc-based binaries.
  • node:16 in case it does.
• The image is uploaded to a pre-created (AWS ECR) container registry.

External-buildpack (container-workload)

• The image is built using a zero-config external buildpack.
• You can find a buildpack for almost any language or framework. The default buildpack used is paketobuildpacks/builder:base. You can configure the buildpack used by specifying the buildpack property.
• The buildpack works by scanning the specified source directory and automatically determining how the build the image for a given application.
• The image is uploaded to a pre-created (AWS ECR) container registry.

Custom-dockerfile (container-workload)

• The image is built from your own Dockerfile.
• You need to configure buildContextPath. Stacktape will look for a Dockerfile in this directory (or use a Dockerfile specified by dockerfilePath).
• The image is uploaded to a pre-created (AWS ECR) container registry.

Prebuilt-image (container-workload)

• Pre-built image is used.
• To use private images, you need to configure repositoryCredentialsSecretArn. The body of the secret should have the following format: {"username" : "<<privateRegistryUsername>>", "password" : "<<privateRegistryPassword>>"}. Secrets can be managed directly using Stacktape. For more information, refer to secrets docs.

Packaging Batch jobs

Stacktape-image-buildpack (batch-job)

• Built-in, zero-config, heavily optimized buildpack that creates an image from an entryfile path.
• Your source code is built into a single file with all of its external dependencies. This ensures you are shipping only the minimum required code. Behind the scenes, Stacktape uses esbuild.
• Source-maps are automatically generated and includes in your deployment package. The generated code also includes the source map support library to make them usable.
• If your dependency uses dynamic require() and can't be statically built, it will be copied as-is instead.
• If your dependency is dependent on a binary file, the dependency will be installed in a Docker container using a Docker multi-stage build.
• The base image used is the latest LTS version of node.js.
  • mhart/alpine-node:slim-16 in case your app doesn't require glibc-based binaries.
  • node:16 in case it does.
• The image is uploaded to a pre-created (AWS ECR) container registry.

External-buildpack (batch-job)

• The image is built using a zero-config external buildpack.
• You can find a buildpack for almost any language or framework. The default buildpack used is paketobuildpacks/builder:base. You can configure the buildpack used by specifying the buildpack property.
• The buildpack works by scanning the specified source directory and automatically determining how the build the image for a given application.
• The image is uploaded to a pre-created (AWS ECR) container registry.

Custom-dockerfile (batch-job)

• The image is built from a specified Dockerfile.
• You need to configure buildContextPath. Stacktape will look for a Dockerfile in this directory (or use a Dockerfile specified by dockerfilePath).
• The image is uploaded to a pre-created (AWS ECR) container registry.

Prebuilt-image (batch-job)

• Pre-built image is used.
• The image must be publicly available.

API reference