Madovi

Machines - Données - Virtualisation

Outils pour utilisateurs

Outils du site


tuto:migrations:ub-2-deb

VHS - Une migration vers Debian

En cours...

Le but de cet article est de décrire les opérations qui vont permettre de migrer le serveur NAS VHS de Ve-Hotech, d'un OS Ubuntu «Trusty» 14.04.2 enrichi par VHT (mais obsolète et plus maintenu) vers une distribution Debian «Buster» 10 (à date).

C'est le projet «»… (Virtualisation et stockage 8-)) !

On repart ici d'un «page blanche»… On essayera néanmoins de reconduire un maximum des fonctionnalités initiales (ou des équivalents).

On se donne pour cibles:

  • Un OS Debian Buster (stable), localisé sur une clé usb
  • Un ensemble minimum d'outils à installer, assurant les fonctions de base du système:
    • L’outil mdadm pour gérer des disques en RAID
    • Les outils de gestion des espaces de stockage lvm et/ou btrfs pour la souplesse qu'ils apportent
    • Les protocoles réseau: accès au NAS en ssh, NFS, SMB, …
    • Les outils de virtualisation:
      • VM avec QEMU-KVM (pour les processeurs qui supportent)
      • Containers LXC
      • Containers Docker
    • On prévoit des fonctionnalités nativement installées comme:
      • Un portail de «supervision & surveillance» avec notification et alertes par courriel
      • Gestion d'un onduleur
      • Etc…
  • Les services autres: Base de données (ex. MariaDB), sauvegardes, serveur web(Ex Apache/Nginx/php), gestion vidéos (ex. Kodi, Plex), musiques (ex. Sonerezh), partages (ex. NextCloud), téléchargements (PyLoad), etc…, sont destinés à être virtualisés, de façon légère dans des containers: ceci devrait permettre de préserver le système hôte des contraintes de mises à jour et d'incompatibilités potentielles.

 cible

Le présent travail est … de longue haleine: mine de rien, on ne «remplace» pas tout le boulot de Ve-Hotech d'un claquement de doigt !
Il se fera progressivement, au gré des disponibilités et des besoins.

Par conséquent, il s'agit d'ordonnancer et prioriser les opérations.

  1. La première de ces opérations est évidemment l'installation de l'OS sans quoi rien n'est possible.
  2. Après une petite… digression sur la reprise des données depuis les disques de l'«anciens VHS», on proposera une organisation des supports de stockage et leur mise en œuvre pour la cible.
  3. Dans la mesure où on s'oriente ici vers une virtualisation maximale des services, on y consacrera une présentation et sa mise en musique.
  4. A partir de là on aura fait le plus gros: le… «reste» va consister à choisir et implémenter les services souhaités, après avoir définit la façon la plus efficace de le faire: virtualisation (laquelle ?) ou service «direct host» si c'est techniquement incontournable.
  5. Tout cela se fera forcément en ligne de commande… Sans doute ne coupera-t-on pas à rendre les choses plus «user friendly» (par le biais d'un portail par exemple): Peut-être à définir en dernier quand on aura les idées claires, ou au fil de l'eau en même temps que les services… mais ça paraît plus compliqué!

Allez, hop ….


1. Périmètre de la Migration

Ce tutoriel est joué sur un VHS-4 VX - Intel® Core i5 2405s @ 2.5 GHz - 16 Go DDR3 - OS VHT v 6.1.4.

En principe – et puisqu'on s'emploie ici à le supprimer – la version actuelle du firmware Ve-Hotech n'est pas importante. Et en principe toujours, on peut également appliquer les opérations décrites ici sur d'autres configurations capables d’accueillir 4 disques SATA.

1.1. Matériel VHS candidat

Seuls les VHS suivants sont concernés par la migration décrite ici, avec notamment:

  • 4 emplacements disques au minimum;
  • Prise vidéo pour avoir un écran – peuvent donc s'ajouter des Home I ou Xtrem I avec VGA cachée et câblage maison;
  • Les machines sans support VM (Home I, certains Home II et VHS LS) pourront quand même utiliser les containers LXC et Docker pour les services virtualisés.
Modèle Baies RAM max. Support VM Connectique vidéo Dongle
Home I 4 4Go NON 1) VGA cachée Interne
Home II 4 8Go :?: Selon processeur HDMI Externe
Xtreme I 4 4Go OUI VGA cachée Externe
Xtreme II 4 8Go OUI VGA+DVI+HDMI Externe
Xtreme III 4 16Go OUI VGA+DVI+HDMI Interne
VHS LS 4 4 16 Go NON VGA+DVI+HDMI Interne
VHS LS 8 8 16 Go NON VGA+DVI+HDMI Interne
VHS VX 4 4 16 Go OUI VGA+DVI+HDMI Interne
VHS VX 8 8 16 Go OUI VGA+DVI+HDMI Interne

1.2. Disques et données

On va utiliser ici (en plus d'une clé d'installation):

  • une clé USB pour faire tourner l'OS: 16 Go devraient suffire; ici j'ai fait dans le luxe avec la seule clé «un peu grande» que j'avais sous la main: 128 Go…
  • un disque Maxtor de 250 Go pour la virtualisation
  • Trois disques de 4 TO pour les data en RAID 5 (1 WD RED, 2 IronWolf)

On part, dans le cadre de ce tutoriel, sur des disques neufs ou effacés.

On ne propose pas de reprendre les données du VHS, vous devez les sauvegarder ailleurs si vous souhaitez ré-utiliser vos disques !


2. Installation de l'OS

A l'instar d'autres systèmes pour NAS comme «FreeNAS» ou «OpenMediaVault», il s'agit d'installer le système d'exploitation Debian sur une clé USB sur laquelle la machine va booter.

On se munit donc d'un VHS avec écran/clavier raccordé à internet et de deux clés USB:

  • une clé destinée à l'installation cible d'une taille de 8 Go au minimum (et c'est un peu faible…);
  • une clé LiveUSB avec Debian «Buster» dessus. Tout le parc des VHS étant en architecture 64 bits, l'ISO d'installation depuis internet debian-10.0.0-amd64-netinst.iso convient à tous les modèles.

2.1. Préparation du VHS

Éteignez votre serveur VHS et déboîtez tous les tiroirs des disques, de telle manière qu'ils ne soient plus connectés. Un des disque va être dédié à la virtualisation, en première ou dernière position (juste pour le repérer et que c'est plus logique, ça fonctionnera n'importe où): c'est le moment de le monter dans un de ces tiroirs à la place d'un ancien “gros” car plus de 1 To pour des services, c'est un peu «donner de la confiture aux cochons»…

FIXME Ecrire, ici ou dans Gestion des espaces de stockages, un § sur manipulations d'effacement des partitions d'un disque, avec GParted en live USB par exemple… FIXME

Si votre équipement dispose du dongle / de la clé système en externe (Home II, Xtreme I & II), retirez-le aussi.

Conservez en revanche sa connexion réseau pour garder l'accès à Internet nécessaire à l’installation du nouveau système proposée ici.

Raccordez votre écran et votre clavier, connectez les deux clés USB: celle de l'image Debian, et celle de la cible – a priori vierge – pour l'OS, puis lancez la machine; appuyer «frénétiquement» :-D sur la touche <DEL> jusqu'à voir apparaître l’écran du BIOS.

A ce stade, il se peut que vous rencontriez des problèmes et qu'il soit nécessaire de faire plusieurs tentatives en jonglant avec les prise USB, en particulier pour le raccordement du clavier.

En effet, selon les modèles, les prises USB ne sont pas nécessairement gérées dès le démarrage du serveur. Il est donc possible que votre clavier doivent être branché sur une autre prise USB pour qu'il soit opérationnel dès le démarrage et que vous puissiez effectivement accéder au menu du BIOS. Par exemple sur Xtreme II, utiliser la prise en bas juste à coté de la connexion RJ45 pour le clavier semble être une bonne idée…:-).

Dès que vous avez votre écran de BIOS, il faut choisir la clé sur laquelle vous allez booter. Il s'agit de ne pas «se mélanger les pinceaux», si en plus votre modèle a sa clé système en interne… Sur VHS-Vx, cette clé Ve-Hotech a un nom en DataTraveler_2.0. De même il faut ignorer la clé cible et bien choisir la seule valable pour booter: celle avec l'image Debian qu'il faut donc choisir en première position…

2.2. Installation du système

On ne va pas décrire ici la procédure d'installation d'une distribution Debian: on trouve tout ce qu'il faut sur le net.

Juste quelques remarques:

  • minimisez la taille de la partition du swap : 1 Go par exemple suffisent.
  • de même, lorsque la procédure arrive au choix des logiciels, n'installez pas d'interface graphique, serveur SSH indispensable.
  • peut-être est-il intéressant lors de l'installation de ne pas définir de compte root: ainsi le premier utilisateur que vous définissez dans cette procédure aura automatiquement les privilèges root via sudo. Utilisez par exemple un compte install qu'on pourra supprimer par la suite éventuellement.

A l'issue de l'installation, redémarrez en conservant seule la clé cible où vous avez installé le système (un nouveau passage par le BIOS et le choix de cette clé comme support de démarrage peut s'avérer nécessaire).

2.3. Quelques contrôles ...

Une fois que vous avez redémarré la machine, elle présente un simple écran d'attente de saisie d'un login.

  • Assurez-vous que vous pouvez vous logé avec compte et mot de passe définis lors de l'installation.

  • Vérifiez la version de votre OS:
    $ lsb_release -a
    No LSB modules are available.
    Distributor ID:	Debian
    Description:	Debian GNU/Linux 10 (buster)
    Release:	10
    Codename:	buster
  • Assurez-vous que les paquets ssh sont bien installés:
    $ dpkg-query -l | grep ssh
    ii  libssh2-1:amd64                1.8.0-2.1                    amd64        SSH2 client-side library
    ii  openssh-client                 1:7.9p1-10                   amd64        secure shell (SSH) client, for secure access to remote machines
    ii  openssh-server                 1:7.9p1-10                   amd64        secure shell (SSH) server, for secure access from remote machines
    ii  openssh-sftp-server            1:7.9p1-10                   amd64        secure shell (SSH) sftp server module, for SFTP access from remote machines
    ii  task-ssh-server                3.53                         all          SSH server
  • Vérifiez que le serveur ssh est bien à l'écoute:
    $ ss -tlp | grep ssh
    LISTEN    0         128                0.0.0.0:ssh               0.0.0.0:*      
    LISTEN    0         128                   [::]:ssh                  [::]:*      
  • Enfin, assurer-vous que votre compte dispose bien des privilèges root via l'utilitaire sudo; celui-ci a été activé par défaut si vous n'avez pas défini de compte root lors de l’installation: Ainsi tapez:
    $ sudo -i

    Cette commande, après un message de rappel et d'attention, va demander le mot de passe du compte courant. Si tout va bien, le prompt vous affichera le caractère #, signe que vous avez désormais des privilèges d'administration sur la machine. Faites:

    # exit

    pour revenir au compte (vous repasserez sur un prompt en $).

2.4. ... et ajustements...

FIXME Epy a écrit: «Il y a des options à activer sur les partitions de la clé pour qu'elle travaille moins: noatime nodiratime pour qu'il ne mette pas à jour l'heure d'accès à la partition à chaque écriture. Cela fait moins d'écritures sur la mémoire flash» FIXME

FIXME Faire le ménage régulièrement (définir des cron ?):

  • Supprimer le cache des paquets périmés :
    # apt autoclean
  • Supprimer tout le cache :
    # apt clean
  • Supprimer les paquets installés comme dépendances et devenus inutiles :
    # apt autoremove
  • Liste des noyaux installés:
    $ dpkg -l | grep -Ei "linux-(g|h|i|lo|si|t)"
  • Pour purger :
    # apt --purge autoremove

Lien externe FIXME

2.5. ... et compléments

Nous allons ajouter quelques outils sur l'hôte lui-même (et donc sur la clé USB). En voici une liste, par domaine:

  • Gestion des espaces de stockage:
    • dfc: Petit outil permettant d'afficher simplement les taux d'occupation sur les points de montage
    • gdisk: c'est le pendant de fdisk, il est indispensable pour partitionner des disques > 2To
    • smartmontools: Outils de monitoring des disques S.M.A.R.T.
    • * …

    • ☛ Commande d'installation:
      # apt install dfc gdisk smartmontools
  • Gestion du réseau:
    • net-tools: Pour mon confort personnel ;-), ce paquet inclut des commandes réseau arp, ifconfig, netstat, rarp, nameif et route, qui simplifient la vie…


    • ☛ Commande d'installation:
      # apt install net-tools
  • Divers:
    • acl: La mise en place des ACL permet une gestion fine des accès des utilisateurs, des groupes, aux répertoires et aux fichiers d'une partition qui dispose d'un “file system” qui accepte les acl. (par ex: Ext3).
    • git: pour récupérer des projets github, gitlab… y compris depuis un container à venir…
    • tree: un petit outil pour afficher les arborescences de fichiers


    • ☛ Commande d'installation:
      # apt install acl git tree

NB: Les autres installations seront décrites au fur et à mesure des besoins, dans les autres §.

A partir de maintenant, on pourra contrôler totalement le serveur avec une connexion ssh depuis un poste client: on peut désormais se passer d'écran et de clavier.

Invitation:

  • Éteignez votre machine
  • Connectez vos disques (le 1ier pour la virtualisation, les autres pour les data)
  • Re-bootez et loguez-vous
  • Utilisez:
    sudo lsblk -o name,model,type,size,fstype,state,mountpoint

    pour repérer quel disque est destiné à quoi…

Vous pouvez donc regagner votre bureau, où écran et fauteuil sont bien plus confortables, avec votre PC véloce qui, s'il a le malheur d'être sous Windows®, devra disposer de PuTTY au moins…


3. Espaces de stockage

3.1. Organisation d'«origine»

Reportez-vous à cette page VHS - Organisation du RAID pour voir comment est organisé le stockage sur le VHS.

On propose ici de faire tout autre chose…

3.2. Organisation cible

La cible de notre système va correspondre au schéma suivant:

Quelques considérations qui motivent un tel choix:

  • OS sur clé:
    • Gain de place (un peu symbolique): Sur le VHS, le système en RAID 1 occupe environ 4,5 Go sur une partition, la zone disque pour le swap mémoire occupe également sur chaque disque une partition d'½ Go. Certes, à l'ère des disques de 20 To, ce n'est pas grand-chose: accordé ! Mais si cet espace était suffisant sur le VHS en version Ubuntu «Trusty» 14.04, les OS récents sont plus gras
    • Disponibilité: Si vous mettez le système sur les disques dans un raid (comme pour le VHS par exemple) et que le raid a un problème, vous n'avez plus d'accès à la machine et il vous faut booter sur… une clé usb. Ici le système vous permet d'avoir la main, même avec un RAID en «carafe».
    • Sauvegarde: L'idée ici est d'installer le système et l'ensemble des programmes utiles; ensuite on n'y touche plus, les services étant ajoutés par virtualisation sur un disque dédié. La plus grande fragilité d'une mémoire flash sur une clé par rapport à un disque dur est compensée par une plus grande souplesse en cas de souci. On fait une sauvegarde de l'OS une fois tout installé (clonage physique bit à bit sur une autre clé avec la commande dd). Quand et pas si ! la clé sera HS, il suffira de re-booter sur la sauvegarde pour retrouver l'ensemble opérationnel.
  • Disque dédié «virtualisation»: Ce disque peut avoir la taille qu'on veut. Il recevra les disques virtuels des VM et des containers.
    • Souplesse:Comme on choisi ici l'outil LVM, avec possibilité d'allouer dynamiquement de l'espace, ces disques virtuels pourront se voir allouer des espaces variés (en taille, en organisation/File System), ajustable au cas par cas et de façon dynamique, pour correspondre au mieux aux besoins des services qu'ils hébergent. De même LVM permet d'en faire des sauvegardes de façon souple.
    • Séparation: Cet espace dédié permet de bien séparer les services des données brutes, avec en tête une plus grande souplesse de manipulation, de même qu'une distinction d'usage. En effet, on créer, on supprime, on agrandit, on sauve «unitairement» un environnement virtualisé; le RAID dans un tel contexte semble moins indiqué, en termes de performance (écriture des informations de parité) et de sollicitations des disques.
    • Reprise: En cas de crash de ce disque, on en change, on restaure la sauvegarde des services, et on s’affranchit de la reconstruction lente et coûteuse d'un RAID, tout en conservant la main sur le serveur (pas d'impact sur l'OS, ni sur l'espace des donnée - cf. ci-dessous). Chaque service virtualisé peut posséder des données «statiques», qui pourront être stockée dans la zone de données RAID. Ces données-là sont ainsi pérennes, même en cas de rupture sur le service ou le disque qui l'héberge.

      Destiné à héberger les services de notre serveur donc, on peut envisager de mettre ici un disque SSD pour des questions de performances…
  • Le reste (de 3 à 7 disques selon le modèle de VHS): Les données «brutes», les plus sensibles, le patrimoine audio, vidéo, photo, documents de toutes natures vont là, en RAID 5 sur minimum 3 disques de même taille… Ces données sont ainsi «sécurisés» par le RAID 5 (on peut perdre un disque sans perdre de données), mais elle ne sont pas pour autant à l’abri.
    Allez, on le redit: «Le RAID n'est pas une sauvegarde !»…

Cette proposition diminue clairement la capacité de stockage par rapport au VHS initial: on perd en gros l'équivalent d'un disque.

Elle renforce l'aspect services et virtualisation, et leur «isolation» par rapport à la fois à l'OS et aux données.

Cette configuration n'est donc a priori pas indiquée si vos priorités sont «simplement» le partage de données sur le réseau, en volume (fonction d'un NAS à la base).

3.3. Installation - Configuration

3.3.1. Espace «OS»

Ça, c'est fait ;-), via l'installation sur clé USB qu'on vient de faire.

Plus loin et quand on aura fini d'y ajouter des fonctionnalités, on proposera une manipulation pour sa sauvegarde, à «garder au chaud»…

3.3.2. Espace «Virtualisations»

Nous réservons un disque complet pour recevoir l'ensemble des services virtualisés, qu'ils soient construits sous KVM, ou par des containers LXC ou Docker.

Ce disque n'a pas besoin d'être grand, même si cela dépend du nombre de services virtualisés que vous souhaitez.

  • Une VM typique (environnement de bureau) aura un disque virtuel de 10/30 Go
  • Un container LXC de base se réserve 1 Go par défaut
  • On considère que les données d'un outils virtualisé, si elles sont volumineuses et/ou précieuses, ne restent pas à l'intérieur de la VM ou du container mais pointent sur l'espace des données, sur les disques en RAID de plusieurs To.

On adopte ici un disque SATA de 250 Go qui suffit bien, au moins pour démarrer (et il traîne dans un vieux pc qui marche pu…).

On va mettre en œuvre ici LVM pour sa grande souplesse dans l'allocation et la sauvegarde des espaces, i.e. ici les disques virtuels de nos machines et services.

Le mode opératoire est décrit là: Gestion d'un disque avec LVM

3.3.3. Espace «Data»

Pour cet espace en RAID 5 dédié aux données, on va utiliser l'outil mdadm.

Une procédure de construction est décrite ici: Création RAID 5 - 3 disques. Elle illustre la mise en œuvre d'un… RAID 5 avec 3 disques m(.

Vous devrez l'adapter à votre environnement, pour les disques, leur position et leur nombre (sd[b,c,d,e,f,g,h]), de même si vous souhaitez un RAID 6 (4 disques minimum - –level=6 ), typiquement sur un VHS 8.

Après la mise en place du RAID, on dispose d'un répertoire /mnt/raid_data.
Maintenant il s'agit d'organiser cet espace.

  • L'organisation sur le VHS est celle-ci:
/mnt
└── data
    ├── data
    │   ├── datasys
    │   │   ├── apps
    │   │   ├── dbsBackup
    │   │   ├── mysql
    │   │   ├── printspool
    │   │   ├── tmp
    │   │   └── var
    │   ├── datausr
    │   │   ├── music
    │   │   ├── mysql
    │   │   ├── photo
    │   │   ├── public
    │   │   ├── shares
    │   │   ├── timemachine
    │   │   ├── tv
    │   │   ├── users
    │   │   ├── video
    │   │   └── www
    │   └── users
    │       ├── admin
    │       ├── intranet
    |       └── toto
    └── lost+found 

Je ne peux pas m’empêcher de penser qu'il y a un niveau de data de trop… Une boulette initiale chez Ve-Hotech, qui a perduré ??

  • On pourrait donc proposer quelque chose d'approchant:
/mnt
└── raid_data 
    ├── datasys
    │   └── < à définir >
    ├── datausr < juste reconduit pour l'instant... >
    │   ├── music
    │   ├── mysql
    │   ├── photo
    │   ├── public
    │   ├── shares
    │   ├── timemachine
    │   ├── tv
    │   ├── users
    │   ├── video
    │   └── www
    ├── users
    │   ├── admin
    │   ├── intranet
    │   └── toto
    └── lost+found 

On verra à l'usage si on garde et comment on rempli tout cela…

Dans l'immédiat, on peut commencer par créer un compte admin, notre utilisateur courant étant toujours install
Souvenez-vous: lors de l'installation du système sur la clé, on a recommandé de ne pas définir de compte root, et de créer un premier compte install qui hérite des droits d’administration via sudo. Ce compte dispose donc de son dossier dans /home/install sur la clé. Et on rappelle qu'il n'y a pas de place là-dessus…

  • On va donc créer le compte admin sur /mnt/raid_data/users/admin sur le système RAID:
     # adduser --home /mnt/raid_data/users/admin --shell /bin/bash admin 
  • Et on lui donne tous les droits (appartenance au groupe sudo):
     # adduser admin sudo


Si vous avez suivi les étapes jusqu'ici, et défini vos espace à l'identique, vous devriez, via la commande

lsblk -o name,model,type,size,fstype,state,mountpoint

obtenir un retour correspondant à ceci (vous pouvez cliquer pour zoomer):

Remarques:

  • On retrouve bien notre disque LVM pour la virtualisation en première position
  • On voit nos 3 disques – 1 WD, 2 IronWolf – de 4 To qui constituent le RAID 5
  • La clé avec le logo VHT (nommée DataTraveler) est due au modèle de VHS, avec dongle interne. A un moment, faudra quand même le débrancher…
  • La dernière clé est notre OS (installé en EUFI, peut-être pas une bonne idée… remettre en BIOS/Legacy ? FIXME )
  • Les plus observateurs vont noter des Volumes Logiques en lxc-xxx sur le premier disque qu'on a dédié à la virtualisation: c'est parce qu'on anticipe sur les § suivants… et voilà donc une excellente transition…:-D

4. Virtualisations des services

On va proposer ici plusieurs technologies de virtualisation pour notre cible :

  • Les containers LXC: ce sont des containers «système», dans lesquels on peut faire tourner ce que l'on veut, sous Linux (partage du noyaux de l'hôte);
  • Les containers Dockers sont orientés «application»: un service/une application par container en principe (on peut cependant tricher moyennant des trucs un peu lourds…);
  • Et bien sûr la virtualisation complète et plus lourde, avec un hyperviseur KVM permettant d’accueillir un OS complet tel que Windows® par exemple, et en simulant le matériel.

Rappel des différences d'architectures sur l'hôte sous forme schématique:

4.1. Containers LXC

Ce tuto définit de façon détaillée l'installation et la configuration d'un environnement LXC, pour la définition des containers LXC (LinuX Containers), qu'ils soient des containers (CT) dits «privilégiés» (depuis un compte root) ou de CT «non privilégiés» (depuis un compte banalisé).

Il est écrit pour notre contexte ici, mais il peut s'appliquer ailleurs, moyennant quelques adaptations sans doute, à la marge.

On utilisera plus loin cette «infrastructure» dans la mise en œuvre de certains services.

4.2. Containers Docker

A faire …FIXME

4.3. QEMU-KVM / libvirt

A faire …FIXME


5. Implémentations des services

Ce chapitre décrit le périmètre des services qu'on va héberger sur notre serveur .

On fera des liens vers les tutoriels de mise en œuvre associés. On va présenter les services proposés dans les «catégories» auxquelles ils appartiennent. On pourra retrouver ainsi ces tutos dans les rubriques correspondantes.

5.1. Service web

Les services web au sens où on l'entend ici sont des services accessibles via un navigateur – nécessaire pas forcément pour ce qu'ils font, mais au moins pour les piloter. Ils ont donc besoin pour fonctionner d'un serveur HTTP qu'on peut atteindre en remplissant une adresse URL dans les navigateurs.

L'expérience sur le VHS a montré que les mises à jour d'un serveur HTTP et sa configuration (Apache dans le cas du VHS) sont des aspects… sensibles:

  • Une version obsolète ne permet pas de faire fonctionner tel ou tel service
  • Une configuration est incompatible, un module manque
  • Le besoin pour un service n'est pas compatible pour maintenir le fonctionnement d'un autre
  • Peuvent s'ajouter d'autres outils qui rendent les choses plus complexes encore à maintenir: PHP et ses versions, un service / une application sous Django/Python, du Java JS2E côté serveur, du Tomcat, NodeJS, etc…

Dans ces conditions, l'idée qu'on propose ici consiste à positionner ce socle technique et logiciel nécessaire de façon isolée sur la machine hôte. Chaque service devient l'équivalent d'une machine serveur, plus ou moins dédiée, avec un ensemble d'outils qui peut ainsi lui être propre.

En gros, on va essayer ceci:

Évidemment, il s'agit de containers (CT) LXC: Multiplier des VM est trop consommateur en ressources et Docker se prête mal à des cibles complexes.

L'aspect de la sécurité est traité à plusieurs niveaux:

  • Un seul CT est exposé sur le LAN, via un NAT des deux seuls ports http[s]: c'est le CT proxy, charger de router les flux vers les bonnes cibles en fonction de l'URL. Il fonctionne en HTTPS/TLS avec Let's Encrypt.
  • Tous les autres CT sont isolés: pas besoin de https, ils ne sont visibles qu'entre-eux (et donc aussi du proxy) sur le réseau dédié des containers (en 10.0.3.x).
  • Tant que faire se peut, ils sont construits en mode «non privilégié». 8-O Ça c'est pas gagné, sauf sur le RAID, pas LVM… FIXME
  • Il faudra se définir des règles de pare-feu sur l'hôte: celles du VHS – réputées sévères – pourraient être récupérées.

Bon… ben… y a pu qu'à:


6. «IHM User Friendly»


1)
OUI jusqu'en v4.1.1, supprimées ensuite en raison de perfs trop médiocres
tuto/migrations/ub-2-deb.txt · Dernière modification: 12/11/2019 21:09 par Cram28