The basic outline of putting static files into production consists of two\nsteps: run the collectstatic command when static files change, then\narrange for the collected static files directory (STATIC_ROOT) to be\nmoved to the static file server and served. Depending on\nSTATICFILES_STORAGE, files may need to be moved to a new location\nmanually or the post_process method of\nthe Storage class might take care of that.
As with all deployment tasks, the devil’s in the details. Every production\nsetup will be a bit different, so you’ll need to adapt the basic outline to fit\nyour needs. Below are a few common patterns that might help.
\nΑν θέλετε να εξυπηρετήσετε τα static files σας από τον ίδιο server ο οποίος εξυπηρετεί ήδη το site σας, η διαδικασία θα μοιάζει κάπως έτσι:
\nΑνεβάστε τον κώδικα σας στον deployment server.
Στον server, τρέξτε την εντολή collectstatic για να αντιγραφτούν όλα τα static files μέσα στο φάκελο STATIC_ROOT.
Παραμετροποιήστε τον Web server σας για να εξυπηρετεί τα αρχεία του φακέλου STATIC_ROOT στο URL STATIC_URL. Για παράδειγμα, δείτε πως μπορείτε να το κάνετε αυτό με τον Apache και το mod_wsgi.
You’ll probably want to automate this process, especially if you’ve got\nmultiple web servers.
\nMost larger Django sites use a separate web server – i.e., one that’s not also\nrunning Django – for serving static files. This server often runs a different\ntype of web server – faster but less full-featured. Some common choices are:
\n\nΗ παραμετροποίηση αυτών των servers είναι εκτός του πεδίου εφαρμογής του παρόντος άρθρου. Συμβουλευτείτε το εγχειρίδιο καθενός από τους παραπάνω servers για λεπτομέρειες και οδηγίες.
\nΕφόσον ο static file server δεν θα τρέχει το Django, θα χρειαστεί να αλλάξετε τη στρατηγική του deployment για να μοιάζει κάπως έτσι:
\nΌταν τα static files αλλάζουν, τρέξτε την εντολή collectstatic τοπικά στον υπολογιστή σας.
Ανεβάστε τον τοπικό σας φάκελο STATIC_ROOT στον static file server μέσα στο φάκελο όπου εξυπηρετείται. Η εντολή rsync είναι μια κοινή λύση για αυτό το βήμα καθώς δεν αντιγράφει κάθε φορά όλο το φάκελο, παρά μόνο τις αλλαγές που έγιναν.
Another common tactic is to serve static files from a cloud storage provider\nlike Amazon’s S3 and/or a CDN (content delivery network). This lets you\nignore the problems of serving static files and can often make for\nfaster-loading web pages (especially when using a CDN).
\nΌταν χρησιμοποιείτε αυτές τις υπηρεσίες, η βασική διαδικασία θα μοιάζει λίγο-πολύ με την παραπάνω, εκτός του ότι αντί να χρησιμοποιείτε την εντολή rsync για να μεταφέρετε τα static files στον server, θα χρειαστεί να μεταφέρετε τα static files στον πάροχο αποθήκευσης αρχείων ή στο CDN.
There’s any number of ways you might do this, but if the provider has an API,\nyou can use a custom file storage backend\nto integrate the CDN with your Django project. If you’ve written or are using a\n3rd party custom storage backend, you can tell collectstatic to use\nit by setting STATICFILES_STORAGE to the storage engine.
Για παράδειγμα, αν έχετε γράψει ένα σύστημα αποθήκευσης S3 στο αρχείο myproject.storage.S3Storage, μπορείτε να το χρησιμοποιήσετε ως εξής:
STATICFILES_STORAGE = 'myproject.storage.S3Storage'\nOnce that’s done, all you have to do is run collectstatic and your\nstatic files would be pushed through your storage package up to S3. If you\nlater needed to switch to a different storage provider, you may only have to\nchange your STATICFILES_STORAGE setting.
For details on how you’d write one of these backends, see\nHow to write a custom storage class. There are 3rd party apps available that\nprovide storage backends for many common file storage APIs. A good starting\npoint is the overview at djangopackages.org.
\nΓια πλήρεις λεπτομέρειες πάνω σε όλες τις ρυθμίσεις, εντολές, template tags και άλλα κομμάτια που περιέχονται στο django.contrib.staticfiles, δείτε στο άρθρο αναφορά στα staticfiles.