Core Tools를 사용하여 로컬로 Azure Functions 개발

  • 아티클

Azure Functions Core Tools를 사용하여 로컬 머신에서 함수를 개발하고 테스트할 수 있습니다. 준비가 되면 Core Tools를 사용하여 코드 프로젝트를 Azure에 배포하고 애플리케이션 설정을 사용할 수도 있습니다.

이 문서의 C# 버전을 보고 있습니다. 문서의 상단에서 선호하는 Functions 프로그래밍 언어를 선택하세요.

즉시 시작하려면 Core Tools 빠른 시작 문서를 완료합니다.

이 문서의 Java 버전을 보고 있습니다. 문서의 상단에서 선호하는 Functions 프로그래밍 언어를 선택하세요.

즉시 시작하려면 Core Tools 빠른 시작 문서를 완료합니다.

이 문서의 JavaScript 버전을 보고 있습니다. 문서의 상단에서 선호하는 Functions 프로그래밍 언어를 선택하세요.

즉시 시작하려면 Core Tools 빠른 시작 문서를 완료합니다.

이 문서의 PowerShell 버전을 보고 있습니다. 문서의 상단에서 선호하는 Functions 프로그래밍 언어를 선택하세요.

즉시 시작하려면 Core Tools 빠른 시작 문서를 완료합니다.

이 문서의 Python 버전을 보고 있습니다. 문서의 상단에서 선호하는 Functions 프로그래밍 언어를 선택하세요.

즉시 시작하려면 Core Tools 빠른 시작 문서를 완료합니다.

이 문서의 TypeScript 버전을 보고 있습니다. 문서의 상단에서 선호하는 Functions 프로그래밍 언어를 선택하세요.

즉시 시작하려면 Core Tools 빠른 시작 문서를 완료합니다.

Azure Functions 핵심 도구 설치

Core Tools를 설치하는 권장 방법은 로컬 개발 시스템의 운영 체제에 따라 다릅니다.

다음 단계에서는 MSI(Windows 설치 프로그램)를 사용하여 Core Tools v4.x를 설치합니다. 다른 패키지 기반 설치 관리자에 대한 자세한 내용은 핵심 도구 추가 정보를 참조하세요.

다음과 같이 Windows 버전에 따라 Core Tools 설치 프로그램을 다운로드하여 실행합니다.

이전에 Windows 설치 프로그램(MSI)을 사용하여 Windows에 Core Tools를 설치한 경우 최신 버전을 설치하기 전에 프로그램 추가/제거에서 이전 버전을 제거해야 합니다.

버전 관련 문제에 대한 도움말은 Core Tools 버전을 참조하세요.

로컬 프로젝트 만들기

Important

Python의 경우 가상 환경에서 Core Tools 명령을 실행해야 합니다. 자세한 내용은 빠른 시작: 명령줄에서 Azure에서 Python 함수 만들기를 참조하세요.

터미널 창 또는 명령 프롬프트에서 다음 명령을 실행하여 MyProjFolder 폴더에 프로젝트를 만듭니다.

func init MyProjFolder --worker-runtime dotnet-isolated

기본적으로 이 명령은 현재 LTS(장기 지원) 버전의 .NET Core에서 Functions 호스트와 함께 실행되는 프로젝트를 만듭니다. --target-framework 옵션을 사용하여 .NET Framework를 비롯한 지원되는 특정 버전의 .NET을 대상으로 지정할 수 있습니다. 자세한 내용은 func init 참조를 참조하세요.

두 .NET 프로세스 모델을 비교하려면 프로세스 모드 비교 문서를 참조하세요.

Java는 Maven 원형을 사용하여 HTTP 트리거된 첫 번째 함수와 함께 로컬 프로젝트를 만듭니다. func init 및 func new을(를) 사용하는 대신 명령줄 빠른 시작의 단계를 따라야 합니다.

func init MyProjFolder --worker-runtime javascript --model V4

이 명령은 원하는 프로그래밍 모델 버전을 사용하는 JavaScript 프로젝트를 만듭니다.

func init MyProjFolder --worker-runtime typescript --model V4

이 명령은 원하는 프로그래밍 모델 버전을 사용하는 TypeScript 프로젝트를 만듭니다.

func init MyProjFolder --worker-runtime powershell

func init MyProjFolder --worker-runtime python --model V2

이 명령은 원하는 프로그래밍 모델 버전을 사용하는 Python 프로젝트를 만듭니다.

--worker-runtime 옵션 없이 func init을(를) 실행하면 프로젝트 언어를 선택하라는 메시지가 표시됩니다. func init 명령에 사용할 수 있는 옵션에 대해 자세히 알아보려면 func init을(를) 참조하세요.

함수 만들기

프로젝트에 함수를 추가하려면 --template 옵션을 사용하여 func new 명령을 실행하여 트리거 템플릿을 선택합니다. 다음 예에서는 MyHttpTrigger(이)라는 HTTP 트리거를 만듭니다.

func new --template "Http Trigger" --name MyHttpTrigger

이 예에서는 MyQueueTrigger라는 Queue Storage 트리거를 만듭니다.

func new --template "Azure Queue Storage Trigger" --name MyQueueTrigger

Functions를 추가할 때는 다음 사항을 고려해야 합니다.

  • --template 옵션 없이 func new을(를) 실행하면 템플릿를 선택하라는 메시지가 표시됩니다.

  • func templates list 명령을 사용하여 언어에 대해 사용 가능한 템플릿의 전체 목록을 확인합니다.

  • 서비스에 연결하는 트리거를 추가하는 경우 연결 문자열 또는 관리 ID를 참조하는 애플리케이션 설정을 local.settings.json 파일에 추가해야 합니다. 이러한 방식으로 앱 설정을 사용하면 코드에 자격 증명을 포함할 필요가 없습니다. 자세한 내용은 로컬로 앱 설정 작업을 참조하세요.

  • 또한 Core Tools는 C# 프로젝트에 특정 바인딩 확장에 대한 참조를 추가합니다.

func new 명령에 사용할 수 있는 옵션에 대해 자세히 알아보려면 func new을(를) 참조하세요.

함수에 바인딩 추가

함수는 서비스별 입력 및 출력 바인딩 집합을 제공하므로 서비스별 클라이언트 SDK를 사용하지 않고도 함수를 다른 Azure 서비스에 쉽게 연결할 수 있습니다. 자세한 내용은 Azure Functions 트리거 및 바인딩 개념을 참조하세요.

기존 함수에 입력 또는 출력 바인딩을 추가하려면 함수 정의를 수동으로 업데이트해야 합니다.

다음 예제에서는 HTTP 트리거 함수에 Queue Storage 출력 바인딩을 추가한 후의 함수 정의를 보여 줍니다.

HTTP 트리거 함수도 HTTP 응답을 반환하므로 함수는 HTTP 및 큐 출력을 모두 나타내는 MultiResponse 개체를 반환합니다.

[Function("HttpExample")]
public static MultiResponse Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req,
    FunctionContext executionContext)
{

이 예제는 출력 바인딩을 포함하는 MultiResponse 개체의 정의입니다.

public class MultiResponse
{
    [QueueOutput("outqueue",Connection = "AzureWebJobsStorage")]
    public string[] Messages { get; set; }
    public IActionResult HttpResponse { get; set; }
}

해당 예제를 자체 프로젝트에 적용할 때 ASP.NET Core 통합을 사용하는지 여부에 따라 HttpRequest를 HttpRequestData로 변경하고 IActionResult를 HttpResponseData로 변경해야 할 수 있습니다.

함수가 완료되면 큐에 메시지가 전송됩니다. 출력 바인딩을 정의하는 방법은 프로세스 모델에 따라 다릅니다. 참조할 수 있는 예제 바인딩 코드에 대한 링크를 비롯한 자세한 내용은 함수에 바인딩 추가를 참조하세요.

@FunctionName("HttpExample")
public HttpResponseMessage run(
        @HttpTrigger(name = "req", methods = {HttpMethod.GET, HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS) 
        HttpRequestMessage<Optional<String>> request, 
        @QueueOutput(name = "msg", queueName = "outqueue", 
        connection = "AzureWebJobsStorage") OutputBinding<String> msg, 
        final ExecutionContext context) {

참조할 수 있는 예제 바인딩 코드에 대한 링크를 비롯한 자세한 내용은 함수에 바인딩 추가를 참조하세요.

Node.js 모델 v4에 대한 예 바인딩은 아직 사용할 수 없습니다.

출력 바인딩을 정의하는 방법은 Node.js 모델의 버전에 따라 달라집니다. 참조할 수 있는 예제 바인딩 코드에 대한 링크를 비롯한 자세한 내용은 함수에 바인딩 추가를 참조하세요.

$outputMsg = $name
Push-OutputBinding -name msg -Value $outputMsg

참조할 수 있는 예제 바인딩 코드에 대한 링크를 비롯한 자세한 내용은 함수에 바인딩 추가를 참조하세요.

@app.route(route="HttpExample")
@app.queue_output(arg_name="msg", queue_name="outqueue", connection="AzureWebJobsStorage")
def HttpExample(req: func.HttpRequest, msg: func.Out [func.QueueMessage]) -> func.HttpResponse:
    logging.info('Python HTTP trigger function processed a request.')

출력 바인딩을 정의하는 방법은 Python 모델의 버전에 따라 달라집니다. 참조할 수 있는 예제 바인딩 코드에 대한 링크를 비롯한 자세한 내용은 함수에 바인딩 추가를 참조하세요.

Node.js 모델 v4에 대한 예 바인딩은 아직 사용할 수 없습니다.

출력 바인딩을 정의하는 방법은 Node.js 모델의 버전에 따라 달라집니다. 참조할 수 있는 예제 바인딩 코드에 대한 링크를 비롯한 자세한 내용은 함수에 바인딩 추가를 참조하세요.

함수에 바인딩을 추가할 때는 다음 사항을 고려해야 합니다.

  • function.json 구성 파일을 사용하여 함수를 정의하는 언어의 경우 Visual Studio Code는 기존 함수 정의에 바인딩을 추가하는 프로세스를 간소화합니다. 자세한 내용은 바인딩을 사용하여 Azure 서비스에 함수 연결을 참조하세요.
  • 서비스에 연결하는 바인딩을 추가할 때는 연결 문자열 또는 관리 ID를 참조하는 애플리케이션 설정도 local.settings.json 파일에 추가해야 합니다. 자세한 내용은 로컬로 앱 설정 작업을 참조하세요.
  • 지원되는 바인딩을 추가할 때 앱에서 확장 번들을 사용할 때 확장 프로그램이 이미 설치되어 있어야 합니다. 자세한 내용은 확장 번들을 참조하세요.
  • 새 바인딩 확장이 필요한 바인딩을 추가하는 경우 C# 프로젝트에서 해당 특정 바인딩 확장에 대한 참조도 추가해야 합니다.

참조할 수 있는 예제 바인딩 코드에 대한 링크를 비롯한 자세한 내용은 함수에 바인딩 추가를 참조하세요.

참조할 수 있는 예제 바인딩 코드에 대한 링크를 비롯한 자세한 내용은 함수에 바인딩 추가를 참조하세요.

참조할 수 있는 예제 바인딩 코드에 대한 링크를 비롯한 자세한 내용은 함수에 바인딩 추가를 참조하세요.

참조할 수 있는 예제 바인딩 코드에 대한 링크를 비롯한 자세한 내용은 함수에 바인딩 추가를 참조하세요.

참조할 수 있는 예제 바인딩 코드에 대한 링크를 비롯한 자세한 내용은 함수에 바인딩 추가를 참조하세요.

참조할 수 있는 예제 바인딩 코드에 대한 링크를 비롯한 자세한 내용은 함수에 바인딩 추가를 참조하세요.

Functions 런타임 시작

프로젝트에서 함수를 실행하거나 디버그하려면 먼저 프로젝트의 루트 디렉터리에서 Functions 호스트를 시작해야 합니다. 해당 호스트는 프로젝트의 모든 함수에 대한 트리거를 사용하는 것으로 설정합니다. 다음 명령을 사용하여 로컬 런타임을 시작합니다.

mvn clean package 
mvn azure-functions:run

func start

npm install
npm start

이 명령은 가상 환경에서 실행해야 합니다.

Functions 호스트가 시작되면 이 예제와 같이 HTTP 트리거 함수의 URL을 포함하여 프로젝트의 함수 목록을 출력합니다.

Found the following functions:
Host.Functions.MyHttpTrigger

Job host started
Http Function MyHttpTrigger: http://localhost:7071/api/MyHttpTrigger

함수를 로컬로 실행할 때 다음 사항을 고려해야 합니다.

  • 기본적으로 권한 부여는 HTTP 엔드포인트에 대해 로컬로 적용되지 않습니다. 즉, 모든 로컬 HTTP 요청은 authLevel = "anonymous"로 처리됩니다. 자세한 내용은 HTTP 바인딩 문서를 참조하세요. 로컬에서 실행할 때 --enableAuth 옵션을 사용하여 인증을 요구할 수 있습니다. 자세한 내용은 func start를 참조하세요.

  • Azure에서 이러한 서비스에 연결하지 않고도 Azure Storage 서비스(Queue Storage, Blob Storage 및 Table Storage)에 액세스해야 하는 함수를 로컬로 실행할 때 로컬 Azurite 에뮬레이터를 사용할 수 있습니다. 로컬 에뮬레이션을 사용하는 경우 로컬 호스트(func.exe)를 시작하기 전에 Azurite를 시작해야 합니다. 자세한 내용은 로컬 스토리지 에뮬레이션을 참조하세요.

  • 로컬 Azurite 에뮬레이션을 사용하여 Python v2 작업자의 스토리지 요구 사항을 충족할 수 있습니다.

  • 라이브 서비스에 연결하지 않고 로컬로 비 HTTP 함수를 트리거할 수 있습니다. 자세한 내용은 로컬 함수 실행을 참조하세요.

  • local.settings.json 파일에 Application Insights 연결 정보를 포함하면 로컬 로그 데이터가 특정 Application Insights 인스턴스에 기록됩니다. 로컬 원격 분석 데이터를 프로덕션 데이터와 별도로 유지하려면 개발 및 테스트에 별도의 Application Insights 인스턴스를 사용하는 것이 좋습니다.

  • Core Tools 버전 1.x를 사용하는 경우, 대신 func host start 명령을 사용하여 로컬 런타임을 시작하세요.

로컬 함수 실행

로컬 Functions 호스트(func.exe)가 실행되면 이제 개별 함수를 트리거하여 함수 코드를 실행하고 디버그할 수 있습니다. 개별 함수를 실행하는 방법은 트리거 유형에 따라 달라집니다.

참고 항목

이 항목의 예제에서는 cURL 도구를 사용하여 터미널 또는 명령 프롬프트의 HTTP 요청을 보냅니다. 로컬 서버에 HTTP 요청을 보내도록 선택한 도구를 사용할 수 있습니다. cURL 도구는 Linux 기반 시스템 및 Windows 10 빌드 17063 이상에서 기본적으로 사용할 수 있습니다. Windows에서는 먼저 cURL 도구를 다운로드한 후 설치해야 합니다.

HTTP 트리거는 다음과 같은 일반적인 형식의 func.exe 출력에 표시된 대로 로컬 엔드포인트와 포트에 HTTP 요청을 전송하여 시작됩니다.

http://localhost:<PORT>/api/<FUNCTION_NAME>

이 URL 템플릿에서 <FUNCTION_NAME>은(는) 함수 또는 경로의 이름이고 <PORT>은(는) func.exe가 수신 대기 중인 로컬 포트입니다.

예를 들어, cURL 명령은 이름 매개 변수를 쿼리 문자열에 전달한 GET 요청에서 MyHttpTrigger 빠른 시작 함수를 트리거합니다.

curl --get http://localhost:7071/api/MyHttpTrigger?name=Azure%20Rocks

이 예제는 요청 본문에 이름을 전달하는 POST 요청에서 호출되는 동일한 함수로, Bash 셸과 Windows 명령줄 모두에 표시됩니다.

curl --request POST http://localhost:7071/api/MyHttpTrigger --data '{"name":"Azure Rocks"}'

curl --request POST http://localhost:7071/api/MyHttpTrigger --data "{'name':'Azure Rocks'}"

다음 고려 사항은 HTTP 엔드포인트를 로컬로 호출할 때 적용됩니다.

  • 쿼리 문자열에서 데이터를 전달하는 브라우저에서 GET 요청을 수행할 수 있습니다. 다른 모든 HTTP 메서드에서 POST 요청을 지원하는 cURL, Fiddler, Postman 또는 비슷한 HTTP 테스트 도구를 사용해야 합니다.

  • Functions 호스트가 수신 대기 중인 동일한 서버 이름 및 포트를 사용하도록 합니다. Function 호스트를 시작할 때 생성된 출력에서 이와 같은 엔드포인트를 볼 수 있습니다. 트리거에서 지원하는 HTTP 메서드를 사용하여 이 URL을 호출할 수 있습니다.

Azure에 게시

Azure Functions Core Tools는 세 가지 배포 유형을 지원합니다.

배포 유형 명령 설명
프로젝트 파일 func azure functionapp publish zip 배포를 사용하여 함수 프로젝트 파일을 함수 앱에 직접 배포합니다.
Azure Container Apps func azurecontainerapps deploy 컨테이너화된 함수 앱을 기존 Container Apps 환경에 배포합니다.
Kubernetes 클러스터 func kubernetes deploy Linux 함수 앱을 Kubernetes 클러스터에 사용자 지정 Docker 컨테이너로 배포합니다.

Core Tools에서 Azure에 게시하려면 Azure CLI 또는 Azure PowerShell을 로컬로 설치해야 합니다. 기본적으로 Core Tools는 이러한 도구를 사용하여 Azure 계정으로 인증합니다.

이러한 도구가 설치되어 있지 않은 경우 배포 중에 사용할 유효한 액세스 토큰을 대신 가져와야 합니다. 배포 명령의 --access-token 옵션을 사용하여 액세스 토큰을 표시할 수 있습니다.

프로젝트 파일 배포

다음 예시와 같이 Azure의 함수 앱에 로컬 코드를 게시하려면 func azure functionapp publish publish 명령을 사용합니다.

func azure functionapp publish <FunctionAppName>

이 명령은 현재 디렉터리의 프로젝트 파일을 .zip 배포 패키지로 <FunctionAppName>에 게시합니다. 프로젝트에 컴파일이 필요한 경우 배포 중에 원격으로 수행됩니다.

Java는 Maven을 사용하여 로컬 프로젝트를 Azure에 게시합니다. 다음 Maven 명령을 사용하여 Azure에 프로젝트를 게시합니다.

mvn azure-functions:deploy

이 명령을 실행하면 초기 배포 중에 pom.xml 파일의 설정에 따라 Azure 리소스가 만들어집니다. 자세한 내용은 함수 프로젝트를 Azure에 배포하기를 참조하세요.

이러한 종류의 배포에는 다음 고려 사항이 적용됩니다.

  • 게시하면 원격 기능 앱 배포의 기존 파일을 덮어씁니다.

  • 그리고 이미 Azure 구독에서 함수 앱을 작성한 상태여야 합니다. Core Tools는 프로젝트 코드를 이 함수 앱 리소스에 배포합니다. Azure CLI 또는 Azure PowerShell을 사용하여 명령 프롬프트 또는 터미널 창에서 함수 앱을 만드는 방법을 알아보려면 서버리스 실행을 위한 함수 앱 만들기를 참조하세요. Azure portal에서 이러한 리소스를 만들 수도 있습니다. 구독에 존재하지 않는 <FunctionAppName>에 게시하려고 하면 오류가 발생합니다.

  • 프로젝트 폴더는 게시하지 않아야 하는 언어별 파일 및 디렉터리를 포함할 수 있습니다. 제외된 항목은 루트 프로젝트 폴더의 .funcignore 파일에 나열됩니다.

  • 기본적으로 프로젝트는 배포 패키지에서 실행되도록 배포됩니다. 권장 배포 모드를 사용하지 않도록 설정하려면 --nozip 옵션을 사용합니다.

  • 컴파일된 프로젝트에서 원격 빌드가 수행됩니다. 이는 --no-build 옵션을 사용하여 제어할 수 있습니다.

  • --publish-local-settings 옵션을 사용하여 local.settings.json 파일의 값을 기반으로 함수 앱에서 앱 설정을 자동으로 만듭니다.

  • 함수 앱의 특정 명명된 슬롯에 게시하려면 --slot옵션을 사용합니다.

컨테이너 배포

Core Tools를 사용하면 컨테이너화된 함수 앱을 관리되는 Azure Container Apps 환경과 사용자가 관리하는 Kubernetes 클러스터에 모두 배포할 수 있습니다.

다음 func azurecontainerapps deploy 명령을 사용하여 기존 컨테이너 이미지를 Container Apps 환경에 배포합니다.

func azurecontainerapps deploy --name <APP_NAME> --environment <ENVIRONMENT_NAME> --storage-account <STORAGE_CONNECTION> --resource-group <RESOURCE_GROUP> --image-name <IMAGE_NAME> [--registry-password] [--registry-server] [--registry-username]

Azure Container Apps 환경에 배포하는 경우 다음 고려 사항이 적용됩니다.

  • 환경 및 스토리지 계정이 이미 존재해야 합니다. 제공한 스토리지 계정 연결 문자열은 배포된 함수 앱에서 사용됩니다.

  • Container Apps에 배포할 때 별도의 함수 앱 리소스를 생성할 필요가 없습니다.

  • 스토리지 연결 문자열 및 기타 서비스 자격 증명은 중요한 암호입니다. func azurecontainerapps deploy을(를) 사용하여 스크립트 파일을 안전하게 저장하고 공개적으로 액세스할 수 있는 소스 제어 시스템에 저장하지 않도록 합니다. 보안을 강화하기 위해 local.settings.json 파일을 암호화 할 수 있습니다.

자세한 내용은 Azure Functions의 Azure Container Apps 호스팅을 참조하세요.

로컬에서 앱 설정 작업

Azure의 함수 앱에서 실행하는 경우 함수에 필요한 설정은 앱 설정에 안전하게 저장됩니다. 로컬 개발 중에 이러한 설정은 local.settings.json 파일의 Values 컬렉션에 대신 추가됩니다. local.settings.json 파일은 로컬 개발 도구에서 사용하는 설정도 저장합니다.

프로젝트의 local.settings.json 파일에 있는 Values 컬렉션의 항목은 Azure에서 함수 앱의 애플리케이션 설정에 있는 항목을 미러링하기 위한 것입니다.

로컬 설정 파일로 작업할 때 다음 고려 사항이 적용됩니다.

  • local.settings.json에는 연결 문자열과 같은 비밀이 포함될 수 있으므로 원격 리포지토리에 저장해서는 안 됩니다. Core Tools를 사용하면 보안을 개선하기 위해 이 로컬 설정 파일을 암호화할 수 있습니다. 자세한 내용은 로컬 설정 파일을 참조하세요. 보안을 강화하기 위해 local.settings.json 파일을 암호화 할 수도 있습니다.

  • 기본적으로 로컬 설정은 프로젝트가 Azure에 게시될 때 자동으로 마이그레이션되지 않습니다. 사용자의 프로젝트 파일을 게시할 때 --publish-local-settings 옵션을 사용하여 이러한 설정이 Azure의 함수 앱에 추가되었는지 확인합니다. ConnectionStrings 섹션의 값은 게시되지 않습니다. 언제든지 local.settings.json 파일에서 설정을 업로드 할 수도 있습니다.

  • local.settings.json 파일에 있는 설정을 다운로드하여 Azure의 함수 앱에서 설정으로 덮어쓸 수 있습니다. 자세한 내용은 애플리케이션 설정 다운로드를 참조하세요.

  • 이 함수 앱 설정 값은 코드에서 환경 변수로 읽을 수도 있습니다. 자세한 내용은 환경 변수를 참조하세요.
  • 이 함수 앱 설정 값은 코드에서 환경 변수로 읽을 수도 있습니다. 자세한 내용은 환경 변수를 참조하세요.
  • 이 함수 앱 설정 값은 코드에서 환경 변수로 읽을 수도 있습니다. 자세한 내용은 환경 변수를 참조하세요.
  • 이 함수 앱 설정 값은 코드에서 환경 변수로 읽을 수도 있습니다. 자세한 내용은 환경 변수를 참조하세요.
  • 이 함수 앱 설정 값은 코드에서 환경 변수로 읽을 수도 있습니다. 자세한 내용은 환경 변수를 참조하세요.
  • AzureWebJobsStorage에 대해 유효한 스토리지 연결 문자열이 설정되어 있지 않고 로컬 스토리지 에뮬레이터가 사용 중이 아닌 경우 오류가 표시됩니다. Core Tools를 사용하여 Azure Storage 계정에서 특정 연결 문자열을 다운로드 할 수 있습니다.

애플리케이션 설정 다운로드

프로젝트 루트에서 다음 명령을 사용하여 Azure의 myfunctionapp12345 앱에서 모든 애플리케이션 설정을 다운로드합니다.

func azure functionapp fetch-app-settings myfunctionapp12345

이 명령은 local.settings.json 파일의 모든 기존 설정을 Azure의 값으로 덮어씁니다. 아직 없는 경우 새 항목이 컬렉션에 추가됩니다. 자세한 내용은 func azure functionapp fetch-app-settings 명령을 참조하세요.

스토리지 연결 문자열 다운로드

또한 Core Tools를 사용하면 액세스 권한이 있는 모든 스토리지 계정의 연결 문자열을 쉽게 가져올 수 있습니다. 프로젝트 루트에서 다음 명령을 사용하여 mystorage12345(이)라는 스토리지 계정에서 연결 문자열을 다운로드합니다.

func azure storage fetch-connection-string mystorage12345

이 명령은 mystorage12345 계정에 대한 연결 문자열이 포함된 local.settings.json 파일에 mystorage12345_STORAGE(이)라는 설정을 추가합니다. 자세한 내용은 func azure storage fetch-connection-string 명령을 참조하세요.

개발 중 보안을 강화하려면 local.settings.json 파일을 암호화하는 것이 좋습니다.

Azure에 로컬 설정 업로드

--publish-local-settings 옵션을 사용하지 않고 프로젝트 파일을 Azure에 게시하는 경우, 함수 앱에서 local.settings.json 파일의 설정이 설정되지 않습니다. 프로젝트 파일을 다시 게시하지 않고 설정만 업로드하려면 언제든지 --publish-settings-only 옵션으로 func azure functionapp publish을(를) 다시 실행할 수 있습니다.

다음 예제에서는 local.settings.json 파일에 있는 Values 컬렉션의 설정만 Azure의 함수 앱에 myfunctionapp12345(이)라는 이름으로 업로드합니다.

func azure functionapp publish myfunctionapp12345 --publish-settings-only

로컬 설정 파일 암호화

로컬 설정에서 연결 문자열 및 기타 중요한 데이터의 보안을 강화하기 위해 Core Tools를 사용하면 local.settings.json 파일을 암호화할 수 있습니다. 이 파일이 암호화되면 런타임은 Azure의 애플리케이션 설정과 동일한 방식으로 필요할 때 자동으로 설정을 해독합니다. 로컬로 암호화된 파일을 해독하여 설정에 사용할 수도 있습니다.

다음 명령을 사용하여 프로젝트의 로컬 설정 파일을 암호화합니다.

func settings encrypt

다음 명령을 사용하여 암호화된 로컬 설정을 해독하여 작업할 수 있습니다.

func settings decrypt

설정 파일이 암호화되고 암호 해독되면 파일의 IsEncrypted 설정도 업데이트됩니다.

바인딩 확장 구성

Functions 트리거 및 바인딩은 .NET 확장(NuGet) 패키지로 구현됩니다. 특정 바인딩 확장을 사용하려면 해당 확장을 프로젝트에 설치해야 합니다.

이 섹션은 Functions 런타임 버전 1.x에는 적용되지 않습니다. 버전 1.x에서는 지원되는 바인딩이 핵심 제품 확장에 포함되었습니다.

C# 클래스 라이브러리 프로젝트의 경우 함수에 필요한 바인딩 확장에 대한 특정 NuGet 패키지에 대한 참조를 추가하세요. C# 스크립트(.csx) 프로젝트는 확장 번들을 사용해야 합니다.

Functions는 프로젝트에서 바인딩 확장을 쉽게 사용할 수 있도록 확장 번들을 제공합니다. 확장 번들은 host.json 파일에 버전이 지정되고 정의되어 있으며, 앱에 호환되는 바인딩 확장 패키지의 전체 세트를 설치합니다. host.json에 이미 확장 번들이 활성화되어 있어야 합니다. 어떤 이유로 host.json 파일에 확장 번들을 추가하거나 업데이트해야 하는 경우 확장 번들을 참조하세요.

바인딩 확장 프로그램이나 지원되는 번들에 없는 확장 프로그램 버전을 사용해야 하는 경우에는 수동으로 확장 프로그램을 설치해야 합니다. 이러한 드문 시나리오는 func extensions install 명령을 참조하세요.

Core Tools 버전

Azure Functions Core Tools의 주 버전은 Azure Functions 런타임의 특정 주 버전에 연결됩니다. 예를 들어 Core Tools 버전 4.x는 Functions 런타임 버전 4.x를 지원합니다. 이 버전은 Functions 런타임과 Core Tools 모두에서 권장되는 주요 버전입니다. Core Tools의 최신 릴리스 버전은 Azure Functions Core Tools 리포지토리에서 확인할 수 있습니다.

다음 명령을 실행하여 현재 Core Tools 설치 버전을 확인합니다.

func --version

별도로 언급하지 않는 한 이 문서의 예제는 4.x 버전용입니다.

Core Tools 설치에는 다음과 같은 고려 사항이 적용됩니다.

  • 지정된 컴퓨터에는 Core Tools의 한 버전만 설치할 수 있습니다.

  • 최신 버전의 Core Tools로 업그레이드할 때는 원래 설치 시 사용한 것과 동일한 방법을 사용하여 업그레이드를 수행해야 합니다. 예를 들어 Windows에서 MSI를 사용하는 경우 현재 MSI를 제거하고 최신 MSI를 설치합니다. 또는 npm을 사용했다면 npm install command을(를) 다시 실행하세요.

  • Core Tools 버전 2.x 및 3.x는 지원 종료에 도달한 Functions 런타임 버전 2.x 및 3.x와 함께 사용되었습니다. 자세한 내용은 Azure Functions 런타임 버전 개요를 참조하세요.

  • Functions Runtime 버전 1.x를 사용하는 경우 Core Tools 버전 1.x가 필요하며, 이 버전은 계속 지원됩니다. 이 버전의 Core Tools는 Windows 컴퓨터에서만 로컬로 실행할 수 있습니다. 현재 버전 1.x에서 앱을 실행하고 있다면 지금 바로 버전 4.x로 마이그레이션하는 것을 고려해야 합니다.

다음 단계

Azure Functions 핵심 도구를 사용하여 Azure 함수를 개발, 테스트 및 게시하는 방법을 알아봅니다. Azure Functions 핵심 도구는 오픈 소스이며 GitHub에서 호스팅됩니다. 버그 또는 기능 요청을 제출하려면 GitHub 문제를 개설합니다.