* feat(agent-engine): add support for container and custom image specs - Add container_config to deployment_files. - Add image_spec with build_args to source_config. - Make agent_framework optional and document supported values. - Implement dynamic specs for container and source deployments. - Add examples and automated tests for new deployment types. * chore: update Google provider version to 7.28.0 across modules Mechanical update of versions.tf and versions.tofu files using tools/versions.py. * feat(agent-engine): refactor for container deployments and API alignment - Group deployment settings under 'deployment_config' (renamed from 'deployment_files'). - Support container-based deployments via 'container_config' and 'image_spec'. - Refactor 'source_files_config' (renamed from 'source_config') to include mutually exclusive 'python_spec' and 'image_spec'. - Support 'developer_connect_config' as a source code type. - Group engine settings (framework, env, secrets) under 'agent_engine_config'. - Add support for 'memory_bank_config' persistent memory. - Overhaul reasoning engine resources with dynamic blocks to match provider schema. - Update all documentation examples, add TOC, and refresh test inventories. * Update dynamic python_spec block and related example yamls * Ignore changes setting for developer_connect_source under lifecycle management * fixing review comments for `try` and default path for `source_path` --------- Co-authored-by: Hemanand <hemr@google.com> Co-authored-by: Julio Castillo <jccb@google.com>
Google Cloud Service Directory Module
This module allows managing a single Service Directory namespace, including multiple services, endpoints and IAM bindings at the namespace and service levels.
It can be used in conjunction with the DNS module to create [service-directory based DNS zones](https://cloud.google.com/service-directory/docs/configuring-service-directory-zone, offloading IAM control of A and SRV records at the namespace or service level to Service Directory. The last examples shows how to wire the two modules together.
Examples
Namespace with IAM
module "service-directory" {
source = "./fabric/modules/service-directory"
project_id = "my-project"
location = "europe-west1"
name = "sd-1"
iam = {
"roles/servicedirectory.editor" = [
"serviceAccount:namespace-editor@example.com"
]
}
}
# tftest modules=1 resources=2 inventory=simple.yaml
Services with IAM and endpoints
module "service-directory" {
source = "./fabric/modules/service-directory"
project_id = "my-project"
location = "europe-west1"
name = "sd-1"
services = {
one = {
endpoints = ["first", "second"]
metadata = null
}
}
service_iam = {
one = {
"roles/servicedirectory.editor" = [
"serviceAccount:service-editor.example.com"
]
}
}
endpoint_config = {
"one/first" = { address = "127.0.0.1", port = 80, metadata = {} }
"one/second" = { address = "127.0.0.2", port = 80, metadata = {} }
}
}
# tftest modules=1 resources=5 inventory=services.yaml
DNS based zone
Wiring a service directory namespace to a private DNS zone allows querying the namespace, and delegating control of DNS records at the namespace or service level. This effectively allows fine grained ACL control of Cloud DNS zones.
module "service-directory" {
source = "./fabric/modules/service-directory"
project_id = "my-project"
location = "europe-west1"
name = "apps"
iam = {
"roles/servicedirectory.editor" = [
"serviceAccount:namespace-editor@example.com"
]
}
services = {
app1 = { endpoints = ["one"], metadata = null }
}
endpoint_config = {
"app1/one" = { address = "127.0.0.1", port = 80, metadata = {} }
}
}
module "dns-sd" {
source = "./fabric/modules/dns"
project_id = "my-project"
name = "apps"
zone_config = {
domain = "apps.example.org."
private = {
client_networks = [var.vpc.self_link]
service_directory_namespace = module.service-directory.id
}
}
}
# tftest modules=2 resources=5 inventory=dns.yaml
Services with endpoints using Private Network Access
Private Network Access enables supported Google Cloud products to send HTTP requests to resources inside a VPC.
locals {
project_number = "123456789012"
}
module "service-directory" {
source = "./fabric/modules/service-directory"
project_id = "my-project"
location = "europe-west1"
name = "sd-1"
services = {
one = {
endpoints = ["first", "second"]
metadata = null
}
}
endpoint_config = {
"one/first" = {
address = "10.0.0.11",
port = 443,
network = "projects/${local.project_number}/locations/global/networks/${var.vpc.name}"
metadata = {}
}
"one/second" = {
address = "10.0.0.12",
port = 443,
network = "projects/${local.project_number}/locations/global/networks/${var.vpc.name}"
metadata = {}
}
}
}
# tftest modules=1 resources=4 inventory=pna.yaml
Note that the network argument is unusual in that it requires the project number, instead of the more common project ID.
Variables
| name | description | type | required | default |
|---|---|---|---|---|
| location | Namespace location. | string |
✓ | |
| name | Namespace name. | string |
✓ | |
| project_id | Project used for resources. | string |
✓ | |
| endpoint_config | Map of endpoint attributes, keys are in service/endpoint format. | map(object({…})) |
{} |
|
| iam | IAM bindings for namespace, in {ROLE => [MEMBERS]} format. | map(list(string)) |
{} |
|
| labels | Labels. | map(string) |
{} |
|
| service_iam | IAM bindings for services, in {SERVICE => {ROLE => [MEMBERS]}} format. | map(map(list(string))) |
{} |
|
| services | Service configuration, using service names as keys. | map(object({…})) |
{} |
Outputs
| name | description | sensitive |
|---|---|---|
| endpoints | Endpoint resources. | |
| id | Fully qualified namespace id. | |
| name | Namespace name. | |
| namespace | Namespace resource. | |
| service_id | Service ids (short names). | |
| service_names | Service ids (long names). | |
| services | Service resources. |