Generally page-related systems have a large number of static files, including js, css, and icon images, which are generally relative paths to the project and are read locally and then forwarded when loaded. As these files are generally larger, resulting in a longer interface response, but these files are generally rarely changed, so they are ideal for caching through Nginx or cloud services. Generally cloud services are seamlessly integrated with cdn to enable faster delivery to the client. Many of our backend systems use python based Django framework , how to achieve static file caching?
The process was surprisingly simple, but the beginning kept getting confused about the relationship and there was a lot of delay before and after.
command
First of all, Django has a collectstatic command. The function of this script is to package local static files and required dependencies, such as static files needed by Django and python themselves, into a unified directory. This is somewhat similar to the maven pre-release packaging feature.
This script is usually executed at go-live time. For example, this is how it is written in our startup script:
sh
Then add this line to djang's config file:
static-map = /static=./static_files
We use collectstatic to package local static files and send them to a cloud service.
2. How to publish to cloud services
The method is very simple and there is very little code, but it seems that a lot of it doesn't make it clear why, which caused me to mess around for a long time and whittle down a lot of garbage code.
First you need to create a new class that inherits from Storage, like this.
@deconstructible class CosStorage(Storage):
The note above must be there as well.
Then in many materials will be, to implement multiple methods in the class here, some of them start with _, some are just ordinary classes, I understand that _ starts with the main method of collectstatic implementation, and not with the program execution is called when. The former is similar to all kinds of service in java, the program will be executed when starting. And the latter is similar to the controller under the interface, only when the external call will be executed.
The most important methods beginning with _ are the following three.
def __init__(self):
('init cos file list...')
self.get_cos_file_list()
# To see if it's needed here
def _open(self, name, mode='r'):
return File(open((name), mode))
def _save(self, name, content):
.upload_os_file(FileBizType.TRUMAN_CMS_STATIC_FILES, content, name, name)
(0.02)
The __init__ is naturally set up for initialization. Write the corresponding code as needed, e.g. signatures needed to call cloud services, etc.
_open() this I forgot to test whether there is no use, according to the reason here is to open the file, anyway, I was on the so written.
_save(self, name, content) is the most critical code. This interface is the two main keys to understanding Storage. The function of this method is to deal with the current file has been opened, the file title is the name, content is the contents of the file will be converted to a byte stream, you can use directly on the line. How to understand this?
The meaning of name: If you have a deep static path, a lot of files, and a lot of different types. Then Storage will help you deal with the path problem first, name is the relative path + filename. So when you pass the name, you will pass the relative directory together.
The meaning of content: content is the content of the file, whether it is js, css, or icon images, in the network will first be converted to byte stream is not. Here the content is the current file byte stream. So use upload_os_file(content) to send the file content, do not need to read the file again, converted to byte stream and other operations. But here upload_os_file is my own business code, you can do according to the needs of the corresponding implementation.
Another important point is that _save only handles one file at a time, so when you write the code in this method you only have to test one file, you don't have to write the logic for batch and so on.
Here is another point is that if you do not add a limit, the execution speed of _save will be very fast, all the files will be read at once, and a file a request to send out all, which may lead to the server can not be processed in time to be rejected and so on. The method is also very simple, _save add a wait on the line
(0.02)
The above code will be automatically scanned, loaded and executed when collectstatic is executed during the service startup process, but you have to add the following information in your own configuration file, otherwise it will not be found.
STATICFILES_STORAGE = 'cos.cos_storage.CosStorage'
3. How the visit is redirected to cos
After saving the file to the cloud service, how do I access it when the page is executed?
This brings us to several other methods of Storage, mainly:
def listdir(self, path):
pass
def delete(self, name):
pass
def size(self, name):
pass
def url(self, name):
url = .get_file_os_download_url(name)
return url
def exists(self, name):
pass
Above look at the name we can roughly know the function, the most important is the url() method, this is the second key to understand Storage.
The name here is the relative path of the file in the cloud service, you need to splice your domain name and so on is the address of the file. Then return on the line.
If the static files are public, it seems that the url is not written here, it can automatically realize the domain name and relative path of the file to splice the program to access the full url.
But in our system, static files are not allowed to be accessed directly, they need to be signed. So here we need to access our another service via customized get_file_os_download_url() method in the url.
But there is a pitfall here, that is, python's base package will also use relative paths to access their own static files, that is, so write "/" and so on, this case can not be intercepted by the url. Because our business code is uniformly prefixed with /static/.
What to block, so far no solution, if you know, please talk to me, thanks!
To this point this article on Django static file caching to cloud services to achieve the operation of the article is introduced to this, more related to Django static file caching content, please search for my previous articles or continue to browse the following related articles I hope that you will support me more in the future!