Pour un besoin métier nous aurions besoin, à la suite d’un adapter (dans la méthode postProcess). J’ai tenté d’utiliser ce qui est indiqué dans la documentation : training section S3.
J’ai bien configurer le paramètre système comme indiqué mais lorsque j’ajoute la ligne :
cst = new CloudStorageTool(getGrant().getJSONObjectParameter(“SUP_S3_STORAGE”));
L’adapteur ne s’arrête plus (je l’ai laissé tourner toute la nuit mais il ne s’est pas terminé). Sans cette ligne il ne dure que quelques millisecondes.
Y aurait-il un moyen de tester la connexion à la bucket pour savoir si le sytème parvient à s’y connecter ou sinon de voir pourquoi il n’y parvient pas?
Sur quelle version/révision êtes vous ?
L’info s’obtient en appealnt le /health
Je pose la question car en fct de la révision les libs JClouds ur lesquelles s’appuient notre classe tool “CloudStorageTool” ne sont pas de même version
OK vous êtes sur la branche release. On va faire un test sur nos environnements
Je vois que vous êtes dans un container Docker. Celui-ci a-t-il la connectivité nécessaire pour accéder aux APIs S3 ?
Pour vérifier vous pouvez vous connecter en bash sur un container et faire des test par curl (ou alors si vous n’avez pas la main sur votre container vous pouvez toujours écrire un objet externe utilisant des APIs Java de bas niveau pour vérifier cette connectivité).
Par “connectivité” je veux dire “tuyauterie réseau”, votre container est en effet dans un réseau qui n’a peut être pas accès aux services S3 ou qui ne sait pas résoudre au niveau DNS le hostname des URLs de l’API S3 etc…
Les appels aux APIs S3 ne sont en fait que des appels HTTP qui suivent un “protocole” fonctionnel ad hoc - géré par la lib JClouds - mais ça reste de simples appels HTTP. Donc le test de base c’est un simple curl (en ligne de commande dans le container ou en Java dans un objet externe) pour voir si déjà depuis l’endroit où s’exécute votre code vous avez bien un tuyau qui fonctionne pour appeler en HTTP ces APIs…
En // de vos investigations dans l’enfer des habilitations AWS je fais des tests dans un environnement technique que je maîtrise et sur la même révision que vous et je vous dis si notre CloudStorageTool fait ce qu’il est sensé faire. Peut être que votre cas est un cas plus compliqué auquel cas vous devrez tapez directement dans les APIs de la lib JClouds.
Bon j’ai testé sur les branches prerelease (image Docker “beta”) et release (image Docker “latest”).
Sur ces 2 branches il y a un pb de dépendance entre les libs Google et les libs JClouds concernant la lib gson (https://mvnrepository.com/artifact/com.google.code.gson/gson), les libs Google ont besoin d’une version >= 2.8.5 alors que les libs JClouds ont besoin d’une version <= 2.6.2… Bref on va devoir faire des tests pour voir quel est la bonne solution : upgrader les libs JClouds et/ou les libs Google ou juste downgrader la lib gson en 2.6.2, en espérant que ça ne nous emmène pas dans d’autres inextricables pbs de dépendances…
Mais bon ça crache simplement une série d’exceptions à l’instanciation du wrapper CloudStorageTool et ça rend la main immédiatement. Donc votre pb d’appels qui ne répondent jamais sont, selon moi, plutôt lié à un pb de tuyauterie.
Bon la bonne solution était d’upgrader les libs JClouds. Cela a été poussé sur les branches prerelease et release (donc sur les images Docker “beta” et “latest”).
J’ai bien mis à jour mon instance à la suite de votre message, cependant je ne parviens toujours à accéder à la bucket.
J’ai crée un objet externe dans lequel j’ai collé le code que vous avez fourni plus haut (en remplaçant bien sûr le paramètre contenant les informations sur la bucket). Je l’ai ajouté dans un domaine pour y avoir accès depuis la page principale :
En revanche dans les logs il n’apparaît strictement rien. Savez-vous s’il est possible d’augmenter ce niveau de logs? Mon but ici est surtout de savoir si il s’agit d’un problème d’authentification auprès de la bucket (lié aux informations de connexion) ou carrément d’un problème d’accès à S3.
Si ça répond comme ci-dessus (ou comme ci-dessous quand on passe par un simple navigateur) c’est que la tuyauterie est ok (et donc qu’il y a un autre pb, genre authentification)
J’ai fais vérifier les paramètres de connexion que j’utilise auprès des propriétaires de ces données et il s’avère qu’il y avait un problème dans l’url.
Maintenant, j’obtiens une erreur “Access Denied” avec votre test. J’ai réessayé avec votre exemple plus haut mais ça ne fonctionne toujours pas. J’obtiens un erreur 500 dans l’interface lorsque je clique sur l’entrée de l’objet dans le menu et rien dans les logs.
Je ne vois plus vraiment d’axe de recherche de mon côté.
Auriez-vous des nouvelles d’une versions fournissant d’avantage de logs?
Mon code de test ne gère pas l’authentification AWS donc le mieux qu’il puisse obtenir c’est un"AccessDenied" comme sur ma copie d’écran. S’il l’obtient ça veut bien dire qu’il n’y a plus de pb de tuyauterie technique. C’est un bon point.
Je n’ai pas eu le temps d’ajouter un mode “verbeux” au wrapper CloudStorageTool. Mais le but de ce wrapper c’est juste d’offrir des méthodes simplifiées qui marchent dans les cas usuels auxquels on a été confrontés jusqu’ici. Mais rien ne vous oblige à utiliser ce composant, vous pouvez directement utiliser les APIs JClouds.
J’ai redéployé le docker (en attendant votre réponse) et désormais ça fonctionne! Je ne comprends pas bien pourquoi si il était déjà sur la dernière résision… Mais l’essentiel c’est que ça marche.
Merci pour votre aide.
