Aspnetcore: IIS-> .NET Core 애플리케이션 DLL 파일 잠금

app_offline.htm을 참조하십시오. https://docs.asp.net/en/latest/hosting/aspnet-core-module.html#asp -net-core-module-app-offline-htm

PowerShell 방식을 원하는 경우 IIS Admin cmdlet을 사용할 수 있습니다. https://technet.microsoft.com/en-us/library/ee790599.aspx

Stop-WebAppPool -Name $appPoolName

... deploy ...

Start-WebAppPool -Name $appPoolName

@Tratcher 설명 주셔서 감사합니다.
이것이 귀하의 계획에 있는지 확실하지 않지만 이전 ASP.NET MVC에서 작동했다고 생각합니까?
이 기능을 구현할 계획입니까?

@GuardRex 공유 호스팅 환경이고 AppPool을 중지 할 권한이 없기 때문에 할 수 없습니다.

msdeploy.exe 및 Azure로 '그냥 작동'할 수 있습니까? 내가 올바르게 이해하면 파일 잠금을 방지하기 위해 웹 사이트를 다시 시작해야합니다. -enableRule:AppOffline 은 (는) 작동하지만 전체 웹 사이트가 몇 분 동안 오프라인 상태이므로 특히 하루에 몇 번 배포한다는 점을 고려할 때 훌륭한 사용자 경험이 아닙니다.

http://stackoverflow.com/q/40276582/14131 참조

@chuchuva 일 수도 있지만 모든 마법에는 비용이

마술이든 아니든 잘 작동했습니다. ASP.NET 코어로 마이그레이션 한 후 지금은 좀 그리워요 ...

@HarelM과 동의했습니다. 자동화 된 배포에서 최종 사용자 경험에 이르기까지 이와 관련하여 문제가 발생했습니다. 우리는 이전 MVC를 사용하여 하루에 약 10 번 배포하는 것에서 밤에 매일 배포하는 것으로 전환했으며 Core 앱을 사용하는 사람들이 오프라인으로 전환 할 때 짜증이 날 것이라는 점을 받아 들였습니다. 쇼 스토퍼는 아니지만 Core 채택에 대한 마찰이 추가되었습니다.

👍

중복 재활용을 지원하지 않는 것은 회귀입니다.

이 기능을 다시 방문하여 로드맵에 올릴 계획이 있습니까? 다운 타임없는 배포를 지원하려는 경우 .Net Core 웹 사이트를 배포하는 모든 사람이 스테이징 슬롯 전략을 수동으로 구현하도록 요구하는 것은 매우 불편하고 비우호적입니다.

이 기능을 사용하면 많은 사람들이 .Net Core 웹 사이트로 훨씬 원활하게 전환 할 수 있으며 .Net Core 웹 사이트를 더 빠르게 채택 할 수 있습니다.

우리도 알고 싶습니다. 응용 프로그램 디렉토리에 app_offline.htm을 넣는 것은 작동하지 않습니다.

여러 사이트를 AspNetCore로 이동 한 후에야이 '기능'을 깨달았습니다. 게시 할 때마다 몇 분 동안 사이트를 오프라인으로 전환하는 것이 허용된다고 생각할 수 없습니다!

이것은 소규모 팀의 리더로서 나에게 충분하지 않습니다. AspNetCore가 대규모로 연속 통합을 실행하고 있습니까? 다시 게시하기 위해 매시간 몇 분 동안 사이트를 오프라인 상태로 만들 수는 없습니다.

FTP 또는 xcopying을 사용하여 배포하고 있습니까? 아니면 webdeploy를 사용하고 있습니까?

웹 배포를 통해 IIS에 게시하고 있습니다.

우리는 현재 web.config를 먼저 삭제 (효과적으로 응용 프로그램을 종료)하여이 문제를 해결하고 있지만 장기적으로는 실제로 허용되는 솔루션이 아닙니다.

@DaleMckeown 이상적으로 지속적인 통합 워크 플로를 사용하면로드 밸런서 뒤에 여러 서버가 있습니다. 그런 다음 하나의 서버를 가져 와서 업데이트 한 다음 다시 넣고 다음 서버로 이동합니다. 물론 이것이 항상 가능한 것은 아니므로 (우리의 경우처럼) 몇 분의 다운 타임을 가지고 살아야합니다. 우리의 경우 앱이 30 초 이내에 백업되므로 실제로는 문제가되지 않습니다.

헉헉

웹 배포를 통해 IIS에 게시하고 있습니다.

webdeploy를 사용하여 배포하는 데 사용할 수있는 몇 가지 옵션이 있습니다 (잠긴 파일의 이름을 바꾸고 앱을 오프라인으로 자동으로 삭제할 수 있음). 기본적으로 @shirhatti 입니까?

뿡 빵뀨

우리는 현재 web.config를 먼저 삭제 (효과적으로 응용 프로그램을 종료)하여이 문제를 해결하고 있지만 장기적으로는 실제로 허용되는 솔루션이 아닙니다.

xcopy 배포를 수행한다는 의미입니까?

webdeploy를 사용하여 배포하는 데 사용할 수있는 몇 가지 옵션이 있습니다 (잠긴 파일의 이름을 바꾸고 앱을 오프라인으로 자동으로 삭제할 수 있음). 기본적으로 @shirhatti 입니까?

감사합니다 David-내가 현재하고있는 것보다 더 좋게 들립니다 (IIS에서 사이트 및 앱 풀을 수동으로 중지). 이러한 접근 방식의 의미를 조사 할 수 있도록 몇 가지 리소스를 알려 주시겠습니까?

진실의 근원을 찾을 때까지 @DaleMckeown 몇 가지 정보 https://github.com/Microsoft/vsts-tasks/issues/5259#issuecomment -346202503

@davidfowl 우리는 webdeploy를 사용하여 테스트 서버 (btw는 우리에게 문제를주지 않음)에 배포하고, 거기에서 robocopy를 사용하여 파일을 라이브 서버로 복사합니다.

뿡 빵뀨

현재 web.config를 먼저 삭제하여이 문제를 해결하고 있습니다.

web.config 가 배포에서 제거되면 IIS는 배포에서 중요한 파일을 제공합니다. 공격자는 30 대가 열릴 때까지 밤낮으로 계속 파일을 요청할 수 있습니다.

헉헉

PS 접근 방식으로 잡초에 조금이라도 들어가고 싶다면 @ajeckmans의 조언에 따라 웹 팜에 배포하기 위해 AppPools를 한 번에 하나씩 삭제하는 프로세스를 스크립팅 할 수 있습니다. 이를 수행하는 방법에 대한 예제는 https://github.com/guardrex/aspnetcore-iis-ps-publish ...를 참조

@guardrex 당신이 맞아요. 먼저 app_offline.htm을 dir에 복사 한 다음 web.config를 제거하고 애플리케이션을 복사 한 다음 web.config를 다시 넣고 app_offline을 제거합니다 (모두 ofc 스크립트 사용). 불행히도 웹 사이트 디렉토리에 app_offline 파일을 배치하는 것만으로는 dll에 대한 잠금이 해제되지 않습니다. web.config를 제거해야합니다. 이는 이전의 asp.net 전체 앱 (예 : 이전 웹 양식 등)에 대해 수행 할 필요가없는 작업입니다.

@ajeckmans 작동하지 않아야합니다. web.config 파일이 제거되면 IIS는 변경 사항을 즉시 선택하므로 기본적으로 정적 파일 모듈에 대한 요청을 수행하고 파일 제공을 시작해야합니다. 그것을 시도하고 그것이 일어나는지 확인하십시오 ...

1. app_offline.htm을 추가
2. 사이트에서 app_offline.htm을 제공
3. web.config를 꺼내십시오.
4. 민감한 파일을 요청하십시오 (예 : http://localhost:<PORT>/<ASSEMBLY_NAME>.deps.json ... PORT 및 ASSEMBLY_NAME 대체).
5. 정적 파일 모듈이 올바르게 작동하는 경우 deps.json 파일이 제공되어야합니다.

나는 단순히 모듈을 제거하는 것을 신뢰하지 않을 것입니다 ...

<configuration> 
 <system.webServer> 
   <modules> 
     <remove name="StaticFileModule" /> 
   </modules> 
 </system.webServer> 
</configuration>

... 다른 모듈이 남아 있고 다른 공격 벡터를 제공 할 수 있기 때문입니다. 필수가 아닌 모듈을 모두 제거 할 수도 있지만 web.config 제거를 통해 배포를 처리하기 위해 이와 같은 움직임으로 미지의 영역에 진입하고 있습니다. 이는 공식 지침에 따른 옵션이 아니므로 완전히 지원되지 않습니다. 예를 들어, AppPool을 중단하거나 다른 전략을 사용하려면 PS 스크립팅을 권장합니다.

나는 그것에 동정의 메모를 추가해야한다고 생각한다. 그것은 보안 관점에서 약간의 눈썹을 올렸다. 배포 레이아웃이 변경되었을 때 파일을 wwwroot 다시 넣는 것을 포함하여 논의되었습니다.

토론 대상 : IIS 변경 사항을 web.config 위치에 게시 (IISIntegration 158)
web.config 다시 wwwroot (IISIntegration 164)로 이동시주의

[편집] 아마도 그것은 당신의 (지원되지 않는) 해결 방법 일 것입니다 : web.config를 다시 wwwroot 로 이동 한 다음 당신이하는 일을 계속하십시오. 아직도 tho ... 어떻게 오프라인 상태로 만들려면 앱을 깨는 것이 무섭습니다.

이 상황에서 우리가해야 할 일에 대해 더욱 혼란스러워합니다.

파일 잠금을 방지 할 수있는 방식으로 웹 배포를 통해 IIS에 AspNetCore 사이트를 게시하기위한 현재 권장 사항은 무엇입니까?

저도 알고 싶습니다. 이것은 우리 조직에서 .net 핵심 채택에 대한 주요 장애물이되고 있습니다.

내 .net 핵심 웹 애플리케이션이 실행 중이고 새 빌드를 게시하려고 할 때 DLL이 사용 중이라는 오류가 발생합니다. 따라서 앱 풀을 중지 한 다음 DLL을 업데이트하고 앱 풀을 시작해야합니다.

.Net Core에서 앱 풀을 중지하지 않고 새 빌드 / DLL을 게시 할 수있는 해결 방법이 있습니까?

이것은 섀도우 복사 메커니즘을 사용하는 .Net 프레임 워크에서 기본적으로 지원됩니다. 안타깝게도 .Net 코어가 출시 된 지 2 년이 지났고 여전히 매우 기본적인 필수 기능에 대한 지원이없는 것 같습니다. 앞으로이 문제를 해결할 계획이 있습니까?

도움을 주셔서 미리 감사드립니다.

@guardrex dll을 해제하기 위해 IIS (또는 잠금을 유지하는 모든 것)를 얻기 위해 앱을 중단하는 것은 실제로 무섭지 만 핫픽스를 제품에 푸시 할 수없는 것은 더 무섭습니다. 당분간은 앱을 깨는 것이 우리가 할 수있는 유일한 일이지만, 우리는 이것을 처리하는 다른 더 현대적인 접근 방식을 자주 찾고 있습니다. :)

@ shahjay748 숨을
당분간 오래된 프로세스에 갇혀있는 우리에게 도움이되지 않는 ofc :)

내가하는 일은 (올바른 방법인지 확실하지 않음) 사이트를 다른 디렉토리에 업로드하고 iis에서 경로를 전환하는 것입니다.

이 문제에 대해 내부 조사를했습니다. 내가 알 수 있듯이 ANCM은 배포 된 응용 프로그램에 파일 / 핸들을 보관하지 않습니다. webdeploy 자체의 문제로 보이며 배포에 실패합니다. app_offline이 삭제 된 후 몇 번 재 시도한 후에도 지속적으로 애플리케이션 배포에 실패한 적이 없었습니다.

그것에 대한 빠른 PowerShell 사이드 노트 추가 : 앱 어셈블리에 대한 잠금은 항상 해제됩니다 ... 나는 문제가 없었습니다 ( 아직! lol).

@ bpetersen1 ... "스테이징"접근 방식은 새 배포가 중단 될 경우 빠른 롤백 옵션을 제공하는 달콤한 부작용이 있습니다. 필요한 경우 스크립팅하기 쉽습니다.

이것은 여전히 ​​외부 적으로 성가신 일입니다. 우리는 IIS를 뒤로하기 위해 도커 솔루션을 조사하기로 결정했습니다.

나는 해결책을 실험 할 것입니다. 계속 지켜봐주세요.

FTP를 사용하여이 문제가 발생합니다.

이에 대한 Microsoft의 조언은 무엇입니까?!

FTP를 사용하여이 문제가 발생합니다.

이에 대한 Microsoft의 조언은 무엇입니까?!

appoffline.htm 파일을 드롭 한 다음 ftp를 제거한 다음 제거합니다.

@davidfowl 예, 이것이

감사합니다. 배치 파일을 어떻게 실행하고 있습니까?

이것에 대한 MIcrosoft의 문서에 대한 링크도 감사합니다. Google에서 찾을 수 없습니다. 감사.

@ niico100 기본적으로 배치 파일은 파일을 프로젝트 디렉토리에 복사하고 먼저 백업 폴더를 만듭니다. 파일을 복사하기 전에 appoffline.htm을 프로젝트 폴더에 넣으십시오.
파일 잠금 문제가 발생하면 복사가 다시 시도됩니다. 나는 robcopy를 사용하고 있습니다
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy

관심있는 사람이있는 경우 다음 스크립트는 Appveyor에서 배포 파일을 다운로드하고, 사이트를 중지하고, 필요한 파일을 복사하고, 사이트를 백업합니다.
https://github.com/IsraelHikingMap/Site/blob/master/Scripts/Deploy.ps1
그래도 관리자 권한으로 실행해야합니다. 우리가 마이그레이션하면 docker 가이 모든 말도 안되는 문제를 해결할 수 있기를 바랍니다.
Stop-WebAppPool 및 Start-WebAppPool powershell 명령을 사용합니다.

로컬 개발의 경우 WebDeploy가 작동하지 않았습니다. 내 로컬 IIS에 대해 사용해 보았지만 여전히 잠긴 파일에 대해 불평합니다. 그런 다음 VS 사전 / 사후 빌드 이벤트에서 위의 powershell 커맨드 렛을 사용해 보았지만 32 비트 powershell이 ​​64 비트 IIS 설정을 수정할 수 없기 때문에 작동하지 않았습니까? 어쨌든 내 ASP.Net Core 프로젝트의 다음 사전 / 사후 빌드 이벤트가 잘 작동하는 것 같습니다.

빌드 전 이벤트 :
echo "App Offline" /a > $(ProjectDir)app_offline.htm

빌드 후 이벤트 :
del $(ProjectDir)app_offline.htm

나는 여기서 불평을 간략히 숙독했고, 이것이 관련이있는 것 같다. CI 배포를 일반적으로 "방금 작동 한"octopus 배포에서 iis 관리 작업과 함께 azure devops 릴리스를 사용하는 것으로 옮겼습니다. 웹앱을 중지하고 앱 도메인을 중지 한 후에도 파일이 여전히 남아 있기 때문에 새 파일을 배포하는 데 여전히 문제가 있습니다. 사용하다.

이것은 아마도 3 번의 배포 중 적어도 1 번이며 상황을 개선하거나보다 안정적인 배포를 할 수있는 것을 찾지 못했습니다.

@Tratcher @ronnyek Application Insights와 관련된 것 같습니다. App Insights 확장을 추가 한 후 웹 앱 DLL은 갑자기 업데이트하기가 매우 어렵고 그 전에는 문제가 없습니다.

이는 App Insights가 프로파일 러를 앱 프로세스 및 DLL에 연결해야한다는 점을 고려할 때 의미가 있습니다.

나는 여전히이 문제에 직면하고 있습니다. 나는 플래그 -e nableRule : AppOffline을 사용합니다

릴리스를 시작한 후 웹 응용 프로그램 폴더를 모니터링하고 msdeploy에서 삭제 한 App_Offline.html을 확인합니다. 다음으로 위의 메시지와 함께 릴리스가 실패하고 App_Offline 파일이 여전히 폴더에 있습니다. 릴리스를 다시 시작합니다. 이번에는 모듈이 폴더의 파일을 볼 때 잘 작동합니다.

마지막 asp.net 코어 런타임 설치-> aspnetcore.dll 12.1.18263.2

어떤 아이디어? 아직도 버그?

@dhtek app_offline.htm 배치 한 후 즉시 파일을 교체하려고하면 서버가 아직 응용 프로그램을 종료 할 시간이 충분하지 않은 것입니다. 파일 교체를 시도하기 전에 잠시 기다려야합니다.

좋아, 이해하지만 msdeploy에서 -e nableRule : AppOffline 옵션을 사용하고 있으며 페이지가 자동으로 폴더에 드롭되고 동기화가 즉시 완료됩니다. 나는 아무것도하지 않는다.

이 문제도 여전히보고 있습니다. 내 프로젝트 파일은 Microsoft.NET.Sdk.Web 를 참조하지만 문서에 명시된대로 app_offline.htm 파일을 자동으로 삭제하지 않습니다.

안녕하세요. 이 성가신 문제는 최신 VS 2017이 설치된 Core 2.1에서 여전히 존재합니다. 저는 appoffline을 사용하지만 여전히 주 프로젝트 dll은 항상 사용 중이며 게시하는 동안 웹 사이트를 완전히 중지해야합니다. 이것은 웹 배포를 거의 쓸모 없게 만듭니다.

로드 밸런서 뒤에서 호스트를 오프라인으로 전환 할 수없고 더 빨리 수행하려는 경우 심볼릭 링크와 일부 powershell을 사용하는 한 가지 방법이 있습니다.
이런 식으로 생각하고 있었어요.

복사 + 재활용 중에 앱 풀을 중지 할 필요가 없으므로 더 빠릅니다. 현재 요청을 완료 할 수 있으므로 중단 시간이 줄어들 기 때문에 하드 중지보다 낫습니다.

# Setup
Import-Module WebAdministration
# create 2 site root directories
$a = 'C:\inetpub\AspNetCoreSampleA'
$b = 'C:\inetpub\AspNetCoreSampleB'
$siteRoot = 'C:\inetpub\aspnetcoresample'
$siteName = 'AspNetCoreSample'
$poolName = "aspnetcore"
New-Item -Type Directory $a
New-Item -Type Directory $b
# create a symlink to targeting one side
New-Item -Type SymbolicLink -Path $siteRoot -Target $a
# point the site root to the symlink
Set-ItemProperty "IIS:\Sites\$siteName" -name physicalPath -value $siteRoot
# make sure it get's picked up
Restart-WebAppPool -Name $poolName

# this tells you the active side
Get-Item -Path $siteRoot | Select-Object -ExpandProperty target

# Flip the symlink
$current = (Get-Item -Path $siteRoot).Target
$newTarget = if ($current -eq $a) {$b} else {$a}
New-Item -Type SymbolicLink -Path $siteRoot -Target $newTarget -Force
# at this point w3wp.exe still locks the current target folder until it's getting recycled
# Deploy new version to the symlink which is now pointing to the other side which should have no locks
robocopy \\myshare\myapp $siteRoot /mir
# recycle app pool, so it picks up the new files
Restart-WebAppPool -Name $poolName

# bonus point: rollback is easy
$current = (Get-Item -Path $siteRoot).Target
$newTarget = if ($current -eq $a) {$b} else {$a}
New-Item -Type SymbolicLink -Path $siteRoot -Target $newTarget -Force
Restart-WebAppPool -Name $poolName

요점은 다음과 같습니다.
https://gist.github.com/csharmath/b2af0f50700ce9fbdd8c5c3e582fd41b

Restart-WebAppPool은 기본적으로 재활용입니다. 이는 중첩 된 재활용을 활성화 한 경우 (기본값) 유용합니다. 새 w3wp.exe를 생성하고 현재 실행중인 프로세스가 완료되는 동안 모든 새 요청이 해당 새 프로세스에서 제공되기 때문입니다. 이전 w3wp.exe에 의해.
이렇게하면 이전 버전이 요청으로 완료 될 때까지 겹치며 새 버전을 가리키는 단일 w3wp.exe로 끝나고 잠금 문제가 없습니다.

이것은 섀도우 복사와 비슷하지만 훨씬 멋지고 매끄러운 xcopy 시나리오를 제공하므로 100 %는 아닙니다.

지금까지는 릴리스 중에 온라인 상태를 유지해야하는 경우 제가 생각할 수있는 최선의 방법 인 것 같습니다.

@csharmath 또는 내가 추측하는도

물론 그게 더 좋습니다. 한숨, 모든 장소가 아직 그런 것은 아닙니다.
나머지 구식 설정의 경우 가동 중지 시간이 없거나 최소화되지 않고 작동 할 때까지 야크를해야합니다.

@csharmath 동의했지만,이 시점에서 이것이 _years_ 동안 수정되지 않은 문제 였음을 감안할 때 기적을 기다리는 대신 작동하는 솔루션을 적용하고 추구하는 것이 좋습니다 ...

나는 아래의 파워 쉘 스크립트를 사용했으며 IIS가 충돌하고 다른 응용 프로그램 풀에도 영향을 미치고 모든 것을 되찾기 위해 컴퓨터를 다시 시작해야합니다 ...이 프로세스는 공식 문서에서 가져 왔으며 재앙이었습니다. 내 충고는 응용 프로그램 풀을 중지 스크립트를 사용하여 다시 시작하는 것이 좋습니다 DO NOT USE의 app_offline.htm이고, 하나는 내가이 스레드에서 발견 https://github.com/IsraelHikingMap/Site/blob/master/Scripts/Deploy .ps1

$pathToApp = 'G:\prod_web_core'
$pathToAppOfflineHtml = 'G:\prod_web_core\app_offline.htm'
# Stop the AppPool 
New-Item -Path $pathToApp -Name app_offline.htm
# Provide script commands here to deploy the app
Copy-Item "G:\prod_web_core_temp\*" -Destination $pathToApp -Recurse -Force
# Restart the AppPool 
Remove-Item -Path $pathToAppOfflineHtml
Get-ChildItem -Path "G:\prod_web_core_temp" -Recurse | Remove-Item -Force

배포 성공을 위해 AppPool을 강제로 중지해야합니다.이 문제를 해결하기위한 진행 상황이 있습니까?!

dotnet 코어가 우리에게 새로운 것이기 때문에 오늘 처음으로이 파일 잠금 문제가 발생했습니다. 나는 이것 때문에 정말로 경계를 잃었다. 베타 버전 (~ 2001)에있는 동안 Classic ASP에서 .Net Framework로 전환 한 가장 큰 이유는 파일 잠금없이 핫 배포를 수행 할 수 있기 때문입니다. 굉장했습니다! 거의 18 년이 지난 지금 저는 제가 시작한 곳으로 돌아 왔습니다. 오 글쎄요, 당신은 일부를 이기고 일부는 잃습니다.

방금 제 문제를 언급했습니다. 제 경우에는 Blazor 서버 측 솔루션을 배포합니다 ....
며칠 전에는 악몽이었습니다. app_offline.htm을 적용하고 앱 풀을 종료하고 전체 IIS 인스턴스를 다시 시작하여 파일 잠금을 해제했습니다. 다음 단계는 전체 서버를 다시 시작하는 것이 었습니다. 다행히 5 분 후에 .dll이 잠금 해제되었습니다.

2019 년, 저에게도 같은 문제입니다.이 문제는 2016 년에 만들어졌습니다 ... 아직 해결책이 없나요?

2020 년, 저에게도 같은 문제입니다. 역대 가장 큰 회귀. .Net 4.6은 dll 파일을 바꾸고 앱이 새 버전에서 다시로드됩니다. .Net 코어는 모든 것을 잠급니다.

@bladefist 오늘 가장 좋은 방법은 Docker 컨테이너를 사용하는 것입니다.

@kanadaj 감사하지만 Dockers는 처리해야 할 또 다른 골칫거리입니다. 결국 App_offline.htm을 사용하는 방법을 알아 낸 다음 잠시 기다렸다가 파일이 무료가되기를 바랍니다. 99 %의 시간 동안 기다려야합니다. 내 앱의 전원이 꺼지는 데 시간이 걸리는 것 같습니다.

dll을 복사하고 앱이 자동 재활용되는 .net 4.6의 시대는 지났습니다. 너무 간단하다고 생각합니다. 두 배로 실망스러운 것은 이것이 리눅스에서 문제가되지 않는다는 것입니다. Linux에서 사용중인 파일을 바꿀 수 있습니다.

물론 그렇다고 생각하지만 그 방법은 프로덕션 환경에서 그리 간단하지 않습니다. HA가 없으면 앱이 1 분 동안 응답하지 않고 HA를 사용하면로드 밸런서가 앱이 다운되었음을 알 때까지 임의의 잘못된 요청을 받게됩니다.로드 밸런서에서 호스트를 수동으로 순환하지 않는 한. 그러나 설정하는 데 더 많은 문제가있는 것 같습니다.

@kanadaj 그래, 우리는로드 밸런서를 사용하고 서버를 선형 적으로 업데이트합니다. 다운 타임이 없습니다.

우리는 성공했습니다

• 앱 디렉토리에 대한 심볼릭 링크 사용
• 새 버전의 사이트를 다른 디렉터리에 배포
• 심볼릭 링크 업데이트
• IIS와 함께 제공되는 appcmd 유틸리티를 사용하여 앱 풀을 다시 시작합니다.

@davidglassborow 는 창의적인 솔루션입니다. 감사. 하지만 창의적인 솔루션이 필요하지는 않습니다.

내 경험상 사이트가로드 상태 일 때 이전 메커니즘은 신뢰할 수 없었으며 트래픽이 많은 사이트에 대해 역방향 프록시를 사용하게되었습니다.

맞습니다. 인플레 이스 배포는 신뢰할 수 없거나 원자 적이 지 않았습니다. 운이 좋거나 트래픽이 많지 않으면 괜찮을 것입니다. 대부분의 불만이 이러한 시나리오에 관한 것이라고 가정하고 있습니다. .NET 5.0 시간 프레임에서 개선 사항을 살펴볼 것입니다. 몇 가지주의 사항 :

• 우리는 프레임 워크에 의존하는 애플리케이션을 더 좋게 만드는 방법을 살펴볼 것입니다. 독립형을 배포하면 운이 좋지 않습니다. 출력 폴더의 기본 및 관리 파일을 모두 잠급니다. 기본 dll 잠금 문제는 항상 존재 해 왔으며 우리가 어떤 완화 조치를 취하더라도 해결되지 않을 것입니다.
• 우리는 응용 프로그램 어셈블리를 디스크에서로드하고 파일을 잠그는 대신 바이트로 메모리에로드하는 방법을 살펴볼 계획입니다. 이것은 대부분의 경우 괜찮지 만 경우에 따라 더 많은 메모리를 사용할 수 있습니다.
• 애플리케이션을 재활용하려면 여전히 appoffline 파일을 추가하고 제거해야합니다. appoffline 파일을 추가하는 것은 배포의 결과로 애플리케이션을 다시 시작하기를 원한다는 신호를 보내는 방법입니다.

@davidfowl 5.0에 대해 설명한 계획은 훌륭합니다. 우리는 대부분의 경우 프레임 워크에 따라 달라집니다.

현재 위치 배포의 안정성에 대해 정중히 동의하지 않습니다. 나는 매우 높은 부하를 가진 사이트에서 수년간 그것을 해왔고 한 번도 문제가 없었습니다. 처음 감지 된 변경으로 인해 앱이 재설정되고,로드 밸런서는 인스턴스가 응답하지 않는 것을 확인하고, 오프라인으로 전환하고, 모든 DLL이 교체되면로드 밸런서가 상태 확인을 완료하고 다시 온라인 상태가됩니다. 이제로드 밸런서 상태 확인이 없으면 도박입니다.하지만 프록시없이 프로덕션 환경에서 DLL을 대체하는 사람은 누구입니까? 예외가 아닌 규칙에 초점을 맞 춥니 다. 프록시가 없으면 중단없이 앱을 업데이트 할 방법을 생각할 수 없습니다. 핫 리로딩을 지원하더라도 일부 요청은 중단되거나 실패 할 수 있습니다.

현재 위치 배포의 안정성에 대해 정중히 동의하지 않습니다. 나는 매우 높은 부하를 가진 사이트에서 수년간 그것을 해왔고 한 번도 문제가 없었습니다. 처음 감지 된 변경으로 인해 앱이 재설정되고,로드 밸런서는 인스턴스가 응답하지 않는 것을 확인하고, 오프라인으로 전환하고, 모든 DLL이 교체되면로드 밸런서가 상태 확인을 완료하고 다시 온라인 상태가됩니다. 이제로드 밸런서 상태 확인이 없으면 도박입니다.하지만 프록시없이 프로덕션 환경에서 DLL을 대체하는 사람은 누구입니까? 예외가 아닌 규칙에 초점을 맞 춥니 다. 프록시가 없으면 중단없이 앱을 업데이트 할 방법을 생각할 수 없습니다. 핫 리로딩을 지원하더라도 일부 요청은 중단되거나 실패 할 수 있습니다.

로드 밸런서가 있습니다. 많은 사람들이로드 밸런서를 가지고 있지 않고 디스크의 파일을 제자리에 놓고 마법을 기대하고 있습니다 😄

@davidfowl 맞지만 높은 트래픽 + 파운드 없음 = 무모함

또한 app_offline.htm의 문제는 ci / cd 프로세스에서 프로세스가 언제 중지되는지 알 수 없다는 것입니다. 종료 프로세스가 1 분에서 1 분까지 걸릴 수 있기 때문에 해당 파일을 만들고 DLL을 푸시하는 사이에 엄청난 절전 명령을 추가해야했습니다. 수많은 인스턴스를로드 밸런싱 할 때 이러한 휴면이 추가되어 배포주기가 매우 길어집니다.

메모리에 파일을로드하면 모든 문제가 해결됩니다.

@davidfowl 맞지만 높은 트래픽 + 파운드 없음 = 무모함

👍

또한 app_offline.htm의 문제는 ci / cd 프로세스에서 프로세스가 언제 중지되는지 알 수 없다는 것입니다. 종료 프로세스가 1 분에서 1 분까지 걸릴 수 있기 때문에 해당 파일을 만들고 DLL을 푸시하는 사이에 엄청난 절전 명령을 추가해야했습니다. 수많은 인스턴스를로드 밸런싱 할 때 이러한 휴면이 추가되어 배포주기가 매우 길어집니다.

맞습니다. 따라서 문제는 해당 파일을 삭제해도 ANCM에서 알림을받을 때까지 파일이 여전히 잠겨 있기 때문에 배포를 시작해도되는지 알려주지 않는다는 것입니다.

또한 app_offline.htm의 문제는 ci / cd 프로세스에서 프로세스가 언제 중지되는지 알 수 없다는 것입니다.

맞습니다. VS 게시자는 짧은 절전 모드와 여러 번의 재 시도를 사용합니다.

• 애플리케이션을 재활용하려면 여전히 appoffline 파일을 추가하고 제거해야합니다. appoffline 파일을 추가하는 것은 배포의 결과로 애플리케이션을 다시 시작하기를 원한다는 신호를 보내는 방법입니다.

나중에 appoffline 파일을 삭제하지 않고도 재활용 할 앱을 표시하는 "apprestart"파일을 가질 수 있습니까?

@Socolin 왜

@Socolin 왜

내가 잘 이해한다면 (내가 틀렸다면 알려주세요) 잠금을 제거하는 것이 계획이지만 빌드가 완료된 후 IIS에 앱을 재활용하도록 알리기 위해 appoffline을 만들어야합니까?

이렇게하려면 appoffline 파일을 만든 다음 삭제해야합니다. 파일이 생성 된 직후이 파일을 삭제할 수 있습니까? 아니면 IIS가 감지 할 때까지 기다려야합니까? 조금만 기다려야한다면 IIS가 수신 할 "apprestart"와 같은 파일을 선호합니다. 그런 다음 감지되면 삭제하고 재활용을 시작합니다.

또 다른 질문이 있습니다. 빌드 중 IDE 최적화에 관한 것입니다.

현재 저는 종속성을 사용하는 프로젝트에서 작업하고 있으며 웹 레이어 용 프로젝트와 로직 및 데이터 용 다른 프로젝트가 있습니다. 빌드하는 동안 웹 레이어 (ASP.NET Core)에서 작업 할 때 빌드 전에 appoffline 파일을 만든 다음 빌드 후에 삭제하면 작동합니다.

그러나 종속성 중 하나에서 작업 할 때 Rider에서 빌드 할 때 (msbuild를 사용하고 있기 때문에 VS에서 동일한 작업을 수행한다고 생각합니다) msbuild가 수행하는 작업을 볼 때 프로젝트 빌드가 완료되면 .dll은 .Web 프로젝트를 다시 빌드하지 않고 .Web / bin 디렉터리에 직접 복사됩니다. 그리고 dll이 잠겨 있기 때문에 자동으로 실패하고 서버를 수동으로 다시 시작하거나 .Web 프로젝트 빌드를 수동으로 트리거해야합니다.

이것에 대한 해결책이 있습니까?
지금까지 내가 찾은 해결 방법은 내 .Web 프로젝트의 / bin을 찾는 백그라운드에서 실행되는 작은 프로그램을 작성하는 것입니다. 파일이 변경되면 IIS가 수신하는 디렉토리에 appoffline 파일을 생성 한 다음 수정 된 파일을 복사 한 다음 appoffline을 삭제합니다. 하지만 약간 엉망인 것 같지만 지금까지는 빌드 할 수있는 유일한 방법 인 다음 F5 키를 누르고 변경 사항을 테스트합니다.

이렇게하려면 appoffline 파일을 만든 다음 삭제해야합니다. 파일이 생성 된 직후이 파일을 삭제할 수 있습니까? 아니면 IIS가 감지 할 때까지 기다려야합니까? 조금만 기다려야한다면 IIS가 수신 할 "apprestart"와 같은 파일을 선호합니다. 그런 다음 감지되면 삭제하고 재활용을 시작합니다.

IIS는 파일 복사가 끝났음을 어떻게 알 수 있습니까? 찢어진 상태를 어떻게 피합니까? 기본적으로 거래의 시작과 완료를 알리는 신호가 필요합니다. 파일의 생성은 시작 신호를 보내고 삭제는 끝 신호를 보냅니다.

이것에 대한 해결책이 있습니까?
지금까지 내가 찾은 해결 방법은 내 .Web 프로젝트의 / bin을 찾는 백그라운드에서 실행되는 작은 프로그램을 작성하는 것입니다. 파일이 변경되면 IIS가 수신하는 디렉토리에 appoffline 파일을 생성 한 다음 수정 된 파일을 복사 한 다음 appoffline을 삭제합니다. 하지만 약간 엉망인 것 같지만 지금까지는 빌드 할 수있는 유일한 방법 인 다음 F5 키를 누르고 변경 사항을 테스트합니다.

VS는 해당 프로젝트의 빌드에 영향을 미칠 수있는 모든 것에 대해 새 파일을 시작하기 전에 프로세스를 종료하여이를 처리합니다.

이렇게하려면 appoffline 파일을 만든 다음 삭제해야합니다. 파일이 생성 된 직후이 파일을 삭제할 수 있습니까? 아니면 IIS가 감지 할 때까지 기다려야합니까? 조금만 기다려야한다면 IIS가 수신 할 "apprestart"와 같은 파일을 선호합니다. 그런 다음 감지되면 삭제하고 재활용을 시작합니다.

IIS는 파일 복사가 끝났음을 어떻게 알 수 있습니까? 찢어진 상태를 어떻게 피합니까? 기본적으로 거래의 시작과 완료를 알리는 신호가 필요합니다. 파일의 생성은 시작 신호를 보내고 삭제는 끝 신호를 보냅니다.

잠금이없는 경우 빌드가 시작될 때 IIS에 알리는 이유는 무엇입니까? 모든 파일이 업데이트되고 응용 프로그램을 재활용해야 할 때 신호를 보낼 수 없습니까? 뭔가 오해 한 것 같아요.

잠금이없는 경우 빌드가 시작될 때 IIS에 알리는 이유는 무엇입니까? 모든 파일이 업데이트되고 응용 프로그램을 재활용해야 할 때 신호를 보낼 수 없습니까? 뭔가 오해 한 것 같아요.

예, 작동합니다. 나는 당신이 현재의 예술 상태를 설명하고 있다고 생각했습니다. 오늘날 web.config를 사용하여이 작업을 수행 할 수도 있습니다. 파일을 터치하면 애플리케이션이 재부팅됩니다.

다음을 통해 인플레 이스 배포 (https://flukefan.github.io/ZipDeploy/)를 성공적으로 수행했습니다.

1. 어셈블리 파일 이름 바꾸기 (삭제 / 덮어 쓸 수 없더라도 이름을 바꿀 수 있음)
2. 새 어셈블리를 복사하십시오.
3. 웹 구성을 터치하여 앱을 다시 시작하십시오.
4. 이름이 변경된 이전 어셈블리를 삭제합니다.

로드 밸런싱 없음; 단일 IIS 인스턴스; IIS 변경 사항이 없습니다. YMMV.

@FlukeFan 찢어진 배포를 어떻게 방지합니까? 아니면 걱정하지 않습니까? 조각난 것은 애플리케이션을 다시 시작하기 전에 이전 앱이 새 어셈블리를로드하는 창이 있다는 것을 의미합니다.

모든 어셈블리의 이름이 변경 / 업데이트 될 때까지 web.config를 건드리지 않습니다. 그 시간 동안 다른 무언가로 인해 앱 풀이 재활용 될 가능성은 적지 만 아직 발생하지 않았습니다.

일반적으로 다른 모든 자동 재활용 옵션을 끄고 IIS 앱 풀 설정에서 중복 된 재활용을 비활성화합니다.

@FlukeFan 은 재활용이 아니지만 아직 교체 된 어셈블리를로드하지 않은 경우. 예를 들어, 어셈블리 A.dll 및 B.dll이 있다고 가정합니다. 설정 페이지로 이동할 때 B가 사용되어로드되었다고 가정 해 보겠습니다. B.dll이 새 것으로 교체되었을 때 설정 페이지로 이동하면 새 B.dll로 실행되는 이전 앱이 끝날 수 있습니다.

이러한 유형의 배포를 지원하기 위해 dotnet 글로벌 도구를 만들어야하는지 궁금합니다. 이 도구는 기본적으로 사람들이이 스레드에서 언급 한 모든 어려운 작업을 수행 할 수 있습니다.

생각?

@FlukeFan 은 재활용이 아니지만 아직 교체 된 어셈블리를로드하지 않은 경우. 예를 들어, 어셈블리 A.dll 및 B.dll이 있다고 가정합니다. 설정 페이지로 이동할 때 B가 사용되어로드되었다고 가정 해 보겠습니다. B.dll이 새 것으로 교체되었을 때 설정 페이지로 이동하면 새 B.dll로 실행되는 이전 앱이 끝날 수 있습니다.

그래서 지금은 그 사건을 처리하지 않습니다. https://github.com/FlukeFan/ZipDeploy/blob/master/ZipDeploy/ZipDeploy.cs#L55

다른 순서로 작업을 수행하고 web.config를 먼저 터치하고 모든 '다른'요청이 완료되기를 기다린 다음 마지막으로 마지막 요청이 완료되기 직전에 교체를 수행 할 수 있습니다 (IIS가 약에 대한 새 요청을 대기열에 넣는 동안). recycle app-pool), 그러나 내가 가진 것은 지금 저에게 효과적입니다.

현재 설명하고있는 시나리오에 대해서는 충분히 견고하지 않을 것입니다 (하지만 시작 시간 외에는 동적 어셈블리로드에 대해 멋진 작업을 수행하지 않았습니다).

이 기능을 다시 방문하여 로드맵에 올릴 계획이 있습니까? 다운 타임없는 배포를 지원하려는 경우 .Net Core 웹 사이트를 배포하는 모든 사람이 스테이징 슬롯 전략을 수동으로 구현하도록 요구하는 것은 매우 불편하고 비우호적입니다.

이 기능을 사용하면 많은 사람들이 .Net Core 웹 사이트로 훨씬 원활하게 전환 할 수 있으며 .Net Core 웹 사이트를 더 빠르게 채택 할 수 있습니다.

나는 그것을 생각하지 못했습니다. 그러나 당신은 머리에 못을 박았을 것입니다. 이것은 사람들이 하늘빛 슬롯을 사용하도록 강요하는 사악한 비즈니스 결정일 수 있습니다. 과거에 가능하다면 지금 "고치는"데 왜 그렇게 오래 걸렸습니까? 그것이 무엇을 염두에두고 있는지 비즈니스 관점에서 깨지지 않았습니다. 내가 좀 냉소적일지도 몰라. 하지만 이전에는 무료로 제공되어 더 비싼 계층으로 이동 한 푸른 색 기능을 천천히 지켜 봤습니다.

이러한 유형의 배포를 지원하기 위해 dotnet 글로벌 도구를 만들어야하는지 궁금합니다. 이 도구는 기본적으로 사람들이이 스레드에서 언급 한 모든 어려운 작업을 수행 할 수 있습니다.

생각?

이것은 CI 서버에서 실행하는 것입니다. 바이너리 / 패키지를 대상 서버로 어떻게 푸시합니까?

나는 그것을 생각하지 못했습니다. 그러나 당신은 머리에 못을 박았을 것입니다. 이것은 사람들이 하늘빛 슬롯을 사용하도록 강요하는 사악한 비즈니스 결정일 수 있습니다. 과거에 가능하다면 지금 "고치는"데 왜 그렇게 오래 걸렸습니까? 그것이 무엇을 염두에두고 있는지 비즈니스 관점에서 깨지지 않았습니다. 내가 좀 냉소적일지도 몰라. 하지만 이전에는 무료로 제공되어 더 비싼 계층으로 이동 한 푸른 색 기능을 천천히 지켜 봤습니다.

조정이없는 제자리 배포는 위에서 언급 한 이유로 근본적으로 신뢰할 수 없습니다. 이 기능은 역사적으로 신뢰할 수 없었고 .NET 프레임 워크의 ASP.NET에서 많은 문제를 야기했기 때문에 섀도 복사를 다시 구현하지 않을 것입니다. 또한 모든 .NET Framework가 지원되는 특정 유형의 배포, 프레임 워크에 따라 작동합니다. .NET core는 자체 포함 된 단일 파일을 지원하므로 지원하기가 훨씬 더 어렵습니다. 위의 제안조차도 이러한 경우를 다루지 않습니다.

우리는 여전히 인플레 이스 배포가 가능한 한 원자 적이어야한다고 믿고 있으며,이 문제에 대한 많은 문제는 버그와 app_offline 감지 및 재활용의 비 신뢰성에서 비롯되었으므로이를 수정하는 데 많은 시간을 보냈습니다 (및 pdb 잠금도 포함).

웹 배포는 배포하는 것이 합리적이라고 생각하는 흐름을 구현하는 유일한 도구이지만 해당 기술에 갇혀 있으므로 서버에 ftp를 배포하거나 파일 공유에 복사하는 경우에는 도움이되지 않습니다. 할 수 있었다).

여기서 dotnet 글로벌 도구가 답이 될 수 있습니다.

이것은 CI 서버에서 실행하는 것입니다. 바이너리 / 패키지를 대상 서버로 어떻게 푸시합니까?

나는 그렇게 생각하지 않는다. 아마도 FTP와 직접 복사를 지원할 것입니다. 그 이외의 것은 독점 프로토콜 일 가능성이 높습니다.

FTP를 말할 때 ssh를 통한 ftp도 의미하기를 바랍니다. 그러한 도구는 매우 가치가있을 것입니다.

FTP를 말할 때 ssh를 통한 ftp도 의미하기를 바랍니다. 그러한 도구는 매우 가치가있을 것입니다.

아니 나는 ftp를 의미했다. 그러나 우리는 이치에 맞는 모든 것을 할 것입니다. 대상 컴퓨터에서 실행해야하는 복사 도구 인 것이 가장 좋습니다. 그것은 우리를 어디로 든 비트를 보내야하는 사업에서 벗어나게합니다.

또한 IIS에 배포하기 위해 Windows 시스템에 SSH를 사용하고 있습니까?

@davidfowl 배포 슬롯에 대한 지원을 추가 (옵트 인)하십시오.
https://github.com/dotnet/aspnetcore/issues/3719#issuecomment -473183712
https://github.com/dotnet/aspnetcore/issues/3793#issuecomment -335666414

우리는 응용 프로그램 어셈블리를 디스크에서로드하고 파일을 잠그는 대신 바이트로 메모리에로드하는 방법을 살펴볼 계획입니다. 이것은 대부분의 경우에 문제가 없지만 경우 에 따라 더 많은 메모리를 사용할 수 있습니다 .

더군다나 이는 다운 타임을 제로로 만들 수 없습니다.

모듈로 이와 같은 기능에 투자 할 방법은 없습니다.

FTP를 말할 때 ssh를 통한 ftp도 의미하기를 바랍니다. 그러한 도구는 매우 가치가있을 것입니다.

아니 나는 ftp를 의미했다. 그러나 우리는 이치에 맞는 모든 것을 할 것입니다. 대상 컴퓨터에서 실행해야하는 복사 도구 인 것이 가장 좋습니다. 그것은 우리를 어디로 든 비트를 보내야하는 사업에서 벗어나게합니다.

또한 IIS에 배포하기 위해 Windows 시스템에 SSH를 사용하고 있습니까?

예. CI / CD를 사용하고 Linux와 Windows 시스템 모두에 배포하므로 Windows 상자에 openssh를 설치하는 것이 훨씬 쉬웠습니다.

$ appPool = '기본값'
Stop-WebAppPool-이름 $ appPool -Passthru
... 배포 ...

Start-WebAppPool-이름 $ appPool -Passthru
... 배포 .....

또는

$ appPool = '기본값'
중지 -WebAppPool-이름 $ appPool
while ((Get-WebAppPoolState -Name $ appPool) .Value -ne '중지') {
수면 1 # 초
}
... 배포 ...

Start-WebAppPool-이름 $ appPool
while ((Get-WebAppPoolState -Name $ appPool) .Value -ne '시작') {
수면 1 # 초
}

... 배포 .....

가난한 사람의 배포 슬롯
약 1 년 전에 사이트 루트 폴더 2 개를 만드는 방법에 대해 게시했으며 그 중 하나에 대한 심볼릭 링크가 IIS 사이트 용으로 구성되었습니다.
장점은 다른 간단한 솔루션에 비해 다운 타임이 적다는 것입니다.
중복 재활용이 활성화 된 경우 다운 타임이 없으며 어쨌든 첫 번째 요청에 대한 워밍업 패널티 만 발생합니다.

배포 / 복사 작업이 완료되는 데 N 초가 소요되는 경우 N 초 동안 앱 풀을 중지 할 필요가 없습니다.
오프라인에서 의심스러운 앱을 망칠 필요가 없습니다.
비활성 폴더에 복사하고 파일이있을 때 심볼릭 링크를 교체 한 다음 앱 풀을 재활용하십시오.
원자 배포, 다운 타임없이 평소처럼 첫 번째 요청이 느려집니다.

https://github.com/dotnet/aspnetcore/issues/3793#issuecomment -459870870

누구 시도 했어?
이와 같은 것이 작동하면 클라이언트 측 배포 도구를 사용하여 서비스로 전환 할 수 있습니다.

• 클라이언트-> 서버 비활성 폴더 / 공유 란 무엇입니까?
• S : 여기
• C : 배포 / 복사 확인
• S : 심볼릭 링크 교체 및 재활용
• C : thx, http get / healthcheck (선택 사항)
• C : 어, 엉망진창, 롤백 pls
• S : 심볼릭 링크 스왑, 재활용 (재업)
• C : 작업 할 때까지 반복 헹구기

따라서 배포 잠금 파일에도 문제가 있습니다. 앱 호스팅에서. 앱 풀을 중지하려고했지만 파일이 잠겨 있습니다. 나는 app_offline.htm을 밀려 고 시도했지만 거기에서도 운이 없다.
또한 app_offline.htm 파일 삭제를 관리하려면 program.cs에서 앱을 시작할 때 쉽게 할 수 있습니다. 이렇게하면 언제 온라인 상태가되는지 알 수 있습니다.

내가 직면 한 현재 문제는 dll이 중단되고 이름을 바꾼 다음 파일을 복사하더라도 이름이 바뀐 파일에 대해 이전 프로세스가 여전히 실행된다는 것입니다. 따라서 배포를 다시 시도하면 파일 이름을 다시 변경해야합니다. 나는 우리가 파일 이름 대체로 일종의 날짜를 사용할 수 있다고 생각합니다.
IIS 서버 Windows 2012 R2에서이를 위해 dotnet core 3.1.4를 사용하고 있습니다.

@foxjazz 앱 풀 / 프로세스가 중지 되어도 파일은 어떻게 잠기나요? 자세히 설명해 주시겠습니까?

@foxjazz 앱 풀 / 프로세스가 중지 되어도 파일은 어떻게 잠기나요? 자세히 설명해 주시겠습니까?

사용한 dll을 삭제하려고 할 때 그림에 다른 프로세스에서 사용 중이라고 표시됩니다.
앱 풀이 한동안 오프라인 상태였습니다.

프로세스가 여전히 실행 중인지 확인하려면 작업 관리자를 확인하십시오. 중지 버튼을 눌렀다 고해서 즉시 종료되는 것은 아닙니다.

프로세스가 여전히 실행 중인지 확인하려면 작업 관리자를 확인하십시오. 중지 버튼을 눌렀다 고해서 즉시 종료되는 것은 아닙니다.

위의 사진은 작업 관리자에서 가져온 것입니다. 어느 파일인지 확실하지 않지만 삭제하면 파일이 해제됩니다. 핸들을 사용하여 종료 할 pid를 알아낼 수 있다고 생각합니다. 배포를 위해 이러한 길이로 갈 필요가 없다고 생각했습니다. 핸들은 w3wp.exe 2 프로세스에 파일 중 하나가 잠겨 있다고 말합니다. 앱 풀이 종료 된 경우에도 마찬가지입니다.

정말 좋은 것은 프로세스를 중지하는 경로를 갖는 것입니다.
api \ KillDeathKill
{
Program.KillProcess ()
}

그럴 것 같지 않습니다. 프로세스에 의해 파일이 잠겼습니다. w3wp가 해당 프로세스이면 시작하기 위해 절대로 죽지 않았거나 동일한 파일을 다른 pid로 잠그는 새 것이 시작되었습니다. 그렇기 때문에 파일을 잠그고, 기존 프로세스를 종료하고, 새 비트를 배포하고, 앱을 오프라인으로 제거하는 새로운 프로세스가 없는지 확인하기 위해 먼저 앱 오프라인이 다운되었는지 확인해야합니다.

그럴 것 같지 않습니다. 프로세스에 의해 파일이 잠겼습니다. w3wp가 해당 프로세스이면 시작하기 위해 절대로 죽지 않았거나 동일한 파일을 다른 pid로 잠그는 새 것이 시작되었습니다. 그렇기 때문에 파일을 잠그고, 기존 프로세스를 종료하고, 새 비트를 배포하고, 앱을 오프라인으로 제거하는 새로운 프로세스가 없는지 확인하기 위해 먼저 앱 오프라인이 다운되었는지 확인해야합니다.

app_offline.htm이 먼저 다운되었다고 말할 때. 네, 그렇습니다. get 요청을 통해 확인할 수있는 상태 경로가 있으며 확실히 오프라인 상태입니다. 또한 앱 풀을 수동으로 중지했습니다. 그러나 w3wp 프로세스는 여전히 파일을 중단했습니다.

그런 다음 프로세스가 중지되지 않았습니다.

그런 다음 프로세스가 중지되지 않았습니다.

그렇다면 프로세스를 중지하는 것이 아니라 앱 풀을 중지하는 이유는 무엇입니까?

앱 풀은 프로세스를 나타내며 앱 풀을 중지하면 프로세스가 중단됩니다. 파일을 잠글 프로세스가 없으면 파일을 잠글 수 없으므로 다른 이론 중 하나가 더 가능성이있는 것처럼 보입니다.

앱 풀은 프로세스를 나타내며 앱 풀을 중지하면 프로세스가 중단됩니다. 파일을 잠글 프로세스가 없으면 파일을 잠글 수 없으므로 다른 이론 중 하나가 더 가능성이있는 것처럼 보입니다.

하, 당신은 똥을 말했다. 내가 당신을 괴롭히는 것처럼 보이려는 뜻은 아닙니다. 나는 앱 풀을 중지하는 것이 모든 문서에서 광고 된대로 작동하지 않는다고 말하고 있습니다. 이 과정은 90 초 후에도 엉망이되지 않고 여전히 실행 중입니다. 앱 풀이 중지 된 것을 명확하게 볼 수 있어도 파일이 잠 깁니다. 이 프로세스에는 일부 데이터를 얻기위한 단일 항목이 포함됩니다. 그리고 다른 컨트롤러. 잠긴 파일을 기반으로 프로세스를 종료하는 스크립트가 있으면 좋을 것입니다. 그런 다음 두려움없이 배치 할 수 있습니다. 이름 바꾸기도 작동 할 수 있습니다. 파일 이름을 바꿀 수 있습니다. (dotnet core 3.1.4) 맛

약 1 년 전에 사이트 루트 폴더 2 개를 만드는 방법에 대해 게시했으며 그 중 하나에 대한 심볼릭 링크가 IIS 사이트 용으로 구성되었습니다.

누구 시도 했어?
이와 같은 것이 작동하면 클라이언트 측 배포 도구를 사용하여 서비스로 전환 할 수 있습니다.

@CJHarmath- 나는 이것을 시도했고 아래에서 사용하는 수정 된 코드를 가지고 있습니다. 아주 잘 작동합니다, 감사합니다!

업데이트를 더 많이 게시하면 클라이언트 배포 도구를 고려할 수 있지만 실제로는 IIS 서버에 원격 셸을 적용하고 powershell 스크립트를 실행하여 뒤집을 수 있습니다.
psexec.exe \\IIS_SERVER cmd /c "powershell -noninteractive -file C:\FlipSymLink.ps1"

# FlipSymLink.ps1

Import-Module WebAdministration # run as admin
# create 2 site root directories
$a = 'C:\Websites\MySiteA'
$b = 'C:\Websites\MySiteB'
$appRoot  = 'C:\Websites\MySite'
$appName  = 'MyAppName'
$siteName = 'MySiteName'
$poolName = "MyPoolName"
New-Item -Type Directory $a -ErrorAction SilentlyContinue
New-Item -Type Directory $b -ErrorAction SilentlyContinue

# create a symlink to targeting one side
New-Item -Type SymbolicLink -Path $appRoot -Target $a -Name A -ErrorAction SilentlyContinue
New-Item -Type SymbolicLink -Path $appRoot -Target $b -Name B -ErrorAction SilentlyContinue

# point the site root to the symlink
$currentPath = (Get-ItemProperty "IIS:\Sites\$siteName\$appName" -name physicalPath)
if ($currentPath -eq "$appRoot\A") {
    Write-Host "Switched to B"
    New-Item $b\active.txt
    Remove-Item $a\active.txt
    Set-ItemProperty "IIS:\Sites\$siteName\$appName" -name physicalPath -value $appRoot\B
} else {
    Write-Host "Switched to A"
    New-Item $a\active.txt
    Remove-Item $b\active.txt
    Set-ItemProperty "IIS:\Sites\$siteName\$appName" -name physicalPath -value $appRoot\A
}
Restart-WebAppPool -Name $poolName

psexec.exe \\IIS_SERVER cmd /c "powershell -noninteractive -file C:\FlipSymLink.ps1"

이것은 또한 JEA 엔드 포인트 로 전환 될 수 있으므로 flip 를 권한이없는 사용자로 실행할 수 있습니다 (예 : CI / CD 서버 배포 단계에서)
Invoke-Command -ComputerName IIS_SERVER -ConfigurationName IIS-Flip -ScriptBlock { Switch-SymlinkTarget -SiteName MySite}
승인 된 동사이므로 Flip 대신 Switch 사용했습니다.

승인 된 동사이므로 Flip 대신 Switch 사용했습니다.

Swap 는 슬롯을 다룰 때 사용되는 동사입니다. 여기서 재사용하는 것이 합리적일까요?

4 년 전에 설명한 것과 같은 문제가 있습니다.
이것에 대한 업데이트가 있습니까?
새 dll 파일을 업로드하기 위해 원격 데스크톱을 열고 싶지 않습니다.

프로덕션 IIS 서버에서 FTP를 사용하여 .NET Core 애플리케이션 DLL 파일을 덮어 쓰려고하면 파일이 잠겨있어 덮어 쓸 수 없습니다.

새 버전을 배포하려면 IIS (RDP 열기)에서 응용 프로그램을 중지하여 잠금을 해제 한 다음 덮어 써야합니다.
응용 프로그램을 중지하지 않고 배포 할 수 없습니다.

이것에 대한 해결책이 있습니까? 감사

로드 밸런서 뒤에서 호스트를 오프라인으로 전환 할 수없고 더 빨리 수행하려는 경우 심볼릭 링크와 일부 powershell을 사용하는 한 가지 방법이 있습니다.
이런 식으로 생각하고 있었어요.

복사 + 재활용 중에 앱 풀을 중지 할 필요가 없으므로 더 빠릅니다. 현재 요청을 완료 할 수 있으므로 중단 시간이 줄어들 기 때문에 하드 중지보다 낫습니다.

# Setup
Import-Module WebAdministration
# create 2 site root directories
$a = 'C:\inetpub\AspNetCoreSampleA'
$b = 'C:\inetpub\AspNetCoreSampleB'
$siteRoot = 'C:\inetpub\aspnetcoresample'
$siteName = 'AspNetCoreSample'
$poolName = "aspnetcore"
New-Item -Type Directory $a
New-Item -Type Directory $b
# create a symlink to targeting one side
New-Item -Type SymbolicLink -Path $siteRoot -Target $a
# point the site root to the symlink
Set-ItemProperty "IIS:\Sites\$siteName" -name physicalPath -value $siteRoot
# make sure it get's picked up
Restart-WebAppPool -Name $poolName

# this tells you the active side
Get-Item -Path $siteRoot | Select-Object -ExpandProperty target

# Flip the symlink
$current = (Get-Item -Path $siteRoot).Target
$newTarget = if ($current -eq $a) {$b} else {$a}
New-Item -Type SymbolicLink -Path $siteRoot -Target $newTarget -Force
# at this point w3wp.exe still locks the current target folder until it's getting recycled
# Deploy new version to the symlink which is now pointing to the other side which should have no locks
robocopy \\myshare\myapp $siteRoot /mir
# recycle app pool, so it picks up the new files
Restart-WebAppPool -Name $poolName

# bonus point: rollback is easy
$current = (Get-Item -Path $siteRoot).Target
$newTarget = if ($current -eq $a) {$b} else {$a}
New-Item -Type SymbolicLink -Path $siteRoot -Target $newTarget -Force
Restart-WebAppPool -Name $poolName

요점은 다음과 같습니다.
https://gist.github.com/csharmath/b2af0f50700ce9fbdd8c5c3e582fd41b

여기 제가 꼬임이 해결되었다고 생각하는 것이 있습니다. ASP.NET으로 만 시도했지만 net core 용 호스팅 모듈에서도 동일하게 작동 할 것이라고 생각합니다. 첫 번째 실행은 사이트를 잠시 중단하므로 약간 조정하는 것이 좋습니다.

param(
    [Parameter(Mandatory = $true)]
    [string] $iisRootPath,
    [Parameter(Mandatory = $true)]
    [string] $siteName,
    [Parameter(Mandatory = $true)]
    [string] $artifactPath,
    [Parameter(Mandatory = $false)]
    [string] $siteFolderName,
    [Parameter(Mandatory = $false)]
    [string] $appPoolName
)
Import-Module WebAdministration

#populate optional parameters
if (!($PSBoundParameters.ContainsKey('siteFolderName'))) { $siteFolderName = $siteName }
if (!($PSBoundParameters.ContainsKey('appPoolName'))) { $appPoolName = $siteName }

#set A, B and C paths
$a = "$iisRootPath\$siteFolderName" + 'A'
$b = "$iisRootPath\$siteFolderName" + 'B'
$c = "$iisRootPath\$siteFolderName"

#existence test
$cName = Get-Item -Path $c -ErrorAction SilentlyContinue | Select-Object -ExpandProperty name -ErrorAction SilentlyContinue
$bName = Get-Item -Path $b -ErrorAction SilentlyContinue | Select-Object -ExpandProperty name -ErrorAction SilentlyContinue

#get the shudown timeout for the app pool
$shutdownTimeout = Get-WebConfigurationProperty -Filter 'system.web/httpRuntime' -PSPath "IIS:\Sites\$siteName" -Name shutdownTimeout | Select-Object -ExpandProperty Value

#create symlink, if symlink source is an existing directory, rename existing 
if($cName -eq $null) 
{
    Write-Output "Creating SymbolicLink $c -> $a" 
    New-Item -Type SymbolicLink -Path $c -Target $a
} 
else
{
    #directories don't have a target property
    $cTarget = Get-Item -Path $c | Select-Object -ExpandProperty target -ErrorAction SilentlyContinue

    #this is a directory, rename and create symlink
    if($cTarget -eq $null)
    {
        #restart AppPool first so no locked files
        #Write-Output "Restarting AppPool $appPoolName" 
        #Restart-WebAppPool -Name $appPoolName

        #stop AppPool first so no locked files
        Write-Output "Stopping AppPool $appPoolName" 
        Stop-WebAppPool -Name $appPoolName

        #sleep for shutdownTimeout
        Write-Output "Sleeping for $shutdownTimeout" 
        Start-Sleep -Seconds (([System.TimeSpan]::Parse("$shutdownTimeout").TotalSeconds) * 1.1)

        try {
             #if the rename fails, there are files in use. stop the script
            $newName = $siteFolderName + 'A'
            Write-Output "Renaming $c to $newName" 
            Rename-Item -Path $c -NewName $newName -ErrorAction Stop
        }
        catch {
            Write-Error -Message "Failed to rename $c to $newName due to files in use."

            #start AppPool 
            Write-Output "Starting AppPool $appPoolName due to failed folder rename. Consider trying again durring a time with reduced traffic." 
            Start-WebAppPool -Name $appPoolName

        }

        #create symlink
        Write-Output "Creating SymbolicLink $c -> $a" 
        New-Item -Type SymbolicLink -Path $c -Target $a

        #start AppPool 
        Write-Output "Starting AppPool $appPoolName" 
        Start-WebAppPool -Name $appPoolName

        #copy a to b to pick up directory permissions
        if($bName -eq $null) 
        {
            Write-Output "Copying Directory $a to $b"  
            robocopy $a $b /e /sec /sl
        }
    }
}

#existence test
$aName = Get-Item -Path $a -ErrorAction SilentlyContinue | Select-Object -ExpandProperty name -ErrorAction SilentlyContinue
$bName = Get-Item -Path $b -ErrorAction SilentlyContinue | Select-Object -ExpandProperty name -ErrorAction SilentlyContinue

#create if needed
if($aName -eq $null) 
{
    Write-Output "Creating Directory $a"  
    New-Item -Type Directory $a 
}
if($bName -eq $null) 
{
    Write-Output "Creating Directory $b"  
    New-Item -Type Directory $b 
}

#make sure site pointing to symlink
Write-Output "Pointing Website $siteName to Path $c" 
Set-ItemProperty "IIS:\Sites\$siteName" -name physicalPath -value $c

#restart so we know it's loading from symlink
Write-Output "Restarting AppPool $appPoolName" 
Restart-WebAppPool -Name $appPoolName

#sleep for shutdownTimeout 
Write-Output "Sleeping for $shutdownTimeout" 
Start-Sleep -Seconds ([System.TimeSpan]::Parse("$shutdownTimeout").TotalSeconds)

#get current symlink target and set new target
Get-Item -Path $c | Select-Object -ExpandProperty target
$current = (Get-Item -Path $c).Target
$newTarget = if ($current -eq $a) {$b} else {$a}

$fileOrDirectoryName = Get-Item $artifactPath | Select-Object -ExpandProperty name

#test for .zip
if(($fileOrDirectoryName).ToLower().EndsWith(".zip") -eq $true)
{
    #copy to temp location
    $guid = [System.Guid]::NewGuid()
    $tempPath = "$iisRootPath\temp-$guid"
    $tempDest = "$iisRootPath\temp-dest-$guid"

    Write-Output "Creating temp directory $tempPath" 
    New-Item -Type Directory $tempPath

    $artifactDirectory = [System.IO.Path]::GetDirectoryName($artifactPath)
    $artifactFile = [System.IO.Path]::GetFileName($artifactPath);

    #TODO: first robocopy arg needs to be a directory, not a file
    Write-Output "Copying archive from $artifactPath to $tempPath" 
    robocopy $artifactDirectory $tempPath $artifactFile

    #extract to temp destination (seems a failed extract can leave empty folders)
    Write-Output "Extracting archive to $tempDest" 
    Expand-Archive -Path "$tempPath\$fileOrDirectoryName" -DestinationPath $tempDest -Force

    #copy from temp destination to destination
    Write-Output "Copying files from $tempDest to $newTarget" 
    robocopy $tempDest $newTarget /e

    #delete temp directory
    Write-Output "Removing temp directory $tempPath" 
    Remove-Item -Path $tempPath -Recurse -Force

    #delete temp directory
    Write-Output "Removing temp directory $tempDest" 
    Remove-Item -Path $tempDest -Recurse -Force
}
else 
{
    #copy new files
    Write-Output "Copying files from $artifactPath to $newTarget" 
    robocopy $artifactPath $newTarget /e
}

#swap symlink
Write-Output "Pointing SymbolicLink $c -> $newTarget" 
New-Item -Type SymbolicLink -Path $c -Target $newTarget -Force

#restart so it loads from newly swapped symlink
Write-Output "Restarting AppPool $appPoolName" 
Restart-WebAppPool -Name $appPoolName

@LucidObscurity 그게 뭐야? cmd 코드? 그 코드를 어디에 추가해야합니까?
감사

프로세스가 해제 될 때까지 msdeploy 명령에 대한 재시도 횟수 (매개 변수 : -retryAttempts:X ) 또는 재시도 시간 간격 (매개 변수 : -retryInterval:XXXX )을 늘리는 아이디어는 어떻습니까? 파일 잠금?

@davidfowl 이 옳다고 생각합니다. 프로세스가 어떻게 든 여전히 거기에 있고 파일을 잠급니다. IIS 재설정은 도움이 되지 않지만 시간이 초과 될 때까지 프로세스를 기다립니다. app_offline.htm을 삭제하고 90 초 동안 기다렸다가 (AppPool을 종료하는 기본 시간 제한 설정) 다시 시도하면 작동하는 것을 볼 수 있습니다.
로컬에서 나는 그렇게 오래 기다리지 않기 때문에이 종료 시간 제한 (초)을 5로 업데이트하고 프로젝트 파일을 업데이트하여 빌드 전에 app_offline.htm 을 생성
서버의 경우 msdeploy 를 사용하여 app_offline.htm을 삭제하고 새 버전을 동기화 한 다음 app_offline.htm을 제거합니다. msdeploy를 사용하면 파일이 잠겨 있지만 때때로 90 초 전에 포기하면 재 시도하므로 배포를 다시 트리거해야하며 두 번째 시도에서 작동합니다.

이것에 대한 업데이트가 있습니까? 이 새로운 릴리스가 언제 준비 될까요?

연락 해주셔서 감사합니다.
향후 평가 / 고려를 위해이 문제를 Next sprint planning 마일스톤으로 이동합니다. 다음 마일스톤에 대한 작업을 계획 할 때 요청을 평가할 것입니다. 다음에 예상되는 사항과이 문제를 처리하는 방법에 대해 자세히 알아 보려면 여기에서 심사 프로세스에 대해 자세히 읽어보십시오.

.NET 4.5.2 응용 프로그램을 .NET 5.0으로 변환 한 후 이번 주에이 문제에 대해 발견했습니다. 이를 극복하기위한 또 다른 접근 방식이 있습니다. IIS 서버에서 실행되는 Windows 서비스를 만들었습니다. 해당 서비스에는 사용자 지정 포트에서 실행되는 간단한 HTTP 서버가 있습니다. 웹 애플리케이션은 해당 서버에 사후 요청을 수행하여 업그레이드를 시작할 수 있습니다. 앱 풀을 중지하면 해당 응용 프로그램의 모든 프로세스를 종료하고 현재 릴리스의 백업을 만들고 현재 릴리스를 제거하고 upgradepackage를 다운로드하고 추출합니다. 그런 다음 앱 풀을 다시 시작합니다.

위에서 언급 한 Windows 서비스가 가져 오는 저장소로 푸시되는 업그레이드 패키지를 만들기 위해 간단한 Windows Forms 애플리케이션을 만들었습니다.