Nếu cơ sở hạ tầng CNTT của bạn phát triển quá nhanh, sớm hay muộn bạn sẽ phải đối mặt với sự lựa chọn: tăng tuyến tính nguồn nhân lực để hỗ trợ hoặc bắt đầu tự động hóa. Cho đến một thời điểm nào đó, chúng tôi đã sống trong mô hình đầu tiên và sau đó con đường dài dẫn đến Cơ sở hạ tầng dưới dạng Mã bắt đầu.
Tất nhiên, NSPK không phải là một công ty khởi nghiệp, nhưng bầu không khí như vậy đã ngự trị trong công ty trong những năm đầu tiên thành lập và đó là những năm rất thú vị. Tên tôi là , Tôi đã hỗ trợ cơ sở hạ tầng Linux với yêu cầu về tính sẵn sàng cao trong hơn 10 năm. Anh ấy gia nhập nhóm NSPK vào tháng 2016 năm XNUMX và thật không may, anh ấy chưa nhìn thấy sự khởi đầu của sự tồn tại của công ty mà đã đến một giai đoạn có nhiều thay đổi lớn.
Nhìn chung, có thể nói rằng nhóm của chúng tôi cung cấp 2 sản phẩm cho công ty. Đầu tiên là cơ sở hạ tầng. Thư sẽ hoạt động, DNS sẽ hoạt động và bộ điều khiển miền sẽ cho phép bạn truy cập vào các máy chủ không gặp sự cố. Bối cảnh CNTT của công ty rất lớn! Đây là những hệ thống quan trọng về kinh doanh và sứ mệnh, yêu cầu về tính khả dụng đối với một số hệ thống là 99,999. Sản phẩm thứ hai chính là các máy chủ, vật lý và ảo. Những cái hiện có cần được theo dõi và những cái mới phải được giao thường xuyên cho khách hàng từ nhiều bộ phận. Trong bài viết này, tôi muốn tập trung vào cách chúng tôi phát triển cơ sở hạ tầng chịu trách nhiệm cho vòng đời của máy chủ.
Bắt đầu một cuộc hành trình
Khi bắt đầu hành trình, nhóm công nghệ của chúng tôi trông như thế này:
Hệ điều hành CentOS 7
Bộ điều khiển miền FreeIPA
Tự động hóa - Ansible(+Tower), Cobbler
Tất cả điều này được đặt trong 3 miền, trải rộng trên một số trung tâm dữ liệu. Trong một trung tâm dữ liệu có hệ thống văn phòng và địa điểm thử nghiệm, phần còn lại có SẢN PHẨM.
Tạo máy chủ tại một thời điểm trông như thế này:
Trong mẫu VM, CentOS là mức tối thiểu và mức tối thiểu bắt buộc giống như /etc/resolv.conf chính xác, phần còn lại thông qua Ansible.
CMDB-Excel.
Nếu máy chủ là vật lý thì thay vì sao chép máy ảo, hệ điều hành đã được cài đặt trên máy ảo bằng Cobbler - địa chỉ MAC của máy chủ đích được thêm vào cấu hình Cobbler, máy chủ nhận địa chỉ IP qua DHCP và sau đó là hệ điều hành được thêm vào.
Lúc đầu, chúng tôi thậm chí còn thử thực hiện một số loại quản lý cấu hình trong Cobbler. Nhưng theo thời gian, điều này bắt đầu gây ra các vấn đề về khả năng di chuyển của cấu hình đến các trung tâm dữ liệu khác và mã Ansible để chuẩn bị máy ảo.
Vào thời điểm đó, nhiều người trong chúng tôi coi Ansible là một phần mở rộng tiện lợi của Bash và không tiết kiệm các thiết kế sử dụng shell và sed. Nhìn chung có thể đánh bại được. Điều này cuối cùng dẫn đến thực tế là nếu playbook vì lý do nào đó không hoạt động trên máy chủ thì việc xóa máy chủ, sửa playbook và chạy lại sẽ dễ dàng hơn. Về cơ bản không có phiên bản của tập lệnh, không có tính di động của cấu hình.
Ví dụ: chúng tôi muốn thay đổi một số cấu hình trên tất cả các máy chủ:
- Chúng tôi thay đổi cấu hình trên các máy chủ hiện có trong phân đoạn logic/trung tâm dữ liệu. Đôi khi không phải trong một ngày - yêu cầu về khả năng tiếp cận và luật số lớn không cho phép áp dụng tất cả các thay đổi cùng một lúc. Và một số thay đổi có khả năng phá hủy và yêu cầu khởi động lại thứ gì đó - từ dịch vụ đến chính hệ điều hành.
- Sửa nó trong Ansible
- Chúng tôi sửa nó trong Cobbler
- Lặp lại N lần cho mỗi phân đoạn logic/trung tâm dữ liệu
Để mọi thay đổi diễn ra suôn sẻ cần phải tính đến nhiều yếu tố và những thay đổi diễn ra liên tục.
- Tái cấu trúc mã ansible, tập tin cấu hình
- Thay đổi các phương pháp hay nhất nội bộ
- Những thay đổi dựa trên kết quả phân tích sự cố/tai nạn
- Thay đổi các tiêu chuẩn bảo mật, cả bên trong và bên ngoài. Ví dụ: PCI DSS được cập nhật các yêu cầu mới hàng năm
Tăng trưởng cơ sở hạ tầng và sự khởi đầu của hành trình
Số lượng máy chủ/miền logic/trung tâm dữ liệu tăng lên và kéo theo đó là số lỗi trong cấu hình. Tại một số thời điểm, chúng tôi đã đi đến ba hướng cần phát triển quản lý cấu hình:
- Tự động hóa. Cần tránh lỗi của con người trong các hoạt động lặp đi lặp lại càng nhiều càng tốt.
- Độ lặp lại. Việc quản lý cơ sở hạ tầng sẽ dễ dàng hơn nhiều khi có thể dự đoán được. Cấu hình của máy chủ và công cụ để chuẩn bị phải giống nhau ở mọi nơi. Điều này cũng quan trọng đối với nhóm sản phẩm - sau khi thử nghiệm, ứng dụng phải được đảm bảo kết thúc trong môi trường sản xuất được định cấu hình tương tự như môi trường thử nghiệm.
- Đơn giản và minh bạch khi thực hiện các thay đổi đối với quản lý cấu hình.
Nó vẫn còn để thêm một vài công cụ.
Chúng tôi đã chọn GitLab CE làm kho lưu trữ mã của mình, nhất là đối với các mô-đun CI/CD tích hợp sẵn của nó.
Hầm bí mật - Hashicorp Vault, bao gồm. cho API tuyệt vời.
Kiểm tra cấu hình và vai trò ansible – Molecule+Testinfra. Quá trình kiểm tra diễn ra nhanh hơn nhiều nếu bạn kết nối với ansible mitogen. Đồng thời, chúng tôi bắt đầu viết CMDB và bộ điều phối của riêng mình để triển khai tự động (trong hình trên Cobbler), nhưng đây là một câu chuyện hoàn toàn khác, mà đồng nghiệp của tôi và nhà phát triển chính của những hệ thống này sẽ kể trong tương lai.
Sự lựa chọn của chúng tôi:
Phân tử + Testinfra
Ansible + Tháp + AWX
Thế giới máy chủ + DITNET (Tự phát triển)
Người thổi
Á hậu Gitlab + GitLab
Hashicorp Vault
Nhân tiện, về vai trò ansible. Lúc đầu chỉ có một, nhưng sau một số lần tái cấu trúc, tôi thực sự khuyên bạn nên chia khối nguyên khối thành các vai trò bình thường, sau đó có thể khởi chạy riêng, ngoài ra, bạn có thể thêm thẻ. Chúng tôi chia vai trò theo chức năng - mạng, ghi nhật ký, gói, phần cứng, phân tử, v.v. Nói chung, chúng tôi đã làm theo chiến lược dưới đây. Tôi không nhấn mạnh rằng đây là sự thật duy nhất, nhưng nó đã có tác dụng với chúng tôi.
- Sao chép máy chủ từ "hình ảnh vàng" là xấu xa!Nhược điểm chính là bạn không biết chính xác trạng thái hiện tại của hình ảnh và mọi thay đổi sẽ đến với tất cả hình ảnh trong tất cả các trang trại ảo hóa.
- Sử dụng các tệp cấu hình mặc định ở mức tối thiểu và thống nhất với các bộ phận khác rằng bạn chịu trách nhiệm về các tệp hệ thống chính, ví dụ:
- Để trống /etc/sysctl.conf, cài đặt chỉ nên có trong /etc/sysctl.d/. Mặc định của bạn trong một tệp, tùy chỉnh cho ứng dụng trong một tệp khác.
- Sử dụng các tập tin ghi đè để chỉnh sửa các đơn vị systemd.
- Tạo mẫu tất cả các cấu hình và bao gồm chúng hoàn toàn nếu có thể, không có sed hoặc các cấu hình tương tự trong sách giải trí;
- Tái cấu trúc mã hệ thống quản lý cấu hình:
- Chia nhiệm vụ thành các thực thể logic và viết lại nguyên khối thành các vai trò
- Sử dụng xơ vải! Ansible-lint, yaml-lint, v.v.
- Thay đổi cách tiếp cận của bạn! Không có gì đáng chê trách. Cần mô tả trạng thái của hệ thống
- Đối với tất cả các vai trò Ansible, bạn cần viết các bài kiểm tra trong phân tử và tạo báo cáo mỗi ngày một lần.
- Trong trường hợp của chúng tôi, sau khi chuẩn bị các bài kiểm tra (trong đó có hơn 100 bài kiểm tra), khoảng 70000 lỗi đã được tìm thấy. Phải mất vài tháng để sửa nó.
Việc thực hiện của chúng tôi
Vì vậy, các vai trò ansible đã sẵn sàng, được tạo khuôn mẫu và kiểm tra bởi linters. Và thậm chí cả git cũng được nâng lên ở khắp mọi nơi. Nhưng câu hỏi về việc phân phối mã đáng tin cậy đến các phân khúc khác nhau vẫn còn bỏ ngỏ. Chúng tôi quyết định đồng bộ hóa với các tập lệnh. Có vẻ như vậy:
Sau khi có thay đổi, CI được khởi chạy, máy chủ thử nghiệm được tạo, các vai trò được triển khai và được phân tử kiểm tra. Nếu mọi thứ đều ổn, mã sẽ chuyển đến nhánh sản phẩm. Nhưng chúng tôi không áp dụng mã mới cho các máy chủ hiện có trong máy. Đây là một loại nút chặn cần thiết để hệ thống của chúng tôi có tính sẵn sàng cao. Và khi cơ sở hạ tầng trở nên khổng lồ, quy luật số lớn phát huy tác dụng - ngay cả khi bạn chắc chắn rằng sự thay đổi đó là vô hại thì nó vẫn có thể dẫn đến những hậu quả thảm khốc.
Ngoài ra còn có nhiều tùy chọn để tạo máy chủ. Cuối cùng chúng tôi đã chọn các tập lệnh Python tùy chỉnh. Và đối với CI ansible:
- name: create1.yml - Create a VM from a template
vmware_guest:
hostname: "{{datacenter}}".domain.ru
username: "{{ username_vc }}"
password: "{{ password_vc }}"
validate_certs: no
cluster: "{{cluster}}"
datacenter: "{{datacenter}}"
name: "{{ name }}"
state: poweredon
folder: "/{{folder}}"
template: "{{template}}"
customization:
hostname: "{{ name }}"
domain: domain.ru
dns_servers:
- "{{ ipa1_dns }}"
- "{{ ipa2_dns }}"
networks:
- name: "{{ network }}"
type: static
ip: "{{ip}}"
netmask: "{{netmask}}"
gateway: "{{gateway}}"
wake_on_lan: True
start_connected: True
allow_guest_control: True
wait_for_ip_address: yes
disk:
- size_gb: 1
type: thin
datastore: "{{datastore}}"
- size_gb: 20
type: thin
datastore: "{{datastore}}"Đây là những gì chúng tôi đã đạt được, hệ thống tiếp tục tồn tại và phát triển.
- 17 Vai trò có thể sử dụng để thiết lập máy chủ. Mỗi vai trò được thiết kế để giải quyết một nhiệm vụ logic riêng biệt (ghi nhật ký, kiểm tra, ủy quyền người dùng, giám sát, v.v.).
- Kiểm tra vai trò. Phân tử + TestInfra.
- Phát triển riêng: CMDB + Orchestrator.
- Thời gian tạo máy chủ là ~30 phút, tự động và thực tế không phụ thuộc vào hàng đợi tác vụ.
- Trạng thái/cách đặt tên giống nhau của cơ sở hạ tầng trong tất cả các phân đoạn - sách giải trí, kho lưu trữ, phần tử ảo hóa.
- Kiểm tra trạng thái máy chủ hàng ngày bằng cách tạo báo cáo về những khác biệt so với tiêu chuẩn.
Tôi hy vọng câu chuyện của tôi sẽ hữu ích cho những ai đang bắt đầu cuộc hành trình của mình. Bạn sử dụng ngăn xếp tự động hóa nào?
Nguồn: www.habr.com