Questa pagina è stata tradotta dall'API Cloud Translation.

Upgrade di Apigee hybrid alla versione 1.3.6 in corso...

Panoramica dell'aggiornamento alla versione 1.3.6.

Le procedure per l'upgrade di Apigee hybrid sono organizzate nelle seguenti sezioni:

preparazione

Creare e aggiornare gli account di servizio.
Pianifica i gruppi di ambienti.
Copia e aggiorna il file degli override.

Esegui l'upgrade di Istio e cert-manager.
Installare il runtime ibrido versione 1.3.
Eseguire la pulizia.

Prerequisito

Apigee hybrid versione 1.2. Se esegui l'aggiornamento da una versione precedente, consulta le istruzioni. per Upgrade di Apigee hybrid alla versione 1.2.

preparazione

(Consigliato) Crea una copia di backup della directory $APIGEECTL_HOME/ della versione 1.2. Ad esempio:
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.2-backup.tar.gz $APIGEECTL_HOME
```
(Consigliato) Esegui il backup del database Cassandra seguendo le istruzioni riportate in Backup e recupero di Cassandra

Esegui l'upgrade della tua piattaforma Kubernetes come segue. Segui la documentazione della piattaforma se hai bisogno di aiuto:

Piattaforma	Esegui l'upgrade alla versione
GKE	1,15,x
Anthos	1,5
AKS	1.16.x utilizzando Anthos cluster collegati

Se non utilizzi Apigee Connect nella tua installazione ibrida, abilita Apigee Connettiti.

Verifica se l'API Apigee Connect è abilitata:

gcloud services list | grep apigeeconnect

apigeeconnect.googleapis.com         Apigee Connect API

In caso contrario, abilita l'API:
```
gcloud services enable apigeeconnect.googleapis.com --project $PROJECT_ID
```
Dove $PROJECT_ID è l'ID progetto di Google Cloud.
Nella riga di comando, recupera le credenziali di autenticazione gcloud, come mostrato nell'esempio seguente:
```
TOKEN=$(gcloud auth print-access-token)
```
Per verificare che il token sia stato compilato, utilizza echo, come mostrato nell'esempio seguente:
```
echo $TOKEN
```
Il token dovrebbe essere visualizzato come stringa codificata.

Per ulteriori informazioni, vedi Panoramica dello strumento a riga di comando gcloud.

Verifica se Apigee Connect è abilitato per la tua organizzazione:

curl -H "Authorization: Bearer $TOKEN" \
  "https://apigee.googleapis.com/v1/organizations/$ORG_NAME"

Dove $ORG_NAME è l'ID della tua organizzazione.

Se l'output contiene:

      "name" : "features.mart.connect.enabled",
      "value" : "true"

Apigee Connect è abilitato.

Se Apigee Connect non è abilitato, assegna il ruolo Agente Apigee Connect Agent al servizio MART :

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member serviceAccount:apigee-mart@$PROJECT_ID.iam.gserviceaccount.com \
  --role roles/apigeeconnect.Agent

Suggerimento: se devi ottenere l'indirizzo email del tuo servizio MART esegui questo comando:

gcloud iam service-accounts list | grep mart

Abilita Apigee Connect con il seguente comando:

curl -H "Authorization: Bearer $TOKEN" -X PUT \
  -H "Content-Type: application/json" \
  -d '{
    "name" : "'"$ORG_NAME"'",
    "properties" : {
      "property" : [ {
        "name" : "features.hybrid.enabled",
        "value" : "true"
      }, {
        "name" : "features.mart.connect.enabled",
        "value" : "true"
      } ]
    }
  }' \
  "https://apigee.googleapis.com/v1/organizations/$ORG_NAME"

Se l'output contiene le due proprietà seguenti, Apigee Connect è stato abilitato correttamente:

      {
        "name": "features.mart.connect.enabled",
        "value": "true"
      },
      {
        "name": "features.hybrid.enabled",
        "value": "true"
      }

Crea l'account di servizio apigee-watcher. Apigee Watcher è un nuovo account di servizio introdotto nella v1.3. Offre il sincronizzatore per le modifiche a livello di organizzazione applica queste modifiche per configurare il traffico Istio in entrata.
Dalla directory ibrida principale:
```
./tools/create-service-account apigee-watcher ./service-accounts
```
Assegna il ruolo Agente di runtime Apigee all'account di servizio Watcher:
```
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member serviceAccount:apigee-watcher@$PROJECT_ID.iam.gserviceaccount.com \
  --role roles/apigee.runtimeAgent
```
Dove PROJECT_ID è l'ID progetto Google Cloud. Se il tuo servizio indirizzi email di account diversi da questo pattern, sostituiscili di conseguenza.
Suggerimento: se hai bisogno dell'indirizzo email di chi guarda i contenuti account di servizio, esegui questo comando:
```
gcloud iam service-accounts list | grep watcher
```
L'output dovrebbe includere un elenco di tutti gli account di servizio e i relativi ruoli, tra cui:
```
  ...
- members:
  - serviceAccount:apigee-watcher@hybrid13rc5.iam.gserviceaccount.com
  role: roles/apigee.runtimeAgent
  ...
```
Pianifica i gruppi di ambienti per il routing. Apigee hybrid 1.3 gestisce il routing del percorso di base con gruppi di ambienti anziché routingRules. Se utilizzi routingRules nel tuo modello ibrido progettando gruppi di ambienti per replicare il routing.
Devi creare almeno un gruppo di ambienti.

Vedi Informazioni sui gruppi di ambienti.
Fai clic per vedere un esempio di utilizzo dei gruppi di ambienti per la sostituzione routingRules

In questo esempio, il seguente routingRules nel file overrides.yaml routing delle richieste ai proxy API foo e bar verso prod-env-1 e il proxy foo-test nell'ambiente test-env:
```
virtualhosts:
  - name: default
    hostAliases:
      - "*.acme.com"
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
    routingRules:
      - paths:
        - /foo
        - /bar
      - env: prod-env-1
      - paths:
        - foo-test
      -env: test-env
```
Per duplicarlo nella versione ibrida 1.3.6:
1. Esegui il deployment dei proxy foo e bar nell'ambiente prod-env-1.
2. Esegui il deployment del proxy foo-test e bar nell'ambiente test-env.
3. Crea un gruppo di ambiente con un hostalias per i proxy, ad esempio api.acme.com.
  Suggerimento:crea un gruppo di ambiente con lo stesso nome del gruppo il nome virtualhost utilizzato nella versione 1.2.
4. Rivedi la stanza virtualhosts in overrides.yaml per
  - Sostituisci virtualhosts:name con il nome del gruppo di ambienti.
  - Rimuovi virtualhosts:routingRules.
  Ad esempio:
```
virtualhosts:
  - name: default # environment group name
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
```
Aggiorna il file degli override:

Crea una copia del file degli override.

Aggiorna le stanza gcp e k8sCluster.

Le seguenti proprietà di configurazione sono state sostituite nella versione ibrida 1.3:

gcpRegion sostituito con gcp:region
gcpProjectID sostituito con gcp:projectID
gcpProjectIDRuntime sostituito con gcp:gcpProjectIDRuntime
k8sClusterName sostituito con k8s:clusterName
k8sClusterRegion sostituito con k8s:clusterRegion

Ad esempio, sostituisci la seguente struttura:

gcpRegion: gcp region
gcpProjectID: gcp project ID
gcpProjectIDRuntime: gcp project ID

k8sClusterName: name
k8sClusterRegion: region

with:

gcp:
 projectID: gcp project ID
 region: gcp region
 gcpProjectIDRuntime: gcp project ID # optional. This is only required if you
                                       # want logger/metrics data to be sent in
                                       # different gcp project.

k8sCluster:
 name: gcp project ID
 region: gcp region

Se non disponi già di un identificatore di istanza univoco nel file di override, aggiungine uno:
```
# unique identifier for this installation. 63 chars length limit
instanceID: ID
```
Dove ID è un identificatore univoco per questa installazione ibrida, ad esempio "my-hybrid-131-installation" o "acmecorp-hybrid-131".

Aggiungi l'account di servizio Watcher (apigee-watcher) al file degli override:

# Note: the SA should have the "Apigee Runtime Agent" role
watcher:
 serviceAccountPath: "service account file"

Aggiungi l'account di servizio Metrics (apigee-metrics) al file degli override:
```
metrics:
 serviceAccountPath: "service account file"
```
Aggiorna la stanza virtualhosts: per sostituire routingRules con il tuo gruppo di ambienti.
1. -name: Sostituisci il nome con il nome del gruppo di ambienti. Puoi avere con più voci di nome, una per ogni gruppo di ambienti.
2. hostAliases:[] Elimina questa riga.
3. Mantieni (o aggiungi) le voci sslCertPath: e sslKeyPath:.
4. Elimina tutte le routingRules voci.
Ad esempio:
```
virtualhosts:
  - name: default
    hostAliases:
      - "*.acme.com"
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
    routingRules:
      - paths:
        - /foo
        - /bar
      - env: my-environment
```
Diventa:
```
virtualhosts:
  - name: example-env-group
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
```
Aggiorna le stanze mart e connectAgent:.
Nota: se non prevedi di utilizzare Apigee Connect nel tuo installazione ibrida 1.3, salta questo passaggio e segui il suggerimento nella procedura 5 in Apigee Connect dopo l'upgrade.
1. In mart: rimuovi hostAlias:, sslCertPath:, e sslKeyPath: voci.
2. Aggiungi una stanza connectAgent:.
3. In connectAgent:, aggiungi una voce serviceAccountPath: e fornisci Il percorso del file dell'account di servizio a cui è assegnato il ruolo Agente Apigee Connect (di solito l'account di servizio MART).
Ad esempio:
```
mart:
  hostAlias: "mart.apigee-hybrid-docs.net"
  serviceAccountPath: ./service-accounts/hybrid-project-apigee-mart.json
  sslCertPath: ./certs/fullchain.pem
  sslKeyPath: ./certs/privkey.key
```
Diventa:
```
mart:
  serviceAccountPath: ./service-accounts/hybrid-project-apigee-mart.json

connectAgent:
  serviceAccountPath: ./service-accounts/hybrid-project-apigee-mart.json
```

Esegui l'upgrade di Istio e cert-manager

Apigee hybrid versione 1.3 richiede cert-manager v0.14.2 per gestire e verificare i certificati e la distribuzione Istio fornita con Anthos Service Mesh (ASM) versione 1.5.7 (o successive) per creare e gestire il gateway in entrata per il runtime.

Esegui l'upgrade di Istio 1.4.6 ad ASM 1.5.7 (o versioni successive)

Per ridurre al minimo i tempi di inattività, i deployment Istio e gli HPA devono avere almeno due repliche ciascuno. Esegui questi comandi per determinare il numero di repliche:
```
kubectl -n istio-system get deployments # list of deployments
kubectl -n istio-system get hpa # list of hpa
```
Modifica ogni deployment che ha una sola replica e aumenta il valore replicas: per 2 o più:
```
kubectl -n istio-system edit deployment name
```
Ad esempio:
```
spec:
  progressDeadlineSeconds: 600
  replicas: 2
```
Modifica ogni HPA che ha una sola replica e aumenta minReplicas: in 2 o più:
```
kubectl -n istio-system edit hpa name
```
Ad esempio:
```
spec:
  maxReplicas: 5
  minReplicas: 2
```
Scarica e installa ASM seguendo le istruzioni di installazione in Scaricare e installare ASM.

Al termine dell'installazione, esegui il comando version per assicurarti di aver installato correttamente la versione 1.5.x:

./bin/istioctl version

client version: 1.5.8-asm.0
apigee-mart-ingressgateway version:
citadel version: 1.4.6
galley version: 1.4.6
ingressgateway version: 1.5.8-asm.0
pilot version: 1.4.6
policy version: 1.4.6
sidecar-injector version: 1.4.6
telemetry version: 1.4.6
pilot version: 1.5.8-asm.0
data plane version: 1.4.6 (1 proxies), 1.5.8-asm.0 (2 proxies)

Esegui l'upgrade del gestore certificati

Elimina il deployment cert-manager attuale:

kubectl delete -n cert-manager deployment cert-manager cert-manager-cainjector cert-manager-webhook

Verifica la tua versione di Kubernetes:
```
kubectl version
```

Esegui questo comando per installare cert-manager da Jetstack:

kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.14.2/cert-manager.yaml

Installa il runtime ibrido

Memorizza il numero dell'ultima versione in una variabile:

export VERSION=$(curl -s \
    https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/current-version.txt?ignoreCache=1)

Verifica che la variabile sia stata compilata con un numero di versione. Se vuoi utilizzare un altro puoi salvarlo in una variabile di ambiente. Ad esempio:
```
echo $VERSION
  1.3.6
```

Scarica il pacchetto di release per il tuo sistema operativo:

Mac a 64 bit:

curl -LO \
    https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/$VERSION/apigeectl_mac_64.tar.gz

Linux a 64 bit:

curl -LO \
    https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/$VERSION/apigeectl_linux_64.tar.gz

Mac 32 bit:

curl -LO \
    https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/$VERSION/apigeectl_mac_32.tar.gz

Linux a 32 bit:

curl -LO \
    https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/$VERSION/apigeectl_linux_32.tar.gz

Rinomina la directory apigeectl/ attuale con il nome della directory di backup. Ad esempio:
```
mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.2/ 
```
Estrai il contenuto del file gzip scaricato nella directory base ibrida. Ad esempio:
```
tar xvzf filename.tar.gz -C hybrid-base-directory
```
cd alla directory di base.
Per impostazione predefinita, i contenuti tar vengono espansi in una directory con la versione e la piattaforma . Ad esempio: ./apigeectl_1.0.0-f7b96a8_linux_64. Rinomina la directory a apigeectl:
```
mv apigeectl_1.0.0-f7b96a8_linux_64 apigeectl
```

Elimina il job apigee-resources-install da apigee-system:

kubectl -n apigee-system delete job apigee-resources-install

Elimina il CRD precedente:

kubectl delete crd apigeetelemetries.apigee.cloud.google.com

Aggiorna la stanza cassandra: nel file di override con un proprietà externalSeedHost. Questa proprietà ti aiuterà a garantire che il tuo nuovo modello l'installazione della versione 1.3.6 utilizzerà lo stesso cluster Kubernetes dell'installazione della versione 1.2. Si tratta di un passaggio una tantum necessario solo per l'upgrade dalla versione ibrida 1.2 alla versione 1.3.6 (o più recenti).
1. Trova uno degli indirizzi IP di Cassandra esistente nello stesso cluster Kubernetes in cui si sta aggiornando l'installazione 1.2.0.
```
kubectl -n namespace get pods -o wide
```
  Dove namespace è il tuo spazio dei nomi ibrido Apigee.
  
  Prendi nota dell'indirizzo IP di un nodo Cassandra. Ad esempio:
```
kubectl -n apigee get pods -o wide
NAME                  READY   STATUS    RESTARTS   AGE   IP          NODE
apigee-cassandra-0    1/1     Running   0          33d   10.68.8.24   gke-example-cluster-rc5-apigee-data-c8bf1234-09kc
apigee-cassandra-1    1/1     Running   0          16d   10.68.8.33   gke-example-cluster-rc5-apigee-data-c9221ee7-10kc
apigee-cassandra-2    1/1     Running   0          23h   10.68.9.11   gke-example-cluster-rc5-apigee-data-d123e456-11kc
```
2. Aggiungi il valore per la proprietà externalSeedHost:
```
cassandra:
 externalSeedHost: Cassandra_node_IP
```
  Dove Cassandra_node_IP è l'IP del nodo Cassandra (10.68.8.24 nell'esempio precedente).
  
  Nota: i externalSeedHost verranno rimossi in un passaggio successivo, dopo che la nuova proprietà Cassandra sarà in esecuzione e verificata.
Nella nuova directory apigeectl/, esegui apigeectl init, apigeectl apply e apigeectl check-ready:
1. Inizializzare l’ibrido 1.3.6:
```
apigeectl init -f overrides_1.3.yaml
```
  Dove overrides_1.3.yaml è il file override.yaml modificato.
2. Nella versione ibrida 1.3, la sintassi del flag --dry-run dipende dal versione di kubectl in esecuzione. Controlla la versione di kubectl:
```
gcloud version
```
3. Verifica la presenza di errori con una prova:
  kubectl 1.17 e versioni precedenti:
```
apigeectl apply -f overrides_1.3.yaml --dry-run=true
```
  kubectl 1.18 e versioni successive:
```
apigeectl apply -f overrides_1.3.yaml --dry-run=client
```
4. Applica gli override. Seleziona e segui le istruzioni per la produzione o ambienti demo/sperimentali, a seconda dell'installazione.
  Durante il processo di upgrade, ogni componente eseguirà un riavvio in sequenza. Pertanto, per gli ambienti di produzione, è preferibile applicare l'upgrade a un componente alla volta.
  Produzione
  
  Per gli ambienti di produzione è necessario eseguire l'upgrade di ogni componente ibrido individualmente, e controlla lo stato del componente aggiornato prima di passare al componente successivo.
  1. Applica gli override per eseguire l'upgrade di Cassandra:
    apigeectl apply -f overrides_1.3.yaml --datastore
  2. Verifica di completamento:
    kubectl -n namespace get pods
    
    Dove namespace è il tuo spazio dei nomi ibrido Apigee.
    
    Procedi al passaggio successivo solo quando i pod sono pronti.
  3. Applica gli override per eseguire l'upgrade dei componenti di telemetria e verificare il completamento:
    apigeectl apply -f overrides_1.3.yaml --telemetry
    
    kubectl -n namespace get pods
  4. Applica gli override per eseguire l'upgrade dei componenti a livello di organizzazione (MART, Watcher e Apigee) connettiti) e verifica il completamento:
    apigeectl apply -f overrides_1.3.yaml --org
    
    kubectl -n namespace get pods
  5. Applica gli override per eseguire l'upgrade degli ambienti. Hai a disposizione due opzioni:
    
    Applica gli override a un ambiente alla volta e controlla il completamento. Ripeti questo passaggio per ogni ambiente:
    apigeectl apply -f overrides_1.3.yaml --env env_name
    
    kubectl -n namespace get pods
    
    dove env_name è il nome dell'ambiente di cui esegui l'upgrade.
    
    Applica gli override a tutti gli ambienti contemporaneamente e verifica il completamento:
    apigeectl apply -f overrides_1.3.yaml --all-envs
    
    kubectl -n namespace get pods
  Demo/sperimentale
  
  Nella maggior parte degli ambienti demo o sperimentali, è possibile applicare override a tutti i componenti contemporaneamente. Se il tuo ambiente dimostrativo/sperimentale è ampio e complesso o imita da vicino una di produzione, ti consigliamo di utilizzare le istruzioni per eseguire l'upgrade ambienti di produzione
  1. apigeectl apply -f overrides_1.3.yaml
  2. Controlla lo stato:
    apigeectl check-ready -f overrides_1.3.yaml
  Per ulteriori istruzioni, vedi Configurazione ibrida di GKE - Passaggio 5: installa ibrido su GKE.
5. Dopo aver configurato e in esecuzione la versione ibrida 1.3, verifica che tutti i nodi Cassandra (vecchia e nuova) fanno parte dello stesso cluster Cassandra. Esegui questo comando su una delle Nodi Cassandra:
```
kubectl -n namespace get pods
kubectl -n namespace exec old Cassandra pod -- nodetool status
```
  Nell'output di esempio seguente, 10.68.8.24 è della versione 1.2.0 ed è l'IP del nodo che utilizzata come externalSeedHost. 10.68.7.11 è dalla versione 1.3.6:
```
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.68.8.24  379.41 KiB  256          50.8%             11bbd43b-af64-464b-a96d-0d6dd0521de1  ra-1
UN  10.68.7.11  1.35 MiB    256          49.2%             0b4d9e08-f353-413a-b4a9-7d18a8d07e58  ra-1
```
  Se non si trovano nello stesso cluster, controlla la externalSeedHost.
6. Quando tutti i pod sono attivi, rimuovi externalSeedHost dal il file degli override ed esegui di nuovo apigeectl apply con --datastore :
```
apigeectl apply --datastore -f overrides_1.3.6.yaml
```
Esegui la pulizia

Dopo aver verificato che tutti i pod siano funzionanti e integri e che gli endpoint ASM siano validi nuova installazione, puoi pulire:
- Risorse ibride 1.2.
- L'istanza Cassandra precedente
- delle risorse di Istio 1.4.6.
Elimina risorse ibride 1.2.0
Nota: questa procedura richiede la versione apigeectl 1.2 nella directory di cui hai eseguito il backup. Per scaricare un'altra copia apigeectl versione 1.2, puoi utilizzare il seguente comando:
```
curl -LO \
    https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/1.2.0/apigeectl_your_system.tar.gz
```
Dove your_system è uno tra linux_32, linux_64, mac_32 o mac_64.
1. Rimuovi i dettagli di routing virtualhost 1.2.0:
```
$APIGEECTL_HOME-v1.2/apigeectl delete -s virtualhost -f 1.2.0_overrides.yaml
```
  Dov'è $APIGEECTL_HOME-v1.2 la directory in cui hai eseguito il backup Directory di apigeectl versione 1.2.
2. Se l'endpoint funziona ancora come previsto e hai verificato tutti i componenti 1.3.0 esegui questo comando per eliminare le risorse ibride 1.2.0:
```
$APIGEECTL_HOME-v1.2/apigeectl delete -c "mart,connect-agent,synchronizer,runtime,udca,metrics,logger" \
  -f 1.2.0_overrides.yaml
```
Dismetti l'istanza Cassandra precedente
1. cd nella directory apigeectl appena installata.
2. Esegui lo script tools/cas_cleanup.sh.
  Questo script rimuove il vecchio pod Cassandra dall'anello di Cassandra, elimina il sistema STS precedente ed elimina le PVC.
```
bash cas_cleanup.sh Apigee namespace
```
Elimina le risorse Istio versione 1.4.6

Nota: se elimini le risorse Istio versione 1.4.6, elimina anche il traffico MART in entrata. Il traffico MART in entrata viene sostituito con Apigee Connect in Apigee hybrid versione 1.3.
1. Esegui questo comando per eliminare le risorse Istio v.1.4.6 più recenti:
```
kubectl delete all -n istio-system --selector \
  'app in (apigee-mart-istio-ingressgateway, galley, security, istio-nodeagent, istio-mixer, sidecarInjectorWebhook, istio-mixer)'
```
2. Esegui i comandi seguenti per eliminare i job meno recenti dall'installazione di Istio 1.4.6:
```
kubectl -n istio-system delete job istio-init-crd-10-1.4.6
kubectl -n istio-system delete job istio-init-crd-11-1.4.6
kubectl -n istio-system delete job istio-init-crd-14-1.4.6
```
Complimenti! Hai eseguito correttamente l'upgrade ad Apigee hybrid versione 1.3.6.

Upgrade di Apigee hybrid alla versione 1.3.6 in corso...

Panoramica dell'aggiornamento alla versione 1.3.6.

Prerequisito

preparazione

Fai clic per vedere un esempio di utilizzo dei gruppi di ambienti per la sostituzione routingRules

Esegui l'upgrade di Istio e cert-manager

Esegui l'upgrade di Istio 1.4.6 ad ASM 1.5.7 (o versioni successive)

Esegui l'upgrade del gestore certificati

Installa il runtime ibrido

Produzione

Demo/sperimentale

Esegui la pulizia

Elimina risorse ibride 1.2.0

Dismetti l'istanza Cassandra precedente

Elimina le risorse Istio versione 1.4.6

Fai clic per vedere un esempio di utilizzo dei gruppi di ambienti per la sostituzione `routingRules`