Spacelift - Revision history

Brett: Use JS-injected video placeholder (raw video tag gets sanitized)

2026-08-21T19:18:11Z

Use JS-injected video placeholder (raw video tag gets sanitized)

← Older revision		Revision as of 19:18, 21 August 2026
Line 5:		Line 5:
	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:		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">		<div class="wiki-video-frame" id="wiki-video-spacelift-build"></div>
	~~<video controls preload~~="~~metadata" poster="/~~wiki~~/media/spacelift~~-~~diagram~~-~~poster.jpg" width="728">~~
	~~<source src="/wiki/media/~~spacelift-~~diagram-video.mp4~~" ~~type="video/mp4">~~
	~~Your browser doesn't support embedded video. <a href="/wiki/media/spacelift-diagram-video.mp4">Download the video</a> instead.~~
	~~</video~~>
	</div>

	== Why it exists ==		== Why it exists ==

Brett: Add build-flow video

2026-08-21T19:16:24Z

Add build-flow video

← Older revision		Revision as of 19:16, 21 August 2026
Line 1:		Line 1:
	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.		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">
			<video controls preload="metadata" poster="/wiki/media/spacelift-diagram-poster.jpg" width="728">
			<source src="/wiki/media/spacelift-diagram-video.mp4" type="video/mp4">
			Your browser doesn't support embedded video. <a href="/wiki/media/spacelift-diagram-video.mp4">Download the video</a> instead.
			</video>
			</div>

	== Why it exists ==		== Why it exists ==

Brett: Link the how-to guide

2026-08-21T16:49:10Z

Link the how-to guide

← Older revision		Revision as of 16:49, 21 August 2026
Line 1:		Line 1:
	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: [[MAC]], the agent that did most of the hands-on work.		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.

	== Why it exists ==		== Why it exists ==

Brett: Add matching categories

2026-08-21T16:39:16Z

Add matching categories

← Older revision		Revision as of 16:39, 21 August 2026
Line 57:		Line 57:
	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.		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:AWS ~~Lab~~]]		[[Category:Infrastructure as Code]]
			[[Category:AWS]]
			[[Category:AI Agents]]

Brett: Document how the lab was built

2026-08-21T16:29:13Z

Document how the lab was built

New page

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: [[MAC]], the agent that did most of the hands-on work.

== 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 <stack-id></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:AWS Lab]]