Documentation sur Oracle Cloud Infrastructure

Guide sur l'API pour les politiques de pilotage pour la gestion du trafic

Utilisez l'API REST d'Oracle Cloud Infrastructure DNS pour créer et configurer des politiques de gestion du trafic.

Utilisez le guide suivant pour apprendre comment créer des politiques à l'aide de l'API REST DNS.

Authentification et autorisation

Chaque service d'Oracle Cloud Infrastructure est intégré avec le service de gestion des identités et des accès GIA aux fins d'authentification et d'autorisation, pour toutes les interfaces (console, trousse SDK ou interface de ligne de commande et API REST).

Un administrateur d'une organisation doit configurer les groupes , les compartiments et les politiques qui déterminent les utilisateurs pouvant accéder aux services et aux ressources, ainsi que le type d'accès. Par exemple, les politiques contrôlent qui peut créer des utilisateurs, créer et gérer le réseau en nuage, créer des instances, créer des seaux, télécharger des objets, etc. Pour plus d'informations, voir Gestion des domaines d'identité. Pour des détails précis sur l'écriture de politiques pour les différents services, voir Informations de référence sur les politiques.

Si vous êtes un utilisateur ordinaire (pas un administrateur) qui doit utiliser les ressources Oracle Cloud Infrastructure de la société, demandez à un administrateur de configurer un ID utilisateur pour vous. L'administrateur vous indiquera les compartiments que vous pouvez utiliser.

Composants d'une politique de pilotage pour la gestion du trafic

La liste suivante présente les composants utilisés pour créer une politique de pilotage pour la gestion du trafic.

POLITIQUES DE PILOTAGE
Cadre global qui définit le comportement de gestion du trafic pour les zones. Les politiques de pilotage contiennent des règles qui servent à traiter intelligemment des réponses DNS.
ATTACHEMENTS
Permet de lier une politique de pilotage à des zones. L'attachement d'une politique de pilotage à une zone occlut tous les enregistrements de son domaine qui sont d'un type d'enregistrement couvert. Ils construisent des réponses DNS à partir de la politique de pilotage et non à partir des enregistrements du domaine. Un domaine peut avoir au moins un attachement qui couvre un type d'enregistrement particulier.
RÈGLES
Directives utilisées par les politiques de pilotage pour filtrer les réponses en fonction des propriétés d'une demande DNS, telles que la géolocalisation des demandes ou l'état des points d'extrémité.
RÉPONSES
Contiennent les données et les métadonnées d'enregistrement DNS à traiter dans une politique de pilotage.
MODÈLES
Les modèles sont des séquences prédéfinies de règles qui créent un type de politique et son comportement prévu. Exemple : Le modèle FAILOVER sert des réponses en vérifiant d'abord l'interrogation DNS sur une règle FILTER , puis les règles suivantes successivement : HEALTH, PRIORITY et LIMIT. Cela fournit au domaine une capacité de basculement dynamique. Les politiques qui définissent le champ template avec toute politique autre que CUSTOM doivent respecter la séquence de règle décrite pour ce type de politique, sinon une erreur de code de statut 400 est retournée lors de la création de la politique.
CAS
Facultativement, une règle peut inclure une séquence de cas définissant des configurations de remplacement de son comportement lors du traitement d'une interrogation DNS particulière. Lorsqu'une règle n'a pas de séquence de cas, elle est toujours évaluée avec la même configuration lors du traitement. Lorsqu'une règle comporte une séquence de cas vide, elle est toujours ignorée lors du traitement. Lorsqu'une règle comporte une séquence non vide, son comportement lors du traitement est configuré par le premier cas correspondant dans la séquence. Un cas de règle sans attribut caseCondition correspond toujours. Un cas de règle avec un attribut caseCondition correspond uniquement lorsque cette expression est évaluée à Vrai pour l'interrogation spécifique.

Créer des politiques de pilotage à l'aide de modèles

La section suivante explique la configuration de règle pour chaque type de modèle de politique de pilotage, suivie d'un exemple de demande POST ( CreateSteeringPolicy ) montrant comment configurer chaque modèle.

BASCULEMENT

Politiques de basculement d'utilisateur pour prioriser l'ordre dans lequel les réponses sont traitées dans une politique (par exemple, Principale et Secondaire). Les moniteurs et les sondes sur demande d'Oracle Cloud Infrastructure Health Checks sont utilisés pour évaluer l'état des réponses dans la politique. Si la réponse principale s'avère non saine, le trafic DNS est automatiquement associé à la réponse secondaire. Chacune des règles suivantes doit être définie dans l'ordre spécifié dans le champ rules du corps de la demande lorsque vous utilisez un modèle FAILOVER :

Ordre Règle Restrictions Commentaires
1 FILTER
  • Aucun cas n'est autorisé.

  • Les données de réponse doivent être définies dans defaultAnswerData à l'aide de l'énoncé JSON suivant :

    
{
  "answerCondition": "answer.isDisabled != true",
  "shouldKeep": true
}
 
2 HEALTH
  • Aucun cas n'est autorisé.
Inclus uniquement si healthCheckMonitorId est défini pour la politique.
3 PRIORITÉ
  • Aucun cas n'est autorisé.
  • Les données de réponse doivent être définies dans la propriété defaultAnswerData pour la règle.

  • Chaque réponse doit avoir une propriété de piscine.

  • defaultAnswerData restrictions :
    • Les réponses ne peuvent pas être référencées par leur propriété de nom dans les expressions answerCondition; elles doivent être référencées par leur propriété de groupe.
    • Chaque groupe de réponses doit être référencé une fois et une seule fois.
    • PRIORITÉ
    • PRIORITÉ
  
4 LIMITE
  • Aucun cas n'est autorisé.
 

Exemple de politique POST /steeringPolicies utilisant le modèle FAILOVER :

{
  "compartmentId": "ocid1...",
  "displayName": "failover between endpoints",
  "ttl": 30,
  "healthCheckMonitorId": "ocid1...",
  "template": "FAILOVER",
  "answers": [
    {
      "name": "server-primary",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "primary"
    },
    {
      "name": "server-secondary",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "secondary"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "HEALTH"
    },
    {
      "ruleType": "PRIORITY",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.pool == 'primary'",
          "value": 1
        },
        {
          "answerCondition": "answer.pool == 'secondary'",
          "value": 99
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

LOAD_BALANCE

Les politiques d'équilibreur de charge répartissent le trafic entre de nombreux points d'extrémité. Vous pouvez affecter des pondérations égales aux points d'extrémité afin de répartir le trafic uniformément entre les points d'extrémité, ou vous pouvez affecter des pondérations personnalisées pour l'équilibrage de charge des ratios. Les moniteurs et les sondes sur demande d'Oracle Cloud Infrastructure Health Checks sont utilisées pour évaluer l'état du point d'extrémité. Si un point d'extrémité s'avère non sain, le trafic DNS est automatiquement réparti entre les autres points d'extrémité. Chacune des règles suivantes doit être définie dans l'ordre spécifié dans le champ rules du corps de la demande lorsque vous utilisez un modèle LOAD_BALANCE :

Ordre Règle Restrictions Commentaires
1 FILTER
  • Aucun cas n'est autorisé.

  • Les données de réponse doivent être définies dans defaultAnswerData à l'aide de l'énoncé JSON suivant :

    
{
  "answerCondition": "answer.isDisabled != true",
  "shouldKeep": true
}
 
2 HEALTH
  • Aucun cas n'est autorisé.
Inclus uniquement si healthCheckMonitorId est défini pour la politique.
3 PONDÉRÉ
  • Aucun cas n'est autorisé.
  • Les données de réponse doivent être définies dans la propriété par défaut AnswerData pour la règle.
  • Les réponses ne peuvent pas être référencées par leur propriété de groupe dans les expressions answerCondition; elles doivent être référencées par leur propriété de nom.
 
4 LIMITE
  • Aucun cas n'est autorisé.
 

Exemple de stratégie POST /SteeingPolicies utilisant le modèle LOAD_BALANCE:

{
  "compartmentId": "ocid1...",
  "displayName": "Weighted load balance for a set of answers with health checks",
  "ttl": 30,
  "healthCheckMonitorId": "ocid1...",
  "template": "LOAD_BALANCE",
  "answers": [
    {
      "name": "server1",
      "rtype": "A",
      "rdata": "192.168.0.2"
    },
    {
      "name": "server2",
      "rtype": "A",
      "rdata": "192.168.0.3"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "HEALTH"
    },
    {
      "ruleType": "WEIGHTED",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.name == 'server1'",
          "value": 99
        },
        {
          "answerCondition": "answer.name == 'server2'",
          "value": 1
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

ROUTE_BY_GEO

Les politiques de pilotage basé sur la géolocalisation transmettent le trafic DNS vers différents points d'extrémité en fonction de l'emplacement de l'utilisateur final. Les clients peuvent définir des régions géographiques constituées du continent d'origine, des pays ou des États/provinces (Amérique du Nord) et définir un point d'extrémité ou un jeu de points d'extrémité distinct pour chaque région. Chaque règle suivante doit être définie dans l'ordre spécifié dans le champ rules du corps de demande lorsque vous utilisez un modèle ROUTE_BY_GEO :

Ordre Règle Restrictions Commentaires
1 FILTER
  • Aucun cas n'est autorisé.

  • Les données de réponse doivent être définies dans defaultAnswerData à l'aide de l'énoncé JSON suivant :

    
{
  "answerCondition": "answer.isDisabled != true",
  "shouldKeep": true
}
 
2 HEALTH
  • Aucun cas n'est autorisé.
Inclus uniquement si healthCheckMonitorId est défini pour la politique.
3 PRIORITÉ
  • La propriété defaultAnswerData ne peut pas être utilisée dans cette règle.
  • Vous devez définir au moins un cas. S'il y a de nombreux cas, le cas final peut fournir un cas "catch-all".
  • La propriété caseCondition dans les cas ne peut utiliser query.client.geoKey que dans l'expression conditionnelle.
  • Les réponses ne peuvent pas être référencées par leur propriété de nom dans les expressions answerCondition; elles doivent être référencées par leur propriété de groupe.
  • Chaque réponse doit avoir une propriété de piscine.

  • Pour chaque cas answerData :

    • Chaque groupe de réponses doit être référencé une fois et une seule fois.
    • Chaque groupe de réponses doit avoir une propriété de valeur unique (dans le cas).
    • Chaque référence de groupe de réponses doit correspondre à la propriété de groupe sur une ou plusieurs réponses définies dans la liste de réponses pour la politique.
 
4 LIMITE
  • Aucun cas n'est autorisé.
 

Exemple de corps de demande POST /steeringPolicies créé à l'aide du modèle ROUTE_BY_GEO :

{
  "compartmentId": "ocid1...",
  "displayName": "Geolocations mapped to answer pools",
  "ttl": 30,
  "healthCheckMonitorId": "ocid1...",
  "template": "ROUTE_BY_GEO",
  "answers": [
    {
      "name": "US Server 1",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "US"
    },
    {
      "name": "US Server 2",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "US"
    },
    {
      "name": "EU Server 1",
      "rtype": "A",
      "rdata": "192.168.0.4",
      "pool": "EU"
    },
    {
      "name": "EU Server 2",
      "rtype": "A",
      "rdata": "192.168.0.5",
      "pool": "EU"
    },
    {
      "name": "rest of world 1",
      "rtype": "A",
      "rdata": "203.0.113.2",
      "pool": "Global"
    },
    {
      "name": "rest of world 2",
      "rtype": "A",
      "rdata": "203.0.113.3",
      "pool": "Global"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "HEALTH"
    },
    {
      "ruleType": "PRIORITY",
      "cases": [
        {
          "caseCondition": "query.client.geoKey in (geoKey '6255149')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'US'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'EU'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Global'",
              "value": 3
            }
          ]
        },
        {
          "caseCondition": "query.client.geokey in (geokey '6255148')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'EU'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'US'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Global'",
              "value": 3
            }
          ]
        },
        {
          "answerData": [
            {
              "answerCondition": "answer.pool == 'Global'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'US'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'EU'",
              "value": 3
            }
          ]
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

ROUTE_BY_ASN

Les politiques de pilotage basées sur l'ASN permettent de piloter le trafic DNS en fonction des numéros de système autonome. Les interrogations DNS provenant d'un ASN ou d'un jeu d'ASN particulier peuvent être dirigées vers un point d'extrémité spécifique. Chaque règle suivante doit être définie dans l'ordre spécifié dans le champ rules du corps de demande lorsque vous utilisez un modèle ROUTE_BY_ASN :

Ordre Règle Restrictions Commentaires
1 FILTER
  • Aucun cas n'est autorisé.

  • Les données de réponse doivent être définies dans defaultAnswerData à l'aide de l'énoncé JSON suivant :

    
{
  "answerCondition": "answer.isDisabled != true",
  "shouldKeep": true
}
 
2 HEALTH
  • Aucun cas n'est autorisé.
Inclus uniquement si healthCheckMonitorId est défini pour la politique.
3 PRIORITÉ
  • La propriété defaultAnswerData ne peut pas être utilisée dans cette règle.
  • Vous devez définir au moins un cas. S'il y a de nombreux cas, le cas final peut fournir un cas "catch-all".
  • La propriété caseCondition dans les cas ne peut utiliser query.client.asn que dans l'expression conditionnelle.
  • Les réponses ne peuvent pas être référencées par leur propriété de nom dans les expressions answerCondition; elles doivent être référencées par leur propriété de groupe.
  • LIMITE

  • Pour answerData de chaque cas :

    • Chaque groupe de réponses doit être référencé une fois et une seule fois.
    • Chaque groupe de réponses doit avoir une propriété de valeur unique (dans le cas).
    • Chaque référence de groupe de réponses doit correspondre à la propriété de groupe sur une ou plusieurs réponses définies dans la liste de réponses pour la politique.
  
4 LIMITE
  • Aucun cas n'est autorisé.
 

Exemple de corps de demande POST /steeringPolicies créé à l'aide du modèle ROUTE_BY_ASN :

{
  "compartmentId": "ocid1...",
  "displayName": "ASNs mapped to pools",
  "ttl": 30,
  "template": "ROUTE_BY_ASN",
  "answers": [
    {
      "name": "ABC Server",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "ABC"
    },
    {
      "name": "DEF Server",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "DEF"
    },
    {
      "name": "Other",
      "rtype": "A",
      "rdata": "203.0.113.2",
      "pool": "Other"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "PRIORITY",
      "cases": [
        {
          "caseCondition": "query.client.asn == 3",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "caseCondition": "query.client.asn == 16591",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "answerData": [
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 3
            }
          ]
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

ROUTE_BY_IP

Les politiques de pilotage basées sur le préfixe IP permettent aux clients de piloter le trafic DNS en fonction du préfixe IP de l'interrogation d'origine. Chaque règle suivante doit être définie dans l'ordre spécifié dans le champ rules du corps de demande lorsque vous utilisez un modèle ROUTE_BY_IP :

Ordre Règle Restrictions Commentaires
1 FILTER
  • Aucun cas n'est autorisé.

  • Les données de réponse doivent être définies dans defaultAnswerData à l'aide de l'énoncé JSON suivant :

    
{
  "answerCondition": "answer.isDisabled != true",
  "shouldKeep": true
}
 
2 HEALTH
  • Aucun cas n'est autorisé.
Inclus uniquement si healthCheckMonitorId est défini pour la politique.
3 PRIORITÉ
  • La propriété defaultAnswerData ne peut pas être utilisée dans cette règle.
  • Vous devez définir au moins un cas. S'il y a de nombreux cas, le cas final peut fournir un cas "catch-all".
  • La propriété caseCondition dans les cas ne peut utiliser query.client.address que dans l'expression conditionnelle.
  • Les réponses ne peuvent pas être référencées par leur propriété de nom dans les expressions answerCondition; elles doivent être référencées par leur propriété de groupe.
  • Chaque réponse doit avoir une propriété de pool.

  • Pour chaque cas answerData :

    • Chaque groupe de réponses doit être référencé une fois et une seule fois.
    • Chaque groupe de réponses doit avoir une propriété de valeur unique (dans le cas).
    • Chaque référence de groupe de réponses doit correspondre à la propriété de groupe sur une ou plusieurs réponses définies dans la liste de réponses pour la politique.
 
4 LIMITE
  • Aucun cas n'est autorisé.
 

Exemple de corps de demande POST /steeringPolicies créé à l'aide du modèle ROUTE_BY_IP :

{
  "compartmentId": "ocid1...",
  "displayName": "IP subnets mapped to answer pools",
  "ttl": 30,
  "template": "ROUTE_BY_IP",
  "answers": [
    {
      "name": "ABC Server",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "ABC"
    },
    {
      "name": "DEF Server",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "DEF"
    },
    {
      "name": "Other",
      "rtype": "A",
      "rdata": "203.0.113.2",
      "pool": "Other"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "PRIORITY",
      "cases": [
        {
          "caseCondition": "query.client.address in (subnet '10.0.3.0/24')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "caseCondition": "query.client.address in (subnet '192.0.2.2/24')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "answerData": [
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 3
            }
          ]
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

PERSONNALISÉE

Utilisez des politiques personnalisées pour créer des politiques complexes combinant les capacités du basculement, de l'équilibrage de charge, de la géolocalisation et du préavis d'expédition et du pilotage par préfixe IP. Les modèles personnalisés ne requièrent pas de séquence restreinte de règles. Nous vous recommandons de communiquer avec le soutien technique d'Oracle Cloud Infrastructure avant de créer une politique personnalisée.

Types de règle

FILTRE
Utilise des données booléennes associées aux réponses et conserve les réponses uniquement si la valeur shouldKeep de la règle est true (Vrai).
ÉTAT
Utilise des moniteurs de vérification d'état OCI et des sondes sur demande pour évaluer l'état des points d'extrémité et ajouter et supprimer des réponses à la politique, au besoin. Un moniteur de vérification d'état doit être référencé dans une règle d'état pour affecter la politique. Pour plus d'informations sur les vérifications d'état, voir Vérifications d'état.
PONDÉRÉ
Utilise un nombre entre 0 et 255 pour évaluer la fréquence à laquelle une réponse est utilisée par rapport à d'autres réponses. Les réponses avec des valeurs élevées sont plus susceptibles d'être retournées.
PRIORITÉ
Utilise un nombre entier associé à chaque réponse pour trier les réponses de la valeur la plus basse à la plus élevée. Exemple : Une réponse avec une valeur de priorité 1 sera retournée avant une réponse d'une valeur de priorité 10 dans la liste des réponses. Les réponses qui n'ont pas de valeur de priorité leur sont déplacées à la fin de la liste de réponses.
LIMITE
Utilise une propriété de comptage pour filtrer toutes les réponses, sauf la première dans la liste.