Journal Installer Drupal automatiquement avec Ansible et Drush sous Debian

12
10
mar.
2019

Un petit journal pour ceux qui voudraient installer Drupal sous Debian, de façon automatique et relativement sécurisée.

  • Pour le déploiement, j'utilise Ansible et Drush.
  • Pour la sécurité, AppArmor et mod_security.
  • Drupal est configuré avec l'option "clean url".
  • La base de données est PostgreSQL.
  • Les mots de passe sont générés aléatroirement, et sauvegardés sur la machine où tourne Ansible.
  • Les certificates sont générés avec LetsEncrypt, et sauvegardés sur la machine où tourne Ansible.

La liste des modules à installer ou à désinstaller est fournie dans le fichier de configuration YAML (branche dev pour l'instant)

Le fait de sauvegarder les certificats et mots de passe permet de redéployer l'application sans redemander des certificats.

C'est juste un petit projet, mais comme ça m'est utile, ça l'est peut être à des lecteurs. Ce projet est complémentaire à HomeBox, je ne l'inclue pas encore, mais cela pourrait se faire plus tard.

https://github.com/progmaticltd/drupal-debian-secure

  • # Certificats

    Posté par . Évalué à 4 (+3/-1).

    Les certificates sont […] sauvegardés sur la machine où tourne Ansible.

    Les clefs privées ne devraient pas sortir de la machine où elles sont générée et exploité. Si tu les perds il faut simplement en générer de nouveaux.

    • [^] # Re: Certificats

      Posté par (page perso) . Évalué à 4 (+3/-0).

      Lorsque je développe, souvent avec une machine virtuelle, je finis par rejouer les scripts plusieurs fois.

      Il y a une limite avec LetsEncrypt qui t'empêche de demander les certificats trop souvent. Au bout de par exemple 15 fois, le serveur réponds que la limite est atteinte, et que tu n'aura plus de certificats avec 24h.

      C'est nécessaire pour le développement.

      Maintenant, c'est vrai que je pourrais limiter ce comportement à la phase de développement.

      Merci pour la suggestion.

  • # Question de neophyte

    Posté par . Évalué à 3 (+1/-0). Dernière modification le 12/03/19 à 10:02.

    Je ne connais pas les outils de type Ansible ou Drush (jamais entendu parler du second).
    Je suis donc curieux : qu'est-ce que ça automatise par rapport à un bon vieil "apt-get install drupal" ?

    ps: je viens de voir la page https://www.drupal.org/docs/8/install et ça a l'air infernal à installer par rapport aux CMS que j'ai connus par le passé

    BeOS le faisait il y a 15 ans !

    • [^] # Re: Question de neophyte

      Posté par (page perso) . Évalué à 5 (+2/-0).

      L'équivalent serait plutôt le shell script qui fait le apt update, le apt installé, la config, le redémarrage du service, etc.

      ansible vs shell : le premier amène l'idempotence, est plus facile, le shell c'est piégeux, ansible c'est gestion du parc tandis que ton script va gérer une machine uniquement, ansible est aussi plus haut niveau et fournit une bibliothèque de fonctions, etc.

      • [^] # Re: Question de neophyte

        Posté par (page perso) . Évalué à 4 (+2/-0).

        Avec ansible, tu vas donner une série d'instructions du type « tel objet doit être dans tel état » :

        • la ligne TOTO=3 doit être présente dans /etc/fichier.conf,
        • le paquet tree doit être installé dans sa dernière version,
        • le fichier /etc/service.conf doit être modifié,
        • le service networkd doit être démarré.

        De plus, tu as une notion de variables (par exemple, n'importe où dans Ansible, "{{ ansible_hostname }}" sera remplacé par le nom de la machine).
        C'est à Ansible de se débrouiller pour que l'état soit mis en place (ou ne rien faire).

        Avec bash, les instructions que tu donnes sont du type « faire quelque chose », et c'est à toi de vérifier si c'est déjà fait.

        • [^] # Re: Question de neophyte

          Posté par . Évalué à 2 (+0/-0).

          Peut-être que dinomasque parlait d'utiliser un paquet Debian custom pour faire ça ?

          Les dépendances en control, les modifications en postinst, et la « variable » hostname est donnée par… "hostname", la commande.

          Ça demande peut-être un peu plus d'intégration parce que personne n'a aussi bien intégré les modifications selon template ou autre (je suppose que chez Debian on est plutôt à la Unix, « tu sais bien utiliser sed/awk/perl »), mais rien n'empêcherait quelqu'un de faire ce genre d'outil intégrable dans dpkg.

          Sans parler du fait qu'on croit qu'ansible c'est idempotent « magiquement », alors que dans la réalité il existe toujours des petits détails qui font que des changements nécessitent de gérer explicitement la transition. C'est explicitement géré par les transitions d'état de dpkg lors des scripts de {pre,post}{inst,rm}. Et dans les déploiements modernes on évite ce problème en… réinstallant tout depuis le début à chaque fois. Et du coup on doit réinventer des mécanismes de persistance hors-FS.

          Après, ansible & co simplifient le cas « autoroute » où on a deux-trois modifications simples à faire, mais pour des trucs un peu plus travaillés, je ne suis pas sûr que la quantité de travail soit si inférieure à gérer un paquet Debian.

  • # J'suis pas prés de retourner sous Debian / Apache

    Posté par . Évalué à 1 (+0/-0).

    • AppArmor et mod_security.

    Je ne sais pas ce que c'est encore que cette énième surcouche de bidouille "AppArmor" mais sous FreeBSD Apache tournerait isolé dans sa Jail déployée avec Ansible.
    Puis si je veux augmenter le niveau de sécurité je colle un coup de Chroot au binaires Nginx à l'intérieur de la jail.
    Je ne touche pas évidemment plus à Apache.
    Au pire j'explose encore la configuration en faisant tourner PHP à part isolé dans une autre jail.
    La communication inter jails étant effectuée par la pile network de l'host FreeBSD avec un Packet Filter des familles.

    • Les certificates sont générés avec LetsEncrypt, et sauvegardés sur la machine où tourne Ansible.

    Mon RSSI serait blanc en lisant ça !

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.