upgrade and develop

서버 배포와 백업까지 정리한 뒤에는 테스트가 신경 쓰이기 시작했다.처음에는 로컬에서 dotnet test가 통과하면 괜찮다고 생각했다. 그런데 Codex나 GitHub Actions 같은 환경에서 테스트를 돌리려고 하니 문제가 생겼다.오류는 대략 이런 식이었다.Cannot create an automatic instance.Unknown error처음에는 코드가 깨졌나 싶었는데, 자세히 보니 테스트 코드 자체의 실패가 아니라 LocalDB 자동 인스턴스를 만들지 못해서 생긴 문제였다.문제 상황현재 운영 DB는 Ubuntu 서버의 Docker MSSQL에 있다.Ubuntu Server ↓Docker ↓mssql-db ↓SurvivalGame DB하지만 테스트가 운영 DB에 직접 붙으면 안 ..

자동 배포까지 끝나고 나니 다음으로 신경 쓰인 것은 DB였다.앱은 GitHub에 코드가 있고 Docker 이미지로 다시 만들 수 있다. 하지만 DB 데이터는 한 번 날아가면 코드처럼 다시 clone할 수 없다.이전에는 테스트 배포 단계라 DB를 지우고 다시 만들어도 괜찮았다. 하지만 실제 데이터가 쌓이기 시작하면 그런 식으로 작업하면 안 된다. 그래서 이번에는 MSSQL 백업과 복구 과정을 먼저 정리했다.오늘 목표오늘 목표는 네 가지였다.MSSQL 수동 백업 성공 ↓백업 파일을 호스트 서버에 저장 ↓자동 백업 스크립트 작성 ↓백업 파일로 실제 복구 테스트백업 파일이 생기는 것만 확인하고 끝내고 싶지는 않았다. 실제로 복구까지 해봐야 안심할 수 있다고 생각했다.현재 MSSQL 구조MSSQL..

지난 글에서는 ASP.NET Core 게임 서버를 Ubuntu 홈 서버에 올리고, Nginx와 Cloudflare를 통해 으로 접속되도록 만드는 과정까지 정리했다.이번 글은 그 과정에서 따로 발생한 DB 관련 문제를 정리하려고 한다.처음에는 Docker 컨테이너만 잘 뜨면 앱이 바로 실행될 줄 알았다. 그런데 실제로는 방치되어있던 프로젝트를 그대로 가져오는 바람에 실제 애플리케이션이 실행되려면 DB 연결과 스키마 생성을 문제가 발생하고 나서야 해결해나갔다. 여기서 MSSQL 연결 문자열 문제, EF Core Migration 순서 문제, SQL Server의 외래키 제약 조건 문제가 이어졌다.처음에는 “서버에 앱만 올리면 되겠지” 정도로 생각했는데, 실제로는 애플리케이션 코드와 DB 스키마가 운영 환경에..