Comments 141
Прежде, чем я что-то буду говорить, можно, пожалуйста, аргументы? Что Вы имеете против PMA и какие есть альтернативы помимо консоли или аналогичных инструментов аля Adminer?
Использую Ubuntu. Желания корячится с Wine нет
Выбрать и скачать тут. По личному опыту скажу — пма лишняя нагрузка на сервер и трата времени на настройку.
Я использовал workbench какое-то время. Но мне он не нравится. Раньше частенько вылетал посреди работы.
Вариант с "PHPStorm с встроенным в него DataGrip" мне нравится больше. И мне этого пока что достаточно.
Про Wine я имел в виду, чтобы использовать HeidiSQL. По крайней мере готовый DEB пакет я не нашел.
У нас даже таких объемов нет. Таблицы в среднем по 1000 строк. Помимо прочего, у меня 14.04 версия убунты. Новая версия (6.3.10) может не запуститься (пробовал как-то), а вот как раз старая (6.2.5), которые предназначены для моей версии, запускается. Но она не стабильна и в специфичных местах вылетает
По крайней мере я больше ни у кого это не встретил, допускаю что плохо искал.
PMA — это никакой траты времени на настройку. Зайти, запустить конфиг и… все.
В плане сервера — профиль php-fpm и mknod 3 раза, чтобы в chroot сие работало.
Вот и все. Объяснять клиенту, как прокинуть порт на сервер по ssh (+прописывать правила в iptables чтобы они не могли прокидывать другие порта) — оно никому не нужно.
Сам юзаю heidi, в том числе и через wine. Только она багованная до ужаса (и под вин и "под линукс"). Но нормальных и бесплатных альтернатив нет.
На счет phpmyadmin — вполне себе нормальный продукт, когда надо сделать кому-то доступ к базе через веб.
Под убунтой приходится пользоваться Datagrip, под Macos — Sequel Pro. В нем всего один фильтр можно использовать в таблице, форматирования нет вообще при просмотре кода. В отличии от Datagrip видит хранимые процедуры.
В PMA можно случайно не туда ткнуть во время загрузки и грохнуть таблицу, даже спрашивать не будет.
Что Вы имеете против PMA?
Как минимум то, что у вас на каждый проект разворачивается по PMA. А если вам нужен доступ к базе на продакшн? Вы там тоже будете разворачивать PHPMyAdmin?
какие есть альтернативы
Heidisql
PHPStorm с встроенным в него DataGrip
Workbench, прости, господи.
В любом из этих инструментов вы подключаетесь к сторонней базе. Соответственно, если подключение к БД возможно только с локальной машины (а это в 99% случаев будет так), пользуйтесь ssh-туннелями, благо это сейчас умеет любой современный бд-клиент.
Как минимум то, что у вас на каждый проект разворачивается по PMA.
Это… Как сказать, не совсем прям аргумент против самого PMA, как к способу его подключения.
Heidisql
Windown only. Как написал выше "Использую Ubuntu. Желания корячится с Wine нет"
Workbench
Не стабилен. Постоянно вылетает. Почему-то. В любом случае, мне он не нравится
PHPStorm с встроенным в него DataGrip
Его и использую преимущественно.
Но аргументов против PMA я так и не увидел. С чем я могу согласиться, что еще один торчащий наружу сторонний проект, который я не могу контролировать, который использует ROOT доступ к базе — это лишняя угроза.
Но это мой аргумент) И это причина по которой я не исползую PMA в продакшене. Мне было интересно узнать, что скажут мне на это люди. В итоге, единственный адекватный аргумент против использования PMA был, что это "лишняя нагрузка на сервер". Остальные были в духе "он морально устарел используй XXX"
Как минимум то, что у вас на каждый проект разворачивается по PMA.
А играть в "назови мне логин и пароль" не пробовали? PMA в это умеет.
Это не похоже на конструктивную критику. В чем проблема базы в докере? Окей, может быть для нагруженных проектов имеет смысл вынести базу в хост машину или даже на отдельный сервер. Но overhead от использования в докере не такой большой, чтобы как-то сильно запариваться. Производительность в худшем случае будет 91%, а в лучшем 96% от использования базы на хост машине. С другой стороны, благодаря тому, что именованных томов (volumes) хранятся в одном месте, проще настроить backup один раз, и забыть. Или я чего-то не знаю? Буду благодарен, если просветите.
На тестом сервере или при локальном разработке база в докере это замечательно и удобно.
Но не в проде. Тут рассказывают почему. Пункт «Запрещено использовать в DBA.»
Стоит учитывать, что это перевод довольно истеричной статьи 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. Но в некоторых условиях запускать базы в контейнерах вполне можно.
overlay
вёл себя нестабильно на redhat'овском 2.6.32 некоторое время назад, особенно поверх xfs
. Более нестабильно, чем btrfs, с kernel oops'ами в недрах xfs
. Сейчас у меня на проде на centos7 overlay
поверх ext4
.
UPD: засомневался, что у меня на 2.6.32 был overlay
, но сейчас уже не проверю, того сервера уже нет. Возможно, это было на ранних ядрах 7 centos'а.
dm
у меня вполне себе жил (на железном lvm, не на loop, как оно по умолчанию) без особых проблем в сравнении с overlay
поверх xfs
. При количестве контейнеров ~30-50.
Отвечу сразу shurshur, у меня с dm
таких проблем не было поверх lvm на железе, но как выше писал, в основном у меня живёт overlay
поверх ext4
.
отдельно монтируется директория с данными, на реальной файловой системе.
имеет место быть.
Есть какое-то решение как при монтировании volume сменить владельца файлов и потом обратно?
Какого рода вам нужен доступ к базе? Возможность запустить бд еще и с хостовой системы или просто доступ по psql?
Второе и так работает, для получения первого нужно шаманить с uid.
Стандартный образ postgres для docker делает chown для файлов базы перед запуском, если с правами что-то не так.
С того момента, правда, вышла уже третья версия схемы compose. Возможно, там это решено — нужно посмотреть.
Плюс было не очень понятно, как из docker-compose.yml универсально прокидывать юзера не хардкодя его UID
А зачем? Особенно учитывая, что сам docker вполне может быть на удалённой машине.
Проблемы с доступов для кого? Для postgres или для вас? Тут уж надо выбрать что-то одно. Единственное что могу сказать, что postgres и вне докера дает доступ к своим файлам только себе и рут-пользователю.
У меня UID — 1000, допустим. У postgres внутри контейнера он другой. В итоге файлы создаются на диске с UID из контейнера и я со своим UID=1000 не могу получить к ним доступ в хостовой системе.
Насколько мне известно, есть два подхода решения этой проблемы:
— (популярный) пробросить UID в контейнер чтобы пользователь, под которым бегает демон (например, postgres) создался с этим UID
— (странный, костыльный, не особо гибкий) маппер UID для Docker, который работает на уровне демона и содержит карту UID внутри контейнеров и UID на хостовой системе которым они соответстуют и, соответственно, разруливает это.
Моя проблема, если мне не изменяет память, была в том, что я хотел настроить поднятие стека в Docker, но из Docker Compose не мог пробросить в контейнер UID пользователя, с которым нужно создавать пользователя внутри контейнера.
for Dockerfile:
#Hate docker volumes
&& usermod -u 10001 «posgresuser» && groupmod -g 10001 «posgresuser» && chown -R «datadir»
но лучше воздержаться от БД в докере
Данные на внешней системе лежат, том пробрасывается в докер.
У меня сейчас на ноуте крутится гроздь контейнеров, и среди них 4 — базы данных(mariaDB, Redis, ClickHouse, Couchbase). Данные хранятся в папке приложения и линкуются внутрь контейнеров, поэтому при перезапуске или пересборке контейнеров я не теряю данные. На производительность тоже не жалуюсь — для разработки вполне хватает, всё очень шустро бегает) А на проде весь этот зоопарк разбит по нескольким серверам с репликацией, и этим рулит админ.
-
Для этого нужно подрасти. У меня не было надежного руководства, поэтому все приходилось постигать самому. Возможно кто-то как я благодаря этой статье сможет вырасти немного быстрее.
Это действительно проблема, материалов по Docker в русскоязычном сегменте мало, приходится много времени проводить за мануалами на не родном языке. Но ваша статья не решает эту проблему, очередная вода с неполным листингом docker-compose
P.S. Пользуясь случаем прошу подсказать возможные способы деплоя docker проекта на 1 сервер (без оверинжиниринга вроде kubernetes).
- Я в начале статьи написал, что это рассказ о моем опыте. Обещания дать много инфы я не давал. Это статья о понимании Docker'а, как инструмента, а не инструкция по его использованию. Более содержательные статьи об использовании Docker будут в будущем. Есть идеи, которые в интернете как-то совсем не раскрыты.
- Это не листинг docker-compose, а строки, которые нужно добавить, чтобы подключить БД или PMA. Как мне кажется, фраза "Подключение к проекту новых компонентов стало вопросом нескольких строк" на это мягко намекает. Специально разделил эти два куска, чтобы (возможно) было яснее. Писать полный конфиг compose в этой статье я не вижу смысла.
На самом деле… Простых инструментов деплоя я не знаю. В Bitbucket есть pipelines. Можно сделать примерно так:
- Упаковать нужные файлы в архив вместе с docker-compose файлом
- Отправить файл на сервер по ssh
- Распаковать его
- Запустить build и up
- Убраться за собой (удалить архив, остаточные файлы и т.п.)
Не самый идеальный способ, но как-то работает. Для малых и средних проектов, я думаю, подойдет.
1. готовишь релиз application с тестами и т.п.
2. собираешь ducker image
3. пушишь в свой hub
4. создаешь web-хук на хабе, который даст сигнал серверу, на котором хук расположен, стянуть обновленный билд нужного docker image
5. запустить тесты и все остальное что проверяет работоспособность полученного image
в двух словах примерно так и сделали, не доросла наша компания до использования готовых инструментов CI/CD, которых, к слову, не счесть… а понять что подходит лучше — по немногу в каждом надобно разбираться.
Виртуализация здорово подходит для разработки. Но в продакшн оно не годится.
Странное заявление. Вы понимаете, как работают дата центры? В которых, в общем-то, может использоваться тот же Docker, которой является системой виртуализации :) Без виртуализации понятие «масштабирование» означало бы процесс физического наращивания мощности сервера. Т.е. по клику у хостера «добавить контейнер» происходила бы закупка оборудования, чувак бы нес все эти железки, устанавливал в ферму и т.д. И процесс бы занимал недели.
Vagrant — проще говоря, это инструмент, который дает Вам возможность настраивать VirtualBox скриптом.
В общем-то тоже самое делает и докер. Только вряд ли он для этого предназначен.
П.С.
1. Странное занятие — использовать Docker для разработки. Нет, я не отрицаю, что, например, если у вас в компании трудится 100 человек и вы разрабатываете на сервере, то быстро развернуть проект для нового сотрудника или для форка можно и докером, только зачем? Вы же сами написали про вагрант. Туда можно засунуть те же параметры деплоя, закинуть все в архив вместе с файлами проекта и кому-то отдать. Можно это все запрограммировать на уровне скриптов. Резюмируя — не о том здесь описан Docker, не о том :)
2. Если уже говорить о нормальном деплое и Continous Integration (CI), то уместнее было упомянуть стек: контроль версий (GIT, SVN, TFS), сервер CI (Teamcity, Jenkins).
3. Что я вынес из этой статьи
Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы.… Изначально использовал возможности LXC, с 2015 года применял собственную библиотеку, абстрагирующую виртуализационные возможности ядра Linux — libcontainer.
(с) Wiki
Виртуализация на уровне операционной системы позволяет запускать изолированные и безопасные виртуальные машины на одном физическом узле, но не позволяет запускать операционные системы с ядрами, отличными от типа ядра базовой операционной системы. При виртуализации на уровне операционной системы не существует отдельного слоя гипервизора. Вместо этого сама хостовая операционная система отвечает за разделение аппаратных ресурсов между несколькими виртуальными машинами и поддержку их независимости друг от друга. Среди реализаций:
- Solaris Containers/Zones
- FreeBSD Jail
- Linux-VServer[en]
- LXC (Linux Containers)
- FreeVPS[en]
- OpenVZ
- Virtuozzo
- iCore Virtual Accounts
Зачем использовать докер для локальной разработки? В чем его преимущество перед той же VB, которая умеет делать снимок виртуалки, который можно установить на любой комп? Или тот же вагрант? Мне все же кажется, что докер немного не про это.
Навскидку, по личному опыту, виртуальные машины слишком сильно изолированы от хоста и друг друга для эффективного разворачивания сложной системы локально. Зачастую резервируют излишние ресурсы, оставляя их мало для собственно разработки. При этом на продакшене практически не используются, то есть надо поддерживать минимум два слабо связанных окружения. Практика показывает, что если на продакшене используется докер, то на вагранты часто забивают, накапливается разница в окружениях.
Не совсем понял про слабо связанное окружение. Разве нельзя настроить одну среду на докере и вагранте? Я согласен, что здесь имеет место быть человеческий фактор, но в таком случае нужно говорить о CI, а не о докере\вагранте. В моем понимании докер востребован только тогда, когда у тебя облако\удаленный сервер и\или хайлоад. Причем я бы рассматривал его только в случае масштабирования, т.к., на мой взгляд, разработка должна вестись на локальной машине, уходить в систему контроля версий, а от туда разворачивать проект через систему непрерывной интеграции. Хотя допускаю, что разрабатывать можно на докере, форкаться и тд, потом через контроль версий заливать готовый проект в контейнер докера, там пробегать все тесты и через CI заливать контейнер с проектом. Но… если нужно обновить 1 файл в проекте, смысл все пересобирать? В общем, в данном вопросе у меня нет однозначного ответа. Могу лишь утверждать, что для себя я определил докер, как систему быстрого развертывания идентичной среды для нагруженного проекта.
Так они идентичные, единственное отличие сред (продакшен, CI, стейджинг, лоакльная) в параметрах типа DNS имён ендпоинтов и количества воркеров. Грубо, все отличия сред только в environment переменных, читаемых из какого-нибудь .env файла, который в репозиторий не вносится. Плюс для локальной можно примонтировать каталоги с локальными кодами, чтобы не билдить/рестартовать контейнер на каждый чих, только на какие-то глобальные изменения.
Скорее всего, на проде это будет минимум два отдельных сервера, а то и больше. А на ВБ, скорее всего, одна виртуалка. Процедуры обновления скорее всего будут разные — на проде автоматизированная, а на виртуалке часто ставят что-то ручками, забывая занести в вагрантфайл.
Возможно, я попутал термины. Подумаю, что можно сделать, чтобы не переписывать всю статью.
Основное преимущество Docker перед VB в первую очередь в том, что он не ест столько оперативки и не требует целой кучи ресурсов.
У меня всего 8гб, на плечи которых лежит PHPstorm со всеми плюшками, Chrome с десятком плагинов, Webpack с запущенным на нем Hot reload и ещё несколько инструментов. Чтобы запустить и держать в рабочем состоянии VB рядом со всем этим добром, нужно ресурсов гораздо больше. В итоге, ОЗУ заканчивалась, процессы лезли в swap и насиловали мой HDD, после чего разработка становится невыносимой и приходилось от чего-то отказываться.
VB запускает всю систему целиком со всеми ее процессами, которых не так уж и мало. В свою очередь Docker запускает только то, что мне нужно.
Docker запускается намного быстрее. Подключать дополнительные компоненты удобно. Тестировать хорошо, так как можно быстро поднять новый, чистый контейнер. Selenium работает из коробки без всяких танцев с бубном.
Для себя я нашел много преимуществ. Если их не находите Вы, это может говорить об одном — Вам он (Docker) просто не нужен.
Мне докер нужен, но для предназначения, которое написано на официальном сайте проекта :) Для разработки есть масса удобных и более удобных инструментов. Тот же пхпшторм. У него из коробки идет плагин для вагранта.
На вкус и цвет конечно. Мой вопрос лишь в том, что не стрельба ли это по воробьям из танка?
Это разве не в вагрант файле хранится?
и переопределить локально затруднительно.
Обычно, вагрант файл лежит в репозитории проекта или где-то рядом, с параметрами подходящими его автору, у которого, например, 32Гб оперативы и 4 физических ядра плюс HT. Вот и даст одно физическое ядро и 4 Гб, чтобы избегать малейших тормозов. А у тебя 8Гб оперативы и 2 физических ядра. Эта виртуалочка скушает половину ресурсов. А пулл реквест на изменение автор не примет. Придётся изменить и как-то следить чтобы в репу не закоммитить эти изменения, а изменения из апстрима прилетали.
Т.е. не каждый VPS поддерживает докер. В итоге получаем неработающую «серебряную пулю».
Не утверждаю, что здесь что-то плохое, но позволю себе чутка возразить на некоторые части поста
Это [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
Я считаю, что пытаться фиксировать окружение вместо того, чтобы писать приложение так, чтобы оно работало как можно более везде без искусственных ограничений вроде того же докера — лень и безответственность. Если, конечно, дедлайн не вчера)
Кстати, докеры и прочие виртуалки ещё и место занимают на образы базовых ОС, минималистичный Alpine в качестве базы юзают далеко не все, а на моём VPS сейчас свободно всего четыре гига, так что докер я не могу себе позволить даже если бы хотел)
А вот на битбакет теоретически может прийти крымнаш, вам прикроют ваш репозиторий из-за санкций россиянам (это я ещё роскомнадзор не вспоминаю), и вы побежите доставать репозиторий из бэкапов прошлогодней давности стаить 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
, если его хватает.
4 версии MongoDB
Ну nosql-хипсторы уже ССЗБ) Мои проекты успешно работают на всём разнообразии версий MySQL и MariaDB за последние пять лет (а скорее всего и больше, но я просто не пробовал). Хотя про постгрес мне ответить нечего, окей
Вы это на нормальном проде без предварительного тестирования делаете?
Зачем же, есть staging-сервер, идентичный проду. Хотя вообще да, лично у меня просто условный личный бложик, и мне обновляться без подготовки на проде в общем-то не страшно) Но для страшных действий staging всё равно есть
C++11
Ой, тут я не компетентен. У меня в питонах подобной ереси нет)
Ну nosql-хипсторы уже ССЗБ) Мои проекты успешно работают на всём разнообразии версий MySQL и MariaDB за последние пять лет (а скорее всего и больше, но я просто не пробовал). Хотя про постгрес мне ответить нечего, окей
Ну nosql-хипсторы уже ССЗБ) Мои проекты успешно работают на всём разнообразии версий MySQL и MariaDB за последние пять лет (а скорее всего и больше, но я просто не пробовал). Хотя про постгрес мне ответить нечего, окей
Ну тогда и не стоит использовать ad hominem. MongoDB и Apache Cassandra в определённых областях очень удобны и заменить их на MySQL/MariaDB невозможно.
Ой, тут я не компетентен. У меня в питонах подобной ереси нет)
Вероятно, вам просто везёт, что не используются бинарные расширения, написанные на C++11 и выше. В питонячем мире на это нарваться сложнее, но тоже бывает.
Ну и Git для кода, разумеется. (С сервером в отдельном контейнере и резервными копиями каждый час на отдельный диск)
Сильно зависит от задач, да. Для некоторых вещей оверхед от использования докера будет больше, чем польза от оного. Для деплоя в проде это может быть способом избавиться от большого количества головной боли, но потребует вложения определенного количества сил и средств в соответствующую систему оркестрации (будь то банальный docker swarm, или более тяжелые kubernetes с openshift'ом).
Жду тогда от Вас статью "Docker, как показатель подросткового возраста")
Поясните, пожалуйста, подробнее. Нутром чувствую, что с вашим комментом согласен, но надо убедиться)
Короче Docker только новые проблемы пораждает.
Я реально слабо представляю нафига он в том же ASP.NET или Go нужен.
И полезен он прежде всего для компилируемых языков. Это в скриптовых можно залезть и поправить, например, порт, который будет слушать процесс в простом текстовом редакторе, а в компилируемых так не выйдет.
А для изоляции есть LXC.
Это было года 2-3 назад. Потом появился libcontainer и docker отказался от использования lxc, а использует namespaces и cgroups напрямую.
Как только у вас возникло желание обвинить кого бы то ни было в незрелости — это отличный маячок, что статью писать не надо.
Ваши доводы уже разбили в комментах. Но это не важно. Ваша ошибка — в самом начале статьи и остальное уже неважно.
Пожалуйста, если хотите рассазать о технологиях — рассказывайте о технологиях, а не о том, что «тот кто не использует, тот нуб!»
Я думаю, Вы и без моих оправданий прекрасно понимаете, что цели кого-то унизить или обвинить у меня не было. Я сам новичок в этом и мне многое что не известно. Вот, люди указали на Ansible. Я с удовольствием посмотрю, когда будет время.
Мотивы мои чисты и искренни. Мне хотелось поделиться своим небольшим опытом и полученными знаниями.
Мне понравился Docker. Он вызывает сейчас у меня такой же восторг, как в свое время вызвал Git, Vagrant и открытия мира Open Source. В моей ситуации Docker решает много проблем. И я не считаю его серебряной пулей, которая способна решить все проблемы.
Но если найдется хоть один, кому я смог помочь, пусть статья не столь информативна, я буду очень рад.
В любом случае, это мой первый опыт в написании статей. И учитывая, что рейтинг статьи, благо, ещё в плюсе, а 28 человек добавило её в закладки, есть те, кто оценил мою поэзию положительно)
Мне понравился Docker. Он вызывает сейчас у меня такой же восторг, как в свое время вызвал Git,
Проблема в том, что многие здесь не только попробовали Docker, но уже и наелись проблем с ним. Вы только погружаетесь в тему, а для тех кто пользуется им давно подобный заголовок как красная тряпка. Многие на Хабре хорошо осведомлены как устроен Docker и как он работает. И не все от этих знаний в таком же восторге как вы.
А я разве сказал, что WordPress — это плохо и его не нужно использовать? Напротив, он здорово справляется со своей задачей. Я говорю про то, что новичкам сложно понять, зачем нужны фреймворки. И в особенности Symfony, у которого уровень абстракции гораздо выше, чем у многих других фреймворков.
Скажу про себя: я действительно не понимал, к чему такая сложность. Сейчас сижу и жалею, что выбрал не его. Гибкий компонентный подход был бы очень кстати. И почувствовал это я, когда начал тестировать. Но раньше я этого не мог понять по причине недостатка опыта.
CMS изначально заточена под одну задачу — управление контентом. Фреймворки заточены, как правило, под две задачи — предоставление типичной инфраструктуры, чтобы не писать её с нуля, и быстрое создание прототипов/MVP. CMS решает одну бизнес-задачу, фреймворк не решает ни одну, это инструмент для создания решений.
.dev
— домен верхнего уровня в собственности у Google. Не стоит им пользоваться.
Да сколько можно? Ранее пользовался local, в форуме мне намекнули, что не нужно, потому что это зарезервированный домен. Начал пользоваться dev. Да нет же, его тоже решили занять… Хорошо, что test, как оказалось, тоже зарезервированный, но для разработчиков.
Спасибо больше за ссылку. Добавил пояснение в статью.
*.localhost обычно пользуюсь локально.
sites:
— map: test.app
to: /home/vagrant/Code/test.app
php: «5.6»
Нужно обновить версию MySQL? Сколько времени и усилий пришлось бы приложить, чтобы сделать это на обычном VPS хостинге? Тут это вопрос 3-4 символов.
Благодаря тому, что Docker работает внутри рабочей системы, а не создает новую, он не сильно нагружает машину для разработки и вполне пригоден для прода
Вообще-то, он конкретно съедает ресурс памяти. А проброс потоков между контейнерами — вообще отдельный гемор.
Представляю себе решение с использованием docker =D.
host:~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.
Docker как раз обеспечивает значительные преимущества для небольшого и среднего бизнеса, который не имеют возможности содержать команды девопсов и наборы кластеров для целей разработки и тестирования, для внедрения CI/CD. Если для большого бизнеса докер во многом удобное средство масштабирования, то для малого прежде всего удобное средство доставки фич от разработчика к пользователю.
Дело не в воспринимании, а в способах и целях использования. Кто-то использует контейнеры прежде всего чтобы запускать тысячи инстансов приложения особо не заботясь о процессе запуска, а кто-то чтобы без особых проблем перенести на продакшен то, что работает локальноу разработчика.
Роллбэк без проблем
А кстати, как дела с откатом миграций БД?
В случае факапа в проде только db:migrate:redo, во что я не сильно верю, тут косяк, но мы надеемся, что первые две среды позволят заметить ошибку, наивные мы :)
Добавление пары контейнеров с автодеплоем на пару сред пока себя оправдывает.
Во сколько вы оцениваете стоимость перехода малого бизнеса к контейнеризации, как с точчи зрения затрат на разработку, так и с точки затрат на эксплуатацию? Ну вот совсем малый бизнес: один разработчик, который пилит корпоративный сайт с функциями CRM, и один админ который обеспечивает деплой и работу, логи там смотрит, метрики и т. п… Развёрнуто три окружения: локально у разработчика, прод и тестовое, на котором бизнес апрувит деплой на продакшен. Худо бедно настроено даже CI/CD на баш-скриптах. Но время от времени происходят инциденты по типу: разработчик установил что-то себе локально, а админу забыл сообщить. Или ввёл новый параметр конфигурации и тоже забыл сообщить. Или админ как-то ночью залез руками в конфиги сервера, чтобы какой-то параметр изменить, но разработчику не сообщил, и конфигурации стали расходиться.
Вот по опыту перехода на докер гораздо больше времени экономится на сокращении числа рутинных операций по сихронизации трёх окружений.
- Из-за разности конфигураций и окружений приложение может падать не сразу, а в каких-то редких кейсах, а то и вообще не падать, а просто вести себя по другому, не так как должно. А насчёт "недопустимо" — описанных бизнес-процессов передачи из разработки в эксплуатацию может не быть вовсе, не говоря о контроле за их соблюдением. Докер — не единственное средство автоматизации, снижающее влияние человеского фактора на подобные процессы, но он им является.
Фраза «работает локально у разработчика» намекает...
Фраза намекает на то, что разработчик предпочитает сначала локально проверить код в работе, а лишь потом пушить его в репозиторий, отдавая на растерзание CI/CD, ревьюверам, тестировщикам, приёмщикам и т. д. Ничего более.
либо процесс развертывания приложения при использовании контейнеров выглядит излишне усложненным для небольшой команды в сравнении (например) с Capistrano, забирающим код из репозитория.
Грубо, процесс разворачивания проекта на кластер сводится (есть разные варианты, но для себя выбрал такой) к трём командам:
docker-compose build
docker-compose push
docker stack deploy
хоть на локальной машине разработчика (docker-compose push не требуется), хоть на CI/CD — сервере, хоть на на продакшене
Не нужно практически ничего настраивать на машинах разработчиков.
давно не работал с рельсами, но навскидку нужно настроить даже для небольшого монолита:
- СУБД
- веб-сервер
- кэш-сервер
- собственно приложение
Это не считая различных компиляторов и транспиллеров для Script, SS и т. п. и єто для простого монолита. А если у нас хотя бы сервис аутентификации вынесен в отдельное приложение, то количество настроек даже не в два раза больше увеличивается.
Он станет ещё более удобен при росте команды. Конечно, при условии, что эти два-три человека понимают что делают, что без докера их бы допустили до написания скриптов деплоя на продакшен.
Но среду разработки умеют настраивать на рефлексах большинство специалистов на рынке труда.
Развернуть один монолитный проект на одной машине с рутовым доступом — да, каждый, практически может за часок-другой, а то и быстрее. А вот когда проект усложняется, да одновременно надо развернуть несколько, причём все на стандартных портах, да с разными версиями — уже дни могут тратиться.
Docker, как показатель зрелости