Nextcloud est un serveur de stockage et de partage de fichiers en ligne.

Sa grande force réside dans le fait que vous contrôlez entièrement vos données, l'emplacement du stockage, le partage, la suppression, etc. Tout reste sous votre contrôle, à la différence des services comme Dropbox ou Google Drive.
Techniquement Nextcloud est un fork d'Owncloud. Il en reprend les bases, mais son développement est plus actif, et il bénéficie de plus d'application qu'Owncloud.

J'ai choisis ce projet à faire sur mon temps libre pour plusieurs raisons, d'abord car je trouvais intéressant de monter un service semblable au Drive de Google mais de manière gratuite et transparente pour mes données. En effet, avec mon serveur Nextcloud, je suis maitre de mes données, je sais ou elles sont, je sais que personne ne les donnes à des sociétés publicitaires ou qu'elles ne sont pas analysées à des fins commerciales.

La deuxième raison est qu'en Juin, je vais dans l'entreprise d'un collègue de mon IUT Christian Barreto pour répondre à une demande de son entreprise :
Monter une architecture Nextcloud pour eux et leurs utilisateurs.
Je trouvais donc intéressant de monter la solution de mon côté avant le projet "officiel" pour le comprendre, résoudre les problèmes que je peux rencontrer pour gagner du temps en entreprise et du coup, avancer plus vite.

Au niveau de l'architecture choisi, j'aurais pu monter tout ça sur un seul serveur mais l’intérêt est très limité.
En effet, il n'y aurais eu aucune redondance, aucune scalabilité, si mon serveur tombe pour x ou y raison, mon service Nextcloud est hors-ligne.
Bref, monté tout sur un serveur c'est bien à l'école ou pour s'amuser mais en entreprise, ce n'est pas comme cela qu'il faut fonctionner.

J'ai donc décidé de m'appuyer sur la documentation officiel de Nextcloud pour proposer une architecture redondante et scalable.

A la fin mon architecture ressemble à ça:

J'ai donc une architecture redondée, hautement disponible et scalable au besoin.

Au niveau des choix technologiques, j'ai essayé de reprendre ce que nous avons vu en cours.

Au niveau de la base de donnée, je suis parti sur un cluster Galera.

Cette parti ne fut pas très compliqué vu que nous l'avions deja tester en cours avec Julien Breyault.
Il est possible de chiffrer les communications entre les noeuds du cluster, ce que je ferais dans l'entreprise de mon collègue.
Au dessus de ce Galera cluster, j'ai mis en place deux serveurs HAPROXY pour équilibrer la charge entre chaque noeud du cluster, et sur ces deux serveurs HAPROXY il y a le service Keepalived d'installé et de configurer ce qui me permet d'avoir une adresse IP virtuelle que je fournis à mon serveur WEB. Cette adresse ip virtuelle (VIP) permet de basculer entre le premier serveur HAproxy ou le deuxième si le premier tombe.

Et pour la scalabilité, si les noeuds présents ne suffisent plus à répondre à la demande, il est possible de rajouter un serveur Mariadb au cluster très simplement.

HAPROXY est un équilibreur de charge très performant, fiable et flexible. De plus, la communauté autour de ce service est très forte ce qui rend la résolution de problème rapide.

Au niveau du stockage, j'ai repris le cours que nous avons effectué avec Julien Breyault sur GlusterFS.

Gluster permet de mettre en cluster plusieurs nœuds de stockage (à minima deux), ce qui permet de répondre à deux problématiques majeures dès qu’une application a besoin de pouvoir monter en charge : la parallélisation et la réplication du stockage.
Pour fournir ces fonctionnalités sur un volume, une « brick » en langage Gluster, le système s’appuie sur des systèmes de fichiers traditionnels, XFS ou EXT4 au-dessus d’un périphérique en mode bloc (partition, LVM, RAID, etc..). Gluster travaille donc principalement au niveau fichier.
J'ai donc monté un glusterfs avec deux noeuds, je l'ai sécurisé en n’autorisant uniquement que les ip de mes serveurs web à s'y connecter.
Il est possible si nous manquons d'espace de stockage ou que nous voulons améliorer les performances de note cluster, on peut rajouter un ou des nœuds très simplement.

Au niveau des serveurs web, on reprend le même principe que pour le cluster Galera, sauf qu'un serveur est sans état (ce ne sont que des fichiers html,php), j'ai installé nextcloud sur deux serveurs APACHE, monté deux serveurs HAPROXY pour l'équilibrage de charge et le service Keepalived sur ces deux serveurs.
A la fin, je n'ai plus qu'une IP virtuelle qui me permet de me connecter à mon Nextcloud. Évidemment, on communique uniquement via le protocole HTTPS.

Et en ce qui concerne la scalabilité, il est possible de rajouter un serveur web simplement, et de l'intégrer à l'équilibreur de charge.

Adopter des choix technologiques justifiés par les théories des réseaux et des systèmes ainsi que par l’offre de solutions existantes.

Prévenir les problèmes de sécurité.

Même si j'éteins 6 machines sur 11, mon serveur Nextcloud continuera à tourner !

On voit ici toute l'importance de la haute dispo, qui permet de réaliser de la maintenance sur les différents serveurs sans impacter la production ou de permettre à l'application de tourner même si un serveur ne marche pour n'importe quel raison

Organiser et tester la réaction en cas d’incident

Ce projet est surement l'un des plus intéressant que j'ai réalisé à ce jour.

En effet, je sais maintenant architecturer une application en ayant  les contraintes de haute disponibilité, redondance et de scalabilité en tête.
Les technologies que j'ai utilisés me serviront pour mes projets futures (surtout HAproxy qui est le ou l'un des répartiteur de charges les plus utilisés.)

Je me sens également plus serein à l'idée de proposer cette solution à l'entreprise de mon collègue.

Ce projet fut assez long, je travaillais dessus uniquement deux à quatre heures par week-end. J'ai mis un mois et demi avant de le finir.
J'ai pris des notes par rapport aux problèmes que j'ai rencontré ou aux tutoriels que j'ai suivi pour l'entreprise de mon collègue.
Si nous rencontrons ces problèmes, nous ne passerons pas de temps à chercher la cause et nous gagnerons ainsi du temps.

Documenter des actions individuelles dans une logique de groupe