GALAXY TECH
Chuyên gia Công nghệ
Thứ ba, 04/02/2014 | 00:00 GMT+7

cách sử dụng role và môi trường trong Chef để kiểm soát cấu hình server

Khi bạn xây dựng cơ sở hạ tầng của bạn , việc quản lý nhiều server , dịch vụ, user và ứng dụng của bạn có thể trở nên khó sử dụng rất nhanh chóng. Hệ thống quản lý cấu hình được dùng để giúp bạn quản lý sự nhầm lẫn này.

Chef là một hệ thống quản lý cấu hình tuyệt vời có thể cho phép bạn cấu hình các thành phần khác nhau của hệ thống tổng thể một cách rất dễ dàng. Trong các hướng dẫn trước, ta đã thảo luận về thuật ngữ Chef , cách cài đặt server Chef, máy trạm và nút (với Chef 12 hoặc Chef 11 ) và cách tạo sách nấu ăn đơn giản để quản lý cấu hình .

Trong hướng dẫn này, ta sẽ tiếp tục khám phá cách bạn có thể quản lý môi trường của bạn với Chef. Lần này, ta sẽ nói về cách sử dụng các role và môi trường để phân biệt các server và dịch vụ của bạn dựa trên loại chức năng mà chúng nên thể hiện.

Ta sẽ giả định bạn đã cài đặt server , máy trạm và ứng dụng client của bạn và bạn có các sách dạy nấu ăn mà ta đã tạo trong hướng dẫn cuối cùng của ta .

Role và Môi trường

Role là gì?

Trong tổ chức của bạn, nếu cơ sở hạ tầng của bạn phát triển để đáp ứng nhu cầu của lưu lượng truy cập cao hơn, có thể sẽ có nhiều server dự phòng, tất cả đều thực hiện các việc cơ bản giống nhau. Ví dụ: đây có thể là các web server mà bộ cân bằng tải chuyển các yêu cầu đến. Tất cả chúng sẽ có cùng một cấu hình cơ bản và có thể nói rằng chúng đều đáp ứng “ role ” giống nhau.

Quan điểm về role của đầu bếp gần như hoàn toàn giống với định nghĩa thông thường. Role trong Chef là một phân loại mô tả những gì một máy cụ thể phải làm . Nó có những trách nhiệm gì và phần mềm và cài đặt nào nên được cung cấp cho nó.

Trong các tình huống khác nhau, bạn có thể có một số máy xử lý nhiều hơn một role . Ví dụ: nếu bạn đang kiểm tra phần mềm của bạn , một server có thể bao gồm database và các thành phần web server , trong khi đang production , bạn có kế hoạch đặt chúng trên các server riêng biệt.

Với Chef, điều này có thể dễ dàng như gán server đầu tiên cho cả hai role và sau đó chỉ định từng role cho các máy tính riêng biệt cho các máy production của bạn. Mỗi role sẽ chứa các chi tiết cấu hình cần thiết để đưa máy về trạng thái hoạt động hoàn toàn để thực hiện role cụ thể của nó. Điều này nghĩa là bạn có thể thu thập các sách dạy nấu ăn sẽ xử lý cài đặt gói, cấu hình dịch vụ, các thuộc tính đặc biệt cho role đó, v.v.

Môi trường là gì?

Liên quan đến ý tưởng về một role là khái niệm về môi trường Chef. Môi trường chỉ đơn giản là một ký hiệu nhằm giúp administrator biết server là một phần của quá trình production . Mỗi server có thể là một phần của chính xác một môi trường.

Theo mặc định, một môi trường có tên “_default” được tạo. Mỗi nút sẽ được đặt vào môi trường này trừ khi môi trường khác được chỉ định. Có thể tạo môi trường để gắn thẻ server như một phần của group quy trình.

Ví dụ, một môi trường có thể được gọi là “thử nghiệm” và môi trường khác có thể được gọi là “sản xuất”. Vì bạn không muốn bất kỳ mã nào vẫn đang được thử nghiệm trên máy production của bạn , nên mỗi máy chỉ có thể ở trong một môi trường.Sau đó, bạn có thể có một cấu hình cho các máy trong môi trường thử nghiệm của bạn và một cấu hình hoàn toàn khác cho máy tính đang production .

Trong ví dụ trên được đưa ra về các role , bạn có thể chỉ định rằng trong môi trường thử nghiệm của bạn , các role server database và web sẽ nằm trên một máy duy nhất. Trong môi trường production của bạn, những role này nên được giải quyết bởi các server riêng lẻ.

Môi trường cũng trợ giúp cho chính quá trình thử nghiệm. Bạn có thể chỉ định rằng trong quá trình production , sách dạy nấu ăn phải là version ổn định. Tuy nhiên, bạn có thể chỉ định rằng nếu một máy là một phần của môi trường thử nghiệm, thì nó có thể nhận được version mới hơn của sách nấu ăn.

Cách sử dụng role

Tạo một role bằng Ruby DSL

Ta có thể tạo các role bằng cách sử dụng folder roles trong folder chef-repo trên máy trạm của ta .

Đăng nhập vào máy trạm của bạn và chuyển vào folder này ngay bây giờ:

cd ~/chef-repo/roles

Trong folder này, ta có thể tạo các file khác nhau xác định role mà ta muốn trong tổ chức của bạn . Mỗi file role có thể được viết trong Chef's Ruby DSL hoặc trong JSON.

Hãy tạo một role cho web server của ta :

nano web_server.rb

Bên trong file này, ta có thể bắt đầu bằng cách chỉ định một số dữ liệu cơ bản về role :

name "web_server" description "A role to configure our front-line web servers"

Những điều này sẽ khá thẳng về phía trước. Tên mà ta cung cấp không được chứa khoảng trắng và thường phải trùng với tên file ta đã chọn cho role này, trừ phần mở rộng. Mô tả chỉ là một thông điệp mà con người có thể đọc được về những gì role phải quản lý.

Tiếp theo, ta có thể chỉ định danh sách chạy mà ta muốn sử dụng cho role cụ thể này. Danh sách chạy của một role có thể chứa sách nấu ăn (sẽ chạy công thức mặc định), công thức nấu ăn từ sách nấu ăn (như được chỉ định bằng cách sử dụng cú pháp sách nấu ăn :: công thức) và các role khác. Lưu ý run_list luôn được thực thi tuần tự, vì vậy hãy đặt các mục phụ thuộc trước các mục khác.

Nếu ta muốn chỉ định rằng run_list phải chính xác như những gì ta đã cấu hình trong hướng dẫn cuối cùng, ta sẽ có một cái gì đó giống như sau:

name "web_server" description "A role to configure our front-line web servers" run_list "recipe[apt]", "recipe[nginx]"

Ta cũng có thể sử dụng run_lists dành riêng cho môi trường để chỉ định các thay đổi cấu hình tùy thuộc vào môi trường mà server thuộc về.

Ví dụ: nếu một nút ở trong môi trường “sản xuất”, bạn có thể cần chạy một công thức đặc biệt trong sách dạy nấu ăn “nginx” của bạn để đưa server đó đáp ứng các yêu cầu của policy production . Bạn cũng có thể có một công thức trong sách nấu ăn nginx dùng để cấu hình các thay đổi đặc biệt cho các server thử nghiệm.

Giả sử rằng hai công thức này được gọi là “config prod” và “config test”, ta có thể tạo một số danh sách chạy theo môi trường cụ thể như sau:

name "web_server" description "A role to configure our front-line web servers" run_list "recipe[apt]", "recipe[nginx]" env_run_lists "production" => ["recipe[nginx::config_prod]"], "testing" => ["recipe[nginx::config_test]"]

Trong ví dụ trên, ta đã chỉ định rằng nếu nút là một phần của môi trường production , thì nó sẽ chạy công thức “config prod” trong sách dạy nấu ăn “nginx”. Tuy nhiên, nếu nút đang ở trong môi trường thử nghiệm, nó sẽ chạy công thức "kiểm tra cấu hình ". Nếu một nút ở trong một môi trường khác, thì run_list mặc định sẽ được áp dụng.

Tương tự, ta có thể chỉ định các thuộc tính mặc định và overrides . Bạn nên làm quen với các thuộc tính mặc định tại thời điểm này. Với role của bạn , ta có thể đặt các thuộc tính mặc định có thể overrides bất kỳ thuộc tính mặc định nào được đặt ở bất kỳ nơi nào khác.

Ta cũng có thể đặt các thuộc tính overrides , các thuộc tính này có mức độ ưu tiên cao hơn so với nhiều khai báo thuộc tính khác. Ta có thể sử dụng điều này để cố gắng buộc các node được gán role này hoạt động theo một cách nhất định.

Trong file của ta , những thứ này có thể được thêm vào như sau:

name "web_server" description "A role to configure our front-line web servers" run_list "recipe[apt]", "recipe[nginx]" env_run_lists "production" => ["recipe[nginx::config_prod]"], "testing" => ["recipe[nginx::config_test]"] default_attributes "nginx" => { "log_location" => "/var/log/nginx.log" } override_attributes "nginx" => { "gzip" => "on" }

Ở đây ta đã đặt vị trí log mặc định cho bất kỳ server nào trong nút. Ta cũng đã chỉ rõ rằng bất chấp những gì một số khai báo thuộc tính khác đã nêu ở các vị trí khác, các node trong role này phải đặt thuộc tính gzip thành “bật”. Điều này có thể được overrides ở một số nơi khác, nhưng nói chung là một khai báo có mức độ ưu tiên cao.

Tạo role bằng JSON

Định dạng khác mà bạn có thể sử dụng để cấu hình role là JSON. Trên thực tế, ta có thể khám phá định dạng này bằng cách sử dụng dao để tự động tạo một role trong định dạng này. Hãy tạo một role thử nghiệm:

knife role create test

Trình soạn thảo văn bản của bạn sẽ được mở với file role mẫu được tải trước. Nó trông giống như sau :

{   "name": "test",   "description": "",   "json_class": "Chef::Role",   "default_attributes": {   },   "override_attributes": {   },   "chef_type": "role",   "run_list": [    ],   "env_run_lists": {   } }

Về cơ bản, đây là thông tin mà ta đã nhập vào file có định dạng DSL của Ruby. Sự khác biệt duy nhất là định dạng và bổ sung hai khóa mới gọi là json_class và chef_type . Chúng được sử dụng trong nội bộ và không được sửa đổi.

Ngoài ra, ta có thể dễ dàng tạo lại file khác của bạn trong JSON với những thứ như:

{   "name": "web_server",   "description": "A role to configure our front-line web servers",   "json_class": "Chef::Role",   "default_attributes": {     "nginx": {       "log_location": "/var/log/nginx.log"     }   },   "override_attributes": {     "nginx": {       "gzip": "on"     }   },   "chef_type": "role",   "run_list": [     "recipe[apt]",     "recipe[nginx]"   ],   "env_run_lists": {     "production": [       "recipe[nginx::config_prod]"     ],     "testing": [       "recipe[nginx::config_test]"     ]   } }

Điều này sẽ có khá nhiều chức năng giống như version Ruby ở trên.

Chuyển Role giữa Máy trạm và Server

Khi ta lưu file JSON được tạo bằng lệnh dao, role được tạo trên server Chef. Ngược lại, file Ruby của ta mà ta đã tạo local không được tải lên server .

Ta có thể tải file ruby lên server bằng cách chạy lệnh giống như sau:

<pre>
role dao từ file <span class = “highlight”> path / to / role / file </span>
</pre>

Thao tác này sẽ tải thông tin role được chỉ định trong file của ta lên server . Điều này sẽ hoạt động với file được định dạng Ruby DSL hoặc file JSON.

Theo cách tương tự, nếu ta muốn lấy file JSON của bạn từ server , ta có thể yêu cầu lệnh dao hiển thị file role đó trong JSON và sau đó chuyển file đó vào một file như sau:

<pre>
chương trình vai dao web_server -Fjson> <span class = “highlight”> path / to / save / to </span>
</pre>

Gán role cho các node

Vì vậy, bây giờ, dù định dạng ta đã sử dụng, ta có role của bạn trên server Chef. Làm thế nào để ta gán một nút một role nhất định?

Ta gán một role cho một nút giống như ta làm với một công thức, trong run_list của nút.

Vì vậy, để thêm role của ta vào một nút, ta sẽ tìm nút bằng cách phát hành:

knife node list

Và sau đó ta sẽ đưa ra một lệnh như:

<pre>
chỉnh sửa nút dao <span class = “highlight”> node_name </span>
</pre>

Thao tác này sẽ hiển thị file định nghĩa của nút, cho phép ta thêm role vào run_list của nó:

{   "name": "client1",   "chef_environment": "_default",   "normal": {     "tags": [      ]   },   "run_list": [     "recipe[nginx]"   ] }

Ví dụ: ta có thể thay thế công thức của bạn bằng role của ta trong file này:

<pre>
{
"Name": "client1",
" Môi trường đầu bếp ": " mặc định",
"Bình thường": {
“Thẻ”: [

]

},
" Danh sách chạy ": [
“<Span class =" highlight "> role [ server web ] </span>“
]
}
</pre>

Thao tác này sẽ thực hiện các bước tương tự như các công thức nấu ăn trước đây của ta , nhưng thay vào đó, nó chỉ đơn giản nói lên role của server .

Điều này cho phép bạn truy cập tất cả các server trong một role cụ thể bằng cách tìm kiếm. Ví dụ: bạn có thể tìm kiếm tất cả các server database trong môi trường production của bạn bằng cách tìm kiếm một role và môi trường:

knife search "role:database_server AND chef_environment:prod" -a name

Thao tác này sẽ cung cấp cho bạn danh sách các node được cấu hình làm server database . Bạn có thể sử dụng nội bộ này trong sách dạy nấu ăn của bạn để cấu hình web server để tự động thêm tất cả các server database production vào group của nó để thực hiện các yêu cầu đọc từ đó.

Cách sử dụng môi trường

Tạo môi trường

Theo một số cách, các môi trường khá giống với các role . Chúng cũng được sử dụng để phân biệt các server khác nhau, nhưng thay vì phân biệt theo chức năng của server , các môi trường phân biệt theo giai đoạn phát triển của một máy.

Ta đã thảo luận một số điều này trước đó khi nói về role . Môi trường phù hợp nhất với vòng đời sản phẩm thực tế của bạn sẽ có ý nghĩa nhất. Nếu bạn chạy mã của bạn thông qua thử nghiệm, dàn dựng và production , bạn phải có môi trường để phù hợp.

Như với các role , ta có thể cài đặt các file định nghĩa trong Ruby DSL hoặc trong JSON.

Trong folder "chef-repo" trên máy trạm của ta , ta nên có một folder môi trường. Đây là nơi ta nên đặt các file môi trường của bạn .

cd ~/chef-repo/environments

Trong folder này, nếu ta định xác định một môi trường để phát triển, ta có thể tạo một file như sau:

nano development.rb 
name "development" description "The master development branch" cookbook_versions({     "nginx" => "<= 1.1.0",     "apt" => "= 0.0.1" }) override_attributes ({     "nginx" => {         "listen" => [ "80", "443" ]     },     "mysql" => {         "root_pass" => "root"     } })

Như bạn thấy , một trong những lợi thế chính của việc kết hợp các môi trường vào hệ thống của bạn là bạn có thể chỉ định các ràng buộc version cho sách nấu ăn và công thức nấu ăn được triển khai.

Ta cũng có thể sử dụng định dạng JSON. Công cụ dao có thể tạo mẫu của file môi trường bằng lệnh :

knife environment create development

Thao tác này sẽ mở editor của ta ( , bạn có thể đặt editor của bạn bằng export EDITOR=nano ) với file môi trường được tải trước với tên được điền vào.

Ta có thể tạo cùng một file bằng lệnh :

{   "name": "development",   "description": "The master development branch",   "cookbook_versions": {     "nginx": "<= 1.1.0",     "apt": "= 0.0.1"   },   "json_class": "Cheff:Environment",   "chef_type": "environment",   "default_attributes": {   },   "override_attributes": {     "nginx": {       "listen": [         "80",         "443"       ]     },     "mysql": {       "root_pass": "root"     }   } }

Tệp này phải có chức năng giống như file Ruby mà ta đã trình bày ở trên. Cũng như các file role JSON, các file JSON môi trường có hai phần thông tin bổ sung ( json_class và chef_type ) nên được để riêng.

Di chuyển file môi trường đến và đi từ server

Đến đây, nếu bạn sử dụng Ruby DSL, file của bạn nằm trên máy trạm và nếu bạn sử dụng JSON, file của bạn chỉ nằm trên server . Ta có thể dễ dàng di chuyển các file qua lại bằng dao.

Ta có thể tải file Ruby của bạn lên server Chef bằng lệnh :

knife environment from file ~/chef-repo/environments/development.rb

Đối với file JSON của ta , ta có thể lấy file môi trường ra khỏi server bằng lệnh thông tin như :

knife environment show development -Fjson > ~/chef-repo/environments/development.json

Thao tác này sẽ hiển thị file JSON từ server và chuyển kết quả vào file local trong folder con môi trường.

Đặt môi trường trong nút

Mỗi nút có thể nằm trong chính xác một môi trường. Ta có thể chỉ định môi trường của một nút bằng cách chỉnh sửa thông tin nút của nó.

Ví dụ: để chỉnh sửa một nút có tên là client1 , ta có thể nhập:

knife node edit client1

Thao tác này sẽ mở ra file có định dạng JSON với các tham số nút hiện tại:

{   "name": "client1",   "chef_environment": "_default",   "normal": {     "tags": [      ]   },   "run_list": [     "role[web_server]"   ] }

Như bạn thấy , đầu chef_environment được đặt thành _default ban đầu. Ta có thể chỉ cần sửa đổi giá trị đó để đưa nút vào một môi trường mới.

Khi bạn hoàn tất, hãy lưu file . Trong lần chạy đầu bếp-khách hàng tiếp theo trên nút, nó sẽ chọn các thuộc tính và ràng buộc version mới và tự sửa đổi để phù hợp với policy mới.

Kết luận

Bây giờ, bạn đã hiểu rõ về các cách khác nhau mà bạn có thể làm việc với các role và môi trường để củng cố trạng thái mà máy của bạn phải ở. Sử dụng các chiến lược phân loại này, bạn có thể bắt đầu quản lý cách Chef xử lý các server trong các ngữ cảnh khác nhau.

<div class = “author”> Bởi Justin Ellingwood </div>

Tags:

Các tin liên quan

Cách cài đặt Chef Server, Workstation và Client trên Phiên bản VPS Ubuntu
2014-01-30
Giới thiệu về Chuyển hướng I / O Linux
2014-01-23
Giới thiệu về Chuyển hướng I / O Linux
2014-01-23
Cách thiết lập server email Postfix với Dovecot: Dynamic Maildirs và LMTP
2013-12-17
Cách xem và cấu hình log Linux trên Ubuntu và Centos
2013-12-17
Cách cài đặt Linux Socket Monitor (LSM) trên CentOS 6.4
2013-11-26
Cách sử dụng ApacheBench để thực hiện kiểm tra tải trên VPS Arch Linux
2013-11-21
Cách thiết lập server VPN đa giao thức bằng SoftEther
2013-11-19
Cách thiết lập server e-mail Postfix với Dovecot
2013-11-14
Cách thiết lập WordPress với W3 Total Cache trên Lighttpd Server
2013-11-12