Когда мы были детьми, мы многого не понимали, что на данный момент является абсолютно очевидным. "Почему я не могу есть одни конфеты? Почему бутерброды — не еда, я же это ем? Почему я не могу спать с хомяком? Зачем чистить зубы каждый день, да еще целых два раза?!" Действительно, зачем? Но будучи взрослыми, зрелыми людьми, мы не задаемся подобными вопросами.
Похожая ситуация происходит и в мире IT (возможно, это касается любой профессиональной деятельности). Многих вещей на начальных стадиях мы можем не понимать. "Зачем, да и вообще кому нужны всякие Symfony, если есть WordPress? Зачем тратить время на автоматическое тестирование, если и так все работает? Git? Linux? SOLID, DRY, DDD, TDD? Что за страшные слова?". Новичкам сложно понять, зачем нужно так много всего. Осознание приходит со временем и вскоре такие вещи становятся не только понятными, но и очевидными.
Хочу рассказать свою историю того, как я дорос до Docker и что этому поспособствовало.
Дисклеймер
Эта статья всего-лишь повествование, в котором могут быть как объективные, так и субъективные мысли. Если я в чем-то не прав или сильно заблуждаюсь, пожалуйста, скажите мне об этом. Я люблю здравую, адекватную критику и готов принять конструктивные замечания.
Docker достаточно простая вещь. Но вы когда-нибудь пытались объяснить простому смертному, что это такое? Я пытался. Не получилось. Я и сам долгое время не понимал, зачем нужна эта штука. Я слышал про него, пытался вникнуть, но каждый раз бросал. Видимо, было еще рано — не созрел. Но в определенный момент произошла "Эврика"! Это был достаточно долгий путь, о котором я хотел бы рассказать другим. Возможно, эта статья поможет Вам сократить свой путь и начать пользоваться этим замечательным инструментом как можно раньше.
Этап 1. FTP или что-то подобное
Когда я начал работать веб-разработчиком, я попал в одну очень маленькую контору. Опыта у меня было 0, мы разрабатывали простые сайты на собственной, как мы это называли, "CMS". Слово OpenSource для меня было незнакомым, все функции писались руками, архитектуры не было никакой. Дыры в безопасности были подобны черным дырам. Если сайты типа "Блог", "Самый простой интернет-магазин" или "Новостная лента" были еще как-то реализуемы, то вещи чуть сложнее вызывали дикую боль и страдания. Работали мы через FTP, из-за чего возникали серьезные проблемы, когда два человека работали над одним и тем же файлом. Если кто-то что-то сломал или случайно затер, это пропадало на веки вечные.
И тут к нам пришел заказчик, по совместительству мой хороший друг, с одним незаурядным на фоне всех других наших работ проектом. Мы приступили за работу, но вскоре контора закрылась и я стал напрямую работать с этим проектом один. Тогда у меня и появилась возможность сделать все по-человечески...
Этап 2. LAMP
На втором этапе было принято несколько решений, порядок которых я уже и не помню. Скорее всего они происходили одновременно.
Во-первых, весь код я стал хранить в приватном Git репозитории на Bitbucket. Это, пожалуй, первое, чему стоит научиться любому разработчику. Это повысило защищенность кода от стороннего вмешательства. VPS мог сломаться, его могли взломать, просто не успели заплатить. Думаю, мысль ясна. Помимо этого, я закрыл FTP и деплой происходил по Git Push Webhook из ветки release или test.
Во-вторых, вместо одного сайта, было запущено два почти одинаковых. Первый — релиз, который обслуживал реальных клиентов. Второй — тестовый, который был запаролен, имел все самые последние нестабильные фичи. Последний нужен для того, чтобы не выкатывать в продакшн то, что не проверено и может работать не правильно. Хоть и работали эти два сайта на одном хосте, но были независимы.
В-третьих, что самое главное, разработка стала вестись локально. На ноутбук устанавливался стек LAMP, все это дело настраивалось, проект запускался локально на поддомене .dev (UPD Этот домен как оказалось занят и использовать его не стоит. Спасибо alexkbs, за комментарий). Это значительно ускорило разработку, позволило работать offline, пропала боязнь что-то сломать и жить стало чуточку проще.
Но вдруг я накосячил и пришлось переустановить Ubuntu. Заново приходится устанавливать и настраивать весь этот стек… Это дело можно было автоматизировать bash скриптом, но будет жесткая привязка к системе. Пусть я работаю один, но у начальства есть планы нанять второго, поэтому хотелось бы упростить жизнь и ему, и себе. После нескольких таких косяков я все таки нашел решение.
Этап 3. Vagrant
Vagrant — проще говоря, это инструмент, который дает Вам возможность настраивать VirtualBox скриптом. То есть, если написать правильный конфиг, то одной командой vagrant up можно загрузить готовый образ Debian, установить туда необходимый софт, настроить и получить готовое тестовое окружение.
Ну не чудо ли? На самом деле чудо! Это заметно упростило процесс разворачивания среды разработки, очистило основную систему от ненужных пакетов, и, благодаря виртуализации, я смог настроить машину как можно ближе к настройкам хостинга.
Виртуализация здорово подходит для разработки. Но в продакшн оно не годится. Это лютый овехед для системы. К тому же этот метод не решает несколько проблем:
- Окружение хостинга и виртуальной машины похоже, но не одинаково. Поэтому все еще всплывали баги жанра "У меня все работает"
- Окружение хоста и виртуалки нужно было поддерживать в актуальном состоянии. Если что-то менялось на сервере, нужно было менять и в виртуалке
- Смена хостинга или переустановка системы в VPS еще та боль. Хостинг все еще приходилось настраивать вручную.
- Обновлять некоторые пакеты не так-то просто. Попробуйте обновить PHP с версии 5.6 на 7.x. Это возможно. Но вероятность напортачить с зависимостями или сломать apache2 все же присутствует. Особенно, если Вы не сисадмин, а просто веб-разработчик, который любит и немного знает линукс.
- Попробуйте запустить на одном хостинге два проекта с разными версиями MySQL и PHP. Почему-то я сомневаюсь, что это вообще возможно. Это может быть полезно, если нужно протестировать, как работает сайт на новой версии PHP, при этом продакшн оставить на старой версии. Вероятность что-то сломать при подобной настройке очень велика.
Да и лишними несколько гигабайт оперативки никогда не бывает.
Этап 4. Docker!
А вот теперь возьмите все проблемы из всех этапов выше и представьте, что есть инструмент, который просто и элегантно решит их за Вас.
Что такое Docker? В интернете очень много сравнений с контейнерами, которые используются для транспортировки товара. Это верно.
Но представьте себе большой зал и много людей, которые над чем-то работают. Не обязательно, что они делают одно и то же. Бухгалтера, юристы, плотники, маляры, аналитики, программисты. Да, они иногда взаимодействуют. Но из-за того, что у них нет личного рабочего пространства, такая работа больше похожа на хаос. Беда с документами, кто-то у кого-то ручку стащил, кто-то сел на чужой стул, притронулся к не своему компу и п.р. Но если поставить перегородки, каждому человеку или группе людей выделить личное рабочее место, то и жить становится проще. Каждый занимается своим делом, пользуется своими ресурсами, никому не мешает. Взаимодействие происходит через выделенные каналы — почту, архивы или двери.
Также и Docker. Большой зал — это Ваша система (в действительности, всё немного сложнее, но для общего понимания концепций можно и упростить). Docker может создать изолированное пространство для процесса или группу процессов, делающих свою работу. Взаимодействие происходит путем открытых портов, общих файлов, внутренних и внешних сетей. Никто никому не мешает. Таким образом, Вы можете на одном хосте иметь хоть 20 версий PHP или еще чего-нибудь. А благодаря образам (images) Вы можете, образно говоря, заказать готовый офис со всеми плюшками.
Подключение к проекту новых компонентов стало вопросом нескольких строк благодаря docker-compose. Вот несколько примеров:
#Подключение PHPMyAdmin
pma:
image: phpmyadmin/phpmyadmin:4.7
restart: always
environment:
MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
depends_on:
- db
ports:
- "181:80" #Подключение MySQL
db:
image: mysql:5.7.20
restart: always
environment:
MYSQL_DATABASE: ${DB_NAME}
MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
volumes:
- db-data:/var/lib/mysqlНужно обновить версию MySQL? Сколько времени и усилий пришлось бы приложить, чтобы сделать это на обычном VPS хостинге? Тут это вопрос 3-4 символов.
Благодаря тому, что Docker работает внутри рабочей системы, а не создает новую, он не сильно нагружает машину для разработки и вполне пригоден для прода. И это большой плюс, потому что код, запущенный на машине разработчика с Ubuntu, будет работать ровно также, как и на сервере с Debian
Еще одна польза от такого решения — автоматическое тестирование стало значительно проще. Проверка происходит внутри изолированных контейнеров, которые создаются перед каждым запуском. Поэтому тесты стабильны и выполняются или не выполняются всегда.
Заключение
Docker понять не просто, несмотря на его простоту. Для этого нужно подрасти. У меня не было надежного руководства, поэтому все приходилось постигать самому. Возможно кто-то как я благодаря этой статье сможет вырасти немного быстрее.
Хочу отметить одну мысль. Внедрение Docker может быть порой избыточным. Если у Вас личный блог, одностраничник или какой-либо другой простой проект, то настройка сервера съест у Вас время и ресурсы, а на выхлопе профита либо не будет, либо он будет отрицательным. Но если это крупный и долгосрочный проект, до Docker скорее всего будет правильным решением. Это как автоматические тесты. Для маленьких проектов они не нужны, тогда как для крупных обязательны.
И еще, я никого не хочу учить плохому. Если я предоставил какую-то ложную информацию, пожалуйста, исправьте меня. Если допустил ошибку, помогите исправить.
Комментарии (136)
dluhhbiu
30.11.2017 17:03+1База в докере? Серьезно?
vtvz_ru Автор
30.11.2017 17:18Это не похоже на конструктивную критику. В чем проблема базы в докере? Окей, может быть для нагруженных проектов имеет смысл вынести базу в хост машину или даже на отдельный сервер. Но overhead от использования в докере не такой большой, чтобы как-то сильно запариваться. Производительность в худшем случае будет 91%, а в лучшем 96% от использования базы на хост машине. С другой стороны, благодаря тому, что именованных томов (volumes) хранятся в одном месте, проще настроить backup один раз, и забыть. Или я чего-то не знаю? Буду благодарен, если просветите.
dluhhbiu
30.11.2017 20:09Проблема не в производительности, а в стабильности.
На тестом сервере или при локальном разработке база в докере это замечательно и удобно.
Но не в проде. Тут рассказывают почему. Пункт «Запрещено использовать в DBA.»
grossws
30.11.2017 20:48Стоит учитывать, что это перевод довольно истеричной статьи 2016 года.
Например, там упоминаются aufs, overlay и overlay2, но не devicemapper, btrfs, vfs или zfs. Тот же devicemapper на мой вкус куда более приятен чем aufs, "стабильность" которого меня поразила в своё время наповал. В итоге, в проде у меня были только devicemapper, btrfs (только для экспериментов) и overlay (т. к. прод на CentOS 7 с небольшой примесью CentOS 6). Использовать в проде overlay поверх чего-то кроме ext4 крайне не рекомендую.
Базы, которые у меня в проде живут в контейнерах используют исключительно bind mount на нормальные фс (xfs, ext4) поверх lvm2. Естественно, эти fs должны быть изолированны от
/var/lib/docker(или где у вас живёт docker graph).
В 2015 докер был ещё сильно сырой и использовать его в продакшне было опасно. В частности, были баги в cgroups, которые приводили к паникам (на centos6). В современном мире уже всё не настолько страшно.
Я не призываю переносить базы в docker, если этого можно избежать. И тем более, запускать базы поверх чего-нибудь типа flocker. Но в некоторых условиях запускать базы в контейнерах вполне можно.
neumeika
30.11.2017 22:59devicemapper, серьёзно? Контейнеров хотя бы 40 на хост, ci/cd jenkins/teamcity/bamboo для деплоя в паралельку (ну хотя бы штуки по 3 одновременно) с docker api, и вот тут начинается веселье с локами, а ещё можно ждать docker rm -f в несколько минут. Удачи в проектах покрупнее. А вот оверлей и его братик с индексом 2 очень хороши, желательно ещё ядро 4 накинуть. И лучше кубернетесом приправить :)
grossws
01.12.2017 20:20overlayвёл себя нестабильно на redhat'овском 2.6.32 некоторое время назад, особенно поверхxfs. Более нестабильно, чем btrfs, с kernel oops'ами в недрахxfs. Сейчас у меня на проде на centos7overlayповерхext4.
UPD: засомневался, что у меня на 2.6.32 был
overlay, но сейчас уже не проверю, того сервера уже нет. Возможно, это было на ранних ядрах 7 centos'а.
dmу меня вполне себе жил (на железном lvm, не на loop, как оно по умолчанию) без особых проблем в сравнении сoverlayповерхxfs. При количестве контейнеров ~30-50.
Отвечу сразу shurshur, у меня с
dmтаких проблем не было поверх lvm на железе, но как выше писал, в основном у меня живётoverlayповерхext4.
shurshur
01.12.2017 20:31Так у нас dm вылез из-за того, что какая-то версия докера для centos по умолчанию использовала именно dm, а часть серверов на проде выкатывались чуть раньше, в итоге у нас часть серверов без проблем, а часть — докер раз в неделю в несознанке.
grossws
01.12.2017 20:39Проблемы сырого продукта, никуда не деться. Но сейчас уже всё не столь болезненно. Хотя, что сейчас с
dmв этом плане — без понятия.
shurshur
01.12.2017 20:12Не надо использовать dm в проде, с ним обязательно что-то случается время от времени, и временами ничего лучше полного ребута сервера не помогает.
lavilav
30.11.2017 17:19популярное решение.
отдельно монтируется директория с данными, на реальной файловой системе.
имеет место быть.n0dwis
30.11.2017 17:41Не подскажете, как решить проблему с владельцем файлов БД? Postgres в докере отказывается запускаться, если владелец не postgres. Но хотелось бы иметь доступ к базе и с хоста (не отдоновременно с docker-ом конечно).
Есть какое-то решение как при монтировании volume сменить владельца файлов и потом обратно?
SirEdvin
30.11.2017 18:06Какого рода вам нужен доступ к базе? Возможность запустить бд еще и с хостовой системы или просто доступ по psql?
Второе и так работает, для получения первого нужно шаманить с uid.n0dwis
30.11.2017 18:11Сейчас база как раз на хосте. Перенести её в docker можно, но придётся менять uid, и обратно тоже. Автоматически это нельзя делать? Какой-нибудь командой RUN в dockerfile или опциями монтирования, может ещё как?
SirEdvin
30.11.2017 18:30+2Стандартный образ postgres для docker делает chown для файлов базы перед запуском, если с правами что-то не так.
skobkin
03.12.2017 16:33Последний раз, когда пробовал работать с официальным образом PostgreSQL, также были проблемы с доступом к файлам. Плюс было не очень понятно, как из docker-compose.yml универсально прокидывать юзера не хардкодя его UID — ведь этот конфиг могут запускать люди с разными UID, а не только 1000.
С того момента, правда, вышла уже третья версия схемы compose. Возможно, там это решено — нужно посмотреть.VolCh
03.12.2017 16:40Плюс было не очень понятно, как из docker-compose.yml универсально прокидывать юзера не хардкодя его UID
А зачем? Особенно учитывая, что сам docker вполне может быть на удалённой машине.
SirEdvin
03.12.2017 20:15+1Проблемы с доступов для кого? Для postgres или для вас? Тут уж надо выбрать что-то одно. Единственное что могу сказать, что postgres и вне докера дает доступ к своим файлам только себе и рут-пользователю.
neumeika
30.11.2017 23:05не надо ничего менять потом, если я правильно вас понял
for Dockerfile:
#Hate docker volumes
&& usermod -u 10001 «posgresuser» && groupmod -g 10001 «posgresuser» && chown -R «datadir»
но лучше воздержаться от БД в докере
wladyspb
01.12.2017 14:02А что не так, собственно? Если мы говорим о разработке, естественно.
У меня сейчас на ноуте крутится гроздь контейнеров, и среди них 4 — базы данных(mariaDB, Redis, ClickHouse, Couchbase). Данные хранятся в папке приложения и линкуются внутрь контейнеров, поэтому при перезапуске или пересборке контейнеров я не теряю данные. На производительность тоже не жалуюсь — для разработки вполне хватает, всё очень шустро бегает) А на проде весь этот зоопарк разбит по нескольким серверам с репликацией, и этим рулит админ.
Fantyk
30.11.2017 17:20Для этого нужно подрасти. У меня не было надежного руководства, поэтому все приходилось постигать самому. Возможно кто-то как я благодаря этой статье сможет вырасти немного быстрее.
Это действительно проблема, материалов по Docker в русскоязычном сегменте мало, приходится много времени проводить за мануалами на не родном языке. Но ваша статья не решает эту проблему, очередная вода с неполным листингом docker-compose
P.S. Пользуясь случаем прошу подсказать возможные способы деплоя docker проекта на 1 сервер (без оверинжиниринга вроде kubernetes).vtvz_ru Автор
30.11.2017 17:35- Я в начале статьи написал, что это рассказ о моем опыте. Обещания дать много инфы я не давал. Это статья о понимании Docker'а, как инструмента, а не инструкция по его использованию. Более содержательные статьи об использовании Docker будут в будущем. Есть идеи, которые в интернете как-то совсем не раскрыты.
- Это не листинг docker-compose, а строки, которые нужно добавить, чтобы подключить БД или PMA. Как мне кажется, фраза "Подключение к проекту новых компонентов стало вопросом нескольких строк" на это мягко намекает. Специально разделил эти два куска, чтобы (возможно) было яснее. Писать полный конфиг compose в этой статье я не вижу смысла.
На самом деле… Простых инструментов деплоя я не знаю. В Bitbucket есть pipelines. Можно сделать примерно так:
- Упаковать нужные файлы в архив вместе с docker-compose файлом
- Отправить файл на сервер по ssh
- Распаковать его
- Запустить build и up
- Убраться за собой (удалить архив, остаточные файлы и т.п.)
Не самый идеальный способ, но как-то работает. Для малых и средних проектов, я думаю, подойдет.
KirEv
30.11.2017 17:54самое простое решение, как по мне, использовать посредником docker hub,
1. готовишь релиз application с тестами и т.п.
2. собираешь ducker image
3. пушишь в свой hub
4. создаешь web-хук на хабе, который даст сигнал серверу, на котором хук расположен, стянуть обновленный билд нужного docker image
5. запустить тесты и все остальное что проверяет работоспособность полученного image
в двух словах примерно так и сделали, не доросла наша компания до использования готовых инструментов CI/CD, которых, к слову, не счесть… а понять что подходит лучше — по немногу в каждом надобно разбираться.
chelovekkakvse
30.11.2017 17:51+3Позволю себе немного язвы, поправьте, если я не прав.
Виртуализация здорово подходит для разработки. Но в продакшн оно не годится.
Странное заявление. Вы понимаете, как работают дата центры? В которых, в общем-то, может использоваться тот же Docker, которой является системой виртуализации :) Без виртуализации понятие «масштабирование» означало бы процесс физического наращивания мощности сервера. Т.е. по клику у хостера «добавить контейнер» происходила бы закупка оборудования, чувак бы нес все эти железки, устанавливал в ферму и т.д. И процесс бы занимал недели.
Vagrant — проще говоря, это инструмент, который дает Вам возможность настраивать VirtualBox скриптом.
В общем-то тоже самое делает и докер. Только вряд ли он для этого предназначен.
П.С.
1. Странное занятие — использовать Docker для разработки. Нет, я не отрицаю, что, например, если у вас в компании трудится 100 человек и вы разрабатываете на сервере, то быстро развернуть проект для нового сотрудника или для форка можно и докером, только зачем? Вы же сами написали про вагрант. Туда можно засунуть те же параметры деплоя, закинуть все в архив вместе с файлами проекта и кому-то отдать. Можно это все запрограммировать на уровне скриптов. Резюмируя — не о том здесь описан Docker, не о том :)
2. Если уже говорить о нормальном деплое и Continous Integration (CI), то уместнее было упомянуть стек: контроль версий (GIT, SVN, TFS), сервер CI (Teamcity, Jenkins).
3. Что я вынес из этой статьи
VolCh
01.12.2017 08:11Докер не является средством виртуализации, а использовать его для локальной разработки обычная практика.
chelovekkakvse
01.12.2017 08:40Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы.… Изначально использовал возможности LXC, с 2015 года применял собственную библиотеку, абстрагирующую виртуализационные возможности ядра Linux — libcontainer.
(с) Wiki
Виртуализация на уровне операционной системы позволяет запускать изолированные и безопасные виртуальные машины на одном физическом узле, но не позволяет запускать операционные системы с ядрами, отличными от типа ядра базовой операционной системы. При виртуализации на уровне операционной системы не существует отдельного слоя гипервизора. Вместо этого сама хостовая операционная система отвечает за разделение аппаратных ресурсов между несколькими виртуальными машинами и поддержку их независимости друг от друга. Среди реализаций:
- Solaris Containers/Zones
- FreeBSD Jail
- Linux-VServer[en]
- LXC (Linux Containers)
- FreeVPS[en]
- OpenVZ
- Virtuozzo
- iCore Virtual Accounts
Зачем использовать докер для локальной разработки? В чем его преимущество перед той же VB, которая умеет делать снимок виртуалки, который можно установить на любой комп? Или тот же вагрант? Мне все же кажется, что докер немного не про это.VolCh
01.12.2017 09:10Виртуализация на уровне ядра — это как морская свинка. :)
Навскидку, по личному опыту, виртуальные машины слишком сильно изолированы от хоста и друг друга для эффективного разворачивания сложной системы локально. Зачастую резервируют излишние ресурсы, оставляя их мало для собственно разработки. При этом на продакшене практически не используются, то есть надо поддерживать минимум два слабо связанных окружения. Практика показывает, что если на продакшене используется докер, то на вагранты часто забивают, накапливается разница в окружениях.chelovekkakvse
01.12.2017 09:55Виртуализация на уровне ядра все равно виртуализация)
Не совсем понял про слабо связанное окружение. Разве нельзя настроить одну среду на докере и вагранте? Я согласен, что здесь имеет место быть человеческий фактор, но в таком случае нужно говорить о CI, а не о докере\вагранте. В моем понимании докер востребован только тогда, когда у тебя облако\удаленный сервер и\или хайлоад. Причем я бы рассматривал его только в случае масштабирования, т.к., на мой взгляд, разработка должна вестись на локальной машине, уходить в систему контроля версий, а от туда разворачивать проект через систему непрерывной интеграции. Хотя допускаю, что разрабатывать можно на докере, форкаться и тд, потом через контроль версий заливать готовый проект в контейнер докера, там пробегать все тесты и через CI заливать контейнер с проектом. Но… если нужно обновить 1 файл в проекте, смысл все пересобирать? В общем, в данном вопросе у меня нет однозначного ответа. Могу лишь утверждать, что для себя я определил докер, как систему быстрого развертывания идентичной среды для нагруженного проекта.VolCh
01.12.2017 10:37Ну так в разработке желательно иметь среду максимально близкую к продакшену, чтобы избегать ситуаций «а у меня всё работает». Локально проверяешь, что образа билдятся, что работают как надо, а потом коммитишься и дальше уже пошло по принятому флоу. Но результат твоей работы не только исходный код на ЯП, но и докерфайлы, конфиги сервисов типа веб-сервера и СУБД, описания/скрипты процессов деплоя и т. п. Можно это делать наобум, отправляя изменения в vcs, и ожидая результата от пайплайнов CI, проверяя работу где-то, куда они её раскатали, но при наличии возможности проверить локально, почему это не делать? А докер в этом плане более простой и легковесный, и чем более сложная система, тем преимущества виднее для меня. По крайне мере пока всей системе из десятков сервисов хватает ресурсов локальной машины.
chelovekkakvse
01.12.2017 11:57Подождите. При деве необходимо на локальной машине эмулировать среду продакшена, а не наоборот. Зачем деплоить настройки среды на продакшн?
VolCh
01.12.2017 13:46Так они идентичные, единственное отличие сред (продакшен, CI, стейджинг, лоакльная) в параметрах типа DNS имён ендпоинтов и количества воркеров. Грубо, все отличия сред только в environment переменных, читаемых из какого-нибудь .env файла, который в репозиторий не вносится. Плюс для локальной можно примонтировать каталоги с локальными кодами, чтобы не билдить/рестартовать контейнер на каждый чих, только на какие-то глобальные изменения.
chelovekkakvse
01.12.2017 14:50Это понятно. У меня тогда вопрос, чем отличается среда на ВБ с Debian 9.1\PHP7.1\MySQL5.7.20 от среды на проде с тем же стеком? Я не думаю, что в вопросах данного стека принципиально железо и сопутствующие ему драйвера. Иными словами, весь этот стек штатно работает на обоих машинах, поэтому и код должен работать одинаково. Разве нет?
VolCh
01.12.2017 14:59Скорее всего, на проде это будет минимум два отдельных сервера, а то и больше. А на ВБ, скорее всего, одна виртуалка. Процедуры обновления скорее всего будут разные — на проде автоматизированная, а на виртуалке часто ставят что-то ручками, забывая занести в вагрантфайл.
vtvz_ru Автор
01.12.2017 09:41Возможно, я попутал термины. Подумаю, что можно сделать, чтобы не переписывать всю статью.
Основное преимущество Docker перед VB в первую очередь в том, что он не ест столько оперативки и не требует целой кучи ресурсов.
У меня всего 8гб, на плечи которых лежит PHPstorm со всеми плюшками, Chrome с десятком плагинов, Webpack с запущенным на нем Hot reload и ещё несколько инструментов. Чтобы запустить и держать в рабочем состоянии VB рядом со всем этим добром, нужно ресурсов гораздо больше. В итоге, ОЗУ заканчивалась, процессы лезли в swap и насиловали мой HDD, после чего разработка становится невыносимой и приходилось от чего-то отказываться.
VB запускает всю систему целиком со всеми ее процессами, которых не так уж и мало. В свою очередь Docker запускает только то, что мне нужно.
Docker запускается намного быстрее. Подключать дополнительные компоненты удобно. Тестировать хорошо, так как можно быстро поднять новый, чистый контейнер. Selenium работает из коробки без всяких танцев с бубном.
Для себя я нашел много преимуществ. Если их не находите Вы, это может говорить об одном — Вам он (Docker) просто не нужен.chelovekkakvse
01.12.2017 10:02Странно, что VB у вас ест все ресурсы хоста. ВБ это гипервизор, он жестко ограничивает использование виртуалкой ресурсов хоста. Иными словами, вы выделили виртуалке 1гб озу и 1 ядро, оно больше этого и не может использовать. Если у вас проблемы с ВБ, попробуйте Hyper-V, если конечно у вас хост на винде.
Мне докер нужен, но для предназначения, которое написано на официальном сайте проекта :) Для разработки есть масса удобных и более удобных инструментов. Тот же пхпшторм. У него из коробки идет плагин для вагранта.
На вкус и цвет конечно. Мой вопрос лишь в том, что не стрельба ли это по воробьям из танка?VolCh
01.12.2017 10:39В случае вагранта ресурсы определяет разработчик вагрантфайла. Сказал нужно 2 гига и
VolCh
01.12.2017 10:40и переопределить локально затруднительно.
chelovekkakvse
01.12.2017 12:02Ну как бы нет :)
VolCh
01.12.2017 13:48Это разве не в вагрант файле хранится?
chelovekkakvse
01.12.2017 14:45Да, в нем. Я не совсем тогда понимаю, что вы подразумеваете под
и переопределить локально затруднительно.
VolCh
01.12.2017 15:03Обычно, вагрант файл лежит в репозитории проекта или где-то рядом, с параметрами подходящими его автору, у которого, например, 32Гб оперативы и 4 физических ядра плюс HT. Вот и даст одно физическое ядро и 4 Гб, чтобы избегать малейших тормозов. А у тебя 8Гб оперативы и 2 физических ядра. Эта виртуалочка скушает половину ресурсов. А пулл реквест на изменение автор не примет. Придётся изменить и как-то следить чтобы в репу не закоммитить эти изменения, а изменения из апстрима прилетали.
Sway
30.11.2017 18:32+2Docker невозможно установить на VPS поднятом на OpenVZ если ядро linux ниже минимальной версии требуемой докером. У меня вот весьма хороший тариф на VPS, но докер я юзать не могу из-за этого ограничения, а платить в 2 раза дороже за аналогичную конфигурацию с SSD на борту вместо HDD как-то не хочется.
Т.е. не каждый VPS поддерживает докер. В итоге получаем неработающую «серебряную пулю».grossws
30.11.2017 19:36Если говорить про нормальный vps/vds, а не контейнер в openvz/lxc, то вы сами выбираете нужный дистрибутив, ядро и т. п.
Другое дело, что многим мелким проектам это просто не нужно и никогда не понадобится.
alexkuzko
30.11.2017 18:38+2Посмотрите ещё в сторону ansible. Его также можно связать с докером, иногда вместо, иногда вместе. Как раз очень прост в плане настройки, хоть и требует некоторого внимания к деталям.
andreymal
30.11.2017 19:10-1Не утверждаю, что здесь что-то плохое, но позволю себе чутка возразить на некоторые части поста
Это [Bitbucket] повысило защищенность кода от стороннего вмешательства. VPS мог сломаться, его могли взломать, просто не успели заплатить.
За VPS не следите — сами виноваты, не обеспечели безопасность — сами виноваты, не заплатили — опять же сами виноваты. А вот на битбакет теоретически может прийти крымнаш, вам прикроют ваш репозиторий из-за санкций россиянам (это я ещё роскомнадзор не вспоминаю), и вы побежите доставать репозиторий из бэкапов прошлогодней давности стаить Gogs на VPS как миленький :)
Попробуйте запустить на одном хостинге два проекта с разными версиями MySQL и PHP.
Разные версии PHP лично запускал (не на дебиане, правда, а на арче, но всё равно никаких трудностей, всё разделено по папочкам php5 и php7). А зачем может понадобиться ставить разные версии MySQL?
Если что-то менялось на сервере, нужно было менять и в виртуалке
Выше уже упомянули Ansible. Всё меняться должно только через него, и подобная проблема перестанет существовать, хоть с докером, хоть без
Но если поставить перегородки, каждому человеку или группе людей выделить личное рабочее место, то и жить становится проще.
Такой перегородкой во многих случаях может послужить банальное разделение по разным пользователям. Хотя, конечно, беспроблемно поставить двадцать версий PHP это не даст, однако это и нужно редко
Нужно обновить версию MySQL? Сколько времени и усилий пришлось бы приложить, чтобы сделать это на обычном VPS хостинге?
sudo apt-get update && sudo apt-get dist-upgrade. Можно загнать в алиас размером в 3-4 символа. Что я делаю не так?
код, запущенный на машине разработчика с Ubuntu, будет работать ровно также, как и на сервере с Debian
Ох-ох
grossws
30.11.2017 19:58А вот на битбакет теоретически может прийти крымнаш, вам прикроют ваш репозиторий из-за санкций россиянам (это я ещё роскомнадзор не вспоминаю), и вы побежите доставать репозиторий из бэкапов прошлогодней давности стаить Gogs на VPS как миленький :)
В чём проблема добавить новый
remoteи запушить актуальный репозиторий? Чай не svn/cvs.
Разные версии PHP лично запускал (не на дебиане, правда, а на арче, но всё равно никаких трудностей, всё разделено по папочкам php5 и php7). А зачем может понадобиться ставить разные версии MySQL?
Это пока вам не понадобится держать, скажем, php 5.5 и 5.3 одновременно. Или что-нибудь ещё в таком роде. Другое дело, что поправить
PKGBUILDне составляет труда. Но на prod я бы arch ставить не стал, а большинство дистрибутивов вам не позволят держать несколько минорных версий того же php одновременно. Мейнтейнить это барахло самому может быть слишком дорого.
Говоря же про несколько версий баз приведу два примера. У меня одновременно работают 4 версии MongoDB (2.6, 3.0, 3.2 и 3.4), более 20 инстансов. Так сложилось исторически и некоторые из них мигрировать на новые версии либо не имеет смысла, либо просто дорого по времени и ресурсам. Проще и безопаснее иметь несколько запущенных версий. Мейнтейнить несколько пакетов под это просто неоправдано: их сборка, поддержка и тестирование будут съедать большое количество времени и сил без значительных преимуществ относительно нескольких версий, запущенных в разных контейнерах с bind mount для актуальных данных. Другой пример — несколько инстансов postgres с различными бинарными расширениями. Причём тех версий, которых просто нет в CentOS 7.4.
Выше уже упомянули Ansible. Всё меняться должно только через него, и подобная проблема перестанет существовать, хоть с докером, хоть без
С этим сложно поспорить. Хотя ansible местами тоже та ещё боль. Если интересно, я чуток упоминал.
sudo apt-get update && sudo apt-get dist-upgrade. Можно загнать в алиас размером в 3-4 символа. Что я делаю не так?
Вы это на нормальном проде без предварительного тестирования делаете? Тогда всё делаете не так, если речь не идёт о личном бложике.
Я считаю, что пытаться фиксировать окружение вместо того, чтобы писать приложение так, чтобы оно работало как можно более везде без искусственных ограничений вроде того же докера — лень и безответственность. Если, конечно, дедлайн не вчера)
Соберите пару-тройку пакетов, требующих C++11 с фиксированной версией, скажем boost'а или poco под CentOS 7. Потом вместе посмеёмся.
Кстати, докеры и прочие виртуалки ещё и место занимают на образы базовых ОС, минималистичный Alpine в качестве базы юзают далеко не все, а на моём VPS сейчас свободно всего четыре гига, так что докер я не могу себе позволить даже если бы хотел)
Никто не мешает написать свои dockerfiles, положить их на github/bitbucket, настроить на dockerhub automated build и использовать минималистичные образы. Тот же
centos:7весит всего 74M, а дальше его можно использовать как базу для всех нужных образов. Илиalpine, если его хватает.andreymal
30.11.2017 20:17-14 версии MongoDB
Ну nosql-хипсторы уже ССЗБ) Мои проекты успешно работают на всём разнообразии версий MySQL и MariaDB за последние пять лет (а скорее всего и больше, но я просто не пробовал). Хотя про постгрес мне ответить нечего, окей
Вы это на нормальном проде без предварительного тестирования делаете?
Зачем же, есть staging-сервер, идентичный проду. Хотя вообще да, лично у меня просто условный личный бложик, и мне обновляться без подготовки на проде в общем-то не страшно) Но для страшных действий staging всё равно есть
C++11
Ой, тут я не компетентен. У меня в питонах подобной ереси нет)
grossws
30.11.2017 20:52Ну nosql-хипсторы уже ССЗБ) Мои проекты успешно работают на всём разнообразии версий MySQL и MariaDB за последние пять лет (а скорее всего и больше, но я просто не пробовал). Хотя про постгрес мне ответить нечего, окей
Ну nosql-хипсторы уже ССЗБ) Мои проекты успешно работают на всём разнообразии версий MySQL и MariaDB за последние пять лет (а скорее всего и больше, но я просто не пробовал). Хотя про постгрес мне ответить нечего, окейНу тогда и не стоит использовать ad hominem. MongoDB и Apache Cassandra в определённых областях очень удобны и заменить их на MySQL/MariaDB невозможно.
Ой, тут я не компетентен. У меня в питонах подобной ереси нет)
Вероятно, вам просто везёт, что не используются бинарные расширения, написанные на C++11 и выше. В питонячем мире на это нарваться сложнее, но тоже бывает.
Fox_exe
30.11.2017 19:13Я, наверно, тоже не дорос до Docker'а — Использую ProxMox: OpenVZ контейнеры легко копируются, а снепшоты позволяют спокойно откатываться на любую резервную копию или вообще отдельную ветку с совсем другим софтом/окрежением/проектом.
Ну и Git для кода, разумеется. (С сервером в отдельном контейнере и резервными копиями каждый час на отдельный диск)
Kroid
30.11.2017 19:26По мне, так наоборот, докер — показатель «подросткового возраста» в it. Пару лет назад я его везде использовал, потом повзрослел, и теперь только в некоторых специфических задачах его юзаю.
grossws
30.11.2017 20:02Сильно зависит от задач, да. Для некоторых вещей оверхед от использования докера будет больше, чем польза от оного. Для деплоя в проде это может быть способом избавиться от большого количества головной боли, но потребует вложения определенного количества сил и средств в соответствующую систему оркестрации (будь то банальный docker swarm, или более тяжелые kubernetes с openshift'ом).
vtvz_ru Автор
30.11.2017 21:16Жду тогда от Вас статью "Docker, как показатель подросткового возраста")
VezhLos
30.11.2017 21:46Поясните, пожалуйста, подробнее. Нутром чувствую, что с вашим комментом согласен, но надо убедиться)
beduin01
30.11.2017 22:02У меня сложилось устойчивое мнение, что Docker это костыль решающий вечные проблемы скриптовых языков когда скрипт может сломаться на ровном месте или, к примеру, какой нить JodeJS может устареть, а проект уже никто переписывать не будет.
Короче Docker только новые проблемы пораждает.
Я реально слабо представляю нафига он в том же ASP.NET или Go нужен.VolCh
01.12.2017 08:49Первое, что делает докер — изолирует процессы друг от друга, используя различные маппинги. Второе, что он делает — фиксирует окружение (как билд, так и рантайм), только версия ядра и самого докера не зависит от автора докерфайла, а так он контролирует каждый файл в своей ФС без конфликтов с другими приложениями на том же хосте.
И полезен он прежде всего для компилируемых языков. Это в скриптовых можно залезть и поправить, например, порт, который будет слушать процесс в простом текстовом редакторе, а в компилируемых так не выйдет.Temtaime
01.12.2017 09:37Нормальные приложения имеют текстовые конфиги.
А для изоляции есть LXC.VolCh
01.12.2017 10:42Докер позволяет эти конфиги вынести из приложения и конфигурировать всё в едином месте и формате.
andreymal
01.12.2017 10:44+1Докер и есть настройка над LXC) Но, по моему субъективному впечталению, с докером и его аналогами работать удобнее, чем с голым LXC
Temtaime
01.12.2017 12:09Proxmox позволяет на проде делать контейнеры LXC, что получается довольно удобно.
chupasaurus
01.12.2017 20:38Скрипт на баше в 20 строк тоже может создавать полноценные контейнеры, но это не значит, что он будет также хорош, как Docker.
grossws
01.12.2017 20:37Это было года 2-3 назад. Потом появился libcontainer и docker отказался от использования lxc, а использует namespaces и cgroups напрямую.
AllexIn
30.11.2017 22:41Пожалуйста, не надо так.
Как только у вас возникло желание обвинить кого бы то ни было в незрелости — это отличный маячок, что статью писать не надо.
Ваши доводы уже разбили в комментах. Но это не важно. Ваша ошибка — в самом начале статьи и остальное уже неважно.
Пожалуйста, если хотите рассазать о технологиях — рассказывайте о технологиях, а не о том, что «тот кто не использует, тот нуб!»vtvz_ru Автор
30.11.2017 22:56Я думаю, Вы и без моих оправданий прекрасно понимаете, что цели кого-то унизить или обвинить у меня не было. Я сам новичок в этом и мне многое что не известно. Вот, люди указали на Ansible. Я с удовольствием посмотрю, когда будет время.
Мотивы мои чисты и искренни. Мне хотелось поделиться своим небольшим опытом и полученными знаниями.
Мне понравился Docker. Он вызывает сейчас у меня такой же восторг, как в свое время вызвал Git, Vagrant и открытия мира Open Source. В моей ситуации Docker решает много проблем. И я не считаю его серебряной пулей, которая способна решить все проблемы.
Но если найдется хоть один, кому я смог помочь, пусть статья не столь информативна, я буду очень рад.
В любом случае, это мой первый опыт в написании статей. И учитывая, что рейтинг статьи, благо, ещё в плюсе, а 28 человек добавило её в закладки, есть те, кто оценил мою поэзию положительно)
acmnu
01.12.2017 10:04Мне понравился Docker. Он вызывает сейчас у меня такой же восторг, как в свое время вызвал Git,
Проблема в том, что многие здесь не только попробовали Docker, но уже и наелись проблем с ним. Вы только погружаетесь в тему, а для тех кто пользуется им давно подобный заголовок как красная тряпка. Многие на Хабре хорошо осведомлены как устроен Docker и как он работает. И не все от этих знаний в таком же восторге как вы.
noroots
01.12.2017 02:48«Зачем, да и вообще кому нужны всякие Symfony, если есть WordPress?» А что плохого в Wordpress? Как раз использование фреймворков там, где это не надо и есть изврат. В Америке и Европе большинство проектов как раз и строятся на CMS них, а не пишутся на фреймворках. Просто потому, что поддержка для клиента более предсказуема и выгодна в материальном плане. Нужен блог — берут Wordpress, нужен магазин — берут Magento или Woocommerce.
VolCh
01.12.2017 08:53А потом ищут спецов, которые к вордпрессе прикрутят магазин, а к магенте блог. Или обеспечат прозрачную интеграцию вордпресса и магенты.
noroots
01.12.2017 14:37Woocommerce — это и есть магазин для Wordpress. из коробки. Ну и интеграция Magento и Wordpress решается установкой модуля. И найти спецов по CMS гораздо легче и дешевле, чем по фреймворку. Гораздо хуже, когда для Landing Page или 10 страничного сайта разработчик Laravel или Symphony использует.
vtvz_ru Автор
01.12.2017 09:19А я разве сказал, что WordPress — это плохо и его не нужно использовать? Напротив, он здорово справляется со своей задачей. Я говорю про то, что новичкам сложно понять, зачем нужны фреймворки. И в особенности Symfony, у которого уровень абстракции гораздо выше, чем у многих других фреймворков.
Скажу про себя: я действительно не понимал, к чему такая сложность. Сейчас сижу и жалею, что выбрал не его. Гибкий компонентный подход был бы очень кстати. И почувствовал это я, когда начал тестировать. Но раньше я этого не мог понять по причине недостатка опыта.noroots
01.12.2017 14:51Фреймворки для типичных задач — это зло. Всегда легче использовать CMS, чем писать «с нуля». Просто потому, что CMS изначально заточена под решение задач и содержит какие то вещи, которые вы просто можете не учесть и её поддержка для клиента в дальнейшем выйдет дешевле. Это на самом деле какие то реалии российского рынка, когда у каждой студии своя самописная CMS, на которой они строят все сайты, независимо от того подходит она или нет. Для нестандартных задач — бесспорно надо использовать фреймворк, но если присмотреться, в общей массе их не так много.
VolCh
01.12.2017 15:08CMS изначально заточена под одну задачу — управление контентом. Фреймворки заточены, как правило, под две задачи — предоставление типичной инфраструктуры, чтобы не писать её с нуля, и быстрое создание прототипов/MVP. CMS решает одну бизнес-задачу, фреймворк не решает ни одну, это инструмент для создания решений.
alexkbs
01.12.2017 10:38.dev— домен верхнего уровня в собственности у Google. Не стоит им пользоваться.vtvz_ru Автор
01.12.2017 11:50Да сколько можно? Ранее пользовался local, в форуме мне намекнули, что не нужно, потому что это зарезервированный домен. Начал пользоваться dev. Да нет же, его тоже решили занять… Хорошо, что test, как оказалось, тоже зарезервированный, но для разработчиков.
Спасибо больше за ссылку. Добавил пояснение в статью.VolCh
01.12.2017 13:51*.localhost обычно пользуюсь локально.
andreymal
01.12.2017 14:59Тоже не всегда подходит, потому что некоторые хромы принудительно приписывают ему 127.0.0.1, даже если в файле hosts переопределить. Мне как-то раз приспичило вёрстку в хроме под виндой проверить, поставил их в виртуалбокс — а dev.localhost не открывается (причём с IE/Edge в той же виртуалке отлично открывается), пришлось менять конфиги сайта, отвязывая его от домена, и по айпишнику 10.0.2.1 ходить
serg3
01.12.2017 11:42Статья интересная, с точки зрения развития инструментов CI/CD. Другое дело что это все полезно в более менее крупных проектах.
lodas
01.12.2017 11:42В последнем связке Virtualbox+Vagrant+Laravel Homestead каждому сайту легко можно указать версию php(5.6б, 7.0, 7.1), вот так:
sites:
— map: test.app
to: /home/vagrant/Code/test.app
php: «5.6»
demimurych
01.12.2017 12:26Меня помножило на ноль вот этой фразой
Нужно обновить версию MySQL? Сколько времени и усилий пришлось бы приложить, чтобы сделать это на обычном VPS хостинге? Тут это вопрос 3-4 символов.
romy4
01.12.2017 14:22Благодаря тому, что Docker работает внутри рабочей системы, а не создает новую, он не сильно нагружает машину для разработки и вполне пригоден для прода
Вообще-то, он конкретно съедает ресурс памяти. А проброс потоков между контейнерами — вообще отдельный гемор.
gavrilovm
01.12.2017 16:29Время расти дальше и представив себе что сайт вашего блога просматривают столько же людей сколько просматривают habrahabr.ru растирожировать его на несколько серверов.
Представляю себе решение с использованием docker =D.de1m
01.12.2017 16:36Такое решение надо предствалять с помощью kubernetes'a. Там такое делается просто.
VolCh
02.12.2017 17:45host:~docker swarm init host1:~apt install docker-ce && docker swarm join ... host2:~apt install docker-ce && docker swarm join ... ... host<N>:~apt install docker-ce && docker swarm join ... host:~docker service scale blog-app-http=<N*3> host:~docker service scale blog-app-fpm=<N*6>
На каждом из серверов запустится (примерно) по три контейнера с nginx и по шесть с fpm с балансировкой. Про MySQL отдельный вопрос, но это вопрос прежеде всего к Oracle.
lomnev
01.12.2017 23:31Популяризация Docker осуществляется крупными компаниями для обеспечения кадрового резерва программистов, знакомых с этой технологией. Это не плохо.
Однако ясно, что Docker не обеспечит значительных преимуществ для небольшого и среднего бизнеса.
Docker больше подходит для крупных компаний в качестве одной из оптимизаций системы непрерывной интеграции, сокращая за счет большей унификации среды исполнения, потребность контроля за корректностью деплоя, упрощая смену площадки / вендора серверов и софта.
Знание Docker для лиц не работающих в описанных выше компаниях – признак любознательности и стремления быть в корпоративных трендах. Однако практическую пользу оно может сыграть в основном в виде фактора, учитываемого при трудоустройстве в одну из таких компаний.VolCh
02.12.2017 17:55Docker как раз обеспечивает значительные преимущества для небольшого и среднего бизнеса, который не имеют возможности содержать команды девопсов и наборы кластеров для целей разработки и тестирования, для внедрения CI/CD. Если для большого бизнеса докер во многом удобное средство масштабирования, то для малого прежде всего удобное средство доставки фич от разработчика к пользователю.
lomnev
02.12.2017 18:02Согласен. Мир программирования, типы команд и бизнес-процессов в нем очень разнообразны. В результате прохождения отличающихся путей профессионального опыта можно совершенно по разному воспринимать одну технологию.
VolCh
03.12.2017 00:40Дело не в воспринимании, а в способах и целях использования. Кто-то использует контейнеры прежде всего чтобы запускать тысячи инстансов приложения особо не заботясь о процессе запуска, а кто-то чтобы без особых проблем перенести на продакшен то, что работает локальноу разработчика.
lomnev
03.12.2017 02:39Фраза «работает локально у разработчика» намекает, что разработчик либо работает над проектом в одиночку и без админа, либо процесс развертывания приложения при использовании контейнеров выглядит излишне усложненным для небольшой команды в сравнении (например) с Capistrano, забирающим код из репозитория.
Понятно, что при деплое с Capistrano приложение с некоторой вероятностью может «упасть», но тут мы возвращаемся к «запускать тысячи инстансов приложения особо не заботясь о процессе запуска», что неактуально для малого бизнеса.
На примере Rails и малого проекта:
cap staging deploy # погоняли функциональные тесты cap production deploy # production готов, на одном или нескольких серверах
Не нужно практически ничего настраивать на машинах разработчиков. Сервера готовит админ своими ansible-скриптами. Все просто, удобно и интуитивно понятно. Зачем здесь Docker?
Ожидаемый downtime среднего проекта (2-3 сервера) по причине ошибок деплоя новых версий по схеме выше я оценил бы в «один час раз в два года». А затраты на обучение команды, смену тех.процессов, документирование, отработку новых внештатных ситуаций – в десятки и сотни раз дороже.neumeika
03.12.2017 03:33правильно, зачем теги и бранчи, зачем роллбэк, тестовая/стейжевая/продовая среды, уютненько работаете ;)
lomnev
03.12.2017 10:50Бранчи в репозитории. Деплой всегда с master. Роллбэк без проблем:
cap production deploy:rollback ROLLBACK_RELEASE=20171129121359
Тесты локально и на staging, чтобы не держать лишний сервер.
В примере выше как раз две команды — staging и production.
Уютно, надежно, быстро и главное эффективно ;)
Кстати, как с роллбэком у Docker-powered систем? Если не Alpine, то приходится закачивать на сервера гигабайтные контейнеры?andreymal
03.12.2017 13:04Роллбэк без проблем
А кстати, как дела с откатом миграций БД?
lomnev
03.12.2017 13:20Наверное так же сложно, как и в случае с Docker. Ясно, что делать откат миграций автоматически в большинстве случаев не следует.
Откатить работающую под нагрузкой базу – сложная задача для команды из админа, DBA и пары разработчиков.
Именно поэтому:
1. Изменения в схемах базы данных согласовываются с DBA и по возможности строятся так, чтобы обеспечить обратную совместимость.
2. Проводятся тесты: локально на копии БД, а также функциональные тесты staging сервере.
3. Если случайно прошла лишняя миграция вида «создать ненужную таблицу», то ее не откатывают, а удаляют новой миграцией в следующем релизе.
4. Мажорные релизы со значительными изменениями в структуре базы данных, которые на мой взгляд малому бизнесу нужны крайне редко, целесообразно разворачивать по совершенно другой схеме. Возможно, в другом репозитории, с деплоем на другой сервер[а] и постепенным переводом пользователей на него.
Вероятность форс-мажора с базой данных даже при необходимости отката на предыдущий релиз невысока.
А как вы откатываете миграции в случае с Docker?andreymal
03.12.2017 13:23Я докером не пользуюсь, просто из интереса спросил) и вообще свои базы руками обновляю, но не будем о грустном
lomnev
03.12.2017 13:35На своем Pet project'е я тоже использую связку «руки + SequelPro», которая уже годы не подводит при нагрузке 15-20 тысяч пользователей в день. Остальное на мой взгляд было бы уже Overengineering )
Другое дело, когда по работе приходится иметь дело с чужими деньгами в виде проекта, час простоя которого имеет свою цену, иногда сравнимую с зарплатой разработчика за месяц. Тогда схема с одним staging сервером и деплоем Capistrano похоже самое то.
Есть проекты, где время простоя неприлично дорогое. Там Docker вероятно приносит большую пользу.
neumeika
03.12.2017 15:10а не было такого (тьфу-тьфу), есть test с с тестами stage с qa, куда копируется база с прода, делается db:migrate.
В случае факапа в проде только db:migrate:redo, во что я не сильно верю, тут косяк, но мы надеемся, что первые две среды позволят заметить ошибку, наивные мы :)
Добавление пары контейнеров с автодеплоем на пару сред пока себя оправдывает.lomnev
03.12.2017 15:24Технический прогресс это хорошо :)
Средства оркестрации типа Kubernetes в последнее время также неплохо развиваются. Вполне возможно со временем использование контейнеров станет стандартом индустрии и большинство коллективов придут к их использованию.
Насколько я могу оценивать по динамике развития подходов к разработке, экономическая целесообразность массового перехода к контейнеризации проектов для малого бизнеса наступит через 4-5 лет. А до тех пор интересно почитать статьи на хабре, посмотреть на чужой опыт.VolCh
03.12.2017 16:37Во сколько вы оцениваете стоимость перехода малого бизнеса к контейнеризации, как с точчи зрения затрат на разработку, так и с точки затрат на эксплуатацию? Ну вот совсем малый бизнес: один разработчик, который пилит корпоративный сайт с функциями CRM, и один админ который обеспечивает деплой и работу, логи там смотрит, метрики и т. п… Развёрнуто три окружения: локально у разработчика, прод и тестовое, на котором бизнес апрувит деплой на продакшен. Худо бедно настроено даже CI/CD на баш-скриптах. Но время от времени происходят инциденты по типу: разработчик установил что-то себе локально, а админу забыл сообщить. Или ввёл новый параметр конфигурации и тоже забыл сообщить. Или админ как-то ночью залез руками в конфиги сервера, чтобы какой-то параметр изменить, но разработчику не сообщил, и конфигурации стали расходиться.
lomnev
03.12.2017 17:111. В человеко-часах (первый год):
— обучение 20 часов тимлида + по 8 часов на каждого разработчика в команде,
— устранение багов Docker (см. статью habrahabr.ru/post/332450) примерно по 8 часов тимлида и админа в год.
— риски простоя приложения (downtime) примерно 4 часа в год.
2. Рассогласование действий с админом случается. Особенно когда админ удаленный и редко доступен. Для защиты от описанных вами случаев существует staging сервер (он же тестовый, для небольших проектов). Такой сервер должен быть идентичен production. Если приложение упало на staging, то деплой на production не проводится. «Забывать сообщить» недопустимо в бизнес-процессах.de1m
03.12.2017 19:51вы на эту статью сколько ещё ссылаться собираетесь, ей уже больше года, в мире devops'а это уже много.
lomnev
03.12.2017 20:01Открытых issues с тех пор стало больше. Уже 2888.
github.com/moby/moby/issues
Старые баги убавились, появились новые.
Я поддерживаю мнение, что у Docker есть перспективы.
Но нужно позаботиться и о деньгах клиентов.
В сфере давно и успешно работающих веб-проектов малого и среднего бизнеса уравнение
x = плюсы_Docker — (стоимость_рисков * вероятность_рисков) — расходы_на_смену_технологии
пока не выглядит положительно.
VolCh
03.12.2017 21:54Вот по опыту перехода на докер гораздо больше времени экономится на сокращении числа рутинных операций по сихронизации трёх окружений.
- Из-за разности конфигураций и окружений приложение может падать не сразу, а в каких-то редких кейсах, а то и вообще не падать, а просто вести себя по другому, не так как должно. А насчёт "недопустимо" — описанных бизнес-процессов передачи из разработки в эксплуатацию может не быть вовсе, не говоря о контроле за их соблюдением. Докер — не единственное средство автоматизации, снижающее влияние человеского фактора на подобные процессы, но он им является.
VolCh
03.12.2017 16:25Фраза «работает локально у разработчика» намекает...
Фраза намекает на то, что разработчик предпочитает сначала локально проверить код в работе, а лишь потом пушить его в репозиторий, отдавая на растерзание CI/CD, ревьюверам, тестировщикам, приёмщикам и т. д. Ничего более.
либо процесс развертывания приложения при использовании контейнеров выглядит излишне усложненным для небольшой команды в сравнении (например) с Capistrano, забирающим код из репозитория.
Грубо, процесс разворачивания проекта на кластер сводится (есть разные варианты, но для себя выбрал такой) к трём командам:
docker-compose build docker-compose push docker stack deploy
хоть на локальной машине разработчика (docker-compose push не требуется), хоть на CI/CD — сервере, хоть на на продакшене
Не нужно практически ничего настраивать на машинах разработчиков.
давно не работал с рельсами, но навскидку нужно настроить даже для небольшого монолита:
- СУБД
- веб-сервер
- кэш-сервер
- собственно приложение
Это не считая различных компиляторов и транспиллеров для Script, SS и т. п. и єто для простого монолита. А если у нас хотя бы сервис аутентификации вынесен в отдельное приложение, то количество настроек даже не в два раза больше увеличивается.
lomnev
03.12.2017 17:18Как думаете, будет ли ваш способ развертывания так же удобен, если число разработчиков, имеющих право коммита в master и деплоя, увеличится до двух-трех? Я не спорю с этим, хотелось бы узнать ваше мнение.
с рельсами… нужно настроить
Всё правильно. Но среду разработки умеют настраивать на рефлексах большинство специалистов на рынке труда. А Docker больше знаком Devops'ам. Разработчиков придется обучать и ждать пока они пройдутся по всем граблям для набора опыта.VolCh
03.12.2017 23:24Он станет ещё более удобен при росте команды. Конечно, при условии, что эти два-три человека понимают что делают, что без докера их бы допустили до написания скриптов деплоя на продакшен.
Но среду разработки умеют настраивать на рефлексах большинство специалистов на рынке труда.
Развернуть один монолитный проект на одной машине с рутовым доступом — да, каждый, практически может за часок-другой, а то и быстрее. А вот когда проект усложняется, да одновременно надо развернуть несколько, причём все на стандартных портах, да с разными версиями — уже дни могут тратиться.
berezuev
Докер… Зрелось… А сами зачем-то PHPMyAdmin в 2017-м юзаете.
vtvz_ru Автор
Прежде, чем я что-то буду говорить, можно, пожалуйста, аргументы? Что Вы имеете против PMA и какие есть альтернативы помимо консоли или аналогичных инструментов аля Adminer?
chelovekkakvse
Ну например официальное приложение MySQL Workbench :)
sumanai
Не могу не порекомендовать HeidiSQL.
П.С. Зря поленился обновить комментарии.
vtvz_ru Автор
Использую Ubuntu. Желания корячится с Wine нет
chelovekkakvse
Друг, оно (workbench) есть для Linux…
Выбрать и скачать тут. По личному опыту скажу — пма лишняя нагрузка на сервер и трата времени на настройку.
vtvz_ru Автор
Я использовал workbench какое-то время. Но мне он не нравится. Раньше частенько вылетал посреди работы.
Вариант с "PHPStorm с встроенным в него DataGrip" мне нравится больше. И мне этого пока что достаточно.
Про Wine я имел в виду, чтобы использовать HeidiSQL. По крайней мере готовый DEB пакет я не нашел.
chelovekkakvse
Странно. У нас есть БД с 2 млн. записей и воркбенч нормально их переваривает. 2 млн это конечно не хайлоад, но все же.
vtvz_ru Автор
У нас даже таких объемов нет. Таблицы в среднем по 1000 строк. Помимо прочего, у меня 14.04 версия убунты. Новая версия (6.3.10) может не запуститься (пробовал как-то), а вот как раз старая (6.2.5), которые предназначены для моей версии, запускается. Но она не стабильна и в специфичных местах вылетает
NiPh
Вот кстати воркбенч при работе с Марией часто проявлял нестабильность(пол года назад примерно с него ушёл), но он поддержку Марии и не обещает. Сейчас сижу на смеси хейди и дбивера. Очень странно конечно что такого интуитивно правильного функционала как подстановка дропдауна со значениями если поле — внешний ключ, при редактировании таблиц, кроме хейди никто и не предлагает.
По крайней мере я больше ни у кого это не встретил, допускаю что плохо искал.
nikitasius
PMA — это никакой траты времени на настройку. Зайти, запустить конфиг и… все.
В плане сервера — профиль php-fpm и mknod 3 раза, чтобы в chroot сие работало.
Вот и все. Объяснять клиенту, как прокинуть порт на сервер по ssh (+прописывать правила в iptables чтобы они не могли прокидывать другие порта) — оно никому не нужно.
nikitasius
Сам юзаю heidi, в том числе и через wine. Только она багованная до ужаса (и под вин и "под линукс"). Но нормальных и бесплатных альтернатив нет.
На счет phpmyadmin — вполне себе нормальный продукт, когда надо сделать кому-то доступ к базе через веб.
VolCh
Или простая админа для системы :)
berezuev
Как минимум то, что у вас на каждый проект разворачивается по PMA. А если вам нужен доступ к базе на продакшн? Вы там тоже будете разворачивать PHPMyAdmin?
Heidisql
PHPStorm с встроенным в него DataGrip
Workbench, прости, господи.
В любом из этих инструментов вы подключаетесь к сторонней базе. Соответственно, если подключение к БД возможно только с локальной машины (а это в 99% случаев будет так), пользуйтесь ssh-туннелями, благо это сейчас умеет любой современный бд-клиент.
vtvz_ru Автор
Это… Как сказать, не совсем прям аргумент против самого PMA, как к способу его подключения.
Windown only. Как написал выше "Использую Ubuntu. Желания корячится с Wine нет"
Не стабилен. Постоянно вылетает. Почему-то. В любом случае, мне он не нравится
Его и использую преимущественно.
Но аргументов против PMA я так и не увидел. С чем я могу согласиться, что еще один торчащий наружу сторонний проект, который я не могу контролировать, который использует ROOT доступ к базе — это лишняя угроза.
berezuev
Вы в последнем предложении разнесли в пух и прах PMA. Если для вас безопасность приложения не является аргументом, я с вами спорить не буду.
vtvz_ru Автор
Но это мой аргумент) И это причина по которой я не исползую PMA в продакшене. Мне было интересно узнать, что скажут мне на это люди. В итоге, единственный адекватный аргумент против использования PMA был, что это "лишняя нагрузка на сервер". Остальные были в духе "он морально устарел используй XXX"
vanxant
Совершенно необязательно давать туда рут
nikitasius
А играть в "назови мне логин и пароль" не пробовали? PMA в это умеет.
KirEv
navicat лет десять как использую… еще frontmysql лет 5 назад пользовался.
nikitasius
navicat платная.
AlexanderY
DBeaver для ubuntu отлично работает. В одном флаконе доступ к mysql, postgres, каким-то nosql решениям (не помню к каким). Рекомендую. PMA подходит для проектов, которые вы в конце статьи описали как «очень простые».