Retour d'expérience - déploiement automatique de sites web #nowwwel

Aujourd'hui un article un peu différent de ce que vous avez l'habitude de voir sur ce blog. Depuis le 1er décembre des auteurs français se relaient autour du hashtag #nowwwel à l'initiative de HTeuMeuLeu pour offrir chaque jour un nouvel article sur la conception web ; et je vous propose donc aujourd'hui mon article.

Je vais vous parler aujourd'hui de déploiement automatisé. Ou, pour être précis, je vais vous faire un retour d'expérience sur la manière dont je suis passé en plusieurs années de la copie par FTP au déploiement par TFS Release Management.

Les fichiers HTML et le FTP

J'étais au lycée quand j'ai fait ma première page perso. J'avais trouvé un logiciel sur le CD de Wanadoo qui permettait de faire son propre site web, et j'ai donc décidé de me lancer. Claris Home Page était un éditeur WYSIWYG, et j'ai découvert le HTML en regardant le code qu'il générait. Je n'ai su que beaucoup plus tard que ce n'était pas la meilleure manière d'apprendre, mais ça fonctionnait, et c'est tout ce qui m'importait.

Pour déployer, c'était très simple : on trouve un hébergeur gratuit, on crée un compte, et on envoie tous les fichiers par FTP. C'était du contenu pûrement statique, donc pas de question à se poser, ça ne pouvait pas ne pas marcher. Il fallait juste s'assurer que la page d'accueil s'appelle index.html.

Quelques temps plus tard, je me suis mis au php, pour développer un site web avec un ami. Ça fonctionnait toujours pareil : on se connecte au ftp et on copie les fichiers. Et vu qu'on était 2, le ftp servait aussi à partager le code entre nous...

Avantages : c'est facile à utiliser

Inconvénients : à l'époque j'en voyais aucun :)

Découverte du monde professionnel et des sites compilés

En 2006 j'ai rejoins la société Bewise en tant que stagiaire, où j'ai énormément appris. C'est là que j'ai débuté avec les technologies de Microsoft, j'ai découvert que TFS permettait de gérer les codes sources très efficacement (avec le recul, j'ai du mal à comprendre comment j'ai pu faire 5 ans de fac en gardant mes codes sources sur clé usb), et j'ai surtout découvert ASP.NET.

La grosse différence avec ce dont j'avais l'habitude, c'est que cette fois le code est compilé ; pas question donc de se contenter d'envoyer les fichiers par ftp.
Je travaillais sur un projet pour Airbus (c'est le passage obligé pour un Toulousain), et pas question de déployer directement sur le serveur, ils ont des équipes dédiées pour ça. Nous leur fournissions un programme d'installation (InstallShield, le même que lorsque vous installez un jeu sur votre PC) qui installait le site et configurait IIS correctement.

Avantages : Le process à suivre limitait le risque d'erreur

Inconvénients : On perdait beaucoup de temps à chaque livraison

Un peu de simplicité avec WebDeploy

L'exemple précédent est particulier, en général pour déployer un site ASP.NET on préfèrera passer par l'outil de déploiement intégré à Visual Studio. Cet outil va compiler le site et nous fournir la version prête à déployer. Il propose aussi de déployer directement le site sur un serveur IIS distant en utilisant le protocole Web Deploy.

Web Deploy

Ici le fonctionnement est très simple, on rentre l'adresse du serveur, le nom du site dans IIS, le login et mot de passe, et c'est parti. Le protocole est basé sur HTTPS, donc le transfert sera plus sécurisé que par FTP.

Avantages : Très simple et rapide, sécurisé

Inconvénients : Il ne faut pas oublier de récupérer le code des collègues avant de déployer

Déploiement automatique par un serveur de compilation

Début 2015 j'ai rejoins ma société actuelle, et je découvrais de nouvelles conditions de travail. Au lieu de développer et livrer des projets à des clients, j'avais maintenant la charge de développer et maintenir des applications web sur le long terme.
J'avais entendu parler des vertus de la compilation automatique et de l'intégration continue –notamment grâce à mon ami Patrice– mais je n'avais jamais réellement pratiqué.

Honteux de mon ignorance à ce sujet, je me suis empressé d'apprendre à configurer un serveur de build, avant que mes nouveaux collègues ne s'aperçoivent de mon incompétence.
J'ai donc commencé par mettre en place des compilations automatiques, avant d'enchainer par le déploiement. J'étais tellement fier de moi que j'en ai fait un article sur ce blog.

Il existe de nombreux outils d'intégration continue (Jenkins, TeamCity pour les plus connus), j'ai choisi TFS pour une raison très simple (et certainement très mauvaise) : on utilisait déjà TFS, et c'était intégré. Mais ça fonctionnait, et ça a très bien évolué par la suite, je ne regrette aujourd'hui absolument pas ce choix.

Enfin, pour être franc, à l'époque j'ai regretté de l'avoir fait un poil trop tôt :)

Avantages : Le déploiement est entièrement automatisé, on ne risque pas de se louper. On peut bloquer le déploiement si les tests unitaires ne passent pas. On peut se moquer des collègues qui font planter la compilation.

Inconvénients : La gestion des définitions de build demande un travail supplémentaire. Les collègues se moquent de moi quand je fais planter la compilation.

Des scénarios plus poussés avec Release Management

Dans la continuité de la section précédente, j'ai commencé à utiliser un nouvel outil : Release Management.
Maintenant, au lieu d'avoir une compilation qui déploie, on a 2 outils séparés pour la compilation et le déploiement. Cela permet notamment de gérer plus facilement les différent environnements : on ne compile qu'une fois, et on déploie sur les différents serveurs sans problème.

J'en ai aussi profité pour ajouter la base de données de mes applis à mon process de déploiement. L'image de la base de données est dans mon contrôleur de source, au même titre que le code, et peut être déployée manuellement sur les postes des développeurs, ou automatiquement sur les serveurs de test et de production lors du déploiement de l'application.

Release Management

Avantages : Comme le paragraphe d'avant, mais en mieux.

Inconvénients : C'est toujours du travail. Mais moins pénible parce que je commence à maitriser l'outil

Et après ?

L'idéal serait de stabiliser une technique de déploiement, et arrêter de changer tous les 3 mois. Mais j'ai encore des améliorations à faire ; et plus j'utilise l'outil plus j'ai envie d'aller encore plus loin.
Premier possibilité : séparer les branches de dev et de déploiement pour pouvoir lancer la publication juste en archivant sur la bonne branche, et ne plus passer par l'interface web. Mais il va falloir que l'équipe prenne l'habitude d'utiliser les branches (en n'oubliant pas qu'on utilise TFS, qui malgré ses qualités a une gestion des branches moins pratique que Git).
Autre possibilité, soyons fous, un déploiement auto de la branche dev tous les soirs. Mais là attention, ça va demander beaucoup de discipline de la part des développeurs, je ne suis pas sûr qu'on soit encore prêts.

Je n'ai pas de section commentaire sur mon blog, mais vous pouvez réagir sur twitter ; merci pour votre attention, et joyeux #nowwwel à tous !

C'est tout pour moi, merci !

Article invité - Ludovic Cornac : Comment nous sécurisons nos postes utilisateurs

Aujourd'hui je laisse mon blog à mon collègue Ludovic Cornac, qui s'occupe de l'administration des serveurs et des postes utilisateurs dans la société Sothis


En tant que responsable du support informatique, et de l'installation des postes utilisateurs dans ma société, je dois faire en sorte que mes utilisateurs travaillent le plus efficacement possible, dans un contexte sécurisé.

Pour simplifier le déploiement et la maintenance des postes, nous avons mis en place un système de bureau virtuel (ou Desktop as a service). Nous sommes dans le cas d’un serveur hébergé Windows 2012R2 ou les utilisateurs s’y connectent en TSE.

Leurs boites mails ainsi que tous les logiciels de gestions leurs sont accessible sur ce même serveur. Celui-ci est protégé avec un Anti-virus System Center 2012 Endpoint Protection (antivirus de Microsoft).
Mais malgré cela nous ne sommes pas passé au travers de "ransomware".

Nous avons eu principalement beaucoup de mails "parasite" proposant des archives avec des scripts .js ou des fichiers Word avec des macros.
Une fois ces fichiers exécutés, les dossiers ou l'utilisateur possède des droits d’écriture sur le serveur sont chiffrés et certains ransomwares demandent des droits d’administrateur pour attaquer le reste du système notamment des répertoires ou l’user classique n’a pas accès le lecteur C: par exemple.

Une rançon est demandée en échange pour déchiffrer ces fichiers, sans aucune garantie. Dans le cadre professionnel c’est très ennuyeux c’est souvent plusieurs milliers de fichiers de données qui sont cryptés et qui rendent les documents illisibles ou les logiciels de gestions tout simplement inutilisable. C'est pourquoi nous avons du agir contre ces menaces.

Paramètres de sécurité

Blocage des fichiers dangereux

La première solution est d’administrer les options de sécurité d’Office via GPO, ce qui n’est pas possible par défaut.
Nous allons expliquer comment faire pour les versions d’Office 2010, 2013 et 2016.

Pour voir apparaitre dans les GPOs les paramètres pour Office il faut ajouter des fichiers ADMX. Ils sont disponibles sur le site de Microsoft :

Télécharger le contenu, se rendre sur le serveur appliquant les GPOs.
Extraire l’archive, récupérer le contenu et le coller dans : C:\Windows\PolicyDefinitions

Définitions des GPOs

Attention lors de la copie de ne pas remplacer des fichiers déjà existants.
Ouvrir gpedit.msc (Exemple avec Office 2010 mais même chose pour Office 2013 et 2016)

Configuration Utilisateur -> Stratégie -> Modèles d’administration -> Microsoft Outlook 2010 -> Options Outlook -> Sécurité -> Centre de gestion de confidentialité

GPO Office

Cliquer sur Mode de sécurité Outlook -> Activé (Utiliser la stratégie Groupe de sécurité Outlook)

Mode de sécurité Outlook

Configuration Utilisateur -> Stratégie -> Modèles d’administration -> Microsoft Outlook 2010 -> Sécurité -> Paramètre du formulaire de sécurité -> Sécurité par pièce jointes.

Extensions à bloquer niveau 1

Liste à bloquer pour le niveau 1 : (Tous les fichiers de cette liste seront complètement bloqués par Outlook)

Cette liste permet de bloquer tous les fichiers avec l'extensions suivantes: ceux-ci ne pourront être ni éxecutés ni enregistrés

JS;BAT;CMD;PY;PS;PS1;REG;DOTM;DOT;XLT;XLST;EXE;COM;DLL;MSI;SCR;VBS;VBA;VB;WSF

Extensions à bloquer niveau 2

Liste à bloquer pour le niveau 2 : (Tous les fichiers de cette liste, auront un message d’avertissement avant d’ouvrir le fichier en permettant à l’utilisateur d’enregistrer le fichier)

DOC;DOCX;XLS;XLSX;ZIP;RAR;7ZIP

Association de fichiers via GPO

On a configuré Outlook pour empêcher les fichiers dangereux d'arriver par e-mail, mais ils risquent toujours d'arriver par d'autres moyens.

Le but maintenant est d’ouvrir les fichiers .js (et d’autres…) avec Notepad pour éviter que l’utilisateur exécute des scripts et donc des virus.

Ouvrir gpedit.msc
Configuration Utilisateur -> Préférences Paramètres du Panneau de configuration -> Options des dossiers.

Nouvelle association de fichier
Associer .bat au Notepad

Faire pareil pour toutes les extensions dangereuses :

BAT, CMD, PIF, APPLICATION, GADGET, COM, SCR, HTA, CPL, JS, JSE, MSC, JAR, PS, PS1, PY, PS, PS1, PS1XML, PS2, PS2XML, PSC1, PSC2, DOTM, DOT, XLT, XLST, VBS, VBA, VB, VBE, WS, WSF, WSC, WSH, MSH, MSH1, MSH2, MSHXML, MSH1XML, MSH2XML

Vous pouvez aussi associer toutes ces extensions de fichiers au notepad directement depuis la session d'un itulisateur en utilisant ce fichier de registre.

Macro Word

En dehors des fichiers .js et autres fichiers directement exécutables, la principale source de contamination vient des Macro Office.

Un utilisateur qui ouvrait un fichier Word ou Excel était directement exposé, suite à l'activation de toutes les macros dans les paramètres de Word et Excel, de plus le mode protégé était complètement désactivé.
L'utilisateur pouvait donc ouvrir un fichier Word ou Excel, depuis un accès réseau, un mail Outlook ou depuis les téléchargements Internet.

La meilleure chose à faire est de les désactiver totalement - et ne pas laisser la possibilité à l'utilisateur de l'activer (on sait tous comment ça se passe, ils cliquent sans lire). Ça se fait toujours par GPO :
Configuration Utilisateur -> Stratégie -> Modèles d’administration -> Microsoft Word 2010 -> Options Word -> Sécurité -> Centre de gestion de confidentialité

blocage macros

Mais pour nous cela aurait posé problème car nous possédons un logiciel de gestion qui a besoin des macros Word pour fonctionner.
Nous avons donc plutôt sélectionné l'option "Désactiver tous sauf les macros signées numériquement", et contacté le développeur de l'outil de gestion pour lui demander de signer leur plugin : maintenant nos macros fonctionnent, et nous sommes quand même protégés des macros non signées.

Stratégie de backup

La dernière chose à faire - probablement la plus importante, est de faire en sorte d'avoir toujours des sauvegardes, parce que malgré nos précautions, on n'est jamais totalement à l'abris.

Nous avons décidé de renforcer notre stratégie de backup - avant on utilisait une réplication de machine virtuelle entre 2 serveurs Datacenter OVH. La restauration prenait énormement de temps et l'administration des sauvegardes ou des restaurations est assez limité.

Nous utilisons maintenant Veeam Backup & Replication qui coûte 650€ par hôte Hyper-V dans sa version standard (suffisante dans notre cas).

Nous avons des sauvegardes quotidiennes et hebdomadaires en fonction de nos serveurs et de leurs risques et expositions aux dangers, avec ce nouvel outil de sauvegarde, sur des sauvegardes quotidienne nous sommes en capacité de restaurer rapidement, en fonction de la taille du disque, un disque dur spécifique. Par exemple, un serveur attaqué par le virus locky à endommagé principalement le disque de donnée et non l'OS (car l'utilisateur ne possède pas les droits dessus) nous pouvons donc choisir de restaurer le disque de donnée F: à une heure H et un jour J.
Il suffit ensuite d'éteindre la VM et de remplacer notre VHDX et le tour est joué.

Entity Framework Core permets de travailler sur différentes bases de données, avec maintenant des providers pour différentes bases fournis par Microsoft. Les différents providers sont documentés sur le site [https://docs.microsoft.com/en-us/ef/core/providers/]

Un provider est particulièrement intéressant pour effectuer des tests est le InMemory Provider. Au lieu d'utiliser une vraie instance SQL Server, les tests sont effectués dans Entity Framework en mémoire.

Commençons par créer un nouveau projet. Nous allons utiliser une dll distincte pour toutes les classes Enfity Framework. On va utiliser un exemple simple de blog, avec une table pour les posts, et une table pour les auteurs. Commencez par ajouter le package Nuger Microsoft.EntityFrameworkCore, puis créez les entités :

public class Post
{
    [Key]
    public int Id { get; set; }

    [Required]
    [StringLength(50)]
    public string Title { get; set; }

    public string FullText { get; set; }

    public Writer Author { get; set; }
}

public class Writer
{
    [Key]
    public int Id { get; set; }

    [StringLength(50)]
    [Required]
    public string UserName { get; set; }

    [StringLength(50)]
    public string RealName { get; set; }

    public List<Post> Posts { get; set; }
}

Maintenant on va créer un contexte. Le contexte doit être lié à sa source de données lorsqu'on le construit. Ici, on ne connait pas le provider, puisqu'on peut être appelé depuis un test unitaire (qui utilisera un provider in-memory) ou notre application qui voudra utiliser une vraie base. On va écrire un constructeur qui reçoit les options du provider en paramètre.

public class BlogContext : DbContext
{
    public BlogContext(DbContextOptions<BlogContext> options)
        : base(options)
    {
    }

    public DbSet<Post> Posts { get; set; }

    public DbSet<Writer> Writers { get; set; }
}