Что такое деплоить проект
Что такое деплой в программировании
Deploy (деплой) — что это такое? Дословный перевод слова деплой на русский язык означает «развертывать». Давайте разберемся что именно мы развертываем и каким образом.
После того как программный код сайта написан, возникает вопрос: что-же необходимо сделать, чтобы он появился в интернете? Как правило, классический путь состоит из 3-х шагов:
Простыми словами, деплой — это процедура переноса вашего сайта на сервер. Данная операция может быть очень затруднительной и напрямую зависит от применяемых инструментов. Когда программисты начинают реализовывать deploy, они выполняют следующие действия:
Мы привели в пример один из возможных и очевидных вариантов для понимания, на самом деле их бесчисленное множество.
Хочется отметить, что многие web-студии до сих пор реализовывают данный процесс вручную. То есть программист заходит на сервер и включает git pull. После чего реализовывает вышеуказанные пункты. Данный подход к деплоингу — неправильный. Web-deploy подразумевает под собой полную автоматизацию всех задач, которые необходимо выполнить.
По большому счету, на сегодняшний день все работы, связанные с настройкой и обслуживанием серверов должны быть максимально автоматизированы и отточены.
Однако невзирая на множество различных вариантов деплоя проектов, существует одно неотъемлемое правило для каждого — запрещено делать откаты. Другими словами, если в процессе выполнения deploy вы допустили ошибку и все пошло не по плану, то следует «деплоить» по новой версию, которая была ранее.
Помимо этого, deploy можно подразделять на категории откатов и обновлений:
Так же следует отметить такой способ, как канареечный релиз (canary release). Применяя такую методологию переход на обновленную версию происходит поэтапно — первоначально для малого количества пользователей, а потом для всех остальных.
Выбираемый вариант деплоинга напрямую зависит от применяемого хоста, а также метода настройки сервера. Вот перечень основных хостингов:
По большому счету все варианты web-деплоя разделены на 2 составляющих: на PaaS и все прочее.
Теперь вы знаете, что такое деплой для сайта или приложения. Также следует отметить, что существует такое понятие, как Deployer для PHP. Данная опция позволяет загрузить на сервер определенную ветку системы контроля версий. Более того, ему можно написать задачи наподобие выполнения миграции после выкачивания ветки на рабочий сервер.
Надеемся данный материал был для вас полезен. В случае, если вы не смогли найти ответа на ваш вопрос или в чем-то не до конца разобрались — пишите нам в комментарии, и мы обязательно ответим.
Deployer — удобный и гибкий деплой приложений
Несомненно, тема, думаю, многими заезжена до дыр — всё-таки, деплой надо делать для каждого проекта — но я всё же подниму её и расскажу об одном замечательном инструменте, о котором, по какой-то странной причине, до сих пор ничего не написали на Хабре, да и вообще в русскоязычном сегменте как-то о нём мало что написано. Исправим это недоразумение.
Deployer хорош во многих отношениях. Код скрипта для деплоя получается коротким. Написан на старом добром Пыхчанском — то бишь, скорее всего, ставить отдельно какие-то другие инструменты на сервер вам не придётся. Если же и придётся — то PHP обычно устанавливается одной командой на любом сервере. Почему-бы и не заюзать его в своих проектах?
Первый коммит был сделан аж в 2013-м году, и до сих пор инструмент потихоньку развивается. У него также есть приятный сайт, на котором можно найти о нём всю документацию.
Что лично мне нравится больше всего из того, что даёт данный инструмент — это возможность быстро откатиться на прошлый «рабочий» релиз, если новый релиз оказался неудачным. Также довольно удобно то, что если при попытке «выкатить» новый релиз что-то пойдёт не так (миграции не применились, фронтенд файлы не скомпилировались, тесты не прогнались..) — то ваше текущее работающее приложение это никак не затронет — оно будет работать как ни в чём ни бывало. Дело в том, что Deployer не изменит ссылку у директории, обозначающей текущий активный релиз, до того момента, пока ваш новый «релиз» не будет полностью установлен и готов к работе.
Единственное, чего Deployer не решает — это возможные проблемы с применением миграций к вашей базе данных. Но это вообще тема сложная, не знаю, существуют ли вообще элегантные решения в данном случае. Если существует — буду рад узнать, какое.
Структура папок релизов
Пример скрипта деплоя Laravel приложения
Я люблю лично зайти на свой сервер, запустить скрипт деплоя и наблюдать за процессом его работы. Просто, мне так намного спокойнее жить, так как я всегда могу предпринять какие-то срочные меры, если при деплое что-то пойдёт не так. А так, как я знаю, люди обычно запускают подобный скрипт со своей локальной машины, которая подключается по SSH к серверу и производит деплой. Если это надо сделать сразу на нескольких машинах — то такой подход конечно будет удобнее. К слову, Deployer позволяет выполнять деплой сразу на нескольких машинах в том числе.
Естественно, перед тем как получить возможность выполнить данный скрипт, вам необходимо сначала установить Deployer на свою систему.
В одном из моих проектов на Laravel 5 скрипт деплоя deploy.php выглядит следующим образом:
Следовательно, чтобы запустить процесс деплоя, нам остаётся набрать лишь одну команду в Bash’е:
Таким образом, как мы видим, введя всего одну команду, мы заставим сервер выполнить все необходимые шаги для разворачивания нашего проекта. И только если всё прошло хорошо, папка current сменит ссылку на новый релиз и перезапустит PHP после всего этого.
В общем-то, это всё, что я хотел рассказать и показать. Надеюсь, это будет кому-то полезным. Ну и конечно интересно будет узнать мнение других людей о том, как они занимаются деплоем своих приложений.
Эволюция процесса деплоя в проекте
Денис Яковлев (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.
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 различными способами: