Pull to refresh

Comments 141

Докер… Зрелось… А сами зачем-то PHPMyAdmin в 2017-м юзаете.

Прежде, чем я что-то буду говорить, можно, пожалуйста, аргументы? Что Вы имеете против PMA и какие есть альтернативы помимо консоли или аналогичных инструментов аля Adminer?

Ну например официальное приложение MySQL Workbench :)
UFO just landed and posted this here

Использую Ubuntu. Желания корячится с Wine нет

Я использовал workbench какое-то время. Но мне он не нравится. Раньше частенько вылетал посреди работы.
Вариант с "PHPStorm с встроенным в него DataGrip" мне нравится больше. И мне этого пока что достаточно.
Про Wine я имел в виду, чтобы использовать HeidiSQL. По крайней мере готовый DEB пакет я не нашел.

Странно. У нас есть БД с 2 млн. записей и воркбенч нормально их переваривает. 2 млн это конечно не хайлоад, но все же.

У нас даже таких объемов нет. Таблицы в среднем по 1000 строк. Помимо прочего, у меня 14.04 версия убунты. Новая версия (6.3.10) может не запуститься (пробовал как-то), а вот как раз старая (6.2.5), которые предназначены для моей версии, запускается. Но она не стабильна и в специфичных местах вылетает

Вот кстати воркбенч при работе с Марией часто проявлял нестабильность(пол года назад примерно с него ушёл), но он поддержку Марии и не обещает. Сейчас сижу на смеси хейди и дбивера. Очень странно конечно что такого интуитивно правильного функционала как подстановка дропдауна со значениями если поле — внешний ключ, при редактировании таблиц, кроме хейди никто и не предлагает.
По крайней мере я больше ни у кого это не встретил, допускаю что плохо искал.

PMA — это никакой траты времени на настройку. Зайти, запустить конфиг и… все.
В плане сервера — профиль php-fpm и mknod 3 раза, чтобы в chroot сие работало.
Вот и все. Объяснять клиенту, как прокинуть порт на сервер по ssh (+прописывать правила в iptables чтобы они не могли прокидывать другие порта) — оно никому не нужно.

Сам юзаю heidi, в том числе и через wine. Только она багованная до ужаса (и под вин и "под линукс"). Но нормальных и бесплатных альтернатив нет.


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

Или простая админа для системы :)

Считаю, что стоит также сюда добавить dbforge. Пользуюсь дома Ubuntu и Macos на работе, но ничего более функционального для MySQL не нашел. Позволяет удобно работать с Views и хранимыми процедурами, посмотреть другую таблицу по ключу и выбрать значение прямо на месте, редактор с нормальным форматированием, удобно анализировать производительность запросов. Для специфических задач держу зафризенный Virtualbox с Windows и данным приложением наготове.
Под убунтой приходится пользоваться 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 в продакшене. Мне было интересно узнать, что скажут мне на это люди. В итоге, единственный адекватный аргумент против использования PMA был, что это "лишняя нагрузка на сервер". Остальные были в духе "он морально устарел используй XXX"

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

А играть в "назови мне логин и пароль" не пробовали? PMA в это умеет.

navicat лет десять как использую… еще frontmysql лет 5 назад пользовался.
DBeaver для ubuntu отлично работает. В одном флаконе доступ к mysql, postgres, каким-то nosql решениям (не помню к каким). Рекомендую. 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. Но в некоторых условиях запускать базы в контейнерах вполне можно.

devicemapper, серьёзно? Контейнеров хотя бы 40 на хост, ci/cd jenkins/teamcity/bamboo для деплоя в паралельку (ну хотя бы штуки по 3 одновременно) с docker api, и вот тут начинается веселье с локами, а ещё можно ждать docker rm -f в несколько минут. Удачи в проектах покрупнее. А вот оверлей и его братик с индексом 2 очень хороши, желательно ещё ядро 4 накинуть. И лучше кубернетесом приправить :)

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.

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

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

Не надо использовать dm в проде, с ним обязательно что-то случается время от времени, и временами ничего лучше полного ребута сервера не помогает.
популярное решение.
отдельно монтируется директория с данными, на реальной файловой системе.
имеет место быть.
Не подскажете, как решить проблему с владельцем файлов БД? Postgres в докере отказывается запускаться, если владелец не postgres. Но хотелось бы иметь доступ к базе и с хоста (не отдоновременно с docker-ом конечно).
Есть какое-то решение как при монтировании volume сменить владельца файлов и потом обратно?

Какого рода вам нужен доступ к базе? Возможность запустить бд еще и с хостовой системы или просто доступ по psql?
Второе и так работает, для получения первого нужно шаманить с uid.

Сейчас база как раз на хосте. Перенести её в docker можно, но придётся менять uid, и обратно тоже. Автоматически это нельзя делать? Какой-нибудь командой RUN в dockerfile или опциями монтирования, может ещё как?

Стандартный образ postgres для docker делает chown для файлов базы перед запуском, если с правами что-то не так.

Хм… проверю, спасибо.
Последний раз, когда пробовал работать с официальным образом PostgreSQL, также были проблемы с доступом к файлам. Плюс было не очень понятно, как из docker-compose.yml универсально прокидывать юзера не хардкодя его UID — ведь этот конфиг могут запускать люди с разными UID, а не только 1000.
С того момента, правда, вышла уже третья версия схемы compose. Возможно, там это решено — нужно посмотреть.
Плюс было не очень понятно, как из docker-compose.yml универсально прокидывать юзера не хардкодя его UID

А зачем? Особенно учитывая, что сам docker вполне может быть на удалённой машине.

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

env переменные с поддержкой их на уровне entrypoint/cmd. Что-то вроде


version: "3.4"
services:
  test:
    image: ubuntu
    environment:
    - USER_ID
    command: env

запускаете USER_ID=$UID docker-compose up или иным способом передаёте нужный id

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

Проблемы с доступов для кого? Для 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
    • Убраться за собой (удалить архив, остаточные файлы и т.п.)

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


самое простое решение, как по мне, использовать посредником docker hub,

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. Что я вынес из этой статьи
image
Докер не является средством виртуализации, а использовать его для локальной разработки обычная практика.
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 файл в проекте, смысл все пересобирать? В общем, в данном вопросе у меня нет однозначного ответа. Могу лишь утверждать, что для себя я определил докер, как систему быстрого развертывания идентичной среды для нагруженного проекта.
Ну так в разработке желательно иметь среду максимально близкую к продакшену, чтобы избегать ситуаций «а у меня всё работает». Локально проверяешь, что образа билдятся, что работают как надо, а потом коммитишься и дальше уже пошло по принятому флоу. Но результат твоей работы не только исходный код на ЯП, но и докерфайлы, конфиги сервисов типа веб-сервера и СУБД, описания/скрипты процессов деплоя и т. п. Можно это делать наобум, отправляя изменения в vcs, и ожидая результата от пайплайнов CI, проверяя работу где-то, куда они её раскатали, но при наличии возможности проверить локально, почему это не делать? А докер в этом плане более простой и легковесный, и чем более сложная система, тем преимущества виднее для меня. По крайне мере пока всей системе из десятков сервисов хватает ресурсов локальной машины.
Подождите. При деве необходимо на локальной машине эмулировать среду продакшена, а не наоборот. Зачем деплоить настройки среды на продакшн?

Так они идентичные, единственное отличие сред (продакшен, CI, стейджинг, лоакльная) в параметрах типа DNS имён ендпоинтов и количества воркеров. Грубо, все отличия сред только в environment переменных, читаемых из какого-нибудь .env файла, который в репозиторий не вносится. Плюс для локальной можно примонтировать каталоги с локальными кодами, чтобы не билдить/рестартовать контейнер на каждый чих, только на какие-то глобальные изменения.

Это понятно. У меня тогда вопрос, чем отличается среда на ВБ с Debian 9.1\PHP7.1\MySQL5.7.20 от среды на проде с тем же стеком? Я не думаю, что в вопросах данного стека принципиально железо и сопутствующие ему драйвера. Иными словами, весь этот стек штатно работает на обоих машинах, поэтому и код должен работать одинаково. Разве нет?

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

Согласен. Тут вопрос в размере проекта.

Возможно, я попутал термины. Подумаю, что можно сделать, чтобы не переписывать всю статью.
Основное преимущество Docker перед VB в первую очередь в том, что он не ест столько оперативки и не требует целой кучи ресурсов.
У меня всего 8гб, на плечи которых лежит PHPstorm со всеми плюшками, Chrome с десятком плагинов, Webpack с запущенным на нем Hot reload и ещё несколько инструментов. Чтобы запустить и держать в рабочем состоянии VB рядом со всем этим добром, нужно ресурсов гораздо больше. В итоге, ОЗУ заканчивалась, процессы лезли в swap и насиловали мой HDD, после чего разработка становится невыносимой и приходилось от чего-то отказываться.
VB запускает всю систему целиком со всеми ее процессами, которых не так уж и мало. В свою очередь Docker запускает только то, что мне нужно.
Docker запускается намного быстрее. Подключать дополнительные компоненты удобно. Тестировать хорошо, так как можно быстро поднять новый, чистый контейнер. Selenium работает из коробки без всяких танцев с бубном.
Для себя я нашел много преимуществ. Если их не находите Вы, это может говорить об одном — Вам он (Docker) просто не нужен.

Странно, что VB у вас ест все ресурсы хоста. ВБ это гипервизор, он жестко ограничивает использование виртуалкой ресурсов хоста. Иными словами, вы выделили виртуалке 1гб озу и 1 ядро, оно больше этого и не может использовать. Если у вас проблемы с ВБ, попробуйте Hyper-V, если конечно у вас хост на винде.
Мне докер нужен, но для предназначения, которое написано на официальном сайте проекта :) Для разработки есть масса удобных и более удобных инструментов. Тот же пхпшторм. У него из коробки идет плагин для вагранта.
На вкус и цвет конечно. Мой вопрос лишь в том, что не стрельба ли это по воробьям из танка?
В случае вагранта ресурсы определяет разработчик вагрантфайла. Сказал нужно 2 гига и
и переопределить локально затруднительно.

Это разве не в вагрант файле хранится?

Да, в нем. Я не совсем тогда понимаю, что вы подразумеваете под
и переопределить локально затруднительно.

Обычно, вагрант файл лежит в репозитории проекта или где-то рядом, с параметрами подходящими его автору, у которого, например, 32Гб оперативы и 4 физических ядра плюс HT. Вот и даст одно физическое ядро и 4 Гб, чтобы избегать малейших тормозов. А у тебя 8Гб оперативы и 2 физических ядра. Эта виртуалочка скушает половину ресурсов. А пулл реквест на изменение автор не примет. Придётся изменить и как-то следить чтобы в репу не закоммитить эти изменения, а изменения из апстрима прилетали.

Docker невозможно установить на VPS поднятом на OpenVZ если ядро linux ниже минимальной версии требуемой докером. У меня вот весьма хороший тариф на VPS, но докер я юзать не могу из-за этого ограничения, а платить в 2 раза дороже за аналогичную конфигурацию с SSD на борту вместо HDD как-то не хочется.
Т.е. не каждый VPS поддерживает докер. В итоге получаем неработающую «серебряную пулю».

Если говорить про нормальный vps/vds, а не контейнер в openvz/lxc, то вы сами выбираете нужный дистрибутив, ядро и т. п.


Другое дело, что многим мелким проектам это просто не нужно и никогда не понадобится.

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

Много говорят про ansible. Обязательно посмотрю, раз его так любят

Не утверждаю, что здесь что-то плохое, но позволю себе чутка возразить на некоторые части поста


Это [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 и выше. В питонячем мире на это нарваться сложнее, но тоже бывает.

Я, наверно, тоже не дорос до Docker'а — Использую ProxMox: OpenVZ контейнеры легко копируются, а снепшоты позволяют спокойно откатываться на любую резервную копию или вообще отдельную ветку с совсем другим софтом/окрежением/проектом.
Ну и Git для кода, разумеется. (С сервером в отдельном контейнере и резервными копиями каждый час на отдельный диск)
По мне, так наоборот, докер — показатель «подросткового возраста» в it. Пару лет назад я его везде использовал, потом повзрослел, и теперь только в некоторых специфических задачах его юзаю.

Сильно зависит от задач, да. Для некоторых вещей оверхед от использования докера будет больше, чем польза от оного. Для деплоя в проде это может быть способом избавиться от большого количества головной боли, но потребует вложения определенного количества сил и средств в соответствующую систему оркестрации (будь то банальный docker swarm, или более тяжелые kubernetes с openshift'ом).

Жду тогда от Вас статью "Docker, как показатель подросткового возраста")

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

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

Короче Docker только новые проблемы пораждает.

Я реально слабо представляю нафига он в том же ASP.NET или Go нужен.
Первое, что делает докер — изолирует процессы друг от друга, используя различные маппинги. Второе, что он делает — фиксирует окружение (как билд, так и рантайм), только версия ядра и самого докера не зависит от автора докерфайла, а так он контролирует каждый файл в своей ФС без конфликтов с другими приложениями на том же хосте.

И полезен он прежде всего для компилируемых языков. Это в скриптовых можно залезть и поправить, например, порт, который будет слушать процесс в простом текстовом редакторе, а в компилируемых так не выйдет.
Нормальные приложения имеют текстовые конфиги.
А для изоляции есть LXC.
Докер позволяет эти конфиги вынести из приложения и конфигурировать всё в едином месте и формате.
Докер и есть настройка над LXC) Но, по моему субъективному впечталению, с докером и его аналогами работать удобнее, чем с голым LXC
Proxmox позволяет на проде делать контейнеры LXC, что получается довольно удобно.
Скрипт на баше в 20 строк тоже может создавать полноценные контейнеры, но это не значит, что он будет также хорош, как Docker.
Докер был надстройкой на LXC пару лет назад, но не сейчас.

Это было года 2-3 назад. Потом появился libcontainer и docker отказался от использования lxc, а использует namespaces и cgroups напрямую.

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

Пожалуйста, если хотите рассазать о технологиях — рассказывайте о технологиях, а не о том, что «тот кто не использует, тот нуб!»

Я думаю, Вы и без моих оправданий прекрасно понимаете, что цели кого-то унизить или обвинить у меня не было. Я сам новичок в этом и мне многое что не известно. Вот, люди указали на Ansible. Я с удовольствием посмотрю, когда будет время.
Мотивы мои чисты и искренни. Мне хотелось поделиться своим небольшим опытом и полученными знаниями.
Мне понравился Docker. Он вызывает сейчас у меня такой же восторг, как в свое время вызвал Git, Vagrant и открытия мира Open Source. В моей ситуации Docker решает много проблем. И я не считаю его серебряной пулей, которая способна решить все проблемы.
Но если найдется хоть один, кому я смог помочь, пусть статья не столь информативна, я буду очень рад.
В любом случае, это мой первый опыт в написании статей. И учитывая, что рейтинг статьи, благо, ещё в плюсе, а 28 человек добавило её в закладки, есть те, кто оценил мою поэзию положительно)

Мне понравился Docker. Он вызывает сейчас у меня такой же восторг, как в свое время вызвал Git,

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

«Зачем, да и вообще кому нужны всякие Symfony, если есть WordPress?» А что плохого в Wordpress? Как раз использование фреймворков там, где это не надо и есть изврат. В Америке и Европе большинство проектов как раз и строятся на CMS них, а не пишутся на фреймворках. Просто потому, что поддержка для клиента более предсказуема и выгодна в материальном плане. Нужен блог — берут Wordpress, нужен магазин — берут Magento или Woocommerce.
А потом ищут спецов, которые к вордпрессе прикрутят магазин, а к магенте блог. Или обеспечат прозрачную интеграцию вордпресса и магенты.
Woocommerce — это и есть магазин для Wordpress. из коробки. Ну и интеграция Magento и Wordpress решается установкой модуля. И найти спецов по CMS гораздо легче и дешевле, чем по фреймворку. Гораздо хуже, когда для Landing Page или 10 страничного сайта разработчик Laravel или Symphony использует.

А я разве сказал, что WordPress — это плохо и его не нужно использовать? Напротив, он здорово справляется со своей задачей. Я говорю про то, что новичкам сложно понять, зачем нужны фреймворки. И в особенности Symfony, у которого уровень абстракции гораздо выше, чем у многих других фреймворков.
Скажу про себя: я действительно не понимал, к чему такая сложность. Сейчас сижу и жалею, что выбрал не его. Гибкий компонентный подход был бы очень кстати. И почувствовал это я, когда начал тестировать. Но раньше я этого не мог понять по причине недостатка опыта.

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

CMS изначально заточена под одну задачу — управление контентом. Фреймворки заточены, как правило, под две задачи — предоставление типичной инфраструктуры, чтобы не писать её с нуля, и быстрое создание прототипов/MVP. CMS решает одну бизнес-задачу, фреймворк не решает ни одну, это инструмент для создания решений.

Да сколько можно? Ранее пользовался local, в форуме мне намекнули, что не нужно, потому что это зарезервированный домен. Начал пользоваться dev. Да нет же, его тоже решили занять… Хорошо, что test, как оказалось, тоже зарезервированный, но для разработчиков.
Спасибо больше за ссылку. Добавил пояснение в статью.

*.localhost обычно пользуюсь локально.

Тоже не всегда подходит, потому что некоторые хромы принудительно приписывают ему 127.0.0.1, даже если в файле hosts переопределить. Мне как-то раз приспичило вёрстку в хроме под виндой проверить, поставил их в виртуалбокс — а dev.localhost не открывается (причём с IE/Edge в той же виртуалке отлично открывается), пришлось менять конфиги сайта, отвязывая его от домена, и по айпишнику 10.0.2.1 ходить

Странно, не встречаля. Хотя может в винде дело.

Статья интересная, с точки зрения развития инструментов CI/CD. Другое дело что это все полезно в более менее крупных проектах.
В последнем связке Virtualbox+Vagrant+Laravel Homestead каждому сайту легко можно указать версию php(5.6б, 7.0, 7.1), вот так:
sites:
— map: test.app
to: /home/vagrant/Code/test.app
php: «5.6»
Меня помножило на ноль вот этой фразой
Нужно обновить версию MySQL? Сколько времени и усилий пришлось бы приложить, чтобы сделать это на обычном VPS хостинге? Тут это вопрос 3-4 символов.
Благодаря тому, что Docker работает внутри рабочей системы, а не создает новую, он не сильно нагружает машину для разработки и вполне пригоден для прода

Вообще-то, он конкретно съедает ресурс памяти. А проброс потоков между контейнерами — вообще отдельный гемор.

Конкретно это сколько? Вот сейчас на 33 контейнера dockerd меньше 300 метров ест.

Вот что конкретно сейчас в этих контейнерах крутится?
Время расти дальше и представив себе что сайт вашего блога просматривают столько же людей сколько просматривают habrahabr.ru растирожировать его на несколько серверов.
Представляю себе решение с использованием docker =D.
Такое решение надо предствалять с помощью kubernetes'a. Там такое делается просто.
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.

UFO just landed and posted this here

Docker как раз обеспечивает значительные преимущества для небольшого и среднего бизнеса, который не имеют возможности содержать команды девопсов и наборы кластеров для целей разработки и тестирования, для внедрения CI/CD. Если для большого бизнеса докер во многом удобное средство масштабирования, то для малого прежде всего удобное средство доставки фич от разработчика к пользователю.

UFO just landed and posted this here

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

UFO just landed and posted this here
правильно, зачем теги и бранчи, зачем роллбэк, тестовая/стейжевая/продовая среды, уютненько работаете ;)
UFO just landed and posted this here
Роллбэк без проблем

А кстати, как дела с откатом миграций БД?

UFO just landed and posted this here
Я докером не пользуюсь, просто из интереса спросил) и вообще свои базы руками обновляю, но не будем о грустном
UFO just landed and posted this here
а не было такого (тьфу-тьфу), есть test с с тестами stage с qa, куда копируется база с прода, делается db:migrate.
В случае факапа в проде только db:migrate:redo, во что я не сильно верю, тут косяк, но мы надеемся, что первые две среды позволят заметить ошибку, наивные мы :)
Добавление пары контейнеров с автодеплоем на пару сред пока себя оправдывает.
UFO just landed and posted this here

Во сколько вы оцениваете стоимость перехода малого бизнеса к контейнеризации, как с точчи зрения затрат на разработку, так и с точки затрат на эксплуатацию? Ну вот совсем малый бизнес: один разработчик, который пилит корпоративный сайт с функциями CRM, и один админ который обеспечивает деплой и работу, логи там смотрит, метрики и т. п… Развёрнуто три окружения: локально у разработчика, прод и тестовое, на котором бизнес апрувит деплой на продакшен. Худо бедно настроено даже CI/CD на баш-скриптах. Но время от времени происходят инциденты по типу: разработчик установил что-то себе локально, а админу забыл сообщить. Или ввёл новый параметр конфигурации и тоже забыл сообщить. Или админ как-то ночью залез руками в конфиги сервера, чтобы какой-то параметр изменить, но разработчику не сообщил, и конфигурации стали расходиться.

UFO just landed and posted this here
вы на эту статью сколько ещё ссылаться собираетесь, ей уже больше года, в мире devops'а это уже много.
UFO just landed and posted this here
  1. Вот по опыту перехода на докер гораздо больше времени экономится на сокращении числа рутинных операций по сихронизации трёх окружений.


  2. Из-за разности конфигураций и окружений приложение может падать не сразу, а в каких-то редких кейсах, а то и вообще не падать, а просто вести себя по другому, не так как должно. А насчёт "недопустимо" — описанных бизнес-процессов передачи из разработки в эксплуатацию может не быть вовсе, не говоря о контроле за их соблюдением. Докер — не единственное средство автоматизации, снижающее влияние человеского фактора на подобные процессы, но он им является.
Фраза «работает локально у разработчика» намекает...

Фраза намекает на то, что разработчик предпочитает сначала локально проверить код в работе, а лишь потом пушить его в репозиторий, отдавая на растерзание CI/CD, ревьюверам, тестировщикам, приёмщикам и т. д. Ничего более.


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

Грубо, процесс разворачивания проекта на кластер сводится (есть разные варианты, но для себя выбрал такой) к трём командам:


docker-compose build
docker-compose push
docker stack deploy

хоть на локальной машине разработчика (docker-compose push не требуется), хоть на CI/CD — сервере, хоть на на продакшене


Не нужно практически ничего настраивать на машинах разработчиков.

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


  • СУБД
  • веб-сервер
  • кэш-сервер
  • собственно приложение
    Это не считая различных компиляторов и транспиллеров для Script, SS и т. п. и єто для простого монолита. А если у нас хотя бы сервис аутентификации вынесен в отдельное приложение, то количество настроек даже не в два раза больше увеличивается.
UFO just landed and posted this here

Он станет ещё более удобен при росте команды. Конечно, при условии, что эти два-три человека понимают что делают, что без докера их бы допустили до написания скриптов деплоя на продакшен.


Но среду разработки умеют настраивать на рефлексах большинство специалистов на рынке труда.

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

UFO just landed and posted this here
Sign up to leave a comment.

Articles