From e2f038a8fd61a2a6c1d6cdef134809a85a92ad46 Mon Sep 17 00:00:00 2001 From: Quang Mau Date: Wed, 9 Aug 2023 00:27:39 +0900 Subject: [PATCH 01/15] added d64-65 --- 2022/vi/Days/day64.md | 90 ++++++++++++++ 2022/vi/Days/day65.md | 282 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 372 insertions(+) create mode 100644 2022/vi/Days/day64.md create mode 100644 2022/vi/Days/day65.md diff --git a/2022/vi/Days/day64.md b/2022/vi/Days/day64.md new file mode 100644 index 0000000..259a36f --- /dev/null +++ b/2022/vi/Days/day64.md @@ -0,0 +1,90 @@ +--- +title: '#90DaysOfDevOps - Ansible: Bắt đầu - Ngày 64' +published: false +description: '90DaysOfDevOps - Ansible: Bắt đầu' +tags: 'devops, 90daysofdevops, learning' +cover_image: null +canonical_url: null +id: 1048765 +--- + + +## Ansible: Bắt đầu + +Chúng ta đã đề cập một chút về Ansible là gì trong [bài viết ngày hôm qua](day63.md) Nhưng chúng ta sẽ có một số thông tin bổ sung ở đây. Thứ nhất, Ansible là sản phẩm của RedHat. Thứ hai, agentless , kết nối thông qua SSH và chạy các câu lệnh. Thứ ba, nó đa nền tảng (Linux & macOS, WSL2) và là mã nguồn mở (cũng có tùy chọn trả phí cho doanh nghiệp). + +### Cài đặt Ansible + +Như bạn có thể đoán được, RedHat và team Ansible đã làm rất tốt việc tài liệu hoá Ansible. Việc cài đặt thường bắt đầu với các bước cài đặt mà bạn có thể tìm thấy [tại đây](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html). Hãy nhớ rằng chúng ta đã nói rằng Ansible là một công cụ tự động hóa agentless, công cụ này được triển khai cho một hệ thống từ "Node điều khiển" - node điều khiển này sẽ quản lý máy và các thiết bị khác (có thể là mạng máy tính) thông qua SSH. + +Trong tài liệu được liên kết ở trên, điều được chỉ rõ là node điều khiển không thể chạy hệ điều hành Windows. + +Đối với node điều khiển của tôi và ít nhất là bài demo, tôi sẽ sử dụng máy ảo Linux mà chúng ta đã tạo lại trong [phần Linux](day20.md) làm node điều khiển của mình. + +Hệ thống này đang chạy Ubuntu và chỉ cần các lệnh sau để cài đặt. + +```Shell +sudo apt update +sudo apt install software-properties-common +sudo add-apt-repository --yes --update ppa:ansible/ansible +sudo apt install ansible +``` + +Bây giờ chúng ta đã cài đặt ansible trên node điều khiển của mình, bạn có thể kiểm tra điều này bằng cách chạy `ansible --version` và bạn sẽ thấy gì đó tương tự như bên dưới. + +![](../../Days/Images/Day64_config1.png) + +Trước khi chúng ta bắt đầu xem xét việc kiểm soát các node khác trong môi trường của mình, chúng ta cũng có thể kiểm tra chức năng của ansible bằng cách chạy một lệnh trên máy cục bộ của chúng ta `ansible localhost -m ping` sẽ sử dụng [Ansible Module](https://docs.ansible.com/ansible/2.9/user_guide/modules_intro.html) và đây là một cách nhanh chóng để thực hiện một tác vụ trên nhiều hệ thống khác nhau. Nó không thú vị lắm khi chúng ta chỉ có máy chủ lưu trữ cục bộ nhưng hãy tưởng tượng bạn muốn làm thứ gì đó hoặc đảm bảo rằng tất cả các hệ thống của bạn đã hoạt động khi bạn có hơn 1000 máy chủ và thiết bị. + +![](../../Days/Images/Day64_config2.png) + +Hoặc cách sử dụng thực tế cho một module có thể là `ansible webservers -m service -a "name=httpd state=started"` điều này sẽ cho chúng tôi biết liệu tất cả máy chủ web của chúng tôi có dịch vụ httpd đang chạy hay không. Thuật ngữ máy chủ web được sử dụng trong lệnh đó. + +### hosts + +Cách tôi sử dụng máy chủ cục bộ ở trên để chạy module ping trên hệ thống, tôi không thể chỉ định một máy khác trên mạng của mình, ví dụ: trong môi trường tôi đang sử dụng máy chủ Windows nơi VirtualBox đang chạy có bộ điều hợp mạng với IP 10.0.0.1 nhưng bạn có thể thấy bên dưới rằng tôi có thể ping tới nó nhưng tôi không thể sử dụng ansible để thực hiện tác vụ đó. + +![](../../Days/Images/Day64_config3.png) + +Để chúng ta chỉ định máy chủ của mình hoặc các node mà chúng ta muốn tự động hóa với các tác vụ này, chúng ttaôi cần xác định chúng. Chúng ta có thể xác định chúng bằng cách điều hướng đến thư mục /etc/ansible trên hệ thống của bạn. + +![](../../Days/Images/Day64_config4.png) + +Tệp chúng tôi muốn chỉnh sửa là tệp hosts, sử dụng trình soạn thảo văn bản, chúng ta có thể định nghĩa máy chủ của mình. Tệp hosts chứa nhiều hướng dẫn về cách sử dụng và sửa đổi tệp. Chúng ta sẽ cuộn xuống dưới cùng và sẽ tạo một nhóm mới có tên là [windows] và thêm địa chỉ IP `10.0.0.1` của chúng ta cho máy chủ lưu đó và lưu lại tệp. + +![](../../Days/Images/Day64_config5.png) + +Tuy nhiên, hãy nhớ rằng tôi đã nói rằng bạn sẽ cần có sẵn SSH để cho phép Ansible kết nối với hệ thống của bạn. Như bạn có thể thấy bên dưới khi tôi chạy `ansible windows -m ping`, chúng tôi không thể truy cập được vì mọi thứ không kết nối được qua SSH. + +![](../../Days/Images/Day64_config6.png) + +Bây giờ tôi bắt đầu thêm một số máy chủ khác, một tên khác cho tệp này vì đây là nơi bạn sẽ xác định tất cả các thiết bị của mình, chẳng hạn như thiết bị mạng, bộ chuyển mạch và bộ định tuyến cũng sẽ được thêm vào đây và được phân nhóm. Mặc dù vậy, trong tệp hosts của chúng ta, tôi cũng đã thêm thông tin đăng nhập của mình để truy cập group Linux của hệ thống. + +![](../../Days/Images/Day64_config7.png) + +Bây giờ nếu chúng ta chạy `ansible Linux -m ping`, chúng ta sẽ thành công như bên dưới. + +![](../../Days/Images/Day64_config8.png) + +Sau đó, chúng ta có các yêu cầu về các nodes, đây là những hệ thống đích mà bạn muốn tự động hóa cấu hình. Chúng ta không cài đặt bất kỳ thứ gì cho Ansible trên những hệ thống này (ý tôi là chúng ta có thể đang cài đặt phần mềm nhưng không có ứng dụng khách nào từ Ansible mà chúng ta cần) Ansible sẽ thực hiện kết nối qua SSH và gửi tất cả mọi thứ qua qua SFTP.(Nếu bạn muốn và bạn đã định cấu hình SSH, bạn có thể sử dụng SCP và SFTP.) + +### Các câu lệnh Ansible + +Bạn đã thấy rằng chúng ta có thể chạy `ansible Linux -m ping` trên máy Linux của chúng ta và nhận được phản hồi, về cơ bản, với Ansible, chúng ta có thể chạy nhiều lệnh đặc biệt. [ad hoc commands](https://docs.ansible.com/ansible/latest/user_guide/intro_adhoc.html) + +You saw that we were able to run `ansible Linux -m ping` against our Linux machine and get a response, basically, with Ansible we can run many ad-hoc commands. Nhưng bạn có thể chạy chương trình này với một nhóm hệ thống và lấy lại thông tin đó. [ad hoc commands](https://docs.ansible.com/ansible/latest/user_guide/intro_adhoc.html) + +Nếu bạn thấy mình lặp lại các lệnh hoặc thậm chí tệ hơn là bạn phải đăng nhập vào các hệ thống riêng lẻ để chạy các lệnh này thì Ansible có thể trợ giúp. Ví dụ: lệnh đơn giản bên dưới sẽ cung cấp cho chúng ta đầu ra của tất cả các chi tiết hệ điều hành cho tất cả các hệ thống mà chúng ta thêm vào nhóm Linux của mình. +`ansible linux -a "cat /etc/os-release"` + +Các trường hợp sử dụng khác có thể là khởi động lại hệ thống, sao chép tệp và quản lý người dùng. Bạn cũng có thể kết hợp các lệnh ad-hoc với các module Ansible. + +Các lệnh ad-hoc sử dụng một mô hình khai báo, tính toán và thực hiện các hành động cần thiết để đạt được trạng thái cuối cùng được chỉ định. Chúng đạt được một dạng bình thường bằng cách kiểm tra trạng thái hiện tại trước khi chúng bắt đầu và sẽ không làm gì trừ khi trạng thái hiện tại khác với trạng thái cuối cùng được chỉ định. + +## 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) + +Hẹn gặp lại vào [ngày 65](day65.md). diff --git a/2022/vi/Days/day65.md b/2022/vi/Days/day65.md new file mode 100644 index 0000000..c617805 --- /dev/null +++ b/2022/vi/Days/day65.md @@ -0,0 +1,282 @@ +--- +title: '#90DaysOfDevOps - Ansible Playbooks - Day 65' +published: false +description: 90DaysOfDevOps - Ansible Playbooks +tags: 'devops, 90daysofdevops, learning' +cover_image: null +canonical_url: null +id: 1049054 +--- + +### Ansible Playbooks + +Trong bài viết này, chúng ta sẽ xem xét lý do chính mà chúng ta sử dụng Ansible. Thật tuyệt khi chỉ cần thực hiện một lệnh duy nhất trên nhiều máy chủ khác nhau nhằm thực hiện các lệnh đơn giản như khởi động lại một danh sách dài các máy chủ thay vì phải kết nối với từng máy chủ một. + +Nhưng còn việc sử dụng một hệ điều hành mới được cài đặt và khai báo các phần mềm và dịch vụ mà chúng ta muốn chạy trên hệ thống đó và đảm bảo rằng tất cả chúng đều chạy ở trạng thái mong muốn thì sao. + +Đây là khi các playbook ansible xuất hiện. Playbook cho phép chúng ta sử dụng nhóm máy chủ của mình và thực hiện các tác vụ cấu hình và cài đặt đối với nhóm đó. + +### Playbook format + +Playbook > Plays > Tasks + +Đối với bất kỳ ai chơi thể thao, bạn có thể đã bắt gặp thuật ngữ playbook, khi đó playbook là thứ cho cả đội biết bạn sẽ chơi như thế nào bao gồm nhiều plays (lượt chơi) và tasks (nhiệm vụ) khác nhau. Nếu chúng ta coi các plays là các tình huống cố định trong một môn thể thao, và các task (nhiệm vụ) được liên kết với mỗi play (lượt chơi), bạn có thể có nhiều tasks để tạo thành một play và trong playbook, bạn có thể có nhiều các plays khác nhau. + +Các playbook này được viết bằng YAML (YAML không phải là ngôn ngữ đánh dấu), bạn sẽ tìm thấy rất nhiều phần mà chúng ta đã đề cập cho đến nay, đặc biệt là Containers và Kubernetes để thấy tầm quan trọng của các tệp cấu hình được định dạng YAML. + +Chúng ta hãy xem một playbook đơn giản - playbook.yml. + +```Yaml +- name: Simple Play + hosts: localhost + connection: local + tasks: + - name: Ping me + ping: + - name: print os + debug: + msg: "{{ ansible_os_family }}" +``` + +Chúng ta có thể tìm thấy file ở trên tại [simple_play](../../Days/Configmgmt/simple_play.yml). Nếu sau đó chúng ta sử dụng lệnh `ansible-playbook simple_play.yml`, chúng ta sẽ đi qua các bước sau. + +![](../../Days/Images/Day65_config1.png) + +Bạn có thể thấy nhiệm vụ đầu tiên là "thu thập các bước" đã xảy ra, nhưng chúng ta không kích hoạt hoặc yêu cầu điều này? Mô-đun này được playbook gọi tự động để thu thập các biến hữu ích về máy chủ từ xa. [ansible.buildin.setup](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/setup_module.html) + +Nhiệm vụ thứ hai của chúng ta là cài đặt ping, đây không phải là ping ICMP mà là tập lệnh python để báo cáo lại `pong` khi kết nối thành công với máy chủ hoặc máy chủ từ xa. [ansible.builtin.ping](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/ping_module.html) + +Sau đó, nhiệm vụ thứ ba hoặc thứ hai được xác định của chúng ta là nhiệm đầu tiên sẽ chạy trừ khi bạn tắt tính năng in ra thông báo cho chúng ta biết hệ điều hành hiện tại. Trong nhiệm vụ này, chúng ta đang sử dụng các điều kiện, chúng ta có thể chạy playbook này với tất cả các loại hệ điều hành khác nhau và nó sẽ trả về tên hệ điều hành. + +```Yaml +tasks: + - name: "shut down Debian flavoured systems" + command: /sbin/shutdown -t now + when: ansible_os_family == "Debian" +``` + +### Sử dụng vagrant để thiết lập môi trường + +Chúng ta sẽ sử dụng Vagrant để thiết lập môi trường trên node của mình, tôi sẽ cài đặt số node là 4 để hợp lý nhưng bạn có thể kỳ vọng rằng con số này có thể dễ dàng tăng lên 300 hoặc 3000 và đây là sức mạnh của Ansible và các công cụ quản lý cấu hình khác giúp cấu hình máy chủ của bạn một cách dễ dàng. + +Bạn có thể tìm thấy tệp này ở đây ([Vagrantfile](../../Days/Configmgmt/Vagrantfile)) + +```Vagrant +Vagrant.configure("2") do |config| + servers=[ + { + :hostname => "db01", + :box => "bento/ubuntu-21.10", + :ip => "192.168.169.130", + :ssh_port => '2210' + }, + { + :hostname => "web01", + :box => "bento/ubuntu-21.10", + :ip => "192.168.169.131", + :ssh_port => '2211' + }, + { + :hostname => "web02", + :box => "bento/ubuntu-21.10", + :ip => "192.168.169.132", + :ssh_port => '2212' + }, + { + :hostname => "loadbalancer", + :box => "bento/ubuntu-21.10", + :ip => "192.168.169.134", + :ssh_port => '2213' + } + + ] + +config.vm.base_address = 600 + + servers.each do |machine| + + config.vm.define machine[:hostname] do |node| + node.vm.box = machine[:box] + node.vm.hostname = machine[:hostname] + + node.vm.network :public_network, bridge: "Intel(R) Ethernet Connection (7) I219-V", ip: machine[:ip] + node.vm.network "forwarded_port", guest: 22, host: machine[:ssh_port], id: "ssh" + + node.vm.provider :virtualbox do |v| + v.customize ["modifyvm", :id, "--memory", 2048] + v.customize ["modifyvm", :id, "--name", machine[:hostname]] + end + end + end + +end +``` + +Sử dụng lệnh `vagrant up` để khởi động các máy này trong VirtualBox. Bạn có thể thêm nhiều bộ nhớ hơn và xác định một địa chỉ private_network khác cho mỗi máy nhưng cài đặt trên hoạt động trong môi trường của tôi. Hãy nhớ rằng môi trường của chúng ta là máy tính để bàn Ubuntu đã triển khai trong phần viết về Linux. + +Nếu bạn có hạn chế về tài nguyên thì bạn cũng có thể chạy `vagrant up web01 web02` để chỉ khởi động các máy chủ web mà chúng ta đang sử dụng ở đây. + +### Cấu hình máy chủ ansible + +Bây giờ chúng ta đã sẵn sàng cho môi trường của mình, chúng ta có thể kiểm tra ansible để làm việc này, chúng ta sẽ sử dụng máy tính để bàn Ubuntu của mình (Bạn có thể sử dụng máy tính này nhưng bạn cũng có thể sử dụng bất kỳ máy dựa trên Linux nào trong mạng của mình để truy cập vào mạng bên dưới) để làm máy chủ điều khiển, chúng ta cũng hãy thêm các node mới vào nhóm trong tệp ansible hosts file, bạn có thể coi tệp này như một inventory, một giải pháp thay thế cho tệp này là một tệp inventory khác được gọi trong lệnh ansible với `-i filename`. Điều này có thể hữu ích so với việc sử dụng hosts file vì bạn có thể có các tệp khác nhau sử dụng cho các môi trường khác nhau, có thể là production, staging, test hoặc build. Bởi vì chúng ta đang sử dụng hosts file mặc định nên chúng ta không cần chỉ định nó. + +Tôi đã thêm phần sau vào hosts file mặc định. + + +```Text +[control] +ansible-control + +[proxy] +loadbalancer + +[webservers] +web01 +web02 + +[database] +db01 + +``` + +![](../../Days/Images/Day65_config2.png) + +Trước khi tiếp tục, chúng ta muốn đảm bảo có thể chạy một lệnh trên các nodes của mình, hãy chạy `ansible nodes -m command -a hostname` lệnh đơn giản này sẽ kiểm tra xem chúng ta có kết nối hay không và báo cáo lại tên máy chủ của chúng ta. + +Ngoài ra, lưu ý rằng tôi đã thêm các nodes và IP này vào node điều khiển Ubuntu của mình trong tệp /etc/hosts để đảm bảo nó có thể kết nối tới các máy chủ khác. Chúng ta cũng có thể cần thực hiện cấu hình SSH cho từng nodes từ máy chủ Ubuntu. + +```Text +192.168.169.140 ansible-control +192.168.169.130 db01 +192.168.169.131 web01 +192.168.169.132 web02 +192.168.169.133 loadbalancer +``` + +![](../../Days/Images/Day65_config3.png) + +Ở giai đoạn này, chúng ta muốn nói tới việc thiết lập các khóa SSH giữa điều khiển của bạn và các nodes máy chủ của bạn. Đây là việc chúng ta sẽ làm tiếp theo, bạn cũng có thể thêm các biến vào hosts file của bạn để cung cấp tên người dùng và mật khẩu. Nhưng tôi khuyên các bạn không nên điều này vì nó không bao giờ là một thực hành tốt. + +Để thiết lập SSH và chia sẻ giữa các nodes của bạn, hãy làm theo các bước bên dưới, bạn sẽ phải nhập mật khẩu (`vagrant`) và có thể bạn sẽ cần nhấn `y` vài lần để chấp nhận. + +`ssh-keygen` + +![](../../Days/Images/Day65_config5.png) + +`ssh-copy-id localhost` + +![](../../Days/Images/Day65_config6.png) + +Bây giờ, nếu bạn đã bật tất cả các máy ảo của mình thì bạn có thể chạy `ssh-copy-id web01 && ssh-copy-id web02 && ssh-copy-id loadbalancer && ssh-copy-id db01` và bạn sẽ phải mật khẩu trong trường hợp của chúng ta và mật khẩu sẽ là `vagrant` + +Tôi không chạy tất cả các máy ảo của mình mà chỉ chạy các máy chủ web nên tôi đã nhập lệnh `ssh-copy-id web01 && ssh-copy-id web02` + +![](../../Days/Images/Day65_config7.png) + +Trước khi chạy bất kỳ playbook nào, tôi muốn đảm bảo rằng tôi có kết nối tới các groups của mình, vì vậy tôi đã chạy lệnh `ansible webservers -m ping` để kiểm tra. + +![](../../Days/Images/Day65_config4.png) + +### Playbook Ansible "thực" đầu tiên + +Ansible playbook đầu tiên của chúng ta sẽ định cấu hình các máy chủ web, chúng ta đã nhóm các máy chủ này trong hosts file theo nhóm [webservers]. + +Trước khi chạy playbook của mình, chúng ta có thể xác nhận rằng web01 và web02 chưa cài đặt apache. Phần đầu của ảnh chụp màn hình bên dưới cho bạn thấy bố cục thư mục và tệp mà tôi đã tạo trong máy chủ ansible của mình để chạy playbook này, chúng ta có `playbook1 .yml`, sau đó trong thư mục mẫu, chúng ta có các tệp `index.html.j2` và `ports.conf.j2`. + +Sau đó chúng ta SSH vào web01 để kiểm tra xem đã cài apache chưa? + +![](../../Days/Images/Day65_config8.png) + +Bạn có thể thấy ở phần trên rằng chúng ta chưa cài đặt apache trên web01, vì vậy chúng ta có thể khắc phục điều này bằng cách chạy playbook bên dưới. + +```Yaml +- hosts: webservers + become: yes + vars: + http_port: 8000 + https_port: 4443 + html_welcome_msg: "Hello 90DaysOfDevOps" + tasks: + - name: ensure apache is at the latest version + apt: + name: apache2 + state: latest + + - name: write the apache2 ports.conf config file + template: + src: templates/ports.conf.j2 + dest: /etc/apache2/ports.conf + notify: + - restart apache + + - name: write a basic index.html file + template: + src: templates/index.html.j2 + dest: /var/www/html/index.html + notify: + - restart apache + + - name: ensure apache is running + service: + name: apache2 + state: started + + handlers: + - name: restart apache + service: + name: apache2 + state: restarted +``` + +Phân tích playbook ở trên: + +- `- hosts: webservers` điều này có nghĩa là nhóm chạy playbook này là một nhóm có tên là webservers +- `become: yes` có nghĩa là người dùng đang chạy playbook của chúng ttaôi sẽ trở thành root trên các hệ thống được kết nối. Bạn sẽ phải nhập mật khẩu root. +- Sau đó, chúng ta có `vars` và nó dùng để xác định một số biến môi trường mà chúng ta muốn trong các máy chủ web của mình. + +Tiếp theo, chúng ta bắt đầu các tasks, + +- Task 1 là đảm bảo rằng apache đang chạy phiên bản mới nhất +- Task 2 là viết tệp tin port.conf từ nguồn của chúng ta được tìm thấy trong thư mục mẫu. +- Task 3 là tạo 1 file index.html cơ bản +- Task 4 là đảm bảo apache đang chạy + +Cuối cùng, chúng ta có phần về handlers, [Handlers: Running operations on change](https://docs.ansible.com/ansible/latest/user_guide/playbooks_handlers.html) + +"Đôi khi bạn muốn task chỉ chạy khi có thay đổi trên máy. Ví dụ: bạn có thể muốn khởi động lại dịch vụ nếu task cập nhật cấu hình của dịch vụ đó, còn nếu không có thay đổi thì không. Ansible sử dụng trình handlers để giải quyết điều này. Handlers là các task chỉ chạy khi được thông báo. Mỗi trình xử lý phải có một tên duy nhất trên toàn bộ các playbooks." + +Ở giai đoạn này, bạn có thể nghĩ rằng chúng ta đã triển khai 5 máy ảo (bao gồm cả máy chủ Ubuntu hoạt động như Ansible Control của chúng ta) Các hệ thống khác sẽ hoạt động trong phần còn lại của bài viết này. + +### Chạy playbook + +Bây giờ chúng ta đã sẵn sàng để chạy playbook trên các nodes của mình. Để chạy playbook, chúng ta có thể sử dụng `ansible-playbook playbook1.yml` Chúng ta đã xác định các máy chủ mà playbook sẽ chạy trong playbook và điều này sẽ hướng dẫn các tasks đã xác định. + +Khi lệnh hoàn tất, chúng ta nhận được một đầu ra hiển thị các plays và tasks, quá trình này có thể mất một chút thời gian, bạn có thể thấy từ hình ảnh bên dưới rằng quá trình này đã mất một lúc để thực hiện và cài đặt trạng thái mong muốn. + +![](../../Days/Images/Day65_config9.png) + + +Sau đó, chúng ta có thể kiểm tra lại điều này bằng cách nhảy vào một node và kiểm tra xem chúng ta đã cài đặt phần mềm trên node của mình chưa. + +![](../../Days/Images/Day65_config10.png) + + +Để giải quyết vấn đề này vì chúng ta đã triển khai hai máy chủ web độc lập với phần trên, giờ đây chúng ta có thể điều hướng đến các IP tương ứng mà chúng ta đã xác định và nhận trang web mới của mình. + +![](../../Days/Images/Day65_config11.png) + +Chúng ta sẽ xây dựng trên playbook này khi chúng ta chuyển qua phần còn lại của phần này. Tôi cũng quan tâm đến việc sử dụng máy chủ Ubuntu của chúng ta và xem liệu chúng ta có thể khởi động các ứng dụng và cấu hình của mình bằng Ansible hay không. Bạn có thể thấy điều đó khi chúng ta có thể sử dụng local host trong các lệnh của mình, chẳng hạn như chúng ta cũng có thể chạy playbook đối với local host của mình. + +Một điều khác cần bổ sung ở đây là chúng ta chỉ thực sự làm việc với máy ảo Ubuntu nhưng Ansible không hề biết tới các hệ thống đích. Các lựa chọn thay thế đã đề cập trước đây để quản lý hệ thống của bạn không thể mở rộng khi bạn sử dụng một số lượng lớn máy chủ, cộng với sự khó khăn ngay cả với 3 nodes. Chúng ta cũng có thể sử dụng shell script như đã đề cập trong phần Linux nhưng các node này có khả năng cao là sẽ khác nhau nên dù có thể thực hiện được nhưng sau đó cần một người để duy trì và quản lý các tập lệnh đó. Ansible miễn phí và dễ dàng hơn so với việc phải có một tập lệnh chuyên dụng. + +## 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 66](day66.md) From c12d23099670865bc138c6b8a9b631bb23160b06 Mon Sep 17 00:00:00 2001 From: Mau Ha Quang Date: Wed, 9 Aug 2023 02:18:04 +0900 Subject: [PATCH 02/15] Update 2022/vi/Days/day64.md Co-authored-by: Henry Vu <26101787+hungran@users.noreply.github.com> --- 2022/vi/Days/day64.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2022/vi/Days/day64.md b/2022/vi/Days/day64.md index 259a36f..f8a292b 100644 --- a/2022/vi/Days/day64.md +++ b/2022/vi/Days/day64.md @@ -11,7 +11,7 @@ id: 1048765 ## Ansible: Bắt đầu -Chúng ta đã đề cập một chút về Ansible là gì trong [bài viết ngày hôm qua](day63.md) Nhưng chúng ta sẽ có một số thông tin bổ sung ở đây. Thứ nhất, Ansible là sản phẩm của RedHat. Thứ hai, agentless , kết nối thông qua SSH và chạy các câu lệnh. Thứ ba, nó đa nền tảng (Linux & macOS, WSL2) và là mã nguồn mở (cũng có tùy chọn trả phí cho doanh nghiệp). +Chúng ta đã đề cập một chút về Ansible là gì trong [bài viết ngày hôm qua](day63.md) Nhưng chúng ta sẽ có một số thông tin bổ sung ở đây. Thứ nhất, Ansible là sản phẩm của RedHat. Thứ hai, agentless, kết nối thông qua SSH và chạy các câu lệnh. Thứ ba, nó đa nền tảng (Linux & macOS, WSL2) và là mã nguồn mở (cũng có tùy chọn trả phí cho doanh nghiệp). ### Cài đặt Ansible From 9fb6e61d1be39aa5edb63d3fc234865a1680d6eb Mon Sep 17 00:00:00 2001 From: Mau Ha Quang Date: Wed, 9 Aug 2023 02:18:26 +0900 Subject: [PATCH 03/15] Update 2022/vi/Days/day64.md Co-authored-by: Henry Vu <26101787+hungran@users.noreply.github.com> --- 2022/vi/Days/day64.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2022/vi/Days/day64.md b/2022/vi/Days/day64.md index f8a292b..7bd1036 100644 --- a/2022/vi/Days/day64.md +++ b/2022/vi/Days/day64.md @@ -46,7 +46,7 @@ Cách tôi sử dụng máy chủ cục bộ ở trên để chạy module ping ![](../../Days/Images/Day64_config3.png) -Để chúng ta chỉ định máy chủ của mình hoặc các node mà chúng ta muốn tự động hóa với các tác vụ này, chúng ttaôi cần xác định chúng. Chúng ta có thể xác định chúng bằng cách điều hướng đến thư mục /etc/ansible trên hệ thống của bạn. +Để chúng ta chỉ định máy chủ của mình hoặc các node mà chúng ta muốn tự động hóa với các tác vụ này, chúng ta cần xác định chúng. Chúng ta có thể xác định chúng bằng cách điều hướng đến thư mục /etc/ansible trên hệ thống của bạn. ![](../../Days/Images/Day64_config4.png) From 35c3e028840aa51a27e5159f3738428c1b01d9a3 Mon Sep 17 00:00:00 2001 From: Mau Ha Quang Date: Wed, 9 Aug 2023 02:18:46 +0900 Subject: [PATCH 04/15] Update 2022/vi/Days/day64.md Co-authored-by: Henry Vu <26101787+hungran@users.noreply.github.com> --- 2022/vi/Days/day64.md | 1 - 1 file changed, 1 deletion(-) diff --git a/2022/vi/Days/day64.md b/2022/vi/Days/day64.md index 7bd1036..bc8c9a6 100644 --- a/2022/vi/Days/day64.md +++ b/2022/vi/Days/day64.md @@ -72,7 +72,6 @@ Sau đó, chúng ta có các yêu cầu về các nodes, đây là những hệ Bạn đã thấy rằng chúng ta có thể chạy `ansible Linux -m ping` trên máy Linux của chúng ta và nhận được phản hồi, về cơ bản, với Ansible, chúng ta có thể chạy nhiều lệnh đặc biệt. [ad hoc commands](https://docs.ansible.com/ansible/latest/user_guide/intro_adhoc.html) -You saw that we were able to run `ansible Linux -m ping` against our Linux machine and get a response, basically, with Ansible we can run many ad-hoc commands. Nhưng bạn có thể chạy chương trình này với một nhóm hệ thống và lấy lại thông tin đó. [ad hoc commands](https://docs.ansible.com/ansible/latest/user_guide/intro_adhoc.html) Nếu bạn thấy mình lặp lại các lệnh hoặc thậm chí tệ hơn là bạn phải đăng nhập vào các hệ thống riêng lẻ để chạy các lệnh này thì Ansible có thể trợ giúp. Ví dụ: lệnh đơn giản bên dưới sẽ cung cấp cho chúng ta đầu ra của tất cả các chi tiết hệ điều hành cho tất cả các hệ thống mà chúng ta thêm vào nhóm Linux của mình. `ansible linux -a "cat /etc/os-release"` From 6f35f6a89be64139de173a30cec369b8119871d0 Mon Sep 17 00:00:00 2001 From: Quang Mau Date: Wed, 9 Aug 2023 23:40:36 +0900 Subject: [PATCH 05/15] added d66 --- 2022/vi/Days/day66.md | 130 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 2022/vi/Days/day66.md diff --git a/2022/vi/Days/day66.md b/2022/vi/Days/day66.md new file mode 100644 index 0000000..09becee --- /dev/null +++ b/2022/vi/Days/day66.md @@ -0,0 +1,130 @@ +--- +title: '#90DaysOfDevOps - Tiếp tục với Ansible Playbooks... - Ngày 66' +published: false +description: 90DaysOfDevOps - Tiếp tục với Ansible Playbooks... +tags: 'devops, 90daysofdevops, learning' +cover_image: null +canonical_url: null +id: 1048712 +--- + +## Ansible Playbooks (Tiếp tục) + +Trong bài viết trước, chúng ta đã bắt đầu với việc tạo bài lab nhỏ bằng cách sử dụng Vagrantfile để triển khai 4 máy ảo và chúng ta đã sử dụng máy chủ Linux đã được tạo trong bài viết liên quan tới chính chủ đề đó làm hệ thống điều khiển ansible của mình. + +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) + +### Giữ mọi thứ ngăn nắp + +Trước khi bắt đầu triển khai và tiếp tục tự động hoá quy trình, chúng ta sẽ đề cập tới việc giữ các playbooks của mình gọn gàng và ngăn nắp cũng như cách chúng ta có thể tách các tasks và handlers của mình thành các thư mục con. + +Chúng ta sẽ sao chép các nhiệm vụ của mình vào các tệp của chúng trong một thư mục riêng. + +```Yaml +- name: ensure apache is at the latest version + apt: name=apache2 state=latest + +- name: write the apache2 ports.conf config file + template: + src=templates/ports.conf.j2 + dest=/etc/apache2/ports.conf + notify: restart apache + +- name: write a basic index.html file + template: + src: templates/index.html.j2 + dest: /var/www/html/index.html + notify: + - restart apache + +- name: ensure apache is running + service: + name: apache2 + state: started +``` + +và làm điều tương tự với handlers + +```Yaml +- name: restart apache + service: + name: apache2 + state: restarted +``` + +sau đó, trong playbook mà hiện tại có tên là `playbook2.yml`, chúng ta trỏ đến các tệp này. Tất cả đều có thể được tìm thấy tại [ansible-scenario2](../../Days/Configmgmt/ansible-scenario2/) + +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) + +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) + +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ô. + +### Roles và Ansible Galaxy + +Hiện tại, chúng ta đã triển khai 4 máy ảo và chúng ta đã định cấu hình 2 trong số các máy ảo này làm máy chủ web, chúng ta cũng có một số các chứng năng khác, cụ thể là một cơ sở dữ liệu và bộ cân bằng tải hoặc proxy. Để chúng ta có thể làm điều này và dọn dẹp lại repository của mình, chúng ta có thể sử dụng roles trong Ansible. + +Để 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) + +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) + +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) + +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. + +Chúng ta cũng cần thay đổi playbook để có thể sử dụng role mới được tạo. Trong playbook1.yml và playbook2.yml, chúng ta xác định các tasks và handlers theo các cách khác nhau khi chúng ta thay đổi giữa hai phiên bản. Chúng ta cần thay đổi playbook của mình để sử dụng role này như bên dưới: + +```Yaml +- hosts: webservers + become: yes + vars: + http_port: 8000 + https_port: 4443 + html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 66!" + roles: + - apache2 +``` + +![](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. + +![](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. + +![](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) + +Chúng ta cũng sẽ tạo thêm một vài roles trong khi sử dụng `ansible-galaxy`, bao gồm: + +- common = cho tất cả các máy chủ (`ansible-galaxy init roles/common`) +- nginx = cho load balancer (`ansible-galaxy init roles/nginx`) + +![](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 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 67](day67.md) From be03ea3d6de377727abebe070fc2069645133e88 Mon Sep 17 00:00:00 2001 From: Quang Mau Date: Mon, 14 Aug 2023 11:17:37 +0900 Subject: [PATCH 06/15] added day67 vn translation --- 2022/vi/Days/day66.md | 20 +++---- 2022/vi/Days/day67.md | 121 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 131 insertions(+), 10 deletions(-) create mode 100644 2022/vi/Days/day67.md diff --git a/2022/vi/Days/day66.md b/2022/vi/Days/day66.md index 09becee..fcf1261 100644 --- a/2022/vi/Days/day66.md +++ b/2022/vi/Days/day66.md @@ -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. -![](Images/Day66_config1.png) +![](../../Days/Images/Day66_config1.png) ### 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" -![](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` -![](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ô. @@ -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ẻ. -![](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. -![](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. -![](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. @@ -97,15 +97,15 @@ Chúng ta cũng cần thay đổi playbook để có thể sử dụng role mớ - 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. -![](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. -![](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) @@ -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`) - 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ì. diff --git a/2022/vi/Days/day67.md b/2022/vi/Days/day67.md new file mode 100644 index 0000000..400e1f8 --- /dev/null +++ b/2022/vi/Days/day67.md @@ -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) From a6f1666869ce5e4d154f458eb44e1d229feb6ce9 Mon Sep 17 00:00:00 2001 From: Quang Mau Date: Wed, 16 Aug 2023 14:05:17 +0900 Subject: [PATCH 07/15] [content] added d68 --- 2022/vi/Days/day68.md | 342 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 342 insertions(+) create mode 100644 2022/vi/Days/day68.md diff --git a/2022/vi/Days/day68.md b/2022/vi/Days/day68.md new file mode 100644 index 0000000..75ed152 --- /dev/null +++ b/2022/vi/Days/day68.md @@ -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_welcome_msg }}! I'm webserver {{ ansible_facts['nodename'] }}

+ + +``` +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) + From c5d0d79432feb3862b88760ca54d93cd7dd63ffc Mon Sep 17 00:00:00 2001 From: Quang Mau Date: Thu, 17 Aug 2023 10:49:34 +0900 Subject: [PATCH 08/15] added day69 vn translation --- 2022/vi/Days/day69.md | 143 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 143 insertions(+) create mode 100644 2022/vi/Days/day69.md diff --git a/2022/vi/Days/day69.md b/2022/vi/Days/day69.md new file mode 100644 index 0000000..1280dc0 --- /dev/null +++ b/2022/vi/Days/day69.md @@ -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) From a9031d1443430e36f07fc8112202e39d0cc26e8b Mon Sep 17 00:00:00 2001 From: Hieu Quang Date: Tue, 22 Aug 2023 17:41:02 +0700 Subject: [PATCH 09/15] Create day70.md Translation day70 --- 2022/vi/Days/day70.md | 130 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 2022/vi/Days/day70.md diff --git a/2022/vi/Days/day70.md b/2022/vi/Days/day70.md new file mode 100644 index 0000000..5d723da --- /dev/null +++ b/2022/vi/Days/day70.md @@ -0,0 +1,130 @@ +--- +title: '#90DaysOfDevOps - Bức tranh toàn cảnh: CI/CD Pipelines - Ngày 70' +published: false +description: 90DaysOfDevOps - Bức tranh toàn cảnh':' CI/CD Pipelines... +tags: 'devops, 90daysofdevops, learning' +cover_image: null +canonical_url: null +id: 1048712 +--- +## Bức tranh toàn cảnh: CI/CD Pipelines + +Triển khai CI/CD Pipeline (Tích hợp liên tục/Triển khai liên tục) là xương sống của môi trường Devops hiện đại. + +Nó kết nối khoảng cách giữa phát triển và vận hành bằng cách tự động hóa quá trình xây dựng, kiểm thử và triển khai ứng dụng. + +Chúng ta đã đề cập khá nhiều về triết lý liên tục này trong phần mở đầu của chuỗi bài. Nhưng để nhấn mạnh lại: + +Tích hợp Liên tục (CI) là một phương pháp phát triển phần mềm hiện đại hơn, trong đó sự gia tăng về thay đổi mã nguồn được thực hiện thường xuyên và đáng tin cậy hơn. Các bước làm việc xây dựng và kiểm thử tự động được kích hoạt bởi Tích hợp Liên tục đảm bảo rằng những thay đổi mã nguồn được gộp vào kho mã nguồn là đáng tin cậy. + +Mã nguồn/Ứng dụng sau đó được chuyển giao nhanh chóng và một cách trôi chảy như một phần của quá trình Triển khai Liên tục. + +### Tầm quan trọng của CI/CD? + +* Tạo ra phần mềm nhanh chóng và hiệu quả +* Tạo điều kiện cho một quy trình hiệu quả để đưa ứng dụng ra thị trường càng nhanh càng tốt +* Luồng liên tục của việc khắc phục lỗi và tính năng mới mà không cần phải đợi quá trình dài hàng năm tháng cho các phiên bản được phát hành. + +Khả năng cho phép các nhà phát triển thực hiện những thay đổi nhỏ mang tính ảnh hưởng định kỳ nghĩa là chúng ta có thể nhận được các bản vá nhanh chóng hơn và nhiều tính năng hơn một cách nhanh chóng. + +### Vậy điều này có ý nghĩa là gì? + +ở [Ngày 5](day05.md) chúng ta đã đề cập khá nhiều về lý thuyết về đằng sau DevOps và như đã được đề cập ở đây rằng CI/CD Pipelines là nền móng của môi trường DevOps hiện đại. + +![](Images/Day5_DevOps8.png) + +Tôi muốn nhấn mạnh một số điểm mấu chốt ở hình ảnh trên, bây giờ chúng ta đã tiến xa hơn một chút trong hành trình học DevOps cơ bản của chúng ta. + +Chúng ta đang đề cập đến vòng đời phát triển phần mềm (software development life cycle - SDLC). + +Các bước thường được viết ra bên trong các vòng lặp vô tận vì nó là một chu kỳ lặp lại mãi mãi. + +Các bước trong chu kỳ là việc các nhà phát triển viết mã nguồn sau đó được xây dựng hoặc biên dịch, sau đó được **kiểm thử** để tìm lỗi và **triển khai** vào môi trường sản phẩm nơi mà nó được sử dụng (**Operated - Vận hành** ) bởi người dùng cuối hoặc khách hàng sau đó chúng ta **theo giõi** và thu thập phản hồi và cuối cùng **lên kế hoạch** cải tiến xung quanh phản hồi đó và **lặp lại**. + +### Cùng đi sâu hơn một chút vào CI/CD + +### CI + +CI là một phương pháp phát triển yêu cầu nhà phát triển tích hợp mã nguồn vào kho mã nguồn nhiều lần trong một ngày. + +Khi mã nguồn được viết và đẩy lên một kho lưu trữ như Github hoặc GitLab, đó là nơi bắt đầu phép màu. + +![](Images/Day70_CICD1.png) + +Mã nguồn được xác minh bằng quá trình xây dựng tự động, cho phép các nhóm hoặc chủ dự án phát hiện sớm bất kỳ vấn đề nào. + +![](Images/Day70_CICD2.png) + +Từ đó, mã nguồn được phân tích và chạy qua một loạt các bài kiểm tra tự động, với ba ví dụ sau đây: + +* Kiểm thử đơn vị (Unit testing) kiểm tra từng đơn vị riêng biệt của mã nguồn. +* Kiểm thử xác thực (Validation testing) đảm bảo rằng phần mềm đáp ứng hoặc phù hợp với việc mục đích sử dụng. +* Kiểm thử định dạng (Format testing) kiểm tra lỗi cú pháp và định dạng khác. + +Các bài kiểm tra này được tạo thành một quy trình làm việc và sau đó chúng được chạy mỗi khi bạn đẩy mã lên nhánh chính (master branch), vì vậy hầu như mọi đội phát triển lớn đều có một quy trình làm việc CI/CD và hãy nhớ rằng trong một đội phát triển, mã nguồn mới có thể đến từ các đội khắp nơi trên thế giới vào các thời điểm khác nhau trong ngày từ các nhà phát triển làm việc trên nhiều dự án khác nhau. Xây dựng một quy trình làm việc tự động kiểm tra đảm bảo mọi người đều hoạt động theo cùng một tiêu chuẩn trước khi mã được chấp nhận, điều này hiệu quả hơn so với việc con người thực hiện điều này mỗi lần. + +![](Images/Day70_CICD3.png) + +Khi chúng ta đã hoàn thành các bài kiểm thử và thành công, chúng ta có thể biên dịch và gửi chúng đến kho mã nguồn. Ví dụ, tôi đang sử dụng Docker Hub hoặc có thể bất cứ kho lưu trữ nào khác và sau đó sẽ được tận dụng cho khía cạnh triển khai liên tục (CD) của pipeline. + +![](Images/Day70_CICD4.png) + +Vì vậy, quá trình này chủ yếu liên quan đến quá trình phát triển phần mềm. Chúng ta đang tạo ứng dụng, thêm, sửa lỗi và sau đó cập nhật quản lý mã nguồn và phiên bản cùng với việc kiểm thử. + +Chuyển sang giai đoạn tiếp theo là yếu tố triển khai liên tục (CD), mà ngày càng nhiều chúng ta thường thấy trong bất kỳ phần mềm nào có sẵn trên thị trường. Tôi sẽ cho rằng chúng ta sẽ thấy một xu hướng, nếu chúng ta nhận phần mềm từ một nhà cung cấp như Oracle hoặc Microsoft, chúng ta sẽ tiêu thụ chúng từ một kho lưu trữ kiểu Docker Hub, sau đó chúng ta sẽ sử dụng đường ống triển khai liên tục của mình để triển khai chúng vào môi trường của chúng ta. + +### CD + +Bây giờ chúng ta đã có phiên bản mã nguồn đã được kiểm thử và chúng ta sẵn sàng triển khai ra ngoài như tôi nói, nhà cung cấp phần mềm sẽ trải qua giai đoạn này, nhưng tôi rất tin rằng đây là cách chúng ta sẽ triển khai tất cả phần mềm có sẵn mà chúng ta cần trong tương lai. + +Bây giờ là lúc phát hành mã nguồn vào môi trường. Điều này sẽ bao gồm Môi trường Sản phẩm (Production) nhưng cũng có thể bao gồm các môi trường khác như Môi trường Staging. + +![](Images/Day70_CICD5.png) + +Bước tiếp theo của chúng ta, ít nhất là trong Ngày 1 của phiên bản 1 của việc triển khai phần mềm, là chúng ta cần đảm bảo rằng chúng ta đang kéo mã nguồn đúng đến môi trường đúng. Điều này có thể bao gồm việc rút các thành phần từ kho lưu trữ phần mềm (DockerHub), nhưng có khả năng chúng ta cũng đang rút cấu hình bổ sung từ một kho lưu trữ mã nguồn khác, chẳng hạn cấu hình cho ứng dụng. Trong biểu đồ dưới đây, chúng ta đang rút phiên bản phần mềm mới nhất từ DockerHub, sau đó chúng ta đang triển khai nó vào môi trường của chúng ta, có thể sẽ kèm theo việc lấy cấu hình từ một kho lưu trữ Git. Công cụ CD của chúng ta đang thực hiện việc này và đẩy mọi thứ vào môi trường của chúng ta. + +Rất có thể việc này không được thực hiện cùng lúc. Ví dụ, chúng ta có thể đi vào một môi trường Staging và chạy kiểm tra với cấu hình của chúng ta để đảm bảo mọi thứ đúng đắn, và đây có thể là bước kiểm tra thủ công hoặc có thể lại được thực hiện tự động (hãy chọn việc tự động). Sau đó chúng ta cho phép mã nguồn này được triển khai vào môi trường Sản phẩm. + +![](Images/Day70_CICD6.png) + +Sau đó, khi phiên bản 2 của ứng dụng ra mắt, chúng ta lặp lại các bước này. Lần này, chúng ta đảm bảo rằng ứng dụng cùng cấu hình của chúng ta được triển khai vào môi trường Staging, đảm bảo mọi thứ ổn định, sau đó chúng ta triển khai vào môi trường Sản phẩm. + +### Tại sao sử dụng CI/CD? + +Tôi nghĩ chúng ta có thể đã bàn về những lợi ích này nhiều lần, nhưng đó là vì nó tự động hóa những thứ mà ban đầu phải được thực hiện thủ công. Nó tìm ra các vấn đề nhỏ trước khi chúng xâm nhập vào mã nguồn chính, bạn có thể tưởng tượng rằng nếu bạn đẩy mã nguồn không tốt ra cho khách hàng của bạn, thì bạn sẽ có một khoảng thời gian khó khăn! + +Nó cũng giúp ngăn chặn điều gọi là "nợ kỹ thuật" (technical debt), đó là ý tưởng rằng vì kho mã nguồn chính liên tục được xây dựng theo thời gian sau đó một sửa lỗi tạm thời được thực hiện vào ngày đầu bây giờ trở thành một sửa lỗi đắt đỏ hơn theo thời gian vì bây giờ sửa lỗi đó đã được gắn chặt chẽ và được tích hợp vào tất cả các mã nguồn và logic. + +### Công cụ + +Tương tự như các phần khác, chúng ta sẽ thực hành với một số công cụ để thực hiện quá trình CI/CD Pipeline. + +Tôi nghĩ nó cũng quan trọng để lưu ý rằng không phải tất cả các công cụ đều phải thực hiện cả quá trình CI và CD. Chúng ta sẽ xem xét ArgoCD, như bạn đã đoán, nó tốt ở yếu tố CD trong việc triển khai phần mềm của chúng ta lên một cụm Kubernetes. Nhưng một công cụ như Jenkins có thể làm việc trên nhiều nền tảng khác nhau. + +Tôi có kế hoạch xem xét các công cụ sau đây: + +* Jenkins +* ArgoCD +* GitHub Actions + +## Tài liệu tham khảo + +- [Jenkins là một cách để xây dựng, kiểm thử, triển khai](https://www.youtube.com/watch?v=_MXtbjwsz3A) + +- [Giới thiệu về Jenkins](https://www.edx.org/learn/computer-science/the-linux-foundation-introduction-to-jenkins) + +- [Jenkins.io](https://www.jenkins.io) + +- [ArgoCD](https://argo-cd.readthedocs.io/en/stable/) + +- [Hướng dẫn ArgoCD cho người mới bắt đầu](https://www.youtube.com/watch?v=MeU5_k9ssrs) + +- [Jenkins là gì](https://www.youtube.com/watch?v=LFDrDnKPOTg) + +- [Hướng dẫn Jenkins đầy đủ](https://www.youtube.com/watch?v=nCKxl7Q_20I&t=3s) + +- [GitHub Actions](https://www.youtube.com/watch?v=R8_veQiYBjI) + +- [GitHub Actions CI/CD](https://www.youtube.com/watch?v=mFFXuXjVgkU) + +Gặp bạn vào [Ngày 71](day71.md) From 7f870fad8184d0f13ee894650d416347015d1e4d Mon Sep 17 00:00:00 2001 From: Hieu Quang Date: Tue, 22 Aug 2023 18:43:06 +0700 Subject: [PATCH 10/15] Fix path of image Fix path of image --- 2022/vi/Days/day70.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/2022/vi/Days/day70.md b/2022/vi/Days/day70.md index 5d723da..4329152 100644 --- a/2022/vi/Days/day70.md +++ b/2022/vi/Days/day70.md @@ -31,7 +31,7 @@ Khả năng cho phép các nhà phát triển thực hiện những thay đổi ở [Ngày 5](day05.md) chúng ta đã đề cập khá nhiều về lý thuyết về đằng sau DevOps và như đã được đề cập ở đây rằng CI/CD Pipelines là nền móng của môi trường DevOps hiện đại. -![](Images/Day5_DevOps8.png) +![](../../Days/Images/Day5_DevOps8.png) Tôi muốn nhấn mạnh một số điểm mấu chốt ở hình ảnh trên, bây giờ chúng ta đã tiến xa hơn một chút trong hành trình học DevOps cơ bản của chúng ta. @@ -49,11 +49,11 @@ CI là một phương pháp phát triển yêu cầu nhà phát triển tích h Khi mã nguồn được viết và đẩy lên một kho lưu trữ như Github hoặc GitLab, đó là nơi bắt đầu phép màu. -![](Images/Day70_CICD1.png) +![](../../Days/Images/Day70_CICD1.png) Mã nguồn được xác minh bằng quá trình xây dựng tự động, cho phép các nhóm hoặc chủ dự án phát hiện sớm bất kỳ vấn đề nào. -![](Images/Day70_CICD2.png) +![](../../Days/Images/Day70_CICD2.png) Từ đó, mã nguồn được phân tích và chạy qua một loạt các bài kiểm tra tự động, với ba ví dụ sau đây: @@ -63,11 +63,11 @@ Từ đó, mã nguồn được phân tích và chạy qua một loạt các bà Các bài kiểm tra này được tạo thành một quy trình làm việc và sau đó chúng được chạy mỗi khi bạn đẩy mã lên nhánh chính (master branch), vì vậy hầu như mọi đội phát triển lớn đều có một quy trình làm việc CI/CD và hãy nhớ rằng trong một đội phát triển, mã nguồn mới có thể đến từ các đội khắp nơi trên thế giới vào các thời điểm khác nhau trong ngày từ các nhà phát triển làm việc trên nhiều dự án khác nhau. Xây dựng một quy trình làm việc tự động kiểm tra đảm bảo mọi người đều hoạt động theo cùng một tiêu chuẩn trước khi mã được chấp nhận, điều này hiệu quả hơn so với việc con người thực hiện điều này mỗi lần. -![](Images/Day70_CICD3.png) +![](../../Days/Images/Day70_CICD3.png) Khi chúng ta đã hoàn thành các bài kiểm thử và thành công, chúng ta có thể biên dịch và gửi chúng đến kho mã nguồn. Ví dụ, tôi đang sử dụng Docker Hub hoặc có thể bất cứ kho lưu trữ nào khác và sau đó sẽ được tận dụng cho khía cạnh triển khai liên tục (CD) của pipeline. -![](Images/Day70_CICD4.png) +![](../../Days/Images/Day70_CICD4.png) Vì vậy, quá trình này chủ yếu liên quan đến quá trình phát triển phần mềm. Chúng ta đang tạo ứng dụng, thêm, sửa lỗi và sau đó cập nhật quản lý mã nguồn và phiên bản cùng với việc kiểm thử. @@ -79,13 +79,13 @@ Bây giờ chúng ta đã có phiên bản mã nguồn đã được kiểm th Bây giờ là lúc phát hành mã nguồn vào môi trường. Điều này sẽ bao gồm Môi trường Sản phẩm (Production) nhưng cũng có thể bao gồm các môi trường khác như Môi trường Staging. -![](Images/Day70_CICD5.png) +![](../../Days/Images/Day70_CICD5.png) Bước tiếp theo của chúng ta, ít nhất là trong Ngày 1 của phiên bản 1 của việc triển khai phần mềm, là chúng ta cần đảm bảo rằng chúng ta đang kéo mã nguồn đúng đến môi trường đúng. Điều này có thể bao gồm việc rút các thành phần từ kho lưu trữ phần mềm (DockerHub), nhưng có khả năng chúng ta cũng đang rút cấu hình bổ sung từ một kho lưu trữ mã nguồn khác, chẳng hạn cấu hình cho ứng dụng. Trong biểu đồ dưới đây, chúng ta đang rút phiên bản phần mềm mới nhất từ DockerHub, sau đó chúng ta đang triển khai nó vào môi trường của chúng ta, có thể sẽ kèm theo việc lấy cấu hình từ một kho lưu trữ Git. Công cụ CD của chúng ta đang thực hiện việc này và đẩy mọi thứ vào môi trường của chúng ta. Rất có thể việc này không được thực hiện cùng lúc. Ví dụ, chúng ta có thể đi vào một môi trường Staging và chạy kiểm tra với cấu hình của chúng ta để đảm bảo mọi thứ đúng đắn, và đây có thể là bước kiểm tra thủ công hoặc có thể lại được thực hiện tự động (hãy chọn việc tự động). Sau đó chúng ta cho phép mã nguồn này được triển khai vào môi trường Sản phẩm. -![](Images/Day70_CICD6.png) +![](../../Days/Images/Day70_CICD6.png) Sau đó, khi phiên bản 2 của ứng dụng ra mắt, chúng ta lặp lại các bước này. Lần này, chúng ta đảm bảo rằng ứng dụng cùng cấu hình của chúng ta được triển khai vào môi trường Staging, đảm bảo mọi thứ ổn định, sau đó chúng ta triển khai vào môi trường Sản phẩm. From 13f015efded6531733d0f7ea4cbcbc25ff216286 Mon Sep 17 00:00:00 2001 From: Hieu Quang <109328227+HieuChayA4@users.noreply.github.com> Date: Fri, 25 Aug 2023 08:40:11 +0700 Subject: [PATCH 11/15] Update 2022/vi/Days/day70.md Co-authored-by: Mau Ha Quang --- 2022/vi/Days/day70.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2022/vi/Days/day70.md b/2022/vi/Days/day70.md index 4329152..e2f4679 100644 --- a/2022/vi/Days/day70.md +++ b/2022/vi/Days/day70.md @@ -11,7 +11,7 @@ id: 1048712 Triển khai CI/CD Pipeline (Tích hợp liên tục/Triển khai liên tục) là xương sống của môi trường Devops hiện đại. -Nó kết nối khoảng cách giữa phát triển và vận hành bằng cách tự động hóa quá trình xây dựng, kiểm thử và triển khai ứng dụng. +Nó rút ngắn khoảng cách giữa phát triển và vận hành bằng cách tự động hóa quá trình xây dựng, kiểm thử và triển khai ứng dụng. Chúng ta đã đề cập khá nhiều về triết lý liên tục này trong phần mở đầu của chuỗi bài. Nhưng để nhấn mạnh lại: From c920f5183b8d20015a81e9a6f4b0a62b8d27382d Mon Sep 17 00:00:00 2001 From: Hieu Quang Date: Fri, 25 Aug 2023 08:47:32 +0700 Subject: [PATCH 12/15] Fix typo Fix typo --- 2022/vi/Days/day70.md | 37 ++++++++++++++++++------------------- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/2022/vi/Days/day70.md b/2022/vi/Days/day70.md index 4329152..c5c80ee 100644 --- a/2022/vi/Days/day70.md +++ b/2022/vi/Days/day70.md @@ -11,41 +11,41 @@ id: 1048712 Triển khai CI/CD Pipeline (Tích hợp liên tục/Triển khai liên tục) là xương sống của môi trường Devops hiện đại. -Nó kết nối khoảng cách giữa phát triển và vận hành bằng cách tự động hóa quá trình xây dựng, kiểm thử và triển khai ứng dụng. +Nó rút ngắn khoảng cách giữa phát triển và vận hành bằng cách tự động hóa quá trình xây dựng, kiểm thử và triển khai ứng dụng. Chúng ta đã đề cập khá nhiều về triết lý liên tục này trong phần mở đầu của chuỗi bài. Nhưng để nhấn mạnh lại: -Tích hợp Liên tục (CI) là một phương pháp phát triển phần mềm hiện đại hơn, trong đó sự gia tăng về thay đổi mã nguồn được thực hiện thường xuyên và đáng tin cậy hơn. Các bước làm việc xây dựng và kiểm thử tự động được kích hoạt bởi Tích hợp Liên tục đảm bảo rằng những thay đổi mã nguồn được gộp vào kho mã nguồn là đáng tin cậy. +Tích hợp Liên tục (CI) là một phương pháp phát triển phần mềm hiện đại, trong đó thay đổi mã nguồn được thực hiện thường xuyên và đáng tin cậy hơn. Các bước xây dựng và kiểm thử tự động được kích hoạt bởi Tích hợp Liên tục đảm bảo tính tin cậy của những thay đổi mã nguồn được gộp vào kho mã nguồn. -Mã nguồn/Ứng dụng sau đó được chuyển giao nhanh chóng và một cách trôi chảy như một phần của quá trình Triển khai Liên tục. +Mã nguồn/Ứng dụng sau đó được triển khai một cách nhanh chóng và liền mạch như một phần của quá trình Triển khai Liên tục. ### Tầm quan trọng của CI/CD? -* Tạo ra phần mềm nhanh chóng và hiệu quả -* Tạo điều kiện cho một quy trình hiệu quả để đưa ứng dụng ra thị trường càng nhanh càng tốt -* Luồng liên tục của việc khắc phục lỗi và tính năng mới mà không cần phải đợi quá trình dài hàng năm tháng cho các phiên bản được phát hành. +* Tạo ra phần mềm nhanh chóng và hiệu quả. +* Tạo ra một quy trình hiệu quả để đưa ứng dụng ra thị trường nhanh nhất có thể. +* Triển khai các bản sửa lỗi và tính năng mới liên tục mà không cần phải chờ hàng tháng hoặc hàng năm để phát hành phiên bản mới. Khả năng cho phép các nhà phát triển thực hiện những thay đổi nhỏ mang tính ảnh hưởng định kỳ nghĩa là chúng ta có thể nhận được các bản vá nhanh chóng hơn và nhiều tính năng hơn một cách nhanh chóng. ### Vậy điều này có ý nghĩa là gì? -ở [Ngày 5](day05.md) chúng ta đã đề cập khá nhiều về lý thuyết về đằng sau DevOps và như đã được đề cập ở đây rằng CI/CD Pipelines là nền móng của môi trường DevOps hiện đại. +ở [Ngày 5](day05.md) chúng ta đã đề cập khá nhiều tới lý thuyết về DevOps và như đã được đề cập trong bài viết này, CI/CD Pipelines là nền móng của môi trường DevOps hiện đại. ![](../../Days/Images/Day5_DevOps8.png) -Tôi muốn nhấn mạnh một số điểm mấu chốt ở hình ảnh trên, bây giờ chúng ta đã tiến xa hơn một chút trong hành trình học DevOps cơ bản của chúng ta. +Tôi muốn nhấn mạnh một số điểm mấu chốt ở hình trên, bây giờ chúng ta đã tiến xa hơn một chút trong hành trình học DevOps cơ bản. Chúng ta đang đề cập đến vòng đời phát triển phần mềm (software development life cycle - SDLC). Các bước thường được viết ra bên trong các vòng lặp vô tận vì nó là một chu kỳ lặp lại mãi mãi. -Các bước trong chu kỳ là việc các nhà phát triển viết mã nguồn sau đó được xây dựng hoặc biên dịch, sau đó được **kiểm thử** để tìm lỗi và **triển khai** vào môi trường sản phẩm nơi mà nó được sử dụng (**Operated - Vận hành** ) bởi người dùng cuối hoặc khách hàng sau đó chúng ta **theo giõi** và thu thập phản hồi và cuối cùng **lên kế hoạch** cải tiến xung quanh phản hồi đó và **lặp lại**. +Các bước trong quy trình là việc các nhà phát triển viết mã nguồn sau đó được xây dựng hoặc biên dịch, sau đó được **kiểm thử** để tìm lỗi và **triển khai** vào môi trường sản phẩm nơi mà nó được sử dụng (**Operated - Vận hành** ) bởi người dùng cuối hoặc khách hàng sau đó chúng ta **theo dõi**, thu thập phản hồi và cuối cùng **lên kế hoạch** cải tiến xung quanh phản hồi đó, sau cùng là **lặp lại** toàn bộ quy trình. -### Cùng đi sâu hơn một chút vào CI/CD +### Tìm hiểu sâu hơn về CI/CD ### CI -CI là một phương pháp phát triển yêu cầu nhà phát triển tích hợp mã nguồn vào kho mã nguồn nhiều lần trong một ngày. +CI là một thực hành trong quy trình phát triển yêu cầu nhà phát triển tích hợp mã nguồn vào kho mã nguồn nhiều lần trong một ngày. Khi mã nguồn được viết và đẩy lên một kho lưu trữ như Github hoặc GitLab, đó là nơi bắt đầu phép màu. @@ -71,17 +71,16 @@ Khi chúng ta đã hoàn thành các bài kiểm thử và thành công, chúng Vì vậy, quá trình này chủ yếu liên quan đến quá trình phát triển phần mềm. Chúng ta đang tạo ứng dụng, thêm, sửa lỗi và sau đó cập nhật quản lý mã nguồn và phiên bản cùng với việc kiểm thử. -Chuyển sang giai đoạn tiếp theo là yếu tố triển khai liên tục (CD), mà ngày càng nhiều chúng ta thường thấy trong bất kỳ phần mềm nào có sẵn trên thị trường. Tôi sẽ cho rằng chúng ta sẽ thấy một xu hướng, nếu chúng ta nhận phần mềm từ một nhà cung cấp như Oracle hoặc Microsoft, chúng ta sẽ tiêu thụ chúng từ một kho lưu trữ kiểu Docker Hub, sau đó chúng ta sẽ sử dụng đường ống triển khai liên tục của mình để triển khai chúng vào môi trường của chúng ta. - +Chuyển sang giai đoạn tiếp theo là yếu tố triển khai liên tục (CD), mà ngày càng nhiều chúng ta thường thấy trong bất kỳ phần mềm nào có sẵn trên thị trường. Chúng ta sẽ thấy một xu hướng, nếu chúng ta nhận phần mềm từ một nhà cung cấp như Oracle hoặc Microsoft, chúng ta sẽ sử dụng chúng từ một kho lưu trữ kiểu Docker Hub, sau đó sẽ sử dụng đường ống (pipeline) triển khai liên tục của mình để triển khai các phầm mềm đó lên môi trường của chúng ta. ### CD -Bây giờ chúng ta đã có phiên bản mã nguồn đã được kiểm thử và chúng ta sẵn sàng triển khai ra ngoài như tôi nói, nhà cung cấp phần mềm sẽ trải qua giai đoạn này, nhưng tôi rất tin rằng đây là cách chúng ta sẽ triển khai tất cả phần mềm có sẵn mà chúng ta cần trong tương lai. +Bây giờ chúng ta đã có phiên bản mã nguồn đã được kiểm thử và sẵn sàng để được triển khai, nhà cung cấp phần mềm sẽ trải qua giai đoạn này, nhưng tôi rất tin rằng đây là cách chúng ta sẽ triển khai tất cả phần mềm có sẵn mà chúng ta cần trong tương lai. Bây giờ là lúc phát hành mã nguồn vào môi trường. Điều này sẽ bao gồm Môi trường Sản phẩm (Production) nhưng cũng có thể bao gồm các môi trường khác như Môi trường Staging. ![](../../Days/Images/Day70_CICD5.png) -Bước tiếp theo của chúng ta, ít nhất là trong Ngày 1 của phiên bản 1 của việc triển khai phần mềm, là chúng ta cần đảm bảo rằng chúng ta đang kéo mã nguồn đúng đến môi trường đúng. Điều này có thể bao gồm việc rút các thành phần từ kho lưu trữ phần mềm (DockerHub), nhưng có khả năng chúng ta cũng đang rút cấu hình bổ sung từ một kho lưu trữ mã nguồn khác, chẳng hạn cấu hình cho ứng dụng. Trong biểu đồ dưới đây, chúng ta đang rút phiên bản phần mềm mới nhất từ DockerHub, sau đó chúng ta đang triển khai nó vào môi trường của chúng ta, có thể sẽ kèm theo việc lấy cấu hình từ một kho lưu trữ Git. Công cụ CD của chúng ta đang thực hiện việc này và đẩy mọi thứ vào môi trường của chúng ta. +Trong bước tiếp theo, ít nhất là trong Ngày 1 của phiên bản 1 của việc triển khai phần mềm, chúng ta cần đảm bảo việc sử dụng đúng mã nguồn cho môi trường tương ứng. Điều này có thể bao gồm việc kéo từ kho lưu trữ phần mềm (DockerHub), nhưng có khả năng chúng ta cũng sẽ kéo (pull) cấu hình bổ sung từ một kho lưu trữ mã nguồn khác, chẳng hạn cấu hình cho ứng dụng. Trong biểu đồ dưới đây, chúng ta đang kéo phiên bản phần mềm mới nhất từ DockerHub, sau đó chúng ta triển khai nó vào môi trường của mình, có thể sẽ kèm theo việc lấy cấu hình từ một kho lưu trữ Git. Công cụ CD của chúng ta đang thực hiện việc này và đẩy mọi thứ vào môi trường của chúng ta. Rất có thể việc này không được thực hiện cùng lúc. Ví dụ, chúng ta có thể đi vào một môi trường Staging và chạy kiểm tra với cấu hình của chúng ta để đảm bảo mọi thứ đúng đắn, và đây có thể là bước kiểm tra thủ công hoặc có thể lại được thực hiện tự động (hãy chọn việc tự động). Sau đó chúng ta cho phép mã nguồn này được triển khai vào môi trường Sản phẩm. @@ -91,15 +90,15 @@ Sau đó, khi phiên bản 2 của ứng dụng ra mắt, chúng ta lặp lại ### Tại sao sử dụng CI/CD? -Tôi nghĩ chúng ta có thể đã bàn về những lợi ích này nhiều lần, nhưng đó là vì nó tự động hóa những thứ mà ban đầu phải được thực hiện thủ công. Nó tìm ra các vấn đề nhỏ trước khi chúng xâm nhập vào mã nguồn chính, bạn có thể tưởng tượng rằng nếu bạn đẩy mã nguồn không tốt ra cho khách hàng của bạn, thì bạn sẽ có một khoảng thời gian khó khăn! +Tôi nghĩ chúng ta có thể đã bàn về những điều này nhiều lần, đó là vì nó tự động hóa những thứ mà ban đầu phải được thực hiện thủ công. Nó tìm ra các vấn đề nhỏ trước khi chúng ảnh hưởng vào mã nguồn chính, bạn có thể tưởng tượng rằng nếu bạn sử dụng mã nguồn không tốt cho khách hàng của bạn, bạn sẽ có một khoảng thời gian khó khăn! -Nó cũng giúp ngăn chặn điều gọi là "nợ kỹ thuật" (technical debt), đó là ý tưởng rằng vì kho mã nguồn chính liên tục được xây dựng theo thời gian sau đó một sửa lỗi tạm thời được thực hiện vào ngày đầu bây giờ trở thành một sửa lỗi đắt đỏ hơn theo thời gian vì bây giờ sửa lỗi đó đã được gắn chặt chẽ và được tích hợp vào tất cả các mã nguồn và logic. +Nó cũng giúp ngăn chặn "nợ kỹ thuật" (technical debt), vì kho mã nguồn chính liên tục được xây dựng theo thời gian sau đó một chỉnh sửa lỗi tạm thời được thực hiện vào ngày đầu tiên sẽ trở thành một chỉnh sửa lỗi đắt đỏ hơn theo thời gian, vì bây giờ chỉnh sửa đó đã được gắn chặt chẽ và được tích hợp vào tất cả các mã nguồn và logic. ### Công cụ Tương tự như các phần khác, chúng ta sẽ thực hành với một số công cụ để thực hiện quá trình CI/CD Pipeline. -Tôi nghĩ nó cũng quan trọng để lưu ý rằng không phải tất cả các công cụ đều phải thực hiện cả quá trình CI và CD. Chúng ta sẽ xem xét ArgoCD, như bạn đã đoán, nó tốt ở yếu tố CD trong việc triển khai phần mềm của chúng ta lên một cụm Kubernetes. Nhưng một công cụ như Jenkins có thể làm việc trên nhiều nền tảng khác nhau. +Tôi nghĩ quan trọng là chúng ta cần lưu ý rằng không phải tất cả các công cụ đều phải thực hiện cả quá trình CI và CD. Chúng ta sẽ xem xét ArgoCD, như bạn có thể đoán được, nó tốt ở với CD trong việc triển khai phần mềm của chúng ta lên một cụm Kubernetes. Nhưng một công cụ như Jenkins có thể làm việc trên nhiều nền tảng khác nhau. Tôi có kế hoạch xem xét các công cụ sau đây: @@ -127,4 +126,4 @@ Tôi có kế hoạch xem xét các công cụ sau đây: - [GitHub Actions CI/CD](https://www.youtube.com/watch?v=mFFXuXjVgkU) -Gặp bạn vào [Ngày 71](day71.md) +Hẹn gặp lại bạn vào [Ngày 71](day71.md) From 639200fdf66b54bd66d4b2e45e77697bf1964fa1 Mon Sep 17 00:00:00 2001 From: Hieu Quang <109328227+HieuChayA4@users.noreply.github.com> Date: Fri, 25 Aug 2023 09:09:57 +0700 Subject: [PATCH 13/15] fix typo fix typo --- 2022/vi/Days/day70.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2022/vi/Days/day70.md b/2022/vi/Days/day70.md index c5c80ee..2ea9e8f 100644 --- a/2022/vi/Days/day70.md +++ b/2022/vi/Days/day70.md @@ -126,4 +126,4 @@ Tôi có kế hoạch xem xét các công cụ sau đây: - [GitHub Actions CI/CD](https://www.youtube.com/watch?v=mFFXuXjVgkU) -Hẹn gặp lại bạn vào [Ngày 71](day71.md) +Hẹn gặp lại vào [Ngày 71](day71.md) From 1651c0d5b5d7e3c19ab2a649dabaf093c80fb749 Mon Sep 17 00:00:00 2001 From: Hieu Quang Date: Fri, 25 Aug 2023 09:24:28 +0700 Subject: [PATCH 14/15] Update id Update id --- 2022/vi/Days/day70.md | 2 +- 2022/vi/Days/day71.md | 0 2 files changed, 1 insertion(+), 1 deletion(-) create mode 100644 2022/vi/Days/day71.md diff --git a/2022/vi/Days/day70.md b/2022/vi/Days/day70.md index c5c80ee..5e631cd 100644 --- a/2022/vi/Days/day70.md +++ b/2022/vi/Days/day70.md @@ -5,7 +5,7 @@ description: 90DaysOfDevOps - Bức tranh toàn cảnh':' CI/CD Pipelines... tags: 'devops, 90daysofdevops, learning' cover_image: null canonical_url: null -id: 1048712 +id: 1048836 --- ## Bức tranh toàn cảnh: CI/CD Pipelines diff --git a/2022/vi/Days/day71.md b/2022/vi/Days/day71.md new file mode 100644 index 0000000..e69de29 From 54ea449976d3af148f194674a4cc8e4de9174cca Mon Sep 17 00:00:00 2001 From: Hieu Quang <109328227+HieuChayA4@users.noreply.github.com> Date: Fri, 25 Aug 2023 09:46:51 +0700 Subject: [PATCH 15/15] Delete day71.md delete day71.md for next PR --- 2022/vi/Days/day71.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 2022/vi/Days/day71.md diff --git a/2022/vi/Days/day71.md b/2022/vi/Days/day71.md deleted file mode 100644 index e69de29..0000000