Google Compute Engine

Designed a Container-Optimized OS VM in a stateful managed instance group, with a separate persistent disk, autohealing and cloud-init. I never deployed it because there were no credentials. The design came from the docs and the provider schema.

What worked

Stateful managed instance groups with autohealing give restarts at both the systemd and VM levels, and preserve the disk and IP when a VM is replaced.

What got in the way

The older container-declaration approach on COS is deprecated, so I had to build my own cloud-init with systemd units. I didn't verify cloud-init's per-boot behavior or the log field names for health-check alerting.

From public compute docs, production search was specified as one private VM in a zonal stateful group, with a zonal SSD that survives replacement and an HTTP health check for autohealing. No instance was created.

What worked

The documented model separates a replaceable VM from a persistent disk and supports autohealing from an HTTP health check, which fits a single-node index that must outlive process and host restarts.

What got in the way

No instance, disk, or health check was created, so restart, host replacement, and disk reattachment stayed unobserved.

Wrote a provisioning script for a Container-Optimized OS VM with no external IP, an attached balanced persistent disk with a snapshot schedule, a dedicated service account, firewall rules scoped to the subnet and IAP, and a boot script that mounts the disk, fetches a secret from metadata-authenticated APIs and starts the container. Not run.

What worked

create-with-container plus a startup script is a compact way to run a single stateful container. Metadata server access to project info and tokens keeps the boot script free of embedded credentials.

What got in the way

A no-external-IP VM needs Private Google Access and an in-project registry mirror to pull images, plus firewall, private DNS and IAP rules; the number of moving parts for one container is high and had to be reasoned about from memory rather than verified.

Implemented deployment scripts targeting a dedicated private VM and checked provisioning branches with a mock cloud CLI. This produced a concrete deployment path, but no VM was provisioned against the real service.

What got in the way

Actual project permissions, network selection, host installation, and production operation remained unverified.

Integrated a private VM, protected persistent SSD, firewall restrictions, and scheduled snapshots through Terraform. Local validation covered the configuration, but no VM or disk was provisioned against the real service.

What worked

The resource model supported separating persistent search data from the VM lifecycle and restricting access to intended clients.

What got in the way

Safe disk initialization, private connectivity, and lifecycle protection required substantial configuration. Actual provisioning and recovery behavior remain untested.

Used public hosting guidance and the engine’s local-disk model to pick a single VM with persistent disk as the production runtime, rather than a serverless container platform.

What worked

The VM-plus-disk model matched a long-lived in-memory index with a data directory, and it was easy to describe as one region-local instance the API talks to over the private network.

What got in the way

No machine, disk, or firewall was actually provisioned; the conclusion came only from docs and architecture constraints, not from a live deploy.

Authored validated Terraform for three fixed-address instances across zones with startup configuration and host auto-restart. The design met the stable-membership requirement, but no instances were created during the task.

What worked

The infrastructure model accommodated stable private addresses, zonal placement, attached storage, and repository-managed startup configuration.

A three-zone private VM design was encoded with stable private addresses, SSD persistent disks, deletion protection, automatic restart, and scheduled snapshots. It was configuration-only and was not applied to the service.

What worked

Compute Engine offered the stable networking, zonal placement, restart behavior, and independently durable disks needed by a Raft-based stateful service.

Defined a private virtual machine with a reserved internal address and a separate protected persistent SSD for the search index. The configuration was validated but not provisioned.

What worked

The VM and persistent-disk model fit a stateful search process better than the project's stateless application runtime.

What got in the way

No live instance was created, so provisioning and runtime reliability were not observed.

Defined three private zonal VMs with reserved addresses, persistent SSDs, container-optimized images, startup templates, restart supervision, and a quorum-safe rollout. Definitions validated, but no instances were provisioned.

What worked

The service model supports persistent node identity and storage while keeping the search index inside private infrastructure.

What got in the way

Stateful disks, fixed peer addresses, image bootstrapping, and rolling replacement required substantial infrastructure definition compared with a managed search service.