nomos 명령어 사용

nomos 명령어(Windows에서는 nomos.exe)는 워크스테이션 또는 노트북과 같이 로컬로 설치할 수 있는 선택적인 명령줄 도구입니다. nomos 명령어를 사용하여 Config Management Operator와 상호작용하고 저장소에 커밋하기 전에 구성의 구문을 검사하고 Anthos Config Management, 클러스터, 저장소의 문제를 디버깅할 수 있습니다.

기본 요건

nomos 명령어를 사용하여 클러스터와 상호작용하기 위해서는 Operator가 대상 클러스터에 이미 설치된 상태여야 하고, 대상 클러스터로 인증하도록 kubectl 명령어가 구성되어 있어야 합니다. 자세한 내용은 Anthos Config Management 설치를 참조하세요.

nomos 명령어 설치

nomos 명령어는 Go 코드에서 컴파일된 바이너리입니다. 선택사항이며 기본 Anthos Config Management 설치에는 포함되어 있지 않습니다.

각 버전의 Anthos Config Management에 대한 nomos 명령어를 다운로드하려면 다운로드를 참조하세요.

참고" Anthos Config Management에는 활성 Anthos 권한이 필요합니다. 그렇지 않으면 다운로드가 404 File not found 오류와 함께 실패합니다.
자세한 내용은 Anthos의 가격 책정을 참조하세요.

macOS 클라이언트와 Linux 클라이언트용 추가 단계

바이너리를 다운로드하면 실행할 수 있도록 구성합니다.

chmod +x /path/to/nomos

시스템이 바이너리를 검색하는 /usr/local/bin과 같은 위치로 명령어를 이동하거나, 해당 정규화된 경로를 사용하여 명령어를 실행할 수 있습니다.

기본 사용법

nomosnomos.exe 명령어에는 저장소 초기화, 구문 오류 검사, 등록된 각 클러스터 상태 가져오기, 저장소를 일련의 CustomResourceDefinitions로 표시를 위한 하위 명령어가 포함되어 있습니다.

기본 명령어 구문을 보려면 --help 인수를 사용합니다.

nomos --help

nomos 명령어는 저장소의 로컬 클론에서 읽습니다. --path 플래그를 사용하여 저장소의 최상위 수준 위치를 지정합니다. 기본적으로 --path. 또는 현재 디렉터리로 설정됩니다.

nomos --path=path/to/your/repo status

설치 상태 검사

nomos status 명령어를 사용하여 Anthos Config Management가 모든 클러스터에 올바르게 설치되었고 구성되었는지 확인할 수 있습니다. Anthos Config Management가 실행되지 못하게 하는 오류를 보고합니다. 예를 들면 다음과 같습니다.

nomos status
Context             Status           Last Synced Token
-------             ------           -----------------
managed-cluster-1   NOT INSTALLED
managed-cluster-2   NOT CONFIGURED
managed-cluster-3   SYNCED           f52a11e4

Config Management Errors:
managed-cluster-2   missing git-creds Secret

이 출력에서 Anthos Config Management는 managed-cluster-1에 설치되지 않습니다. managed-cluster-2에는 설치되었지만 구성되지 않았습니다. managed-cluster-3에서는 설치되었고 올바르게 실행 중입니다.

또한 managed-cluster-2가 구성되지 않은 이유는 git-creds 보안 비밀이 없기 때문입니다.

새 저장소 초기화

새 Anthos Config Management 저장소를 초기화하려면 빈 디렉터리를 작성하고 변경한 후 새 Git 저장소를 초기화한 후 nomos init 명령어를 실행하세요.

mkdir my-repo
cd my-repo
git init
nomos init

그러면 system/, cluster/, namespaces/ 디렉터리를 포함하여 저장소의 기본 디렉터리 구조가 생성됩니다.

저장소에서 오류 확인

저장소에 구성을 커밋하려면 먼저 nomos vet 명령어를 사용하여 저장소에 있는 구성의 구문 및 유효성을 검사합니다.

nomos vet

구문 오류가 발견되면 nomos vet 명령어가 0이 아닌 상태로 종료되고 오류 메시지를 STDERR에 로깅합니다.

nomos vet에서 유형이 네임스페이스인지 여부를 판별할 수 없는 경우 nomos는 API 서버에 연결합니다. nomos는 핵심 Kubernetes 유형 및 Anthos Config Management CRD를 이해하므로 해당 선언된 CRD가 없는 CR이 있는 경우에만 API 서버에 연결을 시도합니다. 이 경우 API 서버에 CRD가 적용되지 않으면 nomos vet오류를 반환합니다. 이 점검을 사용 불가능하게 하고 누락된 CRD로 인한 오류를 억제하려면 --no-api-server-check 플래그를 전달하세요.

커밋할 때 구문 오류 자동 검사

JSON 또는 YAML 오류가 있는 파일을 커밋하면 Anthos Config Management는 변경사항을 적용하지 않습니다. 그러나 클라이언트 측 또는 서버 측 후크를 사용하면 저장소에 이러한 유형의 오류가 발생하지 않도록 방지할 수 있습니다.

Git 커밋 전 후크에서 nomos vet 사용

저장소의 로컬 Git 클론에 변경사항을 커밋할 때 구문 오류를 검사하도록 nomos vet를 실행하는 커밋 전 후크를 구성할 수 있습니다. 커밋 전 후크가 0이 아닌 상태로 종료되면 git commit 작업이 실패합니다.

nomos vet 명령어를 커밋 전 후크로 실행하려면 저장소에서 .git/hooks/pre-commit 파일을 수정합니다(.git. 문자로 시작됨). 이 파일을 수동으로 만들어야 할 수도 있습니다. 스크립트에서 새 줄에 nomos vet 명령어를 추가합니다. --path 인수는 선택사항입니다.

nomos vet --path=/path/to/repo

pre-commit 파일이 실행 가능한지 확인합니다.

chmod +x .git/hooks/pre-commit

이제 저장소 클론에서 git commit 명령어를 실행하면 nomos vet가 자동으로 실행됩니다.

저장소의 .git/ 디렉터리 콘텐츠는 저장소 자체에서 추적되지 않으며, 동일한 위치에 있는 저장소에 커밋될 수 없습니다. 저장소에 Git 후크용 디렉터리를 만들 수 있으며, 이 저장소를 사용하는 사용자는 후크를 자신의 로컬 클론의 적절한 위치에 복사할 수 있습니다.

서버 측 후크에서 nomos vet 사용

Git은 git push 작업 중에 클라이언트가 아닌 서버에서 검사를 실행하는 메커니즘을 제공합니다. 검사가 실패하면 git push도 실패합니다. 이러한 서버 측 후크는 클라이언트에서 우회될 수 없습니다. 서버 측 후크를 구성하는 방법은 Git 서버가 호스팅된 방식에 따라 다릅니다. 자세한 내용은 다음 링크 중 하나를 참조하거나 Git 호스팅 서비스 관련 문서를 확인하세요.

저장소에서 모든 구성 결과 보기

nomos hydrate 명령어를 사용하여 등록된 각 클러스터에 있는 저장소의 조합된 콘텐츠를 볼 수 있습니다.

옵션 없이 nomos hydrate를 실행하면 현재 작업 디렉터리에 compiled/ 디렉터리가 생성됩니다. 이 디렉터리 내에 등록된 각 클러스터에 대한 하위 디렉터리가 Operator에서 클러스터에 적용할 완전히 확인된 구성과 함께 생성됩니다.

디렉터리 경로를 명령어 인수로 제공하여 출력 디렉터리의 이름을 지정할 수 있습니다.

nomos hydrate [/path/to/directory]

출력을 단일 클러스터 또는 클러스터 목록으로 제한하려면 --clusters 플래그를 사용하고 쉼표로 구분된 클러스터 이름 목록을 제공합니다.

nomos view의 동작을 에뮬레이션하고 유효 구성을 단일 파일로 저장하려면 --flat 플래그를 사용합니다.

자세한 내용을 보려면 --help 플래그를 사용하세요.

nomos hydrate --flat

nomos view

Anthos Config Management는 저장소에서 구성을 가져 오면 ClusterConfig 또는 NamespaceConfig 유형의 CustomResourceDefinitions(CRD)로 변환합니다. nomos view 명령어를 사용하면 저장소의 현재 상태로부터 발생한 CRD를 JSON 형식으로 볼 수 있습니다. 이를 통해 변경사항을 커밋하기 전에 또는 nomos vet 명령어를 사용해도 명확하게 밝혀지지 않은 구성 문제를 디버깅할 수 있습니다.

nomos view --path=/path/to/your/repo

클러스터의 오류 검사

Git 커밋을 저장소에 푸시할 때마다 Operator는 변경사항을 감지하고 새로운 구성을 등록된 모든 클러스터에 적용합니다. nomos status 명령어를 사용하여 등록된 모든 클러스터에서 Anthos Config Management 상태를 모니터링할 수 있습니다. 각 클러스터에 대해 클러스터에 마지막으로 적용된 Git 커밋의 해시를 보고하고 최근 변경사항을 적용하려고 시도하는 동안 발생한 모든 오류를 보고합니다. 예를 들면 다음과 같습니다.

nomos status
Context                 Status      Last Synced Token
-------                 ------      -----------------
managed-cluster-1       SYNCED      f52a11e4
managed-cluster-2       PENDING     9edf8444
managed-cluster-3       ERROR       9edf8444
managed-cluster-4       NOT INSTALLED
managed-cluster-5       SYNCED      f52a11e4

Config Management Errors:
managed-cluster-3       KNV1021: No CustomResourceDefinition is defined for the resource in the cluster.

두 클러스터가 가장 최근 변경사항을 동기화했고, 한 클러스터가 아직 동기화를 수행하는 중이고, 다른 클러스터에는 변경사항 적용을 방해하는 오류가 있는 것을 볼 수 있습니다. 이 경우에는 다른 클러스터가 설치한 CRD가 managed-cluster-3에 누락된 것으로 표시됩니다.

기본적으로 nomos status 명령어는 각 클러스터의 상태를 출력한 후 종료됩니다. 하지만 poll 플래그를 사용하면 명령어를 연속적으로 실행하고, 정기적인 간격으로 상태 테이블을 다시 출력할 수 있습니다.

nomos status --poll 2s

마지막 동기화된 토큰 정보

nomos status는 해당 출력에서 Last Synced Token 아래의 클러스터에 적용된 최근 Git 커밋 해시를 표시합니다. 이 값을 가져오려면 Repo 객체를 쿼리하고 status.sync 필드를 확인합니다.

kubectl get repos.configmanagement.gke.io -o yaml
apiVersion: v1
kind: Repo
items:
- status:
    sync:
      lastUpdate: "2019-09-26T10:17:57Z"
      latestToken: f1739af550912034139aca51e382dc50c4036ae0

이 커밋은 클러스터에 대한 최근 커밋입니다. 그러나 클러스터의 모든 네임스페이스가 각 커밋의 영향을 받지는 않습니다. 특정 네임스페이스에서 최신 커밋을 보려면 해당 NamespaceConfig 객체를 쿼리하고 status 필드를 확인하세요. 예를 들면 다음과 같습니다.

kubectl get namespaceconfigs.configmanagement.gke.io my-namespace -o yaml
apiVersion: configmanagement.gke.io/v1
kind: NamespaceConfig
status:
  syncState: synced
      lastUpdate: "2019-09-26T08:24:32Z"
      latestToken: 1850bad9419d3baec8af220c15d5e952dbeb3b25

네임스페이스가 커밋의 영향을 받을 수 있더라도 네임스페이스의 모든 리소스가 영향을 받지는 않을 수 있습니다. 특정 리소스에 대해 최근에 동기화된 커밋을 찾으려면 특정 리소스를 쿼리하고 metadata.annotations.configmanagement.gke.io/token을 확인하세요. 예를 들면 다음과 같습니다.

kubectl get clusterrolebindings.rbac.authorization.k8s.io my-role-binding -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    configmanagement.gke.io/token: e56b09554ca8004a2c38185a4ed11364fd6986c4

버그 신고 만들기

Google Cloud 지원의 도움이 필요한 Anthos Config Management에 문제가 있는 경우 nomos bugreport 명령어를 사용하여 유용한 디버그 정보를 제공할 수 있습니다.

nomos bugreport

이 명령어는 kubectl 컨텍스트에서 설정된 Kubernetes 클러스터에 대한 정보가 있는 타임스탬프 zip 파일을 생성합니다.

이 파일에는 Anthos Config Management Pod의 로그가 포함되어 있습니다. Anthos Config Management와 동기화된 리소스의 정보는 포함하지 않습니다.

문제 해결

Linux에서는 nomos 명령어를 실행할 때 다음 오류가 표시될 수 있습니다.

failed to create client configs: while getting config path: failed to get current user: user: Current not implemented on linux/amd64

이 문제를 해결하려면 USER 환경 변수를 만듭니다.

export USER=$(whoami)

다음 단계