Je n'ai jamais réellement travaillé pour une entreprise qui déploie une application Django (avec une grande base d'utilisateurs), et je suis curieux de savoir quel est le meilleur moyen de le faire.
En ce moment, j'hôte une application Django sur EC2. Le code de l'application est assis sur mon compte Github. J'ai Nginx servant de contenu statique et derrière lui un seul serveur Apache exécutant Django + Mod_WSGI.
J'essaie de déterminer quelle est la meilleure pratique du "déploiement continu". En ce moment, après avoir ajouté des fonctionnalités supplémentaires, je fais ce qui suit sur EC2:
1) Tête de réinitialisation GIT --HARD
2) Git Tirez
3) redémarrez Apache
4) Redémarrez NGinx
J'ai une logique personnalisée dans mon fichier Paramètres.py de sorte que si je cours sur EC2, débogage est défini sur FALSE, et mes bases de données passent de SQLITE3 (Développement) à MySQL (Production).
Cela semble fonctionner pour moi maintenant, mais je me demande ce qui ne va pas avec ce processus et comment pourrais-je l'améliorer.
merci
4 Réponses :
J'ai travaillé avec des systèmes utilisant Tissu à déployer sur plusieurs serveurs
+1 tissu facilite la logique de déploiement et la maintient simple
On dirait que le tissu est la voie à suivre. Je vais vérifier ce week-end. Merci pour vos gars de votre aide (tout le monde ci-dessous inclus)
Je suis l'ancien développeur principal à The Texas Tribune , qui est 100% Django. Nous avons déployé sur EC2 en utilisant DroitsCale . Je n'ai pas personnellement écrit les scripts de déploiement, mais cela nous a permis d'obtenir de nouvelles instances dans la rotation très, très rapidement et des échelles à la demande. Ce n'est pas bon marché, mais valait chaque centime à mon avis.
Merci. Je vais vérifier cela aussi, bien que je cherche une solution gratuite si possible
Je suis d'accord avec John et dis que tissu est le Outil pour faire ce genre de chose confortablement. Vous ne voulez probablement pas configurer Git pour déployer automatiquement un crochet de messagerie, mais vous souhaiterez peut-être configurer une commande de tissu pour exécuter votre suite de test localement, puis appuyer sur la production si elle passe.
Beaucoup de personnes exécutent des fichiers de paramètres de développement et de production séparés, plutôt que d'avoir une logique personnalisée à détecter si elle est dans un environnement de production. Vous pouvez hériter d'un fichier unifié, puis remplacer les bits différents entre développement et production. Ensuite, vous démarrez le serveur à l'aide du fichier de production plutôt que de s'appuyer sur un seul paramètre unifié.py.
Si vous utilisez Apache pour héberger l'application, vous pouvez bénéficier d'une solution de poids plus légère. L'utilisation de FastCGI avec Nginx vous permettrait de supprimer entièrement les frais généraux d'Apache. Il y a aussi un module WSGI pour Nginx, mais je ne sais pas si c'est la production prête à ce stade.
Quel est l'avantage d'éliminer Apache entièrement? Je pouvais imaginer que cela pourrait accélérer les demandes car ils ne seraient pas redirigés vers un autre port via Nginx (peut-être)? J'ai eu l'impression que Apache est un produit beaucoup plus mature par rapport à Nginx, et c'est pourquoi les gens continuent à l'utiliser?
Apache est un produit plus d'argent, c'est pourquoi les gens continuent à l'utiliser. L'élimination des couches inutiles de votre pile est un bon moyen d'améliorer la vitesse, et côte à côte, Nginx Murders Apache pour des tâches qu'il peut faire. L'utilisateur configurable .htaccess est probablement la raison la plus fréquente que les gens gardent Apache. L'utilisation de la mémoire abaissée est une autre raison d'éliminer Apache.
De plus, si vous avez déjà NGinx dans votre pile, je ne suis pas clair sur le commentaire "Produit mature". Si Nginx échoue, ce n'est pas comme si Apache participera et prend la relève.
Il y a un plus bon moyen de gérer cela. Pour Ubuntu / Debian AMIS, il est bon de gester versions et de faire des déployants en pacquant votre application dans .deb
im en utilisant ubuntu? Je suis un peu confus sur les avantages de cela?
Je ne suis pas sûr de vous utiliser Ubuntu ou d'autres objectifs. La prestation peut être en gestion facile du code, vous pouvez gérer la fusion des options de configuration, gérer automatiquement les dépendances. Peut exécuter Pre / Post .. Installez les scripts pour la mise à jour de configurations / de la base de données, etc.
C'est une idée horrible. Ce n'est tout simplement pas la façon dont les gens déploient des projets Python et Django. Nous utilisons Pip et Virtualenv et Sud pour les migrations.
Je pense que cela dépend du projet, dans de nombreux cas, cela doit être fait dans le cadre du projet.
@Paulmcmillan Juste parce que c'est "tout simplement pas comment les gens déploient des projets Python et Django" ne signifie pas que c'est une idée horrible. Les attitudes élitistes telles que cela entravent les progrès, la discussion potentiellement productive et l'innovation.
@Codygman 2 ans plus tard, après avoir passé une année à faire de l'emballage de Python Debian pour le travail, je n'aime toujours pas le faire de cette façon (mais admettez mon commentaire précédent était trop dur). Il est peut-être approprié que le reste de l'infrastructure déployée a une configuration personnalisée dans les packages Debian, mais ce n'est pas idéal pour les déploiements individuels Python et je ne peux pas vous recommander de démarrer cette voie si vous avez un nouveau choix.