Статьи

Циклы подготовки, развертывания и настройки приложения

Январь 30, 2018

По моему мнению:

  • обеспечение должно осуществляться через «Инфраструктура как код»
  • Развертывание бинарных файлов приложений, как это принято понимать сегодня
  • Конфигурация приложения должна быть «Конфигурация как код»

Вот удобная диаграмма всего этого для одной гипотетической среды:

Прежде чем углубляться в детали, важно знать обоснование конвейерного мышления о непрерывной доставке.

Инфраструктура как код

Для неживых сред вы должны поддерживать сценарии чертежей под контролем исходного кода, которые могут создавать или воссоздавать целые среды с нуля. Это должно включать выделение виртуальных машин, установку необходимых пакетов (Apache, Tomcat, MySql, обратные прокси-серверы, балансировщики нагрузки), которые не поставляются с выбранной базовой ОС на виртуальной виртуальной машине. Все, что подразумевается под словом «платформа», возможно. Вы также запекли бы в подключении внутри ВМ — брандмауэры, DNS. Конфигурация пакетов также будет здесь. например, Apache’s httpd.conf.

Для производства у вас также были бы сценарии проекта, но на самом деле изменения в delta-esque только следовали рекомендациям CD. По крайней мере, однажды ты уже жив.

Рассматриваемый репозиторий с исходным кодом будет содержать только Инфраструктуру как Код. Возможно, одна ветвь на среду, а может и нет. Шаблон может тоже фигурировать:

my_provision QA3 --from templates/one_vm_fewest_processes.yaml

Иногда предприятия хотят портал самообслуживания для обеспечения. Я не уверен, что это необходимо, когда инструмент командной строки так же хорош в функциональном отношении.

Хотя Terraform новее и очень классный, коллеги Джефферсон Жирао, Дэвид МакХоулл и Делуан Квинтао разработали отличный проект с использованием Ansible девять месяцев назад .

Из репозитория Github этого проекта, пример проекта YAML для приложения «зоомагазин» (две виртуальные машины):

# This playbook deploys the whole application stack in this site.

- name: apply common configuration to all nodes
  hosts: all

  roles:
    - common

- name: configure and deploy the web-servers and application code
  hosts:
    - www.petshop.example.com

  roles:
    - ruby19
    - passenger
    - nginx

- name: deploy MySQL and configure the databases
  hosts:
    - db.petshop.example.com

  roles:
    - mysql

Двоичные приложения

У вас могут быть среды, Jenkins01в Jenkins10которых Jenkins-CI развертывается в per-commit непосредственно перед тем, как он входит в фазы Selenium «полного стека» конвейера сборки. Люди не идут в это. Некоторые группы в цикле непрерывной интеграции, возможно, захотят предоставить свежие временные среды для каждого развертывания и фазы тестирования Selenium, но я считаю, что вам это не нужно — их можно повторно использовать в этом контексте.

Регулярные развертывания в QA1, QA2 или UAT будут осуществляться одним нажатием кнопки в Jenkins. По крайней мере, после выбора бинарного (скажем rel-1.1-build-12345) и окружения. В дополнение к простому приложению — версии приложения XXX Nn в среде YYY — наличие эквивалента командной строки порадует более технических членов команды разработчиков. Некоторые компании захотят использовать портал для развертываний вместо дешевой реализации Jenkins. Наименьшее количество вариантов на этом портале — «Разрешено ли (повторное) развертывание?», «Какая версия какого приложения?» И «куда?» будет минимальным контролем на портале развертывания.

Вы можете иметь автоматическое развертывание в стиле CD в среде QA. Только если повторное развертывание временно не делает среду пригодной для использования. Если нестабильность при развертывании действительно имеет место, то, возможно, передислокации происходят только в согласованное время. CD, для самых продвинутых команд, конечно же, означает развертывание в производство.

Двоичные файлы приложения могут возникать только в тех средах, которые были правильно настроены. Это означает, что инфраструктура как код уже произошла, если это не было очевидно. Если подготовка среды и двоичные развертывания приложений произошли без конфигурации (см. Ниже), то среда НЕ пригодна для использования на этом этапе.

Какие биты этого находятся под контролем источника?

Наряду с обычными сценариями сборки, я хотел бы увидеть полное определение конвейера CI. CruiseControl раньше делал это , и я бы предпочел, чтобы такие же, как Дженкинс, тоже делали это (как я однажды сказал Kohsuke Kawaguchi — создателю Jenkins). Продукты билдов — сами двоичные файлы приложений? Многие предприятия должны помещать двоичные файлы в защищенный от несанкционированного доступа репозиторий (а не в систему контроля версий) и извлекать их оттуда для развертывания. Некоторые высокоуровневые CD-команды не собираются этим заниматься. Вместо этого они развернутся в конце цикла сборки / тестирования и отбросят двоичные файлы.

Конфигурация как код

Проблема: вы хотите, чтобы эта конфигурация приложения оставалась в среде даже после повторного развертывания двоичных файлов. Какой лучший способ сделать это?

Установленное приложение может получать конфигурацию, так как оно изменяется ортогонально. Это может быть двоичное переключение, если вы выполняете темное развертывание, или может отключить некритические части приложения, чтобы повысить производительность (или противостоять атаке). Это также может быть более рассмотрены настройки (JSON):

first_line_support: {
	cell: "415 867 5309", 
	name: "Jenny"
}

Если вы выполняли балансировку нагрузки с плохой рабочей нагрузкой в ​​стеке, вы могли бы также закодировать информацию о конечной точке в этой категории конфигурации (JSON):

zipcode_service: [
	{
		name: "zipcodez.qa2.sandwichcorp.com",
		port: 33452,
		state: "active"
	}, {
		name: "zipcodez02.qa2.sandwichcorp.com",
		port: 11233
		state: "active"		
	}, {
		name: "zipcodez.qa2.sandwichcorp.com",
		port: 44444
		state: "suspended"		
	}
]

Вы хотите, чтобы этот материал находился под контролем исходного кода (снова разделите репо). Концепция сред подразумевает дисперсию конфигурации приложения, а также двоичную дисперсию. Таким образом, вы захотите использовать одну ветвь для каждой среды (может быть, не все JenkinsXXиз них). Это позволит вам объединять ключи и / или значения между средами, если это необходимо. Высококвалифицированные команды CD заставят новые ключи действовать доброжелательно в системе, которая их не понимает, поэтому они могут начать работу с опережением графика. Вы можете продвигать изменения как в наборе, так и индивидуально (вишня).

Примечание: Zookeeper и Etcd решают одну и ту же проблему, но я не буду чувствовать себя комфортно, если контроль за исходным кодом не является базовой системой, и обратно.

Что еще нужно в конфигурации приложения?

Редактирование конфигурации через приложение администратора определенно необходимо. Логан МакГрат ранее написал для меня целое приложение-конфигурацию: конфигурация приложения с поддержкой SCM с Perforce и App-Config-App в действии (видео об использовании) и продвижение изменений с помощью App-Config-App . Вы не только хотите, чтобы приложение администратора / редактирование, вы хотите, чтобы работало редактирование в обоих направлениях, таким образом, чтобы опытный инженер мог проверить ветку config в командной строке, отредактировать в Vim и зафиксировать / отодвинуть, чтобы вызвать переиздание конфига.

Чем еще может быть App Config?

Конфигурация взаимодействия партнера и стороннего поставщика, будь то один, два партнера или десятки тысяч. Профессиональные службы могут поддерживать каждый из них и желать, чтобы циклы запуска были отделены от бинарных выпусков, и это именно то, что облегчает конфигурация как код.

Управление контентом также приходит на ум. Ветви Source-Control могут быть местами, которые позволяют координировать изменения «контента» и где они каким-либо образом одобрены до окончательного продвижения (слияния) в производство. Также помогает Diffing, как во время скоординированной переработки контента, так и в конце перед продвижением, чтобы жить (как последний этап проверки).

Контраст трех жизненных циклов.

Infra as Code и двоичные развертывания приложений, безусловно, являются частью традиционного конвейерного представления. Хотя жизненного цикла Config as Code нет. Это ортогонально этому, но жизненно важно для согласованности приложения.

Первые два встроены в систему контроля версий разработчиками и экспертами Devops. Config as Code — это часть более тонкого ориентированного на человека управления в направлении готовности к производству. Многие не разработчики будут вовлечены в получение правильной конфигурации. Возможно, они сделают это в веб-приложении, созданном для поддержки конфигурации (мы использовали AngularJS для дешевой реализации необходимых проверок для доказательства концепции Logan, которую я построил). Контроль над исходным кодом дает вам безопасность — отслеживайте, что изменилось, когда оно изменилось, кто его изменил, и правильно ли это изменило войну. Действительно (вернитесь в командную строку, используйте некоторые жесткие инструменты для отмены выбранных изменений).

дальнейшее чтение

Конечно, я перефразирую предыдущие мысли и фотографии: см. Раздел «Архитектура приложения» в «Эре компакт-дисков» для команд Pro-Services и различные статьи из моего блога « Конфигурация как код» .

Коллега Киф Моррис (который также помог мне правильно сформулировать свое сообщение в этой статье) опубликовал основополагающую статью Automated Server Management Lifecycle много лет назад.

42
Share: