Ma plateforme de travail collaboratif Nextcloud en 5 minutes

Posted by

C’est quoi Nextcloud ?

Par où commencer ? Nextcloud, c’est tellement de choses ;-)

Historiquement, Nextcloud est un fork du projet Owncloud, qui visait à fournir un service en ligne de stockage de fichier via une interface web. Un peu comme Dropbox, mais hébergé par vous, chez vous, et donc respectueux de votre vie privée !

Mais aujourd’hui, Nextcloud c’est bien plus que ça. C’est une véritable plateforme de travail collaboratif avec certes un service de gestion, de partage et de synchronisation de fichiers entre plusieurs devices/utilisateurs, mais aussi un serveur libreoffice/collabora de l’édition de fichiers collaboratifs (Office 365/Google Docs), un serveur Talk (visioconférence), calendrier, gestion de notes et bien plus encore.

La solution s’est même nettement étoffée depuis la version 18 qui vient de sortir, avec de très nombreuses extensions.

Pourquoi attendre si longtemps pour en parler ?

La première fois que j’ai testé Owncloud, c’était en 2014 lorsque j’ai créé (sans succès) une entreprise d’infogérence spécialisée dans les outils open source. Le but était de fournir, entre autre, un service autohébergé pour justement remplacer Dropbox. Cette annecdote fera peut être sourire certains de mes lecteurs, très impliqués dans Nextcloud :-p.

A l’époque, je n’avais pas du tout aimé Owncloud, que j’avais trouvé moyen en terme d’ergonomie, très lent, etc.

Récemment cependant, Nextcloud a gagné beaucoup de traction et c’est tant mieux, car ça m’a forcé à rester l’outil, qui a vraiment évolué pour le mieux.

Et comment on va faire pour le déployer si vite ?

Ahah ! En voilà une bonne question… Grosse surprise, on va déployer tout ça avec un playbook, bien sûr !

Pour ceux qui ne savent pas, à chaque fois que j’installe un soft, j’automatise ça avec ansible, car j’automatise TOUT avec ansible.

Je vous met à disposition sur Github cet ensemble de playbooks qui vous permettront d’installer un serveur Nextcloud de A à Z en partant d’un serveur Ubuntu 18.04 sur lequel vous avez un accès SSH.

Et pour ceux qui n’ont pas de serveur à disposition, je vous ai également mis un playbook permettant de déployer une machine sur le cloud provider français Scaleway.

Pourquoi Scaleway ? Pas parce que j’ai le moindre partenariat avec eux (pas pour l’instant en tout cas), mais parce :

  • ils sont français
  • ils ont une super API et des modules Ansible qui marchent très très bien (j’ai même fais un live coding avec) avec l’inventaire ansible dynamique (ce que d’autres n’ont pas forcément)
  • ils proposent des instances à moins de 4€ par mois, payable à l’heure, ce qui est parfait pour des petits tests

Mais n’importe quelle autre machine sous Ubuntu 18.04 fera l’affaire !

Créer une VM sur Scaleway

Je ne détaillerai pas l’instanciation de la VM sur Scaleway si vous choisissez cette option, car tout est expliqué en détail sur le README.md du dépôt Github. J’ai également abondamment parlé de ce sujet à l’occasion d’autres articles

Préparer l’installation de Nextcloud

Avant de pouvoir installer Nextcloud sur notre nouveau serveur Ubuntu 18.04 tout neuf, il est important de choisir un nom de domaine pour notre futur service Nextcloud. Ajoutez un CNAME permettant de mapper ce nom de domaine sur l’adresse IP de votre machine virtuelle Ubuntu.

Maintenant que le serveur Ubuntu 18.04 est disponible et que le futur service est résolvable, on dispose de 2 méthodes pour installer Nextcloud. Soit on lance le playbook ansible en local sur la machine Nextcloud, soit on l’installe à distance via ansible.

Si on le lance en local

Récupérer le repository zwindler/ansible-nextcloud directement sur le serveur via un git clone. Nous utiliserons le paramètre "-i hosts_local" quand on exécutera ansible-playbook.

Si on a généré une VM avec Scaleway

Dans ce cas, on profitera de la fonctionnalité d’inventaire dynamique fournie par Scaleway. Nous utiliserons le paramètre "-i dynamic_inventory.yml" quand on exécutera ansible-playbook.

Si vous voulez installer à distance

Il sera nécessaire de pouvoir se connecter en SSH à la machine distante mais aussi de générer un inventaire pour qu’ansible sache sur quel machine il doit se connecter. Pour le faire on créera un fichier texte avec l’IP du serveur distant, et nous utiliserons "-i hosts_distant" quand on exécutera ansible-playbook.

echo "IP_of_the_server" > hosts_distant

Installer Nextcloud

En partant du principe que vous avez utilisé la méthode Scaleway avec l’inventaire dynamique, voilà ce que vous devrez faire :

ansible-playbook -i dynamic_inventory.yml -u root nextcloud_install.yml

Le playbook vous promptera pour renseigner un certain nombre de variables qui correspondent à votre installation :

MariaDB root password: awesome_mariadb_password
Nextcloud MariaDB password: awesome_mariadb_user_password
Your domain: zwindler.fr
Nextcloud HTTPS port [8443]: 443
Nextcloud instance name (URL will be https://[thisvalue].[your_domain]) [nextcloud]: nextcloudscw

A l’issue du playbook, vous devriez pouvoir vous connecter sur votre instance pour finaliser l’installation. Lorsque vous vous connecterez pour la première fois, vous tomberez sur un écran qui vous demandera une partie des informations rentrées préalablement

Et la sécurité ?

Et oui, la sécurité pour un outil aussi sensible que vos documents, c’est important.

Heureusement, Nextcloud est un outil bien packagé et un projet pour lequel la sécurité est au cœur du développement.

Nextcloud met à disposition un scan de sécurité (scan.nextcloud.com) qui vous permettra de vous tester contre un certain nombre d’attaques connues.

Comme vous pouvez le voir, ça se passe plutôt bien ;-)

De même, la configuration nginx (le frontal de notre serveur) coté TLS est elle aussi sécurisée. Par défaut, je désactive TLS 1.0 et 1.1, ce qui peut poser des soucis pour les plus vieux appareil mais permet d’obtenir un joli A+ chez SSL Labs

Dans le cas où vous souhaiteriez les réactiver, c’est possible (il y a un flag dans le playbook) mais dans ce cas là la note sera rétrogradée à B.

Et c’est fini ! Have fun !


Vous aimez ce blog ? Partagez-le avec vos amis !   Twitter Facebook Linkedin email

Vous pouvez également soutenir le blog financièrement :
Tipeee

10 comments

  1. Merci pour cet article, j’étais justement dessus !
    J’ai un VPS chez OVH, mon nom de domaine est en commande. N’étant pas encore résolvable, j’attends.

    Une question cependant : est-ce possible, sur un même VPS, d’avoir NextCloud et Gitlab ? (tous deux seront très peu utilisés)
    Encore merci ! <3

  2. Il n’y a pas de contre-indication non. Il faudra juste un peu jouer avec nginx pour rediriger les URLs vers la bonne cibles et faire attention à la conso CPU/RAM (je ne sais pas quel taille de VPS tu as pris), mais dans un contexte mono utilisateur (ou avec quelques users), pas de souci je pense.

    Pour donner un idée, mon Nextcloud perso fonctionne depuis 3 mois avec 1 vCPU et 512 Mo de RAM sans aucun souci pour l’instant. Gitlab ne demandera pas plus.

  3. Gitalb c’est un monstre de consommation de ressources, si le VPS est pas super musclé, c’est même pas la peine. Sinon oui au niveau logiciel y’a rien qui empêche de faire cohabiter les deux derrière Nginx.

  4. Ah, zut, j’avais pas ce souvenir, je pensais que la conso était basique pour une appli web standard.
    Heureusement que tu le note.

  5. Re Zwindler, pour faire suite à mon commentaire j’ai installé Gitlab et avec 1 CPU et 2Go de RAM ça fonctionnait mais tombait souvent en retournant des 502 (un seul user). Il bouffait constamment un peu moins de 1,7Go de RAM, et juste en demandant des pages le CPU était assez demandé.

    Mon VPS est chez OVH, j’ai changé pour 2 CPU et 4Go de RAM (puisque maintenant je vais essayer d’installer Nextcloud et au futur des petits projets Node c’est pas si mal) et ça fonctionne très bien depuis. :)

  6. Gitlab recommande 8 Go de RAM de mémoire (ma mémoire à moi). Quand je l’avais sur un VPS il prenait systématiquement au moins 8 Go. En ce moment je l’ai dans une VM où j’ai alloué 16 Go de RAM et il en prend environ 10.

    Nextcloud est beaucoup plus léger mais va demander de l’espace de stockage.

    C’est complètement possible d’avoir les 2 services sur un VPS (je l’ai fait pendant longtemps), mais je trouve que comme les besoins sont très différents, ce n’est pas forcément adapté.

  7. Effectivement avec des besoins pareil, mieux vaut privilégier la ségrégation !
    Je pensais que ça consommait presque rien du coup autant mutualiser, mais là c’est clairement pas idéal

  8. La consommation Gitlab dont il est question ci-dessus ne concerne que la partie de base de Gitlab (Repo Git et interfaces web, wiki, tickets, …). Si vous utilisez la partie CI, il faut encore ajouter la consommation des Jobs de CI.

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.