Changing things safely

📘What it really is

• Plan symbols:
• + create; - destroy; ~ update in place (the resource stays, a setting changes);
• -/+ destroy and then create a replacement; +/- create the replacement first, then destroy the old one;

• lines marked # forces replacement show which setting can't be changed in place.

• Many settings can't change in place. For a Docker container, almost any change (image, environment, ports) means a new container. In a cloud, changing a database's storage type or a server's base image may mean replacement too. Replacing a database without a volume or snapshot loses its data.

• Lifecycle settings change how Terraform replaces things:

• create_before_destroy = true starts the new one before removing the old. For app copies, that means the site keeps serving during a change. Names must then be unique, because both exist for a moment (RouteRani adds a random suffix that changes with each version);
• prevent_destroy = true makes any plan that would destroy this resource fail. Useful on production databases;

• ignore_changes = [tags] stops Terraform undoing changes another system makes to listed settings.

• Watch out: create_before_destroy also applies to everything that resource depends on. If the API copies used depends_on = [docker_container.db], Terraform would also try to start a second database before removing the first, which on one volume is dangerous. RouteRani's app copies leave out that depends_on on purpose and retry the database connection instead.

• Replacing on purpose: terraform apply -replace=docker_container.db replaces a resource even though nothing changed, for example to recover a broken one.

• Wait for health: the Docker provider's wait = true makes Terraform wait until the container's health check passes. If it doesn't pass in time (wait_timeout), the apply stops with an error, and with create_before_destroy the old copies are still running.