Ngày 9: Tự động hóa quản lý cấu hình (configuration management)

Sử dụng Role & Triển khai Loadbalancer

Chúng ta đã đề cập tới roles và sử dụng câu lệnh ansible-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 đã sắp xếp lại thư mục mã cấu hình gọn gàng hơn 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ác 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.

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

- 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

- 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

Để 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 tệp để cài đặt và một tệp để đị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 để 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 nginx 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

Bây giờ chúng ta đã cấu hình xong webservers và loadbalancer và có thể truy cập http://192.168.169.134/. Đây là địa chỉ IP của máy chủ cân bằng tải (load balancer) của chúng ta.

Nếu bạn đang làm theo và không truy cập được như trên, rất có thể là do địa chỉ IP của máy chủ đang không tồn tại. Bạn hãy kiểm tra filetemplates\mysite.j2, file này 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.

    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

Tags, Variables, Inventory & Database Server config

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.

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

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.

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

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

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

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

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

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.

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.

- 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

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

- 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

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

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

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:

[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

Sửa lỗi ở trên và chạy lại playbook thành công.

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;

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.

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

Xem thêm: Tổng quan về CI/CD pipelines

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.

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

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.

Xem thêm: Học một ngôn ngữ lập trình (Go)

Triển khai Ansible AWX

AWX không cần phải triển khai trên một Kubernetes cluster, github 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.

Bạn có thể xem tài liệu chính thức của 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:t

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

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

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

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.

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.

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.

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

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

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.

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

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

“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 – Dự án được thiết kế để hỗ trợ việc phát triển và kiểm thử Ansible roles
Ansible Lint – Công cụ CLI cho việc linting playbooks, roles và collections

Các tài nguyên khác

Ansible Documentation

Tài liệu tham khảo

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 trong Lộ trình học DevOps trong 12 ngày của chúng ta, 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 10: Tổng quan về CI/CD pipelines

Các bài viết là bản tiếng Việt của tài liệu 90DaysOfDevOps của Micheal Cade và có qua sửa đổi, bổ sung. Tất cả đều có license [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License][cc-by-nc-sa]

Mọi thắc mắc xin hãy liên hệ
Email: [email protected]

(Nguồn: vntechies.dev)

Previous page 1 2