L'hébergement Docker pour les applications que votre panneau ne livre pas
Un site en conteneur exécute une image qu'un administrateur a approuvée, sous le compte propre du site, sans privilèges et avec un système de fichiers racine en lecture seule. C'est ainsi que vous hébergez quelque chose écrit dans un langage que ce serveur n'installe pas.
Quand y recourir
Quand l'environnement d'exécution dont vous avez besoin n'est pas au menu.
Le statique, PHP et Node.js couvrent l'essentiel de ce que les gens hébergent, et ils n'exigent ni image ni approbation. Un site en conteneur est pour le reste : un langage que ce serveur ne livre pas, une bibliothèque système dont une application a besoin, un service qui arrive sous la forme de sa propre image de base.
C'est aussi la réponse à « puis je exécuter cette seule chose » sans transformer le serveur en machine qui exécute n'importe quoi. La liste de ce qui peut s'exécuter est une liste, et quelqu'un a décidé de son contenu.
Approuver une image
Un administrateur l'ajoute, avec une étiquette explicite.
Rien ne peut s'exécuter comme site en conteneur avant qu'une image ne soit ajoutée. Sous Images de conteneur, un administrateur en approuve une, et chaque entrée exige une étiquette explicite, jamais latest, pour que la version qui s'exécute ne puisse pas changer sous vos pieds. Une recompilation en amont ne devient pas silencieusement un déploiement ici.
C'est volontairement l'affaire d'un administrateur plutôt que d'un client. Une image est du code qui s'exécute sur la machine, si bien que ce qui peut s'exécuter est une décision du propriétaire du serveur, et un champ de texte libre en ferait une décision de quiconque y possède un compte.
Ce qu'un conteneur peut faire
Moins que vous ne pourriez le croire, et c'est voulu.
- Aucun privilège, et un système de fichiers racine en lecture seule. Une image qui s'attend à installer des paquets au démarrage ou à écrire partout dans son système de fichiers devra être adaptée.
- Ses limites de mémoire, de processeur et de processus sont appliquées par Docker, à partir du même quota que celui du site.
- Il n'atteint le réseau qu'à travers le serveur web, sur un port qui lui est propre. Rien ne l'expose directement.
- Il s'exécute sous le compte propre du site, comme tous les autres environnements d'exécution ici, si bien que les murs entre les sites sont les mêmes murs.
- Seul
/datasurvit à un redémarrage. Les fichiers téléversés, les fichiers générés, une base SQLite, un cache qui mérite d'être conservé : tout cela se place sous/data.
Ce dernier point surprend ceux qui ont exécuté la même image ailleurs sans y réfléchir, car un conteneur de longue durée masque le problème jusqu'à ce que quelque chose le redémarre. Considérez le conteneur comme jetable et /data comme le seul plancher sur lequel vous pouvez vous tenir. Enregistrer une modification remplace le conteneur en cours d'exécution, si bien que la règle s'applique un après midi ordinaire et pas seulement après un plantage.
Tout le reste est le même site
Un site en conteneur est un site, pas une exception.
Il a un domaine et un certificat gratuit. Il peut avoir des boîtes aux lettres, des enregistrements DNS, des tâches planifiées et des sauvegardes. Les variables d'environnement se modifient sous la forme des lignes qu'elles deviennent, un nom et une valeur par ligne, si bien que ce que vous voyez est ce que le conteneur reçoit, et une base de données créée pour le site s'atteint de la même façon que depuis n'importe quel autre environnement d'exécution.
Et c'est un environnement d'exécution comme les autres : un site peut y être déplacé et en être retiré sans être reconstruit, en gardant ses fichiers, ses noms et son certificat.
Vos serveurs, sans que rien de ce qu'ils portent ne soit compté.
Le panneau entier est gratuit sur un serveur, sans limite de sites, de boîtes aux lettres, de zones DNS ou de comptes clients. Pro, jusqu'à cinq serveurs, n'est pas encore disponible.