TOC

Как использовать файлы карт Salt Cloud для развертывания серверов приложений и обратного прокси-сервера Nginx

Вступление

У вас есть приложение написано, и теперь вам нужно развернуть его. Вы можете создать производственную среду и настроить свое приложение на ВМ, но как вы масштабируете его, когда оно становится популярным? Как вы выкатываете новые версии? Как насчет балансировки нагрузки? И, самое главное, как вы можете быть уверены в правильности конфигурации? Мы можем автоматизировать все это, чтобы сэкономить много времени.

В этом руководстве мы покажем вам, как определить ваше приложение в файле карты Salt Cloud, включая использование пользовательских зерен Salt для назначения ролей вашим серверам и динамической настройки обратного прокси-сервера.

В конце этого урока у вас будет два основных сервера приложений, обратный прокси-сервер Nginx с динамически создаваемой конфигурацией и возможность масштабировать ваше приложение за считанные минуты.

Предпосылки

Чтобы следовать этому уроку, вам понадобится:

  • Одна капля CentOS 7 объемом 1 ГБ. Все команды в этом руководстве будут выполняться от имени пользователя root, поэтому вам не нужно создавать пользователя sudo без полномочий root.

  • Ключ SSH в Droplet для пользователя * root * (т.е. новая пара ключей, созданная в Droplet). Добавьте этот ключ SSH на панель управления DigitalOcean, чтобы использовать его для входа в другие капли DigitalOcean из главной капли. Вы можете использовать How для использования ключей SSH с DigitalOcean Droplets для получения инструкций. + Запишите имя, которое вы назначаете клавише на панели управления DigitalOcean. В этом уроке мы используем имя. Вы также должны отметить местоположение закрытого ключа; по умолчанию это + / root / .ssh / id_rsa +.

  • Персональный токен доступа, который можно создать, следуя инструкциям на этом шаге https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-api-v2#how-to-generate. -a-personal-access-token [Как использовать DigitalOcean APIv2]. Обязательно установите область для чтения и записи.

Шаг 1 - Установка соли и соляного облака

Для начала вам необходимо установить и настроить Salt Cloud на вашем сервере. Для этого урока мы просто используем скрипт начальной загрузки Salt.

Сначала вытравите скрипт начальной загрузки Salt, чтобы установить Salt.

wget -O install_salt.sh https://bootstrap.saltstack.com

Запустите загрузочный скрипт Salt. Мы используем флаг + -M +, чтобы также установить + salt-master +.

sh install_salt.sh -M

Хотя база кода Salt Cloud была объединена с основным проектом Salt, она все еще поставляется отдельно для CentOS. К счастью, скрипт + install_salt + настроил репозитории для нас, поэтому мы можем просто установить + salt-cloud + с помощью yum:

yum install salt-cloud

Теперь мы можем проверить версию Salt Cloud, чтобы подтвердить успешную установку:

salt-cloud --version

Вы должны увидеть результат примерно так:

соляное облако - выходная версия

salt-cloud 2015.5.3 (Lithium)

Обратите внимание, что Salt находится в режиме непрерывного выпуска, поэтому ваша версия может немного отличаться от приведенной выше.

Шаг 2 - Настройка Соленого облака

В этом разделе мы настроим Salt Cloud для подключения к DigitalOcean и определим некоторые профили для наших дроплетов.

Настройка файла провайдера DigitalOcean

В Salt Cloud provider files - это место, где вы определяете, где будут создаваться новые виртуальные машины. Поставщики определены в каталоге + / etc / salt / cloud.providers.d +

Создайте и откройте файл поставщика DigitalOcean, используя + nano + или ваш любимый текстовый редактор.

nano /etc/salt/cloud.providers.d/digital_ocean.conf

Вставьте текст ниже, заменив переменные на ваши, а именно на IP-адрес сервера и токен доступа, а также имя и файл ключа SSH, если вы их настроили.

/etc/salt/cloud.providers.d/digital_ocean.conf

### /etc/salt/cloud.providers.d/digital_ocean.conf ###
######################################################
do:
 provider: digital_ocean
 minion:
   master:

 # DigitalOcean Access Token
 personal_access_token:

 # This is the name of your SSH key in your Digital Ocean account
 # as it appears in the control panel.
 ssh_key_name:

 # This is the path on disk to the private key for your Digital Ocean account
 ssh_key_file:

Вам необходимо заблокировать разрешения для вашего файла ключей SSH. В противном случае SSH откажется его использовать. Предполагая, что ваша папка находится по умолчанию, + / root / .ssh / id_rsa +, вы можете сделать это с помощью:

chmod 600 /root/.ssh/id_rsa

Настройка профилей для разворачиваемых серверов

В Salt Cloud profiles - это отдельные описания виртуальных машин, которые привязаны к поставщику (например, «Ubuntu VM на 512 МБ на DigitalOcean»). Они определены в каталоге + / etc / salt / cloud.profiles.d +.

Создайте и откройте файл профиля.

nano /etc/salt/cloud.profiles.d/digital_ocean.conf

Вставьте следующее в файл. Никаких изменений не требуется:

/etc/salt/cloud.profiles.d/digital_ocean.conf

### /etc/salt/cloud.profiles.d/digital_ocean.conf ###
#####################################################

ubuntu_512MB_ny3:
 provider: do
 image: ubuntu-14-04-x64
 size: 512MB
 location: nyc3
 private_networking: True

ubuntu_1GB_ny3:
 provider: do
 image: ubuntu-14-04-x64
 size: 1GB
 location: nyc3
 private_networking: True

Сохраните и закройте файл. Этот файл определяет два профиля:

  • Виртуальная машина Ubuntu 14.04 с 512 МБ памяти, развернутая в регионе Нью-Йорк 3.

  • Виртуальная машина Ubuntu 14.04 с 1 ГБ памяти, развернутая в регионе Нью-Йорк 3.

Если вы хотите использовать изображение, отличное от Ubuntu 14.04, вы можете использовать Salt Cloud, чтобы вывести список всех доступных имен изображений в DigitalOcean с помощью следующей команды:

salt-cloud --list-images do

Это покажет все стандартные изображения DigitalOcean, а также пользовательские изображения, которые вы сохранили в своей учетной записи с помощью инструмента моментальных снимков. Вы можете заменить имя изображения или регион, который мы использовали в файле поставщика, на другое имя изображения из этого списка. Если вы это сделаете, обязательно используйте поле из этого вывода в настройках в файле профиля.

Проверьте свою конфигурацию с помощью быстрого запроса.

salt-cloud -Q

Вы должны увидеть что-то вроде следующего.

Пример вывода соленого облака -Q

[INFO    ] salt-cloud starting
do:
   ----------
   digital_ocean:
       ----------
       centos-salt:
           ----------
           id:
               2806501
           image_id:
               6372108
           public_ips:
               192.241.247.229
           size_id:
               63
           state:
               active

Это означает, что Salt Cloud общается с вашей учетной записью DigitalOcean, и у вас настроены два основных профиля.

Шаг третий - Написание простого файла карты

Файл карты - это файл YAML, в котором перечислены профили и количество серверов, которые вы хотите создать. Мы начнем с простого файла карты, а затем создадим его в следующем разделе.

Используя приведенные выше профили, предположим, что вы хотите, чтобы два сервера приложений объемом 1 ГБ имели один обратный прокси-сервер объемом 512 МБ. Мы создадим файл с именем + / etc / salt / cloud.maps.d / do-app-with-rproxy.map + и определим приложение.

Сначала создайте файл:

nano /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Вставьте следующий текст. Никаких изменений не требуется:

/etc/salt/cloud.maps.d/do-app-with-proxy.map

### /etc/salt/cloud.maps.d/do-app-with-rproxy.map ####
######################################################
ubuntu_512MB_ny3:
 - nginx-rproxy

ubuntu_1GB_ny3:
 - appserver-01
 - appserver-02

Это оно! Это примерно так же просто, как получить файл карты. Идите вперед и разверните эти серверы с помощью:

salt-cloud -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Как только команда завершится, подтвердите успех быстрым пингом:

salt '*' test.ping

Вы должны увидеть следующее:

[label salt '*' test.ping
appserver-01:
   True
appserver-02:
   True
nginx-rproxy:
   True

После того, как вы успешно создали виртуальные машины в файле карты, удалить их так же просто:

salt-cloud -d -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Обязательно используйте эту команду с осторожностью! Это удалит все виртуальные машины, указанные в этом файле карты.

Шаг четвертый - Написание более реалистичного файла карты

Этот файл карты работал нормально, но даже сценарий оболочки мог раскрутить набор виртуальных машин. Что нам нужно, это определить площадь нашего приложения. Давайте вернемся к нашему файлу карты и добавим еще несколько вещей; снова откройте файл карты.

nano /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Удалите предыдущее содержимое файла и поместите в него следующее. Никаких изменений не требуется:

/etc/salt/cloud.maps.d/do-app-with-proxy.map

### /etc/salt/cloud.maps.d/do-app-with-rproxy.map ###
#####################################################
ubuntu_512MB_ny3:
 - nginx-rproxy:
     minion:
       mine_functions:
         network.ip_addrs:
           interface: eth0
       grains:
         roles: rproxy
ubuntu_1GB_ny3:
 - appserver-01:
     minion:
       mine_functions:
         network.ip_addrs:
           interface: eth0
       grains:
         roles: appserver
 - appserver-02:
     minion:
       mine_functions:
         network.ip_addrs:
           interface: eth0
       grains:
         roles: appserver

Теперь мы куда-то добираемся! Это выглядит много, но мы добавили только две вещи. Давайте рассмотрим два дополнения: раздел + mine_functions + и раздел + grains +.

Мы сказали Salt Cloud изменить конфигурацию Salt Minion для этих виртуальных машин и добавить несколько пользовательских grains. В частности, зерна дают обратной прокси-виртуальной машине роль + rproxy + и дают серверам приложений роль + appserver +. Это пригодится, когда нам нужно будет динамически настроить обратный прокси.

+ Mine_functions + также будет добавлен в конфигурацию Salt Minion. Он поручает Миньону отправить IP-адрес, найденный на * eth0 *, обратно Мастеру соли, чтобы он был сохранен в Salt mine. Это означает, что Salt Master автоматически узнает IP-адрес недавно созданной капли, и нам не нужно его настраивать. Мы будем использовать это в следующей части.

Шаг пятый - Определение обратного прокси

Перед нами стоит общая задача: установить веб-сервер обратного прокси-сервера и настроить его. Для этого урока мы будем использовать Nginx в качестве обратного прокси.

Написание Соляного состояния Nginx

Пришло время пачкать руки и написать несколько соляных состояний. Сначала создайте местоположение дерева состояний соли по умолчанию:

mkdir /srv/salt

Перейдите в этот каталог и создайте еще один каталог только для nginx:

cd /srv/salt
mkdir /srv/salt/nginx

Перейдите в этот каталог и, используя ваш любимый редактор, создайте новый файл с именем + rproxy.sls +:

cd /srv/salt/nginx
nano /srv/salt/nginx/rproxy.sls

Поместите следующее в этот файл. Никаких изменений не требуется:

/srv/salt/nginx/rproxy.sls

### /srv/salt/nginx/rproxy.sls ###
##################################

### Install Nginx and configure it as a reverse proxy, pulling the IPs of
### the app servers from the Salt Mine.

nginx-rproxy:
 # Install Nginx
 pkg:
   - installed
   - name: nginx
 # Place a customized Nginx config file
 file:
   - managed
   - source: salt://nginx/files/awesome-app.conf.jin
   - name: /etc/nginx/conf.d/awesome-app.conf
   - template: jinja
   - require:
     - pkg: nginx-rproxy
 # Ensure Nginx is always running.
 # Restart Nginx if the config file changes.
 service:
   - running
   - enable: True
   - name: nginx
   - require:
     - pkg: nginx-rproxy
   - watch:
     - file: nginx-rproxy
 # Restart Nginx for the initial installation.
 cmd:
   - run
   - name: service nginx restart
   - require:
     - file: nginx-rproxy

Это состояние делает следующее:

  • Устанавливает Nginx.

  • Помещает наш пользовательский файл конфигурации в + / etc / nginx / conf.d / awesome-app.conf +.

  • Гарантирует, что Nginx запущен.

Наше состояние Salt просто устанавливает Nginx и удаляет файл конфигурации; действительно интересный контент находится в конфиге.

Написание файла конфигурации обратного прокси-сервера Nginx

Давайте создадим еще один каталог для нашего конфигурационного файла:

mkdir /srv/salt/nginx/files
cd /srv/salt/nginx/files

И откройте файл конфигурации:

nano /srv/salt/nginx/files/awesome-app.conf.jin

Поместите следующее в файл конфигурации. Никаких изменений не требуется, если только вы не используете частные сети; в этом случае измените + 1 + на + 0 +, как указано в строке:

/srv/salt/nginx/files/awesome-app.conf.jin

### /srv/salt/nginx/files/awesome-app.conf.jin ###
##################################################

### Configuration file for Nginx to act as a
### reverse proxy for an app farm.

# Define the app servers that we're in front of.
upstream awesome-app {
   {% for server, addrs in salt['mine.get']('roles:appserver', 'network.ip_addrs', expr_form='grain').items() %}
   server {{ addrs[0] }}:1337;
   {% endfor %}
}

# Forward all port 80 http traffic to our app farm, defined above as 'awesome-app'.
server {
   listen       80;
   server_name  {{ salt['network.ip_addrs']()[] }};  #
                                                      #     DigitalOcean's private networking.

   access_log  /var/log/nginx/awesome-app.access.log;
   error_log  /var/log/nginx/awesome-app.error.log;

   ## forward request to awesome-app ##
   location / {
    proxy_pass  http://awesome-app;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Мы используем расширение + .jin +, чтобы сказать себе, что файл содержит Jinja templating. Шаблоны Jinja позволяют нам помещать небольшое количество логики в наши текстовые файлы, чтобы мы могли динамически генерировать детали конфигурации.

Этот файл конфигурации инструктирует Nginx взять весь HTTP-трафик порта 80 и перенаправить его на нашу ферму приложений. Он состоит из двух частей: апстрим (наша ферма приложений) и конфигурация, выполняющая роль прокси-сервера между пользователем и нашей фермой приложений.

Давайте поговорим о верхнем течении. Обычный не шаблонный восходящий поток указывает набор IP-адресов. Однако мы не знаем, какими будут IP-адреса наших миньонов, пока они не существуют, и мы не редактируем файлы конфигурации вручную. (В противном случае не было бы никаких причин использовать соль!)

Помните строки + mine_function + в нашем файле карты? Миньоны отдают свои IP-адреса Salt Master, чтобы хранить их как раз для такого случая. Давайте посмотрим на эту линию дзиндзя немного ближе:

Выдержка из дзиндзя

{% for server, addrs in salt['mine.get']('roles:appserver', 'network.ip_addrs', expr_form='grain').items() %}

Это цикл for в Jinja, выполняющий произвольную функцию Salt. В этом случае он работает http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.mine.html#salt.modules.mine.get [+ mine.get +]. Параметры:

  • + role: appserver + - Это говорит о том, что вы должны получать информацию только от миньонов, у которых есть роль «appserver».

  • + network.ip_addrs + - это данные, которые мы хотим получить из шахты. Мы также указали это в нашем файле карты.

  • + expr_form = 'grain' + - Это говорит Солту, что мы нацеливаемся на наших миньонов, основываясь на их зернах. Подробнее о сопоставлении по зерну можно найти на http://docs.saltstack.com/en/latest/topics/targeting/grains.html[the Saltstack doc.

После этого цикла переменная + {{addrs}} + содержит список IP-адресов (даже если это только один адрес). Поскольку это список, мы должны получить первый элемент с помощью + [0] +.

Это вверх по течению. Что касается имени сервера:

server_name  {{ salt['network.ip_addrs']()[0] }};

Это тот же трюк, что и в вызове Соляной шахты (вызов функции Salt в Jinja). Это просто проще. Он вызывает http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.network.html#salt.modules.network.ip_addrs [+ network.ip_addrs +] и берет первый элемент возвращенного списка. Это также позволяет нам избежать необходимости редактировать файл вручную.

Шаг шестой - определение фермы приложений

Обратный прокси не имеет большого значения, если за ним нет приложения. Давайте создадим небольшое приложение Node.js, которое просто сообщает IP-адрес сервера, на котором он находится (чтобы мы могли подтвердить, что достигли обеих машин).

Создайте новый каталог с именем + awesome-app + и переместитесь туда.

mkdir -p /srv/salt/awesome-app
cd /srv/salt/awesome-app

Создайте новый файл состояния приложения с именем + app.sls +.

nano /srv/salt/awesome-app/app.sls

Поместите следующее в файл. Никаких изменений не требуется:

/srv/salt/awesome-app/app.sls

### /srv/salt/awesome-app/app.sls ###
#####################################

### Install Nodejs and start a simple
### web application that reports the server IP.

install-app:
 # Install prerequisites
 pkg:
   - installed
   - names:
     - node
     - npm
     - nodejs-legacy  # workaround for Debian systems
 # Place our Node code
 file:
   - managed
   - source: salt://awesome-app/files/app.js
   - name: /root/app.js
 # Install the package called 'forever'
 cmd:
   - run
   - name: npm install forever -g
   - require:
     - pkg: install-app

run-app:
 # Use 'forever' to start the server
 cmd:
   - run
   - name: forever start app.js
   - cwd: /root

Этот файл состояния делает следующее:

  • Установите пакеты + nodejs,` + npm` и + nodejs-legacy.

  • Добавляет файл JavaScript, который будет нашим простым приложением.

  • Использует NPM для установки https://www.npmjs.org/package/forever [+ Forever +].

  • Запускает приложение.

Теперь создайте (маленький) код приложения:

mkdir /srv/salt/awesome-app/files
cd /srv/salt/awesome-app/files

Создайте файл:

nano /srv/salt/awesome-app/files/app.js

Поместите следующее в это. Никаких изменений не требуется:

/srv/salt/awesome-app/files/app.js

/* /srv/salt/awesome-app/files/app.js

  A simple Node.js web application that
  reports the server's IP.
  Shamefully stolen from StackOverflow:
  http://stackoverflow.com/questions/10750303/how-can-i-get-the-local-ip-address-in-node-js
*/

var os = require('os');
var http = require('http');

http.createServer(function (req, res) {
 var interfaces = os.networkInterfaces();
 var addresses = [];
 for (k in interfaces) {
     for (k2 in interfaces[k]) {
         var address = interfaces[k][k2];
         if (address.family == 'IPv4' && !address.internal) {
             addresses.push(address.address)
         }
     }
 }

 res.writeHead(200, {'Content-Type': 'text/plain'});
 res.end(JSON.stringify(addresses));
}).listen(1337, '0.0.0.0');
console.log('Server listening on port 1337');

Это простой сервер Node.js, который выполняет одно действие: принимает HTTP-запросы через порт 1337 и отвечает IP-адресами сервера.

На этом этапе у вас должна быть файловая структура, которая выглядит следующим образом:

Файловая структура

/srv/salt
        ├── awesome-app
        │   ├── app.sls
        │   └── files
        │       └── app.js
        └── nginx
            ├── rproxy.sls
            └── files
                └── awesome-app.conf.jin

Шаг седьмой - Развертывание приложения

Осталось только развернуть приложение.

Развертывание серверов с помощью Salt Cloud

Запустите ту же команду развертывания, что и сейчас, и теперь будут использоваться все конфигурации, которые мы выполняли.

salt-cloud -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Дождитесь окончания Соленого Облака; это займет некоторое время. Как только он вернется, подтвердите успешное развертывание, отправив команду ping на серверы приложений:

salt -G 'roles:appserver' test.ping

Тебе следует увидеть:

Вывод ping сервера приложений

appserver-02:
   True
appserver-01:
   True

Пинг обратного прокси:

salt -G 'roles:rproxy' test.ping

Тебе следует увидеть:

Обратный прокси-вывод

nginx-rproxy:
   True

Как только у вас появятся виртуальные машины, пора дать им работу.

Создайте приложение

Затем выполните команды Salt, чтобы автоматически построить ферму приложений и обратный прокси-сервер.

Создайте ферму приложений:

salt -G 'roles:appserver' state.sls awesome-app.app

Будет достаточно продукции, но она должна заканчиваться следующим:

Summary
------------
Succeeded: 6 (changed=6)
Failed:    0
------------
Total states run:     6

Создайте обратный прокси:

salt -G 'roles:rproxy' state.sls nginx.rproxy

Опять же, будет значительный объем продукции, заканчивающийся следующим:

Summary
------------
Succeeded: 4 (changed=4)
Failed:    0
------------
Total states run:     4

Так что же здесь произошло?

Первая команда (с серверами приложений) приняла состояние Salt, которое мы написали ранее, и выполнила его на двух серверах приложений. В результате на двух машинах с одинаковыми конфигурациями выполнялись идентичные версии кода.

Вторая команда (обратный прокси) выполнила состояние Salt, которое мы написали для Nginx. Он установил Nginx и файл конфигурации, динамически заполняя IP-адреса нашей фермы приложений в файле конфигурации.

После того, как эти Salt будут выполнены, вы можете проверить, чтобы подтвердить успешное развертывание. Найдите IP вашего обратного прокси:

salt -G 'roles:rproxy' network.ip_addrs

Вы можете получить два IP-адреса, если используете Droplet в частных сетях.

Подключите общедоступный IP-адрес к своему браузеру и посетите веб-страницу! Нажмите несколько раз обновить, чтобы подтвердить, что Nginx на самом деле прокси между двумя серверами приложений, которые вы создали. Вы должны увидеть, как меняются IP-адреса, подтверждая, что вы действительно подключаетесь к нескольким серверам приложений.

Если вы получаете один и тот же IP-адрес, несмотря на обновление, это, вероятно, связано с кэшированием в браузере. Вместо этого вы можете попробовать использовать + curl +, чтобы показать, что Nginx прокси-сервер между вашими серверами приложений. Выполните эту команду несколько раз и просмотрите результат:

curl http://

Мы можем сделать это на несколько шагов дальше и completely автоматизировать развертывание приложения с помощью OverState. Это позволило бы нам создать единую команду, чтобы сообщить Salt, например, сначала о создании серверов приложений, а затем перейти к созданию обратного прокси-сервера, гарантируя порядок нашего процесса сборки.

Шаг восьмой - Увеличение (необязательно)

Смысл использования Salt - автоматизировать процесс сборки; Смысл использования Salt Cloud и файлов карт - легко масштабировать развертывание. Если вы хотите добавить больше серверов приложений (скажем, еще два) в ваше развертывание, вы должны обновить файл карты, чтобы он выглядел следующим образом:

/etc/salt/cloud.maps.d/do-app-with-proxy.map

### /etc/salt/cloud.maps.d/do-app-with-rproxy.map ###
#####################################################
ubuntu_512MB_ny3:
 - nginx-rproxy:
     minion:
       mine_functions:
         network.ip_addrs:
           interface: eth0
       grains:
         roles: rproxy
ubuntu_1GB_ny3:
- appserver-01:
   minion:
     mine_functions:
       network.ip_addrs:
           interface: eth0
     grains:
       roles: appserver
- appserver-02:
   minion:
     mine_functions:
       network.ip_addrs:
           interface: eth0
     grains:
       roles: appserver
- appserver-03:
   minion:
     mine_functions:
       network.ip_addrs:
           interface: eth0
     grains:
       roles: appserver
- appserver-04:
   minion:
     mine_functions:
       network.ip_addrs:
           interface: eth0
     grains:
       roles: appserver

После этого обновления вы повторно запустите команду и две команды из шага 6:

salt-cloud -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map
salt -G 'roles:appserver' state.sls awesome-app.app
salt -G 'roles:rproxy' state.sls nginx.rproxy

Существующие серверы не будут затронуты повторным запуском Salt, новые серверы будут созданы в соответствии со спецификацией, а конфигурация Nginx будет обновлена, чтобы начать маршрутизацию трафика на новые серверы приложений.

Заключение

Развертывание приложения, которое просто сообщает IP-адрес сервера, не очень полезно. К счастью, этот подход не ограничивается приложениями Node.js. Соль не заботится о том, на каком языке написано ваше приложение.

Если вы хотите использовать этот фреймворк для развертывания своего собственного приложения, вам просто нужно автоматизировать задачу установки приложения на сервер (с помощью сценария или с помощью состояний Salt) и заменить наш пример собственной автоматизацией.

Как Salt автоматизирует процессы в ваших каплях, Salt Cloud автоматизирует процессы в вашем облаке. Наслаждайтесь!

Related