Merge pull request #37 from vntechies/day6x

added day67 vn translation
This commit is contained in:
Mau Ha Quang 2023-08-24 01:31:42 +09:00 committed by GitHub
commit e2410ad58f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 616 additions and 10 deletions

View File

@ -14,7 +14,7 @@ Trong bài viết trước, chúng ta đã bắt đầu với việc tạo bài
Chúng ta cũng đã đi qua một số trường hợp sử dụng playbooks và cuối cùng, chúng ta đã có một playbooks giúp các máy chủ web01 và web02 trở thành các máy chủ riêng biệt. Chúng ta cũng đã đi qua một số trường hợp sử dụng playbooks và cuối cùng, chúng ta đã có một playbooks giúp các máy chủ web01 và web02 trở thành các máy chủ riêng biệt.
![](Images/Day66_config1.png) ![](../../Days/Images/Day66_config1.png)
### Giữ mọi thứ ngăn nắp ### Giữ mọi thứ ngăn nắp
@ -58,11 +58,11 @@ sau đó, trong playbook mà hiện tại có tên là `playbook2.yml`, chúng t
Bạn có thể kiểm tra điều này trong máy chủ điều khiển của mình. Nếu bạn đã sao chép các tệp từ repository, bạn sẽ nhận thấy điều gì đó đã thay đổi trong phần "write a basic index.html file" Bạn có thể kiểm tra điều này trong máy chủ điều khiển của mình. Nếu bạn đã sao chép các tệp từ repository, bạn sẽ nhận thấy điều gì đó đã thay đổi trong phần "write a basic index.html file"
![](Images/Day66_config2.png) ![](../../Days/Images/Day66_config2.png)
Hãy tìm hiểu xem tôi đã thực hiện thay đổi đơn giản nào. Sử dụng lệnh `curl web01:8000` Hãy tìm hiểu xem tôi đã thực hiện thay đổi đơn giản nào. Sử dụng lệnh `curl web01:8000`
![](Images/Day66_config3.png) ![](../../Days/Images/Day66_config3.png)
Chúng ta vừa dọn dẹp lại playbook và bắt đầu phân tách các khu vực có thể khiến playbook trở nên phức tạp khi mở rộng quy mô. Chúng ta vừa dọn dẹp lại playbook và bắt đầu phân tách các khu vực có thể khiến playbook trở nên phức tạp khi mở rộng quy mô.
@ -72,15 +72,15 @@ Hiện tại, chúng ta đã triển khai 4 máy ảo và chúng ta đã định
Để làm điều này, chúng ta sẽ sử dụng lệnh `ansible-galaxy` để quản lý các roles trong các kho repository được chia sẻ. Để làm điều này, chúng ta sẽ sử dụng lệnh `ansible-galaxy` để quản lý các roles trong các kho repository được chia sẻ.
![](Images/Day66_config4.png) ![](../../Days/Images/Day66_config4.png)
Chúng ta sẽ sử dụng `ansible-galaxy` để tạo một role cho apache2, đây là nơi chúng ta sẽ đặt các chi tiết cụ thể cho máy của web của mình. Chúng ta sẽ sử dụng `ansible-galaxy` để tạo một role cho apache2, đây là nơi chúng ta sẽ đặt các chi tiết cụ thể cho máy của web của mình.
![](Images/Day66_config5.png) ![](../../Days/Images/Day66_config5.png)
Câu lệnh trên `ansible-galaxy init roles/apache2` sẽ tạo cấu trúc thư mục như ở trên. Bước tiếp theo là chúng ta cần chuyển các tác vụ mà templates hiện có của mình sang các thư mục có liên quan trong cấu trúc mới. Câu lệnh trên `ansible-galaxy init roles/apache2` sẽ tạo cấu trúc thư mục như ở trên. Bước tiếp theo là chúng ta cần chuyển các tác vụ mà templates hiện có của mình sang các thư mục có liên quan trong cấu trúc mới.
![](Images/Day66_config6.png) ![](../../Days/Images/Day66_config6.png)
Copy và paste là cách dễ dàng để chuyển các tệp đó, nhưng chúng ta cũng cần thực hiện thay đổi với tasks/main.yml để trỏ tệp này tới apache2_install.yml. Copy và paste là cách dễ dàng để chuyển các tệp đó, nhưng chúng ta cũng cần thực hiện thay đổi với tasks/main.yml để trỏ tệp này tới apache2_install.yml.
@ -97,15 +97,15 @@ Chúng ta cũng cần thay đổi playbook để có thể sử dụng role mớ
- apache2 - apache2
``` ```
![](Images/Day66_config7.png) ![](../../Days/Images/Day66_config7.png)
Bây giờ, chúng ta có thể chạy lại playbook của mình lần này với tên playbook mới `ansible-playbook playbook3.yml`, bạn sẽ nhận thấy một cảnh báo về việc deprecation, chúng ta có thể khắc phục ngay sau đây. Bây giờ, chúng ta có thể chạy lại playbook của mình lần này với tên playbook mới `ansible-playbook playbook3.yml`, bạn sẽ nhận thấy một cảnh báo về việc deprecation, chúng ta có thể khắc phục ngay sau đây.
![](Images/Day66_config8.png) ![](../../Days/Images/Day66_config8.png)
Ok, dù playbook của chúng ta đã hoạt động nhưng chúng ta cần sử deprecation warning ngay, để làm điều đó, tôi đã thay đổi tuỳ chọn trong tasks/main.yml thành import_tasks như bên dưới. Ok, dù playbook của chúng ta đã hoạt động nhưng chúng ta cần sử deprecation warning ngay, để làm điều đó, tôi đã thay đổi tuỳ chọn trong tasks/main.yml thành import_tasks như bên dưới.
![](Images/Day66_config9.png) ![](../../Days/Images/Day66_config9.png)
Bạn có thể tìm thấy các tệp này trong[ansible-scenario3](../../Days/Configmgmt/ansible-scenario3) Bạn có thể tìm thấy các tệp này trong[ansible-scenario3](../../Days/Configmgmt/ansible-scenario3)
@ -114,7 +114,7 @@ Chúng ta cũng sẽ tạo thêm một vài roles trong khi sử dụng `ansible
- common = cho tất cả các máy chủ (`ansible-galaxy init roles/common`) - common = cho tất cả các máy chủ (`ansible-galaxy init roles/common`)
- nginx = cho load balancer (`ansible-galaxy init roles/nginx`) - nginx = cho load balancer (`ansible-galaxy init roles/nginx`)
![](Images/Day66_config10.png) ![](../../Days/Images/Day66_config10.png)
Tôi sẽ dừng phần này tại đây và trong phần tiếp theo, chúng ta sẽ bắt đầu làm việc trên các nodes khác mà chúng ta đã triển khai nhưng chưa thực hiện bất cứ điều gì. Tôi sẽ dừng phần này tại đây và trong phần tiếp theo, chúng ta sẽ bắt đầu làm việc trên các nodes khác mà chúng ta đã triển khai nhưng chưa thực hiện bất cứ điều gì.

121
2022/vi/Days/day67.md Normal file
View File

@ -0,0 +1,121 @@
---
title: '#90DaysOfDevOps - Sử dụng Role & Triển khai Loadbalancer - Ngày 67'
published: false
description: '90DaysOfDevOps - Sử dụng Role & Triển khai Loadbalancer'
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048713
---
## Sử dụng Role & Triển khai Loadbalancer
Trong bài viết trước, chúng ta đã đề cập tới roles và sử dụng câu lệnh `asnsible-galaxy` để tạo ra cấu trúc thư mục cho một số role mà chúng ta đã sử dụng. Chúng ta đã hoàn thành việc dọn dẹp lại thư mục cho các mã cấu hình của mình vì mọi thứ được đặt vào các thư mục theo từng role.
Tuy nhiên, chúng ta mới chỉ sử dụng role apache2 và có một tệp playbook3.yaml để thiết lập các máy chủ web của chúng ta.
Tại thời điểm này, nếu bạn chỉ sử dụng lệnh `vagrant up web01 web02` thì bây giờ là lúc để chạy lệnh `vagrant up loadbalancer`, điều này sẽ khởi tạo một hệ thống chạy Ubuntu khá mà chúng ta sẽ sử dụng để làm Load Balancer/Proxy của mình.
Chúng ta đã định nghĩa máy này trong file host nhưng không có khoá ssh được định cấu hình cho tới khi nó khả dụng, chính vì thế chúng ta cũng cần chạy lệnh `ssh-copy-id loadbalancer` khi hệ thống đã hoạt động và sẵn sàng.
### Common role
Chúng ta đã tạo role `common` và cuối bài viết ngày hôm qua, common role sẽ được sử dụng trên tất cả các máy chủ của chúng ta trong khi các role khác dành riêng cho từng trường hợp sử dụng. Các ứng dụng chúng ta sắp cài đặt cũng sẽ phổ biến và được sử dụng trên các máy khác nhau. Trong thư mục roles, điều hướng đến thư mục tasks và bạn sẽ có một tệp mail.yml. Trong YAML này, chúng ta cần trỏ tệp mà đến install_tools.yml bằng cách thêm một dòng `- import_tasks: install_tools.yml`, dòng này từng là `include` nhưng nó sẽ sớm không được hỗ trợ nữa nên chúng ta sẽ sử dụng import_tasks.
```Yaml
- name: "Install Common packages"
apt: name={{ item }} state=latest
with_items:
- neofetch
- tree
- figlet
```
Trong playbook của chúng ta, sau đó chúng ta sẽ thêm common role cho từng group máy chủ.
```Yaml
- hosts: webservers
become: yes
vars:
http_port: 8000
https_port: 4443
html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 66!"
roles:
- common
- apache2
```
### nginx
Giai đoạn tiếp theo là để chúng ta cài đặt và định cấu hình nginx trên máy ảo cân bằng tải. Giống như cấu trúc thư mục chung, chúng ta có thể cấu hình nginx theo bài viết trước.
Đầu tiên, chúng ta sẽ thêm một khối máy chủ vào playbook của mình. Khối này sẽ bao gồm common role và sau đó là role nginx mới.
Playbook có thể được tìm thấy tại đây [playbook4.yml](../../Days/Configmgmt/ansible-scenario4/playbook4.yml)
```Yaml
- hosts: webservers
become: yes
vars:
http_port: 8000
https_port: 4443
html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 66!"
roles:
- common
- apache2
- hosts: proxy
become: yes
roles:
- common
- nginx
```
Để nó có thể hoạt động, chúng ta phải định nghĩa các tasks mà chúng ta muốn chạy, theo cách tương tự, chúng ta sẽ sửa main.yml trong các tasks để nó trỏ tới hai tệp, một để cài đặt và một là để định cấu hình.
Có một số tệp khác mà tôi đã sửa dựa vào kết quả mà chúng ta mong muốn, hãy xem trong thư mục [ansible-scenario4](../../Days/Configmgmt/ansible-scenario4) để biết tất cả các tệp đã thay đổi. Bạn nên kiểm tra các thư mục tasks, handlers và templates trong thư mục ngĩn và bạn sẽ tìm thấy các tệp và thay đổi bổ sung đó.
### Chạy playbook đã được cập nhật
Kể từ hôm qua, chúng ta đã thêm common role để cài đặt một số packages trên hệ thống và cũng đã thêm role ngĩn bao gồm cài đặt và định cấu hình.
Hãy chạy playbook4.yml sử dụng câu lệnh `ansible-playbook playbook4.yml`
![](../../Days/Images/Day67_config1.png)
Bây giờ chúng ta đã định cấu hình webservers và loadbalancer và có thể truy cập http://192.168.169.134/, địa chỉ IP của bộ cân bằng tải (load balancer) của chúng ta.
![](../../Days/Images/Day67_config2.png)
Nếu bạn đang làm theo và không có có được trạng thái mong muốn thì rất có thể là do địa chỉ IP của máy chủ mà bạn đang có trong môi trường của mình. Có thể tìm thấy tệp này trong `templates\mysite.j2` và nó sẽ trông tương tự như ở dưới dây. Bạn cần cập nhật địa chỉ IP máy chủ web của mình.
```J2
upstream webservers {
server 192.168.169.131:8000;
server 192.168.169.132:8000;
}
server {
listen 80;
location / {
proxy_pass http://webservers;
}
}
```
Tôi khá tự tin rằng những gì chúng ta đã cài đặt đều tốt nhưng hãy sử dụng một lệnh ad-hoc thông qua ansible để kiểm tra việc cài đặt các công cụ chung này.
`ansible loadbalancer -m command -a neofetch`
![](../../Days/Images/Day67_config3.png)
## Tài liệu tham khảo
- [What is Ansible](https://www.youtube.com/watch?v=1id6ERvfozo)
- [Ansible 101 - Episode 1 - Introduction to Ansible](https://www.youtube.com/watch?v=goclfp6a2IQ)
- [NetworkChuck - You need to learn Ansible right now!](https://www.youtube.com/watch?v=5hycyr-8EKs&t=955s)
- [Your complete guide to Ansible](https://www.youtube.com/playlist?list=PLnFWJCugpwfzTlIJ-JtuATD2MBBD7_m3u)
Playlist cuối cùng được liệt kê ở trên có rất nhiều đoạn mã và ý tưởng cho bài viết này, nó là một video hướng dẫn tuyệt vời.
Hẹn gặp lại vào [ngày 68](day68.md)

342
2022/vi/Days/day68.md Normal file
View File

@ -0,0 +1,342 @@
---
title: '#90DaysOfDevOps - Tags, Variables, Inventory & Database Server config - Ngày 68'
published: false
description: '90DaysOfDevOps - Tags, Variables, Inventory & Database Server config'
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048780
---
## Tags, Variables, Inventory & Database Server config
### Tags
Khi chúng ta hoàn thành playbook trong bài viết ngày hôm qua, chúng ta sẽ cần chạy mọi task và play trong playbook đó. Điều đó có nghĩa là chúng ta phải chạy các plays và tasks của webservers và loadbalancer đến bước hoàn thành.
Tuy nhiên, các tags có thể cho phép chúng ta tách biệt chúng ra nếu muốn. Đây là một cách hiệu quả nếu chúng ta có một playbook lớn và phức tạp trong môi trường của mình.
Trong tệp playbook, trong trường hợp này, chúng ta đang sử dụng [ansible-scenario5](../../Days/Configmgmt/ansible-scenario5/playbook5.yml)
```Yaml
- hosts: webservers
become: yes
vars:
http_port: 8000
https_port: 4443
html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 66!"
roles:
- common
- apache2
tags: web
- hosts: proxy
become: yes
roles:
- common
- nginx
tags: proxy
```
Chúng ta có thể xác nhận bằng cách sử dụng `ansible-playbook playbook5.yml --list-tags` mà danh sách các tags sẽ cho chúng ta biết các tags đã được định nghĩa trong playbook của mình.
![](../../Days/Images/Day68_config1.png)
Bây giờ, nếu chúng ta muốn chỉ muốn nhắm tới proxy, chúng ta có thể thực hiện điều này bằng cách chạy lệnh `ansible-playbook playbook5.yml --tags proxy` mà như các bạn thấy bên dưới, playbook sẽ chỉ chạy với proxy được chỉ định.
![](../../Days/Images/Day68_config2.png)
tags cũng có thể được thêm vào task để chúng ta có thể biết được chi tiết về nơi mà điều mà bạn muốn thực hiện. Đó có thể là các thẻ phân loại theo ứng dụng, chẳng hạn như chúng tôi có thể xem qua các tasks và gắn thẻ cho chúng dựa trên cài đặt (installation), cấu hình (configuration) hoặc xoá (removal). Một thẻ rất hữu ích khác mà bạn có thể sử dụng là `tag: always`, nó sẽ đảm bảo bất kể --tags bạn sử dụng trong lệnh của mình, lệnh ansible-playbook sẽ luôn được chạy khi có tags này.
Chúng ta cũng có thể sử dụng nhiều tags với nhau và nếu chúng ta chạy `ansible-playbook playbook5.yml --tags proxy,web` thì nó sẽ chạy tất cả các thành phần có các tags đó. Rõ ràng, trong trường hợp của chúng ta, điều đó có nghãi giống như chạy toàn bộ playbook, nhưng nó sẽ trở nên có ích nếu chúng ta có thêm các plays mới được bổ sung.
Bạn cũng có thể cấu hình nhiều hơn 1 thẻ.
### Variables
Có hai loại biến chính trong Ansible.
- Ansible Facts
- User created
### Ansible Facts
Mỗi khi chúng ta chạy playbook của mình, chúng ta có một task không được định nghĩa gọi là "Gathering facts (Thu thập dữ kiện)", chúng ta có thể sự dụng các biến hoặc dữ kiện này để thực hiện việc tự động hoá các tác vụ của mình.
![](../../Days/Images/Day68_config3.png)
Nếu chúng ta chạy lệnh `ansible proxy -m setup` sẽ thấy nhiều đầu ra ở dạng JSON. Sẽ có nhiều thông tin trên terminal của bạn được sử dụng nên chúng ta muốn tạo một tệp để lưu trữ các thông tin đó bằng lệnh `ansible proxy -m setup >> facts.json` bạn có thể thấy tệp này trong tại đây [ansible-scenario5](../../Days/Configmgmt/ansible-scenario5/facts.json)
![](../../Days/Images/Day68_config4.png)
Nếu bạn mở tệp này, bạn có thể thấy tất cả các loại thông tin cho lệnh của chúng ta. Chugns ta có thể lấy địa chỉ IP, kiến trúc và phiên bản bios của mình. Rất nhiều thông tin hữu ích nếu chúng ta muốn sử dụng trong playbooks của mình.
Một ý tưởng có thể là sử dụng các biến này trong template cho nginx bằng tệp mysite.j2, nơi chúng ta hard-code các địa chỉ IP của các máy chủ web. Bạn có thể làm điều này bằng cách tạo một vòng lặp trong tệp mysite.j2 và nó sẽ duyệt các phần tử trong nhóm [webservers]. Điều này cho phép chúng ta có nhiều hơn 2 máy chủ web được tạo ra hoặc thêm vào trong cấu hình của bộ cân bằng tải này.
```
#Dynamic Config for server {{ ansible_facts['nodename'] }}
upstream webservers {
{% for host in groups['webservers'] %}
server {{ hostvars[host]['ansible_facts']['nodename'] }}:8000;
{% endfor %}
}
server {
listen 80;
location / {
proxy_pass http://webservers;
}
}
```
Kết quả của phần trên sẽ giống như cấu hình hiện tại, nhưng nếu chúng ta thêm nhiều máy chủ web hoặc xoá đi một máy chủ thì nó sẽ tự động thay đổi cấu hình proxy. Để làm việc này, bạn cần cấu hình name resolution (NS).
### User created (Do người dùng tạo)
Các biến do người dùng tạo là những gì chúng ta tự tạo ra. Nếu bạn xem trong playbook, bạn sẽ thấy chúng ta có phần `vars:` và sau đó là danh sách 3 biến chúng ta đang sử dụng ở đây.
```Yaml
- hosts: webservers
become: yes
vars:
http_port: 8000
https_port: 4443
html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 68!"
roles:
- common
- apache2
tags: web
- hosts: proxy
become: yes
roles:
- common
- nginx
tags: proxy
```
Tuy nhiên, chúng ta có thể giữ cho playbook của mình không có biến bằng cách di chuyển chúng vào một tệp riêng biệt. Chúng ta sẽ làm điều này nhưng sẽ chuyển qua thư mục [ansible-scenario6](../../Days/Configmgmt/ansible-scenario6). Trong thư mục gốc của thư mục đó, chúng ta sẽ tạo thư mục group_vars. Sau đó, chúng ta tạo một thư mục khác với tên all (tất cả các group sẽ nhận các biến này). Trong đó, chúng ta sẽ tạo một tệp có tên `common_variables.yml` và chúng ta sẽ sao chép các biến của mình từ playbook vào tệp này. Xoá chúng khỏi playbook cùng với phần `vars:`.
```Yaml
http_port: 8000
https_port: 4443
html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 68!"
```
Bởi vì chúng ta đang liên kết như một biến toàn cục (global variable), chúng ta cũng có thể thêm vào các máy chủ NTP và DNS tạo đây. Các biến được đặt từ cấu trúc thư mục chúng ta đã tạo. Bạn có thể thấy playbook của chúng ta giờ đây trông rất gọn và sạch sẽ.
```Yaml
- hosts: webservers
become: yes
roles:
- common
- apache2
tags: web
- hosts: proxy
become: yes
roles:
- common
- nginx
tags: proxy
```
Một trong những biến đó là http_port, chúng ta có thể sử dụng lại biến này trong vòng lặp for của mình trong tệp mysite.j2 như bên dưới:
```J2
#Dynamic Config for server {{ ansible_facts['nodename'] }}
upstream webservers {
{% for host in groups['webservers'] %}
server {{ hostvars[host]['ansible_facts']['nodename'] }}:{{ http_port }};
{% endfor %}
}
server {
listen 80;
location / {
proxy_pass http://webservers;
}
}
```
Chúng ta cũng có thể cấu hình một ansible fact trong tệp roles/apache2/templates/index.HTML.j2 để biết rằng chúng ta đang ở máy chủ web nào.
```J2
<html>
<h1>{{ html_welcome_msg }}! I'm webserver {{ ansible_facts['nodename'] }} </h1>
</html>
```
Kết quả của việc chạy lệnh `ansible-playbook playbook6.yml` với các thay đổi trong biến có nghĩa rằng khi chúng sẽ biết rằng máy chủ web nào đang được sử dụng khi chúng ta truy cập bộ cân bằng tải của mình.
![](../../Days/Images/Day68_config5.png)
Chúng ta cũng có thể thêm một thư mục có tên là host_vars và tạo một tệp web01.yml và có một thông báo cụ thể hoặc thay đổi giao diện trên mỗi máy chủ nếu chúng ta muốn.
### Inventory Files
Cho đến nay, chúng ta đã sử dụng host file mặc định trong thư mục /etc/ansible để xác định máy chủ của chúng ta. Tuy nhiên, chúng ta có thể có các tệp khác nhau cho các môi trường khác nhau, chẳng hạn như production và staging. Tôi sẽ không tạo ra nhiều môi trường hơn, nhưng chúng ta có thể tạo các host file của mình.
Chúng ta có thể tạo nhiều tệp cho nhiều server và node inventory khác nhau. Chúng ta sẽ gọi chúng bằng cách sử dụng lệnh `ansible-playbook -i dev playbook.yml`, bạn cũng có thể khai báo các biến trong host file của mình rồi in ra hoặc sử dụng biến đó ở một nơi khác trong playbook của bạn. Chẳng hạn như trong ví dụ về ở bài viết hướng dẫn tạo load balancer, chúng ta đã thêm các biến môi trường được tạo trong host file vào template của web page cho load balancer để hiển thị môi trường như một phần của thông báo trang web.
### Triển khai máy chủ Cơ sở dữ liệu
Chúng ta vẫn còn một máy nữa chưa được khởi động và cấu hình. Chúng ta có thể thực hiện điều này bằng cách sử dụng lệnh `vagrant up db01` tại nơi đặt Vagrantfile của chúng ta. Khi điều này hoàn tất và máy chủ có khả năng truy cập được, chúng ta cần đảm bẳo rằng khoá SSH được sao chép bằng cách sử dụng `ssh-copy-id db01` để có thể truy cập nó.
Chugns ta sẽ làm việc với thư mục [ansible-scenario7](../../Days/Configmgmt/ansible-scenario7).
Sau đó, sử dụng lệnh `ansible-galaxy init roles/mysql` để tạo một cấu trúc thư mục mới cho role "MySQL".
Trong playbook của chúng ta, chúng ta sẽ thêm một play block mới cho cấu hình cơ sở dữ liệu. Chúng ta có cơ sở dữ liệu được xác định trong tệp /etc/ansible/hosts. Sau đó, gắn role common và role mới MySQL mới được tạo tại bước trước vào group database (cơ sở dữ liệu). Chúng ta cũng sẽ đánh tag group này với tag database, điều này như đã thảo luận lúc trước, cho phép chúng ta có thể chạy playbook với một thẻ mong muốn.
```Yaml
- hosts: webservers
become: yes
roles:
- common
- apache2
tags:
web
- hosts: proxy
become: yes
roles:
- common
- nginx
tags:
proxy
- hosts: database
become: yes
roles:
- common
- mysql
tags: database
```
Trong cấu trúc thư mục roles, chúng ta sẽ có ba tệp được tạo tự động, chúng ta cần điền các thông tin sau.
Handlers - main.yml
```Yaml
# handlers file for roles/mysql
- name: restart mysql
service:
name: mysql
state: restarted
```
Tasks - install_mysql.yml, main.yml & setup_mysql.yml
install_mysql.yml - Task này sẽ được sử dụng để cài đặt MySQL và đảm bảo rằng dịch vụ đang chạy.
```Yaml
- name: "Install Common packages"
apt: name={{ item }} state=latest
with_items:
- python3-pip
- mysql-client
- python3-mysqldb
- libmysqlclient-dev
- name: Ensure mysql-server is installed latest version
apt: name=mysql-server state=latest
- name: Installing python module MySQL-python
pip:
name: PyMySQL
- name: Ensure mysql-server is running
service:
name: mysql
state: started
```
main.yml là một tệp con trỏ đề xuất chúng ta import_tasks từ các tệp này
```Yaml
# tasks file for roles/mysql
- import_tasks: install_mysql.yml
- import_tasks: setup_mysql.yml
```
setup_mysql.yml - Task này sẽ tạo database và database user.
```Yaml
- name: Create my.cnf configuration file
template: src=templates/my.cnf.j2 dest=/etc/mysql/conf.d/mysql.cnf
notify: restart mysql
- name: Create database user with name 'devops' and password 'DevOps90' with all database privileges
community.mysql.mysql_user:
login_unix_socket: /var/run/mysqld/mysqld.sock
login_user: "{{ mysql_user_name }}"
login_password: "{{ mysql_user_password }}"
name: "{{db_user}}"
password: "{{db_pass}}"
priv: '*.*:ALL'
host: '%'
state: present
- name: Create a new database with name '90daysofdevops'
mysql_db:
login_user: "{{ mysql_user_name }}"
login_password: "{{ mysql_user_password }}"
name: "{{ db_name }}"
state: present
```
Bạn có thể thấy ở phần trên, chúng ta đang sử dụng một số biến để xác định một số cấu hình, chẳng hạn như mật khẩu, tên người dùng và các databases, tất cả chúng được lưu trữ trong tệp group_vars/all/common_variables.yml.
```Yaml
http_port: 8000
https_port: 4443
html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 68!"
mysql_user_name: root
mysql_user_password: "vagrant"
db_user: devops
db_pass: DevOps90
db_name: 90DaysOfDevOps
```
Chúng ta cũng có tệp my.cnf.j2 trong thư mục mẫu, giống như dưới đây:
```J2
[mysql]
bind-address = 0.0.0.0
```
### Chạy playbook
Bây giờ, chúng ta đã thiết lập và chạy máy ảo và có các tệp cấu hình và sẵn sàng để chạy playbook của mình. Playbook này sẽ bao gồm tất cả những hệ thống trước đó nếu chúng ta chạy câu lệnh `ansible-playbook playbook7.yml` hoặc chúng ta có thể chọn chỉ triển kahi group database bằng lệnh `ansible-playbook playbook7.yml --tags database`, nó sẽ chỉ chạy các tệp cấu hình mới.
Tôi chỉ chạy với tag database nhưng tình cờ gặp lỗi. Lỗi này cho tôi biết rằng chúng ta chưa cài đặt pip3 (Python). Chúng ta có thể khắc phục bằng các thêm phần nào vào các common task và cài đặt
![](../../Days/Images/Day68_config6.png)
Sử lỗi ở trên và chạy lại playbook thành công.
![](../../Days/Images/Day68_config7.png)
Có lẽ chúng ta nên đảm bảo rằng mọi thứ đều đúng như cách chúng ta muốn trên máy chủ db01 mới được cấu hình của chúng ta. Có thể kiểm tra từ control node bằng cách sử dụng lệnh `ssh db01`.
Để kết nối tới MySQL tôi sử dụng lệnh `sudo /usr/bin/mysql -u root -p` và nhập password cho user root trên dòng lệnh.
Khi đã kết nói, trước tên, hãy đảm bảo rằng chúng ta đã tạo người dùng của mình với tên DevOps. `select user, host from mysql.user;`
![](../../Days/Images/Day68_config8.png)
Bây giờ chúng ta có thể thử chạy lệnh `SHOW DATABASES;` để kiểm tra xem cơ sở dữ liệu mới của chúng ta đã được tạo hay chưa.
![](../../Days/Images/Day68_config9.png)
Tôi đang sử dụng root để kết nối nhưng cũng có thể đăng nhập sử dụng tài khoản DevOps theo cách tương tự. sử dụng lệnh `sudo /usr/bin/MySQL -u devops -p` nhưng với mật khẩu DevOps90.
Mội điều mà tôi đã phát hiện ra, trong tệp `setup_mysql.yml` tôi phải thêm dòng `login_unix_socket: /var/run/mysqld/mysqld.sock` để kết nối thàng công tới instance db01 chạy MySQL và bây giờ, mỗi khi tôi chạy dòng này, nó sẽ báo có một thay đổi khi tạo người dùng mới, tôi đang tìm kiếm một đề xuất để cài thiện.
## Tài liệu tham khảo
- [What is Ansible](https://www.youtube.com/watch?v=1id6ERvfozo)
- [Ansible 101 - Episode 1 - Introduction to Ansible](https://www.youtube.com/watch?v=goclfp6a2IQ)
- [NetworkChuck - You need to learn Ansible right now!](https://www.youtube.com/watch?v=5hycyr-8EKs&t=955s)
- [Your complete guide to Ansible](https://www.youtube.com/playlist?list=PLnFWJCugpwfzTlIJ-JtuATD2MBBD7_m3u)
Playlist cuối cùng được liệt kê ở trên có rất nhiều đoạn mã và ý tưởng cho bài viết này, nó là một video hướng dẫn tuyệt vời.
Hẹn gặp lại vào [ngày 69](day69.md)

143
2022/vi/Days/day69.md Normal file
View File

@ -0,0 +1,143 @@
---
title: '#90DaysOfDevOps - Tất cả những thứ còn lại của Ansible - Automation Controller, AWX, Vault - Ngày 69'
published: false
description: '90DaysOfDevOps - Tất cả những thứ còn lại của Ansible - Automation Controller, AWX, Vault'
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048714
---
## Tất cả những thứ còn lại của Ansible - Automation Controller, AWX, Vault
Để kết thúc phần về Quản lý cấu hình, tôi muốn xem xét các lĩnh vực khác mà bạn có thể gặp phải khi làm việc với Ansible.
Có rất nhiều sản phẩm tạo nên nền tảng tự động hoá sử dụng Ansible
Red Hat Ansible Automation Platform là nền tảng để xây dựng và vận hành tự động hoá trong toàn tổ chức. Nền tảng này bao gồm tất cả các công cụ cần thiết để tự động hoá toàn doanh nghiệp.
![](../../Days/Images/Day69_config1.png)
Tôi sẽ cố gắng và trình bày một số trong các công cụ này ở bài viết này. Nhưng để biết thêm các thông tin đầy đủ thì các bạn nên tham khảo trang web chính thức của Red Hat Ansible. [Ansible.com](https://www.ansible.com/?hsLang=en-us)
### Ansible Automation Controller | AWX
Tôi đã kết hợp hai công cụ này với nhau vì Automation Controller và AWX có chức năng tương tự nhau.
Dự án AWX hay viết tắt là AWX là một dự án cộng đồng mã nguồn mở, được tài trợ bởi Red Hat, cho phép bạn kiểm soát tốt hơn các dự án Ansible trong môi trường của mình. AWX là dự án mà từ đó automation controller được tạo ra.
Nếu bạn đang tìm kiếm một giải pháp cho doanh nghiệp thì bạn nên xem xét Automation Controller hoặc bạn có thể đã nghe tới cái tên Ansible Tower. Ansible Automation Controller là control plan cho nền tảng tự động của Ansible (Ansible Automation Platform).
Cả AWX và Automation Controller có những tính năng sau trong tất cả những tính năng khác mà chúng tôi đã đề cập trong loạt bài viết này cho tới thời điểm hiện tại.
- Giao diện người dùng
- Kiểm soát truy cập dựa trên role (Role-Based Access Control)
- Quy trình làm việc (Workflows)
- Tích hợp CI/CD
Automation Controller là giải pháp cho doanh nghiệp mà bạn cần trả tiền cho sự hỗ trợ từ Red Hat.
Chúng ta sẽ nói tới việc triển khai AWX trong môi trường Kubernetes sử dụng minikube.
### Triển khai Ansible AWX
AWX không cần phải triển khai trên một Kubernetes cluster, [github](https://github.com/ansible/awx) của AWX sẽ cung cấp các bạn các thông tin chi tiết. Tuy nhiên, bắt đầu từ phiên bản 18.0, AWX Operator là cách cài đặt được khuyến nghị.
Trước hết, chúng ta cần một minikube cluster. Chúng ta có thể làm điều này giống như trong phần Kubernetes bằng cách tạo một minikube cluster bằng lệnh `minikube start --cpus=4 --memory=6g --addons=ingress`.
![](../../Days/Images/Day69_config2.png)
Bạn có thể xem tài liệu chính thức của [Ansible AWX Operator](https://github.com/ansible/awx-operator) tại đây. Theo như hướng dẫn cài đặt, bạn nên sao chép repository này rồi chạy các deployment trong đó.
Tôi đã fork repo ở trên và để nó tại `git clone https://github.com/MichaelCade/awx-operator.git`, lời khuyên của tôi là bạn nên làm điều tương tự nhưng không sử dụng repository của tôi vì có thể tôi đã thay đổi một số thứ cũng như xoá repository đó.
Trong repository, bạn sẽ thấy tệp awx-demo.yml, chúng ta cần đổi từ `NodePort` thành `ClusterIP` như bên dưới:
```Yaml
---
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
name: awx-demo
spec:
service_type: ClusterIP
```
Bước tiếp theo là khai báo namespace, nơi chúng ta sẽ triển khai awx operator, sử dụng lệnh `export NAMESPACE=awx` sau đó là `make deploy` để bắt đầu triển khai.
![](../../Days/Images/Day69_config3.png)
Khi kiểm tra, chúng ta đã có namespace mới và awx-operator-controller pod chạy trong name space đó. `kubectl get pods -n awx`
![](../../Days/Images/Day69_config4.png)
Trong repo được clone, bạn sẽ tìm thấy một tệp có tên awx-demo.yml mà chúng ta muốn triển khai trên Kubernetes cluster và awx namespace. `kubectl create -f awx-demo.yml -n awx`
![](../../Days/Images/Day69_config5.png)
Bạn có thể theo dõi quá trình với lệnh `kubectl get pods -n awx -w`.
Bạn sẽ thấy gì đó giống với ảnh mà bạn nhìn thấy mọi dưới khi mọi thứ chạy một cách bình thường.
![](../../Days/Images/Day69_config6.png)
Bây giờ, chúng ta có thể truy cập tới awx deployment của mình khi chạy lệnh sau trên một terminal mới `minikube service awx-demo-service --url -n $NAMESPACE` để có thể truy cập từ một minikube ingress.
![](../../Days/Images/Day69_config7.png)
Sau đó, nếu chúng ta mởi trình duyệt và truy cập đến địa chỉ đó, bạn có thể thấy chúng ta phải nhập tên người dùng và mật khẩu.
![](../../Days/Images/Day69_config8.png)
Tên người dùng mặc định là admin, để lấy mật khẩu, chúng ta có thể chạy lệnh sau đây `kubectl get secret awx-demo-admin-password -o jsonpath="{.data.password}" -n awx| base64 --decode`
![](../../Days/Images/Day69_config9.png)
Nó sẽ cung cấp cho bạn một giao diện người dùng để quản lý các playbook, tasks quản lý cấu hình của bạn tại một địa điểm tập trung, nó cũng cho phép bạn làm việc theo nhóm với tất cả những tác vụ chúng ta đã làm cho đến nay trong loạt bài viết này, nó giống với một ansible controler.
Đây là một trong những phần mà bạn có thể thử và dành một khoảng thời gian sử dụng để xem qua các chức năng khác của công cụ này.
Tôi sẽ nhắc tới một tài nguyên rất chất lượng từ Jeff Geerling, nó sẽ có rất nhiều chi tiết cụ thể khi sử dụng Ansible AWX. [Ansible 101 - Episode 10 - Ansible Tower and AWX](https://www.youtube.com/watch?v=iKmY4jEiy_A&t=752s)
Trong video này, anh ấy cũng đi sâu, chi tiết về sự khác biệt giữa Automation Controller (trước đây là Ansible Tower) và Ansible AWX (miễn phí và mã nguồn mở).
### Ansible Vault
`ansible-vault` cho phép chúng ta mã hoá và giải mã các tệp dữ liệu Ansible. Trong suốt phần này, chúng ta đã bỏ qua việc này và đã để một số thông tin nhạy cảm của chúng ta dưới dạng text.
Được tích hợp trong tệp nhị phân của Ansible binary, chúng ta có `ansible-vault` cho phép chúng ta có thể giấu đi những thông tin nhạy cảm.
![](../../Days/Images/Day69_config10.png)
Secrets Management đã trở thành một lĩnh vực khác mà đáng ra chúng ta nên dành ra nhiều thời gian hơn với một số công cụ khác như HashiCorp Vault hay AWS Key Management Service. Tôi sẽ đánh đầu đây là một lĩnh vực cần được tìm hiểu sâu hơn.
Chúng ta cũng có một tài liệu chất lượng cùng demo để theo dõi từ Jeff Geerling [Ansible 101 - Episode 6 - Ansible Vault and Roles](https://www.youtube.com/watch?v=JFweg2dUvqM)
### Ansible Galaxy (Docs)
Bây giờ, chúng ta đã từng sử dụng `ansible-galaxy` để tạo một số roles và cấu trúc tệp cho dự án demo. Tuy nhiên, chúng ta cũng có [Ansible Galaxy documentation](https://galaxy.ansible.com/docs/)
"Galaxy là một hub để tìm kiếm và chia sẻ nội dung của Ansible."
### Kiểm thử với Ansible
- [Ansible Molecule](https://molecule.readthedocs.io/en/latest/) - Dự án được thiết kế để hỗ trợ việc phát triển và kiểm thử Ansible roles
- [Ansible Lint](https://ansible-lint.readthedocs.io/en/latest/) - Công cụ CLI cho việc linting playbooks, roles và collections
### Các tài nguyên khác
- [Ansible Documentation](https://docs.ansible.com/ansible/latest/index.html)
## Tài liệu tham khảo
- [What is Ansible](https://www.youtube.com/watch?v=1id6ERvfozo)
- [Ansible 101 - Episode 1 - Introduction to Ansible](https://www.youtube.com/watch?v=goclfp6a2IQ)
- [NetworkChuck - You need to learn Ansible right now!](https://www.youtube.com/watch?v=5hycyr-8EKs&t=955s)
- [Your complete guide to Ansible](https://www.youtube.com/playlist?list=PLnFWJCugpwfzTlIJ-JtuATD2MBBD7_m3u)
Playlist cuối cùng được liệt kê ở trên có rất nhiều đoạn mã và ý tưởng cho bài viết này, nó là một video hướng dẫn tuyệt vời.
Bài đăng này kết thúc phần về quản lý cấu hình, tiếp theo chúng ta sẽ chuyển qua phần về CI/CD Pipelines và một số công cụ và quy trình mà chúng tôi có thể thấy và sử dụng để đạt được quy trình làm việc cho quá trình phát triển và phát hành ứng dụng.
Hẹn gặp lại vào [ngày 70](day70.md)