Đây là bản ghi lại bài phát biểu и .
Đây là câu chuyện về một dự án sử dụng hệ thống quản lý cấu hình tự viết và tại sao việc chuyển sang Ansible lại mất tới 18 tháng.
Ngày số -ХХХ: Trước khi bắt đầu
Ban đầu, cơ sở hạ tầng bao gồm nhiều máy chủ riêng biệt chạy Hyper-V. Việc tạo một máy ảo cần nhiều bước: đặt các đĩa vào đúng vị trí, đăng ký DNS, đặt trước DHCP, đặt cấu hình VM vào kho git. Quá trình này đã được cơ giới hóa một phần, nhưng chẳng hạn, máy ảo được phân phối thủ công giữa các máy chủ. Tuy nhiên, ví dụ: các nhà phát triển có thể sửa cấu hình VM trong git và áp dụng nó bằng cách khởi động lại VM.
Giải pháp quản lý cấu hình tùy chỉnh
Tôi nghi ngờ ý tưởng ban đầu được hình thành dưới dạng IaC: nhiều máy ảo không trạng thái đặt lại trạng thái của chúng về 0 khi khởi động lại. Quản lý cấu hình VM là gì? Về mặt sơ đồ có vẻ đơn giản:
- Một MAC tĩnh đã được thiết lập cho VM.
- ISO với CoreOS và đĩa khởi động đã được kết nối với VM.
- CoreOS khởi chạy tập lệnh tùy chỉnh bằng cách tải xuống từ máy chủ WEB dựa trên IP của nó.
- Tập lệnh tải xuống cấu hình VM qua SCP dựa trên địa chỉ IP.
- Phần cuối của các tệp đơn vị systemd và phần cuối của các tập lệnh bash được khởi chạy.
Giải pháp này có nhiều vấn đề rõ ràng:
- CoreOS ISO đã không còn được dùng nữa.
- Rất nhiều hành động tự động phức tạp và phép thuật khi di chuyển/tạo VM.
- Khó khăn khi cập nhật và khi cần một phiên bản phần mềm nhất định. Thậm chí còn thú vị hơn với các mô-đun hạt nhân.
- Máy ảo không thể thu được nếu không có dữ liệu, tức là Máy ảo xuất hiện cùng với một đĩa có gắn dữ liệu người dùng bổ sung.
- Ai đó đã liên tục làm hỏng phần phụ thuộc của đơn vị systemd và CoreOS sẽ bị treo khi khởi động lại. Rất khó để phát hiện điều này bằng các công cụ có sẵn trong CoreOS.
- Quản lý bí mật.
- Không có CM. Có cấu hình bash và YML cho CoreOS.
Để áp dụng cấu hình VM, bạn cần khởi động lại nó, nhưng nó có thể không khởi động lại được. Đây có vẻ như là một vấn đề hiển nhiên, nhưng không có đĩa liên tục - không có nơi nào để lưu nhật ký. Được rồi, hãy thử thêm tùy chọn tải kernel để nhật ký được gửi. Nhưng không, mọi chuyện thật phức tạp làm sao.
Ngày #0: Nhận ra vấn đề
Đó là cơ sở hạ tầng phát triển thông thường: jenkins, môi trường thử nghiệm, giám sát, đăng ký. CoreOS được thiết kế để lưu trữ các cụm k8s, tức là. vấn đề là cách sử dụng CoreOS. Bước đầu tiên là chọn một ngăn xếp. Chúng tôi đã quyết định:
- CentOS như là một phân phối cơ sở, bởi vì Đây là bản phân phối gần nhất với môi trường sản xuất.
- Có khả năng để quản lý cấu hình, bởi vì đã có cuộc kiểm tra rộng rãi về nó.
- Jenkins như một khuôn khổ để tự động hóa các quy trình hiện có, bởi vì nó đã được sử dụng tích cực cho các quá trình phát triển
- Hyper-V như một nền tảng ảo hóa. Có một số lý do nằm ngoài phạm vi câu chuyện, nhưng tóm lại - chúng ta không thể sử dụng đám mây, chúng ta phải sử dụng phần cứng của chính mình.
Ngày thứ 30: Sửa chữa các thỏa thuận hiện có - Thỏa thuận như Bộ luật
Khi đống đồ đã rõ ràng, việc chuẩn bị cho việc di chuyển bắt đầu. Sửa các thỏa thuận hiện có dưới dạng mã (Thỏa thuận dưới dạng Bộ luật!). Chuyển tiếp thủ công -> cơ giới hóa -> tự động hóa.
1. Cấu hình máy ảo
Ansible thực hiện rất tốt công việc này. Với tối thiểu chuyển động cơ thể, bạn có thể kiểm soát cấu hình VM:
- Tạo một kho lưu trữ git.
- Chúng tôi đưa danh sách máy ảo vào kho, cấu hình trong sổ tay và vai trò.
- Chúng tôi đang thiết lập một nô lệ jenkins đặc biệt để bạn có thể chạy Ansible.
- Chúng tôi tạo một công việc và cấu hình Jenkins.
Quá trình đầu tiên đã sẵn sàng. Các thỏa thuận đã được cố định.
2. Tạo VM mới
Mọi thứ ở đây không thuận tiện lắm. Việc tạo máy ảo trên Hyper-V từ Linux không thuận tiện lắm. Một trong những nỗ lực cơ giới hóa quá trình này là:
- Ansbile kết nối qua WinRM với máy chủ Windows.
- Ansible chạy tập lệnh powershell.
- Tập lệnh Powershell tạo một VM mới.
- Sử dụng Hyper-V/ScVMM, khi tạo VM trong hệ điều hành khách, tên máy chủ sẽ được định cấu hình.
- Khi cập nhật hợp đồng thuê DHCP, VM sẽ gửi tên máy chủ của nó.
- Tích hợp ddns & dhcp tiêu chuẩn ở phía Bộ điều khiển miền sẽ định cấu hình bản ghi DNS.
- Bạn có thể thêm VM vào kho của mình và định cấu hình nó bằng Ansible.
3.Tạo mẫu VM
Họ không phát minh ra bất cứ thứ gì ở đây - họ lấy một người đóng gói.
- Thêm trình đóng gói, cấu hình khởi động vào kho git.
- Thiết lập một nô lệ jenkins đặc biệt với hyper-v và Packer.
- Chúng tôi tạo một công việc và cấu hình Jenkins.
Cách liên kết này hoạt động:
- Packer tạo một VM trống và chọn ISO.
- VM khởi động, Packer nhập lệnh vào bootloader để sử dụng file kickstart của chúng ta từ đĩa mềm hoặc http.
- Anaconda được khởi chạy với cấu hình của chúng tôi và cấu hình hệ điều hành ban đầu đã hoàn tất.
- Packer đợi VM khả dụng.
- Trình đóng gói bên trong VM chạy ansible ở chế độ cục bộ.
- Ansible sử dụng chính xác các vai trò giống như ở bước #1.
- Packer xuất mẫu VM.
Ngày #75: Tái cấu trúc thỏa thuận mà không vi phạm = Test ansible + Testkitchen
Nắm bắt các quy ước trong mã có thể là không đủ. Rốt cuộc, nếu bạn muốn thay đổi điều gì đó trong và ngoài quy trình, bạn có thể phá vỡ thứ gì đó. Do đó, trong trường hợp cơ sở hạ tầng, việc thử nghiệm chính cơ sở hạ tầng này xuất hiện. Để đồng bộ hóa kiến thức trong nhóm, chúng tôi đã bắt đầu thử nghiệm các vai trò Ansible. Tôi sẽ không đi sâu vì... có một bài viết mô tả các sự kiện tại thời điểm đó (spoiler đây không phải là phiên bản cuối cùng và sau này mọi thứ trở nên phức tạp hơn ).
Ngày thứ 130: Có lẽ CentOS+ansible không cần thiết? có thể là openshift?
Chúng ta phải hiểu rằng quá trình giới thiệu cơ sở hạ tầng không phải là duy nhất và còn có các tiểu dự án phụ. Ví dụ: có một yêu cầu khởi chạy ứng dụng của chúng tôi trong openshift và điều này dẫn đến việc nghiên cứu kéo dài hơn một tuần làm chậm quá trình chuyển động. Kết quả hóa ra là openshift không đáp ứng được mọi nhu cầu; bạn cần phần cứng thực sự hoặc ít nhất là khả năng chơi với kernel.
Ngày thứ 170: Openshift không phù hợp, hãy thử sức với Windows Azure Pack?
Hyper-V không thân thiện lắm, SCVMM cũng không làm nó tốt hơn nhiều. Nhưng có một thứ như Windows Azure Pack, là một tiện ích bổ sung cho SCVMM và bắt chước Azure. Nhưng trên thực tế, sản phẩm có vẻ bị bỏ rơi: tài liệu có liên kết bị hỏng và rất thưa thớt. Nhưng trong khuôn khổ nghiên cứu các lựa chọn nhằm đơn giản hóa hoạt động trên đám mây của chúng tôi, họ cũng đã xem xét nó.
Ngày thứ 250: Windows Azure Pack không tốt lắm. Chúng tôi vẫn ở trên SCVMM
Windows Azure Pack có vẻ đầy hứa hẹn, nhưng người ta đã quyết định không đưa WAP với sự phức tạp của nó vào hệ thống vì những tính năng không cần thiết và vẫn ở lại với SCVMM.
Ngày thứ 360: Ăn thịt voi từng miếng một
Chỉ một năm sau, nền tảng để chuyển đến đã sẵn sàng và quá trình di chuyển bắt đầu. Với mục đích này, S.M.A.R.T đã được cài đặt. nhiệm vụ. Chúng tôi đã kiểm tra tất cả các máy ảo và bắt đầu tìm ra từng cấu hình, mô tả nó trong Ansible và thực hiện các thử nghiệm.
Ngày thứ 450: Bạn đã có được loại hệ thống nào?
Bản thân quá trình này không thú vị. Đó là thông lệ, có thể lưu ý rằng hầu hết các cấu hình đều tương đối đơn giản hoặc đẳng cấu và theo nguyên tắc Pareto, 80% cấu hình VM yêu cầu 20% thời gian. Theo nguyên tắc tương tự, 80% thời gian được dành cho việc chuẩn bị nước đi và chỉ 20% thời gian dành cho việc di chuyển.
Ngày thứ 540: Cuối cùng
Điều gì đã xảy ra trong 18 tháng?
- Các thỏa thuận đã trở thành một quy tắc.
- Thủ công -> Cơ giới hóa -> Tự động hóa.
Liên kết
Nguồn: www.habr.com