Aspire의 전신은 Project: Tye라는 실험용 프로젝트였고, 두 프로젝트 모두 Docker/Podman을 대체한다기보다, Docker/Podman 같은 컨테이너 도구를 "활용"하는 방식으로 동작합니다.
닷넷으로 마이크로서비스, 멀티컨테이너 애플리케이션에 가깝게 만들고 테스트해보고 싶다면, Aspire가 등장하기 전에는 아래 그림처럼 솔루션 속성에 가서 여러 시작 프로젝트를 설정하고 띄워보는 것이 최선이었는데요,
이렇게 띄우더라도 로그를 일괄적으로 수집해서 보거나 하기 무척 까다로웠고 개발 경험도 별로 좋지 않았을 뿐더러, 배포할 때 엄청난 노력이 들어갑니다. 개별 애플리케이션의 컨테이너화를 모두 고려해야 해서 Dockerfile이나 Containerfile을 일일이 만들어줘야하고, 이미지 레지스트리에 푸시하는 것도 챙겨야 하고 할 일이 엄청나게 많았죠.
대신 Aspire를 사용하면, 마이크로서비스를 만들고, 디버깅하고 (*), 배포하는 것을 간소화시켜줘서 큰 이점이 있습니다.
다만 아직 계속 개발 중인 기술이라, 현재는 클라우드 중립 + Azure Resource Manager를 위한 약간의 편의성 보강 정도로만 지원이 되고 있고, AWS나 GCP 등의 클라우드 프로바이더와 연동하는 기능은 커스텀으로 개발해야 하는 상황입니다.
대체한다기보다는 docker를 한 번 더 감싸서 컨테이너 관리라던가 클라우드까지 책임져주는 제품군으로 알고 있었습니다! 전 회사에서 프로젝트할때 서버 별로 도커파일 및 이미지 관리하고 배포까지 하려니 그것도 일이 엄청 많았는데 한방에 되면 좋으니 써보지는 못했지만 좋은 제품 같이 보였습니다!
Aspire를 사용할 수 있는 여러 방법들이 있지만, 기본적으로 아래와 같이 로컬 개발 환경에서 오케스트레이션 설정을 관리하기 위한 AppHost.cs 파일을 작성할 수 있습니다. 아래처럼 기능을 제공한다는 뜻은 우리가 전통적으로 애플리케이션 개발을 할 때와는 달리 “로컬 실행”을 전제로 작성하는 것이고, 실제로도 Aspire 애플리케이션을 패키징해보면 Apphost에 관련된 코드는 정확히 빠진 상태로 나가게 됩니다.
만약 로컬 실행 뿐 아니라 재배포 가능한 요소를 만들어서 Docker Compose나 Helm 차트 같은 것은 어떻게 만들어야할까 그 동안 고민이 많았는데, 이것도 요즈음 유행하는 AI 에디터와 코드 어시스턴트 덕분에 멋진 해결 방안이 생긴 것 같습니다. 예를 들어, 다음과 같이 Podman/Docker에 의존하는 AppHost로 wordpress, phpMyAdmin, MySQL 컨테이너를 오케이스트레이션하는 앱 호스트 코드가 있다고 가정해보겠습니다.
이 코드는 FBA 코드이고, AppHost의 기능 중 인프라 중립적인 관점으로 자신의 구조를 설명하는 JSON 매니페스트를 만드는 기능 (dotnet publish로 아티팩트를 만드는 것과는 다른 기능입니다.)으로 JSON 파일을 아래 명령어를 써서 만들 수 있습니다.
dotnet run .\wordpress.cs --publisher manifest --output-path ./manifest.json
그러면 manifest.json을 컨텍스트로 지정하여 Helm 차트, Kustomize, Docker Compose 파일을 만들어달라고 이야기하면 단순히 말로 프롬프트를 지정하는 것보다 더 구체적이고 해상도가 높은 DevOps용 아티팩트를 만들어내는 것 같습니다.