Повторное использование приложения Cloudfoundry без необходимости повторной сборки с помощью sratch
Я развертываю приложение Django с Cloudfoundry. Сборка приложения занимает некоторое время, однако мне нужно запускать приложение с разными командами запуска, и единственное решение, которое у меня есть сегодня, - это полностью перестраивать приложение каждый раз.
С помощью Docker изменить команду запуска очень просто, и не нужно перестраивать весь контейнер, должен быть более эффективный способ сделать это:
Вот запущенные приложения:
- FrontEndApp-Prod: Приложение Django с использованием gunicorn
- OrchesterApp-Prod: Django Celery Camera и Heartbeat
- WorkerApp-Prod: Рабочие Django Celery
Все эти приложения в основном идентичны, они просто используют разные маршруты, конфигурации и команды запуска.
Ниже приведен файл 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
Я абсолютно могу сделать то, что вы говорите. Однако для меня это все еще неоптимально. Все они используют один и тот же «контейнер», только что выполненный с другой командой запуска. Я уверен, что смогу создать шаблон, а затем изменить команду запуска, маршрут, память, количество экземпляров в соответствии с потребностями приложения.
Ответы 1
Я могу придумать для этого два варианта:
Вы можете использовать некоторые из новых функций API v3 и воспользоваться их поддержкой для нескольких процессов в
Procfile. С этим у вас, по сути, будетProfile, подобный этому:web: ./launch_server.sh worker: ./launch_orchester.sh worker: ./launch_worker.shЗатем платформа должна подготовить ваше приложение один раз, но развернуть его три раза в зависимости от капли, полученной в результате размещения. Это красиво, потому что в итоге вы получаете только одно приложение, в котором запущено несколько процессов. Недостатком является то, что на момент написания этой статьи это экспериментальный API, поэтому у него все еще есть некоторые шероховатости, плюс точная поддержка, которую вы получаете, может варьироваться в зависимости от того, как быстро ваш поставщик CF устанавливает новые версии API Cloud Controller.
Вы можете прочитать все подробности об этом здесь:
https://www.cloudfoundry.org/blog/build-cf-push-learn-procfiles/
Вы можете использовать
cf local. Это плагин cf cli, который позволяет вам создавать дроплет локально (постановка выполняется в контейнере докера на вашем локальном компьютере). Затем вы можете взять эту каплю и развернуть ее столько, сколько захотите.Процесс будет выглядеть примерно так, вам просто нужно заполнить некоторые параметры / флаги (намекать запустите
cf local -h, чтобы увидеть все параметры):cf local stagecf local push FrontEndApp-Prodcf local push OrchesterApp-Prodcf local push WorkerApp-Prod
Первая команда создаст файл, оканчивающийся на
.droplet, в вашем текущем каталоге, последующие три команды развернут этот дроплет у вашего провайдера и запустят его. В конечном итоге у вас должно получиться три приложения, как сейчас, которые все развертываются из одной и той же капли.Недостатком является то, что ваша капля является локальной, поэтому вы загружаете ее три раза, по одному разу для каждого приложения.
Я полагаю, у вас также есть третий вариант - просто использовать контейнер докеров. Однако у этого есть свои преимущества и недостатки.
Надеюсь, это поможет!
Почему вы не запускаете три приложения по отдельности? Разве они не работают одновременно? Добавьте дополнительные сведения о том, как должна выглядеть система. Это с циклом DevOps?