Cách triển khai nhiều ứng dụng PHP bằng Ansible trên Ubuntu 14.04

Hướng dẫn này là bài thứ ba trong loạt bài về triển khai các ứng dụng PHP bằng Ansible trên Ubuntu 14.04. Hướng dẫn đầu tiên bao gồm các bước cơ bản để triển khai một ứng dụng; hướng dẫn thứ hai bao gồm các chủ đề nâng cao hơn như database , daemon hàng đợi và bộ lập lịch tác vụ (crons).

---

Trong hướng dẫn này, ta sẽ xây dựng dựa trên những gì ta đã học được trong các hướng dẫn trước bằng cách chuyển đổi playbook Ansible ứng dụng đơn của ta thành một playbook hỗ trợ triển khai nhiều ứng dụng PHP trên một hoặc nhiều server . Đây là phần cuối cùng của câu đố khi nói đến việc sử dụng Ansible để triển khai các ứng dụng của bạn với nỗ lực tối thiểu.

Ta sẽ sử dụng một số ứng dụng Lumen đơn giản như một phần của các ví dụ của ta . Tuy nhiên, có thể dễ dàng sửa đổi các hướng dẫn này để hỗ trợ các khung và ứng dụng khác nếu bạn đã có. Bạn nên sử dụng các ứng dụng mẫu cho đến khi bạn thấy phù hợp khi áp dụng các thay đổi đối với sách vở.

Yêu cầu

Để làm theo hướng dẫn này, bạn cần :

• Hai Server được cài đặt theo hướng dẫn đầu tiên và thứ hai trong loạt bài này.

• Một Ubuntu 14.04 Server mới (thứ ba) được cài đặt giống như PHP Server ban đầu trong hướng dẫn đầu tiên , với user không phải root có quyền sudo và các SSH key . Server này sẽ được sử dụng để hiển thị cách triển khai nhiều ứng dụng cho nhiều server bằng cách sử dụng một playbook Ansible. Ta sẽ đề cập đến các địa chỉ IP của PHP Server root và PHP Server mới này là your_first_server_ip và your_second_server_ip tương ứng.

• Tệp /etc/hosts được cập nhật trên máy tính local của bạn với các dòng sau được thêm vào. Bạn có thể tìm hiểu thêm về file này trong bước 6 của hướng dẫn này .

your_first_server_ip laravel.example.com one.example.com two.example.com your_second_server_ip laravel.example2.com two.example2.com 

Các trang web mẫu mà ta sẽ sử dụng trong hướng dẫn này là laravel.example.com , one.example.com và two.example.com . Nếu bạn muốn sử dụng domain của riêng mình, bạn cần cập nhật các bản ghi DNS đang hoạt động của bạn .

Bước 1 - Đặt các biến Playbook

Trong bước này, ta sẽ cài đặt các biến playbook để xác định các ứng dụng mới của ta .

Trong các hướng dẫn trước, ta đã mã hóa tất cả các chi tiết cụ thể về cấu hình, đây là điều bình thường đối với nhiều sách chơi thực hiện các việc cụ thể cho một ứng dụng cụ thể. Tuy nhiên, khi bạn muốn hỗ trợ nhiều ứng dụng hoặc mở rộng phạm vi sách vở của bạn , thì việc viết mã mọi thứ không còn có ý nghĩa nữa.

Như ta đã thấy trước đây, Ansible cung cấp các biến mà bạn có thể sử dụng trong cả định nghĩa nhiệm vụ và mẫu file của bạn . Những gì ta chưa thấy là cách đặt các biến theo cách thủ công. Ở đầu playbook của bạn, cùng với các thông số hosts và tasks , bạn có thể xác định một thông số vars và đặt các biến của bạn ở đó.

Nếu bạn chưa làm như vậy, hãy thay đổi folder thành ansible-php từ các hướng dẫn trước.

cd ~/ansible-php/ 

Mở playbook hiện có của ta để chỉnh sửa.

nano php.yml 

Phần đầu của file sẽ trông như thế này:

--- - hosts: php   sudo: yes    tasks: . . . 

Để xác định các biến, ta chỉ có thể thêm vào một phần vars trong cùng với hosts , sudo và tasks . Để đơn giản hóa mọi thứ, ta sẽ bắt đầu với một biến rất cơ bản cho tên user www-data , như sau:

--- - hosts: php   sudo: yes    vars:     wwwuser: www-data    tasks: . . . 

Tiếp theo, xem qua và cập nhật tất cả các lần xuất hiện của user www-data với biến mới {{ wwwuser }} . Định dạng này nên quen thuộc, vì ta đã sử dụng nó trong giao diện và tra cứu.

Để tìm và thay thế bằng nano, hãy nhấn CTRL+\ . Bạn sẽ thấy một dấu nhắc cho biết Tìm kiếm (để thay thế):. Nhập www-data , sau đó nhấn ENTER . Dấu nhắc sẽ thay đổi thành Thay thế bằng:. Tại đây, hãy nhập {{wwwuser}} và nhấn ENTER lần nữa. Nano sẽ đưa bạn qua từng trường hợp của www-data và hỏi Thay thế instanace này? . Bạn có thể nhấn y để thay thế từng cái một hoặc nhấn a để thay thế tất cả.

Lưu ý : Đảm bảo rằng khai báo biến mà ta vừa thêm ở trên cùng cũng không bị thay đổi. Có 11 trường hợp www-data cần được thay thế.

Trước khi ta đi xa hơn, có một số điều ta cần phải cẩn thận khi nói đến các biến. Thông thường, ta có thể thêm chúng vào như thế này, khi chúng nằm trong một dòng dài hơn:

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

Tuy nhiên, nếu biến là giá trị duy nhất trong chuỗi, ta cần đặt nó trong dấu ngoặc kép để trình phân tích cú pháp YAML có thể hiểu đúng về nó:

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

Trong sổ chơi của bạn, điều này cần xảy ra khi nào bạn có sudo_user: {{ wwwuser }} . Bạn có thể sử dụng tìm kiếm toàn cục và thay thế theo cách tương tự, thay thế sudo_user: {{wwwuser}} bằng sudo_user: “{{wwwuser}}” . Cần có bốn dòng cần thay đổi này.

Khi bạn đã thay đổi tất cả các lần xuất hiện, hãy lưu và chạy playbook:

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

Không có tác vụ nào được thay đổi, nghĩa là biến wwwuser của ta đang hoạt động bình thường.

Bước 2 - Xác định các biến lồng nhau cho cấu hình phức tạp

Trong phần này, ta sẽ xem xét các biến lồng nhau cho các tùy chọn cấu hình phức tạp.

Trong bước trước, ta cài đặt một biến cơ bản. Tuy nhiên, cũng có thể lồng các biến và xác định danh sách các biến. Điều này cung cấp chức năng ta cần để xác định danh sách các trang web ta muốn cài đặt trên server của bạn .

Trước tiên, ta hãy xem xét repository git hiện có mà ta đã cài đặt trong playbook của bạn :

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

Ta có thể extract các phần thông tin hữu ích sau: tên (thư mục), repository , chi nhánh và domain . Bởi vì ta đang cài đặt nhiều ứng dụng, ta cũng cần một domain để nó phản hồi. Ở đây, ta sẽ sử dụng laravel.example.com , nhưng nếu bạn có domain của riêng mình, bạn có thể thay thế nó.

Điều này dẫn đến bốn biến sau đây mà ta có thể xác định cho ứng dụng này:

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

Bây giờ, hãy mở playbook của bạn để chỉnh sửa:

nano php.yml 

Trong phần vars trên cùng, ta có thể thêm ứng dụng của bạn vào danh sách ứng dụng mới:

--- - hosts: php   sudo: yes    vars:     wwwuser: www-data      applications:       - name: laravel         domain: laravel.example.com         repository: https://github.com/do-community/do-ansible-adv-php.git         branch: example  ... 

Nếu bạn chạy playbook của bạn ngay bây giờ (sử dụng ansible-playbook php.yml --ask-sudo-pass ), sẽ không có gì thay đổi vì ta vẫn chưa cài đặt nhiệm vụ để sử applications biến applications mới của bạn . Tuy nhiên, nếu bạn truy cập http://laravel.example.com/ trong trình duyệt của bạn , nó sẽ hiển thị ứng dụng root của ta .

Bước 3 - Biến lặp trong Nhiệm vụ

Trong phần này, ta sẽ học cách lặp qua danh sách biến trong các việc .

Như đã đề cập trước đây, danh sách biến cần được lặp lại trong mỗi tác vụ mà ta muốn sử dụng chúng. Như ta đã thấy với tác vụ install packages , ta cần xác định một vòng lặp các mục, sau đó áp dụng tác vụ cho từng mục trong danh sách.

Mở playbook của bạn để chỉnh sửa:

nano php.yml 

Ta sẽ bắt đầu với một số nhiệm vụ dễ dàng trước. Khoảng giữa playbook của bạn, bạn sẽ thấy hai nhiệm vụ env sau:

- 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 

Bạn sẽ nhận thấy rằng chúng hiện đang được mã hóa cứng bằng folder laravel . Ta muốn cập nhật nó để sử dụng thuộc tính name cho mỗi ứng dụng. Để làm điều này, ta thêm tùy chọn with_items để lặp lại danh sách applications của ta . Trong chính nhiệm vụ, ta sẽ swap tham chiếu laravel cho biến {{ item.name }} , biến này sẽ quen thuộc với các định dạng ta đã sử dụng trước đây.

Nó sẽ giống như thế này:

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

Tiếp theo, chuyển xuống hai nhiệm vụ cron của nghệ nhân Laravel. Chúng có thể được cập nhật giống hệt như ta vừa làm với các việc env . Ta cũng sẽ thêm item.name vào tham số name cho các mục cron, vì Ansible sử dụng trường này để xác định duy nhất từng mục cron. Nếu ta để nguyên chúng, ta sẽ không thể có nhiều trang web trên cùng một server vì chúng sẽ overrides lên từng trang liên tục và chỉ trang cuối cùng được lưu.

Các nhiệm vụ sẽ giống như sau:

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

Nếu bạn lưu và chạy playbook ngay bây giờ (sử dụng ansible-playbook php.yml --ask-sudo-pass ), bạn sẽ chỉ thấy hai tác vụ cron được cập nhật là đã cập nhật. Điều này là do sự thay đổi trong tham số name . Ngoài ra, không có thay đổi nào và điều này nghĩa là danh sách ứng dụng của ta đang hoạt động như mong đợi và ta chưa thực hiện bất kỳ thay đổi nào đối với server của bạn do cấu trúc lại playbook của ta .

Bước 4 - Áp dụng các biến được lặp trong các mẫu

Trong phần này, ta sẽ trình bày cách sử dụng các biến lặp trong các mẫu.

Các biến lặp trong các mẫu rất dễ dàng. Chúng được dùng theo cùng một cách mà chúng được sử dụng trong các việc , giống như tất cả các biến khác. Sự phức tạp xuất hiện khi bạn xem xét các đường dẫn file cũng như các biến, vì trong một số trường hợp sử dụng, ta cần tính đến tên file và thậm chí chạy các lệnh khác vì file mới.

Trong trường hợp của Nginx, ta cần tạo một file cấu hình mới cho mỗi ứng dụng và nói với Nginx rằng nó nên được bật. Ta cũng muốn xóa file cấu hình root /etc/nginx/sites-available/default của ta trong quá trình này.

Trước tiên, mở playbook của bạn để chỉnh sửa:

nano php.yml 

Tìm tác vụ Định Configure Nginx (gần giữa playbook) và cập nhật nó như ta đã thực hiện với các việc khác:

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

Trong khi ta ở đây, ta cũng sẽ thêm vào hai nhiệm vụ khác đã được đề cập ở trên. Đầu tiên, ta sẽ nói với Nginx về file cấu hình trang web mới của ta . Này được thực hiện với một softlink giữa các sites-available và sites-enabled folder trong /var/nginx/ .

Thêm tác vụ này sau tác vụ Định Configure 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 

Tiếp theo, ta muốn xóa file cấu hình trang được bật default để nó không gây ra sự cố với file cấu hình trang mới của ta . Điều này được thực hiện dễ dàng với module file :

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

Lưu ý ta không cần lặp lại applications vì ta đang tìm kiếm một file duy nhất.

Khối Nginx trong playbook của bạn bây giờ sẽ giống như sau:

- 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 

Lưu playbook của bạn và mở file nginx.conf để chỉnh sửa:

nano nginx.conf 

Cập nhật file cấu hình để file sử dụng các biến của ta :

server {     listen 80 default_server;     listen [::]:80 default_server ipv6only=on;      root /var/www/{{ item.name }}/public;     index index.php index.html index.htm;      server_name {{ item.domain }};      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/{{ item.name }}/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;     } } 

Tuy nhiên, ta vẫn chưa kết thúc. Chú ý đến default_server ở trên cùng? Ta muốn chỉ bao gồm điều đó cho ứng dụng laravel , để đặt nó làm mặc định. Để làm điều này ta có thể sử dụng một cơ sở NẾU tuyên bố để kiểm tra xem item.name bằng laravel , và nếu như vậy, hiển thị default_server .

Nó sẽ trông giống thế này:

server {     listen 80{% if item.name == "laravel" %} default_server{% endif %};     listen [::]:80{% if item.name == "laravel" %} default_server ipv6only=on{% endif %};  

Cập nhật nginx.conf của bạn cho phù hợp và lưu nó.

Bây giờ đã đến lúc chạy playbook của ta :

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

Bạn sẽ thấy các việc Nginx đã được đánh dấu là đã thay đổi. Khi nó chạy xong, hãy làm mới trang web trong trình duyệt của bạn và nó sẽ hiển thị giống như ở phần cuối của hướng dẫn cuối cùng:

Queue: YES Cron: YES 

Bước 5 - Nối nhiều biến với nhau

Trong bước này, ta sẽ lặp nhiều biến với nhau trong các việc .

Bây giờ đã đến lúc giải quyết một ví dụ vòng lặp phức tạp hơn, cụ thể là các biến đã đăng ký. Để hỗ trợ các trạng thái khác nhau và ngăn các việc chạy không cần thiết, bạn sẽ nhớ rằng ta đã sử dụng register: cloned trong tác vụ kho lưu trữ Clone git của ta để đăng ký biến được cloned với trạng thái của tác vụ. Sau đó ta sử dụng when: cloned|changed trong các việc sau để kích hoạt các việc có điều kiện. Bây giờ ta cần cập nhật các tham chiếu này để hỗ trợ vòng lặp ứng dụng.

Trước tiên, mở playbook của bạn để chỉnh sửa:

nano php.yml 

Tìm kiếm tác vụ kho lưu trữ Clone git :

- 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 

Khi ta đăng ký biến trong tác vụ này, ta không cần phải làm bất kỳ điều gì mà ta chưa làm:

- name: Clone git repository   git: >     dest=/var/www/{{ item.name }}     repo={{ item.repository }}     update=yes     version={{ item.branch }}   sudo: yes   sudo_user: "{{ wwwuser }}"   with_items: applications   register: cloned 

Bây giờ, di chuyển playbook của bạn xuống cho đến khi bạn tìm thấy composer create-project :

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

Bây giờ ta cần cập nhật nó để lặp lại cả hai applications và cloned . Điều này được thực hiện bằng cách sử dụng tùy chọn with_together và truyền vào cả hai applications và cloned with_together . Giống như with_together lặp qua hai biến, việc truy cập các mục được thực hiện với item.# , Trong đó # là chỉ số của biến khi nó được định nghĩa. Ví dụ:

with_together: - list_one - list_two 

item.0 sẽ tham chiếu đến list_one và item.1 sẽ tham chiếu đến list_two .

Nghĩa là đối với applications ta có thể truy cập các thuộc tính thông qua: item.0.name . Đối với cloned ta cần chuyển kết quả từ các việc , có thể được truy cập thông qua cloned.results , sau đó ta có thể kiểm tra xem nó có bị thay đổi hay không qua item.1.changed .

Điều này nghĩa là nhiệm vụ trở thành:

- name: composer create-project   composer: command=create-project working_dir=/var/www/{{ item.0.name }} optimize_autoloader=no   sudo: yes   sudo_user: "{{ wwwuser }}"   when: item.1.changed   with_together:     - applications     - cloned.results 

Bây giờ hãy lưu và chạy playbook của bạn:

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

Không có thay đổi nào từ lần chạy này. Tuy nhiên, bây giờ ta có một biến đã đăng ký hoạt động tốt trong vòng lặp.

Bước 6 - Các biến và vòng lặp đã đăng ký phức tạp

Trong phần này, ta sẽ tìm hiểu về các biến và vòng lặp đã đăng ký phức tạp hơn.

Phần phức tạp nhất của quá trình chuyển đổi là xử lý biến đã đăng ký mà ta đang sử dụng để tạo password cho database MySQL của ta . Điều đó nói rằng, không còn nhiều việc phải làm trong bước này mà ta chưa đề cập, ta chỉ cần cập nhật một số tác vụ cùng một lúc.

Mở playbook của bạn để chỉnh sửa:

nano php.yml 

Tìm các việc MySQL và trong lần vượt qua ban đầu, ta sẽ chỉ thêm các biến cơ bản giống như ta đã thực hiện trong các việc trước:

- 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={{ item.name }} password={{ dbpwd.stdout }} priv={{ item.name }}.*:ALL state=present   when: dbpwd.changed  - 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/{{ item.name }}/.env regexp='^DB_PASSWORD=' line=DB_PASSWORD={{ dbpwd.stdout }}   when: dbpwd.changed  - name: Save dbpw file   lineinfile: dest=/var/www/{{ item.name }}/.dbpw line="{{ dbpwd.stdout }}" create=yes state=present   sudo: yes   sudo_user: "{{ wwwuser }}"   when: dbpwd.changed  - name: Run artisan migrate   shell: php /var/www/{{ item.name }}/artisan migrate --force   sudo: yes   sudo_user: "{{ wwwuser }}"   when: dbpwd.changed 

Tiếp theo, ta sẽ thêm with_together để ta có thể sử dụng password database của bạn . Để tạo password , ta cần lặp qua dbpwd.results và có thể truy cập password từ item.1.stdout , vì applications sẽ được truy cập qua item.0 .

Ta có thể cập nhật sổ chơi của bạn cho phù hợp:

- 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={{ item.0.name }} password={{ item.1.stdout }} priv={{ item.0.name }}.*:ALL state=present   when: item.1.changed   with_together:   - applications   - dbpwd.results  - 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/{{ item.0.name }}/.env regexp='^DB_PASSWORD=' line=DB_PASSWORD={{ item.1.stdout }}   when: item.1.changed   with_together:   - applications   - dbpwd.results  - name: Save dbpw file   lineinfile: dest=/var/www/{{ item.0.name }}/.dbpw line="{{ item.1.stdout }}" create=yes state=present   sudo: yes   sudo_user: "{{ wwwuser }}"   when: item.1.changed   with_together:   - applications   - dbpwd.results  - name: Run artisan migrate   shell: php /var/www/{{ item.0.name }}/artisan migrate --force   sudo: yes   sudo_user: "{{ wwwuser }}"   when: item.1.changed   with_together:   - applications   - dbpwd.results 

Sau khi bạn đã cập nhật playbook của bạn , hãy lưu nó và chạy nó:

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

Bất chấp tất cả những thay đổi mà ta đã thực hiện đối với playbook của bạn , sẽ không có thay đổi nào đối với các việc database . Với những thay đổi trong bước này, đáng lẽ ta đã hoàn thành việc chuyển đổi từ một playbook ứng dụng sang playbook nhiều ứng dụng.

Bước 7 - Thêm các ứng dụng khác

Trong bước này, ta sẽ cấu hình thêm hai ứng dụng trong playbook của ta .

Bây giờ ta đã cấu trúc lại playbook của bạn để sử dụng các biến để xác định ứng dụng, quá trình thêm ứng dụng mới vào server của ta rất dễ dàng. Chỉ cần thêm chúng vào danh sách biến applications . Đây là nơi sức mạnh của các biến Ansible sẽ thực sự tỏa sáng.

Mở playbook của bạn để chỉnh sửa:

nano php.yml 

Ở trên cùng, trong phần vars , tìm khối applications :

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

Bây giờ hãy thêm vào hai ứng dụng khác:

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 

Lưu sách vở của bạn.

Bây giờ là lúc chạy playbook của bạn:

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

Bước này có thể mất một lúc vì composer cài đặt các ứng dụng mới. Khi nó kết thúc, bạn sẽ thấy một số nhiệm vụ được thay đổi, và nếu bạn xem xét cẩn thận, bạn sẽ nhận thấy rằng từng mục lặp lại sẽ được liệt kê. Đầu tiên, ứng dụng root của ta sẽ nói là ok hoặc skipped , trong khi hai ứng dụng mới sẽ nói changed .

Quan trọng hơn, nếu bạn truy cập cả ba domain cho các trang web đã cấu hình trong trình duyệt web của bạn , bạn sẽ thấy ba trang web khác nhau.

Cái đầu tiên sẽ trông quen thuộc. Hai cái còn lại sẽ hiển thị:

This is example app one! 

và

This is example app two! 

Cùng với đó, ta vừa triển khai hai ứng dụng web mới bằng cách cập nhật danh sách ứng dụng của bạn .

Bước 8 - Sử dụng biến server

Trong bước này, ta sẽ extract các biến của ta thành các biến lưu trữ.

Lùi lại một bước, các biến playbook là tốt, nhưng nếu ta muốn triển khai các ứng dụng khác nhau trên các server khác nhau bằng cách sử dụng cùng một playbook thì sao? Ta có thể thực hiện kiểm tra có điều kiện đối với từng tác vụ để tìm ra server nào đang chạy tác vụ hoặc ta có thể sử dụng các biến server . Biến server chỉ giống như những gì chúng nghe: các biến áp dụng cho một server cụ thể, thay vì tất cả các server trên một playbook.

Các biến server có thể được xác định nội tuyến, trong file hosts , giống như ta đã làm với biến ansible_ssh_user hoặc chúng có thể được định nghĩa trong file dành riêng cho từng server trong folder host_vars .

Đầu tiên, hãy tạo một folder mới cùng với file hosts và sách phát của ta . Gọi đến folder host_vars :

mkdir host_vars 

Tiếp theo, ta cần tạo một file cho server của ta . Quy ước Ansible sử dụng là để tên file trùng với tên server trong file hosts . Vì vậy, ví dụ: nếu file hosts của bạn trông giống như sau:

[php] your_first_server_ip ansible_ssh_user=sammy 

Sau đó, bạn nên tạo một file có tên host_vars/your_first_server_ip . Hãy tạo điều đó ngay bây giờ:

nano host_vars/your_first_server_ip 

Giống như sách vở của ta , các file server lưu trữ sử dụng YAML để định dạng. Điều này nghĩa là ta có thể sao chép danh sách applications vào file server mới của ta , vì vậy nó trông giống như sau:

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

Lưu file server mới của bạn và mở playbook của bạn để chỉnh sửa:

nano php.yml 

Cập nhật phần trên cùng để xóa toàn bộ applications :

--- - hosts: php   sudo: yes    vars:     wwwuser: www-data    tasks: . . . 

Lưu playbook và chạy nó:

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

Mặc dù ta đã chuyển các biến từ playbook sang file server của bạn , nhưng kết quả kết quả sẽ giống hệt nhau và không có thay đổi nào được Ansible báo cáo. Như bạn thấy , host_vars hoạt động theo cùng một cách mà các vars trong playbook làm; chúng chỉ dành riêng cho server .

Các biến được xác định trong file host_vars cũng sẽ có thể truy cập được trên tất cả các sách phát quản lý server , điều này hữu ích cho các tùy chọn và cài đặt chung. Tuy nhiên, hãy cẩn thận không sử dụng một tên chung có thể có nghĩa khác nhau trên các sách phát khác nhau.

Bước 9 - Triển khai ứng dụng trên server khác

Trong bước này, ta sẽ sử dụng các file server lưu trữ mới và triển khai các ứng dụng trên server thứ hai.

Đầu tiên, ta cần cập nhật file hosts với server mới. Mở nó để chỉnh sửa:

nano hosts 

Và thêm vào server mới của bạn:

[php] your_first_server_ip ansible_ssh_user=sammy your_second_server_ip ansible_ssh_user=sammy 

Lưu và đóng file .

Tiếp theo, ta cần tạo một file server mới, giống như ta đã làm với file đầu tiên.

nano host_vars/your_second_server_ip 

Bạn có thể chọn một hoặc nhiều ứng dụng mẫu của ta và thêm chúng vào file server của bạn. Ví dụ: nếu bạn muốn triển khai ví dụ ban đầu và ví dụ hai của ta cho server mới, bạn có thể sử dụng:

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

Lưu sách vở của bạn.

Cuối cùng, ta có thể chạy playbook của bạn :

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

Ansible sẽ mất một lúc để chạy vì nó đang cài đặt mọi thứ trên server thứ hai của bạn. Khi hoàn tất , hãy mở các ứng dụng bạn đã chọn trong trình duyệt của bạn (trong ví dụ: ta đã sử dụng laravel.example2.com two.example2.com ) và để xác nhận chúng đã được cài đặt chính xác. Bạn sẽ thấy các ứng dụng cụ thể mà bạn đã chọn cho file server của bạn và server root của bạn sẽ không có thay đổi nào.

Kết luận

Hướng dẫn này lấy một cuốn sách chơi đơn ứng dụng hoạt động đầy đủ và chuyển đổi nó để hỗ trợ nhiều ứng dụng trên nhiều server . Kết hợp với các chủ đề được đề cập trong các hướng dẫn trước, bạn sẽ có mọi thứ cần thiết để viết một cuốn sách hướng dẫn đầy đủ cho việc triển khai các ứng dụng của bạn . Theo các hướng dẫn trước, ta vẫn chưa đăng nhập trực tiếp vào server bằng SSH.

Bạn sẽ nhận thấy việc thêm nhiều ứng dụng và một server khác đơn giản như thế nào khi ta đã hoàn thiện cấu trúc của playbook. Đây là sức mạnh của Ansible, và là điều khiến nó trở nên linh hoạt và dễ sử dụng.

---

---

Các tin liên quan

Cách triển khai ứng dụng PHP nâng cao bằng Ansible trên Ubuntu 14.04
2015-06-02
Cách triển khai một ứng dụng PHP cơ bản bằng Ansible trên Ubuntu 14.04
2015-04-14
Cách chia sẻ các phiên PHP trên nhiều server Memcached trên Ubuntu 14.04
2014-07-22
Cách sử dụng Framework PHP miễn phí béo
2014-03-06
Cách tự động hóa quy trình triển khai ứng dụng PHP bằng Capistrano trên Ubuntu 13
2014-02-26
Cách triển khai ứng dụng Kohana PHP trên VPS Debian 7 / Ubuntu 13 với Nginx và PHP-FPM
2013-12-30
Cách cài đặt và thiết lập Kohana, Khung phát triển ứng dụng web PHP
2013-12-30
Cách tùy chỉnh MediaWiki bằng tệp LocalSettings.php
2013-09-16
Bắt đầu với Yii PHP Framework - Phần 2
2013-08-12
Cách lưu trữ các phiên PHP trong Memcached trên CentOS VPS
2013-08-05