tlr-ansible — IaC déploiements Telaria

tlr-ansible est l'Infrastructure as Code de l'écosystème Telaria. Il automatise et standardise tous les déploiements Symfony : vhosts Apache, workers systemd, configurations PHP-FPM, gestion des certificats, variables d'environnement. Aucun vhost n'existe en production sans passer par Ansible.

Rôle dans l'écosystème

tlr-ansible est le seul chemin vers la production. Tout déploiement d'une app Telaria (telaria.fr, mathieuadrien.fr, adoption-app…) passe par ses playbooks. Cette contrainte garantit :

• Reproductibilité : un vhost créé en staging est identique en prod.
• Traçabilité : chaque changement d'infrastructure est versionné dans Git.
• Sécurité : les secrets (clés DKIM, DSN mail, API keys) sont gérés via group_vars chiffrés, jamais codés en dur.

Architecture

Inventaires

inventory/
├── development/   # WSL2 local — tests playbooks
├── dev/           # poseidon (Ubuntu 26.04 LTS, réseau local LAN)
└── production/    # VPS OVH (Ubuntu 26.04 LTS)

Chaque inventaire a ses group_vars/ propres — variables d'environnement, chemins, credentials spécifiques à l'env.

Rôles principaux

Pratiques clés

Vhost Symfony — pattern canonique

Tout vhost Symfony de l'écosystème Telaria suit ce pattern :

<VirtualHost *:443>
    DocumentRoot /var/www/{app}/public

    <Directory /var/www/{app}/public>
        FallbackResource /index.php
        <FilesMatch \.php$>
            SetHandler "proxy:unix:/run/php/php8.5-fpm-{app}.sock|fcgi://localhost"
        </FilesMatch>
    </Directory>

    # Redirect HTTPS, SSL, headers sécurité…
</VirtualHost>

FallbackResource /index.php est la clé du routing Symfony — sans lui, toutes les routes hors fichiers statiques retournent 404.

asset-map:compile — toujours en www-data

sudo -u www-data php bin/console asset-map:compile --env=prod

Cette commande vide public/assets/ avant d'écrire. Lancée en mauvais utilisateur → Permission denied → dossier vide en prod. Toujours www-data, jamais ubuntu.

staging obligatoire avant prod

staging (telaria-dev/adoption-dev, VPS OVH) est l'environnement d'intégration. Tout déploiement est validé en staging en conditions réelles (navigateur externe, pas curl en loopback) avant de passer en production. dev (poseidon, LAN) sert au développement et aux premiers tests fonctionnels.

Premier déploiement — initial_deploy

Pour une nouvelle app, le playbook initial_deploy gère la séquence complète : clone, dépendances, BDD (création + migrations), vhost, SSL, workers. Les déploiements suivants utilisent le playbook de mise à jour (deploy).

Stack

Voir aussi

• Déploiement
• Stack production
• Email DKIM
• tlr-symfony — bundle socle consommé par les apps déployées