Куда задеплоить приложение

Что такое деплой

Деплой — процесс «разворачивания» веб-сервиса, например, сайта, в рабочем окружении. Рабочее окружение — место, где сайт запускается и доступен для запросов. Это может быть как готовый хостинг, так и своя собственная серверная инфраструктура.

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

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

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

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

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

Стоит сказать, что PaaS-платформы, такие как Heroku, берут деплой полностью на себя. Там достаточно выполнить коммит, и дальше все произойдет само. Цена за это — стоимость самой платформы.

• Шаги деплоя
• Автоматизация
• Zero Downtime Deployment
• Дополнительная литература

Шаги деплоя

Доставка кода на сервер

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

• Git: git checkout tag-name
• Docker: docker pull image-name:tag-name
• Apt (Пакет): apt-install application-package-name

Обновление базы данных

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

CREATE TABLE car ( id INT NOT NULL PRIMARY KEY, license_plate VARCHAR NOT NULL, color VARCHAR NOT NULL ); ALTER TABLE owner ADD driver_license_id VARCHAR; 

Запуск и остановка

Где-то в этом процессе происходит остановка старой версии и запуск новой. Если сначала остановить старую версию, а потом выполнить миграции и запустить новую, то мы получим простой (downtime) в работе сервиса. Так действительно работают многие, но это может быть болезненно для бизнеса и частых деплоев. Поэтому самые продвинутые проекты не останавливаются во время деплоя. О том, как это делать — ниже.

Автоматизация

Деплой нужно максимально автоматизировать, от этого зависит Time To Market — ключевая характеристика бизнес-ориентированных приложений. Чем быстрее и чаще мы доставляем изменения пользователю, тем лучше. Быстрее проверяем гипотезы, быстрее вносим исправления, быстрее оправдываем деньги, вложенные в разработку. Без автоматизации разработчики боятся выполнять деплой, он становится обузой, что приводит к снижению числа деплоев и регулярному стрессу для всей команды, с засиживанием на работе до позднего вечера.

Основных способа автоматизации три:

1. С помощью утилит, созданных для конкретных языков. Например, в Ruby это Capistrano, одна из первых и наиболее известных утилит подобного рода, ставшая популярной далеко за пределами Ruby. Основная проблема с такими инструментами — сильная завязка на язык.
2. С помощью Ansible, в который уже встроен модуль для деплоя. Идеально подходит для большинства ситуаций деплоя на управляемые сервера.
3. Системы оркестрации типа Kubernetes. Если они используются, то без автоматического деплоя никак.

Но, даже если автоматизация выполнена, все равно остается задача «запустить деплой». Запуск тоже автоматизируется. Существует целый подход, который называется Непрерывная доставка(continuous delivery). Его сложно внедрить, и он не везде подходит, но если получилось, то про деплой забывают. Он выполняется полностью сам без участия людей. Главное в таком варианте — хороший мониторинг и система оповещения (алертинг) для реакции на ошибки.

# https://docs.ansible.com/ansible/latest/collections/community/general/deploy_helper_module.html#examples - name: Initialize the deploy root and gather facts community.general.deploy_helper: path: /path/to/root - name: Clone the project to the new release folder ansible.builtin.git: repo: ansible.builtin.git ://foosball.example.org/path/to/repo.git dest: '>' version: v1.1.1 - name: Add an unfinished file , to allow cleanup on successful finalize ansible.builtin.file: path: '>/>' state: touch 

Zero Downtime Deployment

Если не предпринимать специальных шагов, то каждый деплой будет приводить к остановке (возможно частичной) сервиса. В это время пользователи либо увидят ошибку, либо сообщение о происходящем обновлении. Но такого не происходит на большинстве крупных сервисов в интернете. Почему? Из-за реализации подхода «деплой без даунтайма» (downtime — простои в работе сервиса).

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

1. Инфраструктура. Нужен балансировщик, который может переключать трафик (входящие соединения от браузеров или других систем) между старой и новой версиями кода. И желательно иметь как минимум два сервера, хотя это и не обязательно.
2. Деплой. Процесс деплоя без простоя значительно сложнее, чем с остановкой. Проще всего такой деплой делается на системах оркестрации, например, Kubernetes.
3. Культура кода. Обеспечить безостановочную работу невозможно без определенной культуры написания кода. Чтобы старая и новая версии могли работать одновременно, нужно следить за всеми интерфейсами. Важно соблюдение обратной совместимости (работа с api, базой, очередями и, в целом, любыми хранилищами).
4. База данных. Она должна быть обратно-совместима между старой и новой версией. Все миграции только вперед (их нельзя откатывать!) и только на добавление. Нельзя удалять и обновлять (переименовывать, менять тип) колонки и таблицы.

apiVersion: extensions/v1beta1 kind: Deployment metadata: name: tomcat -deployment -$ TARGET_ROLE > spec: replicas: 2 template: metadata: labels: app: tomcat role: $ TARGET_ROLE > spec: containers: - name: tomcat -container image: tomcat :$ TOMCAT_VERSION > ports: - containerPort: 8080 readinessProbe: httpGet: path: / port: 8080 

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

• Подробнее про Zero Downtime Deployment
• Инжиниринг в Booking
• Стратегии деплоя
• Stateless vs Statefull
• Ansible Deploy
• Среды разработки

Топ-5 Альтернатив Платформе Приложений Digital Ocean

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

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

Здесь мы обсудим платформу приложений Digital Ocean и некоторые из лучших компаний, которые предлагают альтернативные услуги этой платформы.

• 1 Что Такое Платформа Приложений DigitalOcean?
• 2 Характеристики Платформы для Разработки Приложений DigitalOcean
• 3 Топ-5 Альтернатив Платформе Приложений DigitalOcean
• 4 Back4App
• 5 Heroku
• 6 Firebase
• 7 Engine Yard
• 8 Cloudflare Workers
• 9 Заключение
• 10 ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
• 11 Что такое Digital Ocean App Platform?
• 12 Какие Основные Характеристики Digital Ocean App Platform?
• 13 Каковы лучшие альтернативы платформе приложений Digital Ocean?

Что Такое Платформа Приложений DigitalOcean?

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

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

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

Характеристики Платформы для Разработки Приложений DigitalOcean

Платформа приложений Digital Ocean включает в себя некоторые из наиболее популярных функций. Вот некоторые из его особенностей.

1. Управление жизненным циклом для повышения производительности программного обеспечения
2. Вертикальное и горизонтальное масштабирование.
3. Самодиагностика
4. Встроенное управление базами данных
5. Мониторинг
6. Поддержка Push-to-deploy, и т.д.

Топ-5 Альтернатив Платформе Приложений DigitalOcean

Хотя платформа приложений Digital Ocean превосходна, некоторые разработчики хотят найти ей альтернативу по своим причинам. Если вы ищете хорошую альтернативу для платформы приложений Digital Ocean, здесь у нас есть пять лучших вариантов, из которых вы можете выбрать.

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

Back4App

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

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

Основные Характеристики Back4App

1. В этой среде баз данных, основанной на запросах, база данных похожа на электронную таблицу.
2. REST API и GraphQL API делают работу с данными очень простыми.
3. Back4App предоставляет масштабируемые услуги хостинга.
4. Уведомления.
5. Поддержка запросов в реальном времени.

Heroku

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

Основные Характеристики Heroku

1. Heroku упрощает работу разработчиков, поскольку поддерживает современные языки с открытым исходным кодом.
2. Функции интеллектуального контейнера позволяют разработчикам очень быстро создавать свои внутренние функции и управлять ими.
3. Доступны функции гибкой среды выполнения.
4. Это платформа, которую вам стоит выбрать за ее надежность.
5. Доступны опции для горизонтального и вертикального масштабирования.

Firebase

Firebase- это управляемый бэкенд-сервис, который Google предоставляет для более простого процесса разработки приложений. Он множество полезных и удобных функций для разработки приложений.

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

Основные Характеристики Firebase

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

Engine Yard

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

Основные Характеристики Yard

• Доступны службы администрирования и анализа баз данных.
• Доступны службы проактивного мониторинга приложений.
• Сканирование безопасности инфраструктуры для обеспечения безопасности всей системы
• Ежегодные проверки состояния здоровья всей системы

Cloudflare Workers

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

Данный обширный сервис Cloudflare Workers представляет из себя JavaScript, который пишут разработчики. Этот код выполняется на стороне Cloudflare, который явно используется для обработки HTTP. Этот код JavaScript написан на уровне API service Worker.

Основные Характеристики Cloud Flare Workers

1. Высокая производительность приложения в глобальной сети
2. С управляемым бэкендом нет необходимости брать на себя ответственность за работу над бэкендом.
3. Параметры автоматического масштабирования позволяют разработчикам очень легко создавать приложения для простого развертывания.
4. Очень доступные по цене бэкенд-услуги.
5. Локальные службы хранения для облегчения управления хранилищем без необходимости иметь хранилище на вашей стороне.

Заключение

Разработка программного обеспечения становится все сложнее с каждым днем из-за необходимости управления серверами, хостинга и другими функциями бэкенда. Тем не менее, такие платформы, как платформа приложений Digital Ocean, делают работу чрезвычайно удобными для разработчиков.

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

ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ

Что такое Digital Ocean App Platform?

Это услуга PaaS от Digital Ocean.

Deploy

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

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

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

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

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

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

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

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

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

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

Читайте также Востребованные 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 — выберите подходящую и сразу освойте ее.

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

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

Деплой Java-приложения в облачную платформу Amazon Web Services (AWS)

Всем привет! Каждому разработчику рано или поздно приходиться деплоить свои приложения в облако. В моем случае, после разработки Телеграм-бота @rabotaUkraineBot стало просто необходимо найти ему приличный хостинг. Сама идея разработки бота и использованные инструменты для реализации описаны в отдельной статье. Кандидатами в выборе облачной платформы были сервисы четырех всем известных гигантов — Amazon Web Services(AWS), Google, Azure и Heroku. При выборе хостинга для себя я поставил следующие приоритеты: минимальная цена, удобство деплоя, наличие дополнительных сервисов, гибкость. Не буду Вас погружать в аналитику и сравнения, сообщу сразу победителя — AWS. Почему AWS, спросите вы? Потому что:

• год бесплатного использования AWS Free Tier, бесплатных ресурсов в рамках этого предложения для моей задачи хватает с лихвой;
• в AWS все Elastic, т.е. все гибкое и эластичное. Благодаря этому при деплое вашего приложения абсолютно не нужны навыки DevOps;
• AWS последние два года вкладывает колосальные средства в развитие, новые сервисы появляются каждый месяц.

А теперь перейдем к подготовке приложения и собственно самого деплоя в облака AWS. Для удобства использования был выбран сервис Elastic Beanstalk для деплоя приложения. С его помощью вы через браузер загрузите свое приложение и все! Да-да, AWS cам настроит инфраструктуру и выделит требуемый пул ресурсов. Так как мой бот написан на SpringBoot, все что нужно — это собрать war с помощью spring-boot-maven-plugin и проверить корректную работу приложения на локально развернутом Tomcat. Очень важное замечание, перед сборкой нужно в application.properties поставить номер порта 5000:

 server.port=5000 

• при сборке приложения не забыть настроить порт как указано выше;
• при регистрации в AWS вам понадобится платежная карта с минимум 1$ на счету (при валидации карты Amazon блокирует 1$);
• внимательно изучите ограничения бесплатного сервиса AWS Free Tier дабы не попасть на деньги;
• если после деплоя приложение не работает, как ожидалось, логи Tomcat вы найдете в меню Logs в Environment вашего приложения.

1. начать платить деньги согласно использованных ресурсов;
2. перейти на сервис Amazon Lightsail (там дешевле);
3. переписать приложение с использованием AWS Lambda и получить бесплатных хостинг;
4. открыть новый аккаунт с сервисами AWS Free Tier и задеплоить туда ваше приложение, т.е. оттянуть решение вопроса еще на один год.