Linux의 Azure App Service에 대한 FAQ.

이러한 명령 또는 스크립트는 기본 제공 Docker 컨테이너가 시작된 후 애플리케이션 코드가 시작되기 전에 실행됩니다.

이 작업은 Docker 다시 시작과 동일합니다.

예. SCM(원본 제어 관리) 사이트를 통해 수행할 수 있습니다.

App Service의 예약된 필드를 true로 설정합니다.

예, Web App for Containers를 사용하여 연속 배포를 수행 하여 Azure Container Registry 또는 DockerHub에 대한 지속적인 통합/배포를 설정합니다. 프라이빗 레지스트리의 경우 웹앱을 중지했다가 다시 시작하여 컨테이너를 새로 고칠 수 있습니다. 또는 더미 애플리케이션 설정을 변경하거나 추가하여 컨테이너를 강제로 새로 고칠 수 있습니다.

예.

예, false로 호출 WEBSITE_WEBDEPLOY_USE_SCM 되는 앱 설정을 설정해야 합니다.

Git 배포가 Linux 웹앱에 실패하는 경우 다음 옵션 중 하나를 선택하여 애플리케이션 코드를 배포합니다.

• 지속적인 업데이트(미리 보기) 기능 사용: Azure DevOps Git 리포지토리 또는 GitHub 리포지토리에 앱의 소스 코드를 저장하여 Azure 지속적인 업데이트를 사용할 수 있습니다. 자세한 내용은 Linux 웹앱에 대한 지속적인 업데이트를 구성하는 방법을 참조 하세요.

• ZIP 배포 API 사용: 이 API를 사용하려면 SSH를 웹앱으로 이동하고 코드를 배포하려는 폴더로 이동합니다. 다음 코드를 실행하세요.

  curl -X POST -u <user> --data-binary @<zipfile> https://{your-sitename}.scm.azurewebsites.net/api/zipdeploy
  

  명령을 찾을 수 없다는 오류가 curl 발생하는 경우 이전 curl 명령을 실행하기 전에 이를 사용하여 apt-get install curl curl을 설치해야 합니다.

예, 서버 쪽 Node.js 코드에서 사용하지 않도록 설정합니다 perMessageDeflate . 예를 들어 socket.io 사용하는 경우 다음 코드를 사용합니다.

const io = require('socket.io')(server,{
  perMessageDeflate :false
});

예.

예, Git 배포 중에 Kudu는 PHP 애플리케이션을 배포하고 있음을 감지해야 합니다(composer.lock 파일이 있음) Kudu는 작성기 설치를 트리거합니다.

예. 이 기능은 Azure CLI에서 사용할 수 있습니다. 시스템이 할당한 ID 또는 사용자 할당 ID를 사용할 수 있습니다. 이 기능은 현재 Azure Portal에서 지원되지 않습니다.

WEBSITES_ENABLE_APP_SERVICE_STORAGE 설정이 지정되지 않았거나 false로 설정된 경우 /home/ 디렉터리는 확장 인스턴스 간에 공유되지 않으며 작성된 파일은 다시 시작해도 지속되지 않습니다. 명시적으로 true로 설정 WEBSITES_ENABLE_APP_SERVICE_STORAGE 하면 탑재가 활성화됩니다. true로 설정되면 탑재를 사용하지 않도록 설정하려는 경우 WEBSITES_ENABLE_APP_SERVICE_STORAGE를 명시적으로 false로 설정해야 합니다.

Linux의 App Service는 두 가지 유형의 스토리지를 사용합니다.

• 파일 시스템 스토리지: 파일 시스템 스토리지는 App Service 계획 할당량에 포함됩니다. 파일이 디렉터리에 루트된 영구 스토리지에 /home 저장될 때 사용됩니다.
• 호스트 디스크 공간: 호스트 디스크 공간은 컨테이너 이미지를 저장하는 데 사용됩니다. Docker 스토리지 드라이버를 통해 플랫폼에서 관리됩니다.

호스트 디스크 공간은 파일 시스템 스토리지 할당량과 별개입니다. 확장할 수 없으며 각 인스턴스에 대해 15GB 제한이 있습니다. 작업자에 사용자 지정 이미지를 저장하는 데 사용됩니다. 호스트 디스크 공간의 정확한 가용성에 따라 15GB를 초과하여 사용할 수 있지만 이것이 보장되지는 않습니다.

컨테이너의 쓰기 가능 계층이 디렉터리 또는 탑재된 Azure Storage 경로 외부에 /home 데이터를 저장하는 경우 호스트 디스크 공간도 사용됩니다.

플랫폼은 호스트 디스크 공간을 정기적으로 정리하여 사용되지 않는 컨테이너를 제거합니다. 컨테이너가 디렉터리 외부 또는 BYOS(Bring Your Own Storage) 외부 /home 에 대량의 데이터를 쓰는 경우 호스트 디스크 공간 제한을 초과하면 시작 실패 또는 런타임 예외가 발생합니다.

Linux App Service에서 실행할 때 컨테이너 이미지를 가능한 한 작게 유지하고 영구 스토리지 또는 BYOS에 데이터를 쓰는 것이 좋습니다. 가능하지 않은 경우 호스트 디스크 공간이 고정되고 App Service 계획의 모든 컨테이너 간에 공유되므로 App Service 계획을 분할해야 합니다.

컨테이너를 다시 시작하기 전에 플랫폼이 대기할 시간을 구성할 수 있습니다. 이렇게 하려면 앱 설정을 원하는 값으로 설정합니다 WEBSITES_CONTAINER_START_TIME_LIMIT . 기본값은 230초이고 최댓값은 1800초입니다.

포함하거나 https://을 포함하여 http:// 전체 레지스트리 URL을 제공합니다.

개인 레지스트리 URL(예: myacr.azurecr.io/dotnet:latest)을 포함하여 전체 이미지 이름을 추가합니다. 사용자 지정 포트 를 사용하는 이미지 이름은 포털을 통해 입력할 수 없습니다. docker-custom-image-name을 설정하려면 az 명령줄 도구를 사용합니다.

둘 이상의 포트를 노출하는 것은 지원되지 않습니다.

예, 사용자 고유의 스토리지 를 미리 보기로 가져옵니다.

SCM 사이트는 별도의 컨테이너에서 실행됩니다. 파일 시스템 또는 앱 컨테이너의 실행 중인 프로세스를 확인할 수 없습니다.

아니요, 플랫폼은 공유 프런트 엔드에서 HTTPS 종료를 처리합니다.

예, 사용자 지정 컨테이너에 필요합니다. 사용자 지정 포트를 수동으로 구성하려면 컨테이너에 바인딩할 포트 값과 함께 Dockerfile 및 앱 설정 WEBSITES_PORT의 EXPOSE 명령을 사용합니다.

예, .NET Core 앱이 시작되기 전에 환경 변수를 덮어씁니다. 예: init.sh 스크립트에서 ASPNETCORE_URLS={Your value} 내보내기

다중 컨테이너에서 ACR을 사용하기 위해 모든 컨테이너 이미지는 동일한 ACR 레지스트리 서버에 호스트되어야 합니다. 동일한 레지스트리 서버에 있으면 애플리케이션 설정을 만든 다음 ACR 이미지 이름을 포함하도록 Docker Compose 구성 파일을 업데이트해야 합니다.

다음 애플리케이션 설정을 만듭니다.

• DOCKER_REGISTRY_SERVER_USERNAME
• DOCKER_REGISTRY_SERVER_URL(전체 URL, 예: https://<server-name>.azurecr.io)
• DOCKER_REGISTRY_SERVER_PASSWORD(ACR 설정에서 관리자 액세스 사용)

구성 파일 내에서 다음 예제와 같이 ACR 이미지를 참조합니다.

image: <server-name>.azurecr.io/<image-name>:<tag>

• 액세스를 위해 하나의 컨테이너만 열 수 있습니다.
• 포트 80 및 8080만 액세스할 수 있음(노출된 포트)

다음은 우선 순위에 따라 액세스할 수 있는 컨테이너를 결정하는 규칙입니다.

• 컨테이너 이름으로 설정된 애플리케이션 설정 WEBSITES_WEB_CONTAINER_NAME
• 포트 80 또는 8080을 정의하는 첫 번째 컨테이너
• 위의 두 컨테이너가 모두 true가 아니면 파일에 정의된 첫 번째 컨테이너에 액세스할 수 있습니다(노출됨).

이 depends_on 옵션은 App Service에서 지원 되지 않으며 무시됩니다. Docker의 제어 시작 및 종료 권장 사항과 마찬가지로 App Service 다중 컨테이너 앱은 시작 및 연결 끊기 시 애플리케이션 코드를 통해 종속성을 확인해야 합니다. 아래 예제 코드는 Redis 컨테이너가 실행 중인지 확인하는 Python 앱을 보여 줍니다.

import time
import redis
from flask import Flask
app = Flask(__name__)
cache = redis.Redis(host='redis', port=6379)
def get_hit_count():
    retries = 5
    while True:
        try:
            return cache.incr('hits')
        except redis.exceptions.ConnectionError as exc:
            if retries == 0:
                raise exc
            retries -= 1
            time.sleep(0.5)
@app.route('/')
def hello():
    count = get_hit_count()
    return 'Hello from Azure App Service team! I have been seen {} times.\n'.format(count)
if __name__ == "__main__":
    app.run(host="0.0.0.0", port=80, debug=True)

WebSocket

웹 소켓은 Linux 앱에서 지원됩니다. 웹 소켓은 webSocketsEnabled 항상 Linux에 대해 사용하도록 설정되므로 ARM 설정은 Linux 앱에 적용되지 않습니다.

가격은 SKU 및 지역에 따라 다르지만 가격 책정 페이지(App Service 가격 책정)에서 자세한 내용을 확인할 수 있습니다.

Azure App Services가 컨테이너를 시작하면 준비 요청은 애플리케이션의 /robots933456.txt 엔드포인트에 HTTP 요청을 보냅니다. 이것은 단순히 더미 엔드포인트이지만 애플리케이션은 5XX가 아닌 상태 코드로 회신해야 합니다. 애플리케이션 논리가 존재하지 않는 엔드포인트에 HTTP 상태 코드로 회신하지 않으면 준비 요청은 응답을 받을 수 없으며 컨테이너를 영구적으로 다시 시작합니다. 포트가 잘못 구성되기 때문에 준비 요청이 실패할 수도 있습니다.

Azure 앱 Services에서 포트가 올바르게 구성되었는지 확인하려면 Linux 컨테이너에서 포트를 지정하는 어떻게 할까요? 질문을 참조하세요.

컨테이너의 회신을 240초 동안 기다린 후 기본적으로 준비 요청이 실패합니다. 240~1800초 사이의 값으로 애플리케이션 설정 WEBSITES_CONTAINER_START_TIME_LIMIT를 추가하여 컨테이너 준비 요청 시간 제한을 늘릴 수 있습니다.

애플리케이션의 파일 시스템은 탑재된 네트워크 공유입니다. 이 기능은 여러 호스트에서 코드를 실행해야 하는 스케일 아웃 시나리오에 사용할 수 있습니다. 아쉽게도 이 기능은 데이터베이스 파일에 대한 배타적 잠금을 획득할 수 없으므로 SQLite와 같은 파일 기반 데이터베이스 공급자의 사용을 차단합니다. 관리형 데이터베이스 서비스인 Azure SQL, Azure Database for MySQL 또는 Azure Database for PostgreSQL을 사용하는 것이 좋습니다.

애플리케이션 설정에 문자(A-Z, a-z), 숫자(0-9) 및 밑줄(_)만 사용할 수 있습니다.

Web Apps 사용자 의견 포럼에서 사용자의 아이디어를 제출할 수 있습니다. 아이디어 제목에 "[Linux]"를 추가합니다.

다음 단계

• Linux의 Azure 앱 Service란?
• Azure App Service에서 스테이징 환경 설정
• Web App for Containers를 사용하여 지속적인 배포
• 알아야 할 사항: Web Apps 및 Linux
• 환경 변수 및 앱 설정 참조

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.