Étiquette : Ansible

Créer un Openstack Object Storage OVH avec Terraform pour backup Nextcloud

Bonjour à tous, cela fait un long moment que je n’ai pas eu l’opportunité d’écrire un article. Il y a quelques jours, j’ai eu besoin de relier un object storage OpenStack à un Nextcloud. J’ai décidé ensuite de l’automatiser avec terraform et l’inclure dans un module. Pour ceux qui ne connaissent pas les pratiques Objects Storage, je renvoie au site OpenStack. Comme d’hab, comme je suis chauvin, je vais utiliser un service cloud français : OVH. Bientôt et si le temps me le permet, j’utiliserai ma propre infra OpenStack sur plusieurs nodes : pour ça, j’ai enfin reçu mes cartes mères bi-xeon supermicro, mais tout est à construire, même le hardware donc à suivre…

Poursuivre la lecture « Créer un Openstack Object Storage OVH avec Terraform pour backup Nextcloud »

Nextcloud avec cluster KVM: GlusterFS, Redis, MariaDB et Load-Balancing

Nous avons vu précédemment comment monter une infra simple et créer un module scalable avec Terraform et Ansible. Maintenant nous allons tout mélanger pour faire un autre cocktail.

Présentation :

schema archi nextcloud

Pour le fun, je mets le graph Terraform que l’on obtient avec la commande `terraform graph | dot -Tpng > graph.png` (la sortie peut également être en .svg) :

Graph terraform
Graph Terraform

Comme vous l’avez compris, il y a maintenant cinq modules : 

  • 2 Mariadb Master / Slave servers,
  • 2 Redis Master / Slave servers,
  • 2 vms in GlusterFS Cluster,
  • Haproxy load-balancer,
  • 2 Nextcloud serveurs avec Nginx ou Apache et php-fpm.

Avec cette version du code j’ai forcé l’installation de nginx : j’avais mis précédemment apache par défaut. C’est configurable via les variables d’Ansible. La base de donnée est répliquée sur le slave de mariadb, j’utiliserai prochainement galera. Le cache Redis est également configuré en Master/Slave, il n’y a pas (encore) de Redis-Sentinelle pour basculer le slave en master en cas de crash du master… Le cluster GlusterFS possède deux bricks répliquées en temps réel sur deux serveurs (replica). Les serveurs Nexcloud utilisent un répertoire /var/www/html/nextcloud commun pour l’application web ainsi qu’un répertoire /var/nc_data commun pour les données du cloud. Vous l’aurez compris lorsque haproxy vous redirige sur l’un ou l’autre des deux serveurs nexcloud, les données sont immédiatement visibles et accessibles sur les deux et répliquées. Par sécurité j’ai gardé SELinux en mode enforcing, mais vous avez la possibilité de basculer en permissive via une variable Ansible.

J’ai aussi intégré dans cette version le code du réseau. J’aurais pu créer des réseaux distincts avec des routes pour que les briques puissent communiquer, cela sera dans une prochaine version… pour l’instant tout est dans un réseau 10.17.3.0/26. De même je n’ai pas eu le temps de coder l’intégration avec les serveurs d’autorité DNS, pour l’instant ça reste un POC, mais ça aussi sera pour une version ultérieure avec noms de domaines, Let’s Encrypt et Terraform en mode multi providers : libvirt et sans doute OVH hein parce qu’on est frenchies.

Requirement

Le tout fonctionne sous Fedora Server cloud image.

Vous devez avoir installé sur l’hyperviseur : Terraform, Libvirt provider et Ansible (Tout est expliqué ici)

Copie / Installation

Copiez le repo, séparez la partie Terraform de la partie Ansible dans les répertoires des applications respectives. Adaptez les variables :

  • variables.tf (terraform)
  • vars (ansible)

Comme le code est franchement long, j’ai tout mis dans un github.

A vous de jouer…

Installer Nextcloud sur Fedora Servers Cloud grâce à Terraform et Ansible, part2

Vue d’ensemble du code de provision des VMs

Maintenant que l’on a notre code pour l’infra, il est temps de passer à la partie provision des vms. Pour cela, comme je vous le disais, j’utilise Ansible. Pourquoi ? Parce qu’il est de plus en plus inclus dans l’écosystème RedHat, que la communauté autour du projet est très vivante et que l’on n’a aucun de mal à trouver des infos. Je vous rappelle que ce code met à disposition des serveurs dans un réseau isolé. Je vous montre l’arborescence des rôles et playbooks en fonction de mon architecture :

Poursuivre la lecture « Installer Nextcloud sur Fedora Servers Cloud grâce à Terraform et Ansible, part2 »

Installer Nextcloud sur Fedora Servers Cloud grâce à Terraform et Ansible, part1

Aujourd’hui, je vais vous exposer un de mes POC. Je voulais installer Nexcloud sur Fedora server et pour plus de sécurité et plus d’efficacité, séparer les middlewares et les applications sur ces différents serveurs. Je pars sur 3 serveurs, on peut faire évoluer le code pour en ajouter plus, notamment Redis en master-slave, Mariadb en Master/Slave et un loadbalancer nginx. Je mets en ligne un de mes premiers codes Terraform fonctionnel. Il est plus simple à comprendre mais pas super optimisé/industrialisé. Dans des articles ultérieurs, je mettrai des codes Terraform pour de l’infra scalable, c’est plus sexy. J’ai essayé dans les playbooks ansible d’adapter les règles SElinux pour que l’application Nextcloud fonctionne en mode enforcing, et ça passe: c’est toujours mieux avec. Un truc sympa à faire également au niveau sécu, serait de relier le chiffrement de Nextcloud à la puce TPM émulée du serveur, dans le même registre je n’ai pas mis de rôle pour le durcissement des souches Fedora. Tout un programme…

Poursuivre la lecture « Installer Nextcloud sur Fedora Servers Cloud grâce à Terraform et Ansible, part1 »