DEV Community: Guillaume Sainthillier

Gérer ses miniatures avec Symfony et Glide

Guillaume Sainthillier — Sat, 13 Jun 2020 12:15:26 +0000

Aujourd'hui j'ai envie de vous parler d'un pattern récurrent dans un projet Web : la gestion des images et surtout des miniatures associées.

En 2020, le poids des images dans une page Web est toujours un facteur clé dans l'optimisation du poids des pages. Combien d'entre-nous continue encore de servir aux internautes mobiles des images de 1200px de long ?

On va donc voir comment mettre en place dans un projet Symfony 5 la librairie PHP Glide qui met à disposition une API pour gérer la manipulation d'image.

Démo

Avant de partir dans les explications, je vais déjà tenter de vous attendrir avec le type de rendu final que l'on peut obtenir avec cette librairie :

La magnifique démo de cet article : 👉 https://labs.silarhi.fr/images

Installation

Sans plus attendre on va commencer par installer tout doucement la librairie et créer un service Symfony pour gérer tout ça. Le package league/glide-symfony possède un adapter pour Symfony qui intègre la gestion des Response mais ne fournit pas de service par défaut.

composer require league/glide league/glide-symfony

Configuration

On va modifier un peu la configuration actuelle pour ajouter le service Symfony et préparer l'API.

# config/services.yaml
parameters:
    app.public_dir: '%kernel.project_dir%/public'
    app.image_cache_dir: '%kernel.project_dir%/var/storage/cache'

services:
    _defaults:
        #...
        bind:
            $secret: '%kernel.secret%'

    League\Glide\Server:
        factory: ['League\Glide\ServerFactory', create]
        arguments:
            source: '%app.public_dir%'
            cache: '%app.image_cache_dir%'

Mise en place

L'idée est ensuite de créer un Controller pour générer à la volée les miniatures (c'est notre "API"). On passera dans la requête le chemin relatif de l'image à utiliser ainsi que des pour indiquer la longueur / largeur désirée de la miniature, la couleur de fond, etc ...

Note sur la sécurité : Pour empêcher des utilisateurs malveillants de demander à générer sur votre serveur des centaines de miniatures aux dimensions non voulues (Imaginez votre serveur répondre à 10 000 requêtes de miniatures au format 50000x50000), nous allons également ajouter un hash de signature qui sera unique pour les dimensions données et que le contrôleur devra valider pour générer la miniature.

Le controller

<?php
//src/Controller/AssetsController.php

namespace App\Controller;

use League\Glide\Filesystem\FileNotFoundException;
use League\Glide\Responses\SymfonyResponseFactory;
use League\Glide\Server;
use League\Glide\Signatures\SignatureException;
use League\Glide\Signatures\SignatureFactory;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController as Controller;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Routing\Annotation\Route;

class AssetsController extends Controller
{
    /**
     * @Route("/assets/{path<(.+)>}", name="asset_url", methods={"GET"})
     */
    public function asset(string $path, string $secret, Request $request, Server $glide)
    {
        $parameters = $request->query->all();

        if (\count($parameters) > 0) {
            try {
                SignatureFactory::create($secret)->validateRequest($path, $parameters);
            } catch (SignatureException $e) {
                throw $this->createNotFoundException('', $e);
            }
        }

        $glide->setResponseFactory(new SymfonyResponseFactory($request));

        try {
            $response = $glide->getImageResponse($path, $parameters);
        } catch (\InvalidArgumentException | FileNotFoundException $e) {
            throw $this->createNotFoundException('', $e);
        }

        return $response;
    }
}

L'extension Twig

<?php
// src/Twig/AssetExtension.php

namespace App\Twig;

use League\Glide\Signatures\SignatureFactory;
use Symfony\Component\Routing\Generator\UrlGeneratorInterface;
use Twig\Extension\AbstractExtension;
use Twig\TwigFunction;

class AssetExtension extends AbstractExtension
{
    /** @var UrlGeneratorInterface */
    private $router;

    /** @var string */
    private $secret;

    public function __construct(UrlGeneratorInterface $router, string $secret)
    {
        $this->router = $router;
        $this->secret = $secret;
    }

    public function getFunctions()
    {
        return [
            new TwigFunction('app_asset', [$this, 'appAsset'], ['is_safe' => ['html']]),
        ];
    }

    public function appAsset(string $path, array $parameters = [], $referenceType = UrlGeneratorInterface::ABSOLUTE_PATH)
    {
        $parameters['fm'] = 'pjpg';

        if ('png' === substr($path, -3)) {
            $parameters['fm'] = 'png';
        }

        $parameters['s'] = SignatureFactory::create($this->secret)->generateSignature($path, $parameters);
        $parameters['path'] = ltrim($path, '/');

        return $this->router->generate('asset_url', $parameters, $referenceType);
    }
}

Avec ces 2 nouveaux fichiers, vous avez un système tout prêt de génération de miniatures sécurisé pour votre belle application !

Utilisation

Il ne vous reste plus qu'à utiliser votre fonction twig dans vos templates. La version minimale pourrait ressembler à ceci :

{# templates/images.html.twig #}
<img class="img-fluid"
     src="{{ app_asset(asset('images/mon-image.jpg'), {'w': 400, 'h': 200}) }}"
     width="400"
     height="200"
     alt="Ma super image de 400x200"
     title="Ma super image de 400x200"
/>

Ce qui produit l'URL suivante :

/assets/images/mon-image.jpg?w=400&h=200&fm=pjpg&s=d6ba0d9ef7622516b83fa3402527affe

Ce qui revient à demander au serveur :

Génère-moi la miniature du fichier /images/mon-image.jpg (si elle n'est pas déjà générée) d'une longueur de 400px (paramètre w), d'une hauteur de 200px (paramètre h), au format JPG Progressive (paramètre fm). Pour te prouver que je suis de bonne foi, je te donne le hash de vérification de ces 4 paramètres (paramètre s). Merci bisous.

Gestion des écrans retina

La gestion des écrans retina devient beaucoup plus simple vu qu'il n'y a plus qu'à passer les bons paramètres au contrôleur.

{# templates/images.html.twig #}
<img class="img-fluid"
     src="{{ app_asset(asset('images/mon-image.jpg'), {'w': 400, 'h': 200}) }}"
     srcset="{{ app_asset(asset('images/mon-image.jpg'), {'w': 400, 'h': 200, 'dpr': 2}) }}" 2x
     width="400"
     height="200"
     alt="Ma super image de 400x200"
     title="Ma super image de 400x200"
/>

J'ai juste ajouté avec le paramètre dpr (Device pixel ratio) pour générer une image 2 fois plus dense (en l'occurence 800x400).

Aller plus loin

Le bon développeur ou la bonne développeuse que vous êtes a sûrement détecté un pattern à factoriser pour améliorer la maintenabilité de tout ça. Je vous joins les 2 macros que j'utilise dans quasiment tous mes projets Symfony :

{# templates/macros.html.twig #}
{% macro image(path, width, height, attrs, params) %}
    <img src="{{ app_asset(path, params|default({})|merge({'w': width, 'h': height})) }}"
         srcset="{{ app_asset(path, params|default({})|merge({'w': width, 'h': height, 'dpr': 2})) }} 2x"
         width="{{ width }}"
         height="{{ height }}"
         loading="lazy"
        {% for name,value in attrs|default([])|filter((k, v) => k != 'class') %}{{ name }}="{{ value|e }}" {% endfor %}
    />
{% endmacro %}

{% macro fixedHeightImage(path, height, attrs) %}
    <img class="img-fluid {{ attrs.class|default(null) }}"
         src="{{ app_asset(path, {'h': height}) }}"
         srcset="{{ app_asset(path, {'h': height, 'dpr': 2}) }} 2x"
         loading="lazy"
        {% for name,value in attrs|default([]) |filter((k, v) => k != 'class') %}{{ name }}="{{ value|e }}" {% endfor %}
    />
{% endmacro %}


{# templates/images.html #}
{% import 'macros.html.twig' as macros %}

{{ macros.image(
    asset('images/mon-image.jpg'),
    300,
    300,
    {'class': 'img-fluid'},
) }}

Voilà ! Vous êtes maintenant un pro des miniatures ! N'hésitez pas à regarder le code source de la démo qui intègre Webpack en plus de tout ça.

Pour aller plus loin

Adieu jQuery ? Bootstrap 5 annonce la tendance, retour d'expérience

Guillaume Sainthillier — Thu, 16 May 2019 06:49:15 +0000

jQuery va-t-il mourir ? Le bug de l'an 2000 va-t-il se reproduire ? Toutes les réponses dans cet article.

C'est officiel, Bootstrap va se séparer de sa dépendance la plus forte : jQuery. C'est ce qu'annonce cette PR sur le Github du plus célèbre Framework CSS. A la place, pas de nouveau framework Javascript, pas de super lib next gen : du Vanilla JS, tout simplement. Cette PR montre pour moi la tendance Javascript de 2019 : jQuery a-t-il encore une raison d'exister ?

Si l'on remonte de quelques années aux temps où IE 6 était roi, jQuery avait du sens lorsque les navigateurs avaient d'énormes différences dans l'implémentation des specs. Aujourd'hui, bien qu'encore présentes, ces différences tendent à se réduire de plus en plus :

querySelector est devenu stable et consistent entre les navigateurs.
XMLHTTPRequest peut être remplacé par fetch qui est devenu standard.
Les animations peuvent être gérées en CSS3 et sont d'ailleurs plus performantes car elles utilisent le GPU du client.
Microsoft a annoncé l'arrêt de l'utilisation de son moteur de rendu en faveur de Chromium pour son navigateur Edge.
etc etc

Pour enfoncer le clou, GitHub annonce lui aussi qu'il a supprimé jQuery de son interface frontend. Alors, faut-il bannir absolument jQuery de ses nouveaux projets ?

Mon retour d'expérience

Un zeste de contexte

J'ai récemment développé une application Symfony pour un client. Fort de cette tendance, j'ai donc décidé d'utiliser du pur Javascript dans le projet et voir si j'arrivais à m'en sortir.

Pour ça, je me suis fortement inspiré de la structure frontend du site en-marche.fr qui est Open Source (pro tip : vous n'avez pas besoin d'adhérer aux idées du partie politique pour pouvoir tirer le meilleur de l'architecture du site 🤫). Je trouve d'ailleurs que Titouan Galopin a fait de l'excellent travail lorsqu'il était sur ce projet.

La stack technique

Pour ce projet, j'ai utilisé Bootstrap, axios pour les requêtes HTTP, SweetAlert2 pour les popups, Select2 pour des jolis select et pjax pour accélérer les changements de page. Le code front métier étant écrit en ES6 et transpilé avec Webpack et Babel.

À cause de certaines de ces libs, j'ai donc quand même été contraint d'inclure jQuery dans mon projet, mais j'ai décidé de restreindre son utilisation uniquement pour manipuler les plugins. Histoire de jouer le jeu pour de vrai.

Résultat

Globalement, l'absence de jQuery ne s'est pas tant fait ressentir. C'est d'ailleurs gratifiant de savoir que l'on peut développer rapidement des apps sans framework JS et leurs contraintes associées.

En utilisant jQuery, je trouve aussi qu'on se place dans une zone de confort qui nous maintient à l’écart de l’univers JS. Et ça bouge vite, très vite. De nouveaux standards apparaissent quasiment chaque année, et apportent des évolutions intéressantes et de nouvelles façons de penser et d’écrire le Javascript. Il se passe des choses et il ne faut pas rater le coche, il n'y a qu’à voir du code écrit avec React pour se rendre compte du fossé qu'il y a avec jQuery, alors que les 2 s'appuient sur le même langage.

Mais tout n'est pas rose, il y a quand même eu quelques points de frustration :

Il y a toujours beaucoup de libs qui ne marchent qu'avec jQuery (Bootstrap 4, select2, etc etc). C'est pourquoi même si je n'en voulais pas, jQuery s'est invité de force dans mon fichier package.json.
fetch n'est pas si cool que ça. J'ai fini par utiliser axios après avoir perdu pas mal de temps à tenter de cerner ses subtilités.

Et vous ? Utilisez-vous encore jQuery en 2020 dans vos nouveaux projets ? Pensez-vous que jQuery va mourir ?

PS : Le bug de l'an 2000 risque bien de se reproduire si les systèmes ne se mettent pas à jour avant le 19 Janvier 2038 à 03h14 et 08s GMT, date à laquelle toutes les architectures d'ordinateurs qui sont encore en 32 bits cesseront de gérer correctement les dates. Mais ça reste entre nous 🤫

Divisez le temps de réponse de votre site Web par 100 avec Varnish et les fragments ESI

Guillaume Sainthillier — Sat, 11 May 2019 13:21:29 +0000

On évoque souvent la mise en place du cache applicatif comme la première solution pour optimiser les temps de réponse des sites. Découvrez ici seulement la vraie solution pour réduire les temps de réponse de votre site Web que seul 1% des gens connait.

Si vous lisez encore ces lignes, c'est que j'ai bien fais mon travail de teasing. Sans plus attendre, voici la solution ultime pour réduire les temps de réponse de votre site : Ne pas appeler votre site.

Mais quelle drôle d'idée.

Démarrer un backend et retourner une réponse au client, même avec un super framework récent, ça reste long et coûteux. Bootstrapping du framework, connexion à une base de données, à un serveur Redis, vérification des droits utilisateurs, moteur de templating, etc etc. Sans trop forcer, vous pouvez vite atteindre les 200 ms pour retourner du contenu.

🤓« Alors comment faire pour réduire mes temps de réponse ? Est-ce que je dois investir, booster mon serveur de prod et doubler le montant ma facture ? »

Pas du tout ! L'idée est d'utiliser à fond le cache HTTP pour stocker le rendu HTML généré par le backend. Pour ça, on va jouer avec Varnish, un reverse proxy ultra puissant écrit en C. On parle ici de temps de réponse de l'ordre de quelques millisecondes si la page existe dans le cache.

Le principe de Varnish est plutôt simple : Le reverse proxy est en première ligne des requêtes utilisateurs. S'il possède déjà la réponse à cette requête, il la délivre tout simplement. Sinon, il forward la request au backend et stocke le résultat. C'est aussi simple que ça. On va voir comment mettre en place concrètement ce flux en place.

Le principe simple de Varnish

C'est parti

L'idée est donc de mettre Varnish en frontal des requêtes utilisateur. C'est lui qui va maintenant écouter sur le port 80 et envoyer les requêtes vers votre serveur Web qui était en frontal jusqu'ici.

La première étape est de modifier les ports d'écoute de votre backend. Par exemple pour Apache on va modifier la configuration :

Listen 80

par

Listen 8000

Gardez en tête le nouveau port d'écoute de votre serveur Web. Ensuite, on va installer Varnish. Rendez vous sur packagecloud et suivez les instructions selon votre distribution : https://packagecloud.io/varnishcache.

Un premier exemple : du contenu statique

Varnish utilise son propre langage de configuration (VCL) qu'il compile ensuite en C. C'est un poil bas niveau mais une fois bien configuré, vous allez mettre un moteur de Ferrari dans votre 2 CV.

On va commencer par un VCL minimaliste :

vcl 4.0;

backend default {
    .host = "127.0.0.1"; 
    .port = "8000"; # Le port d'écoute de votre backend (Apache, Nginx, ...)
}

# Appelé à la fin de chaque réponse (en cache ou non)
sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }

    set resp.http.X-Cache-Hits = obj.hits;

    return (deliver);
}

Prenez le temps de vous familiariser avec la syntaxe et la configuration. Ici, on a indiqué à Varnish qu'il existe un backend (default) accessible à l'adresse 127.0.0.1 sur le port 8000 (souvenez-vous, c'est le nouveau port d'écoute de votre serveur Web). On a aussi configuré une entête de réponse que l'on a nommé X-Cache pour savoir si la réponse a été récupérée du cache ou non. Vérifions le résultat en appelant la page d'accueil de notre site pour la première fois :

Première requête : Varnish n'a rien en cache

Étant donné que c'est la première fois que l'on accède à la ressource, Varnish ne possède pas la réponse dans son cache, ce qui est logique. Il appelle donc le backend normalement et stocke le résultat pour une durée de 120 secondes (c'est la configuration par défaut de Varnish, vous pouvez bien sur le changer selon vos besoins). Si on actualise la page, on constate que Varnish réagit différemment :

Deuxième requête : Varnish retourne directement la réponse

Parfait ! Varnish a directement retourné le résultat qu'il avait stocké lors de la première requête. Le backend n'a purement pas été sollicité, vous n'aurez aucune trace d'accès dans les logs de votre serveur Web. Ça commence à ressembler à quelque chose.

🤓 « Mais si mon contenu varie en fonction de l'utilisateur ... Je ne veux pas retourner le même contenu pour tout le monde. Comment faire ? »

C'est là qu'interviennent les fragments ESI.

Mettre en cache des fragments de page avec ESI

Il est possible de mettre en cache une partie de la page grâce aux blocs de cache ESI (Edge Side Includes). Cette specification a été écrite par Akamai il y a une dizaine d'années dans le but de mettre en place des stratégies de cache différentes par "bloc". Par exemple : ma page possède un menu type navbar propre à l'utilisateur. Le reste de ma page est identique pour tout le monde. Je peux donc mettre en place un bloc qui va contenir le menu et mettre en cache tout le reste.

Assez de théorie, voyons comment ça se traduit dans une app :

<!DOCTYPE html>
<html>
    <body>
        <h1>Ma super app</h1>

        <!-- Le bloc du ESI est défini là -->
        <esi:include src="/mon-menu-prive.php"/>
    </body>
</html>

C'est aussi simple que ça ! On peut le voir un peu comme un appel Ajax qui serait fait pour chaque bloc, sauf que c'est le reverse proxy (Varnish) qui fait la requête. La différence est que la sous-requête est effectuée par le serveur et non par le client.

Un cas d'étude concret

On va mettre en plage une page concrète qui sera composée de plusieurs blocs. Certains blocs vont varier en fonction de l'utilisateur (ex: un menu), d'autres seront publics. La durée de mise en cache des blocs va aussi être variable.

Le cas d'étude : démo disponible

Admirez ces belles bordures

Entrons dans le vif du sujet, voici le code :

<?php // index.php
    header('Surrogate-Control: abc=ESI/1.0');
    header("X-Reverse-Proxy-TTL: 10");
?>
<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
    <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous">
    <title>Ma super page</title>
</head>
<body class="public cached p-2">
    <esi:include src="/menu.php"/>
    <div class="container">
        <esi:include src="/time.php"/>
        <div class="row">
            <div class="col-md-8 col-lg-9">
                <h1>Page de contenu public</h1>
                <p class="lead">Mise en cache le <span class="badge badge-secondary"><?= date('d/m/Y H:i:s') ?></span> (10s)</p>
            </div>
            <div class="col-md-4 col-lg-3">
                <esi:include src="/user.php"/>
                <esi:include src="/sidebar.php"/>
            </div>
        </div>
    </div>
</body>
</html>

Ne vous focalisez pas encore trop sur le détail de ce code, l'idée est juste d'imaginer la mise en place de vos propres blocs dans votre application.

Outre ce design de qualité, vous avez sûrement identifié les 4 blocs. Le menu du haut (menu.php), l'heure du serveur avec la légende (time.php), l'heure de la dernière connexion (user.php) et les widgets (sidebar.php). 4 blocs pour 4 politiques de mise en cache différentes. C'est le mélange de la configuration dans Varnish et l'envoi d'entêtes HTTP de réponses par le backend qui vont permettre de mettre en place nos 4 politiques.

Configuration dans Varnish

# /etc/varnish/default.vcl
vcl 4.0;

import std;
import directors;

backend default {
    .host = "127.0.0.1";
    .port = "8000"; # Le port d'écoute de votre serveur Apache / Nginx
}

# Appelé au début de chaque requête
sub vcl_recv {
    # Pas de mise en cache pour les méthodes type POST / DELETE
    if (req.method != "GET" && req.method != "HEAD") {
        return (pass);
    }

    # On supprime les cookies sur les pages publiques (cf vcl_hash)
    if(! req.url ~ "^/(login|logout|menu|user)\.php") {
        unset req.http.Cookie;
    }

    # On supprime tous les autres cookies que PHPSESSID pour les pages privées
    if (req.http.Cookie) {
        set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");
        set req.http.Cookie = regsuball(req.http.Cookie, ";(PHPSESSID)=", "; \1=");
        set req.http.Cookie = regsuball(req.http.Cookie, ";[^][^;]*", "");
        set req.http.Cookie = regsuball(req.http.Cookie, "^[;]+|[;]+$", "");
        set req.http.Cookie = regsuball(req.http.Cookie, "^;\s*", "");

        if (req.http.Cookie ~ "^\s*$") {
            unset req.http.Cookie;
        }
    }

    return (hash);
}

# Appelé pour calculer un hash de la requête
sub vcl_hash {
    hash_data(req.url);

    if (req.http.host) {
        hash_data(req.http.host);
    } else {
        hash_data(server.ip);
    }

    if (req.http.Cookie) {
        hash_data(req.http.Cookie);
    }
}

# Appelé si le hash a été trouvé (= page en cache)
sub vcl_hit {
    if (obj.ttl >= 0s) {
        return (deliver);
    }

    return (miss);
}

# Appelé au retour de la réponse par le backend
sub vcl_backend_response {
    # L'entête est envoyée par index.php
    if (beresp.http.Surrogate-Control ~ "ESI/1.0") {
        unset beresp.http.Surrogate-Control;
        set beresp.do_esi = true;
    }

    # Notre fameuse entête custom
    if (beresp.http.X-Reverse-Proxy-TTL) {
        set beresp.ttl = std.duration(beresp.http.X-Reverse-Proxy-TTL + "s", 0s);
        unset beresp.http.X-Reverse-Proxy-TTL;
    }

    return (deliver);
}

# Appelé à la fin de chaque réponse (en cache ou non)
sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }

    set resp.http.X-Cache-Hits = obj.hits;

    return (deliver);
}

Il y a plusieurs concepts clés à comprendre dans cette configuration. L'idée de fond est de générer un hash unique pour chaque requête / sous - requête. Ce hash doit dépendre du contexte utilisateur pour les blocs privés, en revanche il n'est pas nécéssaire pour les blocs publics. En PHP, l'utilisateur est lié à la session du serveur via le cookie PHPSESSID. C'est cette valeur de cookie que l'on doit conserver pour générer ce fameux hash unique dans les pages qui nous intéresse. Pour les autres pages, on peut se permettre de supprimer ce cookie pour maximiser les chances de délivrer un contenu mis en cache par un autre utilisateur.

On supprime également les cookies non utiles au backend (du type Google Analytics etc) qui vont faire baisser le taux de HIT pour rien. Adaptez bien sûr la fonction vcl_recv en fonction de vos besoins.

L'illustration ci-dessous résume bien les différentes étapes pendant lesquelles nous devons agir :

Crédits : Varnish Basics

sidebar.php

<?php //sidebar.php
    header("X-Reverse-Proxy-TTL: 20");
?>
<div class="public cached p-2">
    <h1>Widgets publics</h1>
    <p class="lead">
        Mise en cache le <span class="badge badge-secondary"><?= date('d/m/Y H:i:s') ?></span> (20s)
    </p>
</div>

Politique de mise en cache du bloc : Contenu publique mis en cache pendant 20 secondes.

C'est l'entête X-Reverse-Proxy-TTL qui va donner la durée de mise en cache par Varnish. Cette entête n'est pas standard. On aurait pu jouer sur l'entête standard Cache-Control, mais elle possède un inconvénient majeur : On ne contrôle pas la propagation du cache avec la directive Cache-Control: public, smax-age=20. Eh oui, il peut y avoir d'autres serveurs mandataires entre le client et votre serveur qui peuvent eux-aussi mettre en cache le contenu HTML avec cette directive. Et si vous mettez des grandes valeurs de TTL dans votre politique de Cache-Control, adieu la maîtrise de vos mises à jour. Mieux vaut rester maître de la diffusion de vos contenus. En revanche, pour vos contenus type Images/CSS/JS, faites vous plaisir et laissez le cache-control public avec un grand TTL si vous maîtrisez le cache busting.

menu.php

<?php //menu.php
    session_start();
    header("X-Reverse-Proxy-TTL: 60");
?>
<nav class="navbar navbar-expand-lg navbar-light bg-light private cached">
    <div class="container">
        <div class="collapse navbar-collapse" id="navbarSupportedContent">
            <ul class="navbar-nav mr-auto">
                <?php if (isset($_SESSION['logged'])): ?>
                    <li class="navbar-text">
                        <span class="badge badge-success">Connecté</span>
                    </li>
                    <li class="nav-item">
                        <a class="nav-link" href="logout.php">Déconnexion</a>
                    </li>
                <?php else: ?>
                    <li class="navbar-text">
                        <span class="badge badge-danger">Anonyme</span>
                    </li>
                    <li class="nav-item">
                        <a class="nav-link" href="login.php">Connexion</a>
                    </li>
                <?php endif; ?>
            </ul>
            <span class="navbar-text">
                Mise en cache le <span class="badge badge-secondary"><?= date('d/m/Y H:i:s') ?></span> (60s)
            </span>
        </div>
    </div>
</nav>

Politique de mise en cache du bloc : Contenu privé mis en cache pendant 60 secondes.

La mise en cache du contenu en fonction de l'utilisateur sera gérée dans Varnish directement. Le truc étant d'inclure le PHPSESSID de l'utilisateur dans le calcul du "hash" d'une requête pour ce bloc-ci, ce que nous avons fait dans la méthode vcl_recv.

time.php

<?php //time.php ?>
<div class="text-center p-2 public">
    <p class="lead text-center">Heure serveur : <span class="badge badge-secondary"><?= date('d/m/Y H:i:s') ?></span> (pas de cache)</p>
    <div class="row">
        <div class="col-3"><span class="public p-1">Public</span></div>
        <div class="col-3"><span class="public cached p-1">Public + cache</span></div>
        <div class="col-3"><span class="private p-1">Privé</span></div>
        <div class="col-3"><span class="private cached p-1">Privé + cache</span></div>
    </div>
</div>

Politique de mise en cache du bloc : Contenu public sans mise en cache particulière.

Le backend est appelé systématiquement pour ce bloc (j'ai changé la configuration de base de Varnish pour mettre le TTL par défaut à 0s).

user.php

<?php //user.php
    session_start();
?>
<br />
<div class="private p-2">
    <?php if($_SESSION['logged'] ?? false): ?>
        Dernière connexion il y a <?= time() - $_SESSION['last_login'] ?>s
    <?php else: ?>
        Pas de dernière connexion
    <?php endif; ?>
</div>

Politique de mise en cache du bloc : Contenu privé sans mise en cache particulière.

Le backend est appelé systématiquement pour ce bloc.

login.php

<?php // login.php

session_start();
$_SESSION['logged'] = true;
$_SESSION['last_login'] = time();

header('Location: /', true, 301);

Rien de particulier ici, on est sur un système de login maison très classique.

logout.php

<?php // logout.php

if ( isset( $_COOKIE[session_name()] ) ) {
    setcookie( session_name(), "deleted", time()-3600, "/");
}

session_start();
session_destroy();

header('Location: /', true, 301);

Il y a une particularité importante ici : On détruit entièrement le cookie de la session PHP pour que Varnish ne nous retourne pas l'ancien contenu utilisateur mis en cache qui n'a plus de raison d'exister.

Le mot de la fin

On a vu comment mettre en place plusieurs stratégies de cache différentes en fonction des types de blocs de vos pages. N'hésitez pas à vous approprier le concept de la mise en cache HTTP avec les fragments ESI et à l'utiliser massivement pour réduire drastiquement le temps de réponse de vos belles pages Web.

Pour aller plus loin

La démo de l'exemple utilisé

Le code source de la démo pour bien comprendre (utilise Docker)

La documentation officielle de Varnish

Une image Docker PHP + Apache sur mesure pour la production

Guillaume Sainthillier — Mon, 25 Feb 2019 14:53:00 +0000

Créez l'image Docker PHP + Apache qui vous ressemble. Elle sera donc parfaite puisque vous êtes un lecteur de ce blog et que vous êtes abonnés aux nouveaux articles 💖.

C'est quoi une image Docker parfaite ?

C'est avant tout une image établie selon votre besoin et votre expérience. Vous avez identifié des patterns communs de configuration qui se répètent au fil de vos développements. Et comme vous êtes quelqu'un de bien, vous voulez donc les regrouper dans une couche commune à toutes vos apps pour en faciliter la maintenance.

À partir de ma propre expérience et du type d'applications que je développe la plupart du temps, une image PHP Apache parfaite selon moi c'est :

Composer installé par défaut (qui n'utilise pas de gestionnaire de dépendances de nos jours ?).
PHP et Apache configurés pour la production.
Des modules PHP récurrents activés par défaut.
De jolies page d'erreurs type 404 un peu plus silencieuses que celles par défaut d'Apache.
Idéalement des variantes déjà prêtes pour des applications qui tournent avec Symfony.

Créer son image parfaite

En premier lieu on va partir de l'image officielle de php, parce qu'on veut gagner du temps et ne pas réinventer la roue. Vous savez quoi ? L'image est même fournie avec un serveur Apache intégré. TOP.

🤓 « Pourquoi utiliser Apache plutôt que nginx ? »

Parce que cet article n'est pas neutre et qu'il faut trancher. Personnellement, je trouve la différence de performances négligeables entre les deux et Apache convient parfaitement pour la plupart des projets. C'est également plus serein pour les mises à jour de sécurité qui seront directement effectuées par la team PHP Docker. Il m'arrive par contre pour des projets un peu plus importants d'utiliser nginx. Encore une fois, cela reste vraiment une question de besoin, d'expérience et de goûts.

On va donc commencer notre Dockerfile avec la ligne suivante :

# Dockerfile
FROM php:7.4-apache

On build et on run tout ça pour vérifier que tout va bien :

docker build -t super/hero .
docker run -it -p 8080:80 super/hero

En vous rendant sur http://127.0.0.1:8080 vous devez tomber sur une belle page 403. Ça veut bien dire que tout fonctionne, il n'y a pas encore vos sources donc Apache vous répond gentiement !

Composer par défaut

Rien de plus simple, on installe la dernière version de composer et on rend la commande accessible partout dans le conteneur.

# Dockerfile
ENV COMPOSER_ALLOW_SUPERUSER=1
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
RUN composer --version

Configuration d'Apache

Par défaut, l'image officielle est configurée pour avoir la racine du serveur Web dans /var/www/html. Trop long ! On va ignorer tout ça et accueillir notre futur code source dans un dossier /app directement à la racine du conteneur.

# conf/vhost.conf
<VirtualHost *:80>
    ServerAdmin contact@monsupersite.fr

    DocumentRoot /app

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# conf/apache.conf
<Directory /app/>
    Options -Indexes +FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

ServerTokens Prod
ServerSignature Off

# Dockerfile
# ...
ADD conf/vhost.conf /etc/apache2/sites-available/000-default.conf
ADD conf/apache.conf /etc/apache2/conf-available/z-app.conf
RUN a2enconf z-app

On a changé ici la configuration du vhost de base d'Apache (000-default.conf), qui délivre maintenant le contenu du dossier /app. On configure aussi le dossier /app pour ne pas autoriser Apache de lister les fichiers d'un répertoire avec Options -Indexes.

Pour ma part, je n'aime pas configurer mes sites avec un .htaccess (pour des raisons de performance). C'est pourquoi j'ai placé la directive AllowOverride None. Comme l'image est destinée pour le staging / production, j'ai aussi supprimé les infos sur l'infrastructure utilisée avec les directives ServerTokens Prod et ServerSignature Off.

J'ai volontairement nommé la configuration z-app pour être sûr qu'elle soit chargée en dernier et qu'aucun autre module ne vienne surcharger les instructions.

Configuration de PHP

On va configurer PHP selon les besoins récurrents de nos futures images. Ne mettez pas de valeurs trop importantes ici, si un de vos conteneurs en particulier a besoin d'une configuration plus véloce, vous pourrez override cette configuration de base dans le Dockerfile propre à cette app.

; conf/php.ini
date.timezone = Europe/Paris

opcache.enable = 1
opcache.enable_cli = 1
opcache.memory_consumption = 128
opcache.revalidate_freq = 0
apc.enable_cli = On

upload_max_filesize = 16M
post_max_size = 16M

realpath_cache_size = 4096k
realpath_cache_ttl = 7200

display_errors = Off
display_startup_errors = Off

# Dockerfile
# ...
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    libicu-dev
RUN docker-php-ext-install -j$(nproc) opcache pdo_mysql
ADD conf/php.ini /usr/local/etc/php/conf.d/app.ini

Adaptez les modules par défaut qui vous semblent essentiels. Pour moi, la quasi totalité de mes projets utilisent PDO et MySQL. OPCache est bien sûr par défaut également.

Des jolies pages d'erreur par défaut

Qui ne s'est jamais retrouvé devant la page 404 par défaut d'Apache ? C'est l'assurance de perdre la crédibilité du ninja DevOp big data pro de baby-foot et autres buzzwords que vous êtes auprès de votre client. On va donc modifier la conf existante pour ajouter la gestion des pages d'erreurs :

# conf/apache.conf
# ...
<Directory /errors/>
    Options -Indexes
    AllowOverride None
    Require all granted
</Directory>

Alias /_errors/ /errors/
ErrorDocument 404 /_errors/404.html
ErrorDocument 403 /_errors/403.html
ErrorDocument 500 /_errors/500.html

# Dockerfile
# ...
ADD errors /errors

Pour ne pas causer de conflits avec les futures apps, j'ai placé le contenu des pages d'erreur dans un dossier à part (/errors à la racine du conteneur) et j'isole les requêtes HTTP spécifiques à ces pages via le chemin /_errors.

Ça donne quoi au final ?

Le Dockerfile a été optimisé pour réduire la taille des couches.

# Dockerfile
FROM php:7.2-apache

ENV COMPOSER_ALLOW_SUPERUSER=1

EXPOSE 80
WORKDIR /app

RUN apt-get update -qy && \
    apt-get install -y \
    git \
    libicu-dev \
    unzip \
    zip && \
    curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer && \
    apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

# PHP Extensions
RUN docker-php-ext-install -j$(nproc) opcache pdo_mysql
ADD conf/php.ini /usr/local/etc/php/conf.d/app.ini

# Apache
ADD errors /errors
RUN a2enmod rewrite remoteip
ADD conf/vhost.conf /etc/apache2/sites-available/000-default.conf
ADD conf/apache.conf /etc/apache2/conf-available/z-app.conf
RUN a2enconf z-app
ADD index.php /app/index.php

# conf/apache.conf
<Directory /app/>
    Options -Indexes +FollowSymLinks
    AllowOverride None
    Require all granted

    SetEnvIf X_FORWARDED_PROTO https HTTPS=on
</Directory>

ServerTokens Prod
ServerSignature Off

<Directory /errors/>
    Options -Indexes
    AllowOverride None
    Require all granted
</Directory>

Alias /_errors/ /errors/
ErrorDocument 404 /_errors/404.html
ErrorDocument 403 /_errors/403.html
ErrorDocument 500 /_errors/500.html

# conf/vhost.conf
<VirtualHost *:80>
    ServerAdmin guillaume@silarhi.fr

    DocumentRoot /app

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

; conf/php.ini
date.timezone = Europe/Paris

opcache.enable = 1
opcache.enable_cli = 1
opcache.memory_consumption = 128
opcache.revalidate_freq = 0
apc.enable_cli = On

upload_max_filesize = 16M
post_max_size = 16M

realpath_cache_size=4096k
realpath_cache_ttl=7200

display_errors = Off
display_startup_errors = Off

Curieux ? J'ai mis en place rien que pour vous :