TOC

Как развернуть несколько приложений PHP с помощью Ansible в Ubuntu 14.04

Вступление

Это руководство является третьим в серии о развертывании приложений PHP с использованием Ansible в Ubuntu 14.04. Https://www.digitalocean.com/community/tutorials/how-to-deploy-a-basic-php-application-using-ansible-on-ubuntu-14-04[first учебник] охватывает основные шаги для развертывания приложение; Второе руководство охватывает более сложные темы, такие как базы данных, демоны очереди и планировщики задач (crons).

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

Мы будем использовать несколько простых приложений Lumen как часть наших примеров. Тем не менее, эти инструкции могут быть легко изменены для поддержки других платформ и приложений, если у вас уже есть свои собственные. Рекомендуется использовать примеры приложений, пока вы не почувствуете себя комфортно, внося изменения в книгу.

Предпосылки

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

  • Две капли настроены, следуя first и second руководства из этой серии.

  • Новая (третья) Ubuntu 14.04 Droplet, установленная как оригинальная PHP Droplet в https://www.digitalocean.com/community/tutorials/how-to-deploy-a-basic-php-application-using-ansible-on -ubuntu-14-04 [первое руководство], с пользователем без полномочий root и ключами SSH. Эта капля, которая будет использоваться для демонстрации развертывания нескольких приложений на нескольких серверах с использованием одной книги воспроизведения Ansible. Мы будем называть IP-адреса оригинальной PHP-капли и этой новой PHP-капли как ` и ` соответственно.

  • Обновленный файл + / etc / hosts + на вашем локальном компьютере со следующими добавленными строками. Вы можете узнать больше об этом файле в https://www.digitalocean.com/community/tutorials/how-to-set-up-apache-virtual-hosts-on-ubuntu-14-04-lts#step-six- % E2% 80% 94-set-up-local-hosts-file- (необязательно) [шаг 6 этого руководства].

Строки для добавления в любом месте в / etc / hosts

laravel.example.com one.example.com two.example.com
laravel.example2.com two.example2.com

Примеры веб-сайтов, которые мы будем использовать в этом учебном пособии: + laravel.example.com +, + one.example.com + и + two.example.com +. Если вы хотите использовать свой собственный домен, вам необходимо обновить https://www.digitalocean.com/community/tutorials/how-to-set-up-and-test-dns-subdomains-with-digitalocean- Вместо этого s-dns-panel # final-configuration [активные записи DNS].

Шаг 1 - Установка переменных Playbook

На этом шаге мы настроим переменные playbook для определения наших новых приложений.

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

Как мы уже видели, Ansible предоставляет переменные, которые вы можете использовать как в определениях ваших задач, так и в шаблонах файлов. Мы еще не видели, как вручную устанавливать переменные. В верхней части вашей книги воспроизведения, наряду с параметрами + hosts + и + tasks +, вы можете определить параметр + vars + и установить там свои переменные.

Если вы еще этого не сделали, замените каталоги на + ansible-php + из предыдущих уроков.

cd ~/ansible-php/

Откройте нашу существующую книгу для редактирования.

nano php.yml

Верх файла должен выглядеть следующим образом:

Верх оригинального php.yml

---
- hosts: php
 sudo: yes

 tasks:
. . .

Чтобы определить переменные, мы можем просто добавить в раздел + vars +, наряду с + hosts +, + sudo + и + tasks +. Для простоты мы начнем с очень простой переменной для имени пользователя + www-data +, например:

Обновлены переменные в php.yml

---
- hosts: php
 sudo: yes




 tasks:
. . .

Затем просмотрите и обновите все вхождения пользователя + www-data с помощью новой переменной` + {{new user}} + `. Этот формат должен быть знаком, так как мы использовали его во внешнем виде и для поиска.

Чтобы найти и заменить с помощью nano, нажмите + CTRL + \ +. Вы увидите приглашение, которое говорит * Поиск (для замены): *. Введите * www-data *, затем нажмите + ENTER. Приглашение изменится на * Заменить на: *. Здесь введите * \ {\ {wwwuser}} * и снова нажмите + ENTER +. Nano проведет вас через каждый экземпляр + www-data и спросит * Заменить этот экземпляр? *. Вы можете нажать + y +, чтобы заменить каждый на один, или + a +, чтобы заменить все.

  • Примечание *: убедитесь, что объявление переменной, которое мы только что добавили вверху, также не изменилось. Должно быть 11 экземпляров + www-data, которые необходимо заменить.

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

Пример задачи в php.yml

- name: create /var/www/ directory
 file: dest=/var/www/ state=directory owner= group= mode=0700

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

Обновленное задание в php.yml

- name: Run artisan migrate
 shell: php /var/www/laravel/artisan migrate --force
 sudo: yes
 sudo_user:
 when: dbpwd.changed

В вашей пьесе это должно происходить каждый раз, когда у вас есть + sudo_user: {{wwwuser}} +. Вы можете использовать глобальный поиск и заменить таким же образом, заменив * sudo_user: \ {\ {wwwuser}} * на * sudo_user: «\ {\ {wwwuser}}» *. Там должно быть четыре строки, которые нуждаются в этом изменении.

После того, как вы изменили все вхождения, сохраните и запустите playbook:

ansible-playbook php.yml --ask-sudo-pass

Не должно быть никаких измененных задач, это означает, что наша переменная + wwwuser + работает правильно.

Шаг 2 - Определение вложенных переменных для сложной конфигурации

В этом разделе мы рассмотрим вложенные переменные для сложных параметров конфигурации.

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

Во-первых, давайте рассмотрим существующий репозиторий git, который мы создали в нашей книге игр:

Существующая задача git в php.yml

- name: Clone git repository
 git: >
   dest=/var/www/laravel
   repo=https://github.com/do-community/do-ansible-adv-php.git
   update=yes
   version=example

Мы можем извлечь следующие полезные части информации: имя (каталог), хранилище, ветвь и домен. Поскольку мы настраиваем несколько приложений, нам также потребуется доменное имя для ответа. Здесь мы будем использовать + laravel.example.com +, но если у вас есть собственный домен, вы можете заменить его.

Это приводит к следующим четырем переменным, которые мы можем определить для этого приложения:

Переменные приложения

name: laravel
repository: https://github.com/do-community/do-ansible-adv-php.git
branch: example
domain: laravel.example.com

Теперь откройте вашу книгу для редактирования:

nano php.yml

В верхнем разделе + vars мы можем добавить ваше приложение в новый список приложений:

Обновлены переменные приложения в php.yml

---
- hosts: php
 sudo: yes

 vars:
   wwwuser: www-data







...

Если вы сейчас запустите свою playbook (используя + ansible-playbook php.yml --ask-sudo-pass +), ничего не изменится, потому что мы еще не настроили наши задачи на использование нашей новой переменной + Applications +. Однако, если вы перейдете к + http: // laravel.example.com / + в вашем браузере, он должен показать наше оригинальное приложение.

Шаг 3 - зацикливание переменных в задачах

В этом разделе мы научимся обходить списки переменных в задачах.

Как упоминалось ранее, списки переменных необходимо циклически повторять в каждой задаче, в которой мы хотим их использовать. Как мы видели в задаче + install packages +, нам нужно определить цикл элементов, а затем применить задачу для каждого элемента в списке.

Откройте книгу для редактирования:

nano php.yml

Сначала мы начнем с простых задач. Где-то посередине вашей пьесы вы найдете следующие две задачи + env +:

Существующие задачи env в php.yml

- name: set APP_DEBUG=false
 lineinfile: dest=/var/www/laravel/.env regexp='^APP_DEBUG=' line=APP_DEBUG=false

- name: set APP_ENV=production
 lineinfile: dest=/var/www/laravel/.env regexp='^APP_ENV=' line=APP_ENV=production

Вы заметите, что в настоящее время они жестко запрограммированы в каталоге + laravel +. Мы хотим обновить его, чтобы использовать свойство + name + для каждого приложения. Чтобы сделать это, мы добавляем опцию + with_items, чтобы перебрать список ваших` + application`. В самой задаче мы заменим ссылку + laravel + для переменной + {{item.name}} +, которая должна быть знакома из форматов, которые мы использовали ранее.

Это должно выглядеть так:

Обновлены задачи .env в php.yml

- name: set APP_DEBUG=false
 lineinfile: dest=/var/www//.env regexp='^APP_DEBUG=' line=APP_DEBUG=false


- name: set APP_ENV=production
 lineinfile: dest=/var/www//.env regexp='^APP_ENV=' line=APP_ENV=production

Затем перейдите к двум задачам Laravel artisan cron. Они могут быть обновлены точно так же, как мы только что сделали с задачами + env +. Мы также добавим + item.name + в параметр + name + для записей cron, поскольку Ansible использует это поле для уникальной идентификации каждой записи cron. Если мы оставим их как есть, мы не сможем иметь несколько сайтов на одном сервере, поскольку они будут постоянно перезаписывать каждый, и будет сохранен только последний.

Задачи должны выглядеть так:

Обновлены задачи cron в php.yml

- name: Laravel Scheduler
 cron: >
   job="run-one php /var/www//artisan schedule:run 1>> /dev/null 2>&1"
   state=present
   user={{ wwwuser }}
   name=" php artisan schedule:run"


- name: Laravel Queue Worker
 cron: >
   job="run-one php /var/www//artisan queue:work --daemon --sleep=30 --delay=60 --tries=3 1>> /dev/null 2>&1"
   state=present
   user={{ wwwuser }}
   name=" Laravel Queue Worker"

Если вы сейчас сохраните и запустите playbook (используя + ansible-playbook php.yml --ask-sudo-pass +), вы должны увидеть только две обновленные задачи + cron + как обновленные. Это связано с изменением параметра + name +. Кроме того, никаких изменений не произошло, и это означает, что список наших приложений работает должным образом, и мы еще не внесли никаких изменений в наш сервер в результате рефакторинга нашей книги игр.

Шаг 4 - Применение зацикленных переменных в шаблонах

В этом разделе мы рассмотрим, как использовать зацикленные переменные в шаблонах.

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

В случае с Nginx нам нужно создать новый файл конфигурации для каждого приложения и сообщить Nginx, что он должен быть включен. Мы также хотим удалить наш оригинальный файл конфигурации + / etc / nginx / sites-available / default + в процессе.

Сначала откройте свою книгу для редактирования:

nano php.yml

Найдите задачу + Configure Nginx + (около середины книги воспроизведения) и обновите ее, как мы сделали с другими задачами:

Обновлена ​​задача nginx в php.yml

- name: Configure nginx
 template: src=nginx.conf dest=/etc/nginx/sites-available/

 notify:
   - restart php5-fpm
   - restart nginx

Пока мы здесь, мы добавим еще две задачи, которые были упомянуты выше. Сначала мы расскажем Nginx о нашем новом файле конфигурации сайта. Это делается с помощью символической ссылки между каталогами + sites-available + и + sites-enabled + в + / var / nginx / +.

Добавьте эту задачу после задачи + Configure nginx +:

Новая задача символической ссылки в php.yml

- name: Configure nginx symlink
 file: src=/etc/nginx/sites-available/{{ item.name }} dest=/etc/nginx/sites-enabled/{{ item.name }} state=link
 with_items: applications
 notify:
   - restart php5-fpm
   - restart nginx

Далее мы хотим удалить файл конфигурации сайта с включенным + default +, чтобы он не вызывал проблем с нашими новыми файлами конфигурации сайта. Это легко сделать с помощью модуля + file:

Новая файловая задача php.yml

- name: Remove default nginx site
 file: path=/etc/nginx/sites-enabled/default state=absent
 notify:
   - restart php5-fpm
   - restart nginx

Обратите внимание, что нам не нужно было зацикливать + application +, так как мы искали один файл.

Блок Nginx в вашей игровой книге теперь должен выглядеть так:

Обновлены задачи nginx в php.yml

- name: Configure nginx
 template: src=nginx.conf dest=/etc/nginx/sites-available/{{ item.name }}
 with_items: applications
 notify:
   - restart php5-fpm
   - restart nginx

- name: Configure nginx symlink
 file: src=/etc/nginx/sites-available/{{ item.name }} dest=/etc/nginx/sites-enabled/{{ item.name }} state=link
 with_items: applications
 notify:
   - restart php5-fpm
   - restart nginx

- name: Remove default nginx site
 file: path=/etc/nginx/sites-enabled/default state=absent
 notify:
   - restart php5-fpm
   - restart nginx

Сохраните вашу книгу и откройте файл + nginx.conf для редактирования:

nano nginx.conf

Обновите файл конфигурации, чтобы он использовал наши переменные:

Обновлен nginx.conf

server {
   listen 80 default_server;
   listen [::]:80 default_server ipv6only=on;

   root /var/www//public;
   index index.php index.html index.htm;

   server_name ;

   location / {
       try_files $uri $uri/ =404;
   }

   error_page 404 /404.html;
   error_page 500 502 503 504 /50x.html;
   location = /50x.html {
       root /var/www//public;
   }

   location ~ \.php$ {
       try_files $uri =404;
       fastcgi_split_path_info ^(.+\.php)(/.+)$;
       fastcgi_pass unix:/var/run/php5-fpm.sock;
       fastcgi_index index.php;
       fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
       include fastcgi_params;
   }
}

Тем не менее, мы еще не закончили. Обратите внимание на + default_server + вверху? Мы хотим включить это только для приложения + laravel +, чтобы оно было установлено по умолчанию. Для этого мы можем использовать базовый оператор IF, чтобы проверить, равно ли + item.name` + laravel, и, если это так, отобразить` + default_server`.

Это будет выглядеть так:

Обновлен файл nginx.conf с условными обозначениями

server {
   listen ;
   listen [::]:80;

Обновите ваш + nginx.conf + соответствующим образом и сохраните его.

Теперь пришло время запустить наш playbook:

ansible-playbook php.yml --ask-sudo-pass

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

http://laravel.example.com/

Queue: YES
Cron: YES

Шаг 5 - Цикл нескольких переменных

На этом этапе мы будем зацикливать несколько переменных в задачах.

Теперь пришло время заняться более сложным примером цикла, в частности, зарегистрированными переменными. Чтобы поддерживать разные состояния и предотвращать ненужное выполнение задач, вы помните, что мы использовали + register: cloned + в нашей задаче Clone git repository для регистрации переменной + cloned + с состоянием задачи. Затем мы использовали + when: cloned | change + в следующих задачах для условного запуска задач. Теперь нам нужно обновить эти ссылки для поддержки цикла приложений.

Сначала откройте свою книгу для редактирования:

nano php.yml

Найдите задачу _ Clone git repository _:

Существующая задача git в php.yml

- name: Clone git repository
 git: >
   dest=/var/www/laravel
   repo=https://github.com/do-community/do-ansible-adv-php.git
   update=yes
   version=example
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 register: cloned

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

Обновленная задача git в php.yml

- name: Clone git repository
 git: >
   dest=/var/www/
   repo=
   update=yes
   version=
 sudo: yes
 sudo_user: "{{ wwwuser }}"

 register: cloned

Теперь двигайтесь вниз по книге, пока не найдете задачу + composer create-project:

Оригинальная задача композитора в php.yml

- name: composer create-project
 composer: command=create-project working_dir=/var/www/laravel optimize_autoloader=no
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 when: cloned|changed

Теперь нам нужно обновить его, чтобы пройти через * и * + application + и + cloned +. Это делается с помощью опции + with_together и передачей в оба` + application` и + cloned. Поскольку + with_together + проходит через две переменные, доступ к элементам осуществляется с помощью + item. # +, Где + # + - это индекс переменной, как она определена. Так, например:

with_together:
- list_one
- list_two

+ item.0 + будет ссылаться на + list_one +, а + item.1 + будет ссылаться на + list_two +.

Это означает, что для + application мы можем получить доступ к свойствам через:` + item.0.name`. Для + cloned + нам нужно передать результаты задач, к которым можно обратиться через + cloned.results +, а затем мы можем проверить, было ли оно изменено через + item.1.changed +.

Это означает, что задача становится:

Обновлена ​​задача композитора в php.yml

- name: composer create-project
 composer: command=create-project working_dir=/var/www/ optimize_autoloader=no
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 when:

Теперь сохраните и запустите ваш playbook:

ansible-playbook php.yml --ask-sudo-pass

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

Шаг 6 - Сложные зарегистрированные переменные и циклы

В этом разделе мы узнаем о более сложных зарегистрированных переменных и циклах.

Наиболее сложной частью преобразования является обработка зарегистрированной переменной, которую мы используем для генерации пароля для нашей базы данных MySQL. Тем не менее, на этом этапе нам не нужно делать намного больше, чем мы не рассмотрели, нам просто нужно обновить сразу несколько задач.

Откройте вашу книгу для редактирования:

nano php.yml

Найдите задачи MySQL, и на нашем начальном этапе мы просто добавим основные переменные, как мы делали в предыдущих задачах:

Обновлены задачи MySQL в php.yml

- name: Create MySQL DB
 mysql_db: name= state=present


- name: Generate DB password
 shell: makepasswd --chars=32
 args:
   creates: /var/www//.dbpw

 register: dbpwd

- name: Create MySQL User
 mysql_user: name= password={{ dbpwd.stdout }} priv=.*:ALL state=present
 when: dbpwd.changed

- name: set DB_DATABASE
 lineinfile: dest=/var/www//.env regexp='^DB_DATABASE=' line=DB_DATABASE=


- name: set DB_USERNAME
 lineinfile: dest=/var/www//.env regexp='^DB_USERNAME=' line=DB_USERNAME=


- name: set DB_PASSWORD
 lineinfile: dest=/var/www//.env regexp='^DB_PASSWORD=' line=DB_PASSWORD={{ dbpwd.stdout }}
 when: dbpwd.changed

- name: Save dbpw file
 lineinfile: dest=/var/www//.dbpw line="{{ dbpwd.stdout }}" create=yes state=present
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 when: dbpwd.changed

- name: Run artisan migrate
 shell: php /var/www//artisan migrate --force
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 when: dbpwd.changed

Далее мы добавим + with_together +, чтобы мы могли использовать пароль нашей базы данных. Для генерации нашего пароля нам нужно перебрать + db pwd.results, и мы сможем получить доступ к паролю из` + item.1.stdout`, так как + apps будет доступен через` + item.0 + `.

Мы можем обновить наш playbook соответственно:

Обновлены задачи MySQL в php.yml

- name: Create MySQL DB
 mysql_db: name={{ item.name }} state=present
 with_items: applications

- name: Generate DB password
 shell: makepasswd --chars=32
 args:
   creates: /var/www/{{ item.name }}/.dbpw
 with_items: applications
 register: dbpwd

- name: Create MySQL User
 mysql_user: name={{  }} password={{  }} priv={{  }}.*:ALL state=present
 when:




- name: set DB_DATABASE
 lineinfile: dest=/var/www/{{ item.name }}/.env regexp='^DB_DATABASE=' line=DB_DATABASE={{ item.name }}
 with_items: applications

- name: set DB_USERNAME
 lineinfile: dest=/var/www/{{ item.name }}/.env regexp='^DB_USERNAME=' line=DB_USERNAME={{ item.name }}
 with_items: applications

- name: set DB_PASSWORD
 lineinfile: dest=/var/www/{{  }}/.env regexp='^DB_PASSWORD=' line=DB_PASSWORD={{  }}
 when:




- name: Save dbpw file
 lineinfile: dest=/var/www/{{  }}/.dbpw line="{{  }}" create=yes state=present
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 when:




- name: Run artisan migrate
 shell: php /var/www/{{  }}/artisan migrate --force
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 when:

После того, как вы обновите свою книгу, сохраните ее и запустите:

ansible-playbook php.yml --ask-sudo-pass

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

Шаг 7 - Добавление дополнительных приложений

На этом шаге мы настроим еще два приложения в нашей игровой книге.

Теперь, когда мы реорганизовали нашу книгу для использования переменных для определения приложений, процесс добавления новых приложений на наш сервер очень прост. Просто добавьте их в список переменных + application +. Это где сила переменных Ansible будет действительно сиять.

Откройте вашу книгу для редактирования:

nano php.yml

В верхней части раздела + vars + найдите блок + Applications +:

Переменная существующих приложений в php.yml

applications:
 - name: laravel
   domain: laravel.example.com
   repository: https://github.com/do-community/do-ansible-adv-php.git
   branch: example

Теперь добавьте еще два приложения:

Обновлена ​​переменная приложения в php.yml

applications:
 - name: laravel
   domain: laravel.example.com
   repository: https://github.com/do-community/do-ansible-adv-php.git
   branch: example

Сохраните свою пьесу.

Теперь пришло время запустить вашу пьесу:

ansible-playbook php.yml --ask-sudo-pass

Этот шаг может занять некоторое время, так как композитор настраивает новые приложения. Когда он закончится, вы заметите, что ряд задач изменился, и если вы посмотрите внимательно, вы заметите, что каждый из зацикленных элементов будет указан в списке. Во-первых, в нашем исходном приложении должно быть написано + ok + или + skipped +, в то время как в двух новых приложениях должно быть написано + change +.

Что еще более важно, если вы посещаете все три домена для своих настроенных сайтов в веб-браузере, вы должны заметить три разных сайта.

Первый должен выглядеть знакомым. Два других должны отображать:

http://one.example.com/

This is example app one!

and

http://two.example.com/

This is example app two!

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

Шаг 8 - Использование переменных хоста

На этом шаге мы извлечем наши переменные для размещения переменных.

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

Переменные хоста могут быть определены inline, внутри файла + hosts +, как мы сделали с переменной + ansible_ssh_user +, или они могут быть определены в выделенном файле для каждого хоста в каталоге + host_vars +.

Сначала создайте новый каталог вместе с нашим файлом + hosts + и нашей книгой воспроизведения. Вызовите каталог + host_vars +:

mkdir host_vars

Далее нам нужно создать файл для нашего хоста. Соглашение, которое использует Ansible, заключается в том, что имя файла совпадает с именем хоста в файле + hosts +. Так, например, если ваш файл + hosts + выглядит так:

Файл Ansible hosts

[php]
ansible_ssh_user=sammy

Затем вы должны создать файл с именем + host_vars / your_first_server_ip +. Давайте создадим это сейчас:

nano host_vars/

Как и наши playbooks, файлы хостов используют YAML для форматирования. Это означает, что мы можем скопировать ваш список + apps в наш новый файл хоста, поэтому он выглядит так:

Новый файл host_vars / your_first_server_ip

---
applications:
 - name: laravel
   domain: laravel.example.com
   repository: https://github.com/do-community/do-ansible-adv-php.git
   branch: example

 - name: one
   domain: one.example.com
   repository: https://github.com/do-community/do-ansible-php-example-one.git
   branch: master

 - name: two
   domain: two.example.com
   repository: https://github.com/do-community/do-ansible-php-example-two.git
   branch: master

Сохраните новый файл hosts и откройте свою книгу воспроизведения для редактирования:

nano php.yml

Обновите верхнюю часть, чтобы удалить весь раздел + application +:

Обновленная вершина php.yml

---
- hosts: php
 sudo: yes

 vars:
   wwwuser: www-data

 tasks:
. . .

Сохраните playbook и запустите его:

ansible-playbook php.yml --ask-sudo-pass

Даже если мы переместили наши переменные из нашей книги воспроизведения в наш файл хоста, выходные данные должны выглядеть точно так же, и Ansible не должна сообщать об изменениях. Как видите, + host_vars + работает точно так же, как + vars + в playbooks; они просто специфичны для хоста.

Переменные, определенные в файлах + host_vars +, также будут доступны во всех книгах воспроизведения, которые управляют сервером, что полезно для общих опций и настроек. Однако будьте осторожны, чтобы не использовать общее имя, которое может означать разные вещи в разных книгах.

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

На этом этапе мы будем использовать наши новые файлы хоста и развертывать приложения на втором сервере.

Во-первых, нам нужно обновить файл + hosts нашим новым хостом. Откройте его для редактирования:

nano hosts

И добавьте в свой новый хост:

Файл Ansible hosts

[php]
your_first_server_ip ansible_ssh_user=sammy
ansible_ssh_user=

Сохраните и закройте файл.

Далее нам нужно создать новый файл hosts, как мы это сделали с первым.

nano host_vars/

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

Новый файл host_vars / your_second_server_ip

---
applications:
 - name: laravel
   domain: laravel.example2.com
   repository: https://github.com/do-community/do-ansible-adv-php.git
   branch: example

 - name: two
   domain: two.example2.com
   repository: https://github.com/do-community/do-ansible-php-example-two.git
   branch: master

Сохраните свою пьесу.

Наконец, мы можем запустить наш playbook:

ansible-playbook php.yml --ask-sudo-pass

Запуск Ansible займет некоторое время, поскольку он настраивает все на вашем втором сервере. Когда он закончится, откройте выбранные вами приложения в браузере (в нашем примере мы использовали + laravel.example2.com + + two.example2.com +) и убедитесь, что они были настроены правильно. Вы должны увидеть конкретные приложения, которые вы выбрали для вашего хост-файла, и ваш исходный сервер не должен иметь никаких изменений.

Заключение

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

Вы заметите, как просто было добавить больше приложений и другой сервер, как только мы разработали структуру playbook. Это сила Ansible, и именно это делает его таким гибким и простым в использовании.

Related