Removing Docker build dependency from build phase

[cagataycali]

While creating OpenSearch serverless vector index, we’re using Dockerized python app to create mappings in given vector collection, CDK environments are mostly Docker based solutions and leads to docker-in-docker support requirements.

We can remove the Docker phrase from the initial configuration to make the process simpler ^^

generative-ai-cdk-constructs/lambda/opensearch-serverless-custom-resources/custom_resources/opensearch_index.py

Line 179 in fab3bba

def create_index(

[gmarchand]

Hello

We are using @cdklabs/generative-ai-cdk-constructs (notably the VectorKnowledgeBase construct) in our AWS CDK project.

Our CI/CD pipeline (GitLab Runner) does not support Docker-in-Docker (DinD) or installing Docker on the runner for security and infrastructure reasons.

Currently, the construct requires Docker to be available at deploy time, as it uses Code.fromDockerBuild (or similar) to build Lambda assets for custom resource providers. This results in the following error during cdk deploy:

Apply to .semgrep.yml
RuntimeError: spawnSync docker ENOENT
...
at DockerImage.fromBuild
at Code.fromDockerBuild
at new CRProvider (.../custom-resource-provider-helper.js:44:35)
at new VectorIndex (.../vector-index.js:33:62)
at new VectorKnowledgeBase (.../vector-knowledge-base.js:297:36)

Root Cause:

The construct always uses Docker to build Lambda assets for custom resources.
There is no option to use a pre-built asset (e.g., a zip file built in a separate job or locally).
There is no way to override the asset bundling method or provide a custom asset location.

Why This Is a Problem:

Many CI/CD environments (including ours) do not allow Docker or Docker-in-Docker for security or technical reasons.
This makes it impossible to deploy stacks using this construct in such environments.
Other CDK constructs (e.g., Lambda) allow using Code.fromAsset with pre-built zips, which works well for these scenarios.

Feature Request:

Please add support for one or both of the following:
Allow specifying a pre-built Lambda asset (e.g., via a property like customResourceCode or lambdaAssetPath) so that users can build the asset elsewhere and provide it to the construct.
Allow using a non-Docker asset bundling method (e.g., Code.fromAsset or a custom bundler command) for environments where Docker is not available.

Benefits:
Enables use of this construct in a wider range of CI/CD environments.
Aligns with best practices for reproducible builds and secure CI/CD pipelines.
Reduces friction for teams with strict infrastructure policies.

Workarounds Considered:
Using a runner with Docker installed (not possible in our environment).
Forking/patching the construct (not ideal for long-term maintenance).
Pre-building assets, but no way to inject them into the construct as it stands.

[gmarchand]

This Feature Request could solve the issue : aws/aws-cdk-rfcs#719