TOC

Bereitstellen mehrerer PHP-Anwendungen mit Ansible unter Ubuntu 14.04

Einführung

Dieses Tutorial ist das dritte in einer Reihe über die Bereitstellung von PHP-Anwendungen mit Ansible unter Ubuntu 14.04. Das https://www.digitalocean.com/community/tutorials/how-to-deploy-a-basic-php-application- using-ansible-on-ubuntu-14-04[first tutorial] behandelt die grundlegenden Schritte für die Bereitstellung eine Bewerbung; Das second tutorial behandelt fortgeschrittenere Themen wie Datenbanken, Warteschlangendämonen und Taskplaner (crons).

In diesem Tutorial bauen wir auf dem auf, was wir in den vorherigen Tutorials gelernt haben, indem wir unser Ansible-Playbook mit einer Anwendung in ein Playbook verwandeln, das die Bereitstellung mehrerer PHP-Anwendungen auf einem oder mehreren Servern unterstützt. Dies ist der letzte Teil des Puzzles, wenn es darum geht, mit Ansible Ihre Anwendungen mit minimalem Aufwand bereitzustellen.

Als Teil unserer Beispiele werden wir einige einfache Lumen -Anwendungen verwenden. Diese Anweisungen können jedoch leicht geändert werden, um andere Frameworks und Anwendungen zu unterstützen, wenn Sie bereits über eigene verfügen. Es wird empfohlen, die Beispielanwendungen zu verwenden, bis Sie Änderungen am Playbook vornehmen können.

Voraussetzungen

Um diesem Tutorial zu folgen, benötigen Sie:

Zeilen, die an einer beliebigen Stelle in / etc / hosts hinzugefügt werden sollen

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

Die Beispiel-Websites, die wir in diesem Tutorial verwenden, sind "+ laravel.example.com ", " one.example.com " und " two.example.com +". Wenn Sie Ihre eigene Domain verwenden möchten, müssen Sie Ihre https://www.digitalocean.com/community/tutorials/how-to-set-up-and-test-dns-subdomains-with-digitalocean- aktualisieren. Stattdessen s-dns-panel # final-configuration [aktive DNS-Einträge].

Schritt 1 - Einstellen der Playbook-Variablen

In diesem Schritt werden wir Playbook-Variablen einrichten, um unsere neuen Anwendungen zu definieren.

In den vorherigen Tutorials haben wir alle Konfigurationsspezifikationen fest programmiert. Dies ist bei vielen Playbooks üblich, die bestimmte Aufgaben für eine bestimmte Anwendung ausführen. Wenn Sie jedoch mehrere Anwendungen unterstützen oder den Umfang Ihres Playbooks erweitern möchten, ist es nicht mehr sinnvoll, alles hart zu codieren.

Wie wir bereits gesehen haben, bietet Ansible Variablen, die Sie sowohl in Ihren Aufgabendefinitionen als auch in Dateivorlagen verwenden können. Was wir noch nicht gesehen haben, ist das manuelle Setzen von Variablen. Im oberen Bereich Ihres Playbooks können Sie neben den Parametern "+ hosts " und " tasks " einen " vars +" -Parameter definieren und Ihre Variablen dort festlegen.

Wenn Sie dies noch nicht getan haben, ändern Sie die Verzeichnisse aus den vorherigen Tutorials in "+ ansible-php +".

cd ~/ansible-php/

Öffne unser vorhandenes Playbook zur Bearbeitung.

nano php.yml

Der Anfang der Datei sollte folgendermaßen aussehen:

Anfang der ursprünglichen php.yml

---
- hosts: php
 sudo: yes

 tasks:
. . .

Um Variablen zu definieren, können Sie einfach in einem Abschnitt "+ vars " neben " hosts ", " sudo " und " tasks " hinzufügen. Um die Sache einfach zu halten, beginnen wir mit einer sehr einfachen Variablen für den Benutzernamen ` www-data +`, wie folgt:

Aktualisierte Versionen in php.yml

---
- hosts: php
 sudo: yes




 tasks:
. . .

Als nächstes müssen Sie alle Vorkommen des Benutzers "+ www-data" mit der neuen Variablen "+ {{www user}} +" aktualisieren. Dieses Format sollte bekannt sein, da wir es in Looks und für Lookups verwendet haben.

Um mit nano zu suchen und zu ersetzen, drücken Sie + STRG + \ +. Sie erhalten eine Eingabeaufforderung mit der Aufschrift * Suchen (zum Ersetzen): *. Geben Sie * www-data * ein und drücken Sie dann + ENTER. Die Eingabeaufforderung ändert sich in * Ersetzen durch: *. Geben Sie hier * \ {\ {www user}} * ein und drücken Sie erneut die Eingabetaste. Nano führt Sie durch jede Instanz von + www-data und fragt * Diese Instanz ersetzen? *. Sie können "+ y " drücken, um jeden durch einen zu ersetzen, oder " a +", um alle zu ersetzen.

  • Hinweis *: Stellen Sie sicher, dass die Variablendeklaration, die wir oben hinzugefügt haben, nicht geändert wird. Es sollten 11 Instanzen von "+ www-data +" vorhanden sein, die ersetzt werden müssen.

Bevor wir weitermachen, gibt es etwas, auf das wir achten müssen, wenn es um Variablen geht. Normalerweise können wir sie einfach so hinzufügen, wenn sie sich in einer längeren Zeile befinden:

Beispielaufgabe in php.yml

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

Wenn die Variable jedoch der einzige Wert in der Zeichenfolge ist, müssen wir sie in Anführungszeichen setzen, damit der YAML-Parser sie richtig verstehen kann:

Aktualisierte Aufgabe in php.yml

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

In deinem Playbook muss dies jedes Mal geschehen, wenn du "+ sudo_user: {{wwwuser}} +" hast. Sie können ein globales Suchen und Ersetzen auf dieselbe Weise durchführen, indem Sie * sudo_user: \ {\ {wwwuser}} * durch * sudo_user: “\ {\ {wwwuser}}” * ersetzen. Es sollten vier Zeilen vorhanden sein, die diese Änderung benötigen.

Wenn Sie alle Vorkommen geändert haben, speichern Sie das Playbook und führen Sie es aus:

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

Es sollten keine geänderten Tasks vorhanden sein. Dies bedeutet, dass unsere Variable "+ wwwuser +" ordnungsgemäß funktioniert.

Schritt 2 - Definition verschachtelter Variablen für komplexe Konfigurationen

In diesem Abschnitt befassen wir uns mit Verschachtelungsvariablen für komplexe Konfigurationsoptionen.

Im vorherigen Schritt haben wir eine Basisvariable eingerichtet. Es ist jedoch auch möglich, Variablen zu verschachteln und Listen von Variablen zu definieren. Dies bietet die Funktionalität, die wir benötigen, um die Liste der Sites zu definieren, die wir auf unserem Server einrichten möchten.

Betrachten wir zunächst das vorhandene Git-Repository, das wir in unserem Playbook eingerichtet haben:

Bestehende Git-Aufgabe in 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

Wir können die folgenden nützlichen Informationen extrahieren: Name (Verzeichnis), Repository, Zweigstelle und Domäne. Da wir mehrere Anwendungen einrichten, benötigen wir auch einen Domänennamen, um darauf zu antworten. In diesem Fall verwenden wir "+ laravel.example.com +". Wenn Sie jedoch eine eigene Domain haben, können Sie diese ersetzen.

Daraus ergeben sich die folgenden vier Variablen, die wir für diese Anwendung definieren können:

Anwendungsvariablen

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

Öffnen Sie jetzt Ihr Playbook zum Bearbeiten:

nano php.yml

Im oberen Abschnitt "+ vars" können wir Ihre Bewerbung in eine neue Bewerbungsliste aufnehmen:

Aktualisierte Anwendungsvariablen in php.yml

---
- hosts: php
 sudo: yes

 vars:
   wwwuser: www-data







...

Wenn Sie Ihr Playbook jetzt ausführen (mit "+ ansible-playbook php.yml --ask-sudo-pass "), ändert sich nichts, da wir unsere Aufgaben für die Verwendung unserer neuen Variablen " applications " noch nicht eingerichtet haben. Wenn Sie jedoch in Ihrem Browser zu " http: // laravel.example.com / +" wechseln, sollte unsere ursprüngliche Anwendung angezeigt werden.

Schritt 3 - Schleifen von Variablen in Aufgaben

In diesem Abschnitt lernen wir, wie man Variablenlisten in Tasks durchläuft.

Wie bereits erwähnt, müssen Variablenlisten in jeder Aufgabe, in der sie verwendet werden sollen, durchlaufen werden. Wie wir bei der Aufgabe "+ install packages +" gesehen haben, müssen wir eine Elementschleife definieren und dann die Aufgabe für jedes Element in der Liste anwenden.

Öffne dein Playbook zum Bearbeiten:

nano php.yml

Wir werden zunächst mit einigen einfachen Aufgaben beginnen. In der Mitte Ihres Playbooks sollten Sie die folgenden beiden Aufgaben finden:

Bestehende env Aufgaben in 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

Sie werden feststellen, dass sie derzeit mit dem Verzeichnis "+ laravel " fest codiert sind. Wir möchten es aktualisieren, um die Eigenschaft " name " für jede Anwendung zu verwenden. Dazu fügen wir die Option " with_items " hinzu, um unsere Liste " applications " zu durchlaufen. Innerhalb der eigentlichen Aufgabe tauschen wir die Referenz " laravel " gegen die Variable " {{item.name}} +" aus, die aus den zuvor verwendeten Formaten bekannt sein sollte.

Es sollte so aussehen:

Env-Tasks in php.yml aktualisiert
- 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

Fahren Sie als Nächstes mit den beiden Cron-Aufgaben von Laravel fort. Sie können genauso aktualisiert werden, wie wir es gerade mit den + env + - Tasks gemacht haben. Wir werden auch das + item.name + in den + name + Parameter für die Cron-Einträge einfügen, da Ansible dieses Feld verwendet, um jeden Cron-Eintrag eindeutig zu identifizieren. Wenn wir sie so lassen, wie sie sind, können wir nicht mehrere Sites auf demselben Server haben, da sie jede ständig überschreiben und nur die letzte gespeichert wird.

Die Aufgaben sollten so aussehen:

Cron-Tasks in php.yml aktualisiert

- 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"

Wenn Sie das Playbook jetzt speichern und ausführen (mit "+ ansible-playbook php.yml --ask-sudo-pass "), sollten nur die beiden aktualisierten " cron " - Tasks als aktualisiert angezeigt werden. Dies ist auf die Änderung des Parameters " name +" zurückzuführen. Abgesehen davon wurden keine Änderungen vorgenommen. Dies bedeutet, dass unsere Anwendungsliste wie erwartet funktioniert und wir aufgrund der Überarbeitung unseres Playbooks noch keine Änderungen an unserem Server vorgenommen haben.

Schritt 4 - Anwenden von geloopten Variablen in Vorlagen

In diesem Abschnitt wird die Verwendung von Loop-Variablen in Vorlagen behandelt.

Das Durchlaufen von Variablen in Vorlagen ist sehr einfach. Sie können genauso wie alle anderen Variablen in Tasks verwendet werden. Die Komplexität ergibt sich, wenn Sie sowohl Dateipfade als auch Variablen berücksichtigen. In einigen Fällen müssen wir den Dateinamen berücksichtigen und aufgrund der neuen Datei sogar andere Befehle ausführen.

Im Fall von Nginx müssen wir für jede Anwendung eine neue Konfigurationsdatei erstellen und Nginx mitteilen, dass diese aktiviert werden soll. Wir möchten dabei auch unsere ursprüngliche Konfigurationsdatei "+ / etc / nginx / sites-available / default +" entfernen.

Öffnen Sie zuerst Ihr Playbook zum Bearbeiten:

nano php.yml

Suchen Sie die Aufgabe "+ Nginx konfigurieren" (in der Mitte des Playbooks) und aktualisieren Sie sie wie bei den anderen Aufgaben:

Nginx task in php.yml aktualisiert

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

 notify:
   - restart php5-fpm
   - restart nginx

Während wir hier sind, werden wir zwei weitere Aufgaben hinzufügen, die oben erwähnt wurden. Zuerst werden wir Nginx über unsere neue Site-Konfigurationsdatei informieren. Dies geschieht mit einem Symlink zwischen den Verzeichnissen "+ sites-available" und "+ sites-enabled" in "+ / var / nginx / +".

Fügen Sie diese Aufgabe nach der Aufgabe "+ Configure nginx +" hinzu:

Neue Symlink-Aufgabe in 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

Als nächstes möchten wir die "+ default " aktivierte Site-Konfigurationsdatei entfernen, damit sie keine Probleme mit unseren neuen Site-Konfigurationsdateien verursacht. Das geht ganz einfach mit dem ` file` Modul:

Neue Datei task php.yml

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

Beachten Sie, dass wir nicht "+ applications +" schleifen mussten, da wir nach einer einzelnen Datei suchten.

Der Nginx-Block in Ihrem Playbook sollte jetzt so aussehen:

Nginx-Tasks in php.yml aktualisiert

- 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

Speichern Sie Ihr Playbook und öffnen Sie die Datei + nginx.conf zum Bearbeiten:

nano nginx.conf

Aktualisieren Sie die Konfigurationsdatei so, dass sie unsere Variablen verwendet:

Nginx.conf aktualisiert

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;
   }
}

Wir sind jedoch noch nicht fertig. Beachten Sie das "+ default_server " oben? Wir möchten nur das für die Anwendung " laravel " einschließen, um es zum Standard zu machen. Zu diesem Zweck können wir mit einer einfachen IF-Anweisung prüfen, ob " item.name" gleich "+ laravel" ist, und in diesem Fall "+ default_server" anzeigen.

Es wird so aussehen:

Nginx.conf mit Bedingungen aktualisiert

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

Aktualisieren Sie Ihre + nginx.conf + entsprechend und speichern Sie sie.

Jetzt ist es Zeit, unser Playbook zu starten:

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

Sie sollten feststellen, dass die Nginx-Aufgaben als geändert markiert wurden. Aktualisieren Sie nach Abschluss der Ausführung die Site in Ihrem Browser. Sie sollte genauso aussehen wie am Ende des letzten Lernprogramms:

http://laravel.example.com/

Queue: YES
Cron: YES

Schritt 5 - Mehrere Variablen zusammenschleifen

In diesem Schritt werden mehrere Variablen in Tasks zusammengefasst.

Jetzt ist es Zeit, ein komplexeres Schleifenbeispiel in Angriff zu nehmen, speziell registrierte Variablen. Um verschiedene Zustände zu unterstützen und zu verhindern, dass Tasks unnötig ausgeführt werden, werden Sie sich daran erinnern, dass wir in unserer Clone git repository-Task "+ register: cloned " verwendet haben, um die Variable " cloned " mit dem Status der Task zu registrieren. Wir haben dann in den folgenden Tasks " when: cloned | changed +" verwendet, um Tasks bedingt auszulösen. Jetzt müssen wir diese Referenzen aktualisieren, um die Anwendungsschleife zu unterstützen.

Öffnen Sie zuerst Ihr Playbook zum Bearbeiten:

nano php.yml

Suchen Sie nach der Aufgabe _ Clone git repository _:

Bestehende Git-Aufgabe in 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

Da wir die Variable in dieser Aufgabe registrieren, müssen wir nichts tun, was wir noch nicht getan haben:

Die Git-Aufgabe in php.yml wurde aktualisiert

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

 register: cloned

Bewegen Sie sich nun in Ihrem Playbook nach unten, bis Sie die Aufgabe "+ composer create-project" finden:

Ursprüngliche Komponistenaufgabe in 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

Jetzt müssen wir es aktualisieren, um * beide * + applications + und + cloned + durchlaufen zu können. Dies geschieht mit der Option "+ with_together" und der Übergabe von "+ applications" und "+ cloned". Da + with_together + zwei Variablen durchläuft, erfolgt der Zugriff auf Elemente mit + item. # +, Wobei + # + der Index der Variablen ist, wie er definiert ist. Also zum Beispiel:

with_together:
- list_one
- list_two

+ item.0 + bezieht sich auf + list_one + und + item.1 + bezieht sich auf + list_two +.

Das bedeutet, dass wir für "" -Anwendungen über " item.0.name" auf die Eigenschaften zugreifen können. Für "+ geklont " müssen wir die Ergebnisse der Tasks übergeben, auf die über " geklont.Ergebnisse " zugegriffen werden kann, und dann können wir überprüfen, ob sie über " item.1.changed +" geändert wurden.

Das heißt, die Aufgabe wird:

Composer Task in php.yml aktualisiert

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

Speichern Sie nun Ihr Playbook und führen Sie es aus:

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

Bei diesem Lauf sollten keine Änderungen vorgenommen werden. Wir haben jetzt jedoch eine registrierte Variable, die gut in einer Schleife funktioniert.

Schritt 6 - Komplexe registrierte Variablen und Schleifen

In diesem Abschnitt erfahren Sie mehr über kompliziertere registrierte Variablen und Schleifen.

Der komplizierteste Teil der Konvertierung ist die Behandlung der registrierten Variablen, die wir zur Passwortgenerierung für unsere MySQL-Datenbank verwenden. Allerdings müssen wir in diesem Schritt, den wir noch nicht behandelt haben, nicht viel mehr tun, sondern nur eine Reihe von Aufgaben gleichzeitig aktualisieren.

Öffne dein Playbook zum Bearbeiten:

nano php.yml

Finden Sie die MySQL-Aufgaben und fügen Sie in unserem ersten Durchgang einfach die Basisvariablen hinzu, die wir in den vorherigen Aufgaben ausgeführt haben:

Aktualisierte MySQL-Tasks in 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

Als nächstes fügen wir "+ with_together " hinzu, damit wir unser Datenbankkennwort verwenden können. Für unsere Passwortgenerierung müssen wir eine Schleife über " dbpwd.results " durchführen und können dann über " item.1.stdout " auf das Passwort zugreifen, da " applications " über " item.0 +" aufgerufen wird `.

Wir können unser Playbook entsprechend aktualisieren:

Aktualisierte MySQL-Tasks in 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:

Sobald Sie Ihr Playbook aktualisiert haben, speichern Sie es und führen Sie es aus:

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

Trotz aller Änderungen, die wir an unserem Playbook vorgenommen haben, sollten sich keine Änderungen an den Datenbankaufgaben ergeben. Mit den Änderungen in diesem Schritt hätten wir unsere Konvertierung von einem Playbook mit einer Anwendung zu einem Playbook mit mehreren Anwendungen beenden müssen.

Schritt 7 - Hinzufügen weiterer Anwendungen

In diesem Schritt konfigurieren wir zwei weitere Anwendungen in unserem Playbook.

Nachdem wir unser Playbook überarbeitet haben, um Variablen zum Definieren der Anwendungen zu verwenden, ist der Vorgang zum Hinzufügen neuer Anwendungen zu unserem Server sehr einfach. Fügen Sie sie einfach zur Variablenliste "+ applications +" hinzu. Hier wird die Kraft von Ansible-Variablen wirklich zur Geltung kommen.

Öffne dein Playbook zum Bearbeiten:

nano php.yml

Suchen Sie oben im Abschnitt + vars + den Block + applications +:

Bestehende Anwendungen variabel in php.yml

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

Fügen Sie nun zwei weitere Anwendungen hinzu:

Aktualisierte Anwendungsvariable in php.yml

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

Speichere dein Playbook.

Jetzt ist es Zeit, dein Playbook zu starten:

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

Dieser Schritt kann eine Weile dauern, da der Komponist die neuen Anwendungen einrichtet. Wenn es abgeschlossen ist, werden Sie feststellen, dass eine Reihe von Aufgaben geändert wurden, und wenn Sie genau hinschauen, werden Sie feststellen, dass alle geloopten Elemente aufgelistet werden. Die erste, unsere ursprüngliche Anwendung sollte "+ ok " oder " übersprungen " sagen, während die beiden neuen Anwendungen " geändert +" sagen sollten.

Noch wichtiger ist, wenn Sie alle drei Domänen für Ihre konfigurierten Websites in Ihrem Webbrowser besuchen, sollten Sie drei verschiedene Websites bemerken.

Der erste sollte vertraut aussehen. Die anderen beiden sollten anzeigen:

http://one.example.com/

This is example app one!

and

http://two.example.com/

This is example app two!

Damit haben wir gerade zwei neue Webanwendungen bereitgestellt, indem wir einfach unsere Anwendungsliste aktualisiert haben.

Schritt 8 - Verwenden von Hostvariablen

In diesem Schritt extrahieren wir unsere Variablen in Hostvariablen.

Einen Schritt zurück, Playbook-Variablen sind gut, aber was ist, wenn wir verschiedene Anwendungen auf verschiedenen Servern mit demselben Playbook bereitstellen möchten? Wir könnten bei jeder Aufgabe bedingte Prüfungen durchführen, um herauszufinden, auf welchem ​​Server die Aufgabe ausgeführt wird, oder wir könnten Host-Variablen verwenden. Hostvariablen sind genau das, wonach sie klingen: Variablen, die für einen bestimmten Host gelten und nicht für alle Hosts in einem Playbook.

Hostvariablen können inline in der Datei "+ hosts " definiert werden, wie wir es mit der Variablen " ansible_ssh_user " getan haben, oder sie können in einer dedizierten Datei für jeden Host im Verzeichnis " host_vars +" definiert werden.

Erstellen Sie zunächst ein neues Verzeichnis neben unserer "+ hosts " - Datei und unserem Playbook. Rufen Sie das Verzeichnis ` host_vars +` auf:

mkdir host_vars

Als nächstes müssen wir eine Datei für unseren Host erstellen. Die von Ansible verwendete Konvention sieht vor, dass der Dateiname mit dem Hostnamen in der Datei + hosts + übereinstimmt. Also, zum Beispiel, wenn Ihre + hosts + Datei so aussieht:

Ansible Hosts-Datei

[php]
ansible_ssh_user=sammy

Dann sollten Sie eine Datei mit dem Namen "+ host_vars / your_first_server_ip +" erstellen. Lassen Sie uns das jetzt erstellen:

nano host_vars/

Host-Dateien verwenden wie unsere Playbooks YAML für ihre Formatierung. Das bedeutet, wir können unsere "+ applications +" - Liste in unsere neue Host-Datei kopieren. Das sieht also so aus:

Neue Datei 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

Speichern Sie Ihre neue Hosts-Datei und öffnen Sie Ihr Playbook zum Bearbeiten:

nano php.yml

Aktualisieren Sie den oberen Bereich, um den gesamten Abschnitt "+ applications +" zu entfernen:

Aktualisierter Anfang von php.yml

---
- hosts: php
 sudo: yes

 vars:
   wwwuser: www-data

 tasks:
. . .

Speichern Sie das Playbook und führen Sie es aus:

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

Obwohl wir unsere Variablen aus unserem Playbook in unsere Host-Datei verschoben haben, sollte die Ausgabe genau gleich aussehen und von Ansible sollten keine Änderungen gemeldet werden. Wie Sie sehen können, funktioniert "+ host_vars " genauso wie " vars +" in Playbooks. Sie sind nur für den Host spezifisch.

Auf Variablen, die in "+ host_vars +" - Dateien definiert sind, kann auch in allen Playbooks zugegriffen werden, die den Server verwalten. Dies ist nützlich für allgemeine Optionen und Einstellungen. Achten Sie jedoch darauf, keinen gemeinsamen Namen zu verwenden, der in verschiedenen Playbooks unterschiedliche Bedeutungen haben kann.

Schritt 9 - Bereitstellen von Anwendungen auf einem anderen Server

In diesem Schritt verwenden wir unsere neuen Hostdateien und stellen Anwendungen auf einem zweiten Server bereit.

Zuerst müssen wir Ihre "+ hosts" -Datei mit unserem neuen Host aktualisieren. Öffne es zum Bearbeiten:

nano hosts

Und fügen Sie Ihren neuen Host hinzu:

Ansible Hosts-Datei

[php]
your_first_server_ip ansible_ssh_user=sammy
ansible_ssh_user=

Speichern und schließen Sie die Datei.

Als nächstes müssen wir eine neue Hosts-Datei erstellen, wie wir es mit der ersten getan haben.

nano host_vars/

Sie können eine oder mehrere unserer Beispielanwendungen auswählen und in Ihre Hostdatei einfügen. Wenn Sie beispielsweise unser ursprüngliches Beispiel und Beispiel zwei auf dem neuen Server bereitstellen möchten, können Sie Folgendes verwenden:

Neue Datei 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

Speichere dein Playbook.

Endlich können wir unser Playbook starten:

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

Die Ausführung von Ansible dauert eine Weile, da alles auf Ihrem zweiten Server eingerichtet wird. Wenn dies abgeschlossen ist, öffnen Sie Ihre ausgewählten Anwendungen in Ihrem Browser (im Beispiel haben wir "+ laravel.example2.com +" + two.example2.com + "verwendet) und bestätigen Sie, dass sie korrekt eingerichtet wurden. Sie sollten die spezifischen Anwendungen sehen, die Sie für Ihre Hostdatei ausgewählt haben, und Ihr ursprünglicher Server sollte keine Änderungen aufweisen.

Fazit

In diesem Tutorial wurde ein voll funktionsfähiges Playbook für eine Anwendung erstellt und konvertiert, um mehrere Anwendungen auf mehreren Servern zu unterstützen. In Kombination mit den in den vorherigen Tutorials behandelten Themen sollten Sie über alles verfügen, was Sie benötigen, um ein vollständiges Playbook für die Bereitstellung Ihrer Anwendungen zu schreiben. Gemäß den vorherigen Tutorials haben wir uns immer noch nicht direkt mit SSH bei den Servern angemeldet.

Sie werden bemerkt haben, wie einfach es war, weitere Anwendungen und einen anderen Server hinzuzufügen, nachdem wir die Struktur des Playbooks ausgearbeitet hatten. Dies ist die Stärke von Ansible und macht es so flexibel und benutzerfreundlich.

Related