DEV Community: Nicolas KEMPF

Créez vos cartes interactives avec Vue.js et Leaflet

Nicolas KEMPF — Wed, 30 Dec 2020 15:56:31 +0000

Bonjour et bienvenue à tous sur ce tutoriel. Nous allons, au cours des prochains articles, apprendre ensemble à créer un site web permettant l’affichage d’une carte de nos restaurants favoris, le tout grâce au framework Vue.js et à Leaflet.

Introduction et Setup

Vue.js

Comme dit précédemment, nous allons utiliser Vue.js. Si vous ne le connaissez pas, il s’agit d’un framework Javascript open-source très populaire, qui tient la dragée à Angular et React. Je vous invite à aller vous renseigner dessus à cette adresse: https://vuejs.org/

Leaflet

Leaflet est une librairie Javascript permettant de créer des cartes interactives et customisables. Librairie très populaire, facile à utiliser, elle sera au centre de ce tutoriel. Il existe une version spécifique pour Vue.js: https://vue2-leaflet.netlify.app/

Générer le projet

npm install -g @cli/vue
vue create npmduprojet

Pour lancer le projet, on utilisera la commande:

npm run serve

Création de notre premier composant

Rendez vous tout d’abord dans le projet généré, et allez dans le dossier src/components et créez un nouveau fichier Vue. Appelons le map.vue
On le bind alors dans src/App.vue (cf exemple), avant de nous attaquer à remplir ce fichier map.vue.

<template>
 <div id="app">
   <Map/>
 </div>
</template>

<script>
import Map from './components/map.vue'

export default {
 name: 'App',
 components: {
   Map
 }
}
</script>

<style>
</style>

A partir de ceci, on va alors se demander ce que l’on veut voir s’afficher: Une carte bien sûr, puis des icônes s’affichant dessus à des coordonnées précises et chacune ayant son design propre ou ses propres informations lorsqu’on clique dessus… Commençons donc par afficher la carte.

Pour cela, nous allons donc utiliser Leaflet, qui va nous servir donc à effectuer le rendu d’une carte dans notre application. Les choses étant bien faites, il existe une version de Leaflet spécialement pour Vue.js: Vue2Leaflet. Nous allons donc installer via npm les librairies nécessaires. A vos lignes de commandes:

npm install --save leaflet
npm install --save vue2-leaflet

Il est très important d’installer Leaflet car il ne sera pas installé automatiquement lors de l’installation de vue2-leaflet. On s’exposerait alors à des troubles de fonctionnement assez évitables.
Voici les 3 éléments que nous allons utiliser et leur fonctionnement:
l-map: Le composant de base, contient tous les autres éléments et permet de gérer les principaux paramètres.
l-tile-layer: Contient l’url de la map, ainsi que des options telles que le niveau de zoom ou la position par défaut.
l-marker: Composant contenant les marqueurs qui apparaitront sur la map. Dans notre cas, le marker contiendra les icones des restaurants.

<template>
 <l-map
   :center="center"
   :zoom="zoom"
   class="map"
   ref="map"
   @update:zoom="zoomUpdated"
   @update:center="centerUpdated"
 >
   <l-tile-layer
     :url="url"
   >
   </l-tile-layer>
   </l-map>
</template>

<script>
import { LMap, LTileLayer } from 'vue2-leaflet';
import 'leaflet/dist/leaflet.css';

export default {
 components: {
   LMap,
   LTileLayer
 },
 data () {
   return {
     url: 'https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png',
     center: [ 49.1193089, 6.1757156 ],
     zoom: 12,
   }
 },
 methods: {
   zoomUpdated (zoom) {
     this.zoom = zoom;
     console.log(this.markers)
   },
   centerUpdated (center) {
     this.center = center;
   }
 }
}
</script>

<style>
 .map {
   position: absolute;
   width: 100%;
   height: 100%;
   overflow :hidden
 }
</style>

Dans cet exemple, on voit ainsi la configuration “de base” permettant l’affichage de la carte dans notre navigateur, sans ajouts de marqueurs.
Nous allons maintenant ajouter ce qui rendra notre carte unique: les l-marker. Comme expliqué plus haut, Ils seront placés sur la carte à des points précis afin, comme leur nom indique de marquer un emplacement. On les place juste après le l-tile-layer Voici ci dessous le code associé au design:

<l-marker
 :key="marker.id"
 :lat-lng="marker.coordinates"
>
</l-marker>

On rajoute également dans data():

markers: [
   {id: 1, coordinates: [ 49.114910, 6.178810 ]},
   {id: 2, coordinates: [ 49.133290, 6.154370 ]},
   {id: 3, coordinates: [ 49.102160, 6.158850 ]},
   {id: 4, coordinates: [ 49.136010, 6.199630 ]},
   {id: 5, coordinates: [ 49.105563, 6.182234 ]},
]

Comme on le voit, tout fonctionne et les marqueurs sont présents.
Satisfaits? Non? Il est vrai que le design de base laisse clairement à désirer. Heureusement, il est possible de le changer et de customiser les icônes de ces marqueurs afin qu’ils soient plus adaptés à ce qu’on veut leur faire montrer. Il est pour cela possible de créer une icône personnalisée. Afin de rendre notre code lisible et de pouvoir réutiliser ce qui sera l'icône de nos restaurants, nous allons créer un composant à part qui contiendra la future icône:

<template>
 <l-marker
   :key="marker.id"
   :lat-lng="marker.coordinates"
 >
   <l-icon ref="icon">
     <img class="restaurant-icon" :src="marker.imageUrl"/>
   </l-icon>
 </l-marker>
</template>

<script>
import { LIcon, LMarker } from 'vue2-leaflet'
export default {
 components: { LIcon, LMarker },
 props: {
   marker: {
     type: Object,
     required: true
   }
 }
}

</script>

<style>
 .restaurant-icon {
   height: 50px;
   width: auto;
 }
</style>

Ne pas oublier de l’appeler à la place du l-maker dans map.vue
On note la présence de l-icon: Ce composant permet de construire un composant Vue qui sera utilisé pour créer l'icône: Permet interactivité / code propre, voir de construire des icônes complexes (Plusieurs images qui se chevauchent, dynamisme). On peut également faire l’inverse et mettre le composant dans le l-icon afin de pouvoir réutiliser l’image icône dans un autre contexte, tout dépend des choix de développement. Dans le l-icon est précisée l'image qui lui sera associée, qu'on a définie dans les markers mis à jour:

markers: [
        {id: 1, imageUrl: 'https://img.icons8.com/doodle/48/000000/fish-food--v1.png', coordinates: [ 49.114910, 6.178810 ]},
        {id: 2, imageUrl: 'https://img.icons8.com/doodle/48/000000/pizza--v1.png' ,coordinates: [ 49.133290, 6.154370 ]},
        {id: 3, imageUrl: 'https://img.icons8.com/doodle/48/000000/croissant--v1.png', coordinates: [ 49.102160, 6.158850 ]},
        {id: 4, imageUrl: 'https://img.icons8.com/doodle/48/000000/the-toast--v2.png', coordinates: [ 49.136010, 6.199630 ]},
        {id: 5, imageUrl: 'https://img.icons8.com/doodle/48/000000/hamburger.png', coordinates: [ 49.105563, 6.182234 ]},
      ]

Et voici donc le design de notre application:

Vous pouvez retrouver l'intégralité du code de ce projet ici: https://github.com/Jorek57/VueLeaflet-Tutorial/tree/basic-map
Dans une seconde partie, nous apprendrons à créer des clusters d’icône, et à améliorer l’UX de notre carte!

De Laravel 5.5 à Laravel 8, j'ai manqué quoi?

Nicolas KEMPF — Tue, 22 Dec 2020 10:33:15 +0000

Suite à un projet client démarré en 2018 poursuivi sans montée de version, j'ai l'habitude de Laravel 5.5 et j'ai assez peu suivi les mises à jour du framework.

J'en profite pour faire un article avec les plus grandes nouveautés à ne pas manquer !

Changement de méthode de versionning

Traditionnellement, Laravel utilise une version sous la forme paradigme.majeure.mineure. Comme Taylor est satisfait par le paradigme actuel, il n'y aura plus de modifications comme nous l'avons connu lors des passages de Laravel 4 vers Laravel 5. Il était donc tout naturel de laisser de côté cette information. Laravel suit maintenant une notation de semantic versioning classique : majeure.mineure.patch.

Classes pour les channels

On a l'habitude d'utiliser un controller sous la forme de classe dans nos développements mais ce n'était pas encore possible pour les channels. C'est maintenant le cas !

Passage à Bootstrap 4 et transfert vers un package

Il n'y a pas grand chose à dire de plus sur ce point, le framework suit les mises à jour de Bootstrap et a séparé le système d'inscription / connexion dans un package composer à part. Il existe au choix une version Vue ou React.

Laravel Nova

Depuis Laravel 5.7, Nova est un dashboard d'administration créé pour Laravel et coûtant 99€ pour les développeurs individuels ou 199€ pour les agences. Cela permet de gagner un temps considérable lors du démarrage d'un projet compte tenu de l'omniprésence des panels d'administration.

Il est possible de personnaliser Nova et d'y ajouter des nouvelles fonctionnalités mais le produit n'est pas prévu pour être intégralement modifié. Il ne conviendra pas forcément à un besoin avec un design à intégrer.

Laravel Telescope

Nouvel outil de debug présent dans l'écosystème Laravel, Telescope permet de lister les requêtes de cache, les commandes exécutées, les évènements, les exceptions, les jobs, les e-mails, les modifications de modèles, les requêtes SQL et même es tâches planifiées !

Laravel Vapor

Nouveau produit créé par Taylor Otwell, il s'agit un système de déploiement de Laravel pour l'architecture serverless d'Amazon Lambda et l'interfacage avec les autres produits AWS.

Laravel Sanctum

Nouvel arrivant dans l'écosystème Laravel, Sanctum est un système d'authentification clef en main pour vos applications Webs et mobiles. C'est un bon compromis entre Laravel UI qui concerne uniquement les applications web avec une connexion par session et Laravel Passport qui est un serveur Oauth 2 à part entière.

CORS

Grand absent des middlewares de Laravel jusqu'à présent, il est maintenant possible de configurer le support des requêtes Cross Origin !

Laravel Jetstream

Encore un nouveau projet dans l'écosystème Laravel. C'est un template de démarrage tout en un avec connexion, inscription, vérification d'email, 2FA, session, Laravel Sanctum et même une gestion d'équipe optionnelle. C'est un produit réalisé avec Tailwind CSS et Blade / Livewire ou VueJS / Inertia.

Laravel Breeze, le nouveau starter officiel d'authentification avec Blade et Tailwind CSS

Nicolas KEMPF — Wed, 11 Nov 2020 19:22:17 +0000

Laravel Breeze est un package composer qui facilite le démarrage de nos projets en proposant un système d'authentification minimaliste qui utilise Blade et Tailwind CSS.

C'est l’un des deux projets teasés depuis quelques temps sans trop d'informations par Taylor Otwell avec Laravel Sail. À la différence de ce dernier dont on ne sait toujours rien, l'information est tombée hier, le projet est officiellement disponible sur github : https://github.com/laravel/breeze 🥳

Présentation de Laravel Breeze

Le package fait suite aux nombreuses critiques reçues par Laravel 8 qui a été perçu comme trop compliqué à cause de Laravel Jetstream.

Laravel Breeze est un scaffold avec les routes, les controllers, les form requests, les views, le style et les tests.

La grande nouveauté est que l'intégralité du package est publié dans votre code source. Il vous est donc possible de modifier tout ce qui concerne la logique, les vues et le style!

Il utilise uniquement Blade et Tailwind CSS ce qui en fait un choix parfait pour les personnes qui connaissent Laravel mais pas les autres technologies des scaffolds existants. Pour rappel, il existe déjà Laravel UI basé sur React ou VueJS et Laravel Jetstream qui utilise soit Blade + Livewire soit VueJS + InertiaJS.

Très concrètement, qu’est-ce qu’il y a dans Laravel Breeze?

Pour un package minimaliste, il est plutôt bien fourni ! Il contient un système complet de gestion d'utilisateurs avec l'inscription, la connexion, la récupération de mot de passe, la vérification d’email, la confirmation de mot de passe et la déconnexion.

Il est actuellement disponible en v0.0.4. On manque encore d'une réelle timeline sur sa sortie stable en 1.0.

Installation du projet

Dans un projet Laravel nouvellement créé, il est possible d'ajouter Breeze très simplement avec composer.

composer require laravel/breeze --dev
php artisan breeze:install

Quand le package sera disponible en version 1.0.0, il n'y aura plus besoin du flag --dev.

Laravel: les middlewares

Nicolas KEMPF — Fri, 08 May 2020 12:58:04 +0000

Aujourd’hui on va voir un élément clef de tous les projets web : les middlewares parfois appelés filters. Simples à comprendre pour les développeurs un peu aguerris, ils représentent une difficulté pour les débutants.

C’est quoi un middleware ?

Pour faire simple, ce sont des fonctions qui permettent d’enrichir ou de vérifier une requête avant qu’elle arrive à votre controller.

Plusieurs middlewares sont fournis de base avec Laravel comme auth pour autoriser l'accès à la route seulement aux requêtes liées à un utilisateur connecté.

Middlewares par défaut

Laravel inclut les middlewares suivant dans chaque nouveau projet Laravel :

Authenticate : renvoie une 401 si la requête ne contient pas d'Authorization
CheckForMaintenanceMode : Si l'application est en maintenance, vérifie si l'IP ou la requête est autorisée pour l'exécuter malgré la maintenance
EncryptCookies : Encrypte les cookies
RedirectIfAuthenticated : Redirige sur la route définie comme Home si la requête est un utilisateur connecté
TrimStrings : Trim chaque champ du body de la requête
TrustProxies : Liste des proxies qui envoie les requêtes à votre server
VerifyCsrfToken : Vérifie le token Csrf fournit par la requête

Le framework lui même en contient de nombreux autres :

AuthenticateWithBasicAuth
Authorize
EnsureEmailsVerified
RequiredPassword
AddQueuedCookiesToResponse
ConvertEmptyStringToNull
TransformRequest
ValidatePostSize
CheckResponseForModifications
FrameGuard
SetCacheHeadersd
SubstituteBindings
Throttle requests
ThrottleRequestsWithRedis
ValidateSignature
AuthenticateSession
StartSession
ShareErrorsFromSession

Créer votre middleware

Avec artisan, il est possible de créer votre propre middleware avec la commande :

php artisan make:middleware CheckAge

Pour Lumen, il est possible de créer directement le fichier dans app/Http/Middleware.

<?php
namespace App\Http\Middleware;
use Closure;
class CheckAge
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        if ($request->age <= 200) {
            return redirect('home');
        }

        return $next($request);
    }
}

Cette classe dispose d'une fonction handle qui sera appelé par le framework quand vous allez utiliser votre middleware. Le plus important est l'appel au callback next qui permet de continuer la requête.

Il est possible d'ajouter des paramètres à la fonction handle que vous pourrez définir quand vous l'appelerez.

‌`‌
<?php

namespace App\Http\Middleware;

use Closure;

class CheckRole
{
/**
* Handle the incoming request.
*
* @param \Illuminate\Http\Request $request
* @param \Closure $next
* @param string $role
* @return mixed
*/
public function handle($request, Closure $next, $role)
{
if (! $request->user()->hasRole($role)) {
// Redirect...
}

    return $next($request);
}

}
‌`

Une fois votre middleware créé, il ne nous reste plus qu'à l'enregistrer pour qu'il soit reconnu par Laravel.

Enregistrer votre middleware

En fonction de votre besoin, il existe plusieurs manières d'enregistrer votre middleware :

pour toute votre application
pour une seule route
dans un groupe de middleware

Enregistrer un middleware pour toute votre application

Pour qu'il se déclenche à chaque requête, il faut l'enregistrer dans l'attribut $middleware dans le fichier app/Http/Kernel.php.

Enregistrer un middleware pour une seule route

La liste des middlewares utilisable pour vos routes ou groupes de route se trouve dans l'attribut $routeMiddleware de la classe App\Http\Kernel. Elle prend la forme d'un tableau associatif où la clef est une chaîne qui va servir d'identifiant et la valeur est la classe de votre middleware.

Ensuite on peut l'utiliser directement lorsqu'on enregistre nos routes.

‌‌ Route::get('admin/profile', "MonController@fonction")->middleware('auth');‌

Il est possible d'utiliser le nom de la classe plutôt que la clé du tableau pour bénéficier de l'autocompletion.

‌‌ Route::get('admin/profile', "MonController@fonction")->middleware(CheckAge::class);‌

Il est également possible d'enregistrer plusieurs middlewares pour une même route.

‌‌ Route::get('/', function () {})->middleware('first', 'second');‌

Enfin, il est possible d'empêcher l'exécution d'un middleware d'un groupe pour une de ses routes.

‌`‌
Route::middleware([CheckAge::class])->group(function () {
Route::get('/', function () {});

Route::get('admin/profile', function () {})->withoutMiddleware([CheckAge::class]);

});
‌`

Enregistrer un middleware pour un groupe de requêtes

Dans le cas de middlewares que vous allez utiliser ensemble, il est possible de créer un groupe de middlewares dans la propriété $middlewareGroups. Il vous suffira ensuite d'appeler uniquement ce groupe pour appliquer tous ses middlewares.

C'est ce que fait Laravel par défaut avec les groupes web et api.

‌`‌
/**

The application's route middleware groups. *
@var array
*/
protected $middlewareGroups = [
'web' => [
\App\Http\Middleware\EncryptCookies::class,
\Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
\Illuminate\Session\Middleware\StartSession::class,
\Illuminate\View\Middleware\ShareErrorsFromSession::class,
\App\Http\Middleware\VerifyCsrfToken::class,
\Illuminate\Routing\Middleware\SubstituteBindings::class,
],

'api' => [
'throttle:60,1',
'auth:api',
],
];
‌`

Passer des arguments à votre middleware

L'ensemble des arguments se passe à votre middleware avec un : après l'identifiant du middleware. S'il y a plusieurs arguments, on les sépare par des ,.

‌‌ Route::put('post/{id}', function ($id) {})->middleware('role:editor');‌

Les revues de code

Nicolas KEMPF — Thu, 30 Apr 2020 10:17:24 +0000

Un outil pour améliorer la qualité de votre codebase.

Une revue de code ou code review consiste à vérifier les ajouts et modifications afin d’améliorer la qualité générale du code. L’objectif est de faire des retours ou commentaires en rapport avec :

la fonctionnalité implémentée : est-ce qu’elle respecte le cahier des charges ?
des oublis : un élément à rajouter ou du code inutile à supprimer
des choix techniques : conseils sur des alternatives, complexité du code, etc.
des guidelines propres au projet

Pour les modifications purement visuelles comme les espaces, le nommage des variables ou le fameux, il est recommandé d’avoir des commentaires ou corrections automatiques avec des outils comme phpcs ou php-cs-fixer

lien direct : https://xkcd.com/927/

Quand faire une revue de code ?

La revue de code se fait la plupart du temps à la fin du développement d’une fonctionnalité ou d’un correctif mais peut se faire dès que le code est mis en commun.

Les plateformes de versionning les plus connues intègrent directement des possibilités de revue de code. On retrouve cette fonction dans Github, Gitlab, Bitbucket, Azure DevOps, Phabricator. Dans le cas de systèmes ne le permettant pas, il existe des outils spécialisés comme gerrit qui s’intègrent directement à git.

Pour plus d’informations sur le sujet, Google a mis en ligne un ensemble de documents concernant les pratiques de leurs ingénieurs.

lien direct : https://xkcd.com/1513/

L’intérêt d’une checklist

En fonction de votre équipe, vous allez vite remarquer que certaines erreurs vont souvent revenir. Il peut être intéressant dans ce cas de créer une checklist que chaque reviewer pourra utiliser pour s’assurer de ne rien oublier.

Pour démarrer, je vous mets ci-dessous la checklist proposée par la New York University dans le cadre de son cours Effective Code Review et Software Carpentry, des projets pour apprendre les bonnes pratiques de programmation.

Général

Est-ce que le code fonctionne? Est-ce qu’il effectue son fonctionnement attendu, la logique est correcte, etc.
Est-ce que tout le code se comprend facilement?
Est-ce qu’il correspond à vos conventions de code? Cela comprend généralement la position des accolades, les noms de fonction et de variable, la taille des lignes, l’indentation, le format et les commentaires.
Est-ce qu’il y a du code redondant ou dupliqué?
Le code est-il aussi modulaire que possible?
Une variable globale peut-elle être remplacée?
Y-a-t-il des lignes de codes commentées?
Les boucles ont-elles une taille définie et une condition de fin correct?
Est-ce que les noms utilisés sont parlant et informent du sens de la variable ou fonction?

Performance

Y-a-t-il des optimisations évidentes pour améliorer la performance?
Est-ce qu’une partie du code peut être remplacé par une librairie ou une fonction du langage?
Reste-t-il du code concernant les logs ou le debug à supprimer?

Sécurité

Est-ce que toutes les données d’entrées sont vérifiées et encodées? Au niveau de leur type, taille, format et portée
Quand des utilitaires tiers sont utilisées, les retours d’erreurs sont-ils contrôlés?
Les valeurs de sortie sont-elles vérifiées et encodées?
Les valeurs incorrectes sont-elles gérées?

Documentation

Y-a-t-il des commentaires et décrivent-ils les objectifs du code?
Toutes les fonctions sont-elles commentées?
Y-a-t-il des comportements inhabituels ou des cas limites décrits?
Est-ce que l’usage et le fonctionnement des librairies tierces sont documentés?
Est-ce que les structures de données et les unités de mesures sont expliquées?
Y-a-t-il du code incomplet ? Si oui, doit-il être supprimé ou marqué avec un TODO ou un autre moyen?

Tests

Le code est-il testable ? Le code doit être structuré pour qu’il n’ajoute pas trop ou ne cache pas de dépendance, qu’il soit capable d’initialiser ses objets. Des frameworks de tests peuvent être utilisés, etc.
Des tests existent et sont-ils compréhensibles?
Est-ce que les tests unitaires vérifient réellement que le code effectue la fonctionnalité attendue?
Est ce que du code de test peut être remplacé par une API existante?

Publié sur https://www.nicolaskempf.fr/les-revues-de-code/

Installer Ghost avec docker-compose

Nicolas KEMPF — Sat, 28 Mar 2020 16:18:09 +0000

Aujourd’hui nous allons voir comment lancer un nouveau blog avec Ghost sur un VPS disposant de docker-compose. Les instructions sont les mêmes peu importe l’OS, c’est tout l’intérêt de docker.

Configuration de docker-compose pour Ghost

Créer un fichier docker-compose.yml avec le contenu suivant :

version: '2.3'

services:
    ghost:
        image: ghost:latest
        container_name: ghost
        hostname: ghost
        volumes:
        - ./config.production.json:/var/lib/ghost/config.production.json:z
        - ghost:/var/lib/ghost/content
        environment:
            NODE_ENV: production
            VIRTUAL_PROTO: http
            VIRTUAL_HOST: nicolaskempf.fr
            VIRTUAL_PORT: 80
            LETSENCRYPT_HOST: nicolaskempf.fr
            LETSENCRYPT_EMAIL: contact@nicolaskempf.fr
        restart: always
        networks:
        - nginx-proxy
        - ghost
        links:
        - mysql

    mysql:
        image: mysql:5.7
        container_name: mysql
        volumes:
            - db:/var/lib/mysql
        environment:
            MYSQL_ROOT_PASSWORD: ROOT_PASSWORD
            MYSQL_USER: nicolas
            MYSQL_PASSWORD: MY_PASSWORD
            MYSQL_DATABASE: ghost
        restart: always
        networks:
        - ghost
networks:
    nginx-proxy:
        external: true
    ghost:
        name: ghost

volumes:
    ghost: {}
    db: {}

J’utilise nginx-proxy et letsencrypt-nginx-proxy-companion pour faire le lien entre mes containers et mes noms de domaines.

Il est possible de faire fonctionner le blog sans proxy en ajustant un peu les propriétés :

version: '2.3'

services:
    ghost:
        image: ghost:latest
        container_name: ghost
        hostname: ghost
        volumes:
        - ./config.production.json:/var/lib/ghost/config.production.json:z
        - ghost:/var/lib/ghost/content
        environment:
            NODE_ENV: production
        restart: always
        ports:
        - "80:80"
        networks:
        - nginx-proxy
        - ghost
        links:
        - mysql

    mysql:
        image: mysql:5.7
        container_name: mysql
        volumes:
            - db:/var/lib/mysql
        environment:
            MYSQL_ROOT_PASSWORD: ROOT_PASSWORD
            MYSQL_USER: nicolas
            MYSQL_PASSWORD: MY_PASSWORD
            MYSQL_DATABASE: ghost
        restart: always
        networks:
        - ghost
networks:
    nginx-proxy:
        external: true
    ghost:
        name: ghost

volumes:
    ghost: {}
    db: {}

Configuration du container ghost

Pour Ghost, on fournir un fichier de configuration JSON avec les informations de la base de données.

{
    "url": "https://nicolaskempf.fr",
    "server": {
        "port": 2368,
        "host": "0.0.0.0"
    },
    "database": {
        "client": "mysql",
        "connection": {
            "host": "mysql",
            "port": 3306,
            "user": "nicolas",
            "password": "MY_PASSWORD",
            "database": "ghost",
            "charset": "utf8mb4"
        }
    },
    "mail": {
        "from": "'Nicolas KEMPF' <contact@nicolaskempf.fr>", 
        "transport": "SMTP",
        "logger": true,
        "options": {
            "host": "",
            "secureConnection": false,
            "auth": {
                "user": "",
                "pass": ""
            }
        }
    },
    "logging": {
        "transports": [
            "file",
            "stdout"
        ]
    },
    "process": "systemd",
    "paths": {
        "contentPath": "/var/lib/ghost/content"
    }
}

Si tout se passe bien, Ghost se lance et crée les tables nécessaires à son fonctionnement dans la db.

Au niveau de MySQL, il n'y a rien à faire, les variables d'environnement suffisent. Il est possible que vous aillez des erreurs au démarrage des services, le temps que mysql accepte les connexions. Pour le résoudre, il faudra ajouter un endpoint à ghost pour ne pas démarrer le conteneur tant qu'il n'arrive pas à se connecter à la db.

Si jamais vous rencontrez l'erreur suivante, il suffit de supprimer le volume db et recommencer :

ER_HOST_NOT_PRIVILEGED: Host '172.30.0.3' is not allowed to connect to this MySQL server

Une fois le démarrage terminé, votre site est accessible à l’url choisie. Il ne vous reste plus qu’à vous rendre sur /ghost pour créer votre compte administrateur.

Article publié sur https://www.nicolaskempf.fr/installer-ghost-avec-docker/