Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 8개 있습니다.)
개발 환경 구성: 371. Azure Web App 확장 예제 - Simple WebSite Extension
; https://www.sysnet.pe.kr/2/0/11505

개발 환경 구성: 379. Azure Web App 확장 예제 제작
; https://www.sysnet.pe.kr/2/0/11540

개발 환경 구성: 380. Azure Web App 확장 배포 방법
; https://www.sysnet.pe.kr/2/0/11541

개발 환경 구성: 408. C# - REST API를 이용해 Azure Kudu 서비스 이용 - 파일 처리
; https://www.sysnet.pe.kr/2/0/11730

개발 환경 구성: 409. C# - REST API를 이용해 Azure Kudu 서비스 이용 - 웹 앱 확장 처리
; https://www.sysnet.pe.kr/2/0/11731

개발 환경 구성: 578. Azure - Java Web App Service를 위한 Site Extension 제작 방법
; https://www.sysnet.pe.kr/2/0/12711

개발 환경 구성: 579. Azure - 리눅스 호스팅의 Site Extension 제작 방법
; https://www.sysnet.pe.kr/2/0/12712

개발 환경 구성: 605. Azure App Service - Kudu SSH 환경에서 FTP를 이용한 파일 전송
; https://www.sysnet.pe.kr/2/0/12855




Azure - 리눅스 호스팅의 Site Extension 제작 방법

지난 글을 통해 닷넷과 자바에 대한 Site Extension 제작에 대해 간략하게 설명했는데요,

Azure Web App 확장 예제 제작
; https://www.sysnet.pe.kr/2/0/11540

Azure - Java Web App Service를 위한 Site Extension 제작 방법
; https://www.sysnet.pe.kr/2/0/12711

아쉽게도 리눅스 호스팅 환경에 대해서는 기존의 Site Extension 방식을 지원하지 않고 있습니다. 실제로 리눅스 호스팅의 Azure App Service 메뉴에는 "Extensions"가 회색 처리되어 나옵니다.

linux_site_ext_1.png

(메뉴를 아주 빼진 않고 grayed out 처리했다는 것은 향후 지원할 의사가 있다는 것이겠죠? ^^)




그래도 특정 시나리오에서는 이를 해결하는 방법이 있는데요, 그것은 바로 (위의 그림에서도 볼 수 있는) SSH 연결로 들어가 Site Extension으로 해결해야 할 작업을 직접 구성할 수 있다는 것입니다.

아니... 그럼 그렇게 구성하는 경우 scale out 시 인스턴스가 늘어나면 새로운 인스턴스들은 그게 적용이 안 될 텐데요?

물론, 그게 전부라면 안 되는 것이 맞겠지만 Azure의 경우 리눅스에서 App Service를 호스팅하는 것은 내부적으로 docker container로 처리한다고 합니다. 그리고, App Service에서 SSH 연결로 들어가 작업하는 /home 디렉터리가 각각의 컨테이너별로 (아마도 볼륨으로) 공유됩니다. 실제로 SSH 접속 시 보이는 화면은 다음과 같은 메시지를 보여주며 시작합니다.

  _____
  /  _  \ __________ _________   ____
 /  /_\  \___   /  |  \_  __ \_/ __ \
/    |    \/    /|  |  /|  | \/\  ___/
\____|__  /_____ \____/ |__|    \___  >
        \/      \/                  \/
A P P   S E R V I C E   O N   L I N U X
Documentation: http://aka.ms/webapp-linux

**NOTE**: No files or system changes outside of /home will persist beyond your application's current session. 
/home is your application's persistent storage and is shared across all the server instances.

23ec1b86e7b3:/home#

Note: Any data outside '/home' is not persisted

따라서, 사실 Linux 호스팅 환경에서는 윈도우 환경처럼 "Site Extension"으로서 별도 웹 사이트를 구성하는 방식은 제공하지 않습니다. 단지, 해당 Extension이 내부적인 설치 과정 중에 App Service에 변경을 하는 식의 작업이 전부라면 SSH 연결로 /home 디렉터리에 직접 작업하는 것이 가능합니다.

(제가 아직 테스트는 안 해봤지만 윈도우 호스팅에서의 d:\home 디렉터리도 아마 App Service의 scale out 발생 시 늘어나는 인스턴스 간에도 공유되는 걸로 알고 있습니다. 이건 나중에 테스트해 보고 다시 업데이트하겠습니다. ^^)




참고로, Azure에 App Service를 명시적으로 container로 배포하는 유형에 대한 문서가 있는데요,

Configure a custom container for Azure App Service
; https://docs.microsoft.com/en-us/azure/app-service/configure-custom-container?pivots=container-linux

위의 문서에 포함된 "Use persistent shared storage" 설명에 보면,

You can use the /home directory in your app's file system to persist files across restarts and share them across instances. The /home in your app is provided to enable your container app to access persistent storage.

When persistent storage is disabled, then writes to the /home directory aren't persisted across app restarts or across multiple instances. The only exception is the /home/LogFiles directory, which is used to store the Docker and container logs. When persistent storage is enabled, all writes to the /home directory are persisted and can be accessed by all instances of a scaled-out app.

By default, persistent storage is disabled and the setting is not exposed in the app settings. To enable it, set the WEBSITES_ENABLE_APP_SERVICE_STORAGE app setting via the Cloud Shell. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=true


이렇게 나옵니다. 저런 차원에서라면, 아마도 비-컨테이너 방식의 App Service는 /home 디렉터리를 공유/지속시켜 주는 기능이 기본적으로 켜져 있다고 이해할 수 있을 것입니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 12/2/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 61  62  [63]  64  65  66  67  68  69  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12425정성태11/24/202020688VC++: 141. Visual C++ - "Treat Warnings As Errors" 옵션이 꺼져 있는데도 일부 경고가 에러 처리되는 경우
12424정성태11/24/202020731VC++: 140. C++의 연산자 동의어(operator synonyms), 대체 토큰 [1]
12423정성태11/22/202020397.NET Framework: 974. C# 9.0 - (16) 제약 조건이 없는 형식 매개변수 주석(Unconstrained type parameter annotations)파일 다운로드1
12422정성태11/21/202017839.NET Framework: 973. .NET 5, .NET Framework에서만 허용하는 UnmanagedCallersOnly 사용예파일 다운로드1
12421정성태11/19/202016881.NET Framework: 972. DNNE가 출력한 NE DLL을 직접 생성하는 방법파일 다운로드1
12420정성태11/19/202017903오류 유형: 684. Visual C++ - MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
12419정성태11/19/202017787VC++: 139. Visual C++ - .NET Core의 nethost.lib와 정적 링크파일 다운로드1
12418정성태11/19/202019885오류 유형: 683. Visual C++ - error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MDd_DynamicDebug'파일 다운로드1
12417정성태11/19/202018786오류 유형: 682. Visual C++ - warning LNK4099: PDB '...pdb' was not found with '...lib(pch.obj)' or at '...pdb'; linking object as if no debug info
12416정성태11/19/202019971오류 유형: 681. Visual C++ - error LNK2001: unresolved external symbol _CrtDbgReport
12415정성태11/18/202019006.NET Framework: 971. UnmanagedCallersOnly 특성과 DNNE 사용파일 다운로드1
12414정성태11/18/202022740VC++: 138. x64 빌드에서 extern "C"가 아닌 경우 ___cdecl name mangling 적용 [4]파일 다운로드1
12413정성태11/17/202020810.NET Framework: 970. .NET 5 / .NET Core - UnmanagedCallersOnly 특성을 사용한 함수 내보내기파일 다운로드1
12412정성태11/16/202022842.NET Framework: 969. .NET Framework 및 .NET 5 - UnmanagedCallersOnly 특성 사용파일 다운로드1
12411정성태11/12/202019150오류 유형: 680. C# 9.0 - Error CS8889 The target runtime doesn't support extensible or runtime-environment default calling conventions.
12410정성태11/12/202020784디버깅 기술: 174. windbg - System.TypeLoadException 예외 분석 사례
12409정성태11/12/202021956.NET Framework: 968. C# 9.0의 Function pointer를 이용한 함수 주소 구하는 방법파일 다운로드1
12408정성태11/9/202036923도서: 시작하세요! C# 9.0 프로그래밍 [8]
12407정성태11/9/202021997.NET Framework: 967. "clr!JIT_DbgIsJustMyCode" 호출이 뭘까요?
12406정성태11/8/202022796.NET Framework: 966. C# 9.0 - (15) 최상위 문(Top-level statements) [5]파일 다운로드1
12405정성태11/8/202022233.NET Framework: 965. C# 9.0 - (14) 부분 메서드에 대한 새로운 기능(New features for partial methods)파일 다운로드1
12404정성태11/7/202022924.NET Framework: 964. C# 9.0 - (13) 모듈 이니셜라이저(Module initializers)파일 다운로드1
12403정성태11/7/202019895.NET Framework: 963. C# 9.0 - (12) foreach 루프에 대한 GetEnumerator 확장 메서드 지원(Extension GetEnumerator)파일 다운로드1
12402정성태11/7/202023309.NET Framework: 962. C# 9.0 - (11) 공변 반환 형식(Covariant return types) [1]파일 다운로드1
12401정성태11/5/202022151VS.NET IDE: 153. 닷넷 응용 프로그램에서의 "My Code" 범위와 "Enable Just My Code"의 역할 [1]
12400정성태11/5/202017992오류 유형: 679. Visual Studio - "Source Not Found" 창에 "Decompile source code" 링크가 없는 경우
... 61  62  [63]  64  65  66  67  68  69  70  71  72  73  74  75  ...