Usare lo strumento a riga di comando nomos
Lo strumento a riga di comando nomos
è uno strumento facoltativo per Config Sync. Lo strumento nomos
fornisce i seguenti comandi:
Comando | Utilizzo |
---|---|
nomos status |
Verifica lo stato di Config Sync |
nomos vet |
Verificare la presenza di errori nel repository |
nomos hydrate |
Visualizza tutte le configurazioni nel repository |
nomos bugreport |
Creare una segnalazione di bug |
nomos migrate |
Esegui la migrazione da ConfigManagement a RootSync |
nomos init |
Inizializza un repository gerarchico |
Prerequisiti
Per poter utilizzare lo strumento nomos
per interagire con un cluster, devi prima installare Config Sync sul cluster di destinazione. Devi inoltre configurare lo strumento a riga di comando kubectl
per eseguire l'autenticazione nel cluster di destinazione mediante la generazione di una voce kubeconfig.
Lo strumento nomos
supporta la visualizzazione in anteprima e la convalida delle configurazioni Kustomize e dei grafici Helm. Prima di poter utilizzare questa funzionalità, installa Kustomize e Helm nella tua workstation locale. Se il tuo repository contiene solo configurazioni completamente sottoposte a rendering, Kustomize ed Helm sono facoltativi.
Installa lo strumento nomos
Lo strumento nomos
è un programma binario compilato da codice Go e puoi installarlo localmente, ad esempio su una workstation o un laptop.
Lo strumento nomos
non viene incluso quando installi Config Sync. Puoi installare lo strumento nomos
installando Google Cloud CLI. Se utilizzi Cloud Shell, l'Google Cloud CLI è preinstallata.
Se non hai Google Cloud CLI, ti consigliamo di utilizzare gcloud components install nomos
per installare lo strumento nomos
. L'installazione dello strumento nomos
con Google Cloud CLI
consente di utilizzare
gcloud components update
per aggiornare lo strumento nomos
alla versione più recente.
Per informazioni sui modi alternativi per installare lo strumento nomos
, consulta la pagina relativa ai download di Anthos Config Management.
Utilizzo di base
Per la sintassi di comando di base, utilizza l'argomento --help
:
nomos --help
Lo strumento nomos
legge dal clone locale del tuo repository. Utilizza il flag --path
per specificare la località del livello superiore del repository. Per impostazione predefinita, --path
è impostato su .
o sulla directory attuale. Ad esempio:
nomos --path=PATH_TO_REPOSITORY vet
Verifica lo stato di Config Sync
Puoi monitorare lo stato di Config Sync su tutti i cluster registrati utilizzando il comando nomos status
. Per ogni cluster, nomos status
segnala l'hash del commit Git che è stato applicato per l'ultima volta al cluster, nonché eventuali errori che si sono verificati durante il tentativo di applicazione delle modifiche recenti.
Puoi anche utilizzare nomos status
per verificare che le risorse gestite da Config Sync siano pronte. nomos status
indica lo stato di ogni singola risorsa del repository Git nella colonna STATUS
della sezione Managed resources
dell'output.
L'esempio seguente mostra alcune delle diverse condizioni che il comando nomos status
potrebbe segnalare:
nomos status
Output di esempio:
MANAGED_CLUSTER_1
--------------------
<root> git@github.com:foo-corp/acme@main
SYNCED f52a11e4
Managed resources:
NAMESPACE NAME STATUS
k8snoexternalservices.constraints.gatekeeper.sh/no-internet-services Current
namespace/hello Current
MANAGED_CLUSTER_2
--------------------
<root> git@github.com:foo-corp/acme@main
PENDING 9edf8444
MANAGED_CLUSTER_3
--------------------
<root> git@github.com:foo-corp/acme@main
ERROR f52a11e4
Error: KNV1021: No CustomResourceDefinition is defined for the resource in the cluster.
MANGED_CLUSTER_4
--------------------
NOT INSTALLED
MANAGED_CLUSTER_5
--------------------
<root> git@github.com:foo-corp/acme/admin@main
SYNCED f52a11e4
Managed resources:
NAMESPACE NAME STATUS
namespace/gamestore Current
namespace/monitoring Current
gamestore reposync.configsync.gke.io/repo-sync Current
gamestore rolebinding.rbac.authorization.k8s.io/gamestore-admin Current
gamestore rolebinding.rbac.authorization.k8s.io/gamestore-webstore-admin Current
monitoring deployment.apps/prometheus-operator Current
monitoring prometheus.monitoring.coreos.com/acm Current
monitoring service/prometheus-acm Current
monitoring service/prometheus-operator Current
monitoring serviceaccount/prometheus-acm Current
monitoring serviceaccount/prometheus-operator Current
monitoring servicemonitor.monitoring.coreos.com/acm-service Current
--------------------
bookstore git@github.com:foo-corp/acme/bookstore@v1
SYNCED 34d1a8c8
Managed resources:
NAMESPACE NAME STATUS
gamestore configmap/store-inventory Current
gamestore webstore.marketplace.com/gameplace Current
In questo output:
MANAGED_CLUSTER_1
ha sincronizzato la modifica più recente al repository e tutte le risorse gestite hanno uno statoCurrent
. Uno statoCurrent
significa che lo stato della risorsa corrisponde a quello che vuoi.- La sincronizzazione di
MANAGED_CLUSTER_2
è ancora in corso. MANAGED_CLUSTER_3
contiene un errore che ha impedito l'applicazione della modifica. In questo esempio,MANAGED_CLUSTER_3
presenta un errore KNV1021 perché manca una CustomResourceDefinition (CRD) installata dagli altri cluster.MANAGED_CLUSTER_4
non ha installato Config Sync.- È in corso la sincronizzazione di
MANAGED_CLUSTER_5
da due repository Git. Il repository<root>
appartiene all'amministratore del cluster e il repositorybookstore
potrebbe appartenere a un team di sviluppo di applicazioni.
Stati delle risorse gestite
Lo stato delle risorse gestite può essere uno dei seguenti:
InProgress
: lo stato effettivo della risorsa non ha ancora raggiunto lo stato specificato nel manifest della risorsa. Questo stato indica che la riconciliazione delle risorse non è ancora completa. Le nuove risorse create di solito iniziano con questo stato, anche se alcune risorse come ConfigMap sonoCurrent
immediatamente.Failed
: il processo di riconciliazione dello stato effettivo con quello che vuoi si sia verificato o che non ha fatto progressi sufficienti.Current
: lo stato effettivo della risorsa corrisponde a quello che vuoi. La procedura di riconciliazione viene considerata completa finché non vengono apportate modifiche allo stato desiderato o effettivo.Terminating
: la risorsa è in fase di eliminazione.NotFound
: la risorsa non esiste nel cluster.Unknown
: Config Sync non è in grado di determinare lo stato della risorsa.
Per disattivare la visualizzazione dello stato a livello di risorsa, aggiungi --resources=false
al comando nomos status
.
Informazioni sull'ultimo commit sincronizzato
Il comando nomos status
mostra l'hash del commit Git più recente applicato al cluster nell'output in status.sync.commit
. Per ottenere questo valore, esegui una query sull'oggetto RootSync
o RepoSync
e guarda il campo status.sync
.
Ad esempio, per eseguire una query su un oggetto RootSync
, esegui questo comando:
kubectl get rootsyncs.configsync.gke.io -n config-management-system root-sync -o yaml
Output di esempio:
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
status:
sync:
commit: f1739af550912034139aca51e382dc50c4036ae0
lastUpdate: "2021-04-20T00:25:01Z"
Per eseguire una query su un oggetto RepoSync
, esegui il comando seguente:
kubectl get reposync.configsync.gke.io -n NAMESPACE repo-sync -o yaml
Sostituisci NAMESPACE
con lo spazio dei nomi in cui hai creato il repository.
Output di esempio:
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
status:
sync:
commit: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f
lastUpdate: "2021-04-20T00:25:20Z"
Questo commit rappresenta il commit più recente rispetto al cluster. Tuttavia, non tutte le risorse nel cluster sono interessate da ogni commit. Per visualizzare il commit più recente per una risorsa specifica, esegui una query sulla risorsa specifica ed esamina metadata.annotations.configmanagement.gke.io/token
. Ad esempio:
kubectl get clusterroles CLUSTER_ROLE_NAME -o yaml
Sostituisci CLUSTER_ROLE_NAME
con il nome del ruolo cluster per cui vuoi eseguire la query.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
configmanagement.gke.io/token: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f
flag di stato nomos
Per personalizzare il comando nomos status
, aggiungi i seguenti flag:
Flag | Descrizione |
---|---|
--contexts |
Accetta un elenco di contesti separati da virgole da utilizzare nei comandi multi-cluster. Utilizza il valore predefinito per tutti i contesti. Utilizza "" per non fornire alcun contesto. |
-h o --help |
Guida per il comando nomos status . |
--namespace |
Accetta una stringa. Utilizza il flag namespace per limitare il comando a un repository di spazi dei nomi specifico. Non impostato per ottenere tutti i repository. Questo flag è disponibile solo se hai abilitato la sincronizzazione da più repository. |
--poll |
Utilizza il flag poll per eseguire
nomos status continuamente e fare in modo che la tabella di stato venga ristampata
a intervalli regolari. Ad esempio: 3s . Non impostare questo flag per eseguire nomos status una volta |
--resources |
Accetta true o false . Se true , nomos status mostra lo stato a livello di risorsa per il repository root o dello spazio dei nomi durante la sincronizzazione da più repository.
Il valore predefinito è true . |
--timeout |
Timeout per la connessione a ciascun cluster. Il valore predefinito è
3s . |
Autorizzazioni obbligatorie
Se sei proprietario del progetto, hai il ruolo cluster-admin
RBAC e puoi utilizzare il comando nomos status
per qualsiasi cluster nel progetto senza aggiungere ulteriori autorizzazioni. Se non hai il ruolo cluster-admin
, puoi utilizzare nomos status
creando il seguente ClusterRole:
Crea un file denominato
nomos-status-reader.yaml
e copia al suo interno il seguente clusterClusterRole. Le regole di cui hai bisogno variano a seconda che tu stia utilizzando o meno gli oggetti RootSync e RepoSync.Utilizzo degli oggetti RootSync e RepoSync
# nomos-status-reader.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: nomos-status-reader rules: - apiGroups: ["configsync.gke.io"] resources: ["reposyncs", "rootsyncs"] verbs: ["get"] - nonResourceURLs: ["/"] verbs: ["get"]
Non utilizzano gli oggetti RootSync e RepoSync
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: nomos-status-reader rules: - apiGroups: ["configmanagement.gke.io"] resources: ["configmanagements", "repos"] verbs: ["get", "list"] - nonResourceURLs: ["/"] verbs: ["get"]
Applica il file
nomos-status-reader.yaml
:kubectl apply -f nomos-status-reader.yaml
Verifica la presenza di errori nel repository
Prima di eseguire il commit di una configurazione nel repository, utilizza il comando nomos vet
per verificare la sintassi e la validità delle configurazioni nel repository:
nomos vet
Se vengono trovati errori di sintassi, il comando nomos vet
esce con uno stato diverso da zero e registra i messaggi di errore in STDERR
.
flag nomos vet
Per personalizzare il comando nomos vet
, aggiungi i seguenti flag:
Flag | Descrizione |
---|---|
--clusters |
Accetta un elenco separato da virgole di nomi dei cluster da utilizzare nei comandi multi-cluster. Il valore predefinito è tutti i cluster. Utilizza "" per nessun cluster. |
-h o --help |
Guida per il comando nomos vet . |
--namespace |
Accetta una stringa. Se impostato, convalida il repository come repository di spazio dei nomi con il nome fornito. Imposta automaticamente
--source-format=unstructured . |
--no-api-server-check |
Accetta i valori booleani. Se true , smette di comunicare con il server API per il rilevamento. Per ulteriori informazioni su questo flag, consulta la sezione
Convalida lato server. |
--path |
Accetta una stringa. Il percorso della directory radice del repository Config Sync. L'impostazione predefinita è ". " |
--source-format |
Accetta hierarchy o unstructured . Se hierarchy o non viene configurato, convalida il repository come repository gerarchico. Se
unstructured , convalida il repository come
repository non strutturato.
Il flag è obbligatorio se utilizzi un repository non strutturato. |
--keep-output |
Accetta i valori booleani. Se true , l'output sottoposto a rendering viene salvato nella
località che puoi specificare con il flag --output . |
--output |
Accetta una stringa. Il percorso dell'output visualizzato. Il valore predefinito è la directory compiled . Se il criterio --keep-output è impostato su false , questo flag viene ignorato. |
--format |
Accetta yaml o json . Il formato dell'output. Il valore predefinito è yaml . |
Convalida lato server
Se il comando nomos vet
non riesce a determinare se il tipo ha uno spazio dei nomi, lo strumento nomos
si connette al server API. Poiché lo strumento nomos
comprende per impostazione predefinita i tipi di Kubernetes principali e i CRD di Config Sync, prova a connettersi al server API solo se esistono CR che non hanno una risposta CRD dichiarata. In questo caso, se al server API non è applicato il CRD, il comando nomos
vet
restituisce errore KNV1021. Per disabilitare questo controllo ed eliminare gli errori dovuti a CRD mancanti, passa il flag --no-api-
server-check
.
Memorizzazione nella cache dei metadati del server API
Invece di eliminare i controlli del server API, puoi memorizzare nella cache i dati sul server API per il comando nomos vet
. Per memorizzare nella cache api-resources
, completa i seguenti passaggi:
- Connettiti a un cluster che ha tutti i CRD di cui hai bisogno per il tuo repository. Non è necessario abilitare Config Sync nel cluster.
- Vai a policyDir del tuo repository. Si tratta della stessa directory specificata nella risorsa ConfigManagement o RootSync.
- Esegui questo comando:
kubectl api-resources > api-resources.txt
Questo comando crea un file denominato api-resources.txt che contiene l'esatto output di kubectl api-resources.
D'ora in poi, le esecuzioni di nomos vet
all'interno del repository sono a conoscenza di tali definizioni di tipo. Se il file api-resources.txt
viene rimosso o rinominato, nomos vet
non riesce a trovarlo. nomos vet
proverà comunque a connettersi al cluster se trova manifest per i tipi non dichiarati in api-resources.txt (a meno che non venga superato --no-api-server-check
).
Il file api-resources.txt
influisce solo sul funzionamento dello strumento nomos
. senza modificare il comportamento di Config Sync.
Va bene se il file api-resources.txt contiene voci aggiuntive che riguardano tipi non presenti nel repository. nomos vet
importa le definizioni, ma non fa nulla.
Aggiorna api-resources.txt
Dopo aver verificato che tutti gli CRD che vuoi siano nel cluster, esegui il comando seguente:
kubectl api-resources > api-resources.txt
Verifica automaticamente la presenza di errori di sintassi durante il commit
Se esegui il commit di un file con errori JSON o YAML, Config Sync non applica la modifica. Tuttavia, puoi evitare che questi tipi di errori accedano al repository utilizzando hook lato client o lato server.
Utilizza nomos vet
in un hook di pre-impegno di Git
Puoi configurare un hook prima del commit che esegue il comando nomos vet
per verificare la presenza di errori di sintassi quando esegui il commit di una modifica nel clone Git locale del repository.
Se un hook pre-commit termina con uno stato diverso da zero, l'operazione git commit
non riesce.
Per eseguire il comando nomos vet
come hook del commit, modifica il file .git/hooks/pre-commit
nel repository (nota che .git
inizia con un carattere .
). Potrebbe essere necessario creare il file manualmente. Aggiungi il comando nomos vet
a una nuova riga nello script. L'argomento --path
è facoltativo.
nomos vet --path=/path/to/repo
Assicurati che il file pre-commit
sia eseguibile:
chmod +x .git/hooks/pre-commit
Quindi, quando esegui un comando git commit
nel clone del tuo repository,
nomos vet
viene eseguito automaticamente.
I contenuti della directory .git/
del repository non vengono monitorati dal repository stesso e non possono essere sottoposti a commit nel repository nella stessa posizione. Puoi creare una directory nel repository per gli hook Git e le persone che utilizzano il repository possono copiare gli hook nella posizione appropriata del clone locale.
Utilizzare nomos vet
in un hook lato server
Git fornisce un meccanismo per l'esecuzione dei controlli al server, anziché al client, durante un'operazione git push
. Se il controllo non va a buon fine, git push
non viene superato. Questi hook lato server non possono essere ignorati dal client. Il metodo di configurazione dei hook lato server dipende da come è ospitato il server Git. Consulta uno dei seguenti link per ulteriori informazioni o controlla la documentazione del servizio di hosting Git.
Visualizza tutte le configurazioni nel repository
Puoi utilizzare il comando nomos hydrate
per visualizzare i contenuti combinati del repository su ogni cluster registrato.
Se esegui nomos hydrate
senza opzioni, viene creata una directory compiled/
nella directory di lavoro attuale. All'interno di tale directory, viene creata una sottodirectory per ogni cluster registrato, con le configurazioni completamente risolte che l'operatore applicherà al cluster.
Questo comando può essere utilizzato anche per convertire un repository gerarchico in uno o più repository non strutturati, utilizzando i contenuti della directory compiled/
.
bandiere nomos idratate
Per personalizzare il comando nomos hydrate
, aggiungi i seguenti flag:
Flag | Descrizione |
---|---|
--clusters |
Accetta un elenco di nomi dei cluster separati da virgole. Utilizza questo flag per limitare l'output a un singolo cluster o a un elenco di cluster. Il valore predefinito è tutti i cluster. Utilizza "" per nessun cluster. |
--flat |
Se l'opzione è attiva, stampa tutti gli output in un singolo file. Utilizza questo flag se vuoi emulare il comportamento di nomos view . |
-h o --help |
Guida per il comando nomos hydrate . |
--format |
Accetta i yaml o i json . Il formato dell'output. Il valore predefinito è yaml . |
--no-api-server-check |
Accetta i valori booleani. Se true , smette di comunicare con il server API per il rilevamento. Per ulteriori informazioni su questo flag, consulta la sezione
Convalida lato server. |
--output |
Accetta una stringa. La località in cui scrivere la configurazione idratata. L'impostazione predefinita è la directory compiled .
Se --flat non è abilitato, scrive ogni manifest di risorse come file
separato.
Se --flat è abilitato, scrive nel file, scrive un singolo file
contenente tutti i manifest delle risorse.
|
--path |
Accetta una stringa. Il percorso della directory radice del repository Config Sync. L'impostazione predefinita è ". " |
--source-format |
Accetta hierarchy o unstructured . Se hierarchy o non viene configurato, convalida il repository come repository gerarchico. Se
unstructured , convalida il repository come
repository non strutturato.
Il flag è obbligatorio se utilizzi un repository non strutturato. |
nomos view
Quando Config Sync importa le configurazioni dal repository, le converte in CRD di tipo ClusterConfig
o NamespaceConfig
. Il comando nomos view
consente di visualizzare i CRD derivanti dallo stato attuale del repository in formato JSON. Questo può essere utile prima di eseguire il commit della modifica o per eseguire il debug dei problemi con configurazioni non ovvie utilizzando il comando nomos vet
.
nomos view --path=PATH_TO_REPOSITORY
Crea una segnalazione di bug
Se hai un problema con Config Sync che richiede l'assistenza dell'assistenza Google Cloud, puoi fornire informazioni preziose di debug utilizzando il comando nomos bugreport
. Puoi utilizzare questo comando per repository singoli e più repository.
nomos bugreport
Questo comando genera un file ZIP con timestamp con informazioni sul cluster Kubernetes impostato nel tuo contesto kubectl
. Il file contiene anche i log dei pod di Config Sync. Non contiene informazioni provenienti dalle risorse sincronizzate con Config Sync.
Esegui la migrazione da un oggetto ConfigManagement a un oggetto RootSync
Puoi eseguire il comando nomos migrate
per eseguire la migrazione dall'oggetto ConfigManagement a un oggetto RootSync per abilitare le API RootSync
e RepoSync
. Il comando è disponibile nello strumento nomos
versione 1.10.0 e successive.
nomos migrate
supporta l'esecuzione di prova per l'anteprima del processo di migrazione.
nomos migrate --dry-run
Se il risultato è positivo, puoi eseguire la migrazione dell'oggetto ConfigManagement utilizzando nomos migrate
:
nomos migrate
L'output è simile al seguente:
--------------------
Enabling the multi-repo mode on cluster "my_managed_cluster-1" ...
- A RootSync object is generated and saved in "/tmp/nomos-migrate/my_managed_cluster-1/root-sync.yaml".
- The original ConfigManagement object is saved in "/tmp/nomos-migrate/my_managed_cluster-1/cm-original.yaml".
- The ConfigManagement object is updated and saved in "/tmp/nomos-migrate/my_managed_cluster-1/cm-multi.yaml".
- Resources for the multi-repo mode have been saved in a temp folder. If the migration process is terminated, it can be recovered manually by running the following commands:
kubectl apply -f /tmp/nomos-migrate/my_managed_cluster-1/cm-multi.yaml && \
kubectl wait --for condition=established crd rootsyncs.configsync.gke.io && \
kubectl apply -f /tmp/nomos-migrate/my_managed_cluster-1/root-sync.yaml.
- Updating the ConfigManagement object ....
- Waiting for the RootSync CRD to be established ....
- The RootSync CRD has been established.
- Creating the RootSync object ....
- Waiting for the reconciler-manager Pod to be ready ....
- Haven't detected running Pods with the label selector "app=reconciler-manager".
- Haven't detected running Pods with the label selector "app=reconciler-manager".
- Haven't detected running Pods with the label selector "app=reconciler-manager".
- The reconciler-manager Pod is running.
- Waiting for the root-reconciler Pod to be ready ....
- Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
- Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
- Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
- The root-reconciler Pod is running.
- The migration process is done. Please check the sync status with `nomos status`.
Finished migration on all the contexts. Please check the sync status with `nomos status`.
Esegui il rollback alla configurazione precedente
Se devi eseguire il rollback dopo aver eseguito la migrazione con nomos migrate
, applica l'oggetto ConfigManagement originale. nomos migrate
salva l'oggetto ConfigManagement originale in un file e stampa il nome nel terminale.
Il nome del file è nel formato /tmp/nomos-migrate/CURRENT_CONTEXT/cm-original.yaml
.
Per eseguire il rollback alla configurazione precedente, copia il percorso del file per
cm-original.yaml
e applica il file al cluster:
kubectl apply -f CM_ORIGINAL_PATH
flag di migrazione nomos
Per personalizzare il comando nomos migrate
, aggiungi i seguenti flag:
Flag | Descrizione |
---|---|
--connect-timeout |
Accetta una durata. Durata del timeout per la connessione a ciascun cluster.
Il valore predefinito è 3s . |
--contexts |
Accetta un elenco di contesti separati da virgole da utilizzare negli ambienti multi-cluster. Il valore predefinito corrisponde al contesto corrente. Utilizza "all" per tutti i contesti. |
--dry-run |
Accetta i valori booleani. Se true , stampa solo l'output della
migrazione. |
-h o --help |
Guida per il comando nomos migrate . |
--wait-timeout |
Accetta una durata. Durata del timeout per l'attesa delle condizioni delle risorse Kubernetes. Il valore predefinito è 10m . |
Inizializza un repository gerarchico
Puoi organizzare il repository in modo arbitrario se utilizzi un repository non strutturato.
Se utilizzi un repository gerarchico, devi eseguire il comando nomos init
per inizializzare una directory gerarchica:
nomos init
Viene creata la struttura di directory di base di un repository gerarchico, incluse le directory system/
, cluster/
e namespaces/
.
flag nomos init
Per personalizzare nomos init
, aggiungi i seguenti flag:
Flag | Descrizione |
---|---|
--force |
Scrivi nella directory anche se non è vuoto e sovrascrive i file in conflitto |
-h o --help |
Guida per il comando nomos init . |
--path |
Accetta una stringa. La directory radice da utilizzare per il repository Anthos Config Management. Il valore predefinito è "." |
Risolvere i problemi
Su Linux, potresti visualizzare il seguente errore durante l'esecuzione di un comando nomos
:
failed to create client configs: while getting config path: failed to get current user: user: Current not implemented on linux/amd64
Per risolvere il problema, crea una variabile di ambiente USER
:
export USER=$(whoami)
Passaggi successivi
- Inizia a utilizzare Config Sync
- Scopri di più sulle configurazioni