search

Neighbook / Infrastructure

0 stars 1 forks source link

Définir un graphique global de l'infrastructure Azure : PaaS ou IaaS ? #1

Closed Beladric closed 1 year ago

Beladric commented 1 year ago

Bonjour @UTBM-FISA-TutoredProject/infrastructure,

Comme le titre l'indique il faut que l'on se décide sur plusieurs choses pour l'infrastructure. Pour commencer on peut déjà échanger sur les services que nous allons nous servir pour héberger le frontend et le backend.

Frontend : Le frontend sera théoriquement statique, donc est-ce qu'on l'héberge sur Github avec "pages" ou est-ce qu'on l'héberge sur Azure ? Si on l'héberge sur Azure, est-ce que l'on utilise des "resources" PaaS ou IaaS ?

Backend : Pour le backend la question d'où ne se pose pas, la question est quels sont les services que l'on va utiliser ?

Pour ceux qui se sont mis dans l'équipe infrastructure pour apprendre voici juste quelque notions de vocabulaire :

Image descriptive :

Saas, Paas, Iaas

Valentin271 commented 1 year ago

Je dirais que du PaaS est suffisant, on a juste besoin d'un runtime NodeJS, on a pas d'autres besoins particuliers.

Il faut aussi déterminer si on déploie la BD avec le back (via docker-compose par exemple) ou sur un serveur différent.

follyjohn commented 1 year ago

Hello,

Pour le front je suggère qu'on utilise Azure Static Web app (Peut étre intégré dans une offre SaaS via la market palce de Azure).

Le Back on en fait une image docker déployer soir avec Azure Container Instance ou Si on veut de la mise a l'échelle AKS; a voir ...

Une base de donnée Azure PostgreSQL ou CosmosDB PostgreSQL, ils sont tous deux auto-scallable et il n'est pas logiquement lier a l'image docker du backend.

Je pense qu' une offre Saas couvre tout le produit parce que nous concevons et mettons a jour la webapp (le front).

Beladric commented 1 year ago

Bonjour,

Merci pour les différentes réponses.

Frontend : Je suis partagé entre utilisé Azure static web app et Github pages. Au vu des spécifications de chacun je pense qu'il est plus adapté d'utiliser Github pages.

De surcroît, utiliser Github pages permettra de créer des workflow automatique directement trigger sur la branche main.

Backend : En ce qui concerne le backend, je te rejoins sur l'Azure Container Instance. Concernant, l'Azure Kubernetes Service c'est beaucoup trop pour le moment.

Base de données : On s'est pas encore décidé avec la classe sur quelle technologie de base de données relationnelle on va utiliser, je vais ouvrir une issue ou un sondage pour se décider. Quelque chose de sur c'est qu'on utilisera pas Cosmo DB qui est beaucoup trop pour la taille du projet 😄. Cosmo DB est bien pour les projets de très grande envergure, typiquement si le site internet regroupait des millions de personnes autours du monde on aurait un Azure Front Door avec des Statics web app dans chaque région et un Cosmo DB pour connecter toutes les DB entre les régions. Néanmoins une infrastructure de cette envergure dépasse largement les 200$ gratuit d'Azure.

Tarifs : Déjà juste pour le l'hébergement du container on serait à une 40$ par mois (en prenant en compte qu'il soit solliciter à fond 24h/24).

follyjohn commented 1 year ago

Bonjour,

Merci pour les différentes réponses.

Frontend : Je suis partagé entre utilisé Azure static web app et Github pages. Au vu des spécifications de chacun je pense qu'il est plus adapté d'utiliser Github pages.

De surcroît, utiliser Github pages permettra de créer des workflow automatique directement trigger sur la branche main.

Backend : En ce qui concerne le backend, je te rejoins sur l'Azure Container Instance. Concernant, l'Azure Kubernetes Service c'est beaucoup trop pour le moment.

Base de données : On s'est pas encore décidé avec la classe sur quelle technologie de base de données relationnelle on va utiliser, je vais ouvrir une issue ou un sondage pour se décider. Quelque chose de sur c'est qu'on utilisera pas Cosmo DB qui est beaucoup trop pour la taille du projet 😄. Cosmo DB est bien pour les projets de très grande envergure, typiquement si le site internet regroupait des millions de personnes autours du monde on aurait un Azure Front Door avec des Statics web app dans chaque région et un Cosmo DB pour connecter toutes les DB entre les régions. Néanmoins une infrastructure de cette envergure dépasse largement les 200$ gratuit d'Azure.

Tarifs : Déjà juste pour le l'hébergement du container on serait à une 40$ par mois (en prenant en compte qu'il soit solliciter à fond 24h/24).

Hello,

Les azure static web app supporte naturellment le deployment par github action aussi bine que le fait github page et meme crée des version differente déployer de la web app pour chaque version tagger par exemple.

Je voulais ajouter que Azure Static Web app permet de déployer des app en repo privé contarirement a github (du moins a vérifier) page mais je remarque que nos repos sont en public.

Ca reviens a utiliser aussi deux cloud provider.

Avec github page on a pas toute la stack insigth de Azure ...

ayoubqrt commented 1 year ago

Pour le frontend, je suggère très fortement d'utiliser Vercel. Il permet de se connecter au repo github, de deploy automatiquement suite au commit sur une branche. Il est facilement possible d'avoir plus environnements (prod, staging, dev). Il créé automatiquement lors de la création d'une pull request, un site pour preview la code de la PR. Tout ça gratuitement. Et même si c'était payant, c'est quand même un banjer

Beladric commented 1 year ago

Les azure static web app supporte naturellment le deployment par github action aussi bine que le fait github page et meme crée des version differente déployer de la web app pour chaque version tagger par exemple.

Cool c'est bon à savoir 😄 . Est-ce que l'Azure static web app supporte les routes de react router ?

Je voulais ajouter que Azure Static Web app permet de déployer des app en repo privé contarirement a github page mais je remarque que nos repos sont en public.

Effectivement c'est pas mal. Les repositories sont en public car on va ajouter des licences sur les repositories. Je vais ouvrir une issue auprès de tout le monde pour que l'on se mette d'accord sur une licence pour protéger le code.

follyjohn commented 1 year ago

Pour le frontend, je suggère très fortement d'utiliser Vercel. Il permet de se connecter au repo github, de deploy automatiquement suite au commit sur une branche. Il est facilement possible d'avoir plus environnements (prod, staging, dev). Il créé automatiquement lors de la création d'une pull request, un site pour preview la code de la PR. Tout ça gratuitement. Et même si c'était payant, c'est quand même un banjer

En effet ils challenge Azure Static Web app, va savoir si il a les outils de suivis comme insigth ...

follyjohn commented 1 year ago

Les azure static web app supporte naturellment le deployment par github action aussi bine que le fait github page et meme crée des version differente déployer de la web app pour chaque version tagger par exemple.

Cool c'est bon à savoir 😄 . Est-ce que l'Azure static web app supporte les routes de react router ?

Je voulais ajouter que Azure Static Web app permet de déployer des app en repo privé contarirement a github page mais je remarque que nos repos sont en public.

Effectivement c'est pas mal. Les repositories sont en public car on va ajouter des licences sur les repositories. Je vais ouvrir une issue auprès de tout le monde pour que l'on se mette d'accord sur une licence pour protéger le code.

Oui azure supporte les routes de react router, je ne suis dev react mais je deploie des web app react

Beladric commented 1 year ago

Pour le frontend, je suggère très fortement d'utiliser Vercel. Il permet de se connecter au repo github, de deploy automatiquement suite au commit sur une branche. Il est facilement possible d'avoir plus environnements (prod, staging, dev). Il créé automatiquement lors de la création d'une pull request, un site pour preview la code de la PR. Tout ça gratuitement. Et même si c'était payant, c'est quand même un banjer

Salut @ayoubqrt,

Merci pour la réponse, je ne connaissais pas Vercel c'est intéressant.

Néanmoins, le tiers gratuit est trop limitant (specifications vercel) au lieu de fixer une bande passante ils ont fixé le nombre de redirect qui je trouve est trop faible (1024 par projet) . Exemple une authentification "standard" peut contenir plein de redirection (OIDC presque 10) on arrive vite aux limites fixées dans Vercel.

De surcroît, Vercel ne propose pas la possibilité de faire des teams pour le tiers gratuit. Ce qui implique que c'est une seule personne qui aura accès au Vercel et qui devra le maintenir.

ayoubqrt commented 1 year ago

@follyjohn ils proposent des analytics mais j'ai jamais utilisé cette fonction donc aucune idée si c'est complet ou non

@Beladric bah si c'est 1024 redirects il y a pas de problèmes non ? Peux-tu m'éclairer sur le sujet, j'ai jamais été face à cette problématique.

A vérifier si on peut pas accéder aux logs si on est pas le créateur du projet mais si on peut y accéder je pense que c'est bon parce qu'il y aucune maintenance à faire vu que la seule chose à faire est de connecter le github au projet vercel

Beladric commented 1 year ago

@Beladric bah si c'est 1024 redirects il y a pas de problèmes non ? Peux-tu m'éclairer sur le sujet, j'ai jamais été face à cette problématique.

@ayoubqrt je me suis trompé c'est 1024 redirects à la suite donc ça ne pose pas de problème. J'ai cru que c'était 1024 redirects cumulés pour le projet ^^. Du coup, d'un point de vue purement technique Vercel est mieux. Seul problème c'est que l'on peut pas créer de team 😢, ça signifie que ce sera une seule personne qui maintiendra le Vercel.

Autre problème on devra avoir deux scripts Terraform, un pour le Vercel et un pour Azure.

ayoubqrt commented 1 year ago

Mais pour le front je vois pas qu'est-ce que tu veux faire comme infra pour le front. Pour moi c'est vraiment juste un build à faire avec une commande

Beladric commented 1 year ago

Mais pour le front je vois pas qu'est-ce que tu veux faire comme infra pour le front. Pour moi c'est vraiment juste un build à faire avec une commande

Oui je suis d'accord il y a juste un build et un deploy, néanmoins dans la bonne pratique il faut créer un script de déploiement de l'infrastructure. Là je parle de script pour déployer toute l'infra Vercel ^^.

ayoubqrt commented 1 year ago

Pour le back-end je suis d'accord avec toi parce que t'as plusieurs dépendances comme la DB et d'autres. Pour le front, tu n'en as pas, donc je c'est un peu overkill à mon goût de vouloir faire ça (que ça soit sur vercel, azure, aws ou n'importe)

Beladric commented 1 year ago

Pour le back-end je suis d'accord avec toi parce que t'as plusieurs dépendances comme la DB et d'autres. Pour le front, tu n'en as pas, donc je c'est un peu overkill à mon goût de vouloir faire ça (que ça soit sur vercel, azure, aws ou n'importe)

@ayoubqrt, oui je suis d'accord que c'est overkill au vu de la taille du projet. Mais étant donné que ça rajoute quasiment rien en travail autant en faire un, c'est beaucoup plus pro. Pour notre projet je suis d'accord que 20 minutes de non disponibilités n'est pas gênant ^^.

Personnellement ça me dérange pas du tout d'utiliser Vercel, même au contraire c'est mieux au vu des specs. Je dit juste qu'il faudra prévoir de faire un script pour Vercel en plus de celui d'Azure. ^^

@ayoubqrt sais-tu ou l'on peut trouver les SLA de Vercel ?

ayoubqrt commented 1 year ago

J'imagine que c'est ça que tu cherches ? https://vercel.com/legal/sla

Beladric commented 1 year ago

J'imagine que c'est ça que tu cherches ? https://vercel.com/legal/sla

Oui c'est ça 😄. C'est juste pour savoir s'il le fournissait notamment pour le rapport du projet comme ça on pourra calculer le SLA global de l'infrastructure.

@ayoubqrt du coup je vote aussi pour l'utilisation de Vercel pour le host du front 👍. Sur le papier c'est beaucoup mieux pour notre utilisation.

Beladric commented 1 year ago

@UTBM-FISA-TutoredProject/infrastructure,

Pour la base de données, avec @Valentin271 on a pensé à la mettre dans un conteneur comme pour le backend. Car l'Azure container instance facture pas au nombre de container, mais au nombre de groupe de container. Étant donné que l'on va déjà être facturé pour l'hébergement du backend et que l'offre de base est overkill pour notre utilisation, ça permettra de rentabiliser le service ce qui diminuera les coûts. De surcroît on aura moins de déploiement d'infrastructure à faire.

Valentin271 commented 1 year ago

Pour préciser un peu plus pour ceux qui connaissent, l'idée est d'utiliser docker-compose avec un service node et un service BD. Ca façiliterait la liaison back / BD, et ça réduirait les différences entre les environnements de dev et de prod.

Le docker-compose.yml ressemblerait un peu à ça.

version: "3"

services:
  php:
    image: "node:18"
    working_dir: /app
    volumes:
      - "./:/app"
    ports:
      - "8000:8000"
    command: "sleep infinity"

  database:
    image: "mysql"
    ports:
      - "3306:3306"
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: <passwd>
      MYSQL_DATABASE: <db_name>
yaminabes commented 1 year ago

@Valentin271 faudrait pas oublier le volume pour la db aussi

follyjohn commented 1 year ago

@Valentin271 ca marche bien ça quand tu code seul en local de mettre un service bd avec son volume dans la même image docker qu'un backend, mais pour une image docker qu'on déploie ça équivaut au fait à détruire les données de la plateforme à chaque mise à jour de l'image docker du backend. Déjà on déploie sur des service de conteneurisation pas sur des machines virtuelle donc à chaque déploiement tu perd ton volume ça aurais bien marché si on avais une machine virtuelle azure ça aurais fait sens. Si vous voulez je peux donner d'autre argument contre le fait de mettre un service BD dans la même image que l'image d'un backend qui sera déployé 😅.

yaminabes commented 1 year ago

Mais tu n’es pas obligé de mettre le volume dans la vm non? Quoi qu’il en soit tu ne peux pas juste mettre une bd dans un container car le bit du container c’est qu’on peut le détruire quand on veut. Donc si on ne fait pas de volume on perd tout à chaque deploy

follyjohn commented 1 year ago

Sauf erreur de ma part on a pas prévu d'utiliser des vm mais des services d'Azure qui permettent de déployer juste des images docker. Je ne dit pas mettre de bd dans une image docker au contraire pour moi il ne faut jamais mettre une bd dans une image docker. Azure a une panoplie de services de base de données : sql server, PostgresQl, Cosmos DB , ...

follyjohn commented 1 year ago

image De façon très simpliste un truc comme ça ou on sépare le back de la base de donnée

follyjohn commented 1 year ago

Mais en local il convient d'avoir un docker-compose de dev qui possede une bd, un volume pour la bd comme celui que @Valentin271 a proposé.

Valentin271 commented 1 year ago

@Valentin271 ca marche bien ça quand tu code seul en local de mettre un service bd avec son volume dans la même image docker qu'un backend, mais pour une image docker qu'on déploie ça équivaut au fait à détruire les données de la plateforme à chaque mise à jour de l'image docker du backend. Déjà on déploie sur des service de conteneurisation pas sur des machines virtuelle donc à chaque déploiement tu perd ton volume ça aurais bien marché si on avais une machine virtuelle azure ça aurais fait sens. Si vous voulez je peux donner d'autre argument contre le fait de mettre un service BD dans la même image que l'image d'un backend qui sera déployé sweat_smile.

Je suis entièrement d'accord avec toi si on veux faire ça il faut une vm et un endroit pour faire persister les données (c'était sous entendu).

Ceci dit, personnellement j'aurais opté pour une infra telle que tu as décris dans l'image (à l'exception du lien front back puisqu'il ne se fait pas entre 2 instances azures, mais entre un client quelquonque et le backend).

Dernier point sur cette architecture, je ne sais pas quelle est la difficulté à mettre en place une communication entre le back et la BD, c'est très facile avec 2 service container puisqu'ils sont sur le même sous réseau privé. En parlant de privé, je ne sais pas quel est le niveau de sécurité de la communication entre 2 instance.

follyjohn commented 1 year ago

@Valentin271 pour répondre a ton inquiètude concernant :

Ce sont des détails que je ne n'ai pas mis sur le schéma. Est c'est moyennement complexe a mettre en place.

Beladric commented 1 year ago

@follyjohn, @Valentin271, @yaminabes,

Je viens de lire l'échange. Pourquoi ne pas utiliser une virtual machine Azure à la place de container instance et un service pour la BD. J'ai simulé les coûts sur la calculatrice ça reviendrait beaucoup moins chère.

Prix d'un container instance : ~40$ Prix d'un service de BD: ~40$ Prix pour une VM sur laquelle on peut mettre les deux : ~20$

fichier d'estimation

Valentin271 commented 1 year ago

@follyjohn Parfait pour la liaison backend ! Et c'est noté pour la web app. Si c'est moyennement complexe j'imagine qu'on est capable de le mettre en place du coup.

@Beladric Vous êtes plus qualifiés que moi pour déterminer cela. Ceci dit si on utilise une VM il faut penser au stockage (je ne sais pas trop comment fonctionne cette partie).

Je soulève un point important selon moi, si on utilise une VM on peut aussi mettre le front dessus.

Beladric commented 1 year ago

Je soulève un point important selon moi, si on utilise une VM on peut aussi mettre le front dessus.

@Valentin271 pas faux, mais on va éviter de surcharger la VM surtout que le front peut être hébergé sur quelque chose de gratuit et prévu pour ^^.

Ceci dit si on utilise une VM il faut penser au stockage (je ne sais pas trop comment fonctionne cette partie).

@Valentin271 ça sera un simple ubuntu donc on peut installer ce que l'on veut dessus. Donc on pourra faire tourner un serveur SQL dessus.

follyjohn commented 1 year ago
Beladric commented 1 year ago

@follyjohn

Avec une VM pas de deployement continue

Effectivement c'est un inconvénient. Néanmoins, je pense que ça reste faisable, mais ça sera plus complexe. ça nous fera plus de travail au moins 😄 .

Avec une VM pas d' auto-dimentionnment des ressources

L'auto-dimensionnement c'est bien quand ça fait gagner de l'argent, là ça nous coûte 4 fois plus chère ^^.

Avec une VM on oublie Azure App registration

Je ne vois pas d'intérêt à l'azure app registration, la seule aurait été d'hébergé le serveur d'authentification dans l'AD. Sauf que le serveur d'authentification sera dans le backend.

Avec une VM plus de terraform ou de ARM pour déployer

Vraie et faux. La VM se déploie avec Terraform, ce qu'il y a à l'intérieur se déploiera avec des scripts shell.

Le problème du cloud (et pourtant je suis pro cloud ^^) est que les services sont adaptés tout de suite pour des gros projets. Dès que tu veux faire quelque chose de petit tu te retrouve avec des coûts exorbitant pour rien. Typiquement, si on part que sur des services Azure on tournerai autour de 80 à 100 $ par mois. Pour un simple site internet...

Au final si on regarde que d'un point de vu purement technique les services sont effectivement mieux. Mais si on prend en compte la contrainte financière alors ils sont largement à la traîne. À voir sur quoi on priorise 😃.

follyjohn commented 1 year ago

Il y a une ressource azure basé sur la techno des conteneurs qui coute moin cher taillé pour du dev et du test :

https://azure.com/e/56e402f0ce354ae686cb1c8ed29a17bc

ExportedEstimate (3).xlsx

Plus d'info : https://learn.microsoft.com/en-us/azure/container-apps/compare-options

Beladric commented 1 year ago

Il y a une ressource azure basé sur la techno des conteneurs qui coute moin cher taillé pour du dev et du test :

https://azure.com/e/56e402f0ce354ae686cb1c8ed29a17bc

ExportedEstimate (3).xlsx

Plus d'info : https://learn.microsoft.com/en-us/azure/container-apps/compare-options

Effectivement, je ne connaissais pas Azure Container Apps c'est super attractif 😃. J'ai regardé en détail la facturation et même si on utilise beaucoup ça restera gratuit ou alors ça sera des coûts dérisoires. Je suis partant pour utiliser Azure Container Apps pour l'hébergement du backend 👍.

En ce qui concerne la BD j'ai ouvert une issue dans le repository backend pour se décider de la techno. Une fois cette issue terminé on pourra se mettre d'accord sur le service de BD à utiliser et on pourra clore cet issue.

Beladric commented 1 year ago

Bonjour @UTBM-FISA-TutoredProject/infrastructure,

Conformément à ce qui a été voté dans le sondage, c'est PostegreSQL qui remporte la place de technologie de base de données qui sera utilisé.

Nous savons désormais quelles sont les services que nous allons utiliser pour l'hébergement du site, ❗ Je vais donc clore cette issue ❗.

Pour rappel :

Merci à tout ceux qui ont participé à cette issue 😄.