cute british shorthair cat with business tie in front of a laptop and looking at the camera
Содержание
Deploy (деплой) — это процедура запуска веб-сайта или приложения на сервере, хостинге. Деплой позволяет конечным пользователям получить доступ к ресурсу через сеть.
Причем этой сетью может выступать как интернет, так и любая локальная сеть. Все зависит от предназначения веб-ресурса.
Возможно, вы сталкивались с такими выражениями по отношению к сайту, как «отправить в продакшн», «выкатить», «отправить на прод» или «деплоить». Вот это выкатывание сайта на хостинг и есть deploy, а продакшн — готовая версия сайта, с которой могут работать пользователи.
С английского deploy переводится как «развертывание».
С тем, как именно происходит деплой, мы с вами разберемся ниже.
Читайте также: Хрюши позвали накатывать на галере: краткий разговорник программиста
Без деплоя приложение или сайт будут доступны только на локальном устройстве разработчика. Для того, чтобы пользователи сети смогли взаимодействовать с веб-проектом, его нужно загрузить на сервер.
После написания и тестирования готового продукта, его нужно установить, настроить и запустить на сервере, после чего им сможет воспользоваться широкий круг людей. Без деплоя код просто будет лежать на локальном компьютере или репозитории.
Писать веб-сайт сразу на сервере — не лучшее решение. Как минимум сервер может «упасть». К тому же, это не очень удобно, а рабочей средой может выступать не только этот сервер, а и другие устройства, что делает развертывание сложным процессом.
Деплоить нужно все, что работает по сети. Сюда можно отнести веб-приложения, сайты и другие решения. Причем, как говорилось выше, это могут быть как сервисы, работающие в локальных сетях, так и проекты в интернете. То есть внутренний корпоративный портал вашей компании тоже когда-то деплоили. И раз уж он работает, то деплой прошел успешно 🙂
Деплоить можно не весь проект, а некоторые его части. Так происходит, когда в крупных продуктах разный функционал или апгрейды создают несколько разработчиков. В таком случае каждую новую функцию можно деплоить отдельно от остальных. Создание распределенных приложений, состоящих из разных частей, выглядит как серия независимых деплоев.
Ненадолго остановимся на том, как происходит разработка в ІТ-компаниях и какая роль программного кода в жизненном цикле отведена деплою:
Теперь рассмотрим каждый этап деплоя и чем он примечателен.
Код на сервер доставляют разными способами в зависимости от того, как он упакован. Изредка бывает и так, что код в виде набора файлов можно просто скопировать на сервер. Но в большинстве случаев его обновляют через Git.
Еще один устаревший, но в некоторых случаях все еще актуальный способ — деплой через обычные пакетные менеджеры Linux. В ниши дни встречается крайне редко.
В файлах предыдущей версии проекта указываются связи с новыми кусками кода. Все новые функции объединяются в структуру сервиса. Файлы проекта — в общую систему, которая может функционировать.
Помимо этого, обновленная версия сайта или приложения обычно требует изменений в базе данных. Для этого запускаются скрипты миграции, в которых содержатся правила обновления БД. Это нужно делать до деплоя или во время него.
В процессе деплоя нужно остановить старую и запустить новую версии проекта. Нежелательно останавливать старую версию, проводить миграции, а после запускать новую. Таким образом произойдет простой в работе проекта (он же downtime). Приостановка может быть вредной для бизнесс-процессов, поэтому топовые сервисы не делают простоев во время деплоя.
После остановки / запуска сервис начнет работу уже с новыми функциями и обновлениями.
Чем быстрее конечный пользователь продукта будет получать обновления и доработки сервиса, тем будет лучше для всех. Да и весь процесс деплоя занимает приличное количество времени и ресурсов. К тому же возникает вероятность ошибок при внедрении новой версии.
Поэтому deploy лучше автоматизировать — для этого существует три способа. Какой из них выбрать — зависит от размеров вашего проекта, его бюджета и технологий, которые в нем используются:
Запуск деплоя также можно автоматизировать. Для этого нам понадобится Continuous Delivery или «непрерывная доставка» — подход, когда обновление ПО происходит с большей частотой и меньшими «порциями».
Такой подход непросто внедрить, подойдет он далеко не для всех проектов, но если уже удалось — про деплой можно забыть, так как проходит он автоматически. Но стоит отметить, что при таком подходе очень важно иметь качественный мониторинг ошибок и систему оповещения. А то мало ли что.
Читайте также: Как писать деплой-скрипты: гайд от релиз-менеджера Luxoft
Как мы уже говорили ранее, перерывов между остановкой старой версии проекта и запуском новой в идеале быть не должно. Во время таких проектов пользователи не имеют доступа к сайту, а для больших бизнесов это означает потерю прибыли. Тем более крупные проекты деплоятся достаточно долго.
Именно по этому большие проекты используют подход Zero Downtime Deployment или «деплой без простоев». Такой метод позволяет запустить новую версию сайта еще до остановки старой, а это значит, что в определенный момент работают обе версии.
Этот процес автоматизирован, и специальные технологии отслеживают тот момент, когда новая версия уже полноценно запустилась. Только после этого старая версия отключается.
Что нужно для успешного Zero Downtime Deployment:
Zero Downtime Deployment — объемная тема, достойная отдельной статьи. Возможно, в будущем мы к ней вернемся.
Инструментов для успешного деплоя существует довольно много, и для того, чтобы было проще разобраться, мы разделим их на три категории:
Артефакты — искусственно созданные элементы программы. Для их управления существует большое количество инструментов — JFrog Artifactory, Nexus Sonatype и другие. Давайте вкратце рассмотрим самые популярные.
JFrog Artifactory. Условно бесплатный менеджер хранилища, считающийся одним из самых популярных в мире. Инструмент выступает в качестве прокси между средствами для сборки и внешней средой. Artifactory способен кешировать удаленные артефакты, что убирает необходимость их повторной загрузки.
Apache Archiva. Менеджер репозитория артефактов для крупных проектов. По заявлениям компании-собственника, отлично взаимодействует с такими инструментами, как Maven, Continuum, ANT.
Nexus Sonatype. Репозиторий артефактов, работающий с проектами, написанными на всех популярных языках – C / C++, C#, Go, Java, JavaScript, Kotlin, PHP, Ruby, Python… Всего более двух десятков. Из приятного — бесплатная версия довольно функциональна, ее вполне может хватить для большинства проектов.
Управление конфигурацией позволяет разным версиям проекта быть совместимыми на протяжении всего жизненного цикла.
Рассмотрим несколько инструментов, которые помогут правильно управлять конфигурациями.
Ansible. Система управления конфигурациями, созданная с помощью Python. Этот инструмент отличается от остальных отсутствием состояния. Ранее аналогичные решения были направлены на управление состоянием конфигурации. После запуска и получения необходимой конфигурации, такой инструмент попытается исправить нынешнюю конфигурацию проекта. При новом подходе есть только компоненты с отсутствием состояния, а новые версии кода выступают артефактами, которые меняют существующие.
Другие преимущества Ansible — это открытый исходный код, возможность тестирования управления конфигурациями (ведь это тоже код, который нужно тестировать) с помощью фреймворка Molecule, использование языка сериализации YAML (более простой и понятный, чем JSON или XML).
Из минусов — сервер должен работать только под Unix / Linux, хотя все рабочие станции могут быть на Windows. Но такая конфигурация используется и системами-конкурентами, представленными ниже. Так что тут без вариантов — нужно осваивать Linux.
OpsCode Chef. Инструмент для более классических приложений (без отсутствия состояний), не решающий задачи stateless-приложений или проектов в облаке. Проект был очень популярным еще лет 10 назад, но развитие облачных технологий сильно снизило его популярность. В качестве DSL использует Ruby.
Puppet. Менее популярен, чем предыдущие два. Неплохо подойдет для провизионирования и работы с аппаратной частью, но поддержка работы с управлением конфигурациями современных веб-приложений тут отсутствует. Языком конфигурации тут выступает свой PuppetDSL – свой собственный язык, который нужно будет дополнительно освоить. Как и «шеф-повар», был неплох для 2013-го, но в 2023-м это скорее флоп, чем топ.
Saltstack. Как и Ansible — система управления конфигурациями с открытым исходным кодом, написанной на Python. Также использует простой в освоении YAML.
Saltstack и Ansible стремительно набирают популярность, в то время как Chef и Puppet скорее переходят в нишевый сегмент устаревших приложений. Но выбирать вам.
Terraform. ПО с открытым исходным кодом, которое поможет описать инфраструктуру проекта в виде кода — от сетевых компонентов до образов сервера и внешних облачных сервисов. Проект существует с 2014 года, и за это время оброс полезными плагинами и довольно обширным сообществом. Terraform способен поддерживать любое окружение — локальное, облачное, ваш вариант.
В Terraform используется JSON и собственный декларативный язык конфигурации HCL. В последних версиях в HCL представлены большинство логических функций и классов, что и в других популярных языках программирования, что позволяет разработчику быстро и удобно разобраться с Terraform.
AWS CloudFormation. Главный минус системы — она работает только для Amazon, детищем которого и является. Соответственно, если вы создаете приложение на AWS — для всего остального он не подходит. С другой стороны, Terraform также работает с AWS Web Services.
Jenkins. Сложно говорить о деплое и не вспомнить о сервере автоматизации Jenkins. Написан на Java, работает с Windows, Mac OS и Unix-системами. Легко и быстро устанавливается и настраивается, дружит со многими инструментами CI/CD. Едва ли не стандарт для инструментов непрерывной интеграции, хотя и без возможности управления версиями и с не самым новаторским интерфейсом.
Ну и как не упомянуть маскота Jenkins с логотипе платформы — милого британского дворецкого, который периодически становится героем мемов и фотожаб, создаваемых ценителями.
Деплой — логичный этап развития любого веб-сайта или приложения, у которого есть серверная часть и пользователи, которые получают к нему доступ со своих локальных устройств. Без деплоя доступ к вашему продукту никто из них не получит.
Процесс деплоя часто бывает непрост, но существует много инструментов, позволяющих автоматизировать запуск проекта на сервере и сильно облегчить жизнь разработчикам, а также внедрять новые версии проекта без его остановки и простоев.
Так что осваивайте теорию, разбирайтесь с инструментами и удачи с деплоем. Она вам пригодится 😉
Сегодня мы поговорим о том, как выбрать лучшие курсы Power BI в Украине, особенно для…
В 2023 году во всех крупнейших регионах конкуренция за вакансию выросла на 5–12%. Не исключением…
Unicorn Hunter/Talent Manager Лина Калиш создала бесплатный трекер поиска работы в Notion, систематизирующий все этапы…
Edtech-стартап Mate academy принял решение отправить своих работников в десятидневный отпуск – с 25 декабря…
Служба безопасности Украины задержала в Киеве 46-летнего программиста, который за деньги устанавливал шпионские программы и…
IT-специалист Джордан Катлер создал и выложил на Github подборку разнообразных ресурсов, которые помогут достичь уровня…