DJango use templates from seperrate AWS S3 Bucket - django

I have a Django server running in an elastic beanstalk environment. I would like to have it render HTML templates pulled from a separate AWS S3 Bucket.
I am using the Django-storages library, which lets me use static and media files from the bucket, but I can't figure out how to get it to render templates.
The reasoning for doing it like this is that once my site is running, I would like to be able to add these HTML templates without having to redeploy the entire site.
Thank you

To my best knowledge, Django-storages is responsible for managing static assets and media files, it doesn't mount the S3 bucket to the file system, what you might be looking for is something like S3Fuse which will mount the bucket on the File System, which will allow you to update the template and have them sync. This might not be the best solution because even if you got the sync to work, Django might not pick those changes and serve the templates from memory.
I believe what you're looking for is a Continuous Delivery pipeline, that way you won't be worried about hosting.
Good Question though.

Related

Possible to alias a download link (to file in AWS S3 bucket): ".../Foo_v1.0.13" <-- ".../FooLatest"?

This seems like something that happens often enough that there might already be some provision for doing it that I'm not aware of...
Users of our app download our installer package via a link on our site that points to the file hosted in an S3 bucket on AWS. Once installed, our app uses the same (hard-coded) URL to download and install updates when they become available.
One downside to this is that it requires that the download URL be static, and thus it can't contain any version information.
If we were hosting the download on our own (configurable) web server, I'd have an idea of how to set up a redirect from https://.../Foo_Latest to https://.../Foo_v1.0.13, and we could just manage the alias in that one place?
But since we upload new releases to an S3 bucket on AWS, I'm wondering whether there's not some existing capability on AWS to alias the URL. It seems like this might be a common enough use case that there's some solution already in place for doing this?
Of course, we could just have the static URL point to a server we control, and then do the redirect there to the AWS URL. But that feels like it would somewhat defeat the purpose of using high-availability and high-bandwidth benefits of AWS...
Am I missing anything?

Persistent UGC File Storage on AWS For Docker Application

I have a docker-based Flask app that I have been developing and it's nearing completion. I am currently moving to hosting it on AWS. The app allows users to generate various forms of content (usually image files) that are saved into a UGC folder within the /static folder of the app in my dev environment. This temporary solution worked fine in dev but it isn't going to suffice when ported to live as the static/ugc folder will be destroyed with each image update.
I therefore need an alternative solution and have been investigating EFS. Does anybody have experience with this service? Or in hosting persistent static files outside of a Docker app container in general and could advise?
You should probably look at using the S3 object storage service, via the boto3 python client.
There's also a flask extension, Flask-S3 which allows you to host general assets on S3 automatically. You'd probably need to code the logic for user-uploaded content yourself.

updating an S3 website with zero downtime

What would be the best approach to update a static website hosted on an S3 bucket such that there is no downtime. The updates will be done by marketing teams of a company with zero knowledge of cli commands or how to move around in the console. Are there ways to achieve this without having to learn to move around in the console?
Edit
The web site is a collection of static html pages and will be updated using an Html editor. Once edited the marketing team will upload each individual updated file to the S3 bucket. There are no more than 10 such files including html and images. This was currently being hosted on a shared server and we now want to move it to an S3 bucket capable of hosting simple web pages. The preference is to not provision console access for certain users as they are comfortable only using a WYSIWYG html editor and uploading using an FTP client. The editors don't know html and the site doesn't use javascript. I am thinking of writing a batch script to manage the uploads to keep all that cli complexity away so they only work on the HTML in the editor. Looking for the simplest approach to achieve this.
You can set up a CI/CD pipeline as mentioned here
Update static website in an automated way
The above pipeline generally has a code commit as trigger. It depends what your marketing teams are doing on the content and how they are updating it. If they are updating the content that is hosted on AWS, you can change the trigger to S3 updates. The solution depends on an individual use case, which may require some dev from your side to make it simpler for your marketing teams.
I'm unsure what you are asking here, because to "update" a static website, surely you must have some technical knowledge in the very basics of web development.
It's important here to define what exactly you mean by update, because again, updating a website and updating a bucket are two completely different things.
Also, S3 has eventual consistency with PUT's (updating) so there will be some minimal downtime.
The easiest way to update an S3 bucket is via the console, and not the CLI. The console is pretty user friendly, and shouldn't take long to get used to.

Setting up a CDN with Wagtail CMS

I am looking into possibly setting up a CDN to use with my Wagtail sites. I am thinking that this will be a more efficient way to manage media uploads during stage/production pushes, since right now the media folder has to be manually copied from server to server on deploy. If all of the images were being accessed from a CDN then this wouldn't be an issue.
This would be my first time using a CDN so I'm looking for advice. There is lots of info on using a CDN with WordPress, but not a lot of documentation on setting one up with Wagtail/Django. I have the following questions about it:
Does anyone have any suggestions on the best way to implement the CDN with Wagtail?
How does it handle the uploads that the user submits through the CMS? Most of the images will be uploaded as part of the static files, but how does it work when the user uploads a photo as part of a post?
Which CDN companies have you had the best/worst experiences with? The sites I am planning to use this for are professional/business, but not e-commerce.
Also, if there is a more efficient way to handle the transfer of media uploads from one environment to another than using a CDN, I'd love to hear your suggestions for that too. As of right now I've had to copy the media folder over after doing the deploy, and I will have to do this every time I make a change to the site.
Thanks in advance for your assistance.
The following resources can be helpful for your required setup in Wagtail (later on today I can provide you some more details):
Frontend cache invalidator for pages (so not only for static and media files)
Link: http://docs.wagtail.io/en/latest/reference/contrib/frontendcache.html#frontendcache-aws-cloudfront
Storing media files in Amazon Web Services S3 buckets
This should be a better solution instead of copying media files from server to server. In this case Amazon Web Services CloudFront (CDN) would be a perfect choice.
Link: https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html#amazon-s3
More info CloudFront: https://aws.amazon.com/cloudfront/
Static file cache invalidation with Django Whitenoise
Can be relevant to clear the cache for a new deployment (the static files will have a unique filename so CDN will have a new file cache from its origin after the deployment)
Link: http://whitenoise.evans.io/en/stable/django.html
CloudFront from AWS will have my personal choice for CDN. Besides the awesome resources/services AWS has to offer, CloudFront is simple to setup and has one of the best CDN's out there.
Finally a CDN for serving static- and media files has nothing to do with Wagtail specifically. There are some (see list above) nice apps available for Django itself, but you are free to choose another CDN solution (like Cloudflare).
So setting up a AWS S3 Bucket for each environment (tst/acc/stg/prd) and use it for uploading you media files (so the files aren't on the server anymore) and setup a CloudFront distribution for these buckets would be a proper solution for your problem.
Best regards,
Rob Moorman

i'm confused about django statice files during deployment

I'm about two months in with django. I've been following tutorials on youtube and such and one of the tutorials says that I have to use two servers when deploying my site. Django will be served from heroku and static files from amazon s3. I have to pay for two seperate servers to deploy a django app? I did not expect this and this would not be within my budget if this is so. Is he wrong or is this just for special cases like his? Any help would be appreciated
No, sounds like the video is a bit confusing. There is a distinction between static assets, ie the CSS/JS etc that makes up your site, and dynamic media, ie any user-uploaded content.
Heroku can quite happily serve static assets from the filesystem, and their docs on deploying Django state exactly how to do this. However you cannot store dynamically uploaded content on Heroku, since the filesystem is ephemeral. If your app allows this, you need to save them somewhere permanent such as S3.
Note however that S3 is really cheap; hosting media files there should only cost you pennies.
You don't need 2 different servers for deploying your django project. You can just use a single Amazon EC2 instance then install Nginx/Apache+Supervisor+Gunicorn+Python. After that, you just need to configure the location of your static files from your virtualhost. Here's a tutorial from digital ocean.