Connecter Base de données OCI avec PostgreSQL vers Excel, Google Sheets, l'IA et REST

Il n'existe pas de point de terminaison public, et cela s'avère être le cas le plus simple.

Normalement, c'est une base de données privée qui pose problème. Ici, c'est l'inverse, car l'agent a été conçu précisément pour ce type de configuration.

• La base de données OCI avec PostgreSQL est conçue pour être privée au sein d'un VCN. Il n'existe aucun nom d'hôte public à activer ni aucun paramètre permettant d'en définir un.
• Ainsi, tout outil se connectant à son propre cloud ne peut y accéder, et les solutions de contournement habituelles — un serveur bastion, un sous-réseau public, un VPN pour se connecter au bureau — tout cela signifie étendre quelque chose.
• L'agent ne se connecte pas à Internet. Placez-le sur une instance de calcul du même VCN ; il se comporte alors comme un simple client sur le réseau privé et ouvre une seule connexion sortante vers Query Streams pour toutes les autres requêtes. Le VCN reste inchangé.
• Cette connexion sortante est la seule voie d'entrée ou de sortie, et aucune règle de liste de sécurité entrante n'est nécessaire pour la créer. La base de données reste aussi privée qu'avant sa connexion à une feuille de calcul.

Le branding s'appuie sur la connexion enregistrée, car une adresse IP privée ressemble à n'importe quelle autre.

Une petite conséquence de la confidentialité qui mérite d'être expliquée, car elle fait que cette carte se comporte légèrement différemment des autres.

• Ici, chaque autre carte hébergée reconnaît son fournisseur à partir du nom d'hôte. — .neon.tech, .render.com, .aivencloud.com. Il n'existe pas d'équivalent OCI, car votre point de terminaison est une adresse privée au sein de votre propre réseau et peut être n'importe quoi.
• Ce préréglage est donc identifié par la carte sélectionnée, et non par l'adresse. C'est le fait de la sélectionner qui enregistre qu'il s'agit d'une carte OCI.
• La connexion n'en dépend pas ; il s'agit de l'interface et des paramètres par défaut, pas du protocole réseau. En interne, on trouve PostgreSQL et l'agent utilise le pilote Npgsql.
• Cela signifie que cette carte vaut la peine d'être choisie plutôt qu'une configuration PostgreSQL générique, même si les deux permettent la connexion. Heroku est la seule autre solution préconfigurée dans la même situation, et pour la même raison.

Le chiffrement suit la case à cocher, et le réseau privé en est la raison.

La plupart des fiches Postgres gérées ici indiquent que l'agent force l'utilisation de TLS, quelle que soit la valeur de la case à cocher. Celle-ci ne le fait pas, et ce, intentionnellement.

• La case SSL est cochée par défaut et, si elle l'est, la connexion est chiffrée. C'est le comportement normal et cela ne nécessite aucune intervention.
• L'agent ne modifie pas cette configuration, car un système de base de données privée VCN avec TLS désactivé est une configuration légitime et forcer le chiffrement interromprait une connexion fonctionnelle. Le trafic sur un sous-réseau privé ne transite jamais par l'Internet public.
• La consigne est donc simple : laissez cette option activée sauf si votre système de base de données a le protocole TLS désactivé, auquel cas désactivez-la.
• Lorsque le chiffrement est activé, la chaîne de certificats n'est pas vérifiée. Il faut la considérer comme une protection contre l'interception du trafic en transit, et non comme une preuve du serveur ayant répondu.
• Tout ce que l'agent exécute est en lecture seule, les informations d'identification restent sur l'instance Compute sur laquelle vous l'avez installé et Query Streams ne conserve aucune copie de vos données.

-- Postgres ordinaire, en lecture seule, depuis l'intérieur du VCN\nSELECT c.name,\n COUNT(o.id) AS orders,\n SUM(o.amount) AS revenue\nFROM public.customers AS c\nJOIN public.orders AS o ON o.customer_id = c.id\nWHERE o.placed_at >= now() - interval '30 days'\nGROUP BY c.name\nORDER BY revenue DESC;