Object Storage Service:Mirror back-to-origin

Étape 1 : Configurer une règle de récupération par miroir vers l'origine

1. Accédez à la page Buckets et cliquez sur le nom du compartiment cible.

2. Dans le volet de navigation de gauche, choisissez Data Management > Mirroring-based Back-to-origin.

3. Sur la page Mirroring-based Back-to-origin, cliquez sur Create Rule.

4. Dans le panneau Create Rule, configurez les paramètres. Utilisez les valeurs par défaut pour tous les autres paramètres.

   Parameter	Configuration
   Method	Sélectionnez Image.
   Condition	Sélectionnez Object Name Prefix et saisissez examplefolder/ dans la zone de texte.
   Origin URL	Dans la première colonne (Protocol), sélectionnez https. Dans la deuxième colonne (Domain Name), saisissez example.com. Laissez la troisième colonne (Path Prefix) vide. Le préfixe de chemin est ajouté au nom de domaine pour former le chemin de l'URL d'origine.

5. Cliquez sur OK.

Étape 2 : Vérifier la règle

1. Accédez à https://examplebucket.oss-cn-hangzhou.aliyuncs.com/examplefolder/example.txt.

2. Si l'objet examplefolder/example.txt n'existe pas dans le compartiment examplebucket, OSS demande l'objet depuis https://example.com/examplefolder/example.txt.

3. Après avoir récupéré l'objet, OSS l'enregistre sous le nom examplefolder/example.txt dans le compartiment examplebucket et le renvoie au client.

Étape 1 : Configurer une règle de récupération par miroir vers l'origine

1. Accédez à la page Buckets et cliquez sur le nom du compartiment cible.

2. Dans le volet de navigation de gauche, choisissez Data Management > Mirroring-based Back-to-origin.

3. Sur la page Mirroring-based Back-to-origin, cliquez sur Create Rule.

4. Dans le panneau Create Rule, configurez les paramètres requis comme décrit dans le tableau suivant. Utilisez les valeurs par défaut pour les autres paramètres.

   Parameter	Configuration
   Method	Select Image.
   Condition	Select Object Name Prefix and set it to examplefolder/.
   Replace or Delete File Prefix	Select Replace or Delete File Prefix and set it to destfolder/. Remarque This option is displayed only after you set Object Name Prefix for the back-to-origin condition.
   Origin URL	Set the first column to https, the second column to example.com, and leave the third column empty.
   MD5 Verification	Select Perform MD5 verification. If the response to the back-to-origin request contains the Content-MD5 header, OSS verifies whether the MD5 hash of the fetched object matches the value of the Content-MD5 header. If the values match, the client receives the object, and OSS saves the object. If the values do not match, the client still receives the object, but OSS does not save it. This is because calculating the MD5 hash requires the complete object data, and at that point, the object has already been streamed to the client.

5. Cliquez sur OK.

Étape 2 : Vérifier la règle

1. Accédez à https://bucket-01.oss-cn-hangzhou.aliyuncs.com/examplefolder/example.txt.

2. Si l'objet examplefolder/example.txt n'existe pas dans le compartiment bucket-01, OSS demande l'objet depuis https://example.com/destfolder/example.txt.

3. Après avoir récupéré l'objet, OSS effectue les opérations suivantes :

   • Si la réponse à la requête de récupération vers l'origine contient l'en-tête Content-MD5, OSS calcule le hachage MD5 de l'objet récupéré et le compare à la valeur de l'en-tête Content-MD5. Si les valeurs correspondent, OSS enregistre l'objet sous le nom examplefolder/example.txt dans le compartiment bucket-01 et le renvoie au client. Si les valeurs ne correspondent pas, OSS renvoie l'objet au client mais ne l'enregistre pas dans le compartiment bucket-01.

   • Si la réponse à la requête de récupération vers l'origine ne contient pas l'en-tête Content-MD5, OSS enregistre l'objet sous le nom examplefolder/example.txt dans le compartiment bucket-01 et le renvoie au client.

Étape 1 : Configurer les règles de récupération par miroir vers l'origine

1. Accédez à la page Buckets et cliquez sur le nom du compartiment cible.

2. Dans le volet de navigation de gauche, choisissez Data Management > Mirroring-based Back-to-origin.

3. Sur la page Mirroring-based Back-to-origin, cliquez sur Create Rule.

4. Dans le panneau Create Rule, configurez deux règles de récupération par miroir vers l'origine comme décrit ci-dessous. Utilisez les valeurs par défaut pour tous les autres paramètres.

   • Rule 1

     Parameter	Configuration
     Method	Select Image.
     Condition	Select Object Name Prefix and set it to dir1/.
     Replace or Delete File Prefix	Select Replace or Delete File Prefix and set it to example1/. Remarque This option is displayed only after you set Object Name Prefix for the back-to-origin condition.
     Origin URL	Set the first column to https, the second column to example.com, and leave the third column empty.
     3xx Response	Select Follow Origin to Redirect Request. Remarque If Follow Origin to Redirect Request is not selected, OSS returns the redirect address specified by the origin server directly to the client.

   • Rule 2

     Parameter	Configuration
     Method	Select Image.
     Condition	Select Object Name Prefix and set it to dir2/.
     Replace or Delete File Prefix	Select Replace or Delete File Prefix and set it to example2/. Remarque This option is displayed only after you set Object Name Prefix for the back-to-origin condition.
     Origin URL	Set the first column to https, the second column to example.org, and leave the third column empty.
     3xx Response	Select Follow Origin to Redirect Request.

5. Cliquez sur OK.

Étape 2 : Vérifier les règles

1. Accédez à https://bucket-02.oss-cn-beijing.aliyuncs.com/dir1/example.txt.

2. Si l'objet example.txt n'existe pas dans le répertoire dir1 du compartiment bucket-02, OSS envoie une requête pour l'objet vers https://example.com/example1/example.txt.

   • Si le serveur d'origine A possède une règle de redirection pour example1/example.txt, OSS envoie une nouvelle requête vers l'adresse redirigée. Après avoir récupéré l'objet, OSS l'enregistre sous le nom dir1/example.txt dans le compartiment bucket-02 et le renvoie au client.

   • Si le serveur d'origine A ne possède pas de règle de redirection pour example1/example.txt, OSS récupère l'objet, l'enregistre sous le nom dir1/example.txt dans le compartiment bucket-02 et le renvoie au client.

3. Si un client demande https://bucket-02.oss-cn-beijing.aliyuncs.com/dir2/example.txt, l'objet récupéré via la règle de récupération par miroir vers l'origine est stocké sous le nom dir2/example.txt dans le compartiment bucket-02.

Étape 1 : Configurer une règle de récupération d'origine par miroir

1. Accédez à la page Buckets et cliquez sur le nom du compartiment cible.

2. Dans le volet de navigation de gauche, choisissez Data Management > Mirroring-based Back-to-origin.

3. Sur la page Mirroring-based Back-to-origin, cliquez sur Create Rule.

4. Dans le panneau Create Rule, configurez les paramètres requis comme décrit dans le tableau suivant. Conservez les valeurs par défaut pour les autres paramètres.

   Paramètre	Configuration
   Method	Sélectionnez Image.
   Condition	Sélectionnez Object Name Prefix et définissez-le sur examplefolder/.
   Origin Type	Sélectionnez Back-to-origin to Private OSS Bucket, puis choisissez bucket-04 dans la liste déroulante Source Bucket. Une fois cette option configurée, lorsqu'un client demande un objet inexistant, OSS utilise le rôle par défaut AliyunOSSMirrorDefaultRole pour récupérer les données depuis le compartiment d'origine privé spécifié. Cela nécessite l'autorisation AliyunOSSReadOnlyAccess, qui garantit qu'OSS ne peut accéder aux données d'origine qu'en mode lecture seule et ne peut ni les modifier ni les supprimer. Pour configurer la récupération d'origine par miroir pour un compartiment OSS privé, un utilisateur RAM doit disposer de l'autorisation ram:GetRole. Cette autorisation permet de vérifier si le rôle AliyunOSSMirrorDefaultRole existe. Si le rôle existe, il est utilisé directement. Si le rôle n'existe pas, nous vous recommandons d'utiliser le compte principal Alibaba Cloud associé à l'utilisateur RAM pour créer préalablement le rôle AliyunOSSMirrorDefaultRole et lui accorder l'autorisation AliyunOSSReadOnlyAccess. Cette pratique évite d'accorder des autorisations à haut risque, telles que la création de rôles (ram:CreateRole) et l'attachement de politiques aux rôles (ram:AttachPolicyToRole), à l'utilisateur RAM. Une fois le rôle autorisé, l'utilisateur RAM peut réutiliser le rôle existant, ce qui réduit les risques liés à la configuration des autorisations.
   Origin URL	Définissez la première colonne sur https et laissez les autres champs vides.
   Origin Parameter	Sélectionnez Transfer with Query String. OSS transmet la chaîne de requête de l'URL de la requête au serveur d'origine.
   Set Transmission Rule of HTTP Header	Sélectionnez Transmit Specific HTTP Headers et ajoutez les en-têtes HTTP header1, header2 et header3. Les règles de récupération d'origine ne prennent pas en charge le transfert de certains en-têtes HTTP standard, tels que authorization, authorization2, range, content-length et date, ni aucun en-tête commençant par x-oss-, oss- ou x-drs-. Important Lors de la récupération depuis un compartiment privé, ne sélectionnez pas l'option permettant de transférer tous les en-têtes HTTP. Cela entraînerait l'échec de la récupération d'origine.

5. Cliquez sur OK.

Étape 2 : Vérifier la règle

1. Accédez à https://bucket-03.oss-cn-shanghai.aliyuncs.com/examplefolder/example.png?caller=lucas&production=oss.

2. Si l'objet examplefolder/example.png n'existe pas dans le compartiment bucket-03, OSS envoie une requête pour cet objet à https://bucket-04.oss-cn-shanghai.aliyuncs.com/examplefolder/example.png?caller=lucas&production=oss.

3. Le compartiment bucket-04 renvoie l'objet example.png à OSS en fonction des paramètres ?caller=lucas&production=oss transférés.

4. OSS enregistre l'objet récupéré sous le nom examplefolder/example.png dans le compartiment bucket-03.

Si la requête contient également les en-têtes HTTP header1, header2 et header3, OSS les transmet également au compartiment bucket-04.

Migration transparente des données

Pour plus d'informations sur la solution de migration, consultez Migration transparente des services vers Alibaba Cloud OSS à l'aide de la récupération d'origine par miroir.

Actualisation des objets mis en cache

La récupération d'origine par miroir est un mécanisme de mise en cache ponctuel. Si un objet sur le serveur d'origine est mis à jour, OSS ne l'actualise ni ne le récupère automatiquement. Vous pouvez utiliser les méthodes suivantes pour actualiser manuellement les objets mis en cache.

• Suppression manuelle : Supprimez l'objet du compartiment OSS à l'aide de la console ou d'une API. La règle de récupération d'origine sera de nouveau déclenchée lors du prochain accès à l'objet.

• Règles de cycle de vie : Configurez une politique d'expiration pour les objets mis en miroir. Ils seront automatiquement supprimés après une période spécifiée, permettant ainsi des actualisations périodiques.

• Versionnement des noms d'objets : Lorsque vous mettez à jour un objet sur le serveur d'origine, utilisez un nouveau nom (par exemple, style.v2.css). Cette approche est recommandée pour éviter les problèmes de mise en cache.

Prévention des risques et tolérance aux pannes

• Charge du serveur d'origine : Assurez-vous que votre serveur d'origine dispose d'une bande passante et d'une capacité de traitement suffisantes pour gérer les requêtes de récupération d'origine. Nous vous recommandons de surveiller la charge de votre serveur d'origine et d'envisager un préchauffage des données pendant les heures creuses.

• Contrôle des coûts : Pour éviter des coûts élevés inattendus, nous vous recommandons de configurer des alertes de coût dans la console Alibaba Cloud Management Console afin de surveiller le volume des requêtes de récupération d'origine.

• Configuration de sécurité : Assurez-vous que votre serveur d'origine est accessible par OSS. Si l'URL d'origine utilise le protocole HTTPS, vérifiez que le certificat du serveur d'origine est émis par une autorité de certification (CA) approuvée, que le nom de domaine correspond et que le certificat n'a pas expiré.

• Requête de journaux : Utilisez la fonctionnalité requête de journaux en temps réel pour afficher les journaux relatifs à la récupération d'origine. L'User-Agent des requêtes de récupération d'origine contient la chaîne aliyun-oss-mirror.

La taille de l'objet mis en miroir diffère de celle de la source

Si vous constatez une différence de taille entre l'objet mis en miroir et l'objet source, suivez les étapes ci-dessous pour enquêter.

1. Vérifiez les horodatages Last-Modified de l'objet mis en miroir et de l'objet source.

   import oss2
   import requests
   from datetime import datetime
   from oss2.credentials import EnvironmentVariableCredentialsProvider
   
   # Obtain credentials from environment variables. Before running this code,
   # make sure the OSS_ACCESS_KEY_ID and OSS_ACCESS_KEY_SECRET environment variables are set.
   auth = oss2.ProviderAuthV4(EnvironmentVariableCredentialsProvider())
   
   # Specify the endpoint for the region where your bucket is located.
   # For example, for China (Hangzhou), the endpoint is https://oss-cn-hangzhou.aliyuncs.com.
   endpoint = "https://oss-cn-hangzhou.aliyuncs.com"
   
   # Specify the region corresponding to the endpoint, e.g., cn-hangzhou.
   # This parameter is required for V4 signatures.
   region = "cn-hangzhou"
   
   # Replace "yourBucketName" with the name of the bucket where you configured the rule.
   bucket = oss2.Bucket(auth, endpoint, "yourBucketName", region=region)
   # Specify the full path of the mirrored object.
   object_key = 'yourObjectKey'
   # Specify the full path of the source object.
   source_url = 'yourSourceUrl'
   
   # Get the Last-Modified timestamp of the mirrored object.
   oss_object_info = bucket.get_object_meta(object_key)
   oss_last_modified = oss_object_info.headers['last-modified']
   print(f"OSS Last-Modified: {oss_last_modified}")
   
   # Get the Last-Modified timestamp of the source object.
   response = requests.head(source_url)
   source_last_modified = response.headers.get('last-modified')
   print(f"Source Last-Modified: {source_last_modified}")
   
   # Convert the timestamp strings to datetime objects for comparison.
   oss_time = datetime.strptime(oss_last_modified, '%a, %d %b %Y %H:%M:%S %Z')
   source_time = datetime.strptime(source_last_modified, '%a, %d %b %Y %H:%M:%S %Z')
   
   if oss_time < source_time:
       print("The source object has been updated.")
   elif oss_time > source_time:
       print("The mirrored object is newer.")
   else:
       print("The timestamps of the two objects are identical.")

   • Si l'horodatage Last-Modified du fichier source est supérieur à l'horodatage Last-Modified du fichier mis en miroir, cela indique que le fichier source a peut-être été mis à jour après la génération du fichier mis en miroir.

     Remarque

     Lorsqu'OSS récupère un objet depuis un serveur d'origine et l'écrit dans un compartiment, il ne conserve pas l'horodatage Last-Modified de l'objet source. À la place, OSS définit l'horodatage Last-Modified de l'objet mis en miroir sur l'heure de sa création ou de sa mise à jour dans OSS.

   • Si l'horodatage Last-Modified du fichier source est ≤ à l'horodatage Last-Modified du fichier de récupération d'origine par miroir, cela indique que le fichier source n'a pas été mis à jour depuis la génération du fichier de récupération d'origine par miroir. L'étape suivante consiste à vérifier les valeurs de somme de contrôle MD5 ou CRC64 des deux fichiers.

2. Comparez les sommes de contrôle MD5 ou CRC64 de l'objet mis en miroir et de l'objet source.

   # -*- coding: utf-8 -*-
   import oss2
   import hashlib
   import requests
   # For CRC64 comparison, the Python standard library does not support CRC64.
   # You can use a third-party library like crcmod.
   # Install crcmod: pip install crcmod
   import crcmod
   from oss2.credentials import EnvironmentVariableCredentialsProvider
   
   # Obtain credentials from environment variables. Before running this code,
   # make sure the OSS_ACCESS_KEY_ID and OSS_ACCESS_KEY_SECRET environment variables are set.
   auth = oss2.ProviderAuthV4(EnvironmentVariableCredentialsProvider())
   
   # Specify the endpoint for the region where your bucket is located.
   # For example, for China (Hangzhou), the endpoint is https://oss-cn-hangzhou.aliyuncs.com.
   endpoint = "https://oss-cn-hangzhou.aliyuncs.com"
   
   # Specify the region corresponding to the endpoint, e.g., cn-hangzhou.
   # This parameter is required for V4 signatures.
   region = "cn-hangzhou"
   
   # Replace "yourBucketName" with the name of the bucket where you configured the rule.
   bucket = oss2.Bucket(auth, endpoint, "yourBucketName", region=region)
   # Specify the full path of the mirrored object.
   object_key = 'yourObjectKey'
   # Specify the full path of the source object.
   source_url = 'yourSourceUrl'
   
   # Get the metadata of the mirrored object.
   oss_object_info = bucket.get_object_meta(object_key)
   
   oss_md5 = oss_object_info.headers.get('etag', '').strip('"')  # ETag is usually the MD5 hash
   oss_crc64 = oss_object_info.headers.get('x-oss-hash-crc64ecma', '')
   
   print(f"OSS MD5: {oss_md5}")
   print(f"OSS CRC64: {oss_crc64}")
   
   # Get the content of the source object and calculate its MD5 and CRC64.
   response = requests.get(source_url)
   if response.status_code == 200:
       source_content = response.content
       source_md5 = hashlib.md5(source_content).hexdigest()
       print(f"Source MD5: {source_md5}")
   
       crc64_func = crcmod.predefined.mkCrcFun('crc-64')
       source_crc64 = hex(crc64_func(source_content))[2:].upper().zfill(16)  # Convert to hex string and format
       print(f"Source CRC64: {source_crc64}")
   
       # Compare the MD5 values.
       if oss_md5 == source_md5:
           print("MD5 checksums are identical.")
       else:
           print("MD5 checksums do not match.")
   
       # Compare the CRC64 values.
       if oss_crc64.upper() == source_crc64:
           print("CRC64 checksums are identical.")
       else:
           print("CRC64 checksums do not match.")
   else:
       print(f"Failed to fetch source file. HTTP Status Code: {response.status_code}")
       

   • Si les sommes de contrôle MD5 ou CRC64 sont identiques, le contenu des deux objets est le même. Dans ce cas, leurs tailles doivent également être identiques.

   • Si les sommes de contrôle MD5 ou CRC64 ne correspondent pas, le contenu des deux objets est différent. Passez à l'étape suivante pour vérifier la présence d'en-têtes de requête spéciaux.

3. Vérifiez la présence d'en-têtes de requête spéciaux.

   root@qa ~ # ossutil stat oss://xxx
   ACL                          : default
   Accept-Ranges                : bytes
   Content-Encoding             : gzip
   Content-Length               : 1051
   Content-Md5                  : ZMRnM8Rycyel
   Content-Type                 : text/plain
   Etag                         : "64C46733C4xxx"
   Last-Modified                : 2025-01-26 13:32:49 +0800 CST
   Owner                        : xxx
   Vary                         : Origin
   X-Oss-Expiration             : expiry-date="Mon, 27 Jan 2025 00:00:00 GMT", rule-id="004xxx"
   X-Oss-Hash-Crc64ecma         : 4241986122514178170
   X-Oss-Object-Type            : Normal
   X-Oss-Storage-Class          : Standard
   X-Oss-Version-Id             : CAEQORiBgIDmrLKEpRxxx
   
   0.092282(s) elapsed
   root@qa ~ # ossutil stat xxx
   ACL                          : public-read
   Accept-Ranges                : bytes
   Content-Length               : 1048576
   Content-Md5                  : ttgBkgMcfgU
   Content-Type                 : text/plain
   Etag                         : "B6D818360A56xxx"
   Last-Modified                : 2024-05-29 13:06:16 +0800 CST
   Owner                        : xxx
   Vary                         : Accept-Encoding
   X-Oss-Expiration             : expiry-date="Thu, 30 May 2024 00:00:00 GMT", rule-id="60fxxx"
   X-Oss-Hash-Crc64ecma         : 6947790692288575170
   X-Oss-Object-Type            : Normal
   X-Oss-Server-Side-Encryption : KMS
   X-Oss-Server-Side-Encryption-Key-Id: xxx
   X-Oss-Storage-Class          : Standard
   X-Oss-Version-Id             : CAEQMRiBgIDnSvuK_hgiIDRlNG
   
   0.120707(s) elapsed

   • Vérifiez si la requête de récupération d'origine contient des en-têtes de requête HTTP spéciaux, tels que Accept-Encoding: gzip, deflate, br. Cet en-tête indique que le client peut accepter des données compressées.

   • Si la requête de récupération d'origine utilise la compression HTTP et que l'objet demandé répond aux critères de compression, les tailles des deux objets seront différentes.

   • Si l'en-tête Accept-Encoding est présent, ne le transférez pas.

     • Si vous avez configuré la règle pour transférer tous les en-têtes HTTP, ajoutez accept-encoding à la liste des en-têtes interdits.

     • Si vous avez configuré la règle pour transférer des en-têtes HTTP spécifiques, assurez-vous que accept-encoding n'est pas inclus dans la liste des en-têtes spécifiés.

       Sélectionnez Transmit Specific HTTP Headers et ajoutez content-type dans le champ de saisie des paramètres.

Dépannage des échecs de récupération d'origine

Si vous rencontrez un échec de récupération depuis l'origine (tel qu'une erreur 424 MirrorFailed), vous pouvez résoudre le problème en suivant les étapes ci-dessous.

1. Vérifiez l'accessibilité du serveur d'origine.

   # Replace the URL with your actual origin server address and file path
   curl -I "https://www.example.com/images/test.jpg"

2. Vérifiez la résolution DNS.

   # Replace the domain name with your actual origin domain name
   nslookup www.example.com

3. Vérifiez le certificat HTTPS (si le serveur d'origine utilise HTTPS).

   # Replace the domain name with your actual origin domain name
   openssl s_client -connect www.example.com:443 -servername www.example.com

4. Analysez le problème à l'aide de la fonctionnalité requête de journaux en temps réel d'OSS.

Aucun objet mis en miroir créé

Une requête HEAD d'un client récupère uniquement les métadonnées de l'objet, telles que la taille et le type, sans télécharger le contenu. Par conséquent, les requêtes HEAD ne déclenchent pas les règles de récupération d'origine par miroir pour récupérer un objet depuis le serveur d'origine et l'écrire dans le compartiment OSS.

Code d'état inattendu provenant de la récupération d'origine

Lorsqu'une requête déclenche une récupération d'origine par miroir, si le serveur d'origine renvoie un code d'état autre que 404, 200 ou 206, analysez la réponse du serveur d'origine.

• L'origine est OSS : Vérifiez les éléments de configuration suivants.

  • Interdire le transfert d'en-têtes HTTP spécifiques : Interdisez le transfert de l'en-tête host pour éviter d'exposer les informations du serveur d'origine et garantir que les requêtes de récupération d'origine sont traitées comme prévu. Si vous n'interdisez pas le transfert de l'en-tête host, la requête de récupération d'origine transmettra la valeur host du compartiment cible au serveur d'origine. Étant donné que la valeur host de chaque compartiment est unique, si le host demandé ne correspond pas au host réel de l'origine, le serveur d'origine renvoie une erreur 403. OSS renvoie alors une erreur 424 au client.

  • Récupération d'origine pour un compartiment OSS privé : Si les autorisations ne sont pas configurées, vérifiez si l'ACL du compartiment cible et de ses objets est définie sur public-read. Si les autorisations sont configurées, vérifiez si la stratégie d'autorisation de rôle pour la récupération d'origine par miroir a changé, entraînant des autorisations insuffisantes. Le rôle par défaut pour la récupération d'origine par miroir est AliyunOSSMirrorDefaultRole et sa politique système par défaut est AliyunOSSReadOnlyAccess.

• L'origine n'est pas OSS : Analysez les journaux côté serveur et vérifiez les configurations pour l'indication du nom de serveur (SNI), les paramètres de récupération d'origine et le transfert d'en-têtes afin d'identifier la cause spécifique de l'erreur du serveur d'origine. Le serveur d'origine peut renvoyer des codes d'état tels que 401 (Non autorisé), 403 (Interdit) ou une erreur 5xx (Erreur interne du serveur).

Ordre de correspondance des règles de récupération d'origine

Les règles sont mises en correspondance en fonction du numéro de règle (RuleNumber) par ordre croissant. Après la correspondance de la première règle qui remplit les conditions, cette règle est immédiatement exécutée et aucune règle suivante n'est mise en correspondance.

Récupération depuis un VPC ou une IP interne

Non. Le serveur d'origine doit avoir une adresse publiquement accessible. Pour accéder à un service dans un VPC, exposez-le à Internet public à l'aide d'une passerelle NAT ou d'une instance SLB orientée Internet.

Objet OSS non mis à jour après la mise à jour de la source

La récupération d'origine par miroir est un mécanisme d'extraction ponctuel et ne synchronise pas automatiquement les mises à jour depuis le serveur d'origine. Pour récupérer un objet mis à jour, vous devez supprimer manuellement l'objet mis en miroir d'OSS ou utiliser une stratégie de versionnement des noms d'objets.