*Archivé*
= Meilleur service d'hébergement cloud ? =

Salut les gars, donc je veux déployer mon API backend Django mais pas en production, pour le développement. Quel est votre service cloud préféré pour faire cela ? Jusqu'à présent, j'ai trouvé le service Ngrok et Amazon AWS, et Jenkins et moi comprenons chacun en profondeur pour faire une comparaison. Je veux savoir d'après votre expérience, quel est votre service préféré

P.S : récemment, j'ai reçu une réponse très hostile pour mon manque d'expérience et pour avoir simplement essayé d'aider - Je vois ce sous-marin devenir lentement hostile et agressif comme d'autres sites Web (apparemment, le simple fait de mentionner les noms d'autres sites Web entraîne la suppression de votre message)

Veuillez donc excuser tout manque d'expérience que vous trouvez dans mon message (ou dans les futurs messages/commentaires)

EDIT : je ne m'attendais pas à autant de réponses, merci à tous pour votre réponse, je vais essayer de répondre à tout le monde

S'il est déployé sur un serveur distant, peu importe que ce soit pour la production ou non - la plupart des choses seront les mêmes. Pour un déploiement gratuit et relativement facile, essayez Pythonanywhere ou Heroku. Si vous voulez plus de contrôle, essayez Digital Ocean. J'ai écrit un guide (ce que je pense être assez complet) pour déployer votre
*première* application Django pour Digital Ocean ici

Oui, l'océan numérique est définitivement un joyau si vous voulez le contrôle, bien sûr que vous ne vous déploierez pas en une demi-minute, mais il est définitivement supérieur à la plupart des autres options si vous voulez plus de contrôle

Pythonanywhere semble répondre à mes besoins 90 % du temps, pas trop de contrôle, pas trop d'automatisation et de prise en main, quelque part entre les deux

J'ai une tonne d'expérience avec AWS Lambda et Django. Je ne peux pas penser à une seule bonne raison de faire Django sur AWS Lambda. Comme, pas une seule raison. Extrêmement compliqué pour si peu de retour, surtout lorsque vos dépendances deviennent même un peu plus que triviales. Vous ne voulez pas jouer au jeu d'optimisation des dépendances avec la limite de taille de fichier de 250 Mo. Si vous avez vraiment des problèmes d'évolutivité pour un projet Django, je dirais que la solution est probablement une combinaison d'ECS, de céleri et de cloudfront

Heroku est très facile à déployer, gratuit jusqu'à ce que vous atteigniez une certaine limite, pythonanywhere est le même mais un peu plus difficile car vous devez configurer certaines choses à la main, ce qui nécessite une compréhension de base des commandes Linux (rien d'avancé)

Les deux ont la possibilité de verrouiller le site à l'aide d'un mot de passe si vous ne voulez pas que les gens le visitent ou s'y connectent à moins qu'ils ne soient autorisés
J'utilise Heroku depuis quelques années. Ma base de données est le niveau gratuit de postgres. Cela fonctionne très bien et je paie un total de 7 $ par mois. Faites-moi savoir si vous avez des questions plus précises. Leur documentation est très bonne et j'ai eu des problèmes minimes. J'ai une URL personnalisée, https, le tout

Je déploie tous mes projets Django dans Google Cloud Run. Je l'aime vraiment

Voici comment je m'en sors :
Je commence par déployer ma base de données de développement dans Google Cloud SQL. J'utilise cette même instance mySQL cloud pour le développement local et la mise en scène et les tests cloud

** Développeur local, j'exécute 3 conteneurs Docker avec docker-compose :
- mon application Django. Le conteneur a nginx inclus. La base de données pointe vers le conteneur proxy SQL
- Image standard du proxy Google SQL. Nécessite un compte de service Google json

- conteneur phpmyadmin standard. Principalement pour dépanner mySQL
** Déploiement cloud. mise en scène et prod
- J'ai un fichier cloudbuild.yaml pour mon application Django. Cela décrit comment créer et déployer l'application Django sur Google Cloud Run

- Dans Google Cloud Run, j'ai défini un déclencheur pour créer/déployer mon application en fonction des commits git sur mon application. Cela lit le cloudbuild.yaml et automatise le déploiement de mes modifications dans le cloud

- J'ai défini toutes mes variables ENV dans les déclencheurs pour qu'elles soient transmises à cloudbuild.yaml et éventuellement aux instances Cloud Run. Bien sûr, ils diffèrent pour la mise en scène et la prod

**Pourquoi je l'aime**
- La configuration initiale n'est pas simple, mais l'automatisation qu'elle me donne est géniale

- Le coût des instances de développement est vraiment faible. Google Cloud Run ne facture que les secondes utilisées. Donc, quelques dollars par mois Maintenant, l'instance Cloud SQL est là où se situe le coût, car cela déclenche une machine virtuelle qui est toujours en cours d'exécution. Ceux à faible CPU descendent sous 10 $ / mois

- Pour vos instances de prod, vous bénéficiez de toute la puissance de Google Cloud Platform. Mise à l'échelle horizontale infinie (tant que votre application Web est sans état). Cloud Run évoluera automatiquement. Vous pouvez également faire évoluer Cloud SQL vers le haut et/ou horizontalement

- Google Cloud Run est fourni avec des points de terminaison http/https que vous pouvez mapper à votre domaine. Pas de soucis avec les configurations de certificats SSL. J'aime cela

Faites-moi savoir si vous êtes intéressé, je peux fournir plus de détails. Je pense maintenant que je devrais écrire un article détaillé sur la façon de le faire
Et voici mes dernières applications web Django, déployées dans Google Cloud Run
Si vous faites déjà des recherches sur les différents services d'hébergement cloud, il peut être judicieux de consulter Engine Yard. J'ai utilisé Engine Yard pour divers déploiements d'applications sur le cloud, et je dirais que c'est une plate-forme très dynamique et conviviale pour déployer vos applications sur le cloud
Engine Yard Cloud (EYC) est une plate-forme en tant que service (PaaS) largement préférée pour l'hébergement d'applications Ruby, Node et PHP. Il dispose d'une infrastructure robuste et entièrement gérée ainsi que d'un support de classe mondiale. Il dispose d'une infrastructure assez sécurisée et les correctifs sont tenus à jour pour votre commodité. Vous n'avez pas la charge de gérer la pile complète, y compris les bases de données et les équilibreurs de charge. Tout cela est pris en charge. Les sauvegardes se font automatiquement. À mon avis, Engine Yard est une plate-forme permettant d'économiser du temps et de l'argent

Vous pouvez également explorer Engine Yard Kontainers (EYK). C'est une plate-forme de nouvelle génération. Je l'ai essayé et j'ai trouvé que c'était une migration digne. Il prend en charge plusieurs piles, la mise à l'échelle automatique en temps réel et de nombreuses autres fonctionnalités. Vous pouvez rechercher à la fois Engine Yard Cloud et Engine Yard Kontainers

Je recommande d'utiliser App Platform sur Digital Ocean. Il est similaire à Heroku, mais fournit beaucoup plus de puissance pour une fraction des coûts Heroku

Il n'a pas toutes les fonctionnalités d'Heroku, mais au moins pour moi, il en a assez pour fonctionner

Je ne suis pas un DevOps, donc je ne sais pas comment configurer le Droplet normal de manière sécurisée. C'est pourquoi App Platform fonctionne beaucoup mieux - je n'ai pas besoin de penser à la perte de mesures de sécurité autres que dans mon application

Tous mes projets personnels sont regroupés dans des conteneurs docker et déployés dans un cluster kubernetes à nœud unique sur Scaleway.com. C'est plutôt cool et nécessite peu de maintenance, et si l'on atteint une certaine échelle, je peux facilement les déplacer vers un cluster plus grand ou un autre service de déploiement de conteneurs (comme ECS, ou même les déployer moi-même sur une instance avec seulement un runtime de conteneur installé )

Dans le passé, j'ai déployé un service Django sur AWS Lambda avec Zappa, mais vous perdez beaucoup de contrôle, et il y a quelques petites choses que vous devez apprendre et mettre en œuvre (par exemple, utiliser un framework sans serveur, gérer les versions, conserver votre lambdas "chaud", etc.).