Ghost est une plate-forme CMS open source légère, rapide et axée sur la création d'un site Web d'adhésion.
Vous pouvez toujours opter pour l'hébergement géré par Ghost lui-même. Mais comme il s'agit d'un logiciel open source, vous êtes également libre de l'héberger sur votre propre serveur et de le gérer vous-même.
Grâce aux services cloud comme Linode et DigitalOcean, le déploiement d'un nouveau serveur Linux avec Ghost installé devient une question de quelques clics.
Linode | Le cloud ouvert indépendant pour les développeursNotre mission est d'accélérer l'innovation en rendant le cloud computing simple, abordable et accessible à tous.
Linode 
Bien que le déploiement de Ghost sur des serveurs cloud soit une tâche relativement plus simple, la gestion de Ghost n'est pas toujours aussi simple.
Nous gérons notre instance Ghost pour héberger Linux Handbook depuis plusieurs mois maintenant. Et cette expérience nous a appris plusieurs choses que vous ne trouverez probablement pas dans la documentation officielle de Ghost.
Dans cet article, je vais parler de certains facteurs cruciaux à prendre en compte avant de déployer votre blog alimenté par Ghost sur des serveurs de production.
Gardez à l'esprit que cet article concerne l'image Docker de Ghost, construite et gérée par la communauté des développeurs.Dans la communauté DevOps, ce à quoi nous nous efforçons toujours, c'est de nous rapprocher le plus possible d'un état appelé NoOps. Mais dans la pratique, cela restera toujours un paradoxe.
Ici, nous essayons d'atteindre le même objectif que NoOps mais avec une vision hybride avec une intervention humaine chaque fois que nécessaire.
Alors sans plus tarder, permettez-moi de vous enrôler et de vous décrire les éléments essentiels pour assurer une instance Ghost stable et avec un minimum de maintenance.
1. Définissez correctement votre configuration de messagerie
Vous suivrez des types d'e-mails destinés à vos membres et abonnés via votre instance Ghost :
- E-mails transactionnels :pour les connexions des membres, la confirmation d'inscription, etc.
- E-mails en masse :pour l'envoi d'une newsletter par e-mail via Ghost
Si vous ne souhaitez pas envoyer de newsletters via Ghost, vous pouvez utiliser n'importe quel service SMTP. Sinon, vous devez utiliser Mailgun.
Paramètres SMTP pour les e-mails transactionnels
En théorie, votre instance Ghost devrait pouvoir utiliser le service de publipostage grâce à Nodemailer.
Cependant, cela peut entraîner l'échec de certaines inscriptions avec le message d'erreur "Veuillez entrer une adresse e-mail valide".
C'est pourquoi vous devez configurer les paramètres SMTP avec Mailgun ou Amazon SES. Vous pouvez également essayer d'autres services de relais de messagerie tels que SendGrid ou Mailchimp.
Un paramètre SMTP typique, configuré via Mailgun se présente comme suit (défini via un fichier monté sur liaison config.production.json ):
"mail": {
"transport": "SMTP",
"options": {
"service": "Mailgun",
"host": "smtp.eu.mailgun.org",
"port": 465,
"secureConnection": true,
"auth": {
"user": "replace-me-with-a-mailgun-configured-email-address",
"pass": "replace-me-with-the-relevant-mailgun-apikey"
}
}
},Gardez un œil sur le numéro de port SMTP . Parfois, les e-mails échouent à cause du numéro de port. Dans notre cas, certains e-mails échouaient avec le port 587 et commençaient à fonctionner avec le port 465.
Veuillez consulter cette documentation de Mailgun ici pour des informations complètes sur la vérification de votre domaine et la mise à jour des enregistrements DNS nécessaires qui sont également requis pour l'envoi d'e-mails.
En général, vous devez mettre à jour les enregistrements MX, CNAME et TXT obtenus auprès de Mailgun dans les paramètres d'enregistrement DNS de votre panneau de nom de domaine. Sur Linode, ils ressemblent à :
E-mails en masse pour l'envoi de newsletters
Pour envoyer des newsletters en masse à vos membres, Mailgun est le seul service disponible pour l'implémenter dans votre configuration Ghost. Les services de messagerie en masse sont assez différents des services SMTP conventionnels.
Pour configurer correctement les e-mails en masse sur Ghost pour vos membres, vous devez d'abord vous assurer que les abonnements sont activés. C'est une exigence évidente.
Faites maintenant défiler jusqu'à la section e-mail et développez "Paramètres de la newsletter par e-mail".
Entrez le nom de domaine et la clé API configurés par Mailgun. La région de Mailgun serait soit "EU" soit "US". Veuillez choisir celui qui convient.
Si vous vous souvenez d'en haut dans l'exemple des paramètres SMTP, le nom de la région, "EU" peut être perçu avec le nom de l'hôte, qui est smtp.eu.mailgun.org .
Lisez ici pour plus d'informations sur le nom de domaine et la clé API configurés par Mailgun. Pour choisir des noms de domaine, cliquez ici.
2. Choisissez MySQL ou MariaDB pour la base de données au lieu de SQLite
Si votre blog Ghost est prévu pour une utilisation en production, je vous recommande de ne pas utiliser la base de données SQLite fournie par défaut dans le conteneur Ghost.
La raison d'utiliser la base de données recommandée comme MySQL ou MariaDB est extrêmement cruciale lorsque vous avez un nombre important de membres et que vous souhaitez leur envoyer une newsletter par e-mail depuis Ghost lui-même.
Nous l'avons appris à nos dépens. Au départ, nous utilisions MailerLite pour créer et envoyer la newsletter. Ensuite, nous avons décidé de profiter de la fonction de newsletter intégrée de Ghost.
A cette époque, nous avons environ 1 100 membres. Et cela a créé un problème car SQLite ne pouvait pas gérer ces nombreuses requêtes à la fois. Le message nouvellement créé n'a pas pu être envoyé. Les journaux ont affiché cette erreur :
Processed job threw an unhandled error
"The email service was unable to send an email batch."
Error ID:
24bf8000-4f50-11eb-adf5-73dcc562a630
Error Code:
SQLITE_ERROR
Ce n'était pas ça. Il a même refusé d'exporter 1100 membres. Le téléchargement ne démarrerait tout simplement pas. Nous avons téléchargé l'intégralité de la sauvegarde au format JSON et extrait les informations sur les membres à partir de là.
Pour résoudre ce problème, migrez de SQLite vers MySQL ou MariaDB, ce qui deviendrait une surcharge inutile et entraînerait des temps d'arrêt potentiellement indésirables pendant la migration, qui pourraient même durer une durée indéfinie. Il est donc toujours préférable de déployer initialement Ghost avec MySQL ou MariaDB à titre préventif.
Voici un exemple de configuration typique de service de base de données MariaDB pour Ghost sur Docker Compose :
db:
image: mariadb:10.5.3
volumes:
- ghostdb:/var/lib/mysql
restart: on-failure
environment:
MYSQL_RANDOM_ROOT_PASSWORD: 1
MYSQL_USER: rename-me
MYSQL_PASSWORD: replace-me
MYSQL_DATABASE: rename-me3. Activer la rotation des journaux
La rotation des journaux est le processus de réinitialisation automatique de vos fichiers journaux après une période de temps souhaitée. Cela permet d'éviter la création d'énormes fichiers journaux qui s'accumulent et envahissent inutilement l'espace disque de votre serveur. En pratique générale, si vous n'incluez pas l'extrait de code suivant dans votre configuration Ghost, les fichiers journaux s'accumuleront jusqu'à des tailles énormes entre 15 et 20 Go ! :
"logging": {
"path": "content/logs/",
"level": "info",
"rotation": {
"enabled": true,
"count": 15,
"period": "1d"
},
Pour un aperçu détaillé de la connexion à Ghost, vous pouvez visiter sa page de documentation pertinente.
3. Utiliser le proxy inverse
C'est toujours un avantage supplémentaire d'utiliser un proxy inverse dès le début, avant de déployer Ghost. Cela facilite grandement la gestion de vos applications Web à court et à long terme.
Comment utiliser le proxy inverse Nginx avec plusieurs applications DockerDécouvrez comment vous pouvez déployer plusieurs services Web sur le même serveur à l'aide du proxy inverse Nginx et des conteneurs Docker.
Manuel LinuxDebdut Chakraborty 
4. Mettez à jour Ghost sans temps d'arrêt
Si vous utilisez un proxy inverse, la mise à jour de votre instance Ghost sans temps d'arrêt sera une tâche facile.
Voici ce que je recommande. Configurez Docker Notify pour être averti d'une nouvelle image Docker de l'instance Ghost (avec la dernière version de Ghost).
Ensuite, vous pouvez suivre ce tutoriel pour mettre à jour votre conteneur Docker.
Mise à jour des conteneurs Docker avec zéro temps d'arrêtUne méthodologie étape par étape qui peut être très utile dans vos activités DevOps quotidiennes sans sacrifier un temps de disponibilité inestimable.Manuel LinuxAvimanyu Bandyopadhyay 
Heureusement, il n'y a absolument aucun temps d'arrêt lorsque vous effectuez la mise à jour. Si vous êtes déjà connecté au panneau d'administration (par exemple lors de la rédaction d'un article), vous ne remarquerez aucune anomalie.
Cependant, si vous n'êtes pas connecté, jusqu'à ce que vous supprimiez l'ancien conteneur après la mise à jour, le panneau d'administration continuerait d'essayer de se charger si vous essayez une nouvelle connexion.
Mais dans un sens de production, le blog Ghost lui-même continuerait d'être disponible sur le front-end même pendant que vous effectuez la mise à niveau.
6. Définissez toujours une politique de redémarrage
Puisque vous utilisez un conteneur Ghost Docker, une politique de redémarrage est toujours très importante et nécessaire à spécifier dans votre configuration. Cela garantit que votre conteneur Ghost redémarre toujours de lui-même chaque fois que votre serveur physique a été redémarré en raison d'un événement de maintenance.
Si votre configuration Docker générique a activé la restauration en direct, il est recommandé d'utiliser le on-failure politique de redémarrage. Pour mieux comprendre les politiques de redémarrage, veuillez consulter la documentation officielle pour une référence complète sur ces politiques.
En règle générale, vous définissez une telle politique de redémarrage dans le service de votre fichier Docker Compose comme :
restart: on-failure
Manuel LinuxAbhishek Prakash 
7. Utiliser des volumes Docker externes
Si vous utilisez des volumes qui ont été créés manuellement avant de déployer Ghost, cela facilite la migration de votre contenu (au sein du même serveur ou d'un autre) si nécessaire à l'avenir. Cela vous donne plus de contrôle sur vos données puisque c'est vous qui créez et spécifiez le volume à utiliser par le conteneur Ghost. Sinon, vous devrez laisser Docker Compose le créer localement.
Pour créer un volume Docker externe pour le conteneur Ghost, utilisez la commande suivante :
docker volume create ghost
Où ghost est le nom de votre volume Docker Ghost externe.
Comme j'ai déjà mentionné opter pour une base de données MySQL ou MariaDB pour assurer de meilleures performances avec des milliers d'utilisateurs, son volume doit également être créé de la même manière :
docker volume create ghostdb
Où ghostdb est le nom de votre volume de base de données Docker Ghost externe.
Pour demander à Docker Compose d'utiliser ces volumes spécifiques que vous venez de créer ci-dessus, notre section de volumes dans le fichier Docker Compose doit ressembler à :
volumes:
ghost:
external: true
ghostdb:
external: true
Notez comment j'ai spécifié que ces volumes Docker sont de nature externe.
Astuce bonus :planifiez des sauvegardes régulières
Si vous utilisez Linode, Digital Ocean ou tout autre fournisseur de serveur cloud similaire, il est fortement recommandé de toujours activer les sauvegardes lorsque vous créez votre serveur pour déployer Ghost.
Par exemple, lorsque vous créez un serveur avec 1 Go de RAM (appelé nanode) sur Linode, vous trouverez une case à cocher qui demande d'activer les sauvegardes. Chaque fois que vous déployez un serveur de production, je vous recommande toujours de l'activer avant de procéder à l'initialisation du serveur pour le premier démarrage.
De plus, vous pouvez déployer un script sur le serveur basé sur un crontab pour prendre manuellement un instantané de vos volumes Docker externes pour Ghost.
Techniquement, les données de volume telles que discutées dans le pointeur 7 précédent, en particulier ghost et ghostdb , résident localement dans /var/lib/docker/volumes/ghost/_data et /var/lib/docker/volumes/ghostdb/_data respectivement. Pour les archiver efficacement, vous pouvez utiliser tar pour sauvegarder périodiquement ces deux répertoires.
Puisque vous sauriez maintenant quand ces tar les archives seraient facilement disponibles après l'archivage, vous pouvez également déployer un autre script sur votre système local (supposé être exécuté en direct à une heure précise sur une base quotidienne à votre domicile/bureau) pour ssh dans le serveur Ghost et récupérer ces archives. De cette façon, vous aurez toujours une copie mise à jour localement de votre blog Ghost disponible avec vous, quel que soit l'accès à Internet.
Alternativement, vous pouvez également utiliser l'approche de sauvegarde logique pour sauvegarder la base de données MySQL avec la commande de base de données mysqldump. Sur MariaDB, la commande s'appelle mariadb-dump qui n'est rien d'autre qu'un lien symbolique vers le même mysqldump commande.
Une excellente comparaison entre les sauvegardes physiques et logiques peut être trouvée ici.
Apprivoiser le fantôme
Il s'agissait d'une compilation de diverses approches pour minimiser et empêcher tout problème de maintenance potentiel de se produire après le déploiement de votre instance Ghost. J'espère que cela vous sera utile chaque fois que vous lancerez ou utiliserez votre propre blog sur Ghost.
Nous continuerons notre voyage avec Ghost et si nous rencontrons un autre problème qui aurait pu être évité avec une configuration différente lors du déploiement, nous mettrons à jour cet article.
Si vous avez des suggestions concernant les pointeurs discutés ci-dessus ou si vous en avez de nouveaux, veuillez les partager avec nous dans la section de conversation ci-dessous. Nous serions ravis de vous lire et d'en savoir plus.