For the complete documentation index, see llms.txt. This page is also available as Markdown.

Building Serverless Framework Images

A reusable Harness pipeline to build customized Serverless images.

This page provides a Harness CD pipeline to help you build your own Docker images for the Serverless framework.

The purpose of this pipeline is to give you flexibility—so you can adopt newer AWS Lambda runtimes or tailor the image to your specific serverless application needs.

What This Pipeline Does

This pipeline automates building Serverless images for different programming languages using Harness. It enables you to keep up with the latest Serverless versions and apply customizations as required for your projects.

You can find the full pipeline YAML in the Pipeline YAML section below.

Understanding Serverless Runtimes

Serverless runtimes refer to the programming language environments that the Serverless framework supports for function development. Each runtime provides the language-specific libraries, tools, and dependencies to build, test, and deploy serverless applications.

Common Serverless runtimes include:

  • Node.js: Versions like nodejs18.x, nodejs20.x, nodejs22.x

  • Python: Versions like python3.11, python3.12

  • Java: Versions like java8, java17, java21

  • Ruby: Versions like ruby2.7, ruby3.2

When you build your image using the Harness pipeline, you combine the Harness Serverless plugin (which provides the integration with Harness CD) with a specific runtime image from AWS. This allows you to deploy serverless applications written in your preferred programming language while leveraging Harness deployment capabilities.

Key Components and pre-requisites

This pipeline helps you build custom serverless plugin images using Harness, enabling integration of the Harness plugin with supported AWS Lambda runtimes. Below are the key details you should know about the pipeline:

  • Deployment Stage with Kubernetes Infrastructure

    • Utilizes a Deployment stage configured to run on Kubernetes.

  • Kubernetes Cluster Requirement and Privileged Mode

    • Requires a Kubernetes cluster set up by the user.

    • The pipeline’s step group runs with privileged: true mode enabled to allow Docker-in-Docker and image build operations.

    • This privileged mode requires the Kubernetes cluster nodes to permit privileged containers.

    • For example, if using Google Kubernetes Engine (GKE), do not use Autopilot clusters, as they restrict privileged containers. Instead, use a standard GKE cluster with node pools configured to allow privileged pods.

    • Connect the Kubernetes cluster to Harness via a Kubernetes Cluster connector.

  • Use of Official AWS SAM Images

  • Automatic Extraction of Runtime and Version

    • Extracts runtime name and version details directly from the SAM base image name.

  • Final Image Naming Convention

    • Images are named following the format: serverless-plugin:{VERSION}-{RUNTIME_NAME}-{VERSION}-linux-amd64 Example: serverless-plugin:1.1.0-beta-python3.12-1.1.0-beta-linux-amd64

Pipeline Runner Privileged Mode Requirement

Certain steps in the pipeline require the Kubernetes pod to run in privileged mode. This is necessary for starting Docker daemons (DinD), building container images inside pipeline steps, and granting the permissions Docker needs at runtime.

Why privileged mode is required:

  • Enables Docker-in-Docker (DinD) support for building and pushing images.

  • Allows installation and execution of docker CLI and manipulation of containers within the build step.

  • Required for root access and mounting Docker volumes.

To enable privileged execution, set privileged: true in the step group or step-level security context. Example:

For individual steps:

Without this setting, Docker builds and image pushes may fail due to insufficient permissions inside the container.

Quick Start

  1. Copy and paste the pipeline YAML provided into your Harness Project.

  2. Add an empty/do nothing service to the pipeline.

  3. Add a Kubernetes environment to the pipeline.

  4. In the Execution section, enable container-based execution in the step group. Add the Kubernetes cluster connector inside the container step group. Save the pipeline.

  5. Click Run Pipeline

  6. Enter the required parameters:

    • VERSION: The version number of the Harness base image (e.g., 1.1.0-beta). VERSION represents specific code changes in the Harness repository. With each new code change, we push a new tag and publish new Docker images with these tags, allowing users to access specific versions of the plugin.

    • Harness_base_image: You can find the Harness base image with the specific release versions from Harness DockerHub.

    • RUNTIME_BASE_IMAGE_VERSION: Runtime base image from AWS ECR (e.g., public.ecr.aws/sam/build-python3.12:1.142.1-20250701194731-x86_64)

    • NODEJS_BASE_IMAGE_VERSION: Node.js base image from AWS ECR (e.g., public.ecr.aws/sam/build-nodejs20.x:1.142.1-20250701194712-x86_64)

    • SERVERLESS_VERSION: Serverless Framework version (e.g., 3.39.0)

Serverless Plugin Image Pre-requisites

The pipeline supports only complete formats for the base images:

  • public.ecr.aws/sam/build-java21:1.140.0-20250605234711-x86_64

  • public.ecr.aws/sam/build-nodejs18.x:1.120.0-20240626164104-x86_64

Serverless Base Image Pre-requisites

Only official AWS SAM build images from the AWS ECR Public Gallery are supported.

  • Use SAM base images only from: AWS ECR Gallery - SAM

  • Only x86_64 architecture images are supported

  • Using different base images may cause library dependency issues

  • Non-standard base images may cause the plugin not to function as required

  • You must use the final image at the step level of your serverless deployment. This plugin cannot be used in Plugin info at the service level, as this setting at the service level fetches only from the Harness official Dockerhub repository.

Image Configuration

The pipeline produces two types of images with the following naming patterns:

  1. Base Image (without Serverless Framework):

${RUNTIME_NAME}-${VERSION}-linux-amd64

Example: java21-1.1.0-beta-linux-amd64

  1. Serverless Image (with Serverless Framework installed): ${RUNTIME_NAME}-${SERVERLESS_VERSION}-${VERSION}-linux-amd64

Example: java21-3.39.0-1.1.0-beta-linux-amd64

Where:

  • RUNTIME_NAME: Extracted runtime name (e.g., java21, nodejs22.x)

  • SERVERLESS_VERSION: Serverless Framework version (e.g., 3.39.0)

  • VERSION: Harness plugin version (e.g., 1.1.0-beta)

Variables Used in Pipeline

These variables are actively used in the pipeline for building and pushing the image that you need to configure:

Pipeline variables: - TARGET_REPO, DOCKER_USERNAME, and DOCKER_PASSWORD are set once as pipeline-level variables.

Variable
Description
Example
Required

TARGET_REPO

Target Docker repository to push built plugin images

your_account/serverless-plugin

Yes

DOCKER_USERNAME

Docker registry username

dockerhub_username

Yes

DOCKER_PASSWORD

Docker registry password or Personal Access Token (PAT)

<your_dockerhub_pat>

Yes

Runtime inputs: - VERSION, RUNTIME_BASE_IMAGE_VERSION, NODEJS_BASE_IMAGE_VERSION, HARNESS_BASE_IMAGE, and SERVERLESS_VERSION are user inputs set for each pipeline run to specify exact versions for the builds.

Variable
Description
Example
Required

VERSION

Plugin image/version tag

1.1.2

Yes

RUNTIME_BASE_IMAGE_VERSION

AWS SAM runtime base image from ECR

public.ecr.aws/sam/build-python3.12:1.143.0-20250822194415-x86_64

Yes

NODEJS_BASE_IMAGE_VERSION

AWS SAM Node.js base image from ECR

public.ecr.aws/sam/build-nodejs22.x:1.143.0-20250822194415-x86_64

Yes

HARNESS_BASE_IMAGE

Harness base image used in build

harness/serverless-plugin:1.1.0-beta-base-image

Yes

SERVERLESS_VERSION

Serverless Framework version to install

3.39.0

Yes

Compatibility Validation

  • Runtime Compatibility: Always verify compatibility between runtime and Node.js images before building. The Serverless Framework requires Node.js to function correctly.

  • Library Dependencies: Check that both images share the same C++ libraries (especially libstdc++.so) to ensure proper operation.

Validating Image Compatibility

Verify that the runtime and Node.js base images are compatible by sharing the same system libraries and dependencies. This is crucial because the Serverless Framework (which requires Node.js) must run properly on your chosen runtime image.

Step 1: Pull and Inspect Both Images

First, pull both images locally:

Step 2: Check C++ Library Compatibility

Check that both images have the same version of libstdc++.so:

They are compatible if both images show the same version (e.g., libstdc++.so.6.0.33).

Recommended Compatible Combinations

Runtime
Node.js Base Image
Runtime Base Image

nodejs18.x

nodejs18.x

nodejs18.x

nodejs20.x

nodejs20.x

nodejs20.x

nodejs22.x

nodejs22.x

nodejs22.x

java17

nodejs18.x

java17

java21

nodejs22.x

java21

python3.11

nodejs18.x

python3.11

python3.12

nodejs20.x

python3.12

java8.al2

nodejs18.x

java8.al2

ruby3.2

nodejs18.x

ruby3.2

Pipeline YAML

This is the YAML for the AWS CDK image build pipeline. You can copy and paste it into your Harness Project.

This is how the stage would look in the UI:

Click to view full size image
Pipeline YAML

Parameters you need to change:

  • projectIdentifier: Your Harness project identifier

  • orgIdentifier: Your Harness organization identifier

  • connectorRef: Your Kubernetes cluster connector identifier

  • your_k8s_connector: Your Kubernetes cluster connector identifier

Last updated

Was this helpful?