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

Деплой: определение, как правильно деплоить и подробные инструкции

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

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

код программы разрабатывается на устройстве разработчика;

перед отправкой кода в среду запуск а е го добавляют в репозиторий для контроля версий;

если версия программы в репозитории считается работоспособной, тогда ее деплоят на рабочих серверах;

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

Этапы деплоя

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

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

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

Непрерывное внедрение деплоя

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

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

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

автоматизированный деплой при помощи специального софта;

единая культура написания кода, чтобы версии программы «дружили» между собой и были совместимыми;

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

Заключение

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

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

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

Deploy (деплой) — что это такое? Дословный перевод слова деплой на русский язык означает «развертывать». Давайте разберемся что именно мы развертываем и каким образом.

После того как программный код сайта написан, возникает вопрос: что-же необходимо сделать, чтобы он появился в интернете? Как правило, классический путь состоит из 3-х шагов:

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

Мы привели в пример один из возможных и очевидных вариантов для понимания, на самом деле их бесчисленное множество.

Хочется отметить, что многие web-студии до сих пор реализовывают данный процесс вручную. То есть программист заходит на сервер и включает git pull. После чего реализовывает вышеуказанные пункты. Данный подход к деплоингу — неправильный. Web-deploy подразумевает под собой полную автоматизацию всех задач, которые необходимо выполнить.

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

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

Помимо этого, deploy можно подразделять на категории откатов и обновлений:

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

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

По большому счету все варианты web-деплоя разделены на 2 составляющих: на PaaS и все прочее.

Теперь вы знаете, что такое деплой для сайта или приложения. Также следует отметить, что существует такое понятие, как Deployer для PHP. Данная опция позволяет загрузить на сервер определенную ветку системы контроля версий. Более того, ему можно написать задачи наподобие выполнения миграции после выкачивания ветки на рабочий сервер.

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

Источник

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

Deploy (деплой) — что это такое? Дословный перевод слова деплой на русский язык означает «развертывать». Давайте разберемся что именно мы развертываем и каким образом.

После того как программный код сайта написан, возникает вопрос: что-же необходимо сделать, чтобы он появился в интернете? Как правило, классический путь состоит из 3-х шагов:

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

Мы привели в пример один из возможных и очевидных вариантов для понимания, на самом деле их бесчисленное множество.

Хочется отметить, что многие web-студии до сих пор реализовывают данный процесс вручную. То есть программист заходит на сервер и включает git pull. После чего реализовывает вышеуказанные пункты. Данный подход к деплоингу — неправильный. Web-deploy подразумевает под собой полную автоматизацию всех задач, которые необходимо выполнить.

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

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

Помимо этого, deploy можно подразделять на категории откатов и обновлений:

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

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

По большому счету все варианты web-деплоя разделены на 2 составляющих: на PaaS и все прочее.

Теперь вы знаете, что такое деплой для сайта или приложения. Также следует отметить, что существует такое понятие, как Deployer для PHP. Данная опция позволяет загрузить на сервер определенную ветку системы контроля версий. Более того, ему можно написать задачи наподобие выполнения миграции после выкачивания ветки на рабочий сервер.

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

Источник

Фронт без релиз-инженера, или Как я перестал бояться и полюбил деплой

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

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

Разделение ответственности — в ряде случаев ответственность за деплой оказывается высокой.

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

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

Как это происходит у нас

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

Немного истории

С самого начала вся разработка у нас велась внутри одного-единственного монолитного репозитория, поэтому «Шаман» умел собирать его и выкатывать, при этом отлично справляясь со своей задачей. Но компания росла, а вместе с ней осваивались рынки, запускались новые проекты, добавляя перекрестные логические связи и в без того сложный код.

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

Да придет спаситель

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

А что делать, если тебе нужно поднять копию среды для тестирования второго релиза? Не создавать же всю связку целиком заново? А если ее незначительно видоизменить? Для подобного в «Шамане» есть возможность создать шаблон конфигурации, в котором с помощью YAML описана вся россыпь машин, сервисов и эндпоинтов. В результате, если ваша команда поддерживает свой шаблон, поднятие нового инстанса развесистой связки сервисов становится тривиальной задачей.

И, кажется, коллеги со мной согласны:

«Лично для меня в деплое нет ничего сложного. И учитывая, что иногда мне приходится делать больше десяти тестовых выкаток в день, а также развертывания совершенно новых приложений, я очень рад, что не нужно каждый раз подключать кого-то из отдела инфраструктуры. Приложений у нас много, и возможность самостоятельной выкатки сильно упрощает жизнь и ускоряет работу», — Роман Литвинов, ROR разработчик.

Схема связи «Шамана» с кодом

На данный момент почти все наши GitHub-репозитории собираются при помощи GitHub Actions, в результате чего докер-образ пушится в общую приватную докер-репу. Этот workflow можно триггерить как автоматически (пуш в релизную ветку), так и руками, если хочется потестить какой-то сиюминутный фикс. Дальше «Шаман» подцепляет свежий образ и по кнопке раскатывает его на стейдж. Ну не красота, а?

И так как этот процесс находится в ведении разработчиков чуть более чем полностью, у нас есть возможность его упрощать. Меня, например, все-таки расстраивает необходимость сначала идти в GitHub, чтобы посмотреть статус билда, а потом в «Шаман» — чтобы нажать на заветную зеленую кнопку для выкатки образа. После незначительной встряски коллег из инфраструктуры выяснилось, что последний предоставляет API, ручку которого можно дернуть из Github Actions с адресом для деплоя и идентификатором образа для деплоя. А это значит, что деплоить код можно полностью автоматически!

Когда что то идёт не так…

Понятное дело, что после выкатки кода на прод надо убедится, что он ведёт себя так, как задумано. И тут у нас чуть хуже с автоматизацией, но тем не менее всё под контролем. Для мониторинга мы используем сервис Sentry, который нотифицирует как о новых индивидуальных ошибках, так и об изменениях общего фона. Ну и продуктовые дашборды с метриками никто не отменял. А «Шаман», в свою очередь, быстро и непринужденно позволяет откатить бажную версию фронтового приложения в случае серьезных проблем.

Так нужно ли деплоить разработчику?

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

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

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

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

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

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

Как происходит деплой в вашей компании? Считаете ли вы наш подход с «одной кнопкой» оптимальным или вам нравятся другие варианты выкатки новых сервисов и обновлений? Поделитесь мнением в комментариях.

Источник

Деплой — Веб-разработка на PHP

После того как сайт написан, встаёт вопрос о том как выложить его в интернет. Стандартный путь включает три пункта:

Первый я пропущу (скоро мы его опишем в https://guides.hexlet.io), а вот про два других поговорим.

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

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

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

Кроме того, деплои можно классифицировать по способу обновления и отката:

Отдельно стоит сказать про канареечный релиз (canary release). При таком подходе переключение на использование новой версии происходит постепенно, сначала для небольшого процента пользователей, а затем и для всех.

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

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

Самый простой способ начать деплоить. Большинство PaaS-хостеров имеют бесплатные планы, достаточные для выкладки учебных проектов. Из плюсов: не придётся покупать адрес, домен третьего уровня предоставляется бесплатно. Самое популярное PaaS-решение на текущий день — Heroku, у этого сервиса прекрасная документация, следуя которой можно быстро выложить свой первый сайт. Пошаговое руководство, описывающее выкладку сайта на PHP доступно по ссылке: https://devcenter.heroku.com/articles/getting-started-with-php. Heroku используется на Хекслете для JavaScript- и PHP-проектов. Пользователям из РФ для регистрации на этом сервисе необходимо подключить VPN и указать другую страну.

Все остальное

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

Самая первая задача — настроить окружение. Если в виртуальном хостинге всегда есть набор предустановленных программ, то во всех остальных видах хостинга нет ничего, кроме голой операционной системы. Установка необходимого ПО такой же автоматизируемый процесс как процесс деплоя и у него есть даже собственное название — Управление конфигурациями (Configuration Management). Рекомендую использовать Ansible, популярное решение для настройки (На Хекслете есть соответствующий курс).

Источник

Эволюция процесса деплоя в проекте

Денис Яковлев (2ГИС)

Меня зовут Денис, я работаю в компании 2ГИС, около полутора лет занимаюсь вопросами continuous delivery для проектов веб-отдела. До этого работал в компании Parallels и там прошел путь от QA инженера до team lead’а.

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

Из чего это состоит? Нам нужно доставить, прежде всего, код — то, над чем мы работали большое количество времени, тестировали и прочее.

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

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

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

Если мы не обошлись без использования стороннего программного обеспечения, мы должны позаботиться о том, что это ПО надо на наши сервера как-то поставить, сконфигурировать определенным образом, который нужен нам, и своевременно его апгрейдить. Или не апгрейдить, если вдруг в новой версии софта вышла какая-нибудь бага, чтобы у нас все не полегло.

Какие возникают решения «в лоб»?

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

Он, естественно берет, то, что общедоступно и под рукой. Он берет Bash, Perl и все это автоматизирует, потому что зачем все это делать руками, когда можно все это автоматизировать и просто запускать Bash.

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

Так как мы начали все это очень быстро делать, пока мы не испытывали особых проблем, у нас присутствует какое-то количество ручного труда. Сначала это не сильно заметно, а потом это нарастает как снежный ком, а ручной труд — это дополнительный источник человеческих ошибок. Кто-то что-то не так и не туда записал, или записал туда, но не так, второй неправильно скопипастил, и в итоге получается такая ситуация, когда очень много ошибок, и все они возникают, и не понятно, когда они закончатся и откуда берутся. В итоге, у нас этот специально обученный человек, который отвечал за релизы, только и делает, что релизит. Т.е. у него нет времени на какие-то другие его задачи, нет времени даже поесть. Он выкатил один релиз, пока его выкатывал, пришел второй релиз, во время этого релиза случились какие-то ошибки, потом еще пришел патч на этот релиз. В общем, этот большой такой головняк, нервозность возрастает, а бизнес к нам приходит и говорит: «Чего вы не можете до клиентов доставить код? Это ведь просто и быстро, а у нас тут еще вагон фич идет дальше, давайте чего-то с этим делать!».

Определенное время существует такой подход в нашей индустрии, как «Infrastructure as a code», который говорит нам, что мы должны подходить к описанию конфигурации нашего приложения так же, как мы подходим к разработке программного обеспечения. Так Кейф Моррис сказал:

Это немного больше, чем простая автоматизация, потому что автоматизация — это мы просто берем и все, что мы ручками делаем, загоняем в скрипт, и он работает. В подходе «Infrastructure as a code» мы используем все практики, тулзы и подходы. Мы берем это из разработки программного обеспечения нашего сервиса и применяем к описанию инфраструктуры. Т.е. если появился новый подход, соответственно, для его реализации со временем появляются и тулзы, т.е. программное обеспечение.

Какие инструменты есть?

Есть такой класс продуктов — Сonfiguration Management System, т.е. CMS (не путать с Content management system!). Типичные представители — Ansible, Chef, SaltStack, Puppet. Они созданы для того, чтобы нам, как разработчикам или как компаниям, помочь в управлении инфраструктурой. И одной из задач, одним из use case’ов применения такого ПО является приведение нашей системы в определенное описанное нами состояние. Т.е. если у нас есть, нам выделили абстрактный сервак,, там ничего нет или там есть какая-нибудь голая ось, то с помощью таких инструментов мы приводим сервак в нужное нам состояние.

Давайте посмотрим на некоторые из этих инструментов. Я выбрал те, которые используются у нас в компании, чтобы на примерах объяснить. Во-первых, Anisble.

Это ПО достаточно простое для понимания, написано на Python, модульное, достаточно легко устанавливается и, как мы для себя отметили в компании, порог вхождения для использования Ansible достаточно низкий. Т.е. если мы берем человека, говорим: вот тебе Ansible, разберись и начни его использовать, он к концу недели бодренько пишет, все это там понимает.

Что нам нужно сделать после того, как мы установили Ansible?

Дальше, в Ansible есть такая сущность — playbook’и:

Playbook — это набор инструкций, т.е. те шаги, которые Ansible предстоит сделать, чтобы наши сервера привести в то состояние, которое нам нужно. Т.е. playbook’и состоят из hosts (мы указываем, с какими хостами мы хотим работать) и tasks –указываем те шаги, которые Ansible нужно сделать. И есть командочка — мы говорим: «Запусти этот playbook, информацию о хостах возьми из этого файла».

Мы указываем hosts (если кто запомнил — webservers). Это та группа хостов, которая у нас указана в Ansible инвенторе. Мы говорим, что хотим поставить nginx на те сервера, которые мы указали там.

Tasks состоят у нас в данном случае из двух шагов:

Архитектура выглядит примерно так:

Я взял это из Интернета, эту картинку можно свободно нагуглить. У нас есть Host Inventory, Playbooks, Core Modules — это модули, которые написаны самой командой Ansible, что, как раз, отвечает yum, apt и прочее; Custom Modules — это то, что там написано комьюнити или еще какими-нибудь контрибуторами; Plugins. Запускается Ansible, идет по хостам и выполняет то, что ему нужно. Примечательно то, что на тех хостах, с которыми мы работаем, нам дополнительного ПО не надо, т.е. у нас как наши серваки стояли-работали, так они и работают. Там должен быть, по-моему, только Python, но Python есть практически везде.

С этим вкратце понятно, давайте для сравнения посмотрим Chef.

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

Какими мы здесь оперируем терминами?

Мы ставим отдельный сервак где-то в нашем окружении, в котором хранятся все наши cookbooks, роли, environment, ноды с описанием и прочее.

На каждой ноде нашей стоит клиентское ПО — Chef client, которое настроено на этот сервак. И оно ходит туда за описанием этой ноды, т.е. она приходит и
говорит: «Я такая вот нода, скажи мне, пожалуйста, что у меня есть по ролям, по каким-нибудь дополнительным настройкам, по рецептам, что мне нужно
сделать?». Chef сервак ей отвечает: «Вот, выполняй, пожалуйста, эти рецепты с такими вот входными параметрами», и утилитка все это применяет.

Если кто обратил внимание, в Ansible немного по-другому, т.е. в случае с Chef сервером, мы, во-первых, ставим дополнительное ПО на наши ноды, и мы заходим
на сами ноды, либо как-то удаленно должны позвать этот Chef client. В Ansible мы говорим Ansible playbook на нашей рабочей тачке, и он идет сам по SSH
выполняет все на наших серверах.

Но это одна конфигурация Chef.

Я хочу отметить, что это очень маленькая часть функциональности этих всех инструментов, которые я упомянул, т.е. там есть гораздо больше возможностей, use case’ов, составляющих и прочее. Это большие сложные инструменты, они решают широкий круг задач, но сейчас в рамках этого доклада, мы говорим только об одном use case’е — как нам задеплоиться.

Допустим, мы что-то посмотрели, определились, решили, что нам подходит какой-то инструмент, и что же нас ждет помимо каких-то технических вопросов? Мы же работаем в команде. Мы можем сказать, что с сегодняшнего дня мы используем, допустим, Ansible. Хорошо, что мы дальше получаем?

Получаем новые процессные вопросы — это зона ответственности, т.е. я, как team leader, решаю, что теперь мы используем Ansible, но у меня стоит вопрос, кто у меня должен писать playbooks?

Разработчики? Они ко мне приходят и говорят: «Мы не будем писать playbooks, потому что мы не знаем боевую конфигурацию». Хорошо, я иду к админам и говорю: «Теперь вы пишете playbooks». Они говорят: «Мы playbooks писать, извини, не будем, потому что мы не знаем приложения». Это пример из воздуха для понимания. И эту ситуацию мы должны как-то резолвить, потому что получается, что знания для написания playbooks, рецептов у нас размазаны. Часть знаний у нас есть в одной команде, часть — в другой команде.

Приведу пример, как такую штуку мы решали у себя в отделе. У нас есть много продуктов, сервисов, и они разной степени сложности. И один очень сложный высоконагруженный наш проект — это Web API. Мы сделали так: у нас админы взяли Chef, написали всю базу. У нас 3 датацентра по 18 серверов, децентрализация и прочее. И такие таски админы взяли на себя, написали всю эту конфигурацию, раздеплоились во все датацентры, убедились, что все это работает. Потом в процессе жизни продукта, когда меняются те параметры, о которых админы не знают, как я приводил пример — т.е. у нас в кофиге что-то поменялось, мы начали использовать другие еще какие-то утилитки… Это все то, что решается в процессе разработки продукта. Админы пришли, научили разработчиков писать playbooks, рассказали, что такое Chef, с чем его едят, как готовить, и потом после этого момента команда разработки сама начала писать эти playbooks. Когда изменения у нас критичные или очень сложные, рискованные, то команда разработки берет, и сама это пишет и просто на ревью отдает админам, и они смотрят, как это будет ложиться в текущую инфраструктуру и оставляет какие-то комментарии.

Другие же сервисы попроще. Они взяли, и посмотрели, что Chef для нас — это слишком сложно, избыточно и прочее. Они взяли Ansible, сами написали, быстренько разобрались, сами все написали, пришли к админам и сказали: «Посмотрите, можно ли так?». Те посмотрели и сказали: «Да, нет, не знаю, может быть».

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

И, естественно, у нас меняется workflow. У нас появляются новые таски, инструментарии, и workflow разработки у нас меняется.

Vagrant — это не инструмент для тестирования, но это то, что может нам помочь быстро посмотреть. Что это такое Vagrant? Это ПО для создания виртуальной среды. Это обертка над многими провайдерами виртуализации, как виртуал бокс, ВМ варь и прочее. И плюс — у него еще есть интеграция с вышеуказанными системами конфигурации, т.е. с Chef, Ansible, с Puppet.

Чтобы развернуть мне тачку, т.е. я поставил себе Vagrant и мне нужно просто сделать vagrant init — это я указываю, дистрибутив чего мне нужно.

У меня в текущей директории появляется vagrant файл — конфигурационный файл моей будущей виртуалки. И в этой же директории я говорю: «vagrant up» и через некоторое время на моем хосте поднимается виртуальная машина, где я могу делать, что хочу, потом ее грохнуть и еще чего-нибудь, т.е. делаю с ней, что хочу.

Вот быстренький пример, про Chef solo:

В Vagrant файле я пишу, что у меня в provision’e Chef solo, мои cookbooks располагаются вот там-то и, пожалуйста, на эту машину добавь мне рецепт, который у меня называется «apache» и отвечает за установку apache.

Тогда, когда я говорю «vagrant up» для этой машины, она поднимается, и выполняется этот рецепт, который устанавливает apache.

Vagrant’a самого не достаточно для тестирования. Я видел в программе RootConf’а есть отдельный доклад по поводу того, как тестировать инфраструктуру. Там рассказывают именно о тестовых фреймворках, который позволяют тестировать инфраструктуру. Я знаю, что существует test kitchen, который основан на Vagrant’e, и он позволяет писать тесты, когда у нас он поднимает виртуальную машину, и ему указываешь: привяжи мне систему, виртуализацию… Потом говоришь: у меня есть набор тестов, которые выглядят достаточно просто, нам же нужно проверить, что у нас все поставилось, что демоны запустились, нужные нам файлы лежат в определенном месте. Собственно, мы пишем такого рода тесты, и он их после поднятия виртуальной машины, прогоняет и говорит «OK» либо «не OK».

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

Что бы хотелось порекомендовать, с чего начать? Инструменты большие, информации много, хочется взять попробовать. От себя могу сказать, что рекомендации такие — если у нас есть какой-нибудь маленький простой сервис, то берите то, что уже известно, т.е. поставить nginx или postgres и прочее. Попробовать начать с маленького, написать рецепт, playbook, выполнить простые общеизвестные действия, тогда можно будет понять, нужно вам это на данном этапе, или вас до сих пор баш-скрипты устраивают, или ручками вы делаете. Понять, нужно ли вам это. И понять, что вам удобнее.

Я тут ссылочки привел:

По поводу такого немаловажного аспекта, как стоимость, можно сказать, что эти продукты в основном бесплатные. Сhef начал с 12-ой версии хотеть денег, поэтому многие сидят на 11-ой версии до сих пор, а Ansible хотят денег за веб-морду, Ansible tower это, по-моему, называется. А в остальных конфигурациях все это можно взять бесплатно и быстро применить.

Контакты

Этот доклад — расшифровка одного из лучших выступлений на обучающей конференции разработчиков высоконагруженных систем HighLoad++ Junior.

Также некоторые из этих материалов используются нами в обучающем онлайн-курсе по разработке высоконагруженных систем HighLoad.Guide — это цепочка специально подобранных писем, статей, материалов, видео. Уже сейчас в нашем учебнике более 30 уникальных материалов. Подключайтесь!

Ну и главная новость — мы начали подготовку весеннего фестиваля «Российские интернет-технологии», в который входит восемь конференций, включая HighLoad++ Junior.

Источник

What is Deployment?

Deployment is the process of web service “deployment”, e.g. of a website, in the operating environment. An operating environment is a place where a website is started and available for requests. This can be ready-made hosting as well as your own server infrastructure.

Not only web services but also any services available over the network are deployed. Even if this network is internal and not available for requests over the Internet.

To understand deployment, you need to understand the code life cycle. The application code is built on the developer’s workstation and run in another place called production. Production is a startup environment (also called a live environment). In the case of a simple application, it may consist of a single server, but for truly complex applications it can be thousands and tens of thousands of servers.

How does it work? Developers add the code to the information repository. At some point, they decide it’s time to bring it to production. This can be done on a regular schedule such as every two weeks or just as needed up to the release after each change. In many cases, the number of deployments depends on the automation level, i.e. to which extent the process is easy to conduct and rollback. At Hexlet, deployments are performed almost after each change, approximately three deployments a day.

When developers decide now it’s time, they create a release. Release usually refers to a Git tag that marks things to be deployed. Namely, changes added to a master branch after the tag has been created won’t affect the tag itself, which means that we are sure about what we will be deploying.

It’s worth mentioning that such PaaS platforms as Heroku take the deployment completely upon themselves. There you just have to make a commit, and then everything will happen by itself. The price for this is the cost of the platform itself.

Deployment stages

Code delivery to the server

There are different options for code delivery to the server, depending on its packaging. Sometimes the code is directly transmitted to the server as a set of files, but more often it’s updated via Git. Back in the day, the deployment method through standard package managers of Linux distributions was popular. It’s still in use today and best suited for certain situations.

Database update

Start and stop

Somewhere in this process, the old version stops, and the new one starts. If we first stop the old version, then execute migrations and start the new version, we will get service downtime. This is a really common thing for many, but it can be sensitive for business and frequent deployments. So, the most advanced projects don’t stop during deployment. There is a description below of how to do it.

Automation

Deployment should be automated as much as possible; Time To Market, a key characteristic of business-oriented applications, depends on it. The faster and more often we deliver changes to the user, the better. The faster we check hypotheses, the faster we introduce changes, and the faster the money invested in development pays its way. Developers are afraid to perform deployment without automation, it becomes a burden that leads to a decrease in deployments and regular stress for the whole team, working long hours.

There are three main automation ways:

However, even if automation is executed, the task of “running deployment” remains. The start is also automated. There is a whole approach called Continuous Delivery. It’s difficult to implement and is not suitable everywhere, but if it works, you can forget about deployment. It’s performed entirely on its own without human involvement. The main thing in this option is good monitoring and alerting system.

Zero Downtime Deployment

If no special steps are taken, each deployment will cause the service to stop (possibly partially). At this time users will either see an error or a message that an update is in progress. But this does not happen on most major Internet services. Why? Due to the implementation of the “Zero Downtime Deployment” approach (downtime means service operational downtime).

Zero Downtime Deployment is when the service never stops running, but in the meantime, it’s being updated. This is achieved by simultaneously running the old version and the new code. Namely, when an application is deployed, the new version arises next to the old one. And only when the automatics make sure that the new version has started and run, the old version is stopped. The following is required to perform this procedure:

Источник

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

4 года назад 23911 9

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

Основная цель

Тестовое приложение

Начнем с тестового приложения. Создадим проект на laravel и добавим простой роут, выводящий номер версии.

Далее открываем routes/web.php и пишем следующее:

В resources/views/welcome.blade.php добавляем вывод нашей версии:

Создаем git-репозиторий и пушим туда код нашего демо проекта.

Подготовка сервера

Теперь перейдем к подготовке нашего сервера. Установку зависимостей приложения, таких как сам PHP, composer я опущу и остановлю только внимание на важных моментах, а именно создание пользователя для deployer’а, настройка прав доступа для него, а также настройка nginx.

Итак, у меня есть сервер под управлением ubuntu server 16.04 и root-доступ к нему. Я создам пользователя deployer, дам ему sudo-привилегии, настрою ему доступ к серверу по ssh-ключу.

Создаем пользователя, система попросит ввести для него пароль:

Даем пользователю sudo доступ:

Добавляем пользователя в группу www-data:

Создаем директорию для нашего проекта и выставляем права доступа:

Скопируем вывод и на сервере вставим в

Также нужно позаботиться о том, чтобы наш сервер имел возможность клонировать наш репозиторий если он приватный. Для этого будучи залогиненым на сервере как deployer нужно сгенерировать ssh ключ и добавить его публичную часть в deploy keys нашего репозитория.

И вставляем в этот файл следующую строку:

Это позволит пользователю deployer выполнять sudo systemctl restart php7.2-fpm.service без ввода пароля.

Теперь сервер готов к деплою нашего приложения. Перейдем к настройке самого deployer’а.

Настройка deployer’а

На нашей локальной машине устанавливаем deployer:

В папке нашего демо-проекта инициализируем конфиг deployer’а:

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

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

Заметьте что artisan:migrate закомментирован, так как наш демо проект не использует базу данных. В результате наш deploy.php имеет следующий вид:

Деплоим!

Можно деплоить. В корне нашего проекта выполняем простую команду:

Проверяем наш задеплоенный код на сервере:

Мы видим что весь код доставлен, зависимости установлены, символьные ссылки добавлены. Все впорядке. Осталось настроить nginx, используем следующий минимальный конфиг:

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

Открываем routes/web.php и меняем версию на другую:

Делаем ккоммит и пушим в репозиторий. Деплоим:

Открываем в браузере http://deployer-demo.local/ и видим что версия изменилась на 2. Значит все работает корректно.

Все действия описанные в статье производились на ubuntu 16.04.

Источник

Автоматизируй это! Упрощаем жизнь разработчика

Как автоматизировать тестирование, cбор и обработку данных, деплой — и другие рутинные задачи

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

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

В этой статье вместе с курсом Яндекс.Практикума «Мидл Python-разработчик» мы разберёмся, какие готовые инструменты или библиотеки можно использовать для автоматизации рутинных задач. Использовать будем Python: потому что он позволяет быстро написать рабочий код, и для него существует много разных библиотек.

Тестирование

Тестировать вручную — не лучшая привычка. Вы можете что-то пропустить или забыть. Часто случается так, что вы протестировали фичу А и исправили в ней все баги, а потом сделали то же самое с фичей Б. Сколько людей вернутся к фиче А, чтобы проверить, не пошло ли что-нибудь не так? А если таких фич несколько сотен?

Поэтому лучше начать автоматизировать тестирование как можно раньше. Отдельные функции можно проверять с помощью Unit-тестов.

Например, есть функция sum(), которая складывает два числа. Для этой функции пишутся тесты, которые проверяют, как сработает функция, если ввести:

два положительных числа;

два отрицательных числа;

положительное число и None;

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

В Python для этого используется модуль unittest. Допустим, у нас есть файл app.py вот с такими функциями:

Чтобы их проверить, мы создаём файл tests.py:

Запустив код, мы увидим, сколько времени потребовалось на тесты, и где была допущена ошибка:

Если нужно протестировать интерфейс сайта, то можно воспользоваться другой библиотекой — Selenium. Она позволяет имитировать действия пользователя в браузере: кликать, печатать, скроллить и так далее.

Она не входит в состав предустановленных библиотек Python, поэтому её нужно будет установить с помощью команды: pip install selenium. Подробные инструкции по установке можно найти на PyPi.

То же самое можно сделать и с десктопными приложениями — для этого понадобится библиотека Pynput.

Деплой

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

Автоматизировать деплой можно при помощи Git. Он позволяет отправлять файлы не только на GitHub, но и на свой сервер. На сервере вам нужно будет создать специальный bare-репозиторий, а на локальном компьютере указать доступ к нему.

Дальше вы можете создать на сервере скрипты, которые будут вызываться при определённых условиях. Например, если вы отправили на сервер новую версию сайта на Django (Python-фреймворк для разработки веб-приложений) и вам нужно её запустить. Тогда вы напишете скрипт, который вызывается после получения новых файлов.

Если всё настроено правильно, то вы сможете деплоить приложения на сервер с помощью всего одной команды в терминале. Но это тема для отдельной большой статьи о DevOps.

Мониторинг

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

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

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

Сбор и обработка данных

Это, пожалуй, одна из тех сфер, которую стараются автоматизировать практически все. Брокерам нужно парсить котировки, таргетологам — подписчиков конкурентов.

Чаще всего возникает задача собрать данные с какого-нибудь сайта или сервиса. Сервисы предоставляют для своих клиентов API (программный интерфейс приложения) — набор способов, с помощью одна программа может взаимодействовать с другой.

Если же у сервиса нет своего API, то можно получить данные с помощью уже знакомых нам инструментов — Selenium или requests. А для удобной обработки можно воспользоваться библиотекой BeautifulSoup.

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

Он может пригодиться SEO-специалистам — однако если нужно проверить очень больше количество запросов, то поисковик попросит ввести капчу. Скрипт с этим, конечно же, не справится.

Разработчик может использовать скрипты и для работы с данными: например, чтобы проверить валидность JSON, перевести CSV в XML и так далее.

Другие рутинные задачи

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

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

Источник

Деплой Java-приложения

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

Эксперименты можно проводить на облачных серверах провайдера Timeweb Cloud, у которого есть различные тарифы. Есть предложения по готовым решениям и чистые виртуальные машины. Для деплоя Java-приложения на сервер понадобится работающий сайт, созданный на Java в фреймворке Spring Boot. Предполагаем, что разработка ведется на платформе Windows 10 с установленными PostgreSQL, Apache, Maven, Git Bash.

На удаленном хосте должны быть установлены Ubuntu, Nginx, сертификат SSL и панель управления Vesta. Сразу отметим, что в зависимости от версии Java возможны «нестыковки» с операционкой, поэтому при использовании другого релиза вы, возможно, столкнетесь с ошибками. Тогда каждый разбирается в ситуации самостоятельно или с помощью специалистов техподдержки провайдера.

Настроим предустановленную Vesta

Использовать для деплоя Java-приложений допускается любую панель управления. Но в данном случае остановимся на варианте Vesta Control Panel. И будем подключаться к хосту через утилиту Putty, поддерживающую защищенные соединения по протоколу SSH. В ней есть особенность – при вводе пароля курсор стоит на месте, но, на самом деле, он вводится. Итак, подключимся к пользователю с правами root. На экране монитора пользователь увидит следующее:

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

Сразу зададим настройки панели управления:

Если текстовый редактор nano еще не установлен, сделаем это командой:

Кому больше нравится редактор vi, редактируйте конфигурацию с его помощью:

В открытом файле добавим строку FILEMANAGER_KEY = ‘ILOVEREO’ (в самый конец). И еще одну – DB_SYSTEM – меняем на DB_SYSTEM=‘mysql,pgsql’. Закроем файл с сохранением и сразу же перезапустим веб-версию панели Vesta с выходом и повторным входом в аккаунт.

Инсталлируем БД PostgreSQL в Ubuntu и Vesta Panel

Теперь установим PostgreSQL. Выполняется это командой:

Следом скачаем файлы конфигурации Vesta Control Panel:

Перезагрузим процесс PostgreSQL:

Есть альтернативная команда:

И зайдем в систему под пользователем postgres:

Пароль устанавливается разными способами. Вот один из них:

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

Зарегистрируем PostgreSQL в Vesta:

Скачаем настроечные файлы для phppgadmin:

И перезапустим веб-модули:

Инсталлируем Java на Ubuntu

Платформа Java нужна для поддержки тестового проекта JAR. Инсталляция произойдет по команде:

Проверим версию Java:

На экране появится примерно следующее:

Если установили не ту версию, ее легко удалить (на примере 1.8):

Настроим Mail, User, Domain, DNS и прочее через веб-панель Vesta

Панель управления Vesta представляет собой продукт с графическим интерфейсом, где легко разобраться даже без инструкции. И на первом шаге создадим в ней новый аккаунт. Войдите в веб-версию панели под администратором, имеющим право на регистрацию других пользователей. Во вкладке USER создайте нового, указав его название в поле [username]. После сохранения настроек надо зайти в панель управления уже под ним.

5. Приобретем и настроим SSL-сертификат. Здесь мы предположим, что тот уже есть у нас, и остается только настроить его. Кликнем на вкладку Web, далее Edit и поставим галочку на SSL support. Заполним открывшиеся поля. Нажмем Save для завершения процедуры.

Настроим Nginx

Теперь подключимся по протоколу SSH к удаленному хосту с использованием аккаунта root. И сразу проверим каталог созданного ранее пользователя, точно ли он существует:

Система выдаст примерно такое сообщение:

Раз мы установили сертификат SSL, нужно настроить редирект на HTTP на HTTPS. Поэтому откроем файл nginx.conf:

И в конце внесем строку (перед закрывающей скобкой):

Также включим перенаправление портов:

В блоке location/, в поле proxy_pass меняем значение на предложенное выше – 8099.

То же надо сделать в блоке location@fallback proxy_pass:

Выйдите из файла с сохранением изменений. И перезапустите процессы:

Подготовим приложение Java для развертывания

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

trust.store исправляет в проекте некоторые проблемы с сертификацией.

5. Далее в файле pom.xml добавим зависимости:

6. Перейдем в класс WebSecurityConfig и добавим строки:

Осуществим деплой приложения Java

Теперь о самом интересном. Начнем с подготовки скрипта для сборки и развертывания приложения. Создадим файл deploy.sh и внесем в него строки:

Подробнее об используемых переменных:

Важно! Лог-файлы, в которых система записывает события запуска и работы веб-приложений, найдутся в каталоге /home/USER/web/DOMAIN/log.txt.

Переходим к запуску созданного скрипта. Откроем ранее инсталлированный git bash, перейдем в каталог, где размещено приложение, и введем команду:

Начнется процесс запаковки при помощи maven. Если все ранее описанное сделано без ошибок, то оно пройдет безостановочно. Система пару раз запросит пароль пользователя root – для копирования и для развертывания приложения. Все, теперь смело открывайте его через браузер.

Выводы

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

Кстати, в официальном канале Timeweb Cloud собрали комьюнити из специалистов, которые говорят про IT-тренды, делятся полезными инструкциями и даже приглашают к себе работать.

Источник

«Не баг, а фича» — учимся понимать язык программистов

Понять смысл IT-терминов можно, только узнав, как они употребляются

Программисты говорят на особом языке, в котором полно терминов и сленга. Эта речь не всегда понятна не только обычным людям, далёким от компьютеров, но и начинающим айтишникам — новичкам в разработке.

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

Гораздо проще понять, что значит «пичупидо», если знать контекст, в котором употребляются все эти слова. Поэтому попробую объяснить некоторые термины и сленг на примере истории одного программиста (вымышленного).

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

Новая задача

Ваня — обычный джун в веб-студии. Его работа — поддержка бэкенда сайтов старых клиентов студии.

Джуниор ( англ. junior — младший) в данном случае — младший разработчик в веб-студии. Также бывают мидл- ( англ. middle — средний) и сеньор-разработчики ( англ. senior — старший).

Бэкенд или бэк ( англ. back end — задний край) — серверная часть сайта или приложения, которая нужна для обработки и хранения данных. Его противоположность — фронтенд или фронт ( англ. front end — передний край) — видимая часть приложения или сайта. Если же разработчик занимается сразу фронтендом и бэкендом, его называют фуллстек-разработчиком ( англ. full stack — полная куча / полный набор).

Рабочая неделя Вани начинается с митингов, потому что спринт в его компании длится всего неделю.

Митинг — собрание, на котором обсуждается, что успели или не успели сделать сотрудники, а также чем они будут заниматься в новом спринте.

Спринт — период от одной до четырёх недель, за который сотрудники должны успеть выполнить задачу или задачи. Спринты являются частью Скрам.

Скрам ( англ. scrum) — метод управления проектами. Относится к гибкой методологии разработки эджайл ( англ. agile — гибкий).

На этот раз он получил задачу по добавлению валидации в один из интернет-магазинов. До этого вся валидация была на стороне пользователя.

Валидация — проверка данных, которые вводит пользователь.

До пятницы ещё целая неделя, поэтому с митинга Ваня пошёл сразу в курилку. Достав сигарету, он стал слушать разговор мидла и сеньора:

— Недавно залез в репозиторий, а там одни foobar’ы. Целый час голову ломал, а потом махнул рукой и заново переписал.

— Как наберут новых джунов, так всегда говнокод появляется. Как он вообще код ревью проходит?

— Надо проверить в гитхабе историю коммитов.

Тут Ваня поперхнулся, затушил сигарету и заторопился на рабочее место — от греха подальше.

Репозиторий — хранилище исходных файлов проекта.

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

Говнокод — очень плохой код.

Код ревью — проверка кода.

Гитхаб — сервис для хранения репозиториев IT-проектов и совместной работы над ними.

Коммит — запись изменений в репозиторий. Коммит содержит в себе данные об изменениях, комментарий и имя автора коммита.

У стола его уже ждал тимлид:

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

— Вы уверены, что это из-за меня? Мой код вообще промокодов не касался.

— Уверен. Откати сайт и исправь всё до конца недели — нельзя ждать, пока клиент заметит, что одна из фич пропала.

— Но у меня уже есть задача на эту неделю, я не успею всё исправить.

— Это далеко не первый твой факап, поэтому, если не успеешь, мы поставим новый рекорд — так быстро мы джунов ещё не увольняли.

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

Баг ( англ. bug — жук) — неожиданный результат или неожиданное поведение программы, ошибка.

Откатить ( англ. rollback) — отменить изменения, вернуться к прошлой версии.

Фича ( англ. feature — особенность) — полезная (а иногда забавная) функция / особенность программы.

Исправление багов

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

Дебаг (англ. debug — устранение багов) — исправление ошибок в коде программы.

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

— Прости, но если бы я знал, что не так в твоём коде, я бы твой пул реквест не заапрувил.

— Но ты же написал lgtm в комментарии!

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

— Ладно, разберусь как-нибудь.

Апрув ( англ. approve) — подтвердить что-нибудь.

Пул реквест ( англ. pull request) — запрос на подтверждение коммита.

LGTM ( англ. looks good to me — На мой взгляд, хорошо) — сокращение, которое часто встречается на гитхаб в комментариях к подтверждению коммитов. Обычно его используют, когда не получается сказать ничего конструктивного по поводу кода.

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

Пик Балмера — шуточная теория, что при содержании алкоголя в крови между 0,129 и 0,138% (примерно 2 бутылки пива) программист получает сверхспособности к написанию кода. Теорию выдвинул Стив Балмер, CEO Microsoft с 2000 по 2014 год.

Бессонные ночи и пиво сделали своё дело, поэтому Ваня заснул прямо за компьютером.

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

Ненавидя себя, он поплёлся на работу. Сев за рабочий стол и посмотрев в код, внезапно понял, в чём была ошибка (известно, что многие проблемы в разработке приложений решаются, когда программист спит). Исправив всё за пару минут, он пошёл к тимлиду.

— Я разобрался с багом.

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

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

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

Ваня начал думать.

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

JavaScript — язык фронтенд-разработки.

Помучившись день, он всё-таки закончил. Тимлид оценил усилия:

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

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

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

По крайней мере на этот спринт.

Заключение

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

Источник

Docker: На старт. Внимание. Деплой

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

В лучшем случае, у вас был скрипт, который все это делал автоматически. В худшем случае, это могло выглядеть вот так:

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

/Disclaimer:/ Это не обзорный доклад о Docker. В конце этой статьи приведен список полезной литературы, которая описывает работу с Docker лучше. Это первая точка вхождения для разработчиков, которые планируют деплоить node.js приложения при помощи Docker контейнеров.

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

Что это такое и с чем его едят?

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

Для того, чтобы иметь возможность создавать какие-то абстракции на базе таких контейнеров, в Docker существует образ (/docker image/). На базе Docker образа можно конфигурировать и создавать контейнеры.

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

Знакомимся ближе

На установке долго останавливаться не будем. Процесс за последние несколько релизов упростили до нескольких кликов/команд.

В этой статье мы разберем деплой Docker приложения на примере серверного Node.js приложения. Вот его примитивный, исходный код:

У нас есть как минимум два способа упаковки приложения в Docker контейнер:

Для начала скачаем официальный node.js образ:

Команда docker pull скачивает Docker образ. После этого можно выполнить команду docker run. Это создаст и запустит контейнер на базе скачанного образа.

Эта команда запустит index.js файл, произведет маппинг 3000 порта на 80 и выведет id созданного контейнера. Уже лучше! Но на одном CLI далеко не уедешь. Давайте создадим Dockerfile для нашего сервера.

Данный Dockerfile описывает образ, от какого наследуется текущий вариант, а также директорию, в которой начнут выполнятся команды контейнера и команда копирования файлов из директории, в которой запускается сборка образа. Последняя строчка указывает, какая команда запустится в созданном контейнере.

Наш контейнер готов. Мы можем запускать его при помощи команды docker run. Таким образом, мы решаем vendor lock-in проблему. Запуск приложения уже не зависит от окружения. Код доставляется вместе с Docker образом. Эти два критерия позволяют нам деплоить приложение в любое место, где мы можем запустить Docker.

Деплой

Не так страшны первые 99% как оставшиеся 99%.

После того, как мы выполнили все инструкции выше, сам процесс деплоя уже становится делом техники и вашего окружения разработки. Мы рассмотрим 2 варианта деплоя Docker:

Ручной деплой

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

Авторизуемся для доступа к нашему DockerHub:

Загружаем туда наш образ: docker push username/helloworld-with-docker:0.1.0.

Далее заходим на staging сервер (напоминаю, на нем уже должен быть предустановлен Docker).

Для деплоя нашего приложения на сервере нам потребуется выполнить всего одну команду:

И все! Проверьте локальный регистр образов. Если не найдете нужный результат, введите username/helloworld-with-docker для проверки DockerHub регистра. Образ с таким именем найдется в регистре, так как мы его туда уже загрузили. Docker скачает его, создаст на его основе контейнер и запустит в нем ваше приложение.

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

P.S. Данный способ не рекомендуется, если есть возможность воспользоваться Travis-CI.

Деплой при помощи Travis-CI

Первым делом добавим в Travis-CI данные DockerHub. Они будут хранится в переменных окружения.

Далее нам нужно авторизоваться и загрузить образ:

Также доставка образа может запускаться из Travis-CI различными способами:

Источник

Рубин на рельсах: продакшен и деплой для чайников

Год назад я довел свое первое рельсовое приложение до приемлемого вида. Вопрос использования готового кода в продакшене ранее меня не заинтересовал. С чего вдруг? Несложный язык, лаконичный фреймворк — уж деплой-то явно не сложнее, чем преодоление ментального тормоза после PHP.

Команда разработчиков Rails рекомендует использовать Phusion Passenger, он что-то вроде mod_php — установил, разместил файлы и полетел. На момент изучения вопроса на форумах хватало баталий о производительности решений; Passenger в них фаворитом не значился.

Совета относительно альтернативы я спросил у техдиректора сайта с миллионом уников в сутки — тот отправил меня гуглить на тему Nginx и Unicorn. Инструкция по настройке продакшена, найденная на Хабре, датировалась 2009 годом. Помимо прочего, ее просто переполняли изъяны уроков «Как нарисовать сову».

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

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

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

— А подробнее?
— Мы будем использовать Ubuntu 14.04, RVM, Nginx, Unicorn и Capistrano. Текст состоит из двух глав: подготовки проекта и настройки сервера. Все локальные манипуляции описываются в Mac OS X. Для выполнения процедур не будет лишней современная IDE вроде RubyMine, если нет — сойдет и TextMate. Все описываемые действия зафиксированы в специальном репозитории.

Глава первая Хостинг

Выбор хостинга

Сладкая парочка Nginx и Unicorn имеет весьма внушительный аппетит на оперативную память, а сами рельсы требуют установки ряда дополнительного ПО. Эти ограничения явно говорят о необходимости VPS. Есть вариант использовать специализированный хостинг вроде Heroku, но для новичков будет полезным процесс настройки проделать руками.

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

Обновление системных пакетов

Заходим в систему под рутом и обновляем пакеты:

Установка Git и NodeJS

Создание пользователя

Отмена запроса пароля для sudo

Для некоторых процедур деплоя потребуются привилегии суперпользователя. Чтобы команды исполнялись с помощью Capistrano и не вызывали ошибок, необходимо отключить запрос пароля. Отредактируйте файл sudoers : sudo nano /etc/sudoers.

Официальная документация Capistrano поясняет, что нативные фазы деплоя не требуют sudo; однако, если речь заходит об автоматизации всех процессов, без passwordless sudo не обойтись.

Генерация SSH-ключей

Потребуются две пары ключей. С помощью одной из них вы (и Capistrano) будете проходить авторизацию на сервере с локального компьютера. Второй парой вы предоставите серверу доступ в репозиторий (так называемый ключ развертывания). Кодовые фразы в обоих случаях оставьте пустыми.

Первая пара (необходимо генерировать локально):

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

Теперь необходимо скопировать содержимое публичного ключа (по умолчанию

/.ssh/id_rsa.pub на локальном компьютере) и добавить его в файл

/.ssh/authorized_keys на сервере. После этой нехитрой манипуляции с помощью SSH вы сможете подключиться к серверу без пароля. Если нет — проверьте права на сервере: 700 для

Вторая пара (на сервере):

Аналогичным образом содержимое из серверного

/.ssh/id_rsa.pub нужно добавить в список ключей развертывания (в Гитхабе их можно найти в настройках каждого репозитория).

Установка свежего Nginx

Версия Nginx, доступная в Ubuntu, зачастую более старая, нежели в официальном репозитории разработчика. Я стараюсь использовать свежую версию, но если вы других взглядов — установите Nginx самостоятельно и пропустите эту часть.

Мы добавим официальные репозитории Ubuntu в системный список sudo nano /etc/apt/sources.list. В конец файла добавим строки:

Помните, что использованные параметры актуальны только для Ubuntu 14.04. Информацию по установке на другие версии ОС ищите на сайте разработчика. Для установки Nginx из указанных репозиториев потребуется также загрузить и добавить в систему ключ:

Теперь можно обновить список доступных пакетов и установить Nginx:

Установка RVM

В случае с чистым сервером понадобится установить также некоторые зависимости:

Осталось установить непосредственно Ruby необходимой вашему приложению версии. К примеру, новую стабильную версию 2.1.3:

Установка компонентов приложения

Глава вторая Подготовка приложения

Использование Git

Что такое Capistrano

Официальное определение Capistrano звучит так: «A remote server automation and deployment tool». С точки зрения пользователя, Capistrano — штука, которая позволит выполнить произвольный набор команд на удаленном сервере через SSH. Существует и другие инструменты для деплоя (например, Mina), но пока Capistrano также некий стандарт, тем более, что позволяет выполнять параллельный деплой приложения сразу на ряд серверов, в том числе разделенных по ролям.

Принцип работы Capistrano

Когда вы (со своего локального компьютера) отдаете команду Capistrano выполнить деплой, устанавливается SSH-соединение с сервером и начинается выполнение нехитрого алгоритма. Для начала Capistrano сверяется с удаленным репозиторием и получает недостающие коммиты. После создается новый релиз (в директории releases ). Туда перекладывается актуальная версия кода и там же выполняется ряд тестов.

Организация файлов конфигураций

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

Конфигурация Nginx

Мы используем наш VPS для единственного приложения, поэтому хост будет использоваться по умолчанию. (Не нужно же объяснять, что в иной ситуации придется явно указать server_name и позаботиться об уникальности имен апстримов?)

Конфигурация Unicorn

Подключение и настройка Capistrano

Необходимые гемы

В Gemfile нужно внести Capistrano и серию гемов, реализующих его связь с RVM, Bundler и Rails.

Обновление Capfile

Настройка продакшен-сервера

Откройте файл config/deploy/production.rb и внимательно посмотрите на его содержимое. Оно поможет вам разобраться в формате и возможностях настройки. В целом, если вы используете авторизацию с помощью SSH-ключа, никакой экзотики писать не придется; всего одна строчка:

Сценарий деплоя

Обязательные параметры

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

Capistrano требует ряд обязательных параметров:

Установим также параметр log_level (дефолтное значение :debug делает Capistrano излишне разговорчивым):

Релизонезависимые данные

Учтите, что добавление в :linked_files указанных файлов ( config/secrets.yml и config/database.yml ) обязательно. В противном случае деплой завершится ошибкой по причине отсутствия подключения к базе данных.

Процедуры

Capistrano позволяет создавать наборы процедур, которые для удобства можно объединять в пространства имен. Неймспейс :deploy уже существует, его можно лишь дополнить; все включенные в него процедуры для сервера production можно вызвать командой cap production deploy

Сет-ап

Управление Nginx

Я отмечал выше, что Capistrano по сути — способ выполнить произвольные команды на удаленном сервере. Мы загрузили конфигурационные файлы, в том числе для Nginx. Теперь напишем несколько процедур для управления: создание симлинка на конфиг и релоад/рестарт сервиса (для них потребуются права sudo ).

Заметили приятную мелочь? — Можно задать последовательность исполнения различных процедур как в рамках одного неймспейса, так и между ними.

Управление Unicorn

Наверняка уже есть гем, расширяющий Capistrano в плоскости управления Unicorn, но мне было весьма интересно узнать, как он на самом деле устроен и работает. Поэтому сейчас, аналогично предыдущим примерам, напишем две процедуры (старт и завершение) для Unicorn.

Процедуры до и после деплоя

После деплоя нам нужно удалить самые старые релизы (по умолчанию Capistrano хранит пять последних), очистить кеши и перезапустить Unicorn. Главный рабочий блок :deploy будет выглядеть примерно так:

Вынесение процедур в отдельные файлы

Выполнение деплоя

Начиная с этого момента, все, что вам потребуется сделать для выкатки новой версии своего приложения, — закомитить изменения, сделать git push и использовать команду cap production deploy.

Что-то не получается? — Оставляйте комментарии, давайте дополним статью.

Источник

Беглый деплой или как развернуть front-end за 15 минут

Уже очень давно у нас стоял вопрос: как же просто и быстро деплоить front-end проекта?

Мы думали насчет такого инструмента, как Jenkins. Многие, кто настраивал его, знают: настройка занимает немало времени и, что еще важно — затрачивается много ресурсов системы. Поднять его на сервере значит выделить полтора гигабайта памяти. Такое себе удовольствие, когда у тебя 500 мегабайт на всё, например.

Альтернативный вариант — Mina. Это отличное решение, и мы используем его в Ruby проектах. Но как быть, если у тебя только front-end? Ставить Ruby и делать Bundle? Нет, это слишком сложно. Mina, конечно, имеет большой функционал, но мы хотим это делать на NodeJS без лишних телодвижений.

В итоге мы писали Bash скрипты, но это нас утомило. И нам в голову пришла идея написать свой небольшой сервис для деплоя front-end приложений, который будет:

И мы сделали Runy — удобный и практичный инструмент для деплоя front-end.

Все что нужно для его настройки и первого деплоя после установки пакета — это три команды:
init — создать конфиг и внести свои данные в него
setup — создать структуру проекта
deploy — задеплоить ваш проект

Данный модуль упростил нам жизнь! Теперь деплой проходит одной командой. Быстро и просто. Когда к нам приходят новые разработчики, можно дать им доступы к dev/stage серверу, чтобы ребята могли сами деплоить. Junior разработчикам тоже будет полезно, для использования не нужен порог вхождения, а в дальнейшем они могут разобраться в модуле и приобрести новые знания.

Немного о технической части (более подробный мануал есть на github). На данный момент, Runy имеет следующие команды: init, setup, deploy, unlock, rollback.

Создает конфиг файл в месте вызова команды. Вам следуют внести в него свои данные. Как видно, мы используем подключение по ssh-agent, так что никакие пароли в конфиге находиться не будут.

Setup

Deploy

Данная команда имеет некую защиту, в одно и тоже время только один человек может производить деплой.

Команда делает следующие действия. Создает временную папку, устанавливает проект, выполняет список ваших команд из конфиг файла (commands) для подтягивания зависимостей и сборки приложения, создает новую релиз папку, переносит туда только что собранный проект, проверяет количество релизов и удаляет старые (сейчас хранится 3 релиза), создает символическую ссылку на текущий релиз (текущий релиз всегда будет доступен по данному пути your-remote-path/current), обновляет файл с цифрой релиза, чистит папки.

Unlock

Удаляет защитный файл, который создается при исполнении команды deploy. Вообще файл удаляется автоматически и даже при обработке ошибок, но на все случае жизни существует данная команда.

Rollback

Возвращает обратно символическую ссылку на предыдущий релиз и удаляет текущий.

P.S. У нас еще есть идеи по развитию этого инструмента, вы также можете поучаствовать в развитии проекта, создавая/делая задачи здесь.

Пусть deployment каждого разработчика станет удобнее и быстрее.

Источник

Деплой — Продакшен и Деплой

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

В продвинутых сценариях деплой образов выполняется с помощью Kubernetes. У нас ему посвящен отдельный курс, а здесь мы выполняем деплой напрямую, с помощью Ansible. Почему именно он? Ansible наиболее простой и удобный инструмент, из существующих, который позволяет буквально небольшим yaml файлом описать процесс деплоя и использовать его для любого количества серверов. Ansible берет на себя обработку ошибок, параллельное выполнение и многое другое.

Подготовка сервера

Подготовка сервера для деплоя Docker приложения, очень простая задача. В таком случае, вся настройка сведется добавлению ssh-ключей для доступа без пароля и установке Docker.

Создайте самый дешевый сервер (Droplet в терминах DigitalOcean, Compute Cloud у Yandex Cloud) для деплоя. Его стоимость 5$ в месяц. Здесь есть хитрость, по умолчанию DO предлагает сервера с чистыми операционными системами, но если переключиться на вкладку Markeplace, то там есть Ubuntu с предустановленным Docker. То что нам нужно.

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

Когда сервер будет готов, DO покажет вам его ip-адрес. Возьмите этот адрес и попробуйте подключиться к серверу по ssh. Если у вас получилось, то можно готовиться к деплою.

Подготовка к деплою

Для деплоя нам понадобится настроенный Ansible. Установите его. Все файлы Ansible мы будем хранить в директории ansible.

Создадим плейбук, который выполняет всю работу по деплою приложения. Первым делом нам нужно установить python-пакет docker, который используется Ansible для управления Docker. В свою очередь python-пакеты устанавливаются через pip3, который тоже нужно установить. В ручную мы бы сделали это так:

Теперь тоже самое, но через Ansible:

Осталось добавить старт приложения и можно пробовать запускать. Для работы с докером у Ansible есть специальный модуль comunity.docker.docker_container. У него много настроек, но нам сейчас нужны лишь некоторые:

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

Осталось создать inventory-файл. Здесь все просто. Доблавяем группу webservers с одним сервером web1:

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

Деплой

Когда все готово, остается запустить одну команду, которая выполнит деплой:

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

Откат

Ситуация чуть сложнее когда у нас есть база данных, но об этом дальше по курсу.

Разделение плейбуков

Источник

Heroku и React: деплоим свое первое приложение

Всем привет. Вместе с весной в OTUS пришли новые курсы, знакомить с которыми мы начинаем прямо сегодня. Уже сейчас открыт набор на курс «React.js разработчик». Подробнее о курсе можно узнать на бесплатном вебинаре, который пройдет 11 марта. В рамках этого же вебинара будет разработано небольшое веб-приложение на ReactJS.

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

Стартовый шаблон Create-react-app и Heroku — это прекрасные инструменты для быстрого создания работающих в облаке приложений, однако документация React и Heroku включает в себя на удивление немного информации о том, как все-таки выкатить свое React-приложение на Heroku. Описанные в этой статье шаги сработают на любом проекте, созданном с помощью create-react-app. В нашей статье мы задеплоим на Heroku простое todo-приложение с самым минимальным бекэндом, просто чтобы посмотреть на сам процесс. Но обо всем по порядку:

Что такое вообще Heroku? Зачем он мне нужен?

Heroku — это облачная платформа как услуга (PaaS), которая поддерживает множество языков программирования (и этим она очень хвастается и выделяется). История Heroku началась в 2007, и тогда первым языком программирования был Ruby. Теперь она поддерживает Java, Node.js, Scala, Clojure, Python, PHP и Go.

А зачем мне это облако? Я вот могу хостинг недорогой купить

Да, вы можете купить себе любой хостинг и установить туда Node.js сервер, если на хостинге поддерживается эта услуга. Однако облачные платформы обладают такими качествами, как, например, эластичность и учет потребления — если на ваш сервис заходит очень много пользователей, тогда платформа скорее всего автоматически (или вы сами с помощью предоставленных платформой инструментов) отмасштабирует или сузит поток. Учет потребления означает, что вы заплатите только за те ресурсы, которые оказались востребованы. Облачные платформы имеют еще множество преимуществ, с полным списком можно ознакомиться здесь. Ну а мы перейдем непосредственно к деплою.

Создание своего React приложения

Что это вообще за шаблон create-react-app? Хоть немного заниматься разработкой React приложений и не знать про него, наверное, невозможно. Этот шаблон предоставляет React, React-dom, Webpack, ESLint «под капотом». Конечно, вы можете сами собрать свое React — приложение, но зачем плодить себе сложное приложение с кучей зависимостей, когда можно воспользоваться уже готовым велосипедом?

Для начала практических шагов убедитесь, что у вас установлена Node.js.

Что бы создать новое приложение, введите в консоль следующие команды:

Можете поставить это приложение себе и развернуть его при помощи:

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

Создание своего favicon

Зачем нам вообще нужен Node.js сервер, если никакой работы с БД не проводится? С помощью сервера мы будем отдавать favicon и весь остальный код. В нашем React-приложении заходим в папку public и удаляем оттуда шаблонный favicon.ico. Я возьму иконку отсюда и перенесу ее в папку public.

Создаем свой Express-сервер

Пишем в нем следующее:

Так как мы используем пакеты express, express-favicon и path, их нужно проинсталлировать:

В package.json изменяем команду start на следующую:

Запускаем build

Дальше нам нужно забилдить приложение с помощью следующей команды:

Неплохо было бы потестировать, что наше приложение работает корректно. Для этого набираем yarn start и оцениваем, насколько корректно оно работает.

Скрываем sourcemap

Непосредственно деплой

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

Потом мы отправим наш билд с помощью следующих команд:

На этом все! Спасибо за внимание. С работающим приложением можно ознакомиться здесь, а с его готовым кодом — здесь.

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

Источник

Первые шаги с werf: собираем и деплоим простое приложение в Kubernetes

В этой статье мы рассмотрим, как с помощью Open Source-утилиты werf собрать Docker-образ простейшего приложения и развернуть его в кластере Kubernetes, а также с легкостью накатывать изменения в его коде и инфраструктуре.

В качестве кластера Kubernetes мы используем minikube, что позволит легко и быстро попробовать поработать с werf прямо на рабочем компьютере.

Для тех, кто слышит это название впервые, поясним, что werf — это CLI-утилита, организующая полный цикл доставки приложения в Kubernetes. Она использует Git как единый источник, хранящий код и конфигурацию приложения. Каждый коммит — это состояние приложения, которое во время доставки werf синхронизирует с container registry, дособирая несуществующие слои конечных образов, а затем с приложением в Kubernetes, перевыкатывая изменившиеся ресурсы. Также werf позволяет очищать container registry от неактуальных артефактов по уникальному алгоритму, опирающемуся на историю Git и пользовательские политики.

Почему werf? Что в ней такого полезного и особенного? Основная ее фишка — объединение привычных для разработчиков и DevOps-/SRE-инженеров инструментов, таких как Git, Docker, container registry, CI-система, Helm и Kubernetes под одной утилитой. Тесная интеграция компонентов совместно с заложенными в процесс работы лучшими практиками, накопленными нашей компанией за годы работы с кубернетизацией приложений разных клиентов и запуском их в Kubernetes, делает werf достойным претендентом для доставки вашего приложения в Kubernetes.

Подготовка системы

Перед началом работы установите в вашу систему последнюю стабильную версию werf (v1.2 из канала обновлений stable), воспользовавшись официальной документацией.

Все команды и действия, приводимые в статье, актуальны для операционной системы Linux, в частности Ubuntu 20.04.03. При работе с другими ОС, такими как Windows или macOS, команды аналогичны, но могут встречаться небольшие особенности для каждой из этих ОС. (Найти уже адаптированные инструкции для этих систем можно в разделе «Первые шаги» нашего самоучителя.)

Сборка образа

Для начала нужно написать сам скрипт, который будет представлять собой наше «приложение». Создадим каталог, в котором будем работать (у нас это каталог app в домашнем каталоге пользователя):

Инициализируем в созданном каталоге новый Git-репозиторий и закоммитим первые изменения — созданный скрипт:

Т.к. собираться и работать наше приложение будет в Docker, создадим рядом со скриптом Dockerfile, в котором будет описана логика сборки приложения в образ:

Уже готовое состояние репозитория с нужными сейчас файлами также можно забрать из этого каталога репозитория werf/first-steps-example.

Теперь мы готовы собрать наше приложение. Обратите внимание, что перед сборкой нужно зафиксировать все изменения в репозитории проекта (созданные нами Dockerfile и т. д.), поэтому для начала выполним следующие команды:

Запустим сборку приложение командой:

При успешной сборке увидим примерно следующий лог:

Чтобы убедиться в результате сборки, запустим собранное приложение командой:

Проверим, что все запустилось и работает как нужно. Перейдем в браузере по адресу http://127.0.0.1:8000/ping, либо запросим ответ в другом терминале при помощи утилиты curl :

Подготовка к деплою

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

установим и запустим minikube — минимальный дистрибутив Kubernetes, который можно использоваться для простой и быстрой установки на рабочий ПК;

установим NGINX Ingress Controller — специальный компонент кластера, который отвечает за маршрутизацию запросов снаружи вовнутрь;

настроим файл /etc/hosts для доступа к кластеру по доменному имени приложения;

авторизуемся на Docker Hub и настроим секрет с нужными учетными данными;

непосредственно задеплоим приложение в K8s.

1. Установка и запуск minikube

Для начала установим minikube, следуя его официальной документации. Если у вас в системе он уже установлен, убедитесь, что его версия соответствует последней актуальной (v1.23.2 на момент публикации статьи).

Создадим Kubernetes-кластер с помощью minikube:

Зададим пространство имен в Kubernetes (namespace) по умолчанию, чтобы не указывать его явно каждый раз при использовании kubectl (здесь мы только задаем имя по умолчанию, но не создаём сам namespace, это будет сделано ниже):

Установить ее в систему отдельно, воспользовавшись официальной документацией.

Использовать поставляемый с minikube бинарник утилиты. Для этого достаточно выполнить команды:

Если вы выбрали второй вариант, то при первом обращении к kubectl по созданному alias’у утилита будет выкачана и доступна к использованию.

Давайте проверим, что все прошло успешно, и посмотрим на список всех Pod’ов, запущенных в свежесозданном кластере:

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

В результате выполнения команды мы увидим приблизительно следующую картинку:

2. Установка NGINX Ingress Controller

Следующим шагом в подготовке будет установка и настройка Ingress-контроллера, основной задачей которого будет проброс внешних HTTP-запросов в наш кластер.

Установим его следующей командой:

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

Если все прошло успешно, вы увидите сообщение о том, что аддон успешно установлен и активирован.

Немного подождем, чтобы он успел запуститься, и убедимся, что он работает:

В результате будет отображено нечто похожее на картину ранее:

3. Внесение изменений в файл hosts

Если все работает как надо, выполним следующую команду:

Давайте убедимся, что все сделанное нами выше работает как надо. Выполним запрос на адрес http://werf-first-app.test/ping с использованием утилиты curl :

Если все работает правильно — NGINX Ingress Controller вернет страницу с кодом 404, сообщающую, что такого endpoint’а в системе нет:

4. Авторизация в Docker Hub

Залогинимся на Docker Hub, выполнив следующую команду:

5. Создание Secret для доступа к registry

Чтобы иметь возможность в процессе работы пользоваться приватным container registry для хранения образов, необходимо создать Secret с учетными данными для входа в registry. Здесь есть одна особенность — Secret должен располагаться в том же namespace’е, что и приложение.

Поэтому необходимо заранее создать namespace для нашего приложения:

Далее создадим Secret с именем registrysecret :

На этом шаге подготовку окружения к деплою можно считать завершенной.

Далее мы будем использовать созданный Secret для получения образов приложения из registry, указывая поле imagePullSecrets при конфигурации Pod’ов.

Деплой приложения в кластер

Для деплоя приложения в кластер необходимо подготовить Kubernetes-манифесты, которые описывают необходимые для работы ресурсы. Создавать их будем в формате Helm-чартов — пакетов Helm, содержащих все определения ресурсов, необходимых для запуска приложения, инструмента или службы внутри кластера Kubernetes.

Для нашего приложения понадобится три ресурса — Deployment, отвечающий за запуск приложений в контейнерах, а также Ingress и Service, отвечающие за доступ к запущенному приложению снаружи и изнутри кластера соответственно.

Для их создания в случае нашего приложения получится следующая структура файлов:

Рассмотрим манифесты используемых ресурсов более подробно.

1. Deployment

Ресурс Deployment отвечает за создание набора Pod’ов, запускающих приложение. Выглядит он так:

2. Service

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

3. Ingress

Деплой приложения в Kubernetes

Зафиксируем в Git изменения конфигурации — добавленные ресурсы для деплоя в Kubernetes, — как делали в начале статьи:

Уже готовое состояние репозитория с нужными сейчас файлами также можно забрать из этого каталога репозитория werf/first-steps-example.

Запускаем деплой командой:

Если все прошло успешно — вы увидите примерно такой лог:

Давайте убедимся, что все прошло успешно:

В ответ получим заветное:

Мы успешно задеплоили приложение в Kubernetes-кластер!

Внесение изменений в приложение

Давайте попробуем внести изменения в наше приложение и посмотреть, как werf его пересоберёт и повторно задеплоит в кластер.

Масштабирование

Сейчас реплика одна (смотрим на количество строк, начинающихся на werf-first-app ). Вручную заменим их количество на четыре:

Сейчас мы произвели масштабирование вручную, напрямую указав количество реплик внутри кластера, минуя при этом Git. Если сейчас снова запустим werf converge :

А затем снова посмотрим на количество реплик приложения:

То увидим, что количество снова соответствует тому, что указано в Git-репозитории — в файле-манифесте, который мы не редактировали. Так получилось потому, что werf снова привела состояние кластера к тому, что описано в текущем Git-коммите. Этот принцип называется гитерминизмом (giterminism, от англ. Git + determinism).

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

Новое содержимое файла:

Закоммитим изменения и пересоберем приложение командой:

Если теперь посмотреть количество запущенных реплик, их будет четыре:

Меняем само приложение

Действуем по старой схеме — коммитим изменения, перезапускаем converge и смотрим результат:

Поздравляю, у нас все получилось и работает!

Выводы

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

Эта статья основана на главе «Первые шаги» нашего онлайн-самоучителя. Представляя её как максимально лаконичный практический tutorial, мы не стали останавливаться на некоторых теоретических вопросах, которые раскрыты в полном руководстве: шаблоны и манифесты Kubernetes, основные ресурсы K8s для запуска приложений (Deployment, Service, Ingress), режимы работы werf и гитерминизм, использование Helm в werf и т. д. Ответы на них можно найти, проходя «Первые шаги» в полном самоучителе.

Надеемся, что эта статья поможет вам сделать ваши первые шаги с werf и приобрести немного опыта в части деплоя приложений в Kubernetes!

С любыми вопросами и предложениями ждем вас в комментариях к статье, а также в Telegram-каналe werf_ru, где уже более 700 участников и всегда рады помочь. Любым issues (и звёздам) всегда рад и GitHub-репозиторий werf.

Источник