如何在后台部署深度学习模型

搭建深度学习后台服务器

我们的Keras深度学习REST API将能够批量处理图像，扩展到多台机器(包括多台web服务器和Redis实例)，并在负载均衡器之后进行循环调度。

为此，我们将使用:

KerasRedis(内存数据结构存储)

Flask (Python的微web框架)

消息队列和消息代理编程范例

本篇文章的整体思路如下：

我们将首先简要讨论Redis数据存储，以及如何使用它促进消息队列和消息代理。然后，我们将通过安装所需的Python包来配置Python开发环境，以构建我们的Keras深度学习REST API。一旦配置了开发环境，就可以使用Flask web框架实现实际的Keras深度学习REST API。在实现之后，我们将启动Redis和Flask服务器，然后使用cURL和Python向我们的深度学习API端点提交推理请求。最后，我们将以对构建自己的深度学习REST API时应该牢记的注意事项的简短讨论结束。

第一部分：简要介绍Redis如何作为REST API消息代理/消息队列

1：Redis可以用作我们深度学习REST API的消息代理/消息队列

Redis是内存中的数据存储。它不同于简单的键/值存储(比如memcached)，因为它可以存储实际的数据结构。今天我们将使用Redis作为消息代理/消息队列。这包括:

在我们的机器上运行Redis

将数据(图像)按照队列的方式用Redis存储，并依次由我们的REST API处理

为新批输入图像循环访问Redis

对图像进行分类并将结果返回给客户端

文章中对Redis官网有一个超链接（https://redisio/topics/introduction），但是要翻出去，所以我就截图一个放上去仅供参考。

第二部分：安装和配置Redis

官网做法，linux系统的安装：

自己的安装方法：

conda install redis

开启方式相同：

resdis-server

结果：

测试和原文的命令一致。

第三部分：配置Python开发环境以构建Keras REST API

文章中说需要创建新的虚拟环境来防止影响系统级别的python项目（但是我没有创建），但是还是需要安装rest api所需要依赖的包。以下为所需要的包。

第四部分：实现可扩展的Keras REST API

首先是Keras Redis Flask REST API数据流程图

让我们开始构建我们的服务器脚本。为了方便起见，我在一个文件中实现了服务器，但是它可以按照您认为合适的方式模块化。为了获得最好的结果和避免复制/粘贴错误，我建议您使用本文的“下载”部分来获取相关的脚本和图像。

为了简单起见，我们将在ImageNet数据集上使用ResNet预训练。我将指出在哪里可以用你自己的模型交换ResNet。flask模块包含flask库(用于构建web API)。redis模块将使我们能够与redis数据存储接口。从这里开始，让我们初始化将在run_keras_serverpy中使用的常量

我们将向服务器传递float32图像，尺寸为224 x 224，包含3个通道。我们的服务器可以处理一个BATCH_SIZE = 32。如果您的生产系统上有GPU(s)，那么您需要调优BATCH_SIZE以获得最佳性能。我发现将SERVER_SLEEP和CLIENT_SLEEP设置为025秒(服务器和客户端在再次轮询Redis之前分别暂停的时间)在大多数系统上都可以很好地工作。如果您正在构建一个生产系统，那么一定要调整这些常量。

让我们启动我们的Flask app和Redis服务器:

在这里你可以看到启动Flask是多么容易。在运行这个服务器脚本之前，我假设Redis服务器正在运行(之前的redis-server)。我们的Python脚本连接到本地主机6379端口(Redis的默认主机和端口值)上的Redis存储。不要忘记将全局Keras模型初始化为None。接下来我们来处理图像的序列化:

Redis将充当服务器上的临时数据存储。图像将通过诸如cURL、Python脚本甚至是移动应用程序等各种方法进入服务器，而且，图像只能每隔一段时间(几个小时或几天)或者以很高的速率(每秒几次)进入服务器。我们需要把图像放在某个地方，因为它们在被处理前排队。我们的Redis存储将作为临时存储。

为了将图像存储在Redis中，需要对它们进行序列化。由于图像只是数字数组，我们可以使用base64编码来序列化图像。使用base64编码还有一个额外的好处，即允许我们使用JSON存储图像的附加属性。

base64_encode_image函数处理序列化。类似地，在通过模型传递图像之前，我们需要反序列化图像。这由base64_decode_image函数处理。

预处理

我已经定义了一个prepare_image函数，它使用Keras中的ResNet50实现对输入图像进行预处理，以便进行分类。在使用您自己的模型时，我建议修改此函数，以执行所需的预处理、缩放或规范化。

从那里我们将定义我们的分类方法

classify_process函数将在它自己的线程中启动，我们将在下面的__main__中看到这一点。该函数将从Redis服务器轮询图像批次，对图像进行分类，并将结果返回给客户端。

在model = ResNet50(weights="imagenet")这一行中，我将这个操作与终端打印消息连接起来——根据Keras模型的大小，加载是即时的，或者需要几秒钟。

加载模型只在启动这个线程时发生一次——如果每次我们想要处理一个映像时都必须加载模型，那么速度会非常慢，而且由于内存耗尽可能导致服务器崩溃。

加载模型后，这个线程将不断轮询新的图像，然后将它们分类（注意这部分代码应该时尚一部分的继续）

在这里，我们首先使用Redis数据库的lrange函数从队列(第79行)中获取最多的BATCH_SIZE图像。

从那里我们初始化imageIDs和批处理(第80和81行)，并开始在第84行开始循环队列。

在循环中，我们首先解码对象并将其反序列化为一个NumPy数组image(第86-88行)。

接下来，在第90-96行中，我们将向批处理添加图像(或者如果批处理当前为None，我们将该批处理设置为当前图像)。

我们还将图像的id附加到imageIDs(第99行)。

让我们完成循环和函数

在这个代码块中，我们检查批处理中是否有图像(第102行)。如果我们有一批图像，我们通过模型(第105行)对整个批进行预测。从那里，我们循环一个图像和相应的预测结果(110-122行)。这些行向输出列表追加标签和概率，然后使用imageID将输出存储在Redis数据库中(第116-122行)。

我们使用第125行上的ltrim从队列中删除了刚刚分类的图像集。最后，我们将睡眠设置为SERVER_SLEEP时间并等待下一批图像进行分类。下面我们来处理/predict我们的REST API端点

稍后您将看到，当我们发布到REST API时，我们将使用/predict端点。当然，我们的服务器可能有多个端点。我们使用@app。路由修饰符以第130行所示的格式在函数上方定义端点，以便Flask知道调用什么函数。我们可以很容易地得到另一个使用AlexNet而不是ResNet的端点，我们可以用类似的方式定义具有关联函数的端点。你懂的，但就我们今天的目的而言，我们只有一个端点叫做/predict。

我们在第131行定义的predict方法将处理对服务器的POST请求。这个函数的目标是构建JSON数据，并将其发送回客户机。如果POST数据包含图像(第137和138行)，我们将图像转换为PIL/Pillow格式，并对其进行预处理(第141-143行)。

在开发这个脚本时，我花了大量时间调试我的序列化和反序列化函数，结果发现我需要第147行将数组转换为C-contiguous排序(您可以在这里了解更多)。老实说，这是一个相当大的麻烦事，但我希望它能帮助你站起来，快速跑。

如果您想知道在第99行中提到的id，那么实际上是使用uuid(通用唯一标识符)在第151行生成的。我们使用UUID来防止hash/key冲突。

接下来，我们将图像的id和base64编码附加到d字典中。使用rpush(第153行)将这个JSON数据推送到Redis db非常简单。

让我们轮询服务器以返回预测

我们将持续循环，直到模型服务器返回输出预测。我们开始一个无限循环，试图得到157-159条预测线。从这里，如果输出包含预测，我们将对结果进行反序列化，并将结果添加到将返回给客户机的数据中。我们还从db中删除了结果(因为我们已经从数据库中提取了结果，不再需要将它们存储在数据库中)，并跳出了循环(第163-172行)。

否则，我们没有任何预测，我们需要睡觉，继续投票(第176行)。如果我们到达第179行，我们已经成功地得到了我们的预测。在本例中，我们向客户机数据添加True的成功值(第179行)。注意:对于这个示例脚本，我没有在上面的循环中添加超时逻辑，这在理想情况下会为数据添加一个False的成功值。我将由您来处理和实现。最后我们称烧瓶。jsonify对数据，并将其返回给客户端(第182行)。这就完成了我们的预测函数。

为了演示我们的Keras REST API，我们需要一个__main__函数来实际启动服务器

第186-196行定义了__main__函数，它将启动classify_process线程(第190-192行)并运行Flask应用程序(第196行)。

第五部分：启动可伸缩的Keras REST API

要测试我们的Keras深度学习REST API，请确保使用本文的“下载”部分下载源代码示例图像。从这里，让我们启动Redis服务器，如果它还没有运行:

redis-server

然后，在另一个终端中，让我们启动REST API Flask服务器:

python run_keras_serverpy

另外，我建议在向服务器提交请求之前，等待您的模型完全加载到内存中。现在我们可以继续使用cURL和Python测试服务器。

第七部分：使用cURL访问Keras REST API

使用cURL来测试我们的Keras REST API服务器。这是我的家庭小猎犬Jemma。根据我们的ResNet模型，她被归类为一只拥有946%自信的小猎犬。

curl -X POST -F image=@jemmapng 'http://localhost:5000/predict'

你会在你的终端收到JSON格式的预测:

{"predictions": [{"label": "beagle","probability": 09461546540260315},{"label": "bluetick","probability": 0031958919018507004},{"label": "redbone","probability": 0006617196369916201},{"label": "Walker_hound","probability": 00033879687543958426},{"label": "Greater_Swiss_Mountain_dog","probability": 00025766862090677023}],"success": true}

第六部分：使用Python向Keras REST API提交请求

如您所见，使用cURL验证非常简单。现在，让我们构建一个Python脚本，该脚本将发布图像并以编程方式解析返回的JSON。

让我们回顾一下simple_requestpy

# import the necessary packagesimport requests# initialize the Keras REST API endpoint URL along with the input# image pathKERAS_REST_API_URL = "http://localhost:5000/predict"IMAGE_PATH = "jemmapng"

我们在这个脚本中使用Python请求来处理向服务器提交数据。我们的服务器运行在本地主机上，可以通过端口5000访问端点/predict，这是KERAS_REST_API_URL变量(第6行)指定的。

我们还定义了IMAGE_PATH(第7行)。png与我们的脚本在同一个目录中。如果您想测试其他图像，请确保指定到您的输入图像的完整路径。

让我们加载图像并发送到服务器:

# load the input image and construct the payload for the requestimage = open(IMAGE_PATH, "rb")read()payload = {"image": image}# submit the requestr = requestspost(KERAS_REST_API_URL, files=payload)json()# ensure the request was sucessfulif r["success"]: # loop over the predictions and display them for (i, result) in enumerate(r["predictions"]): print("{} {}: {:4f}"format(i + 1, result["label"], result["probability"]))# otherwise, the request failedelse: print("Request failed")

我们在第10行以二进制模式读取图像并将其放入有效负载字典。负载通过请求发送到服务器。在第14行发布。如果我们得到一个成功消息，我们可以循环预测并将它们打印到终端。我使这个脚本很简单，但是如果你想变得更有趣，你也可以使用OpenCV在图像上绘制最高的预测文本。

第七部分：运行简单的请求脚本

编写脚本很容易。打开终端并执行以下命令(当然，前提是我们的Flask服务器和Redis服务器都在运行)。

python simple_requestpy

使用Python以编程方式使用我们的Keras深度学习REST API的结果

第八部分：扩展深度学习REST API时的注意事项

如果您预期在深度学习REST API上有较长一段时间的高负载，那么您可能需要考虑一种负载平衡算法，例如循环调度，以帮助在多个GPU机器和Redis服务器之间平均分配请求。

记住，Redis是内存中的数据存储，所以我们只能在队列中存储可用内存中的尽可能多的图像。

使用float32数据类型的单个224 x 224 x 3图像将消耗602112字节的内存。

不能，因为tomcat只是一个JAVA 的容器。

也就是说tomcat是在JVM的基础上运行的（当然你要用JAVA写一个python的代码解释器也不是没可能，只是没必要罢了）。

apache就可以部署python的web applcation 比较常用的是django这个框架。

扩展资料：

Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选，但是不能部署python程序。

对于一个初学者来说，可以这样认为，当在一台机器上配置好Apache 服务器，可利用它响应HTML（标准通用标记语言下的一个应用）页面的访问请求。

-tomcat

有人说表示只学Python没有用，必须学会一个框架(比如Django和webpy)才能找到工作。

其实掌握一个类似于框架的高级工具是有用的，但是基础的东西可以让你永远不被淘汰，不要被工具限制了自己的发展。

今天不使用框架，也不使用Python标准库中的高级包，只使用标准库中的socket接口写一个Python服务器。

框架与底层

在当今Python服务器框架 (framework, 比如Django, Twisted, webpy等等) 横行的时代，从底层的socket开始写服务器似乎是一个出力不讨好的笨方法。

框架的意义在于掩盖底层的细节，提供一套对于开发人员更加友好的API，并处理诸如MVC的布局问题。

框架允许我们快速的构建一个成型而且成熟的Python服务器。然而，框架本身也是依赖于底层(比如socket)。对于底层socket的了解，不仅可以帮助我们更好的使用框架，更可以让我们明白框架是如何设计的。

更进一步，如果拥有良好的底层socket编程知识和其他系统编程知识，你完全可以设计并开发一款自己的框架。

如果你可以从底层socket开始，实现一个完整的Python服务器，支持用户层的协议，并处理好诸如MVC(Model-View-Control)、多线程(threading)等问题，并整理出一套清晰的函数或者类，作为接口(API)呈现给用户，你就相当于设计了一个框架。

socket接口是实际上是操作系统提供的系统调用。

socket的使用并不局限于Python语言，你可以用C或者Java来写出同样的socket服务器，而所有语言使用socket的方式都类似(Apache就是使用C实现的服务器)。

但是你不能跨语言的使用框架。

框架的好处在于帮你处理了一些细节，从而实现快速开发，但同时受到Python本身性能的限制。

我们已经看到，许多成功的网站都是利用动态语言(比如Python, Ruby或者PHP，比如twitter和facebook)快速开发，在网站成功之后，将代码转换成诸如C和JAVA这样一些效率比较高的语言，从而让服务器能更有效率的面对每天亿万次的请求。

在这种情况下，底层的重要性，就远远超过了框架。

TCP/IP和socket简介

回到我们的任务。

我们需要对网络传输，特别是TCP/IP协议和socket有一定的了解。

socket是进程间通信的一种方法，它是基于网络传输协议的上层接口。

socket有许多种类型，比如基于TCP协议或者UDP协议(两种网络传输协议)，其中又以TCP socket最为常用。

TCP socket与双向管道(duplex PIPE)有些类似，一个进程向socket的一端写入或读取文本流，而另一个进程可以从socket的另一端读取或写入，比较特别是，这两个建立socket通信的进程可以分别属于两台不同的计算机。

TCP协议，就是规定了一些通信的守则，以便在网络环境下能够有效实现上述进程间通信过程。

双向管道(duplex PIPE)存活于同一台电脑中，所以不必区分两个进程的所在计算机的地址，而socket必须包含有地址信息，以便实现网络通信。

一个socket包含四个地址信息: 两台计算机的IP地址和两个进程所使用的端口(port)。IP地址用于定位计算机，而port用于定位进程 (一台计算机上可以有多个进程分别使用不同的端口)。

TCP socket

在互联网上，让某台计算机作为服务器。

服务器开放自己的端口，被动等待其他计算机连接。

当其他计算机作为客户，主动使用socket连接到服务器的时候，服务器就开始为客户提供服务。

在Python中，我们使用标准库中的socket包来进行底层的socket编程。

首先是服务器端，我们使用bind()方法来赋予socket以固定的地址和端口，并使用listen()方法来被动的监听该端口。

当有客户尝试用connect()方法连接的时候，服务器使用accept()接受连接，从而建立一个连接的socket：

socketsocket()创建一个socket对象，并说明socket使用的是IPv4(AF_INET，IP version 4)和TCP协议(SOCK_STREAM)。

然后用另一台电脑作为客户，我们主动使用connect()方法来搜索服务器端的IP地址(在Linux中，你可以用$ifconfig来查询自己的IP地址)和端口，以便客户可以找到服务器，并建立连接:

在上面的例子中，我们对socket的两端都可以调用recv()方法来接收信息，调用sendall()方法来发送信息。

这样，我们就可以在分处于两台计算机的两个进程间进行通信了。

当通信结束的时候，我们使用close()方法来关闭socket连接。

(如果没有两台计算机做实验，也可以将客户端IP想要connect的IP改为"127001"，这是个特殊的IP地址，用来连接当地主机。)

基于TCP socket的HTTP服务器

上面的例子中，我们已经可以使用TCP socket来为两台远程计算机建立连接。

然而，socket传输自由度太高，从而带来很多安全和兼容的问题。

我们往往利用一些应用层的协议(比如HTTP协议)来规定socket使用规则，以及所传输信息的格式。

HTTP协议利用请求-回应(request-response)的方式来使用TCP socket。

客户端向服务器发一段文本作为request，服务器端在接收到request之后，向客户端发送一段文本作为response。

在完成了这样一次request-response交易之后，TCP socket被废弃。

下次的request将建立新的socket。

request和response本质上说是两个文本，只是HTTP协议对这两个文本都有一定的格式要求。

Request <——> Response

现在，我们写出一个HTTP服务器端：

HTTP服务器程序的解释

如我们上面所看到的，服务器会根据request向客户传输的两条信息text_content和pic_content中的一条，作为response文本。

整个response分为起始行(start line), 头信息(head)和主体(body)三部分。起始行就是第一行:

它实际上又由空格分为三个片段，HTTP/1x表示所使用的HTTP版本，200表示状态(status code)，200是HTTP协议规定的，表示服务器正常接收并处理请求，OK是供人来阅读的status code。

头信息跟随起始行，它和主体之间有一个空行。

这里的text_content或者pic_content都只有一行的头信息，text_content用来表示主体信息的类型为html文本：

而pic_content的头信息(Content-Type: image/jpg)说明主体的类型为jpg(image/jpg)。

主体信息为html或者jpg文件的内容。

(注意，对于jpg文件，我们使用"rb"模式打开，是为了与windows兼容。因为在windows下，jpg被认为是二进制(binary)文件，在UNIX系统下，则不需要区分文本文件和二进制文件。)

我们并没有写客户端程序，后面我们会用浏览器作为客户端。

request由客户端程序发给服务器。

尽管request也可以像response那样分为三部分，request的格式与response的格式并不相同。

request由客户发送给服务器，比如下面是一个request：

起始行可以分为三部分，第一部分为请求方法(request method)，第二部分是URL，第三部分为HTTP版本。

request method可以有GET， PUT， POST， DELETE， HEAD。最常用的为GET和POST。

GET是请求服务器发送资源给客户，POST是请求服务器接收客户送来的数据。

当我们打开一个网页时，我们通常是使用GET方法；当我们填写表格并提交时，我们通常使用POST方法。

第二部分为URL，它通常指向一个资源(服务器上的资源或者其它地方的资源)。像现在这样，就是指向当前服务器的当前目录的testjpg。

按照HTTP协议的规定，服务器需要根据请求执行一定的操作。

正如我们在服务器程序中看到的，我们的Python程序先检查了request的方法，随后根据URL的不同，来生成不同的response(text_content或者pic_content)。

随后，这个response被发送回给客户端。

使用浏览器实验

为了配合上面的服务器程序，我已经在放置Python程序的文件夹里，保存了一个testjpg文件。

我们在终端运行上面的Python程序，作为服务器端，再打开一个浏览器作为客户端。

(如果有时间，你也完全可以用Python写一个客户端。原理与上面的TCP socket的客户端程序相类似。)

在浏览器的地址栏输入:

(当然，你也可以用令一台电脑，并输入服务器的IP地址)

OK，我已经有了一个用Python实现的，并从socket写起的服务器了。

从终端，我们可以看到，浏览器实际上发出了两个请求。

第一个请求为 (关键信息在起始行，这一个请求的主体为空):

我们的Python程序根据这个请求，发送给服务器text_content的内容。

浏览器接收到text_content之后，发现正文的html文本中有<IMG src="textjpg" />，知道需要获得textjpg文件来补充为，立即发出了第二个请求:

我们的Python程序分析过起始行之后，发现/testjpg符合if条件，所以将pic_content发送给客户。

最后，浏览器根据html语言的语法，将html文本和图画以适当的方式显示出来。

探索的方向

1) 在我们上面的服务器程序中，我们用while循环来让服务器一直工作下去。

实际上，我们还可以根据多线程的知识，将while循环中的内容改为多进程或者多线程工作。

2) 我们的服务器程序还不完善，我们还可以让我们的Python程序调用Python的其他功能，以实现更复杂的功能。比如说制作一个时间服务器，让服务器向客户返回日期和时间。你还可以使用Python自带的数据库，来实现一个完整的LAMP服务器。

3) socket包是比较底层的包。Python标准库中还有高层的包，比如SocketServer，SimpleHTTPServer，CGIHTTPServer，cgi。这些都包都是在帮助我们更容易的使用socket。如果你已经了解了socket，那么这些包就很容易明白了。利用这些高层的包，你可以写一个相当成熟的服务器。

4) 在经历了所有的辛苦和麻烦之后，你可能发现，框架是那么的方便，所以决定去使用框架。或者，你已经有了参与到框架开发的热情。

1、网络接口：能方便进行系统维护和管理，Linux下标志性语言之一，是很多系统管理员理想的编程工具。

2、图形处理：有PIL、Tkinter等图形库支持，能方便进行图形处理。

3、数学处理：NumPy扩展提供大量与许多标准数学库的接口。

4、文本处理：python提供的re模块能支持正则表达式，还提供SGML，XML分析模块，许多程序员利用python进行XML程序的开发。

5、数据库编程：程序员可通过遵循Python DB-API（应用程序编程接口）规范的模块与Microsoft SQL Server，Oracle，Sybase，DB2，MySQL、SQLite等数据库通信。python自带有一个Gadfly模块，提供了一个完整的SQL环境。

6、网络编程：提供丰富的模块支持sockets编程，能方便快速地开发分布式应用程序。很多大规模软件开发计划例如Zope，Mnet 及BitTorrent Google都在广泛地使用它。

7、Web编程：应用的开发语言，支持最新的XML技术。

8、多媒体应用：Python的PyOpenGL模块封装了“OpenGL应用程序编程接口”，能进行二维和三维图像处理。PyGame模块可用于编写游戏软件。

9、pymo引擎：PYMO全称为python memories off，是一款运行于Symbian S60V3，Symbian3，S60V5，Symbian3，Android系统上的AVG游戏引擎。因其基于python20平台开发，并且适用于创建秋之回忆（memories off）风格的AVG游戏，故命名为PYMO。

首先纠正几个名词问题

服务器是指的硬件,PYthon作为一个编程语言是无法制作硬件的

网址更确切的说应该是域名服务,网址是一个指向地址,指向的是服务器的IP地址

python只能制作网站后台程序,目前已经有现成的py库可以快速搭建网站服务如:Django,Flask,Bottle 等框架都可以实现

通过网址访问,则需要域名服务,需要从域名服务商购买域名,并将域名解析到,网站服务器上,通过80端口访问通过网站程序搭建的网站

网址从服务商处注册,是需要一定费用的,可以根据自己的需要在服务商处选择

域名是可以自己自定义选择的,不过一定得是别人没有注册过的才行

服务器也是需要付费的

Frozen-Flask freezes a Flask application into a set of static files The result can be hosted without any server-side software other than a traditional web server

Note: This project used to be called Flask-Static

Installation

Install the extension with one of the following commands:

$ easy_install Frozen-Flask

or alternatively if you have pip installed:

$ pip install Frozen-Flask

or you can get the source code from github

Context

This documentation assumes that you already have a working Flask application You can run it and test it with the development server:

from myapplication import appapprun(debug=True)

Frozen-Flask is only about deployment: instead of installing Python, a WGSI server and Flask on your server, you can use Frozen-Flask to freeze your application and only have static HTML files on your server

Getting started

Create a Freezer instance with your app object and call its freeze() method Put that in a freezepy script (or call it whatever you like):

from flask_frozen import Freezerfrom myapplication import appfreezer = Freezer(app)if __name__ == '__main__':

freezerfreeze()

This will create a build directory next to your application’s static and templatesdirectories, with your application’s content frozen into  static files

Note

Frozen-Flask considers it “owns” its build directory By default, it will silently overwrite files in that directory, and remove those it did not create

The configuration allows you to change the destination directory, or control what files are removed if at all

This build will most likely be partial since Frozen-Flask can only guess so much about your application

Finding URLs

Frozen-Flask works by simulating requests at the WSGI level and writing the responses to aptly named files So it needs to find out which URLs exist in your application

The following URLs can be found automatically:

Static files handled by Flask for your application or any of its blueprints

Views with no variable parts in the URL, if they accept the GET method

New in version 06: Results of calls to flaskurl_for() made by your application in the request for another URL In other words, if you use url_for() to create links in your application, these links will be “followed”

This means that if your application has an index page at the URL / (without parameters) and every other page can be found from there by recursively following links built with url_for(), then Frozen-Flask can discover all URLs automatically and you’re done

Otherwise, you may need to write URL generators

URL generators

Let’s say that your application looks like this:

@approute('/')def products_list():

   return render_template('indexhtml', products=modelsProductall())@approute('/product_<int:product_id>/')def product_details():

   product = modelsProductget_or_404(id=product_id)

   return render_template('producthtml', product=product)

If, for some reason, some products pages are not linked from another page (or these links are not built by url_for()), Frozen-Flask will not find them

To tell Frozen-Flask about them, write an URL generator and put it after creating your Freezer instance and before calling freeze():

@freezerregister_generatordef product_details():

   for product in modelsProductall():

       yield {'product_id': productid}

Frozen-Flask will find the URL by calling url_for(endpoint, values) whereendpoint is the name of the generator function and values is each dict yielded by the function

You can specify a different endpoint by yielding a (endpoint, values) tuple instead of just values, or you can by-pass url_for and simply yield URLs as strings

Also, generator functions do not have to be Python generators using yield, they can be any callable and return any iterable object

All of these are thus equivalent:

@freezerregister_generatordef product_details():  # endpoint defaults to the function name

   # `values` dicts

   yield {'product_id': '1'}

   yield {'product_id': '2'}@freezerregister_generatordef product_url_generator():  # Some other function name

   # `(endpoint, values)` tuples

   yield 'product_details', {'product_id': '1'}

   yield 'product_details', {'product_id': '2'}@freezerregister_generatordef product_url_generator():

   # URLs as strings

   yield '/product_1/'

   yield '/product_2/'@freezerregister_generatordef product_url_generator():

   # Return a list (Any iterable type will do)

   return [

       '/product_1/',

       # Mixing forms works too

       ('product_details', {'product_id': '2'}),

   ]

Generating the same URL more than once is okay, Frozen-Flask will build it only once Having different functions with the same name is generally a bad practice, but still work here as they are only used by their decorators In practice you will probably have a module for your views and another one for the freezer and URL generators, so having the same name is not a problem

Testing URL generators

The idea behind Frozen-Flask is that you can use Flask directly to develop and test your application However, it is also useful to test your URL generators and see that nothing is missing, before deploying to a production server

You can open the newly generated static HTML files in a web browser, but links probably won’t work The FREEZER_RELATIVE_URLS configuration can fix this, but adds a visible indexhtml to the links Alternatively, use the run() method to start an HTTP server on the build result, so you can check that everything is fine before uploading:

if __name__ == '__main__':

   freezerrun(debug=True)

Freezerrun() will freeze your application before serving and when the reloader kicks in But the reloader only watches Python files, not templates or static files Because of that, you probably want to use Freezerrun() only for testing the URL generators For everything else use the usual apprun()

Flask-Script may come in handy here

Controlling What Is Followed

Frozen-Flask follows links automatically or with some help from URL generators If you want to control what gets followed, then URL generators should be used with the Freezer’s with_no_argument_rules and log_url_for flags Disabling these flags will force Frozen-Flask to use URL generators only The combination of these three elements determines how much Frozen-Flask will follow

Configuration

Frozen-Flask can be configured using Flask’s configuration system The following configuration values are accepted:

FREEZER_BASE_URL

Full URL your application is supposed to be installed at This affects the output of flaskurl_for() for absolute URLs (with _external=True) or if your application is not at the root of its domain name Defaults to 'http://localhost/'

FREEZER_RELATIVE_URLS

If set to True, Frozen-Flask will patch the Jinja environment so that url_for() returns relative URLs Defaults to False Python code is not affected unless you use relative_url_for() explicitly This enables the frozen site to be browsed without a web server (opening the files directly in a browser) but appends a visible indexhtml to URLs that would otherwise end with /

New in version 010

FREEZER_DEFAULT_MIMETYPE

The MIME type that is assumed when it can not be determined from the filename extension If you’re using the Apache web server, this should match the DefaultTypevalue of Apache’s configuration  Defaults to application/octet-stream

New in version 07

FREEZER_IGNORE_MIMETYPE_WARNINGS

If set to True, Frozen-Flask won’t show warnings if the MIME type returned from the server doesn’t match the MIME type derived from the filename extension Defaults to False

New in version 08

FREEZER_DESTINATION

Path to the directory where to put the generated static site If relative, interpreted as relative to the application root, next to the static and templates directories Defaults to build

FREEZER_REMOVE_EXTRA_FILES

If set to True (the default), Frozen-Flask will remove files in the destination directory that were not built during the current freeze This is intended to clean up files generated by a previous call to Freezerfreeze() that are no longer needed Setting this to False is equivalent to setting FREEZER_DESTINATION_IGNORE to ['']

New in version 05

FREEZER_DESTINATION_IGNORE

A list (defaults empty) of fnmatch patterns Files or directories in the destination that match any of the patterns are not removed, even if FREEZER_REMOVE_EXTRA_FILES is true As in gitignore files, patterns apply to the whole path if they contain a slash /, to each slash-separated part otherwise For example, this could be set to ['git