Problème adapter + Connexion S3

Problème adapter + Connexion S3
0
Tags: #<Tag:0x00007eff962deed8>

Bonjour,

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 : https://docs.simplicite.io/documentation/01-core/third-party-apis-examples.md 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?

Merci d’avance.

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

Bonjour ,
Merci de votre réponse, voici le /health de mon instance :

[Platform]
Status=OK
Version=4.0.P23
BuiltOn=2019-10-27 13:22 (revision 7ce2deb82c21811660ada1b38b60a9ad2d9d56a0)
Encoding=UTF-8
EndpointIP=172.17.0.3
EndpointURL=http://4f097b128069:8080
TimeZone=Europe/Paris
SystemDate=2019-10-31 12:52:15

[Application]
ApplicationVersion=0.8 dev
ContextPath=
ContextURL=https://int.rff.dev.aws.renault.com
ActiveSessions=1
EnabledUsers=8
TotalUsers=9
LastLoginDate=2019-10-31 12:00:00

[Server]
ServerInfo=Apache Tomcat/9.0.27
ServerType=WEB
User=root

[OS]
Name=Linux
Architecture=amd64
Version=4.14.101-75.76.amzn1.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=8873
DiskUsable=8345
DiskTotal=10015

[JavaVM]
Version=13
Vendor=N/A
VMName=OpenJDK 64-Bit Server VM
VMVersion=13+33
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.10 2018 04 09
HeapFree=233995
HeapSize=506948
HeapMaxSize=1773888
TotalFreeSize=1500935

[Cache]
GrantCache=20
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=8
ObjectCacheMax=10000
ObjectCacheRatio=0
ProcessCache=0
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=10.6
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.2.8
DBDate=2019-10-31 12:52:15
DBDateOffset=0
DBPatchLevel=P23
UsingBLOBs=true

[Healthcheck]
Date=2019-10-31 12:52:15
ElapsedTime=19

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é).

Quand vous dites connectivité pour accéder aux APIs S3, vous parler du module AWSCLI?

Je n’ai effectivement pas la main pour me connecter en bash sur le container.

Je vais essayer avec un objet externe.

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.

Mon test de creation de fichier S3 fonctionne sur une revision de dev à jour:


Avec le code suivant:

package com.simplicite.extobjects.CloudStorages;

import java.util.Date;

import com.simplicite.util.Globals;
import com.simplicite.util.Tool;
import com.simplicite.util.AppLog;
import com.simplicite.util.ExternalObject;
import com.simplicite.util.tools.Parameters;
import com.simplicite.util.tools.CloudStorageTool;
import com.simplicite.util.tools.HTTPTool;
import com.simplicite.util.tools.HTMLTool;

import org.json.JSONObject;

/**
 * Cloud storage example
 */
public class CloudStorageExample extends ExternalObject {
	private static final long serialVersionUID = 1L;

	/**
	 * Display method
	 * @param params Parameters
	 */
	@Override
	public String display(Parameters params) {
		StringBuilder h = new StringBuilder();
		CloudStorageTool cst = null;
		try {
			String cfg = "CLOUDSTORAGES_AWS_S3";
			//String cfg = "CLOUDSTORAGES_GOOGLE_CLOUD_STORAGE";
			//String cfg = "CLOUDSTORAGES_AZUREBLOB";
			//String cfg = "CLOUDSTORAGES_OPENSTACK_SWIFT";
			JSONObject config = getGrant().getJSONObjectParameter(cfg);
			h.append("<pre class=\"mono\">" + Tool.toHTML(config.toString(2)) + "</pre>");
			cst = new CloudStorageTool(config);
			
			cst.put(new JSONObject()
				.put("name", "test.html")
				.put("mime", HTTPTool.MIME_TYPE_HTML)
				.put("encoding", "UTF-8")
				.put("content", "<html><body>hello world " + new Date() + "!</body></html>")
			);

			JSONObject file = cst.get("test.html", true);
			file.put("content", new String((byte[])file.get("content"), "UTF-8"));
			h.append("<pre class=\"mono\">" + Tool.toHTML(file.toString(2)) + "</pre>");
		} catch (Exception e) {
			AppLog.error(getClass(), "display", null, e, getGrant());
			h.append("<div>" + e.getMessage() + "</div>");
		} finally {
			if (cst != null) cst.close();
		}
		setHTML(h.toString());
		return javascript("void(0)");
	}
}

Je vais faire le même test sur la même révision que vous

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”).

Bonjour,

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 :

Lorsque je clique dessus j’obtiens une erreur :

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.

Merci d’avance.

En l’état le wrapper ne permet pas trop d’avoir plus de logs de debug. On va regarder ce qui peut être amélioré sur ce point.

En attendant un premier test à faire c’est de faire un simple appel HTTP sur l’URI du bucket (via des APIs Java bas niveau genre https://docs.simplicite.io/4.0/javadoc/com/simplicite/util/Tool.html#readUrl-java.lang.String-)

@Override
public String display(Parameters params) {
	try {
		setHTML("<pre class=\"mono\">" + Tool.toHTML(Tool.readUrl("https://simplicitesoftware.s3.eu-west-3.amazonaws.com")) + "</pre>");
	} catch (Exception e) {
		AppLog.error(getClass(), "display", null, e, getGrant());
		setHTML("<pre>" + Tool.toHTML(e.getMessage()) + "</pre>");
	}
	return javascript("void(0)");
}

Qui donne imédiatement ça à l’excution:

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)


Sinon, si ça répond pas c’est que c’est, comme je le pense, plutôt un pb de tuyauterie entre le container Docker et S3

Bonsoir,

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?

Merci d’avance.

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.

PS: on est bien d’accord que vous avez mis à jour votre instance pour avoir les dernières libs JClouds (cf. une de mes réponses précédentes)

Ma version date du 27 Octobre, est-ce la bonne version?

J’ai besoin des informations du /health pour savoir quelle révision exacte vous avez déployée. La date ne suffit pas.

Voici le health :

[Platform]
Status=OK
Version=4.0.P23
BuiltOn=2019-11-08 22:30 (revision 6970090e933f9e3544da86b2900f87c507f568ba)
Encoding=UTF-8
EndpointIP=172.17.0.17
EndpointURL=http://348aefa59091:8080
TimeZone=Europe/Paris
SystemDate=2019-11-12 10:38:44

[Application]
ApplicationVersion=0.8 dev
ContextPath=
ContextURL=https://int.rff.dev.aws.renault.com
ActiveSessions=32
EnabledUsers=8
TotalUsers=9
LastLoginDate=2019-11-12 10:38:36

[Server]
ServerInfo=Apache Tomcat/9.0.27
ServerType=WEB
User=root

[OS]
Name=Linux
Architecture=amd64
Version=4.14.101-75.76.amzn1.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=9182
DiskUsable=8654
DiskTotal=10015

[JavaVM]
Version=13
Vendor=N/A
VMName=OpenJDK 64-Bit Server VM
VMVersion=13+33
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.10 2018 04 09
HeapFree=266889
HeapSize=662488
HeapMaxSize=1773888
TotalFreeSize=1378289

[Cache]
GrantCache=34
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=185
ObjectCacheMax=10000
ObjectCacheRatio=1
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=10.6
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.2.8
DBDate=2019-11-12 10:38:44
DBDateOffset=0
DBPatchLevel=P23
UsingBLOBs=true

[Healthcheck]
Date=2019-11-12 10:38:44
ElapsedTime=106

OK cette révision (6970090e933f9e3544da86b2900f87c507f568ba) est bien la plus récente sur cette branche “release”.

Les libs JClouds embarquées dans cette révision sont les dernières (2.2.0, cf. https://mvnrepository.com/artifact/org.apache.jclouds/jclouds-core/2.2.0).

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.

La mise à jour des libs JClouds a été poussée le 01/11/2019 à 20:30:

commit f3c7e70dbec79a73fa3d9d53b1fa84d73112e82e
Author: David AZOULAY <dazoulay@simplicite.io> 2019-11-01 20:30:32
Committer: David AZOULAY <dazoulay@simplicite.io> 2019-11-01 20:30:32
Branches: origin/release

Updated JClouds libs

Si vous aviez déployé une révision du 27/10 elle contenait forcément les anciennes libs JClouds.