kitchen.yml

[править на GitHub]

Используйте Test Kitchen, чтобы автоматически тестировать данные кулинарных книг на любых комбинациях платформ и наборов тестов:

• Определяются в файле kitchen.yml
• Используют архитектуру плагинов драйверов
• Поддерживают тестирование кулинарных книг на многих облачных провайдерах и технологиях виртуализации
• Поддерживают все распространённые фреймворки тестирования, используемые сообществом Ruby
• Используют комплексный набор базовых образов, предоставленных Bento

Используйте файл kitchen.yml для определения того, что необходимо для запуска Test Kitchen, включая драйверы, провайдеры, платформы и наборы тестов.

Синтаксис

Базовая структура файла kitchen.yml:

driver:name:driver_nameprovisioner:name:provisioner_nameverifier:name:verifier_nametransport:name:transport_nameplatforms:- name:platform-versiondriver:name:driver_name- name:platform-versionsuites:- name:suite_namerun_list:- recipe[cookbook_name::recipe_name]attributes:{foo:"bar"}excludes:- platform-version- name:suite_namedriver:name:driver_namerun_list:- recipe[cookbook_name::recipe_name]attributes:{foo:"bar"}includes:- platform-version

где:

• driver_name — имя драйвера, который будет использоваться для создания экземпляров платформ, используемых при тестировании кулинарных книг. Это драйвер по умолчанию для всех платформ и наборов тестов кроме случаев, когда платформа или набор тестов явно указывают driver, чтобы переопределить драйвер по умолчанию для этой платформы или набора; драйвер, указанный для набора, переопределяет драйвер, заданный для платформы

• provisioner_name — способ моделирования Chef Infra Client во время тестирования. chef_zero и chef_solo — наиболее распространённые провайдеры, используемые для тестирования кулинарных книг

• verifier_name — указывает, какое приложение использовать при запуске тестов, например, inspec

• transport_name — указывает транспорт для выполнения команд удалённо на тестовом экземпляре. winrm — транспорт по умолчанию для Windows. Транспорт ssh — по умолчанию для всех остальных операционных систем.

• platform-version — имя платформы, на которой Test Kitchen будет выполнять тестирование кулинарных книг, например, ubuntu-20.04 или centos-7; в зависимости от платформы могут потребоваться дополнительные сведения о драйвере, например, имена экземпляров и URL-адреса, используемые с облачными платформами, такими как OpenStack или Amazon EC2

• platforms может определять атрибуты Chef Infra Server, общие для набора наборов тестов

• suites — набор наборов тестов, при этом каждый suite_name определяет аспект кулинарной книги, который необходимо протестировать. Каждый suite_name должен указать список для выполнения, например:

  run_list:
    - recipe[cookbook_name::default]
    - recipe[cookbook_name::recipe_name]
  

• Каждый suite_name блок может указывать attributes как хеш: { foo: "bar" }

• Блок suite_name может использовать excludes и includes для исключения/включения одной (или нескольких) платформ. Например:

  excludes:
     - platform-version
     - platform-version       # for additional platforms
  

Пример простого файла kitchen.yml:

driver:name:vagrantprovisioner:name:chef_zeroplatforms:- name:ubuntu-20.04- name:centos-8- name:debian-10suites:- name:defaultrun_list:- recipe[apache::httpd]excludes:- debian-10

Этот файл использует HashiCorp Vagrant в качестве драйвера, для которого не требуется дополнительная настройка, поскольку это драйвер по умолчанию, используемый Test Kitchen, chef-zero в качестве провайдера и единственный (по умолчанию) набор тестов, который выполняется на Ubuntu 20.04 и CentOS 7.

Настройки провайдеров

Test Kitchen может настроить провайдер chef-zero с помощью следующих установок, специфичных для Chef:

client_rb:
log_level: :warn

Эти настройки можно добавить в раздел provisioner файла kitchen.yml при использовании провайдера chef-zero или chef-solo.

Новые настройки провайдера

Настройки транспорта

Kitchen может настроить транспорт с помощью следующих настроек для перевозок ssh или winrm.

Эти настройки могут быть добавлены в раздел transport файла kitchen.yml, когда транспорт — SSH:

Эти настройки могут быть добавлены в раздел transport файла kitchen.yml, когда транспорт — WinRM:

Работа с прокси

Переменные окружения http_proxy, https_proxy, и ftp_proxy учитываются Test Kitchen для прокси. Файл client.rb считывается для поиска настроек конфигурации прокси. Если http_proxy, ftp_proxy, и ftp_proxy указаны в файле client.rb, Chef Infra Client сконфигурирует переменную ENV на основе этих (и связанных) настроек. Например:

http_proxy 'http://proxy.example.org:8080'
http_proxy_user 'myself'
http_proxy_pass 'Password1'

будет установлено:

ENV['http_proxy'] = 'http://myself:Password1@proxy.example.org:8080'

Test Kitchen также поддерживает http_proxy и https_proxy в файле kitchen.yml. Вы можете установить их вручную или прочитать из переменных среды:

driver:name:vagrantprovisioner:name:chef_zero# Set proxy settings manually, orhttp_proxy:'http://user:password@server:port'https_proxy:'http://user:password@server:port'# Read from local environment variableshttp_proxy:<%= ENV['http_proxy'] %>https_proxy:<%= ENV['https_proxy'] %>

Это не установит переменные среды прокси для приложений, отличных от Chef. Плагин Vagrant vagrant-proxyconf можно использовать для установки переменных среды прокси для приложений внутри виртуальной машины.

Настройки Chef Infra Client

Файл kitchen.yml может определять настройки, специфичные для Chef Infra Client, такие как необходимость установки установщика Chef или URL, с которого скачивается Chef Infra Client, или переопределение настроек в файле client.rb:

provisioner:name:chef_zero *or* chef_solorequire_chef_omnibus:truechef_omnibus_url:https://www.chef.io/chef/install.sh...suites:- name:configrun_list:...attributes:chef_client:load_gems:chef-handler-updated-resources:require_name:"chef/handler/updated_resources"config:log_level:":debug"ssl_verify_mode:":verify_peer"start_handlers:[{class:"SimpleReport::UpdatedResources", arguments:[]}]report_handlers:[{class:"SimpleReport::UpdatedResources", arguments:[]}]exception_handlers:[{class:"SimpleReport::UpdatedResources", arguments:[]}]ohai:disabled_plugins:["passwd"]

где:

• require_chef_omnibus используется для обеспечения того, что установщик Chef будет использован для установки Chef Infra Client на все экземпляры платформ; require_chef_omnibus также может быть установлено в latest, что означает, что для тестирования кулинарной книги будет использована самая последняя версия Chef Infra Client для данной платформы
• chef_omnibus_url используется для указания URL, с которого скачивается Chef Infra Client
• Все attributes для набора тестов config содержат специфические настройки client.rb для использования с этим набором тестов

Настройки драйвера

Могут потребоваться настройки конфигурации, специфичные для драйвера. Используйте блок, аналогичный:

driver:name:driver_nameoptional_settings:values

Можно указать специфические optional_settings: values.

Bento

Bento — проект Chef Software, который создаёт базовые тестовые виртуальные машины VirtualBox, Parallels и VMware для нескольких операционных систем для использования с Test Kitchen. По умолчанию Test Kitchen использует базовые образы, предоставляемые Bento, хотя могут быть созданы и пользовательские образы с помощью HashiCorp Packer.

Драйверы

Test Kitchen использует архитектуру плагинов драйверов, чтобы Test Kitchen мог тестировать экземпляры на провайдерах облачных сервисов, таких как Amazon EC2, Google Compute Engine и Microsoft Azure. Вы также можете тестировать на нескольких локальных гипервизорах, таких как VMware, Hyper-V или VirtualBox.

У большинства драйверов есть настройки конфигурации, специфичные для драйвера, которые необходимо добавить в файл kitchen.yml, прежде чем Test Kitchen сможет использовать эту платформу при тестировании кулинарных книг. Сведения об этих настройках, специфичных для драйвера, можно найти в соответствующей документации.

Некоторые популярные драйверы:

kitchen-vagrant

Драйвер kitchen-vagrant для Kitchen генерирует один Vagrantfile для каждого экземпляра Kitchen в изолированной директории. Драйвер kitchen-vagrant поддерживает VirtualBox и VMware Fusion, требует Vagrant 1.1.0 (или выше) и является драйвером по умолчанию для Test Kitchen.

Ниже приведены атрибуты, используемые для настройки kitchen-vagrant для Chef:

Драйвер kitchen-vagrant может предсказывать имя бокса для Vagrant и URL для скачивания, опубликованные Chef. Например:

platforms:
- name: ubuntu-18.04
- name: ubuntu-20.04
- name: centos-7
- name: centos-8
- name: debian-10

что сгенерирует конфигурационный файл, похожий на:

platforms:
- name: ubuntu-18.04
  driver:
    box: bento/ubuntu-18.04
- name: ubuntu-20.04
  driver:
    box: bento/ubuntu-20.04
# ...

Примеры

В следующих примерах показаны фактические файлы kitchen.yml, используемые в поддерживаемых Chef кулинарных книгах.

Chef, Chef Workstation

Следующий пример демонстрирует настройки провайдера, необходимые для установки Chef Workstation и использования версии Chef, встроенной в Chef Workstation, для схождения узла.

Для установки последней версии Chef Workstation:

provisioner:...chef_omnibus_install_options:-P chef-workstationchef_omnibus_root:/opt/chef-workstation

а для установки определенной версии Chef Workstation:

provisioner:...chef_omnibus_install_options:-P chef-workstationchef_omnibus_root:/opt/chef-workstationrequire_chef_omnibus:0.9

Платформа Microsoft Windows

Следующий пример демонстрирует настройки платформы для платформы Microsoft Windows:

platforms:- name:eval-win2012r2-standardos_type:windowstransport:name:winrmelevated:true

Если name начинается с win, то значения по умолчанию os_type устанавливаются в windows. Транспорт winrm является стандартным для операционных систем Windows. Здесь elevated равно true, что выполняет команды Windows через запланированную задачу для имитации локального пользователя.

Кулинарная книга Chef Infra Client

Следующий файл kitchen.yml является частью кулинарной книги chef-client и гарантирует правильную настройку Chef Infra Client.

driver:name:vagrantprovisioner:name:chef_zeroplatforms:- name:centos-8- name:fedora-latest- name:ubuntu-1804- name:ubuntu-2004suites:- name:service_initrun_list:- recipe[minitest-handler]- recipe[chef-client::config]- recipe[chef-client_test::service_init]- recipe[chef-client::init_service]attributes:{}- name:service_runitrun_list:- recipe[minitest-handler]- recipe[runit]- recipe[chef-client_test::service_runit]- recipe[chef-client::runit_service]attributes:{}- name:service_upstartrun_list:- recipe[minitest-handler]- recipe[chef-client_test::service_upstart]- recipe[chef-client::upstart_service]excludes:["centos-5.9"]attributes:{}- name:cronrun_list:- recipe[minitest-handler]- recipe[chef-client::cron]attributes:{}- name:delete_validationrun_list:- recipe[chef-client::delete_validation]attributes:{}

Кулинарная книга chef-splunk

Следующий файл kitchen.yml является частью кулинарной книги chef-splunk и используется для обеспечения правильной установки клиента и сервера Splunk.

driver:name:vagrantcustomize:memory:1024provisioner:name:chef_zeroplatforms:- name:ubuntu-18.04- name:ubuntu-20.04- name:centos-7- name:centos-8suites:- name:clientrun_list:- recipe[chef-splunk::default]- recipe[test::default]attributes:dev_mode:truesplunk:accept_license:true- name:serverrun_list:- recipe[chef-splunk::default]attributes:dev_mode:truesplunk:is_server:trueaccept_license:truessl_options:enable_ssl:true

Кулинарная книга yum

Следующий файл kitchen.yml является частью кулинарной книги yum.

driver:name:vagrantprovisioner:name:chef_zeroplatforms:- name:centos-7- name:centos-8- name:fedora-latestsuites:- name:defaultrun_list:- recipe[yum::default]- recipe[yum_test::test_repo]

Атрибуты платформы

Следующий файл kitchen.yml настраивает простую многоуровневую конфигурацию сервера Chef, включая два сервера front-end, один сервер back-end и два плагина (Chef Push Jobs и консоль управления Chef). Блок platforms использует раздел attributes для определения атрибутов, специфичных для сервера Chef, которые используются всеми тремя наборами тестов:

driver:name:vagrantprovisioner:name:chef_zeroplatforms:- name:ubuntu-18.04attributes:chef-server:api_fqdn:backend.chef-server.combackend:fqdn:backend.chef-server.comipaddress:123.456.789.0frontends:frontend1.chef-server.com:123.456.789.0frontend2.chef-server.com:123.456.789.0urls:private_chef:http://123.456.789.0/path/to/private-chef_11.1.4-1_amd64.debmanage:http://123.456.789.0/path/to/opscode-manage_1.3.1-1_amd64.debpush_jobs:http://123.456.789.0/path/to/opscode-push-jobs-server_1.1.1-1_amd64.debsuites:- name:frontend1driver:vm_hostname:frontend1.chef-server.comnetwork:- ["private_network",{ip:"123.456.789.0"}]customize:memory:2048cpus:2run_list:- recipe[chef-server::configfile]- recipe[chef-server::ntp]- recipe[chef-server::server]- recipe[chef-server::frontend]- name:frontend2driver:vm_hostname:frontend2.chef-server.comnetwork:- ["private_network",{ip:"123.456.789.0"}]customize:memory:2048cpus:2run_list:- recipe[chef-server::configfile]- recipe[chef-server::ntp]- recipe[chef-server::server]- recipe[chef-server::frontend]- name:backenddriver:vm_hostname:backend.chef-server.comnetwork:- ["private_network",{ip:"123.456.789.0"}]customize:memory:8192cpus:4run_list:- recipe[chef-server::configfile]- recipe[chef-server::ntp]- recipe[chef-server::server]- recipe[chef-server::backend]

Схождение Kitchen при перезагрузке системы

Test-Kitchen может обрабатывать перезагрузки (инициированные с помощью Chef Infra Client), устанавливая атрибуты retry_on_exit_code, max_retries и wait_for_retry в провайдере в файле kitchen.yml следующим образом:

provisioner:name:chef_zeroretry_on_exit_code:- 35# 35 is the exit code signaling that the node is rebooting- 1max_retries:1client_rb:exit_status::enabled# Opt-in to the standardized exit codesclient_fork:false# Forked instances don't return the real exit code

Примечание по узлам Linux: Команда shutdown блокирует выполнение (в отличие от Windows-варианта, который регистрирует перезагрузку и возвращает результат сразу), поэтому после истечения таймаута Chef Infra Client и узел находятся в гонке, чтобы увидеть, кто выйдет/перезагрузится первым — поэтому вы можете или не можете получить код выхода из узлов Linux. В этом случае можно добавить 1 в массив retry_on_exit_code — это должно уловить оба случая.

См. документацию YAML для установки атрибута retry_on_exit_code.