RETOUR SUR LE FORUM PHP 2014 organisé par l’AFUP

J’étais présent au Forum PHP 2014 organisé par l’AFUP. Toutes les vidéos de l’événement sur leur chaine YouTube Voici un retour sur deux des conférences.

Vers des applications “12 factor” avec Symfony et Docker

Cette session avait pour objectif de nous présenter la méthodologie du “twelve-factor app”, à travers des exemples concrets pour PHP à l’aide de Symfony et Docker. “The twelve-factor app” est une suite de recommandations, indépendante d’un langage de programmation particulier et pouvant s’appliquer à toutes sortes de logiciels développés en tant que service. Sans revenir sur l’ensemble de la présentation, voici une synthèse des 12 facteurs :

  • Codebase : une app = un repo (ou équivalent) servant de source à tous les déploiements (dev / preprod / recette / prod etc.). Exemples : git, mercurial etc.
  • Dependencies : déclaration explicite et complète de l’arbre de dépendances, utilisé uniformément pour tous les environnements. Exemples : composer, npm etc.
  • Config : séparation stricte config/code (Resources, Backing services, Credentials, Hostname etc.). Exemples : parameters.yml pour Symfony 2 ou utilisation de variables d’environnement avec Docker notamment. Utilisation de fig pour l’orchestration des containers docker.
  • Backing Services : tous les services utilisés par l’application sont accessibles par le réseau. Il n’y a pas de distinction entre les ressources locales et distantes car toutes sont accessibles via URL et/ou Credentials. Exemples : MySQL, RabbitMQ, Postfix, Redis, S3 etc.
  • Build, release, run : séparation stricte entre
    • “build stage” : téléchargement d’une version du code et des dépendances. Exemples : “docker build”
    • “release stage“ : utilise le “build” et le combine avec la configuration du déploiement (une version sur un environnement). Exemple : “docker push”, utilisation de capistrano…
    • “run stage” : lancement de la “release” sur l’environnement cible. Exemple “docker run” ou “fig run”
  • Processes : chaque composant de l’application est ‘sans état’ et ne doit pas partager directement des données. Tout doit être partagé en “backing service”.
  • Port binding : les services doivent être disponibles en mettant à disposition un port d’accès, directement accessible. Cela permet une utilisation aisée en environnement de dev mais également de réutiliser les services.
  • Concurrency : une application respectant les “12 factor” est facilement scalable, quel que soit son type (web, worker, etc.) car elle repose sur des composants systèmes pour son pilotage.
  • Disposability : robustesse par le lancement et l’arrêt rapide des services, pour rendre chacune de ses services scalables.
  • Dev/Prod parity : homogénéité des environnements dev/prod et gain de temps pour la prise en main d’un projet. (mais le développeur n’aura pas une vision précise de la configuration… boite noire ?)
  • Logs : traitement des logs en tant que flux, utilisés par des services. Exemples : ELK, StatsD/Grafana etc.
  • Admin process : Exécuter les tâches de maintenance sur les mêmes environnements/containers. Exemples : docker exec

slides Personnellement, j’ai trouvé cette conférence vraiment riche et instructive. Peut-être un peu plus d’exemples de configuration fig/docker aurait pu illustrer d’avantage.

PHP dans les distributions RPM

Slides Cette session avait comme objectif de faire un état de PHP dans les distributions RPM RHEL/Centos/Fedora. RHEL / Centos :

  • Objectif de stabilité à 10 ans
  • Stabilité binaire et de configuration sur la durée de vie de la distribution
  • RHEL : version payante avec support (contacts avec les ingénieurs RedHat, ressources en ligne, cycles de mises à jour garantis etc.).
  • Centos : même code que RHEL (juste recompilé) mais uniquement un support communautaire (comme fedora, ubuntu, suse…).
  • RHEL 5 : PHP 5.1 / RHEL 6 : PHP 5.3 / RHEL 7 : PHP 5.4
  • Application des patchs de sécurités sur les versions anciennes de PHP pendant 10 ans.
  • Possibilité d’utiliser des repos tiers pour choisir une version plus récente spécifique (comme ceux de Remi Collet) – mais pas de support officiel.
  • Distributions plutôt destinées à des applicatifs maintenus sur le long terme.

Fedora 21+ :

  • 3 sous distributions : Workstation / Server / Cloud
  • Dernière version de PHP (PHP5.5 pour f20 et PHP5.6 pour f21)
  • Intégration continue de PHP dans les cycles de Fédora. Permet d’éviter les régressions.

A venir : Software Collections (scl) permet d’avoir TOUTES les versions de PHP souhaitées simultanément sur la même installation de Fedora. Vraiment prometteur ! Exemple d’utilisation des SCL en cli :

scl enable php56 -f myscript56.php
scl enable php56 bash
scl enable php53 -f myscript53only.php
scl enable php53 bash

Dans une config apache :

<VirtualHost *:80>
    ServerName php56scl
    
    # Redirect to FPM server in php56 SCL
    <FilesMatch \.php$>
    SetHandler "proxy:fcgi://127.0.0.1:9006"
    </FilesMatch>
</VirtualHost>

Aucun commentaire pour RETOUR SUR LE FORUM PHP 2014 organisé par l’AFUP