Запуск в продакшн что это
Перейти к содержимому

Запуск в продакшн что это

  • автор:

Что представляет собой веб-приложение в продакшне?

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

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

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

Если вы начали работу в таком окружении, а затем приступили к созданию и развёртыванию веб-приложения с нуля, то очень быстро узнаете, что такое «до опасного поверхностные знания».

В отрасли существует ряд решений для решения этой проблемы: управляемые веб-приложения (Beanstalk, AppEngine и т. д.), управление контейнерами (Kubernetes, ECS и т. д.) и многие другие. Они хорошо работают из коробки и могут отлично решить проблему. Но это излишняя сложность при запуске веб-приложения, и обычно такие решения «просто работают».

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

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

Начало

Представьте, что ваш бюджет на хостинг $500 в год, поэтому вы решили арендовать один сервер t2.medium на Amazon AWS. На момент написания статьи это около $400 в год.

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

Рис. 1

Пока этого достаточно. На самом деле такая система может проработать довольно долго. Сервис маленький, менее 10 посещений в день. Возможно, и маленького инстанса было достаточно, но мы с оптимизмом смотрим на рост компании, поэтому предусмотрительно взяли t2.medium.

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

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

Теперь система выглядит примерно так:

Рис. 2

Вы повысили надёжность базы данных, и пришло время подготовиться к «хабраэффекту», прогнав на сервере нагрузочный тест. Всё идет вроде нормально, пока не появляются ошибки 500, а затем поток ошибок 404, поэтому вы изучаете, что произошло.

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

Вы исправляете проблему с автоматическим перезапуском, создав службу systemd , запускаете веб-сервер, который одновременно решает проблему с записью логов. Затем запускаете ещё один нагрузочный тест для проверки.

И опять видим ошибки 500 (к счастью, без 404). Вы проверяете логи. Обнаруживается, что пул подключений к базе данных заполнен, потому что было установлено маленькое ограничение в 10 подключений. Обновляете ограничение, перезапускаете БД и снова запускаете нагрузочный тест. Всё идёт хорошо, поэтому вы решаете рассказать о своём сайте на Хабре.

День запуска

Матерь божья! Ваш сервис мгновенно становится хитом. Вы попали на главную страницу и получаете 5000 просмотров за первые 30 минут — и видите комментарии. Что там пишут?

У меня ошибка 404, поэтому пришлось открыть кэшированную версию страницы. Вот ссылка, если кому надо: …

Ничего не открывается. Кроме того, у меня отключен Javascript. Почему люди считают, что я хочу грузить их Javascript на 2 МБ…

Загрузка домашней страницы занимает 4 секунды. Traceroute из Австралии показывает, что сервер размещен где-то в Техасе. Кроме того, почему первая страница загружает 2 мегабайта Javascript?

В безумной спешке вы настраиваете Nginx в качестве обратного прокси-сервера для своего приложения и настраиваете там статическую страницу 404. Вы также изменяете процедуру деплоя, чтобы отправлять статические файлы в S3: это необходимо для работы CloudFront CDN, чтобы сократить время загрузки в Австралии.

Рис. 3

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

Проблемы с производительностью

Проходят месяцы. Аудитория растёт. Сайт начинает тормозить. Вы заметили в мониторинге CloudWatch, что это происходит только между 00:00 и 12:00 UTC. Из-за одинакового времени начала и окончания лагов вы догадываетесь, что это связано с запланированной задачей на сервере. Проверяете crontab и понимаете, что одно задание запланировано на полночь: резервное копирование. Конечно, резервное копирование занимает двенадцать часов и приводит к перегрузке базы данных, вызывая значительное замедление работы сайта.

Вы читали об этом раньше — и решаете запускать резервные копии в подчинённой БД (slave). Затем вспоминаете: у вас же нет подчинённой базы данных, поэтому её нужно создать. Не имеет большого смысла запускать базу данных slave на том же сервере, поэтому вы решаете расширяться. Создаёте два новых сервера: один для базы данных master и один для базы данных slave. Изменяете резервное копирование для работы с подчинённой БД.

Рис. 4

Рост команды

Некоторое время всё идёт гладко. Проходят месяцы. Вы нанимаете разработчиков. Один из новичков вносит баг, который валит производственный сервер. Разработчик обвиняет среду разработки, которая отличается от продакшна. В его словах есть доля правды. Поскольку вы разумный человек с хорошим характером, то воспринимаете это событие как урок.

Пришло время создать дополнительные окружения: промежуточное (staging), QA и продакшн. К счастью, вы с первого дня автоматизировали создание инфраструктуры, так что всё проходит гладко и просто. У вас также с первого дня налажены хорошие практики непрерывной доставки, поэтому вы легко собираете конвейер из новых веток.

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

Рис. 5

Уверенный в том, что вы справитесь с нагрузкой, вы снова упоминаете свой сайт на Хабре. О чудо, он выдерживает трафик. Большой успех!

Всё вроде шло хорошо, пока вы не пошли проверять логи. На проверку 12 серверов ушёл час (по четыре сервера в каждом окружении). Настоящая нервотрёпка. К счастью, денег хватает на покупку стека ELK (ElasticSearch, LogStash, Kibana). Вы развёртываете его и направляете туда серверы со всех окружений.

Рис. 6

Теперь, можно снова обратиться к логам, вы смотрите их — и замечаете что-то странное. Они полны таких записей:

GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1

Вы не используете PHP или WordPress, так что это довольно странно. Вы замечаете похожие подозрительные записи в логах серверов БД и удивляетесь, как они вообще подключились к интернету. Пришло время внедрять публичные и частные подсети.

Рис. 7

Ещё раз проверьте логи. Попытки взлома остались, но теперь они ограничены портом 80 на балансировщике нагрузки, что немного утешает, потому что серверы приложений, серверы БД и стек ELK больше не в открытом доступе.

Несмотря на централизованные логи, вам надоело искать даунтаймы, проверяя логи вручную. Через Amazon CloudWatch вы настраиваете оповещения по электронной почте, когда диск, CPU и сеть достигают 80% утилизации. Отлично!

Бесперебойная работа

Просто шучу! В программном обеспечении нет такого понятия, как бесперебойная работа. Что-то обязательно сломается. К счастью, теперь у вас много инструментов, чтобы справиться с ситуацией.

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

На рынке много вариантов хостинга, которые берут на себя бóльшую часть упомянутых задач. Вместо самостоятельной разработки вы можете положиться на Beanstalk, AppEngine, GKE, ECS и т. д. Большинство этих сервисов автоматически настраивают разумные разрешения, подсистемы балансировки нагрузки, подсети и т. д. Это устраняет существенную часть нервотрёпки при запуске веб-приложения на быстром и надёжном бэкенде, который работает в течение длительного времени.

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

Заключение

В этой статье опущено много деталей. В ней не описывается, как автоматизировать создание инфраструктуры, как подготовить и настроить серверы. Не рассматривается создание сред разработки, настройка конвейеров непрерывной доставки, а также выполнение развёртываний и откатов. Мы не затронули сетевую безопасность, разделение ключей и принцип минимальных привилегий. Не рассказали о важности неизменной (immutable) инфраструктуры, stateless-серверов и миграций. Каждая из тем требует отдельной статьи.

Цель этого поста — общий обзор, как должно выглядеть разумное веб-приложение в продакшне. Будущие статьи могут ссылаться сюда и расширять тему.

На данный момент это всё.

Спасибо за чтение и удачного кодирования!

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

  • продакшн
  • деплой веб-приложения
  • надежная работа

Что такое продакшн рекламного видеоролика

Продакшн — широкий термин, в переводе с английского (production) буквально означающий “производство”. Чаще всего используется в отношении киноиндустрии, медиа, видеорекламы, видеоконтента, последнее время и в IT-сфере. Об этом заимствованном термине и поговорим.

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

  1. Препродакшн — это стадия, когда вы готовитесь к производству.
  2. Продакшн — это стадия непосредственного производства.
  3. Постпродакшн — это стадия превращения всего произведенного контента в итоговый продукт (фильм, мультфильм, музыкальный клип, трейлер к видеоигре и т.п.).

В свою очередь эти три ключевых этапа делятся на более мелкие.

Продакшн, по сути, подразумевает создание некоего медиапродукта (еще не финального) либо определенный этап работы над ним.

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

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

Прояснилось? Еще не сломали мозг? Тогда поехали дальше!

Когда объясняешь что такое продакшн

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

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

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

1. Дикторское озвучивание

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

Как правило, озвучивание видеоряда делается сразу после согласования Клиентом сценария.

Пример ТЗ для диктора

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

Все участники команды: моушн-дизайнеры, аниматоры, VFX-художники и моделлеры проводят свой собственный R&D. Чем дальше развивается CG-индустрия, тем больше времени уходит на R&D.

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

3. Создание графики (стайлфреймов, иллюстраций)

Если говорить о 2D графике, работают иллюстраторы и графические дизайнеры под руководством арт-директора. Сначала на основе раскадровки рисуют 2-3 иллюстрации для согласования стилистики графики и персонажей. После чего прорисовывают остальные сцены.

Широкоформатная иллюстрация QWQER Коптер и небоскреб QWQER

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

Игральные кубики Planet Of Bets Лабиринт и мозг Planet Of Bets Все стайлфреймы к PlanetOfBets 2

4. Анимация

Пришла пора “оживить” всю картинку в кадре. Этот этап называется анимацией и он также делится на две части: черновую и чистовую анимацию.

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

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

Заключение?

После чистовой анимации в анимационных роликах или съемок, если это съемочный рекламный ролик, основная работа над роликом заканчивается. Это финал продакшена.

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

Следуй за “ВидеоЗайцем”! Все тайны будут раскрыты ��

Продакшн

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

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

Терминология

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

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

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

Специалистами также отдельно выделяется стадия пост-продакшна (от англ. postproduction ) — период обработки материала, который следует сразу после съёмочного процесса, может включать в себя компьютерную графику, титрование, монтаж, озвучание, обработка и так далее.

Классификация

Продакшн в медиа и в сфере развлечений:

  • Кинопроизводство — полный художественный процесс создания фильма, включающий процесс организации производства, определение техники и технологии создания фильма, пост-продакшн (последующая обработка материала после съёмок эпизодов фильма).
  • Радио и ТВ — создание эфирного пакета телеканала или радиостанции (заставок, джинглов, отбивок), эфирного промо.
  • Аудио — музыкальное оформление проекта, создание музыкального произведения (аранжировки) или использование музыкальных библиотек, подбор звуковых эффектов, монтаж и мастеринг.
  • Видео — создание видеопроекта, фильма, ролика.
  • Реклама — создание рекламных аудио-, видео-, мультимедиа-материалов.

См. также

Ссылки

  • Продакшн в Яндекс. Словарях
  • Викифицировать статью.
  • Найти и оформить в виде сносок ссылки на авторитетные источники, подтверждающие написанное.
  • Продакшн
  • Радио
  • Телевидение
  • Индустрия кино и видео
  • Мультимедиа
  • Компьютерная графика
  • Реклама

Wikimedia Foundation . 2010 .

Deploy

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

«IT-специалист с нуля» наш лучший курс для старта в IT

Когда сайт загружают на сервер или хостинг, говорят, что его деплоят или «выкатывают». Также процесс называют деплоингом (deploying). Еще есть выражение «отправка в продакшн» или «на прод» — оно описывает этот же процесс.

Продакшн (production) — запущенная версия сайта, та, которую видят пользователи. Так что отправка в продакшн — тоже деплой. Точнее, одна из его разновидностей, потому что разворачивать приложение могут не только для конечных пользователей, но и, например, на тестовом сервере.

Само английское слово deploy в переводе означает «развертывать».

Профессия / 8 месяцев
IT-специалист с нуля

Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

vsrat_7 1 (1)

Для чего нужен деплой

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

Без деплоя код не дойдет до сервера и так и останется на рабочей машине программиста. А писать прямо на сервере — очень плохая идея даже в теории: это сложно, неудобно и может его «уронить». Тем более часто рабочая среда — не один сервер, а сотни разных устройств, и процесс развертывания и запуска в продакшн довольно сложный.

Читайте также Востребованные IT-профессии 2023 года: на кого учиться онлайн

Что именно деплоят

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

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

Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить

Как выглядит жизненный цикл кода

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

1. Разработчик пишет код. Это может быть принципиально новый сервис или доработка к уже существующему, обновление сайта или что-то еще. Он делает это на локальном компьютере.

2. Когда код готов, разработчик коммитит его: загружает в репозиторий, специальную «общую папку» команды, например на сервисе GitHub. Там его смогут увидеть и прокомментировать другие разработчики — это называется код-ревью.

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

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

5. В нужное время происходит деплой. Код уходит в продакшн, появляется на серверах, его видят пользователи.

Что входит в деплой

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

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

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

Деплоймент пошагово: как это выглядит

Вот как примерно выглядит процесс:

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

Автоматизация деплоя

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

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

  • с помощью надстроек и утилит, написанных для конкретных языков или библиотек;
  • через системы автоматизации и управления, такие как Ansible, или через облачные сервисы для веб-приложений вроде Heroku;
  • с помощью оркестраторов, платформ, которые управляют контейнерами, — самым известным примером считается Kubernetes.

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

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

Избежание простоя: что такое подход Zero Downtime

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

При использовании подхода Zero Downtime Deployment сайт не останавливается. Это происходит, потому что в таком случае сначала запускается новая версия, а потом отключается старая.

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

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

Как начать деплоить

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

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

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

IT-специалист с нуля

Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.

картинка (75)

Статьи по теме:

  • «Ты совсем о нас не вспоминаешь» или 20 строчек на Python, чтобы порадовать родителей
  • Чем занимается DevOps-инженер в международной IT-компании?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *