Application Configuration Service for Tanzu 사용
참고 항목
Azure Spring Apps는 Azure Spring Cloud 서비스의 새 이름입니다. 서비스에 새 이름이 지정되었지만, 자산을 업데이트하는 동안 스크린샷, 비디오, 다이어그램과 같은 일부 위치에서는 당분간 이전 이름이 표시됩니다.
이 문서의 적용 대상:❌ 기본/표준 ✔️ 엔터프라이즈
이 문서에서는 Azure Spring Apps Enterprise 플랜에서 Application Configuration Service for VMware Tanzu를 사용하는 방법을 보여줍니다.
VMware Tanzu용 애플리케이션 구성 서비스는 상용 VMware Tanzu 구성 요소 중 하나입니다. 하나 이상의 Git 리포지토리에 정의된 속성에서 채워진 Kubernetes 네이티브 ConfigMap 리소스를 관리할 수 있습니다.
Application Configuration Service를 사용하면 모든 환경에서 애플리케이션의 외부 속성을 중앙의 한 곳에서 관리할 수 있습니다. 기본 및 표준 플랜의 Spring Cloud Config Server와 무엇이 다른지 알아보려면 Azure Spring Apps 기본 또는 표준 플랜 인스턴스를 Enterprise 플랜으로 마이그레이션의 외부 구성에 Application Configuration Service 사용 섹션을 참조하세요.
Application Configuration Service는 Gen1 및 Gen2의 두 가지 버전으로 제공됩니다. Gen1 버전은 주로 이전 버전과의 호환성을 위해 기존 고객에게 제공되며 2024년 4월 30일까지만 지원됩니다. 새 서비스 인스턴스는 Gen2를 사용해야 합니다. Gen2 버전은 flux를 백 엔드로 사용하여 Git 리포지토리와 통신하며 Gen1에 비해 더 나은 성능을 제공합니다.
다음 표에서는 하위 구성 요소 관계를 보여줍니다.
| Application Configuration Service 생성 | 하위 구성 요소 |
|---|---|
| 1세대 | application-configuration-service |
| 2세대 | application-configuration-service flux-source-controller |
다음 표에서는 참조용 벤치마크 데이터를 보여줍니다. 그러나 Git 리포지토리 크기는 성능 데이터에 상당한 영향을 미치는 핵심 요소입니다. 필요한 구성 파일만 Git 리포지토리에 저장하여 작게 유지하는 것이 좋습니다.
| Application Configuration Service 생성 | 100개 미만 패턴에서 새로 고치는 기간 | 250개 미만 패턴에서 새로 고치는 기간 | 500개 패턴에서 새로 고치는 기간 |
|---|---|---|---|
| 1세대 | 330초 | 840초 | 1500초 |
| 2세대 | 13초 | 100초 | 378초 |
또한 Gen2는 원격 Git 리포지토리에 연결할 때 추가 보안 인증을 제공합니다. Gen2는 HTTPS를 사용하는 경우 보안 연결이 필요하며 SSH 연결을 사용할 경우 올바른 호스트 키 및 호스트 알고리즘을 확인합니다.
Azure Spring Apps Enterprise 서비스 인스턴스를 만들 때 Application Configuration Service 버전을 선택할 수 있습니다. 기본 버전은 Gen1입니다. 인스턴스를 만든 후 Gen2로 업그레이드할 수도 있지만 다운그레이드는 지원되지 않습니다. 업그레이드는 가동 중지 시간이 0이지만 프로덕션 환경으로 이동하기 전에 스테이징 환경에서 테스트하는 것이 좋습니다.
필수 조건
- Application Configuration Service를 사용하도록 설정하고 프로비전한 Azure Spring Apps Enterprise 플랜 인스턴스. 자세한 내용은 빠른 시작: 엔터프라이즈 플랜을 사용하여 Azure Spring Apps에 앱 빌드 및 배포를 참조하세요.
Application Configuration Service 설정 관리
Application Configuration Service는 구성 파일을 저장하기 위한 Azure DevOps, GitHub, GitLab 및 Bitbucket을 지원합니다.
서비스 설정을 관리하려면 설정 섹션을 엽니다. 이 섹션에서는 다음과 같은 주요 측면을 구성할 수 있습니다.
- 세대: 서비스 세대를 업그레이드합니다.
- 새로 고침 간격: 서비스가 Git 리포지토리의 업데이트를 확인하는 빈도를 조정합니다.
- 리포지토리: 새 항목을 추가하거나 기존 항목을 수정합니다. 이 함수를 사용하면 서비스 모니터가 데이터를 끌어오는 데 사용하는 리포지토리를 제어할 수 있습니다.
현재 서비스 세대가 Gen1인 경우 더 나은 성능을 위해 Gen2로 업그레이드할 수 있습니다. 자세한 내용은 Gen1에서 Gen2로 업그레이드 섹션을 참조하세요.
새로 고침 간격은 리포지토리에서 업데이트를 확인하는 빈도(초)를 지정합니다. 최솟값은 0이며 자동 새로 고침을 사용하지 않도록 설정합니다. 최적의 성능을 위해 이 간격을 최솟값 60초로 설정합니다.
다음 표에서는 각 리포지토리 항목의 속성을 설명합니다.
| 속성 | 필수 여부 | 설명 |
|---|---|---|
Name |
예 | 각 Git 리포지토리에 레이블을 지정하는 고유한 이름입니다. |
Patterns |
예 | Git 리포지토리에서 검색할 패턴입니다. 각 패턴에 대해 {애플리케이션}-{프로필}.yml이 아닌 {애플리케이션} 또는 {애플리케이션}/{프로필}과 같은 형식을 사용합니다. 패턴을 쉼표로 구분합니다. 자세한 내용은 이 문서의 패턴 섹션을 참조하세요. |
URI |
예 | Git URI(예: https://github.com/Azure-Samples/piggymetrics-config 또는 git@github.com:Azure-Samples/piggymetrics-config) |
Label |
예 | Git 리포지토리에서 검색할 분기 이름입니다. |
Search path |
아니요 | Git 리포지토리의 하위 디렉터리를 검색하는 선택적 검색 경로이며, 쉼표로 구분됩니다. |
패턴
패턴에서 정의한 내용을 사용하여 Git 백 엔드에서 구성을 가져옵니다. 패턴은 다음 가이드라인에 설명된 대로 {애플리케이션}/{프로필}의 조합입니다.
- {애플리케이션} - 구성을 검색 중인 애플리케이션의 이름입니다.
application값은 기본 애플리케이션으로 간주되며 여러 애플리케이션에서 공유되는 구성 정보를 포함합니다. 다른 모든 값은 특정 애플리케이션을 참조하며 특정 애플리케이션에 대한 속성과 기본 애플리케이션에 대한 공유 속성을 모두 포함합니다. - {profile} - 선택 사항입니다. 속성을 검색할 수 있는 프로필의 이름입니다. 빈 값 또는 값
default에는 프로필 간에 공유되는 속성이 포함됩니다. 기본값 이외의 값에는 지정된 프로필의 속성과 기본 프로필의 속성이 포함됩니다.
인증
다음 스크린샷은 Application Configuration Service에서 지원하는 세 가지 유형의 리포지토리 인증을 보여줍니다.
다음 목록에서는 세 가지 인증 유형을 설명합니다.
퍼블릭 리포지토리.
공용 리포지토리를 사용할 때 추가 인증 구성이 필요하지 않습니다. 인증 양식에서 퍼블릭을 선택합니다.
다음 표에서는 공용 Git 리포지토리를 설정하는 데 사용할 수 있는 구성 가능한 속성을 보여줍니다.
속성 필수 여부 설명 CA certificate아니요 Git 리포지토리 URL에 자체 서명된 인증서를 사용하는 경우에만 필요합니다. 기본 인증을 사용하는 프라이빗 리포지토리.
다음 표는 기본 인증으로 프라이빗 Git 리포지토리를 설정하는 데 사용할 수 있는 구성 가능한 속성을 보여줍니다.
속성 필수 여부 설명 username예 리포지토리에 액세스하는 데 사용되는 사용자 이름입니다. password예 리포지토리에 액세스하는 데 사용되는 암호입니다. CA certificate아니요 Git 리포지토리 URL에 자체 서명된 인증서를 사용하는 경우에만 필요합니다. SSH 인증을 사용하는 프라이빗 리포지토리.
다음 표는 SSH를 사용하여 프라이빗 Git 리포지토리를 설정하는 데 사용할 수 있는 구성 가능한 속성을 보여줍니다.
속성 필수 여부 설명 Private key예 Git 사용자를 식별하는 프라이빗 키입니다. 전달 구로 암호화된 프라이빗 키는 지원되지 않습니다. Host keyGen1은 필수 아님
Gen2는 필수Git 서버의 호스트 키입니다. 명령줄에서 Git를 통해 서버에 연결하는 경우 호스트 키는 .ssh/known_hosts 파일에 있습니다. 알고리즘 접두사는 포함하지 마세요. Host key algorithm에 지정되어 있습니다.Host key algorithmGen1은 필수 아님
Gen2는 필수hostKey의 알고리즘이며ssh-dss,ssh-rsa,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384및ecdsa-sha2-nistp521중 하나입니다. (Host key를 제공하는 경우 필수입니다.)Strict host key checking아니요 제공된 Host key를 사용할 때 오류가 발생하는 경우 백 엔드를 무시할지 여부를 나타내는 선택적 값입니다. 유효한 값은true및false입니다. 기본값은true입니다.
대상 URI에 대한 액세스의 유효성을 검사하려면 유효성 검사를 선택합니다. 유효성 검사가 성공적으로 완료되면 적용을 선택하여 구성 설정을 업데이트합니다.
Gen1에서 Gen2로 업그레이드
Application Configuration Service Gen2는 특히 많은 수의 구성 파일이 있는 경우 Gen1에 비해 더 나은 성능을 제공합니다. 특히 Gen1이 곧 사용 중지되므로 Gen2를 사용하는 것이 좋습니다. Gen1에서 Gen2로의 업그레이드는 가동 중지 시간이 0이지만 프로덕션 환경으로 이동하기 전에 스테이징 환경에서 테스트하는 것이 좋습니다.
Gen2에는 SSH 인증을 사용하는 경우 Gen1보다 더 많은 구성 속성이 필요합니다. Gen2에서 작동하도록 애플리케이션의 구성 속성을 업데이트해야 합니다. 다음 표에는 SSH 인증을 사용할 때 Gen2에 필요한 속성을 보여줍니다.
| 속성 | 설명 |
|---|---|
Host key |
Git 서버의 호스트 키입니다. 명령줄에서 Git를 통해 서버에 연결하는 경우 호스트 키는 .ssh/known_hosts 파일에 있습니다. 알고리즘 접두사는 포함하지 마세요. Host key algorithm에 지정되어 있습니다. |
Host key algorithm |
hostKey의 알고리즘이며 ssh-dss, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384 또는 ecdsa-sha2-nistp521 중 하나입니다. |
Gen1에서 Gen2로 업그레이드하려면 다음 단계를 사용합니다.
Azure Portal에서 Azure Spring Apps 서비스 인스턴스에 대한 Application Configuration Service 페이지로 이동합니다.
설정 섹션을 선택한 다음, 세대 드롭다운 메뉴에서 Gen 2를 선택합니다.
유효성 검사를 선택하여 대상 URI에 대한 액세스의 유효성을 검사합니다. 유효성 검사가 성공적으로 완료되면 적용을 선택하여 구성 설정을 업데이트합니다.
다국어 지원
Application Configuration Service는 Spring Boot 애플리케이션에서 원활하게 작동합니다. 이 서비스에서 생성된 속성은 Spring Boot에서 외부 구성으로 가져와 Bean에 삽입됩니다. 추가 코드를 작성할 필요가 없습니다. Spring 환경 추상화를 통해 액세스되는 @Value 주석을 통해 값을 사용하거나, @ConfigurationProperties 주석을 통해 구조화된 개체에 바인딩할 수 있습니다.
Application Configuration Service는 dotNET, Go, Python 등과 같은 다국어 앱도 지원합니다. 앱에서 다국어 앱을 배포하는 동안 로드하도록 지정한 구성 파일에 액세스하려면 AZURE_SPRING_APPS_CONFIG_FILE_PATH 등과 같은 이름으로 환경 변수를 통해 검색할 수 있는 파일 경로에 액세스합니다. 해당 경로에서 의도한 모든 구성 파일에 액세스할 수 있습니다. 구성 파일의 속성 값에 액세스하려면 앱에 대한 기존 읽기/쓰기 파일 라이브러리를 사용합니다.
새로 고침 전략
Git 리포지토리에서 구성을 수정하고 커밋할 때 이러한 변경 내용이 애플리케이션에 반영되기 전에 몇 가지 단계가 필요합니다. 이 프로세스는 자동화되어 있지만 각각 고유한 타이밍과 동작을 갖는 다음과 같은 개별 단계와 구성 요소를 포함합니다.
- 애플리케이션 구성 서비스에 의한 폴링: 애플리케이션 구성 서비스는 정기적으로 백 엔드 Git 리포지토리를 폴링하여 변경 내용을 검색합니다. 이 폴링은 새로 고침 간격으로 정의된 설정된 빈도로 발생합니다. 변경 내용이 검색되면 애플리케이션 구성 서비스가 Kubernetes
ConfigMap을 업데이트합니다. ConfigMap업데이트 및 kubelet 캐시와의 상호 작용: Azure Spring Apps에서 이ConfigMap은 관련 애플리케이션에 데이터 볼륨으로 탑재됩니다. 그러나 kubelet이ConfigMap의 변경 내용을 인식하기 위해 캐시를 새로 고치는 빈도로 인해 이 프로세스에는 자연스러운 지연이 있습니다.- 애플리케이션이 업데이트된 구성을 읽습니다. Azure Spring Apps 환경에서 실행되는 애플리케이션은 업데이트된 구성 값에 액세스할 수 있습니다. Spring 컨텍스트의 기존 Bean은 업데이트된 구성을 사용하기 위해 자동으로 새로 고쳐지지 않습니다.
이러한 단계는 다음 다이어그램에 요약되어 있습니다.
특정 요구 사항에 맞게 애플리케이션 구성 서비스의 폴링 새로 고침 간격을 조정할 수 있습니다. 애플리케이션에 업데이트된 구성을 적용하려면 다시 시작 또는 새로 고침 작업이 필요합니다.
Spring 애플리케이션에서 속성은 Spring 컨텍스트 내에서 Bean으로 유지되거나 참조됩니다. 새 구성을 로드하려면 다음 방법을 사용하는 것이 좋습니다.
애플리케이션을 다시 시작합니다. 애플리케이션을 다시 시작하면 항상 새 구성이 로드됩니다.
Spring Actuator를 통해 구성 클라이언트에 노출된
/actuator/refresh엔드포인트를 호출합니다.이 방법을 사용하려면 구성 클라이언트의 pom.xml 파일에 다음 종속성을 추가합니다.
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>다음 구성을 추가하여 actuator 엔드포인트를 사용하도록 설정할 수도 있습니다.
management.endpoints.web.exposure.include=refresh, bus-refresh, beans, env/actuator/refresh엔드포인트를 호출하여 속성 원본을 다시 로드하면@RefreshScope주석이 있는 빈에서@Value로 바인딩된 특성이 새로 고쳐집니다.@Service @Getter @Setter @RefreshScope public class MyService { @Value private Boolean activated; }다음 예와 같이 애플리케이션 엔드포인트와 함께 컬을 사용하여 새 구성을 새로 고칩니다.
curl -X POST http://{app-endpoint}/actuator/refresh파일 변경을 관찰하고 요청 시 컨텍스트를 새로 고치려면
FileSystemWatcher를 사용합니다.FileSystemWatcher는 특정 디렉터리에서 파일 변경 내용을 감시하는spring-boot-devtools와 함께 제공되는 클래스입니다. 또는 유사한 함수를 가진 다른 유틸리티를 사용할 수 있습니다. 이전 옵션을 사용하려면 사용자가 새로 고침을 적극적으로 시작해야 하지만 후자는 파일 변경 내용을 모니터링하고 업데이트가 검색되면 자동으로 새로 고침을 호출할 수 있습니다. Polyglot 지원 섹션에 언급된 대로 환경 변수AZURE_SPRING_APPS_CONFIG_FILE_PATH를 사용하여 파일 경로를 검색할 수 있습니다.
Application Configuration Service 설정 구성
다음 단계에 따라 Application Configuration Service를 구성합니다.
Application Configuration Service를 선택합니다.
개요를 선택하여 Application Configuration Service의 실행 상태와 할당된 리소스를 확인합니다.
설정을 선택하고 Git 백 엔드 정보를 사용하여 리포지토리 섹션에서 새 항목을 추가합니다.
유효성 검사를 선택하여 대상 URI에 대한 액세스의 유효성을 검사합니다. 유효성 검사가 성공적으로 완료되면 적용을 선택하여 구성 설정을 업데이트합니다.
Gen2에 대한 자체 서명된 인증서를 사용하여 Git 백 엔드에 액세스하도록 TLS 인증서 구성
이 단계는 선택 사항입니다. Git 백 엔드에 자체 서명된 인증서를 사용하는 경우 Git 백 엔드에 액세스하도록 TLS 인증서를 구성해야 합니다.
먼저 Azure Spring Apps에 인증서를 업로드해야 합니다. 자세한 내용은 Azure Spring Apps의 애플리케이션에서 TLS/SSL 인증서 사용의 인증서 가져오기 섹션을 참조하세요.
다음 단계에 따라 TLS 인증서를 구성합니다.
서비스 리소스로 이동한 다음, Application Configuration Service를 선택합니다.
설정을 선택하고 Git 백 엔드 정보를 사용하여 리포지토리 섹션에서 새 항목을 추가하거나 업데이트합니다.
애플리케이션에서 Application Configuration Service 사용
Git 백 엔드에서 Application Configuration Service를 사용하고 중앙 집중식 구성을 사용하는 경우 앱을 Application Configuration Service에 바인딩해야 합니다.
다음 단계에 따라 애플리케이션에서 Application Configuration Service를 사용합니다.
앱 바인딩 탭을 엽니다.
앱 바인딩을 선택하고 드롭다운에서 앱 하나를 선택합니다. 적용을 선택하여 바인딩합니다.
참고 항목
바인딩/바인딩 해제 상태를 변경하고 앱을 다시 시작하거나 다시 배포해야만 바인딩이 적용됩니다.
탐색 메뉴에서 앱을 선택하면 모든 앱 목록을 볼 수 있습니다.
name열의 패턴을 구성하려면 대상 앱을 선택합니다.탐색 창에서 구성을 선택한 다음, 일반 설정을 선택합니다.
구성 파일 패턴 드롭다운 목록에서 하나 이상의 패턴을 선택합니다. 자세한 내용은 패턴 섹션을 참조하세요.
저장을 선택합니다.
Application Configuration Service에 앱 바인딩
이제 새 앱을 만들 때 애플리케이션을 Application Configuration Service에 바인딩하도록 선택할 수 있습니다.
다음 단계에 따라 새 앱을 만들고 Application Configuration Service에 바인딩합니다.
탐색 창에서 앱을 선택하여 모든 앱을 표시합니다.
새 앱을 만들려면 앱 만들기를 선택합니다.
새 앱의 이름을 입력합니다.
바인딩 탭을 선택한 다음, 드롭다운에서 Application Configuration Service를 선택합니다.
만들기를 선택하여 앱 만들기를 완료하고 앱을 Application Configuration Service에 바인딩합니다.
서비스를 만든 후 Application Configuration Service 사용/사용 안 함
Azure Portal 또는 Azure CLI를 사용하여 서비스를 만든 후 Application Configuration Service를 사용하거나 사용하지 않도록 설정할 수 있습니다. Application Configuration Service를 사용하지 않도록 설정하기 전에 모든 앱을 바인딩 해제해야 합니다.
다음 단계에 따라 Application Configuration Service를 사용하거나 사용하지 않도록 설정합니다.
- 서비스 리소스로 이동한 다음, Application Configuration Service를 선택합니다.
- 관리를 선택합니다.
- Enable Application Configuration Service를 선택하거나 선택 취소한 다음, 저장을 선택합니다.
- 이제 Application Configuration Service 페이지에서 Application Configuration Service의 상태를 볼 수 있습니다.
ConfigMap에서 구성 파일 검사
다음 섹션에서는 관련 Kubernetes ConfigMap의 업스트림 Git 리포지토리에서 Application Configuration Service가 끌어온 구성 파일의 콘텐츠를 검사하는 방법을 보여 줍니다. 자세한 내용은 이 문서의 새로 고침 전략 섹션을 참조하세요.
Azure 역할 할당
먼저 Azure 역할 Azure Spring Apps Application Configuration Service Config File Pattern Reader Role이 할당되어 있어야 합니다.
Azure 역할을 할당하려면 다음 단계를 따릅니다.
Azure Portal을 열고 Azure Spring Apps 서비스 인스턴스로 이동합니다.
왼쪽 탐색 창에서 액세스 제어(IAM)를 선택합니다.
액세스 제어(IAM) 페이지에서 추가를 선택한 다음, 역할 할당 추가를 선택합니다.
역할 할당 추가 페이지의 이름 목록에서 대상 역할을 검색하여 선택한 후 다음을 선택합니다.
멤버를 선택한 다음 사용자 이름을 검색하여 선택합니다.
검토 + 할당을 선택합니다.
Azure CLI를 사용하여 구성 파일 검사
패턴별로 구성 파일의 콘텐츠를 보려면 다음 명령을 사용합니다.
az spring application-configuration-service config show \
--resource-group <resource-group-name> \
--service <Azure-Spring-Apps-instance-name> \
--config-file-pattern <pattern>
이 명령은 다음 예와 유사한 JSON 출력을 생성합니다.
{
"configurationFiles": {
"application.properties": [
"example.property.application.name: example-service",
"example.property.cloud: Azure"
]
},
"metadata": {
"gitRevisions": "[{\"url\":\"{gitRepoUrl}\",\"revision\":\"{revisionInfo}\"}]"
}
}
참고 항목
Gen1 버전의 애플리케이션 구성 서비스에서는 metadata 및 gitRevisions 속성을 사용할 수 없습니다.
또한 이 명령을 --export-path {/path/to/target/folder} 매개 변수와 함께 사용하여 구성 파일을 지정된 폴더로 내보낼 수도 있습니다. 상대 경로와 절대 경로를 모두 지원합니다. 경로를 지정하지 않으면 명령은 기본적으로 현재 디렉터리의 경로를 사용합니다.
앱에서 구성 파일 검사
이 문서의 애플리케이션과 함께 애플리케이션 구성 서비스 사용 섹션에 설명된 대로 앱을 애플리케이션 구성 서비스에 바인딩하고 앱 배포를 위한 패턴을 설정한 후 ConfigMap 패턴에 대한 구성 파일이 포함된 파일은 애플리케이션 컨테이너에 탑재되어야 합니다. 다음 단계에서 앱 배포의 각 인스턴스에서 구성 파일을 확인합니다.
애플리케이션 인스턴스 중 하나에 연결합니다. 자세한 내용은 문제 해결을 위해 앱 인스턴스에 연결을 참조하세요.
구성 파일이 포함된 폴더를 찾으려면
echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH명령을 사용합니다. 다음 예와 같이 위치 목록이 쉼표로 구분되어 표시됩니다.$ echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH /etc/azure-spring-cloud/configmap/acs-default-payment-default-e9d46,/etc/azure-spring-cloud/configmap/acs-default-catalog-default-616f4cat와 같은 명령을 사용하여 구성 파일의 콘텐츠를 확인합니다.
참고 항목
Git 수정 버전 정보는 앱에서 확인할 수 없습니다.
로그 확인
다음 섹션에서는 Azure CLI 또는 Azure Portal을 사용하여 애플리케이션 로그를 보는 방법을 보여줍니다.
실시간 로그 스트리밍 사용
Azure CLI를 사용하여 실시간으로 로그를 스트리밍할 수 있습니다. 자세한 내용은 실시간으로 Azure Spring Apps 관리형 구성 요소 로그 스트리밍을 참조하세요. 다음 예제에서는 Azure CLI 명령을 사용하여 application-configuration-service 및 flux-source-controller 하위 구성 요소에 대한 새 로그를 지속적으로 스트리밍하는 방법을 보여 줍니다.
application-configuration-service에 대한 로그를 스트리밍하려면 다음 명령을 사용합니다.
az spring component logs \
--resource-group <resource-group-name> \
--service <Azure-Spring-Apps-instance-name> \
--name application-configuration-service \
--all-instances \
--follow
flux-source-controller에 대한 로그를 스트리밍하려면 다음 명령을 사용합니다.
az spring component logs \
--resource-group <resource-group-name> \
--service <Azure-Spring-Apps-instance-name> \
--name flux-source-controller \
--all-instances \
--follow
Log Analytics 사용
다음 섹션에서는 Log Analytics를 사용하여 시스템 로그를 켜고 보는 방법을 보여줍니다.
Log Analytics에 대한 진단 설정
Application Configuration Service에 대한 로그를 쿼리하려면 먼저 시스템 로그를 켜고 Log Analytics 인스턴스로 로그를 보내야 합니다. Azure Portal에서 시스템 로그를 사용하도록 설정하려면 다음 단계를 수행합니다.
Azure Spring Apps 인스턴스를 엽니다.
탐색 창에서 진단 설정을 선택합니다.
진단 설정 추가를 선택하거나 기존 설정에 대한 편집 설정을 선택합니다.
로그 섹션에서 시스템 로그 범주를 선택합니다.
대상 세부 정보 섹션에서 Log Analytics 작업 영역으로 보내기를 선택한 다음, 작업 영역을 선택합니다.
저장을 선택하여 설정을 업데이트합니다.
Log Analytics에서 로그 확인
Azure Portal을 사용하여 application-configuration-service 및 flux-source-controller의 로그를 확인하려면 다음 단계를 수행합니다.
시스템 로그가 켜져 있는지 확인합니다. 자세한 내용은 Log Analytics에 대한 진단 설정 섹션을 참조하세요.
Azure Spring Apps 인스턴스를 엽니다.
탐색 메뉴에서 로그를 선택한 다음, 개요를 선택합니다.
쿼리 편집 창에서 다음과 같은 샘플 쿼리를 사용합니다. 시간 범위를 조정한 다음, 실행을 선택하여 로그를 검색합니다.
application-configuration-service에 대한 로그를 보려면 다음 쿼리를 사용합니다.AppPlatformSystemLogs | where LogType in ("ApplicationConfigurationService") | project TimeGenerated , ServiceName , LogType, Log , _ResourceId | limit 100
flux-source-controller에 대한 로그를 보려면 다음 쿼리를 사용합니다.AppPlatformSystemLogs | where LogType in ("Flux") | project TimeGenerated , ServiceName , LogType, Log , _ResourceId | limit 100
참고 항목
Log Analytics에서 로그를 사용할 수 있을 때까지 몇 분 정도 지연될 수 있습니다.
알려진 문제 해결
최신 변경 내용이 애플리케이션에 반영되지 않으면 새로 고침 전략 섹션에 따라 다음 항목을 확인합니다.
- 다음 항목을 확인하여 Git 리포지토리가 올바르게 업데이트되었는지 확인합니다.
- 원하는 구성 파일 변경 내용의 분기가 업데이트되었는지 확인합니다.
- 애플리케이션 구성 서비스에 구성된 패턴이 업데이트된 구성 파일과 일치하는지 확인합니다.
- 애플리케이션이 애플리케이션 구성 서비스에 바인딩되어 있는지 확인합니다.
- 이 문서의 ConfigMap에서 구성 파일 검사 섹션에 설명된 대로 애플리케이션에서 사용하는 패턴에 대한 구성 파일이 포함된
ConfigMap이 업데이트되었는지 확인합니다. 업데이트되지 않은 경우 티켓을 제출합니다. - 이 문서의 앱에서 구성 파일 검사 섹션에 설명된 대로
ConfigMap이 애플리케이션에 파일로 탑재되었는지 확인합니다. 파일이 업데이트되지 않으면 Kubernetes 새로 고침 간격(1분)을 기다리거나 애플리케이션을 다시 시작하여 강제로 새로 고칩니다.
이러한 항목을 확인한 후 애플리케이션은 업데이트된 구성을 읽을 수 있어야 합니다. 애플리케이션이 여전히 업데이트되지 않으면 티켓을 제출합니다.