Poke-fu-mi est une application qui permet d'organiser des combats entre maîtres Pokémon mais les règles ne sont pas exactement celles du jeu classique.
-
En tant que joueur, je peux …
- m'inscrire à la plateforme avec un nom d'utilisateur unique.
- me connecter à la plateforme utilisant mon nom d’utilisateur et un mot de passe
- voir la liste de joueurs (avec leur score)
- voir la liste de matchs
- voir les détails d’un match: joueurs, Pokémons utilisés, etc
- inviter un autre joueur à un match (creer un match)
- consulter les invitations reçues
- accepter une invitation à un match (joindre un match existant)
- créer un deck pour un match
- envoyer un Pokémon à l’arena et consulter le résultat du combat (le joueur n'envoie pas un Pokémon en particulier mais envoie un deck, donc au moins un Pokémon, à l'arena)
-
En tant qu’administrateur, je peux …
- me connecter à la plateforme utilisant mon nom d’utilisateur et un mot de passe
- voir la liste de joueurs
- voir la liste de matchs
- effacer et modifier les joueurs et les matchs
- consulter les statistiques de la plateforme : nombre de matchs par jour, nombre de matchs par pokemon, nombre de victoires par pokemon, etc
TODO requirements :
- ajouter un service de statistiques générés à partir de log, avec kafka ou Elastic Stack.
A la racine des dossiers suivants : users-api
et match-api
ajouter des fichiers .env
comportant les informations suivantes :
DATABASE_URL="postgres://User:Password@Host.db.User.com/User?schema=public"
USERS_API_BASE_URL="http://localhost"
USERS_API_PORT="3000"
MATCH_API_BASE_URL="http://localhost"
MATCH_API_PORT="3100"
SECRET="an awesome secret for our token"
Pour DATABASE_URL
, on pourra utiliser des bases de données pgSQL proposées par le service suivant : ElephantSQL - PostgreSQL as a Service.
Si le schéma de la base de données est différent de celui indiqué dans les schémas de prisma, une erreur peut survenir. Dans ce cas on pourra remplacer la commande RUN npx prisma db push
par RUN npx prisma db push --accept-data-loss
dans les fichiers de configuration docker de users-api et de match-api, mais ceci écrasera les données existantes.
git clone https://github.com/reifocS/IMT-pokefumi-microservices.git
cd ./IMT-pokefumi-microservices
docker compose build
docker compose up
Des exemples de requêtes sont données pour être exécutées avec l'extension chrome Open Talend Api teste, Celles-ci sont disponibles dans le dossier test.
graph TB
subgraph Légende
A((Humain))
S_I{{Service interne}}
S_E[Service externe]
D[(Base de données)]
end
graph LR
%%variable
U((Utilisateur))
S_RP{{Reverse Proxy}}
S_U{{Service des profils<br/><br/>- Login, Logout<br/>- Gestion des decks}}
D_U[(pgSQL<br/><br/>- Profil<br/>- Deck)]
S_M{{Service des matchs<br/><br/>- Combat<br/>- Invitation}}
D_M[(pgSQL<br/><br/>- Match<br/>- Round)]
S_P[Service Poke-API]
%%relation
U ---> S_RP
S_U --- D_U
S_RP <--> S_U & S_M ---> S_P
S_M --- D_M
%%structure
subgraph Pokefumi Application
subgraph Internal Network
S_RP
S_U
S_M
end
D_U
D_M
end
Les bases de données utilisées étaient au départ en local avec SQLite mais comme ce type de base de données ne supporte pas les enumérations alors que ce projet est réalisé en TypeScript qui supporte cette puissante fonctionnalité, nous avons décidé d'utiliser des bases de données de type pqSQL.
sequenceDiagram
%%variable
actor U as Joueur
participant S_U as Service des profils
participant S_M as Service des matchs
%%sequence
U ->> S_U : Connection (Pseudo, Mot de passe)
activate S_U
S_U -->> U : Token (utilisateur)
deactivate S_U
U ->>+ S_M : Choix du deck pour un match (Deck, Match, Token)
S_M ->>+ S_U : Evaluation du deck (Deck, Token du joueur)
S_U -->>- S_M : Validation du propriétaire du deck
S_M -->>- U : Confirmation du choix du deck
- Le répertoire users-api contiendra le microservice pour répondre aux besoins de connexions et de gestion du profil utilisateur.
- Le répertoire match-api contiendra le microservice pour répondre aux besoins des matchs (e.g. matchmaking, combat).
- Le répertoire proxy contiendra les configurations pour le proxy.
- Les microservices, qu'est-ce que c'est ?
- Microservice Architecture — Learn, Build, and Deploy Applications - DZone Microservices
- Getting started with Prisma, the best TypeScript ORM | by Dries Augustyns | CodeX | Medium
- Database connectors | Prisma Docs
- Vidéo sur la comparaison d'un proxy et d'un reverse proxy
- Comparaison des méthodes de reverse proxing with nginx
- Comprendre le serveur Nginx et les algorithmes de sélection de blocs de localisation
- nginx.conf example
Pour exécuter des applications Windows et Linux sur des systèmes d'exploitation (OS) différents, il est nécessaire de répliquer l'environnement requis pour celles-ci. Pour se faire, deux méthodes existent : les machines virtuelles (VMs) et les conteneurs.
La comparaison de l'architecture de ces technologies montrent que pour exécuter des applications les VMs répliquent un OS indépendant et s'appuient directement sur le matériel informatique. Les conteneurs quand à eux permettent l'exécution d'applications sur l'OS hôte sans en répliquer d'autres, et s'appuient sur son kernel (noyau de l'OS hôte).
Par ailleurs, le développement, le déploiement et la gestion des applications des conteneurs sont plus simples pour les conteneurs que pour les VMs.
Dans le cadre de ce projet de microservices, une isolation totale avec des ressources garanties n'est pas nécessaire, ainsi on préfèrera la technologie des conteneurs. L'outils permettant de gérer les configurations de conteneurs le plus utilisé est Docker.
- introduction
- réseau
- debbuging
Executer les commandes suivantes à la racine du répertoire
docker compose build
docker compose up
Un petit exemple :
FROM node:17.0.1
WORKDIR /match-api/
# dependencies
COPY . .
RUN npm install
# database
COPY prisma prisma
RUN npx prisma db push
RUN npx prisma generate
CMD ["npm", "run", "build-start"]
EXPOSE 3100
Chaque instruction crée une couche :
FROM
pour créer une couche à partir de l'image Dockernode:17.0.1
.WORKDIR
pour définir le répertoire de travail.COPY
pour ajouter des fichiers depuis le répertoire courant (répertoire pouvant être défini par le docker-compose.yml) dans le dît répertoire de travail du client Docker (les fichiers du .dockerignore ne seront pas copiés).RUN
pour préparer l'environnement.CMD
pour spécifier une commande / un script à exécuter dans le conteneur afin de lancer l'image construite.EXPOSE
pour informer sur quel port l'application écoute.
docker build -t matchs:v1 .
docker run --publish 5000:3000/tcp matchs:v1 # permettant d'autoriser le transfert des requêtes sur le port `5000` de l'hôte vers le port `3000` du conteneur.
docker compose build # à faire que si l'on modifie les dockers files
docker compose up # start et monopolisation du shell (on Ctrl+C avant de relancer le shell), la monopolisation peut être empêchée avec --detach
docker compose start # start et rend la main sur le shell après (on peut restart facilement)
docker compose restart # docker compose stop + docker compose start (nécessaire pour mettre à jour l'architecture docker)
Commands | Purposes |
---|---|
docker ps |
List running containers |
docker images |
List local images |
docker rmi <ImageName> |
Remove an image from local registry |
docker pull [ImageName:tag] |
Download an image from registry (docker hub) |
docker exec -it <ContainerId> bash |
Access running container (command line) |
docker stop <ContainerId> |
Stop a running container |
docker network ls |
List all the networks the Engine daemon knows about |
docker network inspect <NetworkName> |
Return information about the selected NetworkName network |