Чеклист для создания и публикации веб-приложений

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

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

Итак, построение приложений можно разделить все же на 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). Зачастую применяется для построения больших корпоративных приложений.

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

Комментарии 15

    +1
    Ubuntu – содержит дистрибутивы всех пакетов в их последних версиях

    Неправда, так же протухшие на несколько месяцев, а на LTS и того больше


    что может сказываться на стабильности

    Может, но иногда рассказывают, что Ubuntu наоборот стабильнее Debian. Перевёл свои сервера с Debian на Ubuntu и не жалею (впрочем, лично у меня оба работают одинаково стабильно)


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

    Существуют всякие DynDNS для динамических IP, поддержка встроена во многие домашние роутеры, я таким в 2009-2011 баловался (через GPRS причём. Тормозило, но работало)


    Если же у Вас нет лишней машины

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


    Зачем нужны CI и фронтенд-фреймворки, из поста осталось непонятно (сам я в курсе, если что)

      +7
      Выбор автором серверных языков правда является субъективным, без претензии на объективность.
      Нету node.js, нету .net core…
      А вообще статья с абсолютно непонятной ца. Тому, кто поймёт в ней все слова, она ничего нового не скажет. В тому, кто не поймёт — тем более.
        0
        И руби, и хаскеля, и…
        Зачем было упоминать этот тезис, если изначально автор акцентировал внимание — не ясно.
        (Питон кстати хорошая параллель для ноды на беке, нода сейчас нужна в основном для SSR)
        40+ человек добавили в закладки. На момент среза статистики 1.5к просмотров, что вполне неплохо, статья нашла своих читателей.
          0
          Жаль, что нет статистики, сколько из этих 1.5к всё-таки увидели заявленный чек-лист…
        +7

        То что вы написали это не чеклист создания и публикации приложения.
        Извиняюсь конечно, но ваш стиль изложения напомнил старый прикол.
        Хочется добавить из статьи-диалога про k8s — да ну вас нафиг, пойду деплоить на heroku — по аналогии с финалом прикола.


        старый прикол

        Короче, дело было во времена моего обучения на 3-м или 4-м курсе универа… Была у нас военная кафедра, на которой будущих специалистов еще к тому же обучали быть командирами взвода (или может роты,… короче не помню какой мотострелковой единицы)… На кафедру я с завидным постоянством забивал большой болт, так как маршировать (а чаще – просто плац подметать...), меня как-то не фонтанировало…
        Но вот решил под конец семестра я туда заглянуть и полушать, мож че и дельное скажут… Сидим с другом и бурные выходные обсуждаем…
        Но тут залетает в аудиторию бравый такой майор или подпол… уже не упомнишь… и во всю глотку орет: "А сеня у нас контрольная работа по тактике!!! "…
        Выпадаю я в сухой осадок, так как понимаю, что тактику я знаю не больше, чем какой-нибудь сопромат (я на юрфаке учился...), но бежать уже некуда и тихо стал смиряться с тем, что как-то придется выкручиваться… Друг немного успокаивает: — я, грит, почти на всех лекциях был (читай – почти весь плац вымел)))…
        В общем, разделил нас майоро-подпол на два варианта и каждому варианту – по два вопроса… Первый вопрос я уже не помню,… что-то, что мне друг помог написать, а вот второй меня поставил в откровенный тупик… Звучал он так: "Действия командира взвода (роты) на марше при переправе через водные преграды"…
        Сижу я и думаю, что же может командир-то придумать, если вылезши с утра из походной палатки, внезапно обнаруживает перед руководимой им ротой не врага, а, б*я… водную преграду…
        В общем, до конца времени почти совсем не остается и я выдохнув, на одном дыхании впариваю ответ, примерно следующим образом:
        "При следовании на марше командир роты при обнаружении водной преграды и необходимости ее переправы должен исходить из совокупности условий.
        Командир роты должен оценить водную преграду руководствуясь многими факторами. Так, водные преграды подразделяются на:


        1. По типу: реки, озера, моря, океаны, болота.
        2. По температуре воды: теплые, холодные.
        3. По географическому месторасположению: северные, южные,
          экваториальные.
        4. По направленности течения: с севера на юг, с юга на север.
        5. По наличию брода: с бродом, без брода.
        6. По крутизне берегов: с крутыми берегами, с пологими берегами.
        7. По типу дна: каменистые, илистые, песочные.
        8. По скорости течения: медленные, быстрые, очень быстрые.
        9. По ширине: узкие, широкие, очень широкие.
        10. По типу окружающей местности: горные, предгорные, равнинные.
          11..."

        Отчебучив таким образом любимому командиру этак пятнадцать видов классификации водных преград, смело подвел резюме: "Оценивая в совокупности все имеющиеся условия, руководствуясь принципом сохранения боеспособности вверенной командиру роты, командир самостоятельно принимает решение о способе переправы через водную преграду". Точка!!!
        Я получил ПЯТЬ… ЕДИНСТВЕННЫЙ из группы… На следующей лекции маойро-подпол немного поразарялся перед аудиторией за мою "работу"… А я сидел в офигевшем виде и думал: да, б*я… вот буду я командиром и выведу свою доблестную краснознаменную роту к водной преграде типа экваториального теплого болота, расположенного с севера на юг, без брода с крутыми берегами, с илистым дном, медленным, очень широким и очень глубоким и без труда выберу способ переправы… вертолетом...

          +2
          Что-то чеклиста нет, а есть пока очень обзорное вступление, и слишком сильно «на пальцах», IMO.
            +1

            Go, Rust — куда это все? А вернее — откуда? Откуда вы взяли, что это языки для бэкенда? Тем более в такой «начальной» статье.

              0

              Оттуда, что они для бэкенда используются, не? )

              –1
              Справедливости ради, VueJS — это тоже библиотека, но не фреймворк.
                0
                Vue.js — The Progressive JavaScript Framework

                vuejs.org
                  0
                  Но ведь, со слов автора про React: «Собственно, от гордого звания фреймворк отличается лишь отсутствием некоторых функций «из коробки», и необходимостью устанавливать их вручную». А чем же Vue более фреймворкистый?
                  0
                  Теперь даже React стал больше фреймворком, нежели библиотекой. Так как они задают определенный стиль программирования.
                  0

                  А где сам чек-лист? Вот, например, хороший чек-лист https://habr.com/ru/post/438064

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

                    А дальше вы рассказываете дедиках, расте, докере, оркестрировании… Это всё не для новичков.

                    Для новичков это ruby(rails)/python(django/flask)/php(wp/drupal/laravel)/nodejs(next/хз что ещё). Хостинги в виде heroku/forge/now, которые за копейки позволяют в пару строк выкатить приложение в онлайн. Непомешает пару слов о доменах — где брать, как установить. О такой классной/бесплатной штуке как cloudflare.

                    Отдельно стоит отметить, что нынче приложения можно разрабатывать вообще без собственного бэкэнда, на React/Vue/Angular и специально разработаных для этого фреймворках, хостить это всё через какой-то cdn, а данные держать в каком-то firebase.

                    Дальше уже можно смотреть в сторону более сложных фреймворков. Хостингов по типу digital ocean/linode/vulture. Контейнеризации, CI/CD.

                    Ну а дальше aws/gcloud/azure, обмазанные k8s, и всякие go'шки/расты где надо производительность.
                      0

                      Версия Rust 1.0 появилась в 2015 году и она существенно отличалась от ранних версий. В 2006 году языка по существу еще не было, только началась разработка его ранних версий. И да, сейчас Rust можно использовать и на клиенте тоже, если компилировать в WASM.

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