Dịch vụ Thông tin Dữ liệu Vệ tinh Môi trường Quốc gia (NESDIS) đã giảm 35% chi phí quản lý cấu hình cho Red Hat Enterprise Linux (RHEL) bằng cách di chuyển từ Puppet Enterprise sang Ansible Tower. Trong video "chúng tôi đã thực hiện như thế nào" này, kỹ sư hệ thống Michael Rau giải thích trường hợp di chuyển này, chia sẻ các mẹo và bài học hữu ích rút ra từ việc chuyển từ SCM này sang SCM khác.
Trong video này, bạn sẽ học:
- làm thế nào để chứng minh cho ban quản lý tính khả thi của việc chuyển từ Puppet Enterprise sang Ansible Tower;
- nên sử dụng những chiến lược nào để quá trình chuyển đổi diễn ra suôn sẻ nhất có thể;
- mẹo chuyển mã các bảng kê khai PE sang Ansible Playbook;
- Khuyến nghị lắp đặt tối ưu Ansible Tower.
Xin chào mọi người, tên tôi là Michael Rau, tôi là Kỹ sư hệ thống cấp cao tại ActioNet, làm việc cho dịch vụ NESDIS của Cơ quan Khí quyển và Đại dương Quốc gia (NOAA). Hôm nay chúng ta sẽ nói về việc cắt dây - trải nghiệm của riêng tôi khi chuyển từ Puppet Enterprise sang Ansible Tower. Chủ đề của bài thuyết trình này là “hãy nhìn vào những vết sẹo của tôi” để lại sau khi tôi thực hiện quá trình chuyển đổi này vào đầu năm. Tôi muốn chia sẻ những gì tôi học được qua quá trình này. Vì vậy, khi bạn đảm nhận một công việc như thế này, sử dụng kinh nghiệm của tôi, bạn có thể thực hiện quá trình chuyển đổi mà không cần phải làm thêm bất kỳ công việc nào.
Bạn sẽ thấy các slide tương tự như thế này ở đầu mỗi bài thuyết trình tại Ansible Fest. Trang trình bày này tóm tắt lịch sử tự động hóa của công ty tôi. Tôi không lạ gì với điều này vì tôi đã sử dụng Puppet/Puppet Enterprise từ năm 2007. Tôi bắt đầu làm việc với Ansible vào năm 2016, và giống như nhiều người dùng khác của sản phẩm này, tôi bị thu hút bởi khả năng xảy ra các “thủ thuật” bằng cách sử dụng dòng lệnh và các tập lệnh đơn giản (playbook). Vào cuối năm 2017, tôi đã liên hệ với ban quản lý của mình về những lý do chính đáng để chuyển đến Ansible Tower. Trong một phút nữa, tôi sẽ cho bạn biết lý do thúc đẩy tôi thực hiện bước này. Sau khi nhận được sự đồng ý của ban lãnh đạo, phải mất thêm vài tháng nữa mới hoàn thành kế hoạch và tôi đã thực hiện chuyển đổi vào tháng XNUMX-tháng XNUMX năm nay. Vì vậy, chúng tôi đã hoàn toàn từ bỏ Puppet để chuyển sang sử dụng Ansible và đó là một điều tuyệt vời.
Điều hấp dẫn tôi nhất ở Ansible là khả năng viết và sử dụng các vai trò cũng như sách giải trí. Vai trò rất phù hợp để tạo các nhiệm vụ riêng biệt nhưng có liên quan và đặt tất cả dữ liệu liên quan đến các nhiệm vụ đó vào một nơi. Playbook là một cú pháp YAML, tệp tập lệnh mô tả các hành động cho một hoặc nhiều máy chủ. Tôi nói với người dùng về những tính năng này, chủ yếu là các nhà phát triển phần mềm. Ansible Tower cung cấp cho bạn khả năng nói, "không, bạn không có quyền truy cập shell, nhưng tôi cung cấp cho bạn khả năng chạy tất cả các quy trình của Tower và khởi động lại dịch vụ khi bạn cần." Tôi sẽ kể cho bạn nghe về môi trường làm việc và thiết bị chúng tôi sử dụng.
Đây là mạng LAN liên bang, 7 địa điểm vật lý được kết nối qua MPLS đám mây, 140 máy chủ RHEL, 99% trong số đó là ảo (vSphere), phần cứng SuperMicro, bộ lưu trữ mạng NexentaStore, một bộ thiết bị chuyển mạch Cisco, Arista và Cumulus và quản lý mối đe dọa thống nhất Fortinet UTM công cụ trên mỗi trang web.
Mạng liên bang có nghĩa là tôi phải sử dụng tất cả các biện pháp bảo mật thông tin do pháp luật quy định. Bạn nên nhớ rằng Puppet Enterprise không hỗ trợ hầu hết phần cứng mà chúng tôi sử dụng. Chúng tôi buộc phải sử dụng phần cứng ngân sách vì các cơ quan chính phủ gặp khó khăn trong việc tài trợ cho khoản mục chi phí này. Đó là lý do tại sao chúng tôi mua phần cứng SuperMicro và lắp ráp thiết bị của mình từ các bộ phận riêng lẻ, việc bảo trì được đảm bảo theo hợp đồng của chính phủ. Chúng tôi sử dụng Linux và đây là một trong những lý do quan trọng để chuyển sang Ansible.
Lịch sử của chúng tôi với Puppet như sau.
Năm 2007, chúng tôi có một mạng nhỏ gồm 20-25 nút, trong đó chúng tôi đã triển khai Puppet. Về cơ bản, các nút này chỉ là các “hộp” RedHat. Năm 2010, chúng tôi bắt đầu sử dụng giao diện web Bảng điều khiển con rối cho 45 nút. Khi mạng tiếp tục mở rộng, chúng tôi đã chuyển sang PE 2014 vào năm 3.3, thực hiện quá trình chuyển đổi hoàn toàn bằng cách viết lại bảng kê khai cho 75 nút. Điều này phải được thực hiện vì Puppet thích thay đổi luật chơi và trong trường hợp này họ đã thay đổi hoàn toàn ngôn ngữ. Một năm sau, khi hỗ trợ cho phiên bản 3 của Puppet Enterprise kết thúc, chúng tôi buộc phải chuyển sang PE 2015.2. Chúng tôi phải viết lại bảng kê khai một lần nữa cho các máy chủ mới và mua giấy phép với số lượng dự trữ là 100 nút, mặc dù vào thời điểm đó chúng tôi chỉ có 85 nút.
Chỉ mới 2 năm trôi qua, chúng tôi lại phải làm rất nhiều việc để chuyển sang phiên bản mới PE 2016.4. Chúng tôi đã mua giấy phép cho 300 nút, nhưng chỉ có 130 nút. Một lần nữa, chúng tôi phải thực hiện những thay đổi lớn đối với tệp kê khai vì phiên bản mới của ngôn ngữ có cú pháp khác với ngôn ngữ của phiên bản 2015. Do đó, SCM của chúng tôi đã chuyển từ kiểm soát phiên bản SVN sang Bitbucket (Git). Đây chính là “mối quan hệ” của chúng tôi với Puppet.
Vì vậy, tôi phải giải thích với ban quản lý lý do tại sao chúng tôi cần chuyển sang một SCM khác bằng cách sử dụng các lập luận sau. Đầu tiên là giá dịch vụ cao. Tôi đã nói chuyện với những người ở RedHat và họ nói rằng chi phí vận hành mạng 300 nút với Ansible Tower chỉ bằng một nửa chi phí của Puppet Enterprise. Nếu bạn cũng mua Ansible Engine, chi phí sẽ tương đương nhưng bạn sẽ nhận được nhiều tính năng hơn PE. Vì chúng tôi là một công ty nhà nước được tài trợ từ ngân sách liên bang nên đây là một lập luận khá thuyết phục.
Đối số thứ hai là tính linh hoạt. Puppet chỉ hỗ trợ phần cứng có tác nhân Puppet. Điều này có nghĩa là một tác nhân phải được cài đặt trên tất cả các thiết bị chuyển mạch và nó phải là phiên bản mới nhất. Và nếu một số thiết bị chuyển mạch của bạn hỗ trợ một phiên bản và một số hỗ trợ phiên bản khác, bạn sẽ cần cài đặt phiên bản mới của tác nhân PE trên chúng để tất cả chúng có thể hoạt động trong cùng một hệ thống SCM.
Hệ thống Ansible Tower hoạt động khác biệt vì nó không có bất kỳ tác nhân nào, nhưng nó có các mô-đun hỗ trợ các thiết bị chuyển mạch Cisco và tất cả các thiết bị chuyển mạch khác. SCM này hỗ trợ Qubes OS, Linux và 4.NET UTM. Ansible Tower cũng hỗ trợ bộ điều khiển lưu trữ mạng NexentaStore dựa trên kernel Illumos, một hệ điều hành mã nguồn mở dựa trên Unix. Điều này có rất ít sự hỗ trợ, nhưng Ansible Tower vẫn làm được.
Lập luận thứ ba, rất quan trọng đối với cả tôi và chính quyền của chúng tôi, là tính dễ sử dụng. Tôi đã dành 10 năm để thành thạo các mô-đun Puppet và mã kê khai, nhưng tôi đã học được Ansible trong vòng một tuần vì SCM này dễ làm việc hơn nhiều. Tất nhiên, nếu bạn chạy các tệp thực thi, trừ khi bạn làm như vậy một cách không cần thiết, thì các trình xử lý thông minh và phản hồi nhanh sẽ làm việc với chúng. Sách hướng dẫn dựa trên YAML rất dễ học và sử dụng nhanh chóng. Những người chưa bao giờ nghe nói về YAML trước đây có thể chỉ cần đọc các tập lệnh và dễ dàng hiểu cách thức hoạt động của nó.
Thành thật mà nói, Puppet khiến công việc phát triển của bạn trở nên khó khăn hơn nhiều vì nó dựa trên việc sử dụng Puppet Master. Đây là cỗ máy duy nhất được phép giao tiếp với các đặc vụ Puppet. Nếu bạn đã thực hiện bất kỳ thay đổi nào đối với tệp kê khai và muốn kiểm tra mã của mình, bạn phải viết lại mã cho Puppet Master, nghĩa là định cấu hình tệp Puppet Master /etc/hosts để kết nối tất cả máy khách và khởi động dịch vụ Puppet Server. Chỉ sau đó, bạn mới có thể kiểm tra hoạt động của thiết bị mạng trên một máy chủ. Đây là một thủ tục khá đau đớn.
Mọi thứ đơn giản hơn nhiều trong Ansible. Tất cả những gì bạn cần làm là phát triển mã cho một máy có thể giao tiếp qua SSH với máy chủ đang được thử nghiệm. Điều này dễ dàng hơn nhiều để làm việc với.
Ưu điểm lớn tiếp theo của Ansible Tower là khả năng tận dụng hệ thống hỗ trợ hiện có và duy trì cấu hình phần cứng hiện có của bạn. SCM này sử dụng tất cả thông tin có sẵn về cơ sở hạ tầng và phần cứng, máy ảo, máy chủ, v.v. của bạn mà không cần bất kỳ bước bổ sung nào. Nó có thể giao tiếp với các máy chủ Vệ tinh RH của bạn, nếu bạn có, và cung cấp cho bạn những tích hợp mà bạn sẽ không bao giờ có được với Puppet.
Một điều quan trọng khác là kiểm soát chi tiết. Bạn biết rằng Puppet là một hệ thống mô-đun, nó là một ứng dụng máy khách-máy chủ, vì vậy bạn phải xác định các khía cạnh hiện có của tất cả các máy của mình trong một bảng kê khai dài. Trong trường hợp này, trạng thái của từng thành phần riêng lẻ của hệ thống phải được kiểm tra nửa giờ một lần - đây là khoảng thời gian mặc định. Đây là cách con rối hoạt động.
Tháp cứu bạn khỏi điều đó. Bạn có thể chạy nhiều quy trình khác nhau trên nhiều loại thiết bị mà không bị hạn chế; bạn có thể thực hiện công việc cơ bản, chạy các quy trình quan trọng khác, thiết lập hệ thống bảo mật và làm việc với cơ sở dữ liệu. Bạn có thể làm mọi điều khó khăn trong Puppet Enterprise. Vì vậy, nếu bạn đã định cấu hình nó trên một máy chủ, sẽ mất thời gian để các thay đổi có hiệu lực trên các máy chủ còn lại. Trong Ansible, tất cả các thay đổi đều có hiệu lực cùng một lúc.
Cuối cùng, hãy xem mô-đun bảo mật. Ansible Tower thực hiện nó một cách đơn giản đến kinh ngạc, với độ chính xác và sự cẩn thận cao độ. Bạn có thể cấp cho người dùng quyền truy cập vào các dịch vụ cụ thể hoặc các máy chủ cụ thể. Tôi làm điều này với những nhân viên đã quen làm việc trên Windows, hạn chế quyền truy cập của họ vào shell Linux. Tôi đảm bảo rằng họ có quyền truy cập vào Tower để họ chỉ có thể thực hiện công việc và chỉ chạy các dịch vụ phù hợp với họ.
Hãy xem trước những điều bạn cần làm để giúp quá trình chuyển đổi sang Ansible Tower trở nên dễ dàng hơn. Trước hết, bạn cần chuẩn bị thiết bị của mình. Nếu một số thành phần cơ sở hạ tầng của bạn chưa có trong cơ sở dữ liệu, bạn cần thêm chúng vào đó. Có những hệ thống không thay đổi đặc điểm của chúng và do đó không có trong cơ sở dữ liệu Puppet, nhưng nếu bạn không thêm chúng vào đó trước khi chuyển sang Tower, bạn sẽ mất đi một số lợi thế. Đây có thể là một cơ sở dữ liệu sơ bộ “bẩn”, nhưng nó phải chứa thông tin về tất cả các thiết bị bạn có. Do đó, bạn nên viết một tập lệnh phần cứng động sẽ tự động đẩy tất cả các thay đổi về cơ sở hạ tầng vào cơ sở dữ liệu, khi đó Ansible sẽ biết máy chủ nào sẽ có trên hệ thống mới. Bạn sẽ không cần phải cho SCM này biết máy chủ nào bạn đã thêm và máy chủ nào không còn tồn tại vì nó sẽ tự động biết tất cả những điều này. Càng có nhiều dữ liệu trong cơ sở dữ liệu thì Ansible sẽ càng hữu ích và linh hoạt hơn. Nó hoạt động như thể nó chỉ đọc mã vạch trạng thái phần cứng từ cơ sở dữ liệu.
Dành chút thời gian làm quen với dòng lệnh trong Ansible. Chạy một số lệnh tùy chỉnh để kiểm tra tập lệnh phần cứng, viết và chạy một số tập lệnh playbook đơn giản nhưng hữu ích, sử dụng các mẫu Jinja2 khi thích hợp. Hãy thử viết vai trò và tập lệnh cho một quy trình phức tạp gồm nhiều bước bằng cách sử dụng cấu hình phần cứng phổ biến, thường gặp. Chơi với những thứ này, kiểm tra xem nó hoạt động như thế nào. Bằng cách này, bạn sẽ học cách sử dụng các công cụ tạo thư viện được sử dụng trong Tower. Tôi đã nói rằng tôi mất khoảng 3 tháng để chuẩn bị cho quá trình chuyển đổi. Tôi nghĩ rằng dựa trên kinh nghiệm của tôi, bạn sẽ có thể làm điều này nhanh hơn. Đừng coi thời gian này là lãng phí, vì sau này bạn sẽ trải nghiệm được tất cả lợi ích của công việc đã làm.
Tiếp theo, bạn cần quyết định những gì bạn mong đợi từ Ansible Tower, chính xác thì hệ thống này sẽ làm gì cho bạn.
Bạn có cần triển khai hệ thống trên phần cứng trần, trên máy ảo trần không? Hay bạn muốn duy trì các điều kiện hoạt động và cài đặt ban đầu của thiết bị hiện có? Đây là một khía cạnh rất quan trọng đối với các công ty đại chúng, vì vậy bạn cần chắc chắn rằng bạn sẽ có thể di chuyển và triển khai Ansible trên cấu hình hiện có của mình. Xác định các quy trình quản trị thông thường mà bạn muốn tự động hóa. Tìm hiểu xem bạn có cần triển khai các ứng dụng và dịch vụ cụ thể trên hệ thống mới hay không. Lập danh sách những việc bạn muốn làm và ưu tiên thực hiện nó.
Sau đó, bắt đầu viết mã tập lệnh và các vai trò sẽ hỗ trợ các nhiệm vụ bạn dự định hoàn thành. Kết hợp chúng thành Dự án, một bộ sưu tập hợp lý các cẩm nang có liên quan. Mỗi Dự án sẽ thuộc về một kho Git riêng hoặc một kho lưu trữ khác tùy thuộc vào trình quản lý mã bạn sử dụng. Bạn có thể quản lý tập lệnh playbook và thư mục playbook bằng cách đặt chúng theo cách thủ công trong Đường dẫn cơ sở dự án trên máy chủ Tower hoặc bằng cách đặt playbook vào bất kỳ hệ thống quản lý mã nguồn (SCM) nào được Tower hỗ trợ, bao gồm Git, Subversion, Mercurial và Red Hat Thông tin chi tiết. Trong một Dự án, bạn có thể đặt bao nhiêu tập lệnh tùy thích. Ví dụ: tôi đã tạo một Dự án cơ bản trong đó tôi đặt tập lệnh cho các thành phần cốt lõi của RedHat, tập lệnh cho lõi Linux và tập lệnh cho phần còn lại của đường cơ sở. Do đó, trong một dự án có nhiều vai trò và kịch bản khác nhau được quản lý từ một kho Git.
Chạy tất cả những thứ này thông qua dòng lệnh là một cách hay để kiểm tra chức năng của chúng. Điều này sẽ giúp bạn chuẩn bị cho việc cài đặt Tháp.
Hãy nói một chút về việc chuyển mã tệp kê khai Puppet, vì tôi đã dành rất nhiều thời gian cho việc này cho đến khi tôi tìm ra những gì thực sự cần phải làm.
Như tôi đã nói trước đây, Puppet lưu trữ tất cả các cài đặt và tùy chọn phần cứng trong một bảng kê khai dài và bảng kê khai này lưu trữ mọi thứ mà SCM này nên làm. Khi thực hiện chuyển đổi, bạn không cần phải nhồi nhét tất cả nhiệm vụ của mình vào một danh sách; thay vào đó, hãy nghĩ về cấu trúc của hệ thống mới: vai trò, tập lệnh, thẻ, nhóm và những gì nên có trong đó. Một số thành phần mạng tự trị nên được nhóm thành các nhóm để có thể tạo tập lệnh. Các thành phần cơ sở hạ tầng phức tạp hơn liên quan đến một số lượng lớn tài nguyên, bao gồm các lớp độc lập, có thể được kết hợp thành các vai trò. Trước khi di chuyển, bạn cần phải quyết định về điều này. Nếu bạn đang tạo các vai trò hoặc kịch bản lớn không vừa trên một màn hình, bạn nên sử dụng thẻ để có thể nắm bắt các phần cụ thể của cơ sở hạ tầng.
18:00
Một số quảng cáo 🙂
Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, , một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).
Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com