Для того, чтобы создать свое веб приложение в наше время недостаточно уметь его разрабатывать. Важным аспектом является настройка инструментов по развертыванию приложения, мониторингу, а также управление и администрирование среды, в которой оно работает. Эра ручного развертывания уходит в забвение, даже для небольших проектов, инструменты автоматизации могут принести ощутимую пользу. При развертывании «руками», зачастую мы можем забыть перенести что-либо, учесть тот или иной нюанс, запустить забытый тест, этот список можно продолжать довольно долго.
Данная статья может помочь тем, кто только постигает основы создания веб приложений, и хочет немного разобраться в основных терминах и конвенциях.
Итак, построение приложений можно разделить все же на 2 части, это все что соотносится с кодом приложения, и все что соотносится со средой, в которой этот код выполняется. Код приложения в свою очередь также делится на серверный (тот, что выполняется на сервере, часто: бизнес логика, авторизация, хранение данных, и т.п.), и на клиентский (тот что выполняется на машине пользователя: часто интерфейс, и связанная с ним логика).
Начнем, пожалуй, со среды.
Основой для работы любого кода, системы, программного обеспечения является, Операционная система, поэтому ниже мы рассмотрим наиболее популярные системы, представленные на рынке хостингов, и дадим им краткую характеристику:
Windows Server – та самая Windows, но в серверной вариации. Некоторый функционал, доступный в клиентской(обычной) версии Windows здесь не присутствует, например, некоторые службы по сбору статистик, и подобного рода ПО, зато присутствует набор утилит для администрирования сети, базовое ПО для развертывания серверов (web, ftp, …). В общем и целом, Windows Server выглядит как обычная Windows, крякает как обычная Windows, однако, стоит в 2 раза дороже своего обычного собрата. Однако, учитывая, что развертывание приложения Вы будете делать скорее всего на выделенном/виртуальном сервере, конечная стоимость для Вас хоть и может возрасти, но не критично. Так как платформа Windows занимает подавляющее место на рынке пользовательских ОС, ее серверная редакция будет наиболее привычной большинству пользователей.
Unix-подобная система. Традиционная работа в данных системах не предполагает наличия привычного графического интерфейса, предлагая пользователю в качестве элемента управления лишь консоль. Для неопытного пользователя работа в таком формате может представлять трудность, чего только стоит выход из достаточно популярного в данных текстового редактора Vim, вопрос, связанный с этим за 6 лет набрал уже больше 1.8 млн просмотров. Основными дистрибутивами (редакциями) данного семейства являются: Debian — популярный дистрибутив, версии пакетов в нем ориентированы в основном на LTS (Long Term Support – поддержка в течение долгого времени), что выражается в достаточно большой надежности и стабильности системы и пакетов; Ubuntu – содержит дистрибутивы всех пакетов в их последних версиях, что может сказываться на стабильности, однако позволяет пользоваться функционалом, поставляемым с новыми версиями; Red Hat Enterprise Linux – ОС, позиционируемая для коммерческого использования, является платной, однако, включает в себя поддержку со стороны поставщиков ПО, некоторые проприетарные пакеты и пакеты драйверов; CentOS – opensource вариация Red Hat Enterprise Linux, отличается отсутствием проприетарных пакетов и поддержки.
Для тех, кто лишь постигает освоение данной области, моей рекомендацией будут системы Windows Server, либо Ubuntu. Если рассматривать Windows, то это в первую очередь привычность системы, Ubuntu – больше толерантности к обновлениям, и в сою очередь, например, меньше проблем при запуске проектов на технологиях требующих новые версии.
Итак, определившись с ОС, перейдем к набору инструментов, позволяющих деплоить (устанавливать), обновлять и мониторить состояние приложения или его частей на сервере.
Следующим важным решением будет – размещение вашего приложения, и сервера для него. На данный момент, самыми распространенными являются 3 пути:
В зависимости от выбранного пути, в дальнейшем изменится лишь тот факт, на ком, по большей части лежит ответственность за ту, или иную область администрирования. Если Вы хостите сами, то Вы должны понимать, что любые перебои с электричеством, интернетом, самим сервером, ПО, развернутом на нем – все это полностью лежит на Ваших плечах. Впрочем, для обучения и тестирования, этого более чем достаточно.
Если же у Вас нет лишней машины, способной сыграть роль сервера, то тогда Вы захотите воспользоваться вторым или третьим путем. Второй случай идентичен первому, за тем исключением, что Вы перекладываете ответственность за доступность сервера, и его мощности на плечи хостера. Администрирование сервера и ПО все еще под Вашим контролем.
И наконец, вариант с арендой мощностей облачных провайдеров. Здесь Вы можете настроить автоматизированное управление практически чем-угодно, не сильно вдаваясь в технические нюансы. Кроме того, вместо одной машины, вы можете иметь несколько параллельно запущенных инстансов (экземпляров), которые могут, например, отвечать за разные части приложения, при этом не сильно отличаясь по стоимости от владения выделенного сервера. А еще, тут в наличии инструменты оркестрирования, контейнеризации, автоматического деплоя, непрерывной интеграции и многого другого! Некоторые из этих вещей мы рассмотрим ниже.
В общем случае, инфраструктура сервера выглядит следующим образом: мы имеем так называемый «оркестратор» («оркестрирование» — процесс управления несколькими инстансами серверов), управляющий изменениями среды на инстансе сервера, контейнер виртуализации (опционален, но достаточно часто применяемый), позволяющий разделить приложение на изолированные логические слои, и ПО для Непрерывной Интеграции – позволяющее осуществлять обновление размещенного кода посредством «сценариев».
Итак, оркестрирование, позволяет Вам видеть статусы серверов, осуществлять «накатывание», или «откат» обновлений окружающей среды сервера, и так далее. На первых порах данный аспект вряд ли коснется Вас, поскольку чтобы чем-то оркестрировать, необходимо несколько серверов (можно и один, но зачем это нужно?), а, чтобы было несколько серверов, необходима потребность в них. Из инструментов данного направления, на слуху в основном Kubernetes, разработанный Google.
Следующая ступенька – виртуализация на уровне ОС. Сейчас широкое распространение получило понятие «докеризация», — которое пошло от инструмента Docker, предоставляющего функционал изолированных друг от друга контейнеров, но запускающихся в контексте одной операционной системы. Что это значит: в каждом из таких контейнеров можно запустить приложение, или даже набор приложений, которые будут считать, что они одни единственные во всей ОС, даже не подозревая о существовании кого-то еще на данной машине. Эта функция очень полезна как для запуска одинаковых приложений разных версий, либо просто конфликтующих приложений, а также для разделения кусочков приложения на слои. Этот слепок слоёв, впоследствии можно записать в образ, который использовать, например, для деплоя приложения. То есть, устанавливая этот образ, и разворачивая контейнеры, который он содержит вы получаете готовую среду для запуска Вашего приложения! На первых шагах Вы можете воспользоваться данным инструментом как в ознакомительных целях, так и для получения вполне реальной выгоды, разнеся логику приложения на разные слои. Но, тут стоит сказать, что докеризация нужна далеко не всем, и не всегда. Докеризация оправдана в случаях, когда приложение «фрагментировано», разбито на небольшие части, каждая отвечающая за свою задачу, так называемая «микросервисная архитектура».
Кроме того, помимо обеспечения среды, нам необходимо обеспечить и грамотный деплой приложения, включающий в себя всевозможные трансформации кода, установки связанных с приложением библиотек и пакетов, прогонки тестов, оповещений об этих операциях и так далее. Тут нам необходимо обратить внимание на такое понятие как «Непрерывная Интеграция» (CI – Continuous Integration). Основными инструментами в данной области на данный момент являются Jenkins (ПO для CI, написанное на Java, может показаться несколько сложным на старте), Travis CI (написан на Ruby, субъективно, несколько проще Jenkins’a, впрочем, все еще необходимо некоторые знания в области настройки деплоя), Gitlab CI (написан на Ruby и Go).
Итак, поговорив о среде, в которой предстоит работать Вашему приложению, настало время наконец посмотреть, какие инструменты предлагает нам современный мир, для создания этих самых приложений.
Начнем с основы: Backend (бэкэнд) – серверная часть. Выбор языка, набора основных функций и предопределенной структуры (фреймворка) здесь определяется в основном личными предпочтениями, но тем не менее, стоит упомянуть для рассмотрения (мнение автора насчет языков является достаточно субъективным, хоть и с претензией на непредвзятое описание):
Ну и финальная часть нашего приложения – наиболее осязаемая для пользователя – Frontend (фронтэнд) – является лицом Вашего приложения, именно с этой частью пользователь взаимодействует напрямую.
Не вдаваясь в детали, современный фронтэнд стоит на трех столпах, фреймворков (и не очень), для создания пользовательских интерфейсов. Соответственно, три наиболее популярных являются:
Резюмируя выше написанное, можно сделать вывод, что сейчас разворачивание приложения кардинально отличается от то, как этот процесс протекал раньше. Впрочем, никто не мешает осуществлять «деплой» по старинке. Но стоит ли немного сэкономленного времени на старте – огромного количества граблей, на которые предстоит наступить разработчику выбравшего этот путь? Я считаю, что ответ «нет». Потратив немного больше времени на ознакомление с этими инструментами (а большего и не требуется, ведь Вам необходимо понять, нужны ли они Вам в текущем проекте или нет), Вы сможете отыграть его, значительно сократив, например, случаи призрачных ошибок, зависящих от среды и проявляющихся только на продакшн-сервере, ночных разборов, что же привело к падению сервера, и почему он не запускается, и многого другого.
Данная статья может помочь тем, кто только постигает основы создания веб приложений, и хочет немного разобраться в основных терминах и конвенциях.
Итак, построение приложений можно разделить все же на 2 части, это все что соотносится с кодом приложения, и все что соотносится со средой, в которой этот код выполняется. Код приложения в свою очередь также делится на серверный (тот, что выполняется на сервере, часто: бизнес логика, авторизация, хранение данных, и т.п.), и на клиентский (тот что выполняется на машине пользователя: часто интерфейс, и связанная с ним логика).
Начнем, пожалуй, со среды.
Основой для работы любого кода, системы, программного обеспечения является, Операционная система, поэтому ниже мы рассмотрим наиболее популярные системы, представленные на рынке хостингов, и дадим им краткую характеристику:
Windows Server – та самая Windows, но в серверной вариации. Некоторый функционал, доступный в клиентской(обычной) версии Windows здесь не присутствует, например, некоторые службы по сбору статистик, и подобного рода ПО, зато присутствует набор утилит для администрирования сети, базовое ПО для развертывания серверов (web, ftp, …). В общем и целом, Windows Server выглядит как обычная Windows, крякает как обычная Windows, однако, стоит в 2 раза дороже своего обычного собрата. Однако, учитывая, что развертывание приложения Вы будете делать скорее всего на выделенном/виртуальном сервере, конечная стоимость для Вас хоть и может возрасти, но не критично. Так как платформа Windows занимает подавляющее место на рынке пользовательских ОС, ее серверная редакция будет наиболее привычной большинству пользователей.
Unix-подобная система. Традиционная работа в данных системах не предполагает наличия привычного графического интерфейса, предлагая пользователю в качестве элемента управления лишь консоль. Для неопытного пользователя работа в таком формате может представлять трудность, чего только стоит выход из достаточно популярного в данных текстового редактора Vim, вопрос, связанный с этим за 6 лет набрал уже больше 1.8 млн просмотров. Основными дистрибутивами (редакциями) данного семейства являются: Debian — популярный дистрибутив, версии пакетов в нем ориентированы в основном на LTS (Long Term Support – поддержка в течение долгого времени), что выражается в достаточно большой надежности и стабильности системы и пакетов; Ubuntu – содержит дистрибутивы всех пакетов в их последних версиях, что может сказываться на стабильности, однако позволяет пользоваться функционалом, поставляемым с новыми версиями; Red Hat Enterprise Linux – ОС, позиционируемая для коммерческого использования, является платной, однако, включает в себя поддержку со стороны поставщиков ПО, некоторые проприетарные пакеты и пакеты драйверов; CentOS – opensource вариация Red Hat Enterprise Linux, отличается отсутствием проприетарных пакетов и поддержки.
Для тех, кто лишь постигает освоение данной области, моей рекомендацией будут системы Windows Server, либо Ubuntu. Если рассматривать Windows, то это в первую очередь привычность системы, Ubuntu – больше толерантности к обновлениям, и в сою очередь, например, меньше проблем при запуске проектов на технологиях требующих новые версии.
Итак, определившись с ОС, перейдем к набору инструментов, позволяющих деплоить (устанавливать), обновлять и мониторить состояние приложения или его частей на сервере.
Следующим важным решением будет – размещение вашего приложения, и сервера для него. На данный момент, самыми распространенными являются 3 пути:
- Хостить (держать) сервер у себя, самостоятельно, — наиболее бюджетный вариант, но придется заказать у провайдера статический IP, дабы ваш ресурс не изменял своего адреса с течением времени.
- Арендовать Выделенный Сервер (VDS) – и самостоятельно заниматься его администрированием и масштабированием нагрузок
- Оплатить(часто при этом дают бесплатно попробовать функционал платформы) подписку на каком-либо облачном хостинге, где довольно распространена модель оплаты за использованные ресурсы. Наиболее яркие представители данного направления: Amazon AWS (дают бесплатный год пользования услугами, но с лимитом в месяц), Google Cloud (дают 300$ на счет, которые можно потратить в течение года на услуги облачного хостинга), Yandex.Облако (дают 4000 руб. на 2 месяца), Microsoft Azure (дают бесплатный доступ к популярным услугам на год, + 12 500 рублей на любые услуги в течение одного месяца). Таким образом, можно опробовать любого из данных провайдеров, не потратив ни копейки, но получив примерное мнение о качестве и уровне оказания услуг.
В зависимости от выбранного пути, в дальнейшем изменится лишь тот факт, на ком, по большей части лежит ответственность за ту, или иную область администрирования. Если Вы хостите сами, то Вы должны понимать, что любые перебои с электричеством, интернетом, самим сервером, ПО, развернутом на нем – все это полностью лежит на Ваших плечах. Впрочем, для обучения и тестирования, этого более чем достаточно.
Если же у Вас нет лишней машины, способной сыграть роль сервера, то тогда Вы захотите воспользоваться вторым или третьим путем. Второй случай идентичен первому, за тем исключением, что Вы перекладываете ответственность за доступность сервера, и его мощности на плечи хостера. Администрирование сервера и ПО все еще под Вашим контролем.
И наконец, вариант с арендой мощностей облачных провайдеров. Здесь Вы можете настроить автоматизированное управление практически чем-угодно, не сильно вдаваясь в технические нюансы. Кроме того, вместо одной машины, вы можете иметь несколько параллельно запущенных инстансов (экземпляров), которые могут, например, отвечать за разные части приложения, при этом не сильно отличаясь по стоимости от владения выделенного сервера. А еще, тут в наличии инструменты оркестрирования, контейнеризации, автоматического деплоя, непрерывной интеграции и многого другого! Некоторые из этих вещей мы рассмотрим ниже.
В общем случае, инфраструктура сервера выглядит следующим образом: мы имеем так называемый «оркестратор» («оркестрирование» — процесс управления несколькими инстансами серверов), управляющий изменениями среды на инстансе сервера, контейнер виртуализации (опционален, но достаточно часто применяемый), позволяющий разделить приложение на изолированные логические слои, и ПО для Непрерывной Интеграции – позволяющее осуществлять обновление размещенного кода посредством «сценариев».
Итак, оркестрирование, позволяет Вам видеть статусы серверов, осуществлять «накатывание», или «откат» обновлений окружающей среды сервера, и так далее. На первых порах данный аспект вряд ли коснется Вас, поскольку чтобы чем-то оркестрировать, необходимо несколько серверов (можно и один, но зачем это нужно?), а, чтобы было несколько серверов, необходима потребность в них. Из инструментов данного направления, на слуху в основном Kubernetes, разработанный Google.
Следующая ступенька – виртуализация на уровне ОС. Сейчас широкое распространение получило понятие «докеризация», — которое пошло от инструмента Docker, предоставляющего функционал изолированных друг от друга контейнеров, но запускающихся в контексте одной операционной системы. Что это значит: в каждом из таких контейнеров можно запустить приложение, или даже набор приложений, которые будут считать, что они одни единственные во всей ОС, даже не подозревая о существовании кого-то еще на данной машине. Эта функция очень полезна как для запуска одинаковых приложений разных версий, либо просто конфликтующих приложений, а также для разделения кусочков приложения на слои. Этот слепок слоёв, впоследствии можно записать в образ, который использовать, например, для деплоя приложения. То есть, устанавливая этот образ, и разворачивая контейнеры, который он содержит вы получаете готовую среду для запуска Вашего приложения! На первых шагах Вы можете воспользоваться данным инструментом как в ознакомительных целях, так и для получения вполне реальной выгоды, разнеся логику приложения на разные слои. Но, тут стоит сказать, что докеризация нужна далеко не всем, и не всегда. Докеризация оправдана в случаях, когда приложение «фрагментировано», разбито на небольшие части, каждая отвечающая за свою задачу, так называемая «микросервисная архитектура».
Кроме того, помимо обеспечения среды, нам необходимо обеспечить и грамотный деплой приложения, включающий в себя всевозможные трансформации кода, установки связанных с приложением библиотек и пакетов, прогонки тестов, оповещений об этих операциях и так далее. Тут нам необходимо обратить внимание на такое понятие как «Непрерывная Интеграция» (CI – Continuous Integration). Основными инструментами в данной области на данный момент являются Jenkins (ПO для CI, написанное на Java, может показаться несколько сложным на старте), Travis CI (написан на Ruby, субъективно, несколько проще Jenkins’a, впрочем, все еще необходимо некоторые знания в области настройки деплоя), Gitlab CI (написан на Ruby и Go).
Итак, поговорив о среде, в которой предстоит работать Вашему приложению, настало время наконец посмотреть, какие инструменты предлагает нам современный мир, для создания этих самых приложений.
Начнем с основы: Backend (бэкэнд) – серверная часть. Выбор языка, набора основных функций и предопределенной структуры (фреймворка) здесь определяется в основном личными предпочтениями, но тем не менее, стоит упомянуть для рассмотрения (мнение автора насчет языков является достаточно субъективным, хоть и с претензией на непредвзятое описание):
- Python – достаточно дружелюбный для неопытного пользователя язык, прощает некоторые ошибки, но в тоже может быть достаточно строг с разработчиком, дабы тот не натворил чего плохого. Уже достаточно взрослый и осмысленный ЯП, появившийся в 1991 году.
- Go – язык от компании Google, также достаточно дружелюбен и удобен, достаточно легко скомпилировать и получить исполняемый файл на любой платформе. Может быть простым и приятным, а может и сложным и серьёзным. Свеж и молод, появился относительно недавно, в 2009 году.
- Rust – немного старше предыдущего коллеги, вышедший в 2006 году, все еще достаточно молод относительно своих собратьев. Ориентирован на более опытных разработчиков, хотя все еще старается решать многие низкоуровневые задачи за программиста.
- Java – ветеран коммерческой разработки, появившийся в 1995 году, один из наиболее часто используемых языков при разработке корпоративных приложений на данный момент. С его базовыми концепциями и тяжелой настройкой среды исполнения может стать достаточно сложным для новичка.
- ASP.net – платформа для разработки приложений, выпущенная компанией Microsoft. Для написания функционала в основном используется язык C# (произносится Cи Шарп), появившийся в 2000 году. По своей сложности сопоставим с уровнем между Java и Rust.
- PHP – изначально использовавшийся для препроцессинга HTML, на данный момент хоть и удерживает абсолютное лидерство на рынке языков, прослеживается тенденция к спаду использования. Отличается низким порогом входа, простотой написания кода, но в то же время, при разработке достаточно крупных приложений, функционала языка может оказаться недостаточно.
Ну и финальная часть нашего приложения – наиболее осязаемая для пользователя – Frontend (фронтэнд) – является лицом Вашего приложения, именно с этой частью пользователь взаимодействует напрямую.
Не вдаваясь в детали, современный фронтэнд стоит на трех столпах, фреймворков (и не очень), для создания пользовательских интерфейсов. Соответственно, три наиболее популярных являются:
- ReactJS – не фреймворк, но библиотека. Собственно, от гордого звания фреймворк отличается лишь отсутствием некоторых функций «из коробки», и необходимостью устанавливать их вручную. Таким образом, есть несколько вариаций «приготовления» данной библиотеки, формирующие своеобразные фреймворки. Для новичка может быть сложноват, из-за некоторых базовых принципов, и достаточно агрессивной настройки сборочной среды. Впрочем, для быстрого старта можно воспользоваться «create-react-app» пакетом.
- VueJS – фреймворк для построения пользовательских интерфесов. Из данной троицы по праву забирает титул самого дружелюбного к пользователю фреймворка, для разработки во Vue порог вхождения ниже чем у остальных приведенных собратьев. Кроме того, среди них он самый молодой.
- Angular – считается самым сложным из приведенных фреймворков, единственный требует наличия TypeScript (надстройка над языком Javascript). Зачастую применяется для построения больших корпоративных приложений.
Резюмируя выше написанное, можно сделать вывод, что сейчас разворачивание приложения кардинально отличается от то, как этот процесс протекал раньше. Впрочем, никто не мешает осуществлять «деплой» по старинке. Но стоит ли немного сэкономленного времени на старте – огромного количества граблей, на которые предстоит наступить разработчику выбравшего этот путь? Я считаю, что ответ «нет». Потратив немного больше времени на ознакомление с этими инструментами (а большего и не требуется, ведь Вам необходимо понять, нужны ли они Вам в текущем проекте или нет), Вы сможете отыграть его, значительно сократив, например, случаи призрачных ошибок, зависящих от среды и проявляющихся только на продакшн-сервере, ночных разборов, что же привело к падению сервера, и почему он не запускается, и многого другого.
