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.
# Certificats
Posté par barmic . Évalué à 4.
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 Andre Rodier (site web personnel) . Évalué à 4.
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.
[^] # Re: Certificats
Posté par jnanar (site web personnel) . Évalué à 8.
Let's Encrypt propose un environnement "Staging". Les certificats ne sont pas valides (ils produisent un avertissement dans le navigateur) mais la limite est beaucoup plus haute. Cela permet de tester et de valider un comportement avant de demander les bons certificats quand tout roule.
https://letsencrypt.org/docs/staging-environment/
[^] # Re: Certificats
Posté par Andre Rodier (site web personnel) . Évalué à 2.
Merci, je l'ai implémenté dans la version master de HomeBox, je le ferais pour la version de Drupal aussi. Bonne soirée.
# Question de neophyte
Posté par dinomasque . Évalué à 3. Dernière modification le 12 mars 2019 à 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 20 ans !
[^] # Re: Question de neophyte
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
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 flan (site web personnel) . Évalué à 4.
Avec ansible, tu vas donner une série d'instructions du type « tel objet doit être dans tel état » :
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 benoar . Évalué à 1.
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 Kwiknclean . Évalué à 1.
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.
Mon RSSI serait blanc en lisant ça !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.