Question

我使用Cloudfoundry部署了Django应用程序。构建应用程序需要花费一些时间，但是我需要使用不同的启动命令来启动应用程序，而我今天唯一的解决方案是每次应用程序都完全重新构建。

使用Docker，更改start命令非常容易，并且不需要重建整个容器，必须有一种更有效的方法来完成此操作：

以下是启动的应用程序：

FrontEndApp-Prod ：使用gunicorn的Django应用
OrchesterApp-Prod ：Django Celery Camera＆Heartbeat
WorkerApp-Prod ：Django Celery Workers

所有这些应用程序基本上都是相同的，只是使用不同的路由，配置和启动命令。

下面是我使用的文件manifest.yml：

defaults: &defaults
  timeout: 120
  memory: 768M
  disk_quota: 2G
  path: .
  stack: cflinuxfs2
  buildpack: https://github.com/cloudfoundry/buildpack-python.git
  services:
  - PostgresDB-Prod
  - RabbitMQ-Prod
  - Redis-Prod

applications:

- name: FrontEndApp-Prod
  <<: *defaults
  routes:
  - route: www.myapp.com
  instances: 2
  command: chmod +x ./launch_server.sh && ./launch_server.sh

- name: OrchesterApp-Prod
  <<: *defaults
  memory: 1G
  instances: 1
  command: chmod +x ./launch_orchester.sh && ./launch_orchester.sh
  health-check-type: process
  no-route: true

- name: WorkerApp-Prod
  <<: *defaults
  instances: 3
  command: chmod +x ./launch_worker.sh && ./launch_worker.sh
  health-check-type: process
  no-route: true

Answer 1

我可以想到两个选择：

您可以使用某些新的v3 API功能，并在Procfile中利用它们对多个进程的支持。这样，您实际上将拥有一个Profile，如下所示：
```
web: ./launch_server.sh
worker: ./launch_orchester.sh
worker: ./launch_worker.sh
```
然后，该平台应将您的应用暂存一次，但根据暂存产生的液滴将其部署3次。之所以如此，是因为您最终只能拥有一个运行着多个进程的应用程序。缺点是，在我撰写本文时，这是一个实验性的API，因此它仍具有一些粗糙的边缘，此外，您所获得的确切支持可能会因CF提供程序安装新版本的Cloud Controller API的速度而异。 / p>
您可以在此处阅读有关此内容的所有详细信息：

https://www.cloudfoundry.org/blog/build-cf-push-learn-procfiles/
您可以使用cf local。这是一个cf cli插件，它允许您在本地构建一个Droplet（暂存在本地计算机上的docker容器中进行）。然后，您可以按照需要分配该液滴并进行尽可能多的部署。

该过程大致类似于此，您只需要填写一些选项/标志（提示运行cf local -h即可查看所有选项）：
- cf local stage
- cf local push FrontEndApp-Prod
- cf local push OrchesterApp-Prod
- cf local push WorkerApp-Prod
第一个命令将在当前目录中创建一个以.droplet结尾的文件，随后的三个命令会将那个Droplet部署到您的提供程序并运行它。最终结果是，您应该像现在一样拥有三个应用程序，它们都从同一个Droplet部署。

缺点是您的Droplet是本地的，因此对于每个应用程序，它都要上传3次。

我想您还有第三个选择，就是只使用docker容器。但这有其优点和缺点。

希望有帮助！

重复使用cloudfoundry应用程序，而无需从sratch进行重建

1 个答案: