refactor: DB EC2 AMI 갱신 시 인스턴스 교체 방지 - #72
Conversation
- 운영 중인 DB EC2가 AMI 변경만으로 재생성되지 않도록 lifecycle ignore_changes에 ami 추가 - API EC2와 동일한 방식으로 통일 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan includes up to 1 review per rolling hour; 0 remain after this review. 📝 WalkthroughWalkthrough
ChangesDB 서버 AMI 설정
Estimated code review effort: 1 (사소함) | ~2 minutes Merge Risk: 🔵 Low · up to This change prevents an AMI ID update from replacing the running DB instance, avoiding an unintended interruption, but it also leaves AMI drift to be managed operationally and still needs plan confirmation for unintended changes; it is mergeable with explicit owner follow-up. Possibly related issues
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Terraform Plan:
|
Terraform Plan:
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 23df9d455b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| lifecycle { | ||
| # AMI 갱신이 운영 중인 DB EC2를 교체하지 않도록 무시하고, 인스턴스가 재생성되는 시점에 새 AMI를 적용합니다. | ||
| ignore_changes = [ | ||
| ami, |
There was a problem hiding this comment.
When db_ami_id changes and the existing instance is later recreated because of -replace, tainting, or another replacement-triggering attribute, Terraform retains the prior state value for attributes in ignore_changes; consequently, the replacement is launched with the old AMI rather than the newly configured one. This contradicts the lifecycle comment and means the planned recovery rehearsal—or an emergency rebuild after AMI drift—will not install the expected backup tooling and can fail entirely if the old AMI has been deregistered. The AMI ignore must therefore be removed or conditionally disabled before replacement, or the rollout needs another mechanism that explicitly supplies the new AMI.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
의견 감사합니다. 하지만 공식 문서를 확인해본 결과 ignore_changes는 create를 계획할 때는 해당 인자를 고려하고, update를 계획할 때만 무시한다고 되어 있습니다. 따라서 해당 의견은 반영하지 않도록 하겠습니다.
2 participants
관련 이슈
작업 내용
aws_instance.db_server의lifecycle.ignore_changes에ami를 추가했습니다.특이 사항
aws_instance.db_server는ignore_changes에ami가 없어db_ec2_ami_id변경만으로 destroy 후 create가 발생합니다.aws_volume_attachment에stop_instance_before_detaching = true가 적용되어 있어 MySQL이 실행 중인 상태에서 인스턴스가 정지됩니다.aws_instance.api_server는 이미 동일하게ami를 무시하고 있어 두 인스턴스의 관리 방식이 통일됩니다.트레이드오프
ignore_changes = [ami]는 코드상의 AMI ID와 실제 인스턴스의 AMI가 달라지는 drift를 지속적으로 숨깁니다. 실제 적용 시점은 운영 문서에 별도로 기록해야 합니다.리뷰 요구사항 (선택)
terraform plan결과에aws_instance.db_server의 교체가 포함되지 않는지 확인 부탁드립니다.🤖 Generated with Claude Code
Summary by CodeRabbit