Что такое деплой: Deployer — удобный и гибкий деплой приложений / Хабр

rolling, recreate, blue/green, canary, dark (A/B-тестирование) / Блог компании Флант / Хабр

Прим. перев.: Этот обзорный материал от Weaveworks знакомит с наиболее популярными стратегиями выката приложений и рассказывает о возможности реализации наиболее продвинутых из них с помощью Kubernetes-оператора Flagger. Он написан простым языком и содержит наглядные схемы, позволяющие разобраться в вопросе даже начинающим инженерам.

Схема взята из другого обзора стратегий выката, сделанного в Container Solutions

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

Более короткие и частые развертывания имеют следующие преимущества:

• Сокращается время выхода на рынок.
• Новые функции быстрее попадают к пользователям.
• Отклики пользователей быстрее доходят до команды разработчиков. Это означает, что команда может дополнять функции и исправлять проблемы более оперативно.
• Повышается моральный дух разработчиков: с большим количеством функций в разработке интереснее работать.

Но с увеличением частоты релизов также повышаются шансы негативно повлиять на надежность приложения или пользовательский опыт. Именно поэтому командам эксплуатации и DevOps важно строить процессы и управлять стратегиями развертывания таким образом, чтобы минимизировать риск для продукта и пользователей. (Узнать больше об автоматизации CI/CD-пайплайна можно здесь.)

В этой публикации мы обсудим различные стратегии деплоя в Kubernetes, в том числе rolling-развертывания и более продвинутые методы, такие как канареечные (canary) выкаты и их разновидности.

Стратегии деплоя

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

Rolling (постепенный, «накатываемый» деплой)

Это стандартная стратегия развертывания в Kubernetes. Она постепенно, один за другим, заменяет pod’ы со старой версией приложения на pod’ы с новой версией — без простоя кластера.

Kubernetes дожидается готовности новых pod’ов к работе (проверяя их с помощью readiness-тестов), прежде чем приступить к сворачиванию старых. Если возникает проблема, подобное накатываемое обновление можно прервать, не останавливая всего кластера. В YAML-файле с описанием типа deployment’а новый образ заменяет собой старый образ:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

Параметры накатываемого обновления можно уточнить в файле манифеста:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

Recreate (повторное создание)

В этом простейшем типе развертывания старые pod’ы убиваются все разом и заменяются новыми:

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

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

Blue/Green (сине-зеленые развертывания)

Стратегия сине-зеленого развертывания (иногда ее ещё называют red/black, т.е. красно-чёрной) предусматривает одновременное развертывание старой (зеленой) и новой (синей) версий приложения. После размещения обеих версий обычные пользователи получают доступ к зеленой, в то время как синяя доступна для QA-команды для автоматизации тестов через отдельный сервис или прямой проброс портов:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

После того, как синяя (новая) версия была протестирована и был одобрен ее релиз, сервис переключается на неё, а зеленая (старая) сворачивается:

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

Canary (канареечные развертывания)

Канареечные выкаты похожи на сине-зеленые, но лучше управляются и используют прогрессивный поэтапный подход. К этому типу относятся несколько различных стратегий, включая «скрытые» запуски и А/В-тестирование.

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

Хотя данную стратегию можно реализовать исключительно средствами Kubernetes, заменяя старые pod’ы на новые, гораздо удобнее и проще использовать service mesh вроде Istio.

Например, у вас может быть два различных манифеста в Git: обычный с тегом 0.1.0 и «канареечный» с тегом 0.2.0. Изменяя веса в манифесте виртуального шлюза Istio, можно управлять распределением трафика между этими двумя deployment’ами:

Пошаговое руководство по реализации канареечных развертываний с помощью Istio можно найти в материале GitOps Workflows with Istio. (Прим. перев.: Мы также переводили материал про канареечные выкаты в Istio здесь.)

Канареечные развертывания с Weaveworks Flagger

Weaveworks Flagger позволяет легко и эффективно управлять канареечными выкатами.

Flagger автоматизирует работу с ними. Он использует Istio или AWS App Mesh для маршрутизации и переключения трафика, а также метрики Prometheus для анализа результатов. Кроме того, анализ канареечных развертываний можно дополнить вебхуками для проведения приемочных (acceptance) тестов, нагрузочных и любых других типов проверок.

На основе deployment’а Kubernetes и, при необходимости, горизонтального масштабирования pod’ов (HPA), Flagger создает наборы из объектов (deployment’ы Kubernetes, сервисы ClusterIP и виртуальные сервисы Istio или App Mesh) для проведения анализа и реализации канареечных развертываний:

Реализуя контур управления (control loop), Flagger постепенно переключает трафик на канареечный сервер, параллельно измеряя ключевые показатели производительности, такие как доля успешных HTTP-запросов, средняя продолжительность запроса и здоровье pod’ов. Основываясь на анализе KPI (ключевых показателей эффективности), канареечная часть либо растет, либо сворачивается, и результаты анализа публикуются в Slack. Описание и демонстрацию этого процесса можно найти в материале Progressive Delivery for App Mesh.

Dark (скрытые) или А/В-развертывания

Скрытое развертывание — еще одна вариация канареечной стратегии (с ней, кстати, Flagger тоже может работать). Разница между скрытым и канареечным развертыванием состоит в том, что скрытые развертывания имеют дело с фронтендом, а не с бэкендом, как канареечные.

Другое название этих развертываний — А/В-тестирование. Вместо того, чтобы открыть доступ к новой функции всем пользователям, ее предлагают лишь ограниченной их части. Обычно эти пользователи не знают, что выступают тестерами-первопроходцами (отсюда и термин «скрытое развертывание»).

С помощью переключателей функциональности (feature toggles) и других инструментов можно следить за тем, как пользователи взаимодействуют с новой функцией, увлекает ли она их или они считают новый пользовательский интерфейс запутанным, и другими типами метрик.

Flagger и A/B-развертывания

Помимо маршрутизации с учётом весов, Flagger также может направлять на канареечный сервер трафик в зависимости от параметров HTTP. При А/В-тестировании можно использовать заголовки HTTP или файлы cookie для перенаправления определенного сегмента пользователей. Это особенно эффективно в случае frontend-приложений, требующих привязки сессии к серверу (session affinity). Дополнительную информацию можно найти в документации Flagger.

Автор выражает благодарность Stefan Prodan, инженеру Weaveworks (и создателю Flagger), за все эти потрясающие схемы деплоя.

P.S. от переводчика

Читайте также в нашем блоге:

Беглый деплой или как развернуть front-end за 15 минут / Хабр

Уже очень давно у нас стоял вопрос: как же просто и быстро деплоить front-end проекта?

Мы думали насчет такого инструмента, как Jenkins. Многие, кто настраивал его, знают: настройка занимает немало времени и, что еще важно — затрачивается много ресурсов системы. Поднять его на сервере значит выделить полтора гигабайта памяти. Такое себе удовольствие, когда у тебя 500 мегабайт на всё, например.

Альтернативный вариант — Mina. Это отличное решение, и мы используем его в Ruby проектах. Но как быть, если у тебя только front-end? Ставить Ruby и делать Bundle? Нет, это слишком сложно. Mina, конечно, имеет большой функционал, но мы хотим это делать на NodeJS без лишних телодвижений.

В итоге мы писали Bash скрипты, но это нас утомило. И нам в голову пришла идея написать свой небольшой сервис для деплоя front-end приложений, который будет:

• npm пакетом
• иметь небольшой и простенький конфиг
• занимать 10 минут для его настройки и 5 минут для деплоя
• иметь систему релизов (если всё-таки что-то пойдет не так и кто-то скажет — «оно само

сломалось», то смело и быстро можно вернуться на предыдущий релиз)

И мы сделали Runy — удобный и практичный инструмент для деплоя front-end.

Все что нужно для его настройки и первого деплоя после установки пакета — это три команды:
init — создать конфиг и внести свои данные в него
setup — создать структуру проекта
deploy — задеплоить ваш проект

И это все!

Данный модуль упростил нам жизнь! Теперь деплой проходит одной командой. Быстро и просто. Когда к нам приходят новые разработчики, можно дать им доступы к dev/stage серверу, чтобы ребята могли сами деплоить. Junior разработчикам тоже будет полезно, для использования не нужен порог вхождения, а в дальнейшем они могут разобраться в модуле и приобрести новые знания.

Немного о технической части (более подробный мануал есть на github). На данный момент, Runy имеет следующие команды: init, setup, deploy, unlock, rollback.

Init

Создает конфиг файл в месте вызова команды. Вам следуют внести в него свои данные. Как видно, мы используем подключение по ssh-agent, так что никакие пароли в конфиге находиться не будут.

// runy.js

module.exports = {
  host: '0.0.0.0', // адрес сервера
  username: 'username', // имя пользователя для входа на сервер
  port: 22, // порт сервера
  remotePath: '/your/project/path', // путь структуры релизов и проекта
  git: 'link-to-your-git-repository', // ссылка (лучше ssh) на ваш репозиторий
  agent: process.env.SSH_AUTH_SOCK, // ключ авторизации
  commands: [ // список команд для развертывания проекта
    'npm install',
    'npm run build',
  ],
};

Setup

По указанному пути в конфиге, создает папку releases (в ней хранятся релизы по номерам 1, 2, 3 и тд.) и файл .current.release (в нем хранится номер текущего релиза).

Deploy

Данная команда имеет некую защиту, в одно и тоже время только один человек может производить деплой.

Команда делает следующие действия. Создает временную папку, устанавливает проект, выполняет список ваших команд из конфиг файла (commands) для подтягивания зависимостей и сборки приложения, создает новую релиз папку, переносит туда только что собранный проект, проверяет количество релизов и удаляет старые (сейчас хранится 3 релиза), создает символическую ссылку на текущий релиз (текущий релиз всегда будет доступен по данному пути your-remote-path/current), обновляет файл с цифрой релиза, чистит папки.

Unlock

Удаляет защитный файл, который создается при исполнении команды deploy. Вообще файл удаляется автоматически и даже при обработке ошибок, но на все случае жизни существует данная команда.

Rollback

Возвращает обратно символическую ссылку на предыдущий релиз и удаляет текущий.

P.S. У нас еще есть идеи по развитию этого инструмента, вы также можете поучаствовать в развитии проекта, создавая/делая задачи здесь.

Пусть deployment каждого разработчика станет удобнее и быстрее.

Capifony. Или деплоим symfony проект через Capistrano / Хабр

Я уже год программирую на PHP с использованием symfony framework и нахожу в этом истинное удовольствие. Однако, есть некоторые процессы разработки сайта, которые данный фрэймворк не полностью покрывает, да и не обязан =)
Одним из таких процессов является деплоймент или разворачивание и обновление проекта на рабочем сервере. Для выполнения подобной рутинной операции было написано множество скриптов и одним из самых популярных является Capistrano. Он чрезвычайно прост в освоении, совершенен функционально и крайне гибок в настройке, однако, из коробки заточен под деплой RoR приложений, для чего собственно и создавался.
Сегодня я постараюсь вам рассказать как использовать Capistrano для деплоймента symfony проектов.

Что такое capify?

Capistrano — ruby библиотека, выполняющая рутину по выкатыванию сайта и предоставляющая гибкие средства для своевременного отката проекта до предыдущей версии (предыдущий деплоймент).
Capistrano путем подключения через SSH оперирует удаленными директориями, создавая новую директорию с актуальным кодом и созданием нужных симлинков. Актуальный код Capistrano может копировать с любой другой машины по SSH серверу, использовать GIT или SVN репозитории. На этом возможности capify не заканчиваются. В принципе, скрипт при должной настройке способен выполнять любой набор unix комманд на любом количестве удаленных систем (к которым у вас есть доступ, естественно). Однако, наибольшее количество скриптов и настроек Capistrano имеет в основном для удаленного развертывания приложений, о котором мы сегодня и говорим.
capify — команда для создания конфига Capistrano

Стандартный процесс деплоймента

Выполнение процесса деплоймента разделено на атомарные операции-задачи (tasks), каждый из которых отвечает за отдельный аспект «выкатки». При этом глобальное выполнение деплоя ведет себя как полноценная транзакция и если хотя бы одна операция не выполняется — весь процесс отменяется, а удаленная файловая система возвращается к состоянию до деплоя.
Основные комманды для capistrano:

1. capify . — создает в текущей директории файлы для конфигурации доступа к удаленной системе и настройки процесса. Файлы эти:
   1. Capfile — основной скрипт, подтягиваемый коммандой «capify»
   2. config/deploy.rb — настройки процесса, заинклуженные в Capfile. Именно в этот файл необходимо прописывать все наши пути до серверов и настройки перед выполнением следующих комманд

2. cap deloy:setup — разворачивает на удаленном сервере/серверах (их может быть несколько) файловую структуру для последующих процессов деплоймента
3. cap deploy — выполняет деплоймент. При этом создается новая директория для проекта, в ней делаются симлинки на общие (shared) ресуры и затем, делается симлинк current на эту директорию, подсовывая web серверу актуальный код
4. cap rollback — откатываемся до предыдущего деплоймента. При этом удаляется директория с текущей версией (при хардовом роллбэке), а симлинк current перебивается на предыдущую директорию деплоя

Зачем нужен capifony?

Как я уже говорил, capistrano изначально создавался для деплоя RoR приложений и есть некоторые места, которые его (из коробки) привязывают именно к этому фрэймворку. Например, структура и список shared папок у Rails и symfony проектов разные. При деплойменте symfony проекта также необходимо выполнять некоторые таски, такие как symfony plugin:publish-assets для создания симлинков на ассеты из плагинов, symfony cc для сброса кэша и symfony fix-perms для восстановления пермишенов на папки cache и web/uploads.
Для решения всех этих проблем я слегка расширил базовые скрипты деплоймента capistrano, что дало рождение capifony
Скачать скрипт и поучаствовать в его разработке можно тут: http://github.com/everzet/capifony/tree/master.

Использование

Итак, у нас есть проект, который необходимо развернуть на рабочем сервере. Этот проект у нас хранится в удаленном git-репозитории на рабочем сервере (это может быть и не git и хранится код может где угодно, куда есть доступ по SSH и в любом виде, о котором знает Capistrano, а он знает много =) ).
Для начала мы переходим в локальную директорию с проектом, который необходимо залить и удаленный git-репозиторий которого находится на сервере:

1. В корне мы выполняем комманду capify ., создающую нам Capfile в корне и deploy.rb в config/
2. Скачиваем файл capifony.rb с гитхаба и кладем его в config/
3. В конец Capfile дописываем load 'config/capifony'
4. И последний штрих — прописываем настройки коннекта к удаленному серверу в deploy.rb:
   

   set :application, "YOUR_APPLICATION_NAME"<br>set :repository, "YOUR_SSH_SERVER_NAME:/PATH/TO/repos/#{application}.git"<br>set :deploy_to,  "/PATH/TO/www/#{application}.com"<br>set :scm,     "git"<br><br>default_run_options[:pty] = true<br>ssh_options[:forward_agent] = true<br><br>server "YOUR_SSH_SERVER_NAME", :web, :app, :db<br><br>* This source code was highlighted with Source Code Highlighter.

5. Теперь из консоли вызываем cap deploy:setup, чтобы настроить удаленную файловую структуру и cap deploy, чтобы выполнить деплоймент. И не забываем, если что-то вдруг при последующих деплоях идет не так (деплой прошел, но сайт упал, к примеру) — cap rollback поможет

Стоит отметить, что директории log/, web/uploads в деплойменте не участвуют, т.к. являются shared ресурсами, которые сохряняются между деплоями. Поэтому, если вы уже накопили набор файлов под web/uploads, их нужно вручную залить на сервер по адресу /PATH/TO/www/#{application}.com/shared/web/uploads/

Вот и все. Если вам понравилась данная статья — дайте мне знать, возможно в следующий раз я расскажу о другом интересном аспекте разработки вместе с замечательным symfony…

upd: Забыл 1 вещь. По стандарту, когда symfony генерирует проект, она прописывает в config/ProjectConfiguration.class.php абсолютный путь до symfony, который на рабочей машине и продакшене может различаться. Для решения проблемы и на продакшене и на рабочей машине добавляем путь до директории с библиотеками (включая symfony) в include_path (прим.: include_path = «.:/php/includes:/opt/local/lib/php»), а путь в ProjectConfiguration.class.php меняем на относительный require_once ‘symfony/autoload/sfCoreAutoload.class.php’;

Деплой приложений в VM, Nomad и Kubernetes / Блог компании Lamoda / Хабр

Всем привет! Меня зовут Павел Агалецкий. Я работаю тимлидом в команде, которая разрабатывает систему доставки Lamoda. В 2018 году я выступал на конференции HighLoad++, а сегодня хочу представить расшифровку своего доклада.

Моя тема посвящена опыту нашей компании по деплою систем и сервисов в разные среды. Начиная от наших доисторических времен, когда мы деплоили все системы в обычные виртуальные сервера, заканчивая постепенным переход от Nomad к деплою в Kubernetes. Расскажу о том, почему мы это сделали и какие у нас были в процессе проблемы.

Начнем с того, что 3 года назад все системы и сервисы компании деплоились на обычные виртуальные сервера. Технически было организовано так, что весь код наших систем лежал и собирался за счет средств автоматической сборки, с помощью jenkins. При помощи Ansible он из нашей системы контроля версий раскатывался уже на виртуальные сервера. При этом каждая система, которая была в нашей компании, деплоилась, как минимум, на 2 сервера: одна из них — на head, вторая — на tail. Эти две системы были абсолютно идентичны между собой по всем своим настройкам, мощности, конфигурации и прочему. Отличие между ними было лишь в том, что head получал пользовательский трафик, а tail никогда трафик пользователей на себя не получал.

Для чего это было сделано?

Когда мы деплоили новые релизы нашего приложения, то хотели обеспечить возможность бесшовной раскатки, то есть без заметных последствий для пользователей. Достигалось это за счет того, что очередной собранный релиз с помощью Ansible выкатывался на tail. Там люди, которые занимались деплоем, могли проверить и убедиться, что все хорошо: все метрики, разделы и приложения работают; запускаются нужные скрипты. Только после того, как они убеждались, что все ок, трафик переключался. Он начинал идти на тот сервер, который до этого был tail. А тот, который до этого был head-ом, оставался без пользовательского трафика, при этом с имеющейся на нем предыдущей версией нашего приложения.

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

Какие мы видели во всем этом достоинства?

1. Прежде всего, это достаточно просто работает. Всем понятно, как функционирует подобная схема деплоя, потому что большинство людей когда-либо деплоили на обычные виртуальные сервера.
2. Это достаточно надежно, так как технология деплоя простая, опробованная тысячами компаний. Миллионы серверов деплоятся именно так. Сложно что-то сломать.
3. И наконец, мы могли получить атомарные деплои. Деплои, которые для пользователей происходят одномоментно, без заметного этапа переключения между старой версией и новой.

Но в этом всем мы также видели несколько недостатков:

1. Помимо продакшн-среды, среды разработки, есть и другие среды. Например, qa и preproduction. На тот момент у нас было много серверов и около 60 сервисов. По этой причине приходилось для каждого сервиса поддерживать актуальную для него версию виртуальной машины. Причем, если вы хотите обновить библиотеки или поставить новые зависимости, вам необходимо это сделать во всех средах. Также нужно было синхронизировать время, когда вы собираетесь деплоить очередную новую версию вашего приложения, со временем, когда devops выполнит необходимые настройки окружения. В таком случае легко попасть в ситуацию, когда окружение у нас будет несколько отличаться сразу во всех средах подряд. Например, в QA-среде будут одни версии библиотек, а в продакшн — другие, что приведет к проблемам.
2. Сложность в обновлении зависимостей вашего приложения. Это зависит не от вас, а от другой команды. А именно, от команды devops, которая поддерживает сервера. Вы должны поставить для них соответствующую задачу и дать описание того, что хотите сделать.
3. В то время мы также хотели разделить имевшиеся у нас большие крупные монолиты на отдельные маленькие сервисы, так как понимали, что их будет становиться все больше и больше. На тот момент у нас уже было их более 100. Необходимо было для каждого нового сервиса создавать отдельную новую виртуальную машину, которую также надо обслуживать и деплоить. Кроме этого, нужна не одна машина, а, как минимум, две. К этому всему еще добавляется QA-среда. Это вызывает проблемы и делает для вас создание и запуск новых систем более сложным, дорогостоящим и долгим процессом.

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

Мы долго размышляли над тем, какую из них можно взять. Дело в том, что на тот момент этот стек деплоя на обычные виртуальные сервера был у нас несколько устаревшим, так как там были не самые свежие версии операционных систем. В какой-то момент там даже FreeBSD стояла, которую было не очень удобно поддерживать. Мы понимали, что нужно как можно быстрее мигрировать в docker. Наши девопс посмотрели на свой имеющийся опыт работы с разными решениями и выбрали такую систему как Nomad.

Nomad – это продукт компании “HashiCorp”. Также они известны другими своими решениями:

«Consul» — это средство для сервис-дискаверинга.

«Terraform» — система для управления серверами, позволяющая вам настраивать их через конфигурацию, так называемую infrastructure-as-a-code.

«Vagrant» позволяет вам разворачивать виртуальные машины локально или в облаке путем определенных файлов конфигурации.

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

Что нужно для того, чтобы вообще задеплоить вашу систему в Nomad?

1. Прежде всего нужен docker image вашего приложения. Необходимо собрать его и поместить в хранилище образов docker. В нашем случае это artifactory — такая система, которая позволяет пушить в нее различные артефакты разного типа. Она умеет хранить архивы, образы docker, пакеты composer РНР, NРМ-пакеты и так далее.
2. Также необходим конфигурационный файл, который скажет Nomad, что, куда и в каком количестве вы хотите задеплоить.

Когда мы говорим про Nomad, то в качестве формата информационного файла он использует язык HСL, что расшифровывается как HashiCorp Configuration Language. Это такое надмножество над Yaml, которое позволяет вам описать ваш сервис в терминах Nomad.

Он позволяет сказать, сколько контейнеров хотите задеплоить, из каких images передать им различные параметры при деплое. Таким образом, вы скармливаете этот файл Nomad, а он запускает в соответствии с ним контейнеры в продакшн.

В нашем случае мы поняли, что просто писать под каждый сервис абсолютно одинаковые, идентичные HСL-файлы будет не очень удобно, потому что сервисов много и иногда хочется их обновить. Бывает такое, что один сервис задеплоен не в одном экземпляре, а в самых разных. Например, одна из систем, которая у нас находится в продакшн, имеет более 100 инстансов в проде. Они запускаются из одних и тех же образов, но отличаются конфигурационными настройками и конфигурационными файлами.

Поэтому мы решили, что нам будет удобно хранить все наши конфигурационные файлы для деплоя в одном общем репозитории. Таким образом, они становились обозреваемы: их было легко поддерживать и можно было увидеть, какие системы у нас есть. В случае необходимости также несложно что-то обновить или поменять. Добавить новую систему тоже не составит труда — достаточно просто завести конфигурационный файл внутри новой директории. Внутри нее лежат файлы: service.hcl, который содержит описание нашего сервиса, и некоторые env-файлы, которые позволяют этот самый сервис, будучи задеплоенным в продакшн, настроить.

Однако некоторые наши системы задеплоены в проде не в одном экземпляре, а в нескольких сразу. Поэтому мы решили, что нам удобно будет хранить не конфиги в чистом виде, а их шаблонизированный вид. И в качестве языка шаблонизации мы выбрали jinja 2. В таком формате у нас хранятся как конфиги самого сервиса, так и env-файлы, нужные для него.

Помимо этого, мы поместили в репозиторий общий для всех проектов скрипт-деплой, который позволяет запустить и задеплоить ваш сервис в продакшн, в нужный environment, в нужный таргет. В случае, когда мы превратили наш HCL-конфиг в шаблон, то тот HСL-файл, который до этого был обычным конфигом Nomad, в этом случае стал выглядеть несколько иначе.

То есть мы заменили какие-то переменные места конфига на вставки переменных, которые берутся из env-файлов или из других источников. Помимо этого, мы получили возможность собирать HСL-файлы динамически, то есть мы можем применять не только обычные вставки переменных. Так как jinja поддерживает циклы и условия, туда же можно делать конфигурационные файлы, которые меняются в зависимости от того, куда именно вы деплоите свои приложения.

Например, вы хотите деплоить ваш сервис в препродакшн и в продакшн. Допустим, что в препродакшн вы не хотите запускать крон-cкрипты, а просто хотите видеть сервис на отдельном домене, чтобы убедиться, что он функционирует. Для любого, кто деплоит сервис, процесс выглядит очень просто и прозрачно. Достаточно выполнить файл deploy.sh, указать, какой сервис вы хотите задеплоить и в какой таргет. Например, вы хотите задеплоить некоторую систему в Россию, в Белоруссию или Казахстан. Для этого достаточно просто поменять один из параметров, и у вас соберется правильный конфигурационный файл.

Когда сервис Nomad уже оказывается у вас задеплоенным в кластер, он выглядит следующим образом.

Для начала вам нужен некоторый балансировщик снаружи, который будет принимать весь пользовательский трафик в себя. Он будет работать вместе с Consul и узнавать у него, где, на какой ноде, по какому IP-адресу находится конкретный сервис, который соответствует тому или иному доменному имени. Сервисы в Consul появляются из самого Nomad. Поскольку это продукты одной и той же компании, они неплохо связаны между собой. Можно сказать, что Nomad из коробки умеет регистрировать все запускаемые в нем сервисы внутри Consul.

После того как ваш внешний балансировщик узнает о том, в какой сервис необходимо отправить трафик, он перенаправляет его в соответствующий контейнер или в несколько контейнеров, которые соответствуют вашему приложению. Естественно, что при этом необходимо думать и о безопасности. Даже несмотря на то, что все сервисы запускаются на одних и тех же виртуальных машинах в контейнерах, обычно для этого требуется запретить свободный доступ из любого сервиса к любому другому. Мы достигали этого за счет сегментации. Каждый сервис запускался в своей виртуальной сети, на которой были прописаны правила маршрутизации и правила разрешения/запрета доступа к другим системами и сервисам. Они могли находиться как внутри этого кластера, так и вне него. Например, если вы хотите запретить сервису коннектиться к определённой базе данных, это можно сделать путем сегментации на уровне сети. То есть даже по ошибке вы не можете случайно подсоединяться из тестового окружения к вашей продакшн базе.

Во что нам обошелся процесс перехода в плане человеческих ресурсов?

Примерно 5-6 месяцев занял переход всей компании в Nomad. Мы переходили посервисно, но в достаточно быстром темпе. Каждая команда должна была создать свои собственные контейнеры для сервисов.

У нас принят такой подход, что каждая команда отвечает за docker images своих систем самостоятельно. Девопс же предоставляют общую инфраструктуру, необходимую для деплоя, то есть поддержку самого кластера, поддержку CI-системы и так далее. И на тот момент у нас более 60 систем переехали в Nomad, получилось порядка 2 тысяч контейнеров.

Девопс отвечает за общую инфраструктуру всего, что связано с деплоем, с серверами. А каждая команда разработки в свою очередь отвечает за реализацию контейнеров под свою конкретную систему, поскольку именно команда знает, что ей вообще нужно в том или ином контейнере.

Какие достоинства мы получили, перейдя на деплой с помощью Nomad и docker в том числе?

1. Мы обеспечили одинаковые условия для всех сред. В девеломпенте, QA-среде, препродакшне, продакшне используются одни и те же образы контейнеров, с одними и теми же зависимостями. Соответственно у вас практически отсутствует шанс того, что в продакшн окажется не то, что вы до этого протестировали у себя локально или на тестовом окружении.
2. Также мы выяснили, что достаточно легко добавить новый сервис. Любые новые системы с точки зрения деплоя запускаются очень просто. Достаточно пойти в репозиторий, хранящий конфиги, добавить туда очередной конфиг для вашей системы, и у вас все готово. Вы можете деплоить вашу систему в продакшн без дополнительных усилий от девопс.
3. Все конфигурационные файлы в одном общем репозитории оказались обозреваемые. В тот момент, когда мы деплоили наши системы с помощью виртуальных серверов, мы использовали Ansible, в котором конфиги лежали в одном и том же репозитории. Однако для большинства разработчиков работать было с этим несколько сложнее. Тут объем конфигов и кода, который вам нужно добавить, чтобы задеплоить сервис, стал намного меньше. Плюс для девопс очень легко поправить его или поменять. В случае переходов, например, на новой версии Nomad, они могут взять и массово обновить все операционные файлы, лежащие в одном и том же месте.

Но мы также столкнулись и с несколькими недостатками:

Оказалось, что мы не смогли достичь бесшовности деплоев в случае Nomad. При выкатке контейнеров из разных условий могло получиться так, что он оказывался запущенным, и Nomad воспринимал его как готовый к принятию трафика контейнер. Это происходило еще до того, как приложение внутри него успело запуститься. По этой причине система на недолгий срок начинала выдавать 500-е ошибки, потому что трафик начинал идти на контейнер, который еще не готов его принять.

Мы столкнулись с некоторыми багами. Самый существенный баг заключается в том, что Nomad не очень хорошо воспринимает большой кластер, если у вас много систем и контейнеров. Когда вы хотите вывезти в обслуживание один из серверов, который включен в кластер Nomad, есть достаточно большая вероятность того, что кластер почувствует себя не очень хорошо и развалится на части. Часть контейнеров может, например, упасть и не подняться — это вам впоследствии очень дорого обойдется, если все ваши системы в продакшн находятся именно в кластере, управляемом Nomad.

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

В этом плане наш выбор пал на Kubernetes как на самую популярную платформу для запуска кластеров. Особенно при условии того, что размер и количество наших контейнеров был достаточно большой. Для таких целей Kubernetes показался самой подходящей системой из тех, что мы могли посмотреть.

Немножко расскажу о том, какие есть основные понятия Kubernetes и чем они отличаются от Nomad.

В первую очередь самым базовым понятием в Kubernetes является понятие pod. Pod — это группа одного или нескольких контейнеров, которые всегда запускаются вместе. И они работают как будто всегда строго на одной виртуальной машине. Они доступны друг другу по айпишнику 127.0.0.1 на разных портах.

Предположим, что у вас есть РНР-приложение, которое состоит из nginx и php-fpm – классическая схема. Скорее всего, вы захотите, чтобы и nginx и php-fpm контейнеры были всегда вместе. Kubernetes позволяет этого добиться, описав их как один общий pod. Как раз этого мы и не могли получить при помощи Nomad.

Вторым понятием является deployment. Дело в том, что pod сам по себе – это эфемерная вещь, она запускается и исчезает. Хотите ли вы сначала убивать все ваши предыдущие контейнеры, а потом запускать сразу новые версии или же вы хотите выкатывать их постепенно – вот именно за этот процесс отвечает понятие deployment. Он описывает то, как вы деплоите ваши podы, в каком количестве и, как их обновлять.

Третьим понятием является service. Ваш service – это фактически ваша система, которая принимает в себя некий трафик, а потом направляет его на один или несколько podов, соответствующих вашему сервису. То есть он позволяет сказать, что весь входящий трафик на такой-то сервис с таким-то именем необходимо отправлять на конкретно эти podы. И при этом он обеспечивает вам балансировку трафика. То есть вы можете запустить два podа вашего приложения, и весь входящий трафик будет равномерно балансироваться между относящимися к этому сервису podами.

И четвертое основное понятие — Ingress. Это сервис, который запускается в кластере Kubernetes. Он выступает как внешний балансировщик нагрузки, который принимает на себя все запросы. За счет API Kubernetes Ingress может определять, куда эти запросы надо отправить. Причем делает он это очень гибко. Вы можете сказать, что все запросы на этот хост и такой-то URL отправляем на этот сервис. А эти запросы, приходящие на этот хост и на другой URL отправляем на другой сервис.

Самое крутое с точки зрения того, кто разрабатывает приложение — это то, что вы способны этим всем управлять самостоятельно. Задав конфиг Ingress, можете весь трафик, приходящий на такой-то API, отправлять на отдельные контейнеры, прописанные, например, на Go. А вот этот трафик, приходящий на тот же домен, но на другой URL, отправлять на контейнеры, написанные на РНР, где много логики, но они не очень скоростные.

Если сравнить все эти понятия с Nomad, то можно сказать, что первые три понятия – это все вместе Service. А последнее понятие в самом Nomad отсутствует. Мы в качестве него использовали внешний балансировщик: это может быть haproxy, nginx, nginx+ и так далее. В случае с кубом вам не надо вводить это дополнительное понятие отдельно. Однако, если посмотреть на Ingress внутри, то это либо nginx, либо haproxy, либо traefik, но как бы встроенный в Kubernetes.

Все описанные мною понятия – это, по сути дела, ресурсы, которые существуют внутри кластера Kubernetes. Для их описания в кубе используется yaml-формат, более читаемый и привычный, чем НСL-файлы в случае с Nomad. Но структурно они описывают в случае, например, podа то же самое. Они говорят – хочу задеплоить такие-то podы туда-то, с такими-то имаджи, в таком-то количестве.

Помимо этого, мы поняли, что не хотим руками создавать каждый отдельный ресурс: deployment, сервисы, Ingress и прочее. Вместо этого мы хотели при деплое описывать нашу каждую систему, имеющуюся в терминах Kubernetes, чтобы не приходилось вручную пересоздавать в нужном порядке все необходимые зависимости ресурсов. В качестве такой системы, которая позволила нам это сделать, был выбран Helm.

Helm – это пакетный менеджер для Kubernetes. Он очень похож на то, как работают пакетные менеджеры в языках программирования. Они позволяют вам хранить сервис, состоящий из, например, deployment nginx, deployment php-fpm, конфига для Ingress, configmaps (это сущность, которая позволяет вам задать env и другие параметры для вашей системы) в виде так называемых чартов. При этом Helm работает поверх Kubernetes. То есть это не какая-то система, стоящая в стороне, а просто ещё один сервис, запускаемый внутри куба. Вы взаимодействуете с ним по его API через консольную команду. Его удобство и прелесть в том, что даже если helm сломается или вы его удалите из кластера, то ваши сервисы не исчезнут, так как helm служит по сути только для запуска системы. За работоспособность и состояние сервисов дальше отвечает сам Kubernetes.

Также мы поняли, что шаблонизация, которую до этого были вынуждены делать самостоятельно через внедрение jinja в наши конфиги, является одной из основных возможностей helm. Все конфиги, которые вы создаете для ваших систем, хранятся в helm в виде шаблонов, похожих немножко на jinja, но, на самом деле, использующих шаблонизацию языка Go, на котором helm написан, как и Kubernetes.

Helm добавляет нам еще несколько дополнительных понятий.

Chart — это описание вашего сервиса. В других пакетных менеджерах его назвали бы пакет, bundle или что-то подобное. Здесь это называется chart.

Values – это переменные, которые вы хотите использовать для сборки ваших конфигов из шаблонов.

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

В случае, когда мы используем helm, обычные конфиги для Kubernetes тоже превращаются в шаблоны, в которых есть возможность использовать переменные, функции, применять условные операторы. Таким образом, вы можете собирать конфиг вашего сервиса в зависимости от среды.

На практике мы решили поступить чуть-чуть иначе, чем мы делали в случае с Nomad. Если в Nomad в одном репозитории хранились и конфиги для деплоя, и n-переменные, которые нужны для того, чтобы задеплоить наш сервис, то здесь мы решили их разделить на два отдельных репозитория. В репозитории «deploy» хранятся только n-переменные, нужные для деплоя, а в репозитории «helm» хранятся конфиги или чарты.

Что это нам дало?

Несмотря на то, что в самих конфигурационных файлах мы не храним какие-то действительно чувствительные данные. Например, пароли к базам данных. Они хранятся в виде secrets в Kubernetes, но тем не менее, там все равно есть отдельные вещи, к которым мы не хотим давать доступ всем подряд. Поэтому доступ к репозиторию «deploy» более ограничен, а репозиторий «helm» содержит просто описание сервиса. По этой причине в него можно дать доступ безопасно большему кругу лиц.

Поскольку у нас есть не только продакшн, но и другие среды, то благодаря такому разделению мы можем переиспользовать наши helm-чарты, чтобы деплоить сервисы не только в продакшн, но и, например, в QA-среду. Даже для того, чтобы разворачивать их локально, используя Minikube — это такая штука для локального запуска Kubernetes.

Внутри каждого репозитория мы оставили разделение на отдельные директории для каждого сервиса. То есть внутри каждой директории находятся шаблоны, относящиеся к соответствующему чарту и описывающие те ресурсы, которые необходимо задеплоить для запуска нашей системы. В репозитории «deploy» мы оставили только энвы. В этом случае мы не стали использовать шаблонизацию с помощью jinja, потому что helm сам дает шаблонизацию из коробки – это одна из его основных функций.

Мы оставили скрипт для деплоя – deploy.sh, который упрощает и стандартизирует запуск для деплоя с помощью helm. Таким образом, для любого, кто хочет задеплоить, интерфейс деплоя выглядит точно так же, как он был в случае деплоя через Nomad. Такой же deploy.sh, название вашего сервиса, и то, куда вы хотите его задеплоить. Это приводит к тому, что внутри запускается helm. Он в свою очередь собирает конфиги из шаблонов, подставляет в них необходимые values-файлы, затем деплоит, пуская их в Kubernetes.

Сервис Kubernetes выглядит более сложным, чем Nomad.

Здесь исходящий трафик приходит в Ingress. Это как раз фронт-контроллер, который принимает на себя все запросы и впоследствии отправляет их в соответствующие данным запроса сервисы. Определяет он их на основе конфигов, которые являются частью описания вашего приложения в helm и которые разработчики задают самостоятельно. Сервис же отправляет запросы на свои podы, то есть конкретные контейнеры, балансируя входящий трафик между всеми контейнерами, которые относятся к данному сервису. Ну и, конечно, не стоит забывать про то, что от безопасности на уровне сети, мы никуда не должны уходить. Поэтому в кластере Kubernetes работает сегментация, которая основана на тегировании. Все сервисы имеют определенные теги, к которым привязаны права доступов сервисов к тем или иным внешним/внутренним ресурсам внутри или вне кластера.

Выполняя переход, мы увидели, что Kubernetes обладает всеми возможностями Nomad, который до этого мы использовали, а также добавляет много нового. Его можно расширять через плагины, а по факту через кастомные типы ресурсов. То есть у вас есть возможность не просто использовать что-то, что идет в Kubernetes из коробки, а создать свой собственный ресурс и сервис, который будет ваш ресурс читать. Это дает дополнительные возможности расширения вашей системы без необходимости переустановки Kubernetes и без необходимости изменений.

Примером такого использования является Prometheus, который запускается у нас внутри кластера Kubernetes. Для того, чтобы он начал собирать метрики с того или иного сервиса, нам нужно добавить в описание сервиса дополнительный тип ресурса, так называемый сервис-монитор. Prometheus за счет того, что умеет вычитывать, будучи запущенным в Kubernetes, кастомный тип ресурсов, автоматически начинает собирать метрики с новой системы. Это достаточно удобно.

Первый деплой, который мы сделали в Kubernetes был в марте 2018 года. И за это время мы никогда не испытывали с ним никаких проблем. Он достаточно стабильно работает без существенных багов. К тому же, мы можем его дальше расширять. На сегодняшний день нам хватает тех возможностей, которые в нем есть, а темпы развития Kubernetes нам очень нравятся. На данный момент больше 3000 контейнеров находятся в Kubernetes. Кластер занимает несколько Node. При этом он обслуживаемый, стабильный и очень контролируемый.

Как правильно выстроить разработку и деплой сайта? — Хабр Q&A

Хьюстон, у нас проблемы. Проблема номер один — я не пользовался системами контроля версий до 2019 года. Собственно, из нее вытекает и набор других проблем, породивших этот вопрос. Суть в чем — я пытаюсь в голове разложить процесс «правильной» разработки вебсайта, чтоб все как у людей — с нормальным версионированием, непрерывной интеграцией и максимальной автоматизацией. Но не очень понимаю стек инструментов, которыми это все можно и нужно рулить.
Если позволите, покажу весь масштаб проблемы на примере небольшого пет-проекта.
Проект — вебсайт на php/Laravel + vuejs + mysql + небольшой набор всяких bash-скриптов.

Как сейчас происходит разработка: случайно и чудом.
1. Собсно, пишу код. Коммичу в dev-ветку все, что плохо лежит (все то, что laravel по умолчанию не выпилил из-под гита)
2. dev-ветку ручками делаю clone на тестовый сервак (локальная машина с окружением, сходным с prod-сервером) в отдельный каталог (не в тот, который рут для сайта)
3. Собираю composer’ом и npm’ом back и front
4. Перемещаю собранный готовый проект в рут-папку сайта
5. Плачу от отсутствия тестов (знаю, что надо, но не понимаю, что нужно тестировать и как)
6. Руками гоняю (гусары, молчать) возможные состояния основных добавленных функций.
7. Если все проходит хорошо, то сливаю ветку с мастером и повторяю процедуру уже с прод-сервером

После нескольких мануалов по unit-тестированию, selenium ide, git, svn и всяких жутких вещах вроде CD\CI (конкретно читал про TeamCity) в голове каша. Мозгом понимаю, что каждый из этапов можно делать лучше. Но какой стороны подойти — хз. Так что, комрады, очень надеюсь на помощь по нескольким вопросам.

1. Разработка.
Стараюсь делать хорошо. После многих лет попыток делать хоть как-то, но быстро — не всегда получается, но потихоньку идет. Паттерны, рефакторинг — уже не просто пустой звук.
Для laravel рекомендуют наращивать функционал пакетами. Собственно, так и делаю. Не уверен, что это можно назвать пакетами, но делаю. Имеет ли смысл такой подход, когда в проекте, предположим, используется разный функционал, который не связан друг с другом? (например, магазин — один пакет, оповещения — другой пакет). Или, может, наоборот, стоит разбивать на более мелкие элементы (типа не отдельный пакет магазина, а поделить на Корзину/Склад/Доставку и т.п.)?

2. Тестирование.
Читал про TDD, пробовал делать — понравилось. Не слишком понравилось, ибо голова так думать не привыкла, но зашло. Возник вопрос — что именно надо тестировать и как выбрать набор тестов? Я всегда ориентировался на 3 варианта использования любого функционала — ожидаемый правильный, ожидаемый неправильный и неожиданный неправильный. Не уверен, что это верно, т.к. это просто выбор пальцем в небо. Если знаете, где почитать/послушать про это дело, буду весьма признателен за информацию.

Опять же, тестировать отдельно фронт и бэк — кажется очень странным. Например, на написание функционала формы для отправки файлов можно уложить в 5-10 минут, но как покрыть ее тестами? Стоит ли вообще? Если правильно понимаю, то на бэке надо тестировать ожидаемый результат (открытие страницы с формой + обработка запроса с файлом + обработка файла) + на фронте тоже есть, чем заняться (отображение страницы в браузерах на разных разрешениях, прикрепление файла, вывод результатов отправки файла). Скорее всего я не совсем понимаю этого, но пока что мне кажется такое поведение слегка безумным (десяток тестов на одну функцию).

3. Контроль версий
Продолжение безумия. Освоил простой путь — тупо храню в vcs ветку с результатами разработки. Но, опять же, здравый смысл подсказывает, что при хреновой памяти и перерывах между коммитами в несколько месяцев надо что-то менять. Как минимум, я не уверен, что правильно хранить все пакеты в одним месте. Однако как сделать правильно — не знаю. С одной стороны, можно вообще пакеты хранить в разных репозиториях и при необходимости перебирать только их. С другой — если большинство из них используются только в одном проекте (хотя могут, потенциально, и еще где-нибудь пригодиться), имеет ли смысл делить все настолько? Или это выносить как часть gitflow и каждый пакет будет чисто feature-веткой?

Про БД читал, что имеет смысл хранить лог запросов и спихивать в vcs именно этот лог. Хорошая ли затея в целом? Или есть какие-то более правильные методы (При условии, что субд MySQL)?

4. Деплой.
Читал где-то занимательную фразу типа «прекратите деплоить, делая clone на production». Я бы и рад, да только как и куда копать? Сдается мне, тут должен помочь TeamCity, но пока что я в него как баран на новые ворота.
Предположим, что код написан, тесты на dev пройдены и пришло врем сделать так, чтобы текущая ветка мастера внезапно оказалась на боевом серваке. Как правильно организовать эту самую доставку кода? В какой момент собирать приложение? Тестировать ли сборку на prod-сервере (при условии, что идентичен dev)?

5. Документирование
С docblock в php все более-менее хорошо, тут иногда даже помогает. Читал, что тесты фронтенда можно использовать в качестве документации/пользовательских мануалов. В каком виде лучше хранить документацию и нужна ли она для конечного продукта (предположим, что бэкендом может заниматься некоторый абстрактный разработчик, а на фронте временами и клиент может бывать, который не знает о системе ничего и не отказался бы от мануала по использованию)? Опять же, если это подход из прошлого века — просветите, пожалуйста, по поводу новинок всего этого.

бесшовный деплой на распределенные кластерные системы без даунтаймов / Блог компании Pixonic / Хабр

Выкладываю второй доклад с нашего первого митапа, который провели в сентябре. В прошлый раз можно было почитать (и посмотреть) про использование Consul для масштабирования stateful-сервисов от Ивана Бубнова из BIT.GAMES, а сегодня поговорим про CICD. Точнее расскажет об этом наш системный администратор Егор Панов, который отвечает за доступность инфраструктуры и сервисов в Pixonic. Под катом — расшифровка выступления.

Начну с того, что игровая индустрия более рискованная — никогда не знаешь, что именно западет в сердце игроку. И поэтому мы создаем множество прототипов. Конечно, прототипы мы создаем на коленке из палочек, веревочек и других подручных материалов.

Казалось бы, при таком подходе сделать что-то, что потом можно будет поддерживать вообще невозможно. Но даже на этом этапе мы держимся. Держимся на трех китах:

1. отличная экспертиза тестировщиков;
2. плотное с ними взаимодействие;
3. время, которое мы выдаем на тестирование.

Соответственно, если мы не выстроим свои процессы, например, деплой или CI (continuous integration) — рано или поздно мы придем к тому, что длительность тестирования все время будет увеличиваться и увеличиваться. И мы либо будем медленно все делать и потерям рынок, либо просто будем взрываться при каждом деплое.

Но CICD-процесс построить не так уж и просто. Некоторые скажут, ну да, я поставлю Jenkins, быстро что-то накликаю, вот у меня готовый CICD. Нет, это не только инструмент, это еще и практики. Начнем по порядку.

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

Мы выделили разные репозитории: деплой у нас в одном репозитории, тесты — в другом. Это работает быстрее. Может быть вам не подойдет, но для нас это гораздо удобнее. Потому что есть один важный момент в этом пункте — нужно выстроить простой и прозрачный для всех гитфлоу. Конечно, вы можете где-то скачать готовый, но в любом случае его нужно под себя подстроить, улучшить. Для нас, например, деплой живет своим гитфлоу, который больше похож на GitHub-флоу, а серверная разработка живет по своему гитфлоу.

Следующий пункт. Нужно настроить полностью автоматическую сборку. Понятно, на первом этапе разработчик сам лично собирает проект, потом сам лично его деплоит при помощи SCP, сам запускает, сам отправляет, кому нужно. Этот вариант долго не прожил, появился bash-скрипт. Ну а так как окружение разработчиков все время меняется, появился специальный выделенный билдсервер. Он прожил очень долго, за это время мы успели увеличиться в серверах до 500, настроить конфигурирование серверов на Puppet, накопить на Puppet легаси, отказаться от Puppet, перейти на Ansible, а этот билдсервер продолжал жить.

Решили все поменять после двух звонков, третьего ждать не стали. История понятная: билдсервер — это единая точка отказа и, конечно же, когда нам нужно было что-то задеплоить, дата-центр полностью упал вместе с нашим билдсервером. А второй звонок: нам нужно было обновить версию Java — обновили на билдсервере, задеплоили на стейдж, все классно, все замечательно и тут же нужно было какой-то маленький багфикс запустить на прод. Конечно, мы забыли обратно откатить и все просто развалилось.

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

Следующее правило: чем чаще коммитишь, тем лучше. А почему? Потому что есть четвертое: каждый коммит собирается. И на самом деле даже больше, чем каждый коммит. Я уже сказал, что у нас TeamCity, а он позволяет запустить коммит из вашей любимой IDE (вы догадываетесь, какую имею ввиду). Собственно, быстрая обратная связь, все замечательно.

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

Тестируем на окружении, повторяющем прод. Тут все просто, мы выбрали Ansible и AWX. Кто-то может быть спросит, а как же Docker, Kubernetes, OpenShift, где все проблемы из коробки давным давно решены? Забыл сказать, у нас есть компоненты как Linux, так и Windows. И, например, Photon-сервер, который на Windows, мы только-только недавно смогли упаковать более менее нормально в 10 Гб докер-контейнер. Соответственно, у нас есть приложение на Windows, которое плохо упаковывается в контейнер; есть приложение на Linux (которое на Java), которое прекрасно запаковывается, но это и незачем, оно прекрасно работает, где бы ты его не запустил. Это же Java.

Дальше мы выбирали между Ansible и Chef. Они оба прекрасно работают с виндой, но Ansible оказался гораздо проще для нас. Когда мы уже установили AWX — вообще все огонь стало. В AWX есть секреты, есть графики, история. Можно вообще далекому от всего этого человеку показать, он сразу все увидит и все станет понятно.

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

7 пунктов — и мы уже построили какой-то CI-процесс. Замечательно. На следующей схеме не видно, но сбоку есть еще Graylog. Кто читает наши статьи на Хабре, тот уже видел, как мы выбирали Graylog и как устанавливали. В любом случае он помогает отдебажить, если какая-то проблема все-таки случилась.

Вот на этой базе уже можно переходить к деплою.

Но про деплой я уже рассказал во втором пункте, поэтому не буду сильно останавливаться на этом. Скажу один лайфках: если вы используете Ansible, обязательно добавьте вот этот serial, который на слайде. Не раз бывало, что ты запускаешь что-то, а потом понимаешь, а я не то запустил, или не туда, или не то и не туда, а потом видишь, что это всего лишь один сервер. А мы потерять один сервер легко можем и ты просто его заново перезаливаешь, никто и не заметил.

Плюс установили хранилище артефактов на Nexus — он является единой точкой входа абсолютно для всех, не только для CI.

И это очень помогает нам обеспечить повторяемость. Ну и так как нексусы могут работать как прокси-сервисы в разных регионах, то они ускоряют деплой, установку rpm-пакетов, докер-образов, чего угодно.

Когда закладываешь новый проект, желательно выбирать компоненты, которые легко поддаются автоматизации. Например с Photon-сервером нам это не удалось. В любом случае, это было лучшее решение по другим параметрам. А вот Cassandra, например, очень удобно обновляется и автоматизируется.

Вот пример одного из наших проектов. Клиент приходи на APP-сервер, где у него лежит профиль в БД Cassandra, а потом идет на мастер-сервер, который при помощи матчмейкинга дает ему уже гейм-сервер с какой-то комнатой. Все остальные сервисы сделаны в виде «приложения — БД» и обновляется точно таким же образом.

Второй момент — нужно обеспечить простую малосвязанную архитектуру для деплоя. Нам это удалось.

Смотрите, обновляем например app-сервер. У нас есть выделенные сервисы дискавери, которые реконфигурируют балансировщик, поэтому мы просто приходим к app-сервер, тушим его, он вылетает из балансировки, обновляем и все. И так с каждым по отдельности.

Мастер-сервера обновляются почти идентично. Клиент пингует каждый мастер-сервер в регионе и идет на тот, на котором пинг лучше. Соответственно, если мы обновляем мастер-сервер, то может быть игра чуть-чуть помедленнее будет идти, но обновляется это легко и просто.

Гейм-сервера обновляются немного по-другому, потому что там все-таки идет игра. Мы идем в матчмейкинг, просим его выкинуть определенный сервер с балансировки, приходим на гейм-сервер, ждем, пока игр не станет ровно ноль, и обновляем. Потом возвращаем обратно в балансировку.

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

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

Что очень важно, мы получили простоту и скорость экспериментов. А это очень важно, ведь когда много экспериментов, мы легко можем отсеять ошибочные идеи и остановится на верных. И не на основе каких-то субъективных оценок, а на основе объективных показателей.

На самом деле я уже и не слежу, когда у нас там деплой происходит, когда релиз. Нет этого ощущения «о, релиз!», всё собрались и мурашки по коже. Сейчас это такая рутинная операция, я в чатике периодически вижу, что что-то зарелизилось, ну и ладно. Это реально круто. Ваши сисадмины будут реветь от радости, когда вы так сделаете.

Но мир не стоит на месте, он иногда подпрыгивает. Нам есть, что улучшать. Например, логи билда хотелось бы тоже засунуть в Graylog. Это потребует еще доработать логирование, чтобы была не какая-то отдельная история, а четко: вот так билд собирался, так тестировался, так деплоился и так он ведет себя на проде. И continuous monitoring — с этим история посложнее.

Мы используем Zabbix, а он вообще не готов к таким подходам. Скоро выйдет 4-я версия, узнаем что там и если все плохо, то придумаем другое решение. Как это у нас получится — расскажу на следующем митапе.

Вопросы из зала

А что происходит, когда вы задеплоили какой-то мусор в продакшн? Например, вы что-то по перформансу не рассчитали и на интегрейшене все ок, а в продакшене смотрите — у вас серваки начинают падать. Как вы откатываетесь обратно? Есть какая-то кнопка «спаси меня»?

Мы пробовали сделать автоматизацию обратной откатки. Можно потом на докладах рассказывать, как она классно работает, как все это замечательно. Но во-первых, мы разрабатываем так, чтобы версии были обратносовместимы и тестируем это. И когда мы сделали эту полностью автоматическую штуку, которая что-то там проверяет и обратно откатывает, а потом начали с этим жить, то поняли, что мы сил в нее вкладываем гораздо больше, чем если просто возьмем и той же самой педалью запустим старые версии.

По поводу автоматического обновления деплоя: почему вы вносите изменения на текущий сервер, а не добавляете новый и просто добавляете его в таргетгруп или балансер?

Так быстрее.

Например, если вам нужно обновить версию Java, вы меняете стейт инстенса на Амазоне, обновляя версию Java или еще что-то, то как вы откатываетесь в таком случае? Вы делаете изменения на рабочем сервере?

Да, каждый компонент работает прекрасно с новой версией и старой. Да, может быть придется перезалить сервер.

Бывают изменения стейтов, когда возможны большие проблемы…

Тогда взорвемся.

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

Мы хостимся на железе, не в облаках. Нам добавить сервер — это можно, но немного дольше, чем просто в облаке накликать. Поэтому мы берем наш текущий сервер (у нас не такая загрузка, чтобы мы не могли вывести часть машин) — выводим часть машин, их обновляем, пускаем туда продашкн-трафик, смотрим, как это работает, если все окей, то докатываем дальше на все остальные машины.

Вы говорите, если каждый коммит собирается и если все плохо — разработчик сразу все правит. Как вы понимаете, что все плохо? Какие процедуры с коммитом проделываются?

Естественно, первое время это какое-то ручное тестирование, обратная связь медленная. Потом уже какими-то автотестами на Appium все это покрывается, работает и дает какую-то обратную связь о том, упали тесты или не упали.

Т.е. сначала каждый коммит выкатывается и тестеры его смотрят?

Ну не каждый, это практика. Мы одну практику из этих 12 пунктов сделали — ускорились. На самом деле это долгая и упорная работа, может быть в течении года. Но в идеале потом приходишь к этому и все работает. Да, нужны какие-то автотесты, хотя бы минимальный набор, о том что у тебя это все работает.

И вопрос поменьше: там на картинке App-сервер и так далее, вот что там мне интересно? Вы сказали, что Докера у вас вроде бы нет, что же такое сервер? Голая Java или что?

Где-то это Photon на винде (гейм-сервер), App-сервер — это Java-приложение на Томкате.

Т.е. никаких виртуалок, никаких контейнеров, ничего?

Ну Java это, можно сказать, контейнер.

И Ансиблом все это раскатывается?

Да. Т.е. в определенный момент мы просто не стали вкладываться в оркестракцию, потому что зачем? Если в любом случае винду надо будет точно так же менеджить отдельно, а тут одним инструментом покрывается абсолютно все.

А базу данных как деплоите? Зависимость к компоненту или к сервису?

В самом сервисе есть схема, которая задеплоит, когда он появился и нужно разрабатывать так, чтобы ничего не удаляли, а просто что-то добавлялось и было это обратно совместимо.

А база у вас тоже железная или база где-то в облаке в Амазоне?

Самая большая база железная, но есть и другие. Есть маленькие, RDS — это уже не железная, виртуальная. Те маленькие сервисы, которые я показывал: чаты, лиги, общение с фейсбуками, кланы, что-то из этого — RDS.

Мастер-сервер — что он из себя представляет?

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

Я правильно понимаю, что на каждую выкатку вы пишите (если появились какие-то фичи) миграцию на обновление данных? Вы сказали, что берете старые артефакты и заливаете — а что с данными происходит при этом? Вы пишите миграцию на откат базы?

Это очень редкая операция с откатом. Да, пишешь ручками миграцию, а что делать.

Как обновление сервера синхронизируется с обновлениями клиента? Т.е. нужно вам новую версию игры выпустить — вы сначала обновите все сервера, потом обновятся клиенты? А сервер поддерживает и старую и новую версию?

Да, мы разрабатываем c feature toggling и feature dimming. Т.е. это специальная ручка, рычаг, который позволяет какую-то фичу включить потом. Можно абсолютно спокойно обновиться, увидеть то, что у тебя все работает, но фичу эту не включать. А когда ты уже клиента разогнал, тогда можешь фичидиммингом на 10% подкрутить, посмотреть, что все окей, а потом на полную.

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

Я говорил вам про кита «плотное взаимодействие с тестировщиками». Эта схема с разными репозиториями очень хорошо работает, только если есть какое-то очень плотное общение. Для нас это не проблема, все друг с другом легко общаются, есть хорошая коммуникация.

Т.е. в вашей команде репозиторий с тестами поддерживают тестировщики? А автотесты отдельно лежат?

Да. Ты сделал какую-то фичу и можешь из репозитория тестировщиков набрать именно те автотесты, которые тебе нужны, а все остальное не проверять.

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

Заставлять пользователей клиента каждые пять минут или каждый день новую версию скачивать — не айс идея. В любом случае ты будешь привязан к клиенту. Классно, когда у тебя web-проект, в котором ты можешь хоть каждый день обновляться и ничего не нужно делать. С клиентом история посложнее, у нас есть какая-то релизная тактика и мы ее придерживаемся.

Ты рассказал про автоматизацию выкатки на продуктовые сервера, а (я так понимаю) есть еще автоматизация выкатки на тест — а что с dev-средами? Есть ли какая-то автоматизация, разворачиваемая разработчиками?

Почти то же самое. Единственное, это уже не железные сервера, а в виртуалке, но суть примерно такая же. При этом на том же самом Ansible мы написали (у нас Ovirt) создание этой виртуалки и накатку на нее.

У вас вся история хранится в одном проекте вместе с продовыми и тестовыми конфигами Ansible или оно отдельно живет и развивается?

Можно сказать, что это отдельные проекты. Dev (devbox мы это называем) — это история, когда все в одном паке, а на проде — это распределенная история.

Еще доклады с Pixonic DevGAMM Talks

деплой — Викисловарь

Содержание

• 1 Русский
  • 1.1 Морфологические и синтаксические свойства
  • 1.2 Произношение
  • 1.3 Семантические свойства
    • 1.3.1 Значение
    • 1.3.2 Синонимы
    • 1.3.3 Антонимы
    • 1.3.4 Гиперонимы
    • 1.3.5 Гипонимы
  • 1.4 Родственные слова
  • 1.5 Этимология
  • 1.6 Фразеологизмы и устойчивые сочетания
  • 1.7 Перевод
  • 1.8 Библиография

Морфологические и синтаксические свойства[править]

де-пло́й

Существительное, неодушевлённое, мужской род, 2-е склонение (тип склонения 6a по классификации А. А. Зализняка).

Корень: -деплой-.

Произношение[править]

• МФА: [dʲɪˈpɫoɪ̯]

Семантические свойства[править]

Значение[править]

1. прогр., жарг. совокупность действий, направленных на перевод исходного кода в рабочее состояние на конкретном сервере ◆ Отсутствует пример употребления (см. рекомендации).

Синонимы[править]

Антонимы[править]

Гиперонимы[править]

Гипонимы[править]

Родственные слова[править]

Этимология[править]

От англ. deploy.

Фразеологизмы и устойчивые сочетания[править]

Перевод[править]

Библиография[править]

Развертывание

— Викисловарь

английский [править]

Этимология [править]

Заимствовано у французского déployer («разворачивать, разворачивать»), из старофранцузского desploiier , непосредственно из des- + ploiier или, возможно, из Late Latin displicāre («раскрывать, отображать» , от латинского dis- («отдельно») + plicare («складывать»). Дублет дисплей .

Произношение [править]

Глагол [править]

развертывание ( простое настоящее в единственном числе от третьего лица развертывание , причастие настоящего развертывание , простое причастие прошедшего и прошедшего времени развернутое )

1. (переходный, эргативный) Подготовить и организовать (обычно воинскую часть или части) к использованию.

   « Расставить два пехотных отряда вдоль фланга противника», — приказал генерал.

   • 2019 Октябрь, Тони Майлз и Филип Шеррат, «EMR открывает новую эру», в Modern Railways , стр. 53:

     EMR развернет из 21 «360» в ежедневное обслуживание, эксплуатация их группами из 12 автомобилей в часы пик.

2. (переходный, непереходный) Раскрывать, открывать или иным образом готовиться к использованию.

   Он напряженно ждал, когда его парашют развернется .

   • 2012 , Джон Бранч, «Снег: Лавина в Туннел-Крик», в New York Time ^[1] :

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

3. (вычисления) Для установки, тестирования и внедрения компьютерной системы или приложения.

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

Связанные термины [править]

Переводы [править]

для подготовки и организации (обычно воинских частей или частей) к использованию

раскладывать, открывать или иным образом готовить к использованию

для установки, тестирования и внедрения компьютерной системы или приложения

Существительное [править]

развертывание ( множественное число развертывание )

1. (военные, датированные) развертывание

Дополнительная литература [править]

Анаграммы [править]

.

Что такое развертывание программного обеспечения

2020-09-03 17:50:04 • Отправлено в: Деловые советы • Проверенные решения

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

Что такое развертывание программного обеспечения и преимущества

В чем смысл развертывания программного обеспечения? Развертывание программного обеспечения включает в себя весь процесс, необходимый для подготовки программного приложения к запуску и работе в определенной среде.Он включает установку, настройку, тестирование и внесение изменений для оптимизации производительности программного обеспечения. Это может быть выполнено вручную или с помощью автоматизированных систем. Ниже перечислены большие преимущества развертывания программного обеспечения:

Преимущество 1. экономия времени

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

Преимущество 2. Повышение безопасности

Развертывание позволяет настроить роли наборов разрешений, которые могут контролировать чувствительную или критически важную группу компьютеров. Это обеспечивает защиту компьютеров на предприятии. Группы задач также можно защитить, поддерживая наборы разрешений на основе задач. Дополнительные протоколы безопасности могут применяться к критически важным или чувствительным задачам.

Преимущество 3. отслеживать действия пользователя

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

Преимущество 4. эффективные обновления программного обеспечения

Раздражает проверять наличие обновлений для каждой установленной версии любого программного обеспечения.Вам нужно найти обновления, а затем вручную инициировать загрузку. Благодаря развертыванию программного обеспечения можно автоматически выполнять точные обновления программного обеспечения, задачи обслуживания и удаления. Компьютеры также отслеживаются на предмет проблем в режиме реального времени.

Скачать или купить PDFelement бесплатно прямо сейчас!

Скачать или купить PDFelement бесплатно прямо сейчас!

Купите PDFelement прямо сейчас!

Купите PDFelement прямо сейчас!

.

Что такое развертывание программного обеспечения? | Развертывание и управление сторонним программным обеспечением

Что подразумевается под развертыванием программного обеспечения?

Разработка программного обеспечения включает в себя процесс создания приложений и программ путем написания и поддержки исходного кода. Речь идет о полном процессе и этапах жизненного цикла разработки программного обеспечения (SDLC).

Разработка программного обеспечения — это пошаговый процесс изобретения, определения, кодирования, записи, тестирования и исправления ошибок, который делается для создания и управления фреймворками, программными компонентами или даже для разработки полного приложения.

Преимущества развертывания программного обеспечения

• Облегчает бизнес-процессы с помощью программных решений, разработанных на заказ, за ​​счет улучшения внутренних операций и производительности организации.
• Помогает в интеграции с Интернетом вещей. Обеспечивает подключение к пользовательским устройствам и другим физическим устройствам для облегчения жизни пользователей и улучшения результатов бизнеса.
• Эффективное управление большими данными — предоставляет возможности для сопоставления и понимания больших данных с помощью эффективной и организованной панели управления.Это поможет бизнес-энтузиастам анализировать широкий спектр показателей и определять тенденции для более эффективной постановки целей.
• Выберите опытную компанию по разработке программного обеспечения, когда пытаетесь адаптироваться к новой программной инфраструктуре, которая влияет на создание или прекращение проекта.
• Развертывание индивидуального программного обеспечения может автоматизировать процессы, связанные с бизнесом, и обеспечить централизованное управление.
• Следуя современной мобильной тенденции, приложения, которые помогают предприятиям подключаться к устройствам удаленно, а пользователи могут получать доступ к процессам с любого устройства в любое время.

Характеристики

• Программное обеспечение разрабатывается согласно требованиям клиента с требованиями. Разработчик получает четкое представление о целях клиента перед тем, как предложить решение. Когда предлагаемое решение способно удовлетворить потребности заказчика — только тогда будет успех в разработке программного обеспечения.
• Разработка программного обеспечения включает в себя жизненный цикл, называемый SDLC (Жизненный цикл разработки программного обеспечения). Различные этапы SDLC — это понимание требований, проектирование, планирование, реализация, тестирование, документирование и сопровождение.Разработка программного обеспечения при прохождении каждого из этапов SDLC — высоки шансы получить программное обеспечение хорошего качества.
• Разработка программного обеспечения гарантирует своевременную поставку программного обеспечения. Программный продукт теряет свою ценность, если он не доставлен вовремя. Своевременная поставка программного обеспечения увеличивает шансы на возврат инвестиций

Лучшие методы развертывания программного обеспечения

Выполните контрольный список развертывания

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

Выберите правильный метод развертывания

Внедрите программное обеспечение, которое легко интегрировать с существующими локальными приложениями и другими инструментами.

Автоматизируйте процесс развертывания

Развертывание новых версий программного обеспечения вручную — сложная задача, которая чревата человеческими ошибками.Автоматизация процесса развертывания снижает вероятность ошибок, увеличивает скорость развертывания и оптимизирует процесс

Принять непрерывную поставку

Adopting Continuous Delivery гарантирует включение кода для требуемого развертывания. Это достигается путем реализации приложения в среде прототипа, чтобы убедиться, что приложение хорошо функционирует и удовлетворяет требованиям после развертывания.

Использовать сервер непрерывной интеграции

Непрерывная интеграция серверов имеет решающее значение для любого успешного гибкого развертывания.Это гарантирует, что разработанная программа работает на машине разработчика, и помогает вам отрицать «ад интеграции».

.

Каковы наилучшие методы развертывания веб-приложений?

Чтобы получить обновленную версию этой статьи, прочтите нашу публикацию за 2020 год.

По крайней мере, за последнее десятилетие процесс передачи веб-приложений из среды разработчика в производственную среду пострадал из-за фундаментальных ограничений, налагаемых ресурсами, когда ограниченное количество сред разработки ограничивает возможность тестирования и развертывания.Это относится ко всему, что находится на сервере и взаимодействует с Интернетом, включая то, что мы называем веб-сайтами, CMS и веб-приложениями. Непрерывная интеграция и развертывание меняет это, но не все инструменты CI&D одинаковы…

Четырехуровневая модель развертывания

Каждый веб-разработчик должен ознакомиться с четырехуровневой моделью развертывания Development, Testing, Staging и Production . В большинстве случаев это «стандарт» для создания, тестирования и обслуживания веб-приложений, он выглядит следующим образом:

1. Разработка: Здесь разработчики вносят изменения в код, и обычно это локальная однопользовательская среда (например.г. ноутбук разработчика).

2. Тестирование: Это среда интеграции, в которой разработчики объединяют изменения для проверки совместной работы. Это также может быть среда обеспечения качества или UAT.

3. Staging: Здесь проверенные изменения запускаются в инфраструктуре и данных, эквивалентных производственным, чтобы гарантировать, что они будут работать должным образом после выпуска.

4. Производство: Это среда живого производства.

Эта модель существует уже некоторое время, и ее часто называют лучшей практикой для архитектур развертывания. Однако у него есть ряд проблем …

Четырехуровневая модель возникла в результате особого исторического слияния возрастающей сложности проектирования, тестирования и упаковки веб-приложений, а также физических ограничений вычислительной инфраструктуры. По мере роста сложности программного обеспечения разработчики начали использовать более сложные методы упаковки для развертывания этого программного обеспечения.Это позволило нам начать разбивать модель развертывания на серию шагов, которые более точно соответствовали видам тестирования, которые требовались для сложных приложений. Эти шаги стали нашей реальной средой. Мы начали перемещать код через эти уровни, при этом каждый уровень заявляет, что предлагает какую-то гарантию в отношении повышения согласованности данных и среды, а также качества кода .

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

Очевидно, что при сокращении количества сред очень сложно определить, безопасно и надежно ли вы тестируете и развертываете код, но даже с четырьмя средами будут проблемы :

• Слияние кода должно выполняться на уровне разработки, что приводит к конфликтам из-за отсутствия видимости.

• Изменения нелегко протестировать изолированно, что затрудняет отслеживание и проверку этих изменений (это проблема, когда у вас больше изменений, чем сред интеграции, поэтому обычно начинается с двух изменений!)

• Если те, кто занимается QA, не обладают техническими знаниями, изменения должны проходить тестирование в общих средах. Это может привести к тому, что эти среды очень легко заблокируются и возникнут проблемы с переделкой.

• Неисправные тестовые среды или изменения требуют тестирования всех изменений, а не только тех, которые требуют доработки.

• Неспособность поддерживать среды в актуальном состоянии с помощью производственной среды приводит к устаревшим данным тестирования, неправильным зависимостям операционной системы и другим факторам среды, которые могут привести к сбою производственных развертываний, требуя дорогостоящих и затруднительных откатов.

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

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

Непрерывная интеграция — это еще не полное решение

«… пока вы перемещаетесь по Blobs и запускаете их в производство, пока развертывание не управляется приложением как единым объектом, нет реальной разницы между этим и использованием FTP в производственной среде» — Ори Пекельман, Контейнеры — это новые статические двоичные файлы

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

Комбинация автоматизации и виртуализации дала нам непрерывную интеграцию (CI), которая в принципе является отличной идеей, но сама по себе не является полным решением.Основная цель CI — снизить риски в конвейере сборки, и он может делать это очень эффективно, однако любой конвейер сборки хорош настолько, насколько хорош его самое слабое звено, а во многих системах CI их до четырех…

1. Возможность согласования любой среды с производственной архитектурой

Многие инструменты CI используют Docker или аналогичный инструмент виртуализации для создания среды интеграции или тестирования для конкретного изменения. Это позволяет тестировать изменения изолированно, что очень важно, но также дает возможность протестировать их в идентичной операционной среде.

К сожалению, существует лишь несколько систем CI, которые могут точно подобрать контейнеры для производственной среды, что может привести к незначительным (но иногда критическим) различиям между тем, что развертывается. Также часто бывает очень сложно протестировать несколько связанных приложений одновременно, особенно если они работают в разных контейнерах. Большинство инструментов CI позволяют развернуть только один контейнер для тестирования, что означает, что вы можете тестировать только одно приложение, и ваши службы также должны работать в этом приложении или быть ограниченными тем, что предлагает поставщик CI.Не повезло, если они не соответствуют вашей производственной системе.

2. Возможность протестировать код с живыми данными в любое время

Инструменты

CI предназначены для создания системы для разработки, однако они также должны иметь возможность тестирования с копией реальных данных. У них должен быть доступ к этой копии при развертывании, и они должны иметь возможность обновлять эти данные в любое время. Ваш действующий экземпляр, вероятно, меняется, и вам нужно знать, что то, что вы создали на прошлой неделе, будет работать с данными за эту неделю, поэтому вам нужна возможность синхронизации по запросу, и вам нужны нетехнические пользователи, чтобы это было .

3. Среда может по-прежнему ограничиваться четырехуровневой моделью

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

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

4. Управление конвейером CI требует людей и знаний

В мире нет конвейера CI, который не требовал бы определенных знаний о том, как он работает, но большинство конвейеров CI возвращают сложность настройки разработчику. Фактически, целая дисциплина («DevOps») была разработана для управления сложностью решений, необходимых для решения этих проблем.

Хотя некоторым поставщикам CI удалось частично упростить этот процесс, в большинстве случаев это все еще нетривиальная проблема.Разработчики должны обладать высокой квалификацией и вкладываться в них, а поскольку существует так много разных способов сделать это, только часть этих навыков можно передавать. Многие предприятия нанимают людей на полную ставку только для создания своих конвейеров сборки и управления ими.

Разве автоматизация не должна была спасти нас от этого?

Так что же такое «лучшая практика»?

Идеальное решение для непрерывного развертывания (CD) должно преодолевать многие ограничения самоуправляемых или сторонних конвейеров непрерывной интеграции, предоставляя разработчику прямой, согласованный конвейер сборки и развертывания, который полностью воспроизводит производственную среду, вплоть до байтовый уровень.

На Platform.sh мы реализовали несколько технических решений, которые помогают разработчикам смягчать проблемы, описанные выше, и продвигать передовой опыт в новых направлениях …

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

• Среды разработки и тестирования клонируются из вашей производственной среды менее чем за две минуты.За исключением изменений конфигурации, внесенных в эту ветвь как часть ваших изменений, новые среды ВСЕГДА соответствуют своей производственной среде. Вы можете не только тестировать код с идеальной согласованностью инфраструктуры, но и тестировать изменения инфраструктуры.

• Среды могут синхронизировать свою базу данных, файлы и другие службы по запросу. Изменились ли ваши данные в реальном времени? Вы можете проверить это менее чем за две минуты. Нетехнический пользователь? Для этого есть кнопка.

• Все это полностью автоматизировано. Единственное, что требуется разработчику, — это некоторая информация о требуемой целевой конфигурации (например, какую версию PHP я использую или какие папки обслуживают статические ресурсы) — это базовая информация.

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

Эта архитектура полностью устраняет ограничения четырехуровневой модели. Вместо того, чтобы перемещать изменения по уровням ограниченных сред, разработчики могут изолировать отдельные изменения в неограниченном количестве одноразовых сред и применять любой рабочий процесс управления и тестирования, необходимый для подготовки этой производственной среды. Изменения можно выпускать по запросу, в том порядке, в котором они готовы, а не в порядке, продиктованном графиком выпуска, основанным на необходимости перепроверять все свои изменения на промежуточном сервере, поскольку вы не можете гарантировать, что они работают.При наличии надлежащего компакт-диска ваша скорость увеличится, а количество ошибок снизится (см. DevOps, чтобы узнать больше об этом)

В ближайшие месяцы мы собираемся посмотреть, как вы можете максимизировать эти преимущества с помощью двух серий сообщений в блоге. В первом будет рассмотрено, как передовая CD-модель Platform.sh может улучшить различные рабочие процессы разработки (например, Scrum), а во втором — помочь вам интегрировать Platform.sh с некоторыми другими инструментами.

—

Крис помогает командам разработчиков, новым клиентам и платформе.sh клиенты из Азиатско-Тихоокеанского региона получают максимальную пользу от использования продукта. Если вы хотите узнать больше о Platform.sh, узнать, как мы можем ускорить ваш рабочий процесс разработки, или просто поговорите, напишите ему здесь …

.