Editing Spacelift

This page documents how the [[Main Page|AWS/IaC practice lab]] actually got built — two working environments, run through Spacelift, with real gotchas along the way. See also: [[How to Use Spacelift]] for the step-by-step version, and [[MAC]], the agent that did most of the hands-on work.

== Watch it happen ==

Brett sketches the architecture, MAC turns it into OpenTofu config, Spacelift plans it and waits for a human to confirm before anything touches AWS. That's the whole loop:

<div class="wiki-video-frame" id="wiki-video-spacelift-build"></div>

== Why it exists ==

Practice, ahead of an interview with Spacelift itself. The goal wasn't a tutorial-grade demo — it was a real AWS account, real infrastructure, real failure modes, so the mistakes happened here instead of live.

== The two labs ==

=== Orbit Labs (two-stack) ===

Two independent Spacelift stacks, one Git repo each, linked by a Spacelift-level stack dependency rather than a Terraform data source:

* '''Networking stack''' — VPC (<code>10.0.0.0/16</code>), one public subnet, an internet gateway, and a public route table. Outputs <code>subnet_id</code>.
* '''App stack''' — consumes <code>subnet_id</code> as <code>var.subnet_id</code>. Builds a key pair, two security groups (web: 80/443/22 from an admin-only CIDR; db: 3306 from the web SG only), a pinned-AMI web fleet across prod/dev/test environments, and one dedicated database instance.

The app stack cannot plan until the networking stack has applied and produced that output — enforced on Spacelift's Dependencies tab, not just documented convention.

=== Pulsar (single-instance) ===

A simpler, single self-contained stack built later specifically to avoid the stack-dependency wiring above for quick experiments: one VPC, one t3.micro/t3.small instance, no cross-stack linkage. 443 open to the world by design (for testing real internet-facing TLS); 22 restricted to an admin IP. An Elastic IP keeps the address stable across stop/start and resize cycles.

== Build order ==

# Push the networking/base stack first; wait for <code>FINISHED</code>.
# Push the app stack; it fails outright with a missing-variable error if pushed before the dependency exists.
# Poll with <code>spacectl</code>, not the browser — the web UI lags behind real state.
# Pull outputs (<code>spacectl stack outputs --id &lt;stack-id&gt;</code>) for live IPs once finished.

== What actually broke ==

* '''AMI drift wiped a fleet.''' A <code>data "aws_ami" { most_recent = true }</code> lookup meant a routine, unrelated push replaced the entire web fleet the moment AWS published a new image — new IPs, and any state that only lived on local disk was gone. Fix: pin the AMI as a fixed-default variable, bump it deliberately.
* '''The AWS console reads a literal <code>Name</code> tag.''' Resources tagged with lowercase <code>name</code> are valid but invisible in the console's Name column. Every resource needs <code>Name = "..."</code>, capital N.
* '''Deleting a stack doesn't clean up its dependency link.''' Emptying the networking stack's config to tear it down left the app stack's dependency reference dangling — the next run on either stack failed with a vague missing-input error until the link was removed and, later, explicitly re-added before rebuilding.
* '''Free-tier restrictions fail mid-operation.''' Requesting a <code>t3.medium</code> resize got rejected by a <code>FreeTierRestrictionError</code> — but only after AWS had already stopped the instance to attempt the resize, leaving it stopped (and, without an Elastic IP already attached, on a fresh IP).
* '''Uploaded-file PHP execution was silently broken.''' Because the vhost proxies every <code>*.php</code> request straight to PHP-FPM at the server-config level, MediaWiki's and WordPress's default "disable script execution in the uploads directory" <code>.htaccess</code> protection didn't actually apply — confirmed by dropping a harmless <code>.php</code> test file in <code>wp-content/uploads/</code> and watching it execute. Fixed with an explicit <code>SetHandler none</code> + <code>Require all denied</code> override in both upload directories.

== The pattern that's worth keeping ==

Instance power state as a declarative resource, not a manual CLI step:

<pre>
resource "aws_ec2_instance_state" "web" {
  instance_id = aws_instance.web.id
  state       = "stopped"  # flip to "running", push, confirm
}
</pre>

Flip the string, push, Spacelift applies it. No compute billing while stopped; the Elastic IP means the address survives the whole cycle.

== Why Spacelift specifically ==

* Plan and apply are structurally separate, with a mandatory human confirm gate before anything touches AWS.
* Stack dependencies are a first-class, enforced object — not a README instruction to run things in order.
* Full run history via <code>spacectl stack run list</code> — every change, when, and why, queryable later.
* The automation API key is scoped read-only by design; it hard-fails on anything that tries to trigger a deploy. Read access for tooling and write access for a human are two separate credentials.

That last point is the one that actually matters most: it's the reason handing real, live infrastructure work to [[MAC]] was something to trust rather than something to worry about.

[[Category:Infrastructure as Code]]
[[Category:AWS]]
[[Category:AI Agents]]