.net 8 로 만든 사이트를 윈도우 웹서비스에 등록해 사용중입니다.
Port 를 변경해야 하는데 7200,8000 이런 포트로 변경하면 작동을 잘합니다.
문제는 80 port 를 사용해야 하는데
당연히 IIS 80 PORT 는 죽였습니다.
방화벽 인바운드 정책에서 80은 딱히 정의 하지 않는것 같아 그대로 놔뒀습니다.
혹시나해서
80 포트도 열어봤습니다.
이렇게 appsetting.json 을 설정하고
도메인에 특정 포트를 지정하지 않으면 80 포트로 열려야 하지 않나요??
근데 열리지 않네요?
프로그램을 관리자 권한으로 실행하세요.
윈도우즈 1000번 이하는 관리자 권한 필요한걸로
cmd 창을 ㅠㅠ 관리자 권한으로 실행해도 안되네요
url을 진짜 저걸로 해놓으신건 아니죠?
사설 인증서 만들어서 특정 테스트 url로 했습니다
당연히 host 설정도 하고요 포트 바뀌면 잘되는데
80 포트쪽만 안되네요
음… https 라서 443으로만 접근 가능하게 된거 아닌가요?
리다이렉트 설정을 따로 해놓으신게 있는건지
Program.cs 에서
app.UseHttpsRedirection();
가 추가되어 있나요?
네 했어요 ㅠㅠ 80 포트 바인딩은 뭐 다른 문제같네요 열심히 찾는중입니다.
잉 IIS에 사이트 올리면 케스트렐을 사용 안하게되지 않나요?
최후의 수단으로 남겨두고 있는데 이것 이유라도 좀 알아야 할것 같아서요 ;
IIS를 사용하지만 사용하지 않는경우인가요…? 어떤 의도로 하신건지 궁금합니다
어차피 core로 서비스 할것라 굳이 iis 로 서비스할필요없을것 같아서 윈도우 서비스로 등록해서 사용할려고 했습니다.
core가 iis로 서비스 하는 방법이 있다고 하는데 아마도 80 포트로 서비스 할려면 iis 로 배포해야 하나보네요
Research 중인데 80이랑 몇개 포트는 윈도우에서 관리하고
system 에서 점유중이라 안된다는것 같네요
닷넷코어 웹앱이라도 IIS배포는 간편한것 같습니다… 퍼블리시 폴더 올리면 끝나던데요?
IIS 자체를 전혀 사용 안하시면 제거를 하거나 해야할것 같습니다. 웹서버가 여러개 돌아가는게 타당한 이유가 있는지 개인적으로는 의문인거 같아요.
음… 저는 개인 홈페이지 만들 때 딱히 포트를 바꿀 일이 없어서 대충 그냥 UseUrls를 썼습니다.
WebApplicationBuilder 객체의 WebHost 속성을 건드리니까 잘 되더군요~
[글 수정] 참고로 IIS는 안썼습니다. 자체 호스팅입니다.
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.UseUrls("http://0.0.0.0:80", "https://0.0.0.0:443").ConfigureKestrel(kestrelOptions =>
kestrelOptions.ConfigureHttpsDefaults(options =>
options.ServerCertificateSelector = kestrelOptions.ApplicationServices.GetServerCertificateSelector()));
...
builder.Services.AddControllersWithViews();
builder.Services.AddRazorPages();
builder.Services.AddCertUpdater();
...
var app = builder.Build();
// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
app.UseWebAssemblyDebugging();
}
else
{
app.UseExceptionHandler("/Error");
// The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
app.UseHsts();
}
...
app.UseHttpsRedirection();
...
app.Run();
일반적으로 윈도우즈에서 80 포트를 사용하기 위해서 점유하는 인스턴스를
종료해야 한다고 하네요
위에 나온대로 80 port 하기 위해서 따라 했는데도
호스팅을 윈도우 서비스 할때 작동 안되서 정석대로 IIS 로 배포해서 해결했습니다.
댓글들 감사합니다.
가능하면 iis 에서 관리가 아닌 윈도우 서비스로 서비스를 관리하고 싶어서
그렇게 배포 전략을 세웠습니다.
core는 아무래도 리눅스 나 docker 같은것랑 친한 느낌입니다.
특정 tcp 포트를 어디서 사용하는지 정확히 확인하는 쉬운 방법이 있어서 추가로 댓글 남깁니다.
netstat -ano | findstr LISTENING 명령어를 사용하시면 아래 그림처럼 포트 별로 리스너를 열어둔 프로세스 ID들이 모두 열거됩니다.
여기서 마지막 컬럼에 나오는 숫자값이 프로세스 아이디 값이고, 이것을 작업 표시줄에서 프로세스 세부 정보에서 찾아보시거나, tasklist /fi "PID eq 프로세스아이디"로 쿼리해보시면 프로세스 명을 확인해보실 수 있습니다.
프로세스 이름이 혹시 svchost 따위로 잡히면 여전히 다른 Windows 코어 서비스가 계속 포트를 점유하고 있는 것이고, 그렇지 않다면 서비스나 일반 프로세스일 가능성이 높을 것 같네요. ㅎㅎ
(TMI) 이런 방법으로 프로세스를 찾을 때 svchost 같은 퉁친 프로세스로 조회되는 이유: 몇몇 NT 서비스들은 프로세스 메모리 절약을 이유로 Service Host (svchost) 안에 서비스 코드를 인 메모리로 로드해서 코드를 실행하는 방식으로 서비스를 입주시키는 경우가 있습니다.
그리고 IIS+ANCM (Asp .Net Core Module) 조합이 여전히 의미가 있을 수 있는 또 다른 이유를 하나 생각해볼 수 있는 것이 있습니다.
리눅스라면 Kestrel을 직접 세우기보다 앞 단에 Envoy, Apache HTTPD, Nginx를 붙이는 것을 선호하는 경우가 있습니다. IIS가 이들 웹 서버와 동일한 역할을 해줄 수 있어서 Windows 서버를 사용한다면 굳이 Envoy, Apache HTTPD, Nginx의 Windows 이식판을 찾기보다는 30년 가까이 Windows 플랫폼에서 잘 돌아가는 것이 확실히 검증된 IIS를 대신 쓰는 것도 효율적인 선택일 수 있다고 생각합니다. (단, 웹 소켓, HTTP/2, HTTP/3 같은 최신 기술을 써야 한다면 IIS는 http.sys 커널 드라이버로 웹 요청을 받기 때문에 반드시 Windows Server 2022로 업그레이드가 꼭 필요합니다.)
그리고 이렇게 애플리케이션용 HTTP 서버 앞에 일반 웹 서버를 두는 이유는, 생각보다 검색 엔진 크롤러, 클라우드 서비스들이 제공하는 웹 방화벽, 로드 밸런서 에이전트 같이 비 웹 브라우저 타입의 클라이언트가 웹 요청을 보내오는 경우가 엄청 많은데, 이럴 때 마다 일일이 Kestrel이 나서서 요청을 받고 응답을 처리할 때 부하도 있고, 불필요한 로그가 남는 불편함이 있어 이런 요청은 웹 서버에서 걸러내도록 하기 위함인 것도 있습니다.
예전에 .net 5.0으로 asp.net core 프로젝트를 iis로 돌리니 브라우저에서 요청할 때 hang이 걸리는 경우가 종종 발생했었습니다. 발생하는 시점이 워낙 불규칙해서 원인은 찾지 못했고 iis를 kestrel로 변경하는 것만으로 해결했습니다. 그다음부터는 asp.net core 프로젝트는 무조건 kestrel로 돌리고 있습니다.
저도 5.0 시절에 그랬던것 같습니다.
저는 윈도우는 아니고 aws ec2에 배포했는데 계속 뭘 요청하고
hang 걸리드라고요 /health 엔드포인트 추가하고 해결했던것 같아요
