Ansible

Các Best Practices trong Ansible

Ansible là một công cụ và nền tảng tự động hóa nguồn mở quan trọng. Nó được sử dụng để quản lý cấu hình, triển khai ứng dụng, tự động hóa tác vụ và điều phối các quy trình làm việc phức tạp.

Ansible đóng vai trò nổi bật trong DevOps. Nó cho phép các nhà quản trị và nhà phát triển Công nghệ thông tin (IT) tự động hóa các tác vụ lặp đi lặp lại và hợp lý hóa việc quản lý và triển khai cơ sở hạ tầng, ứng dụng và dịch vụ. Các tính năng kinh doanh và chiến lược của Ansible bao gồm:

  • Kiến trúc không cần tác nhân : Không yêu cầu cài đặt tác nhân.
  • Tính bất biến : Mang lại kết quả an toàn và đáng tin cậy từ các thành phần không đáng tin cậy.
  • Tính di động : Hoạt động nhất quán trên nhiều hệ điều hành khác nhau và trong nhiều môi trường đám mây khác nhau.

Các trung tâm dữ liệu thực sự cần Ansible hoặc một trong những đối thủ cạnh tranh của nó. Các doanh nghiệp hoạt động ở quy mô trung tâm dữ liệu có các yêu cầu về độ tin cậy, tính kinh tế, khả năng mở rộng và tính linh hoạt. Đây chính xác là những lợi thế của Ansible. Nó giúp các hoạt động của trung tâm dữ liệu tiết kiệm chi phí hơn, có thể dự đoán, phục hồi và phản hồi nhanh hơn.

Cơ bản về Ansible

Sau đây là danh sách các thuật ngữ chính bao gồm các thành phần và khái niệm cơ bản liên quan đến Ansible :

  • Target State : Ansible là một ngôn ngữ khai báo . Nó nêu chi tiết các trạng thái mục tiêu cho các hệ thống máy tính và cách đạt được các trạng thái đó. Sau đó, nó chịu trách nhiệm đạt được các trạng thái mục tiêu. Điều này tạo ra một loại làm việc nhóm giữa người dùng và Ansible, trong đó người dùng dẫn đầu trong việc nói những gì họ muốn và Ansible sẽ đưa ra chi tiết về cách thực hiện. Điều này khác với các kiểu quản trị hệ thống và công cụ quản trị hệ thống cũ.Một khía cạnh quan trọng của trạng thái mục tiêu là cách áp dụng. Nhiều học viên có kinh nghiệm dày dặn về việc sử dụng Ansible trong việc cung cấp và triển khai, nhưng không nhận ra rằng nó cũng áp dụng trong các hoạt động tự động hóa khác. Mặc dù nó tốt trong việc “khởi chạy” một máy chủ mới hoặc cập nhật máy chủ hiện có, nhưng nó cũng tiện dụng cho nhiều mục đích sử dụng khác giúp cải thiện tình trạng chung của hệ thống. Ví dụ, kiểm tra hàng ngày về ngày hết hạn chứng chỉ hoặc xác nhận hàng giờ rằng hệ thống tệp có ít nhất 10% dung lượng lưu trữ miễn phí. Chỉ cần một vài dòng Ansible để triển khai những mục tiêu này và nhiều mục tiêu khác cũng như xác minh.
  • Playbooks : Ansible playbooks được viết bằng YAML và định nghĩa một chuỗi các bước hoặc “plays” để thực hiện trên một hệ thống mục tiêu hoặc một nhóm hệ thống. Playbooks thể hiện các trạng thái mong muốn cho các hệ thống và cách đạt được các trạng thái đó. Sau đó, Ansible chịu trách nhiệm đạt được các trạng thái đó. Động lực đó là thành tựu cơ bản của Ansible.
  • Module : Module Ansible là các khối xây dựng của playbook. Module là các đơn vị mã riêng biệt thực hiện các tác vụ cụ thể như quản lý gói, cấu hình tệp hoặc khởi chạy dịch vụ. Một trong những tài sản tuyệt vời của Ansible là bộ sưu tập khổng lồ các module tích hợp và khả năng cho phép người dùng tạo ra các module tùy chỉnh.
  • Nhiệm vụ : Nhiệm vụ Ansible là các đơn vị riêng lẻ trong một playbook gọi các mô-đun để thực hiện các hành động cụ thể. Nhiệm vụ thực hiện tuần tự trên các hệ thống mục tiêu để đạt được trạng thái mong muốn.
  • Vai trò : Vai trò Ansible sắp xếp và đóng gói các playbook, biến, tác vụ và các thành phần khác liên quan thành các đơn vị có thể tái sử dụng và chia sẻ. Việc mô-đun hóa cấu hình của vai trò thúc đẩy khả năng tái sử dụng trên các playbook và dự án.
  • Inventory : Tệp inventory xác định các máy chủ và hệ thống đang được xem xét. Inventory có thể là tĩnh hoặc động. Nó thường bao gồm các thông tin như tên máy chủ, địa chỉ IP, nhóm và biến.
  • Biến : Ansible cho phép sử dụng các biến giúp playbook năng động và linh hoạt hơn. Chúng cũng có các phạm vi khác nhau, bao gồm global, playbook, role và task.
  • Facts : Ansible thu thập thông tin về các hệ thống mục tiêu bằng các mô-đun được gọi là facts . Ví dụ về thông tin được thu thập bao gồm phần cứng, hệ điều hành và địa chỉ internet. Playbook thông báo các quyết định mà họ đưa ra với các facts đó.
  • Templates : Ansible templates là các file được cấu trúc theo cú pháp Jinja2 với các placeholders. Playbook thực thi sẽ tự động điền các placeholders với các biến. Templates có thể tạo ra các file cấu hình, tập lệnh và các hiện vật Ansible khác.
  • Trình xử lý : Nhiều sự kiện Ansible cụ thể kích hoạt trình xử lý , thường là khi kết thúc quá trình chạy playbook. Trách nhiệm chung của trình xử lý là khởi động lại dịch vụ sau khi thay đổi cấu hình.
  • Lệnh Ad-hoc : Là lệnh khai báo, Ansible đủ linh hoạt để nhúng một số cơ chế bắt buộc giúp hợp lý hóa và đơn giản hóa các hoạt động cụ thể. Các lệnh ad-hoc của nó là không thể thiếu để kiểm tra tình trạng hệ thống nhanh chóng, khắc phục sự cố và các biện pháp khắc phục riêng biệt khác.

Thực hành tốt nhất của Ansible

Trong khi các biện pháp thực hành tốt nhất chắc chắn cải thiện hiệu quả thời gian chạy, chúng cũng cải thiện hiệu quả tổ chức. Chúng có thể thúc đẩy làm việc nhóm, đưa ra kết quả đáng tin cậy với nỗ lực tối thiểu, hỗ trợ tích hợp, giảm gánh nặng bảo trì và thậm chí bảo vệ khỏi trách nhiệm pháp lý.

Như Abelson và Sussman đã viết: “ Các chương trình phải được viết để mọi người đọc và chỉ tình cờ để máy móc thực thi ”. Tương tự như vậy, các sổ tay hướng dẫn Ansible tốt nhất là tài sản liên tục cho người đọc.

Nhận ra rằng các playbook Ansible và các thông số kỹ thuật liên quan là nguồn hoặc “ mã ”. Giống như tất cả các nguồn khác, chúng xứng đáng có một hệ thống kiểm soát mã nguồn được kiểm soát theo phiên bản để gọi về nhà. Hãy coi đây là “thực hành tốt nhất số không”, trước 12 thực hành tốt nhất sau đây để sử dụng Ansible.

Bố cục hệ thống tập tin

Tổ chức các dự án với bố cục hệ thống tệp nhất quán. Tách sổ tay hướng dẫn khỏi các vai trò, trong các thư mục có tên tương ứng playbooksvà roles. Kết quả sẽ trông giống như cấu trúc thư mục dự án mẫu sau:

project/
├── playbooks/
│   └── example_playbook.yml
├── roles/
│   └── example_role/
│       ├── tasks/
│       ├── handlers/
│       ├── templates/
│       └── …
│── ...
├── group_vars/
│   ├── all.yml
│   ├── production.yml
│   └── development.yml
│── ...
├── inventory/
│   ├── production_hosts
│   ├── staging_hosts
│   └── development_hosts
│── ...
├── vault/
│   ├── secret_file.yml
│   └── …
└── ...

Việc đánh vần tên tệp và các khía cạnh chính thức khác của dự án Ansible chỉ mang tính hình thức và không được coi là lập trình Ansible thực sự. Càng có lý do để chuẩn hóa các thông lệ chung mà những người khác đã xác định và dành sự chú ý của nhóm bạn cho các vấn đề sâu sắc hơn. Sau cùng, CNTT là một công việc hợp tác.

Mục đích của phương pháp hay nhất này không phải là về đức tính hay tính thẩm mỹ của một danh mục được đánh vần playbooksmà là playbookvề lợi ích của một ngôn ngữ chung cho toàn bộ nhóm . Sử dụng các phương pháp hay nhất này, các nhóm có thể chuyển sự chú ý của mình từ việc lo lắng về các chi tiết cụ thể sang suy nghĩ nhiều hơn về cách làm việc cùng nhau hướng tới các mục tiêu kinh doanh lớn hơn.

Cấu hình Ansible

Sử dụng ansible.cfgcho cấu hình toàn cầu. Xác định các mặc định hợp lý cho các đường dẫn kiểm kê và vai trò. Sử dụng chú thích cú pháp để ghi lại lý do đằng sau các lựa chọn được thực hiện.

Được thiết lập rõ ràng forksđể kiểm soát tính song song. Cấu hình pipeliningđể giới hạn sshcác hoạt động và tăng hiệu suất. Cấu hình ControlPathđể chia sẻ sshkết nối. Điều chỉnh timeoutvà poll_intervalquản lý thời gian chờ của các tác vụ chạy lâu.

Kiểm soát mức độ chi tiết của việc ghi nhật ký dựa trên kinh nghiệm thực tế và các phép đo của sổ tay hướng dẫn cụ thể đang sử dụng. Xem xét định kỳ cấu hình để đảm bảo nó phù hợp với các chính sách và mục tiêu đã thiết lập.

Thiết kế và cấu trúc Playbook

Sử dụng Roles để mô-đun hóa playbook. Tham khảo Ansible Galaxy để lấy cảm hứng về các định nghĩa hữu ích của Roles. Xác định lựa chọn của riêng bạn trong requirements.yml.

Hãy cân nhắc việc phân đoạn các playbook lớn và phức tạp thành nhiều playbook nhỏ hơn, mỗi playbook tập trung vào một thành phần hoặc chức năng cụ thể. Gói playbook kết quả có thể dễ quản lý hơn so với gói playbook hoàn chỉnh ban đầu. Một cách thay thế để cấu trúc playbook phức tạp là sử dụng thẻ . Thẻ vô hiệu hóa hoặc kích hoạt hiệu quả các phần của playbook. Ví dụ, đôi khi có lợi khi giữ nguyên một playbook, trong khi kiểm soát các phần riêng biệt trong đó.

Phân tách thông tin về kho lưu trữ, cấu hình và biến thành các tệp riêng biệt cho từng môi trường.

Duy trì một Vault cho tất cả thông tin nhạy cảm hoặc riêng tư. Bao gồm mật khẩu, chứng chỉ, mã thông báo, khóa hoặc bất kỳ thông tin chi tiết nào khác của khách hàng mà Ansible cần biết. Hãy cân nhắc phương án lưu trữ dữ liệu nhạy cảm trong một tệp và tham chiếu đến tệp đó thay vì mã hóa dữ liệu đó vào Ansible.

Xem xét và cải tiến cấu trúc sổ tay hướng dẫn theo định kỳ để đảm bảo tính mới mẻ và phù hợp với yêu cầu của dự án.

Tên biến

Chọn tên biến mô tả. Ví dụ, gatewaythay vì gw. Tuy nhiên, cũng nên chọn tên ngắn gọn thay vì tên phức tạp.

Ví dụ, hãy sử dụng snake casedatabase_account thay vì DatabaseAccounthoặc các biến thể khác.

Ghi lại mục đích, cách sử dụng và phạm vi của các biến bằng các bình luận. Ví dụ về các bình luận đặc biệt hữu ích tập trung vào các biến cụ thể bao gồm:

# hostname is case-insensitive, so that 'server1' and 'SERVER1' behave identically
# corpus_account must be qualified: 'name@domain.com' is OK, but 'name' is not

Nhóm các biến theo thứ bậc. Điều này có thể dẫn đến các tên như database_account, database_host, database_password, và database_priority. Các biến cụ thể theo môi trường xứng đáng có tiền tố có ý nghĩa như prod_database_accounthoặc env_database_account.

Tránh làm lu mờ các từ khóa được dành riêng . Thay vì itemhoặc serial, hãy chọn server_itemhoặc hardware_serial_number.

Đừng ngại tạo ra ngoại lệ cho các quy tắc này khi thích hợp. Ví dụ, hãy rút gọn gatewayxuống gwnếu một nhóm cụ thể có thông lệ lâu đời, được hiểu rõ về việc thực hiện như vậy trong các hệ thống và ngôn ngữ khác ngoài Ansible.

Cuối cùng nhưng không kém phần quan trọng, hãy luôn nhất quán trong các kế hoạch và dự án.

Xử lý lỗi trong Ansible

Xử lý lỗi là cực kỳ quan trọng. Hầu hết công việc được thực hiện bởi các hệ thống máy tính được thực hiện khi mọi thứ hoạt động như mong đợi. Tuy nhiên, một sổ tay hướng dẫn tốt có nhiều dòng dành riêng cho việc phản hồi lỗi hơn là những gì xảy ra khi mọi thứ diễn ra đúng.

“Xử lý” bao gồm mọi thứ từ việc bỏ qua lỗi, đến việc ghi nhật ký lỗi, thông báo cho hệ thống giám sát hoặc khởi chạy quy trình chẩn đoán. Thực hành tốt nhất quan trọng nhất trong xử lý lỗi là sử dụng rõ ràng ignore_errorsvà register. Khi một tình trạng cụ thể được đánh giá là không nghiêm trọng, hãy đánh dấu nó bằng ignore_errors, cho phép playbook tiếp tục. Ngoài ra, hãy đánh dấu nó bằng một bình luận thích hợp như # Error here is non-fatal because .... Cũng xử lý các điều kiện lỗi có điều kiện bằng when: task_result.failed. Một cơ chế xử lý lỗi khác, block-rescue-always, có thể áp dụng cho việc quản lý tài nguyên và dọn dẹp các trạng thái có vấn đề. Tận dụng assertmô-đun của Ansible. Đừng cho rằng một dịch vụ cụ thể khả dụng trước khi bắt đầu sử dụng dịch vụ đó. Thay vào đó, hãy cho rằng assertdịch vụ đó khả dụng trước.

Tìm hiểu chức năng ghi nhật ký, kiểm tra, gỡ lỗi và thoát mã tích hợp của Ansible để xử lý lỗi hiệu quả nhất.

Ghi nhật ký Ansible

Ansible logging có một số vai trò. Tìm hiểu những điều cần thiết bằng cách thực hành với các mô-đun log và debug. Ở dạng đơn giản nhất, log có thể truyền tải thông điệp trong quá trình thực thi playbook thông qua một thông số kỹ thuật như:

- name: Log a single diagnostic
  log:
    msg: "This is the diagnostic logged at this point"

Tiếp theo, hãy tìm hiểu cách cấu hình callback_whitelist, log_level, và log_pathtrong ansible.cfg. Thử nghiệm với log_levelđể tìm hiểu cách các danh mục CRITICAL, DEBUG, ERROR, INFO, và WARNINGáp dụng trong các dự án của bạn. Đặt chúng để đáp ứng nhu cầu của các ứng dụng cụ thể và sở thích của riêng bạn. Một số quản trị viên thích ghi lại mọi thứ có thể hữu ích, nhưng chỉ cho phép CRITICALthực hiện các hoạt động hàng ngày. Những người khác chỉ ghi lại chẩn đoán được đảm bảo là yêu cầu phản hồi. Bất kỳ cách tiếp cận nào hoặc nhiều phương án thay thế khác nhau giữa chúng đều có hiệu quả. Điều quan trọng hơn là phải nhất quán về phong cách bạn chọn.

Các plugin gọi lại của Ansible tự nhiên áp dụng cho nhiều tình huống ghi nhật ký. Ví dụ: khi bạn muốn tùy chỉnh định dạng đầu ra, chuyển thông báo đến email, lập hồ sơ số liệu hiệu suất trong một sự cố hoặc đáp ứng các yêu cầu ghi nhật ký.

Đánh dấu thời gian cho các mục nhập nhật ký của bạn. Xoay vòng nhật ký để đảm bảo sử dụng hiệu quả bộ nhớ. Lưu trữ nhật ký để kiểm tra và tuân thủ. Xử lý nhật ký như thông tin nhạy cảm cần được kiểm soát bảo mật, do đó hãy cấu hình quyền truy cập chỉ dành cho những người dùng có nhu cầu xem chúng.

Với các kiến ​​thức cơ bản về ghi nhật ký, hãy cân nhắc quản lý nhật ký phức tạp hơn thông qua các trình tổng hợp như Elasticsearch, Logstash, Kibana và Splunk. Những công cụ này giúp mở rộng khả năng phân tích nhật ký của bạn.

Quyết định về chính sách đánh giá. Không có phương pháp hay nhất nào được chứng minh là có thể áp dụng chung cho cách thức và thời điểm đánh giá nhật ký. Tốt nhất là phải thực tế. Nếu người ra quyết định tin rằng cần phải đọc nhật ký, hãy phân bổ thời gian để thực hiện như một chính sách rõ ràng và theo dõi kết quả.

Bình luận nội tuyến

Bình luận rất quan trọng và bổ ích, mặc dù ít được sử dụng trong thực tế. Mỗi lần bạn viết một dòng Ansible, hãy tự hỏi: điều gì sẽ giúp tôi hiểu được mục đích của điều này nếu tôi quay lại đây sau sáu tháng nữa? Lý tưởng nhất là sổ tay hướng dẫn của bạn phải đơn giản và dễ hiểu đến mức nguồn của chúng tự nói lên điều đó. Điều tốt nhất tiếp theo sau tình huống lý tưởng đó là nguồn được bình luận tốt đến mức nó trả lời mọi câu hỏi tự nhiên nảy sinh. Luôn viết bình luận hay và nhấn mạnh rằng toàn bộ nhóm của bạn cũng vậy.

README

Viết a READMEcho mỗi thư mục và thư mục con trong một dự án. Nó có thể ngắn gọn như sau:

# Variables for the Staging environment

This specification details the Ansible variables which
are specific to actions in the staging environment.

Các tệp khác READMEcó thể dài hàng trăm từ về kiến ​​trúc và quyết định thiết kế mà một thư mục cụ thể đại diện. Ba phương pháp thực hành tốt nhất tự nhiên áp dụng cho READMEcác tệp là:

  • Tạo chính xác một tệp README.mdcho mỗi thư mục trong một dự án.
  • Định dạng nội dung theo chuẩn Markdown .
  • Cung cấp “triết lý” và động lực cấp cao trong README. Để lại các chi tiết kỹ thuật cho các bình luận nguồn. Giảm thiểu việc lặp lại các bình luận nguồn và thay vào đó tham chiếu chúng trong READMEcác tệp.

Tài liệu hướng dẫn

Chuẩn bị một cấp độ cao nhất README.mdgiải thích mục đích và cách sử dụng sổ tay hướng dẫn. Cung cấp cho người đọc ít nhất một cách để kiểm tra sổ tay hướng dẫn. Nói cách khác, giải thích cách thực hiện một việc gì đó và kết quả sẽ như thế nào. Bao gồm các ví dụ, trường hợp sử dụng và tham chiếu đến các tài liệu có liên quan. Cung cấp liên kết đến chính sách của bạn về chủ đề này. Nếu một khía cạnh nào đó của sổ tay hướng dẫn khó giải thích, thì việc giải thích nó thậm chí còn quan trọng hơn. Sử dụng sơ đồ luồng dữ liệu, trạng thái hoặc thực thể, tùy theo trường hợp.

Liệt kê các phiên bản Ansible mà playbook tương thích. Bao gồm thông báo về giấy phép và bản quyền trong README.md. Xem lại README.mdđịnh kỳ để đảm bảo nó phù hợp với trạng thái hiện tại của playbook. Kết quả là một playbook dễ sử dụng và bảo trì đúng cách hơn, đặc biệt là đối với những người không tham gia vào quá trình tạo ban đầu.

Sử dụng Vaults cho dữ liệu nhạy cảm

Mã hóa dữ liệu nhạy cảm, bao gồm các biến, cấu hình, nội dung tác vụ và toàn bộ tệp. Tuy nhiên, không mã hóa thông tin không nhạy cảm. Lưu trữ các biến nhạy cảm trong vars/secrets.ymlvà mã hóa tệp. Tham chiếu các biến được mã hóa trong sổ tay hướng dẫn nếu cần.

Kiểm soát quyền truy cập vào Vault bằng các biện pháp kiểm soát như quyền hệ thống tệp. Chỉ cho phép người dùng được ủy quyền giải mã dữ liệu nhạy cảm và chỉ với khóa giải mã phù hợp. Chọn mật khẩu mạnh và khóa mã hóa. Viết chính sách rõ ràng cho lịch trình luân phiên và thực hành luân phiên để đảm bảo rằng nó được thực hiện đúng.

Mật khẩu không được xuất hiện trong sổ tay hướng dẫn. Sử dụng trình quản lý thông tin xác thực hoặc ít nhất là nhắc nhở cung cấp mật khẩu cần thiết khi chạy.

Giao tiếp an toàn

Các dự án Ansible thường giao tiếp thông qua ssh, và sshcác biện pháp thực hành tốt nhất bao gồm:

  • Chọn khóa mạnh
  • Chọn mật mã mạnh
  • Cấu hình an toàn
  • Chọn xác thực dựa trên khóa thay vì xác thực bằng mật khẩu
  • Phân phối khóa một cách an toàn
  • Giảm thiểu chuyển tiếp đại lý
  • Xác định các chính sách phù hợp, bao gồm giới hạn số lần đăng nhập không thành công và thời gian chờ không hoạt động.
  • Hãy cân nhắc việc cấu hình kiểm soát truy cập, hạn chế phương pháp xác thực và danh sách người dùng được phép thông qua sshd_config.

Cấu hình Ansible để sử dụng SSL cho giao tiếp giữa các nút điều khiển và máy chủ được quản lý. Kiểm soát quyền truy cập vào nút điều khiển bằng tường lửa và hạn chế mạng. Vá các thành phần Ansible thường xuyên và bật xác thực hai yếu tố (2FA).

Nếu dự án của bạn sử dụng Ansible API , hãy cấu hình giao tiếp cho TLS. Nếu dự án của bạn sử dụng Ansible Tower hoặc AWX , hãy cấu hình HTTPS.

Tăng đặc quyền và Sudo

becomeTìm hiểu tính năng của Ansible , được thiết kế riêng cho việc leo thang đặc quyền an toàn. Áp dụng becomechính xác, cho một lần chơi duy nhất tại một thời điểm, thay vì cho toàn bộ sổ tay hướng dẫn. Sử dụng become_usernhư một cách bổ sung để tăng độ chính xác của việc leo thang. Nghiên cứu become_methodđể hiểu khả năng áp dụng của các phương pháp leo thang khác nhau. Ví dụ, while sudolà mặc định, môi trường được trang bị PowerBroker cần ưu tiên pbrun. Xem lại việc sử dụng leo thang theo định kỳ.

Phần kết luận

Lợi ích lớn nhất liên quan đến các biện pháp thực hành tốt nhất của Ansible đến từ thói quen thường ngày, không mang tính kỹ thuật. Điều này bao gồm duy trì kiểm soát phiên bản playbook và tài liệu chính xác, tách biệt bí mật khỏi thông tin công khai, vai trò khỏi hành động và mục tiêu khỏi triển khai. Cập nhật phiên bản Ansible của bạn thông qua vòng đời phát triển phần mềm (SDLC) được xác định rõ ràng và sử dụng các công cụ như Ansible Lint một cách phù hợp. Đảm bảo rằng mọi dòng mã đều tồn tại vì một lý do nào đó.

Mặc dù những thói quen này không quá sâu sắc về mặt kỹ thuật, nhưng khi áp dụng chúng trong toàn bộ nhóm của bạn, các biện pháp thực hành tốt nhất của Ansible sẽ mang lại hiệu quả.

Nguồn: https://www.linode.com/docs/guides/front-line-best-practices-ansible/