브랜트 버넷은 카우치베이스 전문가시스템 설계자이자 데스크톱 및 웹 풀스택 개발 경험이 풍부한 .Net 개발자입니다. 지난 12년 동안 노스캐롤라이나주 록스보로에 본사를 둔 가족 엔터테인먼트 소프트웨어 회사인 CenterEdge Software에서 근무해 왔습니다. Brant는 소프트웨어 제품군의 모든 부문을 위한 애플리케이션을 개발한 경험이 있습니다. 지난 4년 동안 그는 회사의 클라우드 인프라를 Microsoft SQL 플랫폼에서 순수 Couchbase NoSQL 플랫폼으로 전환하기 위해 노력해 왔습니다. CenterEdge에서 일하면서 Brant는 재미있는 비즈니스를 위한 진지한 소프트웨어 솔루션을 만드는 데 집중할 수 있었습니다.
출시와 함께 Couchbase .NET SDK 2.4.0이제 카우치베이스는 다음을 공식 지원합니다. .NET Core. NET을 위한 새로운 세상을 열었습니다. 카우치베이스 개발자를 지원합니다. 특히 이제 다음 기능을 사용할 수 있습니다. Docker 를 사용하여 애플리케이션을 쉽게 관리하고 배포 프로세스를 개선할 수 있게 되었으며, 이는 이전에는 Java 및 Node.js와 같은 애플리케이션의 전유물이었습니다.
에서 CenterEdge 소프트웨어를 통해 ASP.NET 모놀리식 애플리케이션을 Docker 기반 ASP.NET Core 마이크로서비스로 전환하기 위해 빠르게 움직이고 있습니다. 이를 통해 제공되는 새로운 가능성과 애플리케이션의 견고성 및 배포 용이성 개선에 대해 매우 기대가 큽니다. 이러한 전환을 위해 저희가 사용하고 있는 접근 방식에 대한 이 개요가 다른 분들께도 도움이 되기를 바랍니다.
구성 및 환경
대부분의 ASP.NET Core 응용 프로그램에서 구성은 다음에서 읽은 설정을 기반으로 합니다. appsettings.json 파일을 프로젝트 루트에 추가합니다. 그런 다음 이러한 설정은 환경별 설정으로 재정의됩니다(예 appsettings.Development.json). 이러한 설정은 애플리케이션이 시작될 때 존재하는 환경 변수에 의해 차례로 재정의될 수 있습니다.
CenterEdge에서는 실제 환경과 관련된 특정 사항을 의미하도록 .NET Core 환경을 정의했습니다. 기본값을 사용할 필요 없이 자신만의 환경 이름을 추가할 수도 있지만, 저희는 기본값을 사용했습니다.
- 개발 - Visual Studio를 사용한 로컬 머신 개발. 구성은 로컬 머신의 Couchbase Server 등을 가리킵니다.
- 스테이징 - 클라우드 내 테스트 환경
- 프로덕션 - 사전 프로덕션 환경(배포 전 최종 테스트용)과 최종 프로덕션 환경 모두. 이러한 환경은 일반적으로 스테이징과 동일하지만 기본적으로 로깅이 더 가볍습니다.
따라서 기본 앱설정.json은 일반적으로 다음과 같이 보입니다:
{
"로깅": {
"IncludeScopes": false,
"LogLevel": {
"기본값": "디버그",
"시스템": "정보",
"Microsoft": "정보",
"카우치베이스": "디버그"
}
},
"카우치베이스": {
"버킷": [
{
"이름": "내 버킷"
}
]
}
}
위의 구성은 서버 URL을 지정하지 않았기 때문에 기본적으로 Couchbase Server에 로컬호스트를 사용합니다. 다음으로 appsettings.Staging.json 및/또는 appsettings.Production.json 이렇게요:
{
"로깅": {
"LogLevel": {
"기본값": "정보",
"카우치베이스": "정보"
}
}
"카우치베이스서비스디스커버리": "_couchbase._tcp.services.local"
}
이렇게 하면 로그 수준이 보다 합리적인 수준으로 줄어들고 서비스 검색을 위한 설정도 있습니다(나중에 설명).
종속성 주입
ASP.NET Core는 기존 ASP.NET 모델과는 다른 많은 기술을 사용하므로 Couchbase를 .NET Core 애플리케이션에 통합하는 것이 약간 다릅니다. 특히 ASP.NET Core는 처음부터 다음과 함께 작동하도록 만들어졌습니다. 종속성 주입.
이를 지원하기 위해 Couchbase.Extensions.DependencyInjection 패키지를 사용하여 Couchbase SDK 버킷 객체와 종속성 주입 시스템 간의 격차를 해소할 수 있습니다. Couchbase는 서비스 구성 에서 시작 클래스를 생성하고 위의 구성 섹션을 전달합니다. 또한 웹 애플리케이션이 종료될 때 연결을 종료하는 셧다운 코드도 추가합니다.
public void ConfigureServices(IServiceCollection services)
{
// 설정 섹션에 카우치베이스 등록
서비스
.AddCouchbase(Configuration.GetSection("Couchbase"))
.AddCouchbaseBucket("내 버킷");
if (!Environment.IsDevelopment())
{
services.AddCouchbaseDnsDiscovery(Configuration["CouchbaseServiceDiscovery"]);
}
services.AddMvc();
// 다른 서비스 등록하기
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env,
ILoggerFactory loggerFactory,
I애플리케이션평생애플리케이션평생)
{
// …
// 여기에 표준 애플리케이션 시작이 표시되지 않음
// …
// 애플리케이션이 정상적으로 종료되면 카우치베이스 연결이 종료됩니다.
applicationLifetime.ApplicationStopped.Register(() => =>
{
app.ApplicationServices.GetRequiredService().Close();
});
}
모든 컨트롤러의 모든 버킷에 액세스할 수 있습니다. IBucketProvider 를 호출할 수 있습니다. 그러나 위의 예제에서는 다음과 같이 추가카우치베이스버킷("내버킷").
이 방법을 사용하면 다음에서 상속된 빈 인터페이스를 등록할 수 있습니다. INamedBucketProvider:
공용 인터페이스 IMyBucketProvider : INamedBucketProvider
{
}
그런 다음 컨트롤러 또는 비즈니스 로직 서비스에 주입합니다. 이때 제공한 구성에 따라 항상 동일한 버킷을 제공합니다. 서비스 구성.
공용 클래스 HomeController : 컨트롤러
{
비공개 읽기 전용 IMyBucketProvider _버킷 공급자;
public HomeController(IMy버킷프로바이더 버킷프로바이더)
{
_버킷 공급자 = 버킷 공급자;
}
public IActionResult Index()
{
var bucket = _버킷제공자.GetBucket();
var result =
기다리는 버킷.쿼리동기화(
"SELECT Extent.* FROM 내 버킷 AS 범위");
if (!result.Success)
{
새 예외("카우치베이스 오류", result.Exception)를 던집니다;
}
뷰(결과.행)를 반환합니다;
}
}
서비스 검색
마이크로서비스로 작업할 때 서비스 검색은 일반적인 문제입니다. 실행하는 각 환경마다 서로 다른 엔드포인트에 서로 다른 서비스가 있는 경향이 있습니다. Couchbase는 그러한 서비스 중 하나로, 각 환경의 다른 주소에 존재할 수 있습니다. 서비스 검색을 위한 많은 솔루션이 있지만, CenterEdge에서는 현재로서는 간단한 솔루션을 사용하기로 결정했습니다, DNS SRV 레코드.
이를 지원하기 위해 Couchbase.Extensions.DnsDiscovery 패키지를 설치합니다. 이 패키지는 클러스터의 노드를 나열하는 DNS SRV 레코드를 찾습니다. 이를 지원하기 위해 AWS 루트 53에 "services.local"이라는 프라이빗 DNS 도메인을 생성하고, Couchbase 노드 목록이 있는 "_couchbase._tcp.services.local"이라는 SRV 레코드 집합을 생성합니다. Route 53 레코드셋은 다음과 같습니다:
10 10 8091 couchbasedata1.int.dev.centeredgeonline.com
10 10 8091 couchbasedata2.int.dev.centeredgeonline.com
10 10 8091 couchbasedata3.int.dev.centeredgeonline.com
위의 시작 시 서비스 구성 예제에서 다음 섹션을 보셨을 것입니다:
if (!Environment.IsDevelopment())
{
services.AddCouchbaseDnsDiscovery(Configuration["CouchbaseServiceDiscovery"]);
}
이렇게 하면 구성을 통해 전달된 모든 서버가 DNS SRV 레코드를 조회하여 찾은 서버로 대체됩니다. 또한 구성을 통해 DNS 이름을 제공하므로 필요한 경우 쉽게 재정의할 수 있습니다. 특히 로컬호스트를 사용하여 Couchbase 클러스터에 액세스하는 개발 환경에서는 이 확장 기능을 사용하지 않습니다.
멋지네요, 도커는 어때요?
지금까지 설명한 모든 내용은 일반적으로 ASP.NET Core에 적용할 수 있으며 반드시 Docker에만 적용되는 것은 아닙니다. 그렇다면 일반 애플리케이션에서 Docker 컨테이너에서 실행되는 애플리케이션으로 이동하려면 어떻게 해야 할까요?
먼저 개발 머신에서 완료해야 할 몇 가지 준비 단계가 있습니다:
- 다음 사항이 있는지 확인합니다. Windows에서 Hyper-V 사용
- 설치 Windows용 도커
- 구성 Docker의 공유 드라이브 애플리케이션이 있는 드라이브의 경우
- 설치 Docker용 Visual Studio 도구
- Docker가 시작되었는지 확인합니다(로그인 시 자동 시작되도록 Docker를 구성할 수 있습니다).
이제 준비가 완료되었습니다. Visual Studio에서 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 추가 > Docker 지원으로 이동하세요. 그러면 프로젝트에 필요한 파일이 추가됩니다.
Docker 지원 추가
여러 파일이 추가되었지만 특히 중요한 파일이 몇 가지 있습니다. 가장 먼저 언급하고 싶은 파일은 다음과 같습니다. 도커파일:
FROM microsoft/aspnetcore:1.0.1
엔트리포인트 ["닷넷", "TestApp.dll"]
ARG 출처=.
WORKDIR /앱
EXPOSE 80
COPY $source .
이 파일에는 수정해야 할 두 개의 주요 줄이 있습니다:
FROM microsoft/aspnetcore:1.0.1
1.0.3 또는 1.1.0과 같은 다른 버전의 .NET Core를 사용하는 경우 이 줄을 변경해야 합니다. 이 줄의 버전 태그는 프로젝트.json 파일에 사용된 .NET Core 버전과 일치해야 합니다.
엔트리포인트 ["닷넷", "TestApp.dll"]
프로젝트 이름을 변경하면 다른 DLL 파일 이름이 출력됩니다. 이 줄을 변경하여 올바른 DLL 파일명을 참조하세요.
다음 파일은 docker-compose.yml. 이 파일은 일부 관련 파일과 함께 실행을 클릭할 때 시작되는 Docker 컨테이너의 특성을 제어합니다. 이 파일을 변경하려면 docker-compose.yml 를 클릭하여 Couchbase Server 연결이 작동하도록 합니다.
개발 환경의 구성은 "localhost"에 액세스하여 Couchbase Server에 액세스하려고 합니다. 이 접근 방식은 애플리케이션이 IIS Express에서 실행되는 경우 정상적으로 작동합니다. 그러나 Docker 컨테이너 내부에서 "localhost"는 더 이상 개발 컴퓨터를 가리키지 않습니다. 대신 가상 머신 내에서와 마찬가지로 격리된 Docker 컨테이너를 가리킵니다.
이 문제를 해결하려면 다음과 같이 환경 섹션을 추가해야 합니다. docker-compose.yml 를 입력하여 'localhost' 대신 컴퓨터 이름을 사용하세요:
버전: '2'
서비스:
testapp:
이미지: user/testapp${TAG}
빌드:
컨텍스트: .
도커파일: 도커파일
포트:
– “80”
환경으로 이동합니다:
- Couchbase:서버:0=http://$COMPUTERNAME:8091/
위의 마지막 두 줄을 파일에 추가하기만 하면 됩니다. Docker Compose가 자동으로 다음을 대체합니다. $컴퓨터이름 를 컴퓨터 이름과 함께 사용하면 소스 제어를 통해 팀과 애플리케이션을 공유할 때 유용합니다.
이제 Docker에서 테스트할 준비가 되었습니다. 앱을 시작하기 전에 Visual Studio 툴바의 실행 드롭다운을 IIS Express 대신 Docker로 변경하기만 하면 됩니다. 디버깅도 지원하며 디버그 창에 로그가 표시됩니다.
정말 멋지게 꾸미고 싶다면 다음과 같이 조정할 수도 있습니다. docker-compose.yml 를 사용하여 필요한 추가 컨테이너를 시작하고, 환경 변수를 통해 다른 설정을 재정의하는 등의 작업을 수행할 수 있습니다. 예를 들어, CenterEdge에서는 개발 중인 애플리케이션의 종속 요소인 추가 마이크로서비스를 시작할 때 이 접근 방식을 사용합니다.
배포
정확한 배포 방식은 사용 중인 Docker 플랫폼에 따라 달라집니다. 예를 들어, CenterEdge는 Amazon AWS를 사용하므로 다음을 사용하여 배포합니다. EC2 컨테이너 서비스. 선택한 플랫폼에 관계없이 애플리케이션에서 Docker 이미지를 만들어 Docker 컨테이너 레지스트리에 게시해야 합니다.
CenterEdge에서는 이 기능을 지속적 통합 프로세스에 추가했는데, 관련 단계를 요약하면 다음과 같습니다:
- "닷넷 게시 경로/to/your/app -c 릴리스"를 실행하여 애플리케이션을 게시합니다. 이렇게 하면 기본적으로 "bin/Release/netcoreapp1.0/publish"에 게시되지만 "-o some/path" 매개 변수를 사용하여 제어할 수 있습니다. .NET Core 1.1의 경우 기본적으로 netcoreapp1.0이 아닌 netcoreapp1.1이 됩니다.
- "docker build -t myappname 경로/to/your/app/bin/Release/netcoreapp1.0/publish"를 실행하여 Docker 이미지를 빌드합니다. 태그는 "myappname"으로 지정됩니다.
- "docker 태그 내앱이름 yourdockerregistry/내앱이름:sometag"를 실행하여 Docker 레지스트리에 대한 Docker 이미지에 태그를 지정합니다. "yourdockerregistry"를 Docker 레지스트리 경로로 대체합니다. Docker Hub의 경우 이것은 사용자 이름입니다. "sometag"를 "최신" 또는 "1.0.5"와 같이 사용하려는 태그로 대체합니다.
- "docker push yourdockerregistry/myappname:sometag"를 실행하여 이미지를 Docker 컨테이너 레지스트리에 푸시합니다. 여기서는 이미 "docker 로그인"을 사용하여 레지스트리를 인증했다고 가정합니다.
버전 관리와 관련하여, CenterEdge에서는 마이크로서비스에 NuGet 스타일의 버전 번호를 사용합니다. 예를 들어, "1.1.0" 또는 "2.0.5-beta002". 이 버전 번호는 Docker 컨테이너 레지스트리에서 사용하는 태그입니다. 또한 SemVer를 사용하여 숫자의 다른 부분에 대한 증분은 특정한 의미를 갖습니다. 첫 번째 숫자가 증가하면 API에 획기적인 변경 사항이 있으며 이전 버전과 완전히 호환되지 않음을 의미합니다. 두 번째 숫자가 증가하면 중요한 새 기능이 추가되었음을 나타냅니다. 세 번째 숫자는 버그 수정을 위해 증가합니다.
결론
이제 Couchbase를 사용하는 .NET 애플리케이션을 .NET Core 및 Docker로 전환하는 데 필요한 기본 도구를 갖추셨기를 바랍니다. 저희는 이 전환이 재미있고 흥미진진하다는 것을 알게 되었습니다. ASP.NET Core에서 일부 접근 방식이 변경되고 다른 것들이 더 이상 사용되지 않지만 전반적인 플랫폼은 훨씬 더 깔끔하고 사용하기 쉬워졌습니다. 그리고 앞으로 더 멋진 기능들이 추가될 것이라고 확신합니다.
