Django-Kompressor: wie Schreibe S3, gelesen von CloudFront?
Will ich dienen, mein komprimierte CSS/JS aus CloudFront (Sie Leben auf S3), aber nicht in der Lage bin zu arbeiten, wie es über die Kompressor-Einstellungen in settings.py ich habe Folgendes:
COMPRESS_OFFLINE = True
COMPRESS_URL = 'http://static.example.com/' #same as STATIC_URL, so unnecessary, just here for simplicity
COMPRESS_STORAGE = 'my_example_dir.storage.CachedS3BotoStorage' #subclass suggested in [docs][1]
COMPRESS_OUTPUT_DIR = 'compressed_static'
COMPRESS_ROOT = '/home/dotcloud/current/static/' #location of static files on server
Trotz der COMPRESS_URL, meine Dateien Lesen von meinem s3 bucket:
<link href="https://example.s3.amazonaws.com/compressed_static/css/e0684a1d5c25.css?Signature=blahblahblah;Expires=farfuture;AWSAccessKeyId=blahblahblah" type="text/css" />
Ich denke, das Problem ist, ich möchte die Datei schreiben zu S3, aber Lesen Sie es von CloudFront. Ist das möglich?
- sah Ihr ticket auf github... würden Sie mir, posten Sie Ihre Lösung?
- Meine aufrichtigen Entschuldigungen für nicht zu sehen, dies früher ist, poste ich meine Lösung unter morgen (hoffentlich)
Du musst angemeldet sein, um einen Kommentar abzugeben.
Schrieb ich eine wrapper-Speicher-backend um die von boto
myapp/storage_backends.py:
Wo meine settings.py die Datei hat...
Machte ich ein paar, verschiedene änderungen für settings.py
Kompressor Docs
Diese oben genannte Lösung die Dateien gespeichert, die lokal sowie Sie hochgeladen s3. Diese lassen Sie mich komprimieren Sie die Dateien offline. Wenn Sie nicht Gzip, die oben genannten sollten auf die Arbeit für das servieren von komprimierten Dateien von CloudFront.
Hinzufügen gzip fügt eine Falte:
settings.py
obwohl dies führte zu einem Fehler, wenn eine komprimierbare Datei (css-und js-je nach Speicher) gedrängt wurde, um s3 während collectstatic:
Diese wurde durch einige bizarre Fehler mit der Komprimierung der css/js Dateien, die ich nicht verstehe. Diese Dateien brauche ich lokal entpackt, und nicht auf s3, so konnte ich vermeiden das problem vollständig, wenn ich optimieren, die storage-Unterklasse, die die oben angegebenen (und in den Kompressor docs).
neuen storage.py
Diese dann gespeichert werden .css-und .js-Dateien (ohne den admin-Dateien, die ich unkomprimierte aus CloudFront) und drücken Sie den rest der Dateien auf s3 (und nicht Mühe zu machen, speichern Sie Sie lokal, konnte aber leicht hinzufügen des selbst.local_storage._save Linie).
Aber wenn ich komprimieren, ich will mein komprimiert .js-und .css-Dateien zu wolen s3 also ich erstelle eine weitere Unterklasse für Kompressor zu verwenden:
Schließlich, da diese neuen Unterklassen, ich brauche zu aktualisieren, ein paar Einstellungen:
... Und das ist alles was ich dazu zu sagen.
Scheint, das problem wurde tatsächlich behoben upstream in Django, https://github.com/django/django/commit/5c954136eaef3d98d532368deec4c19cf892f664
Den problematischen _get_size Methode könnte wahrscheinlich gepatcht lokal zu arbeiten, um es für ältere Versionen von Django.
EDIT: Haben einen Blick auf https://github.com/jezdez/django_compressor/issues/100 für eine aktuelle Arbeit um.
Tatsächlich scheint dies auch ein Problem sein, in der django-Speicher. Wenn Kompressor vergleicht die hashes der Dateien auf S3, django-Speicher nicht entpacken Sie den Inhalt der Gzip ' ed Dateien, sondern versucht, vergleichen Sie verschiedene hashes. Ich habe geöffnet https://bitbucket.org/david/django-storages/pull-request/33/fix-gzip-support zu beheben.
FWIW, es gibt auch https://bitbucket.org/david/django-storages/pull-request/32/s3boto-gzip-fix-and-associated-unit-tests, die behebt ein weiteres Problem wirklich zu speichern, Dateien zu S3 wenn AWS_IS_GZIPPED auf True gesetzt. Was ein yak ist das schon.
Darüber hinaus für streaming-Distributionen ist es sinnvoll, überschreiben Sie die
url
Funktion zu ermöglichenrtmp://
urls, wie in: