Par contre si tu fais un article complet sur une stack déployée avec docker (et tant qu’on y est du ansible et du jenkins), alors carrément.

Peut être que le tout VM peut résoudre ça.

Bah maintenant, ca devient vraiment à la mode.
Je sais pas ce que ca donne en python (je viens de rails) mais je pense qu’on peut de la meme facon utiliser Docker, ansible si gros besoin de deploiement et un jetkins pour l’integration continue (si besoin).

Utilsant lxc, le docker peut etre utilisé en prod car y’a pas de reduction de perf ou très peu. Un petit dockerfile et hop on gènere des environnements clean et portable.
Vive lxc !

Je vais essayer de faire un article dessus sinon y’a ca !

Sam, max, un article contributeur dessus ca vous interesserait ?

Donc, django_quicky ne sert rien par défaut, il faut rajouter le middleware ‘django_quicky.middleware.StaticServe’. Dans ce cas oui, tous les fichiers statiques sont servis par Django. Idéalement on le met dans le fichier local_settings.py

Moi j’utilise une troisième voie: je met ‘django_quicky.middleware.StaticServe’ dans tous les cas, et j’override en prod l’url des fichier statiques avec nginx. Mais faut vraiment faire gaffe à pas se planter dans ce cas, c’est pour ça que je ne recommande pas cette méthode.

Et c’est aussi un frein pour les débutants.

C’est la même problématique pour la base de données, le moteur de recherche, le gestionnaire de cache, le message broker, etc. Pour tous ces composants, on s’expose au risque d’avoir des différences de comportement en prod (qui n’a jamais eu des surprises de type ou de taille de nom de colonne en passant de sqlite à mysql). Mais en même temps, un setup complet ? C’est la journée de perdue.

Peut être que le tout VM peut résoudre ça.

effectivement c’est horripilant j’ai tourné en rond, je ne voyais pas ce qui ne le satisfaisait pas. Bien entendu c’est pour avoir un premier aperçu de l’appli avant que le contenu static ne soit géré par le serveur HTTP.

avec django_quicky le contenu static est géré par Django du coup ? ou les 2 (avec front HTTP et/ou django) ?

staticfiles_urlpatterns() check en interne DEBUG et se désactive si on est sur False.

Les dev de Django considère que c’est une feature, j’ai trouvé trouver ça agaçant.

Deux solutions:

Soit tu sers les fichiers à l’ancienne:

    urlpatterns += patterns('',
        (r'%s/(?P.*)$' % settings.MEDIA_URL.strip('/'),
         'django.views.static.serve',
         {'document_root': settings.MEDIA_ROOT}),
    )

Soit tu installe Django_quicky et tu utilise le middleware qui sert les static files. Il fait tout automatiquement, y a juste une ligne à rajouter dans le settings, et il sert aussi bien les medias, que les fichiers statiques des tes apps et celles de l’admin, dans tous les cas de figures.

Bien entendu, dans le cas ou on active le service des fichiers statiques avec DEBUG = False, il faut faire très attention à la mise en production de bien servir les fichiers par le serveur front end et pas Django, car on le s’en rendra pas compte facilement. C’est facile de l’oublier.