Discussion sur l'infrastructure de Zeste de Savoir

Je ne crois pas qu'il y ait vraiment une charge associée aux statics.

Mon avis (disclaimer : il vaut ce qu'il vaut) :

• mettre les logs dans /var/log/zds : ça n'a aucun sens de les avoir ailleurs
• bouger le dossier static (pas sur du nom, je parle de celui qui contient les css et js minimisés pour la prod)
• comme le dit un de mes voisins du dessus, bouger les dossiers tutoriels/articles/media/etc ailleurs, ça simplifiera les backup (Dans l'idéal, je pense que tous les dossiers contenant des données utilisateurs devraient être à part)
• mails_beta : pas sur de ce qu'il y a dedans, mais je le deplacerais bien aussi

Donc mettre tous ces dossiers, soit dans /opt/zds-data/ soit directement dans /opt/.

La nouvelle organisation :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

zds@server01:/opt$ tree -d -L 3
.
└── zds
    ├── data
    │   ├── contents-private
    │   ├── contents-public
    │   ├── mails_beta
    │   ├── media
    │   └── static
    ├── solr-4.9.1
    │   ├── contrib
    │   ├── dist
    │   ├── docs
    │   ├── example
    │   └── licenses
    ├── zdsenv
    │   ├── bin
    │   ├── include
    │   ├── lib
    │   └── local
    └── zds-site
        ├── assets
        ├── conf
        ├── dist
        ├── doc
        ├── errors
        ├── fixtures
        ├── geodata
        ├── scripts
        ├── templates
        ├── watchdog-build
        └── zds

Avec les logs dans /var/log/zds.

Reste à faire :

• Sécuriser et monter des accès propres au serveur.
• Remettre en route l'indexation (solr tourne, mais rien n'est indexé).
• Ajouter l'envoi de mails.
• Vérifier que tout ce qui doit aller dans /opt/zds/data y est vraiment (et qu'il ne reste rien de planqué dans le dossier de l'application). - Sauvegarder le serveur (bacula).
• Mettre à jour les scripts et la doc.

Un truc encore, pour moi, tout ce qui doit être servi par nginx doit être dans un dossier à part.

Juste un dossier webroot/ avec static/ + media/ + errors/ + autre (robots.txt, vérification google webmaster et Gandi…), qu'on puisse le mettre en root dans la config nginx, et virer toute la conf spécifique à ces fichiers

Sinon pour le reste, gros +1 ; j'ajouterais aussi qu'on devrait faire la même chose à l'intérieur même de notre dépôt (genre, les fichier forbidden_email_providers.txt, quotes.txt, geodata/, et robots.txt qui sont à la racine du dépôt pour rien), mais c'est beaucoup moins urgent.

On verra si j'ai le courage de le modifier un jour.

OVH est de pire en pire, lors de l'indispo d'il y a quelques minutes, on est montés à 14 secondes (secondes !) de latence disque…

Comme la suggéré Cornichon ça serait bien d'ouvrir un ticket quand même parce que ça devient vraiment récurent.

OVH est de pire en pire, lors de l'indispo d'il y a quelques minutes, on est montés à 14 secondes > (secondes !) de latence disque…

Ah ouai, quand même, même un moine copiste va plus vite ^^. Toujours pas aussi vite que l'administration française par-contre !

La question qu'on attend tous à t-on dépassé le record des 14 secondes ? (et aussi, c'est quand qu'on passe sur Gandi ?)

et aussi, c'est quand qu'on passe sur Gandi ?

Pour cela il nous faut un admin-sys pour configurer le serveur. Notre admin-sys actuel à très très peu de temps ce qui explique que pour le moment rien n'a été fait. On a une réunion du CA ce soir et c'est le point le plus important abordé.

Sans admin-sys, pas d'installation de serveurs et donc pas de changement d'hébergeurs possibles.

C'est pas méchant loin de là, je comprend bien cela. Très loin de moi, l'idée de critiquer. Bonne chance pour la réunion de ce soir. C'était surtout un petit tacle pour OVH, car ils le méritent .

He je ne dis pas que tu critique, j'ai profité de ton message pour expliquer pourquoi c'était un peu bloqué.