CLUSTER_CONFIG

[Jean-Baptiste-Lasselle]

Bon ok,j'ai trovué un nouvreau truc :+1:

• L'erreur de connection sur localhost :8090, localhost :8088, etc... concenent le "rendererselector.go", ce qui a tendance à faire penser à un cluster managment à la con

opt: connection refused
2018/10/28 02:11:19 renderselector.go:117: [DEBUG] '%v' is %v localhost:8090 Offline
2018/10/28 02:11:49 renderselector.go:209: [DEBUG] ping error %v dial tcp 127.0.0.1:8090: getsockopt: connection refused
2018/10/28 02:11:49 renderselector.go:117: [DEBUG] '%v' is %v localhost:8090 Offline
2018/10/28 02:12:19 renderselector.go:209: [DEBUG] ping error %v dial tcp 127.0.0.1:8090: getsockopt: connection refused
2018/10/28 02:12:19 renderselector.go:117: [DEBUG] '%v' is %v localhost:8090 Offline
2018/10/28 02:12:49 renderselector.go:209: [DEBUG] ping error %v dial tcp 127.0.0.1:8090: getsockopt: connection refused
2018/10/28 02:12:49 renderselector.go:117: [DEBUG] '%v' is %v localhost:8090 Offline
^C

• D'autre part, j'ai remarqué que le fichier ./renderer/map_data/config.json est de toute évidence une configuration de cluster (ça parle de slave ...), et de plus que le port 8090 y est bien mentionné, là où il n'est mentionné nul part dansx mon ./docker-compose.yml, ou mon ./.env .

Je pense, pour terminer, qu'il sera logique de créer des conteneurs renderer, autant que d'hôtes réseau mentionnés dans le ./renderer/map_data/config.json (manifestemenet un fichier de conf gopnik)

p.s.: et au fait : gopnik == mapnik, but written in go?

[Jean-Baptiste-Lasselle]

Ouep, dans le fameux ./renderer/map_data/config.json du conteneur gopnik, il y a mention :

• de 4 numéros de port distincts : 8080, 9090, 8088, 8090
• Pour tous ces nuémros de ports, on a une mention de la forme :$NUMERO_DE_PORT, probablement un équivalent d'une forme 0.0.0.0:$NUMERO_DE_PORT soit l'interface par défaut.
• Tous, sauf. Non pas un Gaulois, mais pour le numéro de port 8090, il y a mention de localhost essayer avec la même forme que les autres, sans rien modifier d'autre.

[Jean-Baptiste-Lasselle]

Effectivement, cela a bien changé les logs du renderer :+1:

Désormais, le seul problème qui reste est un erreur d'authentification du serveur GOPNIK, au serveur PostGreSQL.

Et c'est logique, puisque je suis en train de résoudre ce dernier problème, en reconstruisantt de zéro mon stack postgresql / postgis dockerisé (les images et Dockerfiles trouvées dans les repos et doc parcourues présntent souvent le problème de référencer la 'latest', et bien evidemment, 12 mois plus tard, on obtient un plantage. Exemple : dans le [fichier dockerfile suggéré par la documentation Docker](), et que otu ce petit monde semble utiliser sans se poser de question, on un FROM ubuntu. Sauf que python-software-properties n'existe plus sur les repository Ubuntu des releases >= 12.04, et pas de chance, aujourd'hui on est bien plus loin que la rrelease 12.04, dans les latest publiée par Ubuntu.

[jibl@pc-100 proto]$ docker logs -f rendereurpoulet
 ------------------------------------------------------------------------------------------- 
 VERIFICATION RENDERER ENNTRYPOINT : [MAPNIK_POSTGRES_USER=renderer_user] 
 VERIFICATION RENDERER ENNTRYPOINT : [MAPNIK_POSTGRES_DB=bddgeoloc] 
 VERIFICATION RENDERER ENNTRYPOINT : [MAPNIK_POSTGRES_DB_HOST=postgis] 
 VERIFICATION RENDERER ENNTRYPOINT : [MAPNIK_POSTGRES_PASSWORD=whereischarlie] 
 VERIFICATION RENDERER ENNTRYPOINT : [PGUSER=renderer_user] 
 VERIFICATION RENDERER ENNTRYPOINT  : [PGPASSWORD=whereischarlie] 
 ------------------------------------------------------------------------------------------- 

 ----- 
 VERIF JBL dans complie_style.sh de monsieur catactrophe aka 'domman84' [MAPNIK_POSTGRES_DB_HOST=postgis]
 VERIF JBL dans complie_style.sh de monsieur catactrophe aka 'domman84' [MAPNIK_POSTGRES_DB_PORT_NO=5432]
 VERIF JBL dans complie_style.sh de monsieur catactrophe aka 'domman84' [MAPNIK_POSTGRES_DB=bddgeoloc]
 VERIF JBL dans complie_style.sh de monsieur catactrophe aka 'domman84' [MAPNIK_POSTGRES_USER=renderer_user]
 VERIF JBL dans complie_style.sh de monsieur catactrophe aka 'domman84' [MAPNIK_POSTGRES_PASSWORD=whereischarlie]
 ----- 

DB successfully created, waiting for restart
Starting renderer
2018/10/28 02:48:23 renderselector.go:209: [DEBUG] ping error %v dial tcp :8090: getsockopt: connection refused
2018/10/28 02:48:23 renderselector.go:117: [DEBUG] '%v' is %v :8090 Offline
2018/10/28 02:48:23 app.go:266: [INFO] Serving debug data (/debug/vars) on %s... :9080
2018/10/28 02:48:23 app.go:267: [INFO] Serving monitoring xml data on %s... :9080
2018/10/28 02:48:23 main.go:118: [INFO] Starting on %s... :8080
2018/10/28 02:48:23 app.go:266: [INFO] Serving debug data (/debug/vars) on %s... :9090
2018/10/28 02:48:23 app.go:267: [INFO] Serving monitoring xml data on %s... :9090
2018/10/28 02:48:23 render.go:35: [ERROR] Render child error: %v Exception: Postgis Plugin: FATAL:  password authentication failed for user "renderer_user"

2018/10/28 02:48:23 render.go:35: [ERROR] Render child error: %v 

2018/10/28 02:48:23 render.go:35: [ERROR] Render child error: %v Connection string: 'host=postgis port=5432 dbname=bddgeoloc user=renderer_user connect_timeout=4'

2018/10/28 02:48:23 render.go:35: [ERROR] Render child error: %v   encountered during parsing of layer 'landcover-low-zoom' in Layer at line 334 of '/openstreetmap-carto/stylesheet.xml'

2018/10/28 02:48:23 render.go:35: [ERROR] Render child error: %v Exception: Postgis Plugin: FATAL:  password authentication failed for user "renderer_user"

2018/10/28 02:48:23 render.go:35: [ERROR] Render child error: %v 

2018/10/28 02:48:23 render.go:35: [ERROR] Render child error: %v Connection string: 'host=postgis port=5432 dbname=bddgeoloc user=renderer_user connect_timeout=4'

2018/10/28 02:48:23 render.go:35: [ERROR] Render child error: %v   encountered during parsing of layer 'landcover-low-zoom' in Layer at line 334 of '/openstreetmap-carto/stylesheet.xml'

2018/10/28 02:48:23 main.go:91: [CRITICAL] Failed to create tile server: Failed to create some renders: [Invalid read uint64: EOF Invalid read uint64: EOF]
^C
[jibl@pc-100 proto]$ 

[Jean-Baptiste-Lasselle]

Oh purée, le fameux fichier ./renderer/map_data/config.json :+1:

Nom dé diou, c'est un template gopnik pour graver la topologie du cluster .. Dans la confgiuration Docker /etc/docker/daemon.json !!! :-o

cf. https://github.com/sputnik-maps/gopnik/blob/master/example/dockerconfig.json

Tu crois qu'ils aureint ne serait-e que mentionné cela, dansle tutoriel originel shinemachin... :-o :-o !!?? :skull:

[Jean-Baptiste-Lasselle]

Liste des numéros de port mentionnés dans la configuration gopnik ./renderer/map_data/config.json :+1:

• Dispatcher
  • :8080 ( Main Address )
  • :8090 ( ClusterPlugin / Nodes )
• Render
  • :8080 ( Main Address )
  • :9090 ( Debug Address )
• Prerender
  • :8088 ( UI Address )
  • :8090 ( Slaves / ClusterPlugin )
• Prerender Slaves
  • :8080
  • ( Pas de second numéro de port )

Voilà pour la topologie, je pense. REMARQUES IMMEDIATES ! Il y a un probable conflit d'entrée, entre le Dispatcher et le(s) Prerender : ils fot tout deux usage du numéro de port 8090, exectement :8090 signifie plus qu'un numéro de port : ils appellent cela adresse, mais :

• Une notation équivalente courante serait 0.0.0.0:8090, et alors 0.0.0.0 fait référence à l'interface réseau par défaut de l'instance d'OS. En effet, Linux a la notion d'interface réseau par défaut, aprce que les serveurs ont souvent plusieurs port Ethernet / RJ45 / SFP, et le traffic réseau peut rarement (je ne connais aucun protocole réseau capable de cela) utiliser Plusieurs ports Ethernet à la fois. Voyez la notion de 'Predictable interface names, et sienp0s3 enp0s9 enp0s10` vous dit quelque chose...

• Bref, 0.0.0.0:8090 fait bien référence à l'interface réseau par défaut, ... et ce qui est important, c'est que ce n'est JAMAIS localhost. ET c'est certainement pour cette raison que j'ai trouvé des localhost dans ce fichier de configuration : Eh oui, lorsque 2 éléments du cluster (des machins, et des bidules, peu importe ce que c'est) font usage du même numéro de port, au sein de la même machine, le concepteur a atribué le localhost à l'un, et l'interface par défaut, à l'autre. Mieux, je pense qu'il a en général collé sur le localhost les bidules qui n'ont pas besoin d'être accédés de l'extérieur, comme les Slaves, qui n'ont besoin d'être accessible quepar leur Maître (et donc on voit bien que le concepteur a pensé ses Slaves, et leur(s) Maître(s), sur le même hôte réseau

  "Slaves": {
          "Plugin":       "ClusterConfigPlugin",
          "PluginConfig": {
              "Nodes":    ["localhost:8090"]
  }

  (ahhhh et voilà, on retrouve la configuration legacy....)

Mon Hypothèse à la seule lecture du fichier de configuration

Clairement, j'ai un lien entre le Dispatcher, et Prerender :

• Le dispatcher, répartiteur des réquêtes vers le /les Prerender
• Chaque Prerender, gère manifestement un pool de PrerenderSlaves (Chaque PreRender serait le maître de son pool de PrerenderSlaves ?
• Le pool de PrerenderSlaves est configuré par le bloc JSON ["RenderPools"]
• Le bloc JSON ["CachePlugin"] est là pour configurer l'installation d'une dépendance

Remarque : mauvais design pattern, de configurer dans c fichier-là, l'installation d'une dépendance. On obtient en effet là une adhérence entre les configurations de deux choses très différentes:

• la recette d'exécution d'un logiciel, d'une part,
• et la recette de provision / installation de ce logiciel, d'autre part. On applique généralement une configuration, lors d'une installation. Mais les recette IAAC d'installation, et d'exéction, sont deux choses bien distinctes, qui doivent être versionnés de manière indépendante, pour une plus grande agilité, dans les cycles de travail Devops

Cache => :8080

[Jean-Baptiste-Lasselle]

Hop là, hop là ! => Selon :

http://sputnik-maps.github.io/gopnik/overview.html

Les 'PReRender, il ne servent pas dans le processus de run avec le client, mais pour les opérations standards d'exploitation.

Donc on abien un cluster de PreRendering , pour exécuter une tâche de type BULK BATCH, sur des données : faire le pre-rendering, c'est "remplir" le cache, ne serait-ce qu'au départ, et surement périodiquement, avec les données géographiques. Ensuite, les Renderes prennent le relai :+1:

• Le dispatcher exige les données de la requête HTTP client, il demande au cache les tuiles (tiles)
• Si pas trovuées dans le cache, alors le Dispatcher exige des Renderers qu'ils remplissent le cache avec les tuiles réclamées, et le Dispatcher négociera avec le cache jusqu'à obtenir ses tuiles (et les renvoyer au client, bien sûr). J'ai vu une notion de TIME TO LIVE, comme pour les réseaux avec le paramètre de configuration RenderTTL, dans le fichier renderer/map_data/config.json, au niveau de la configuration du service Renderer, je crois bien ... :
• Eh oui, une tuiles peut en effet expirer, il a même mieux, dans certains formats de données / protocoles réseau cartographques, en leur sein même, circule une information d'expiration : je ne'ai plsu ne tête quels standars, je retrovuerai éventuelelement pour étoffer la doc.
• Les tuiles ne peuvent être éternelles, en fait elles doivent absoluement être mortelles, avoir diffrents âge dans sa courte vie... Le paysage change, non?

Périodiquement: à des horaires décidés par une intelligence articficielle, qui analyse les données de monotoring en séries temporelles, etc... La mêem intelligence artificielle utilisera l'apprentissage autmatique de type machine learning, pour appprendre des engeulafdes qu'il prend de la part des humains)

je vais faire mon inmport de données osm2pgsql