Ну так деплой через git у нас не отменяет преимущества докера. Вот пример яркий: в выходные игра попала в фичеринг и онлайн вырос на 30-40%, мощностей стало не хватать. Мы купили новый сервер, поставили ОС, а дальше docker-machine, docker-compose и готово — сервер обрабатывает запросы. 25 минут на всё, из них 20 на покупку сервера и установку ОС. Без докера бы тут было дел на много дольше. Можно конечно всякие там ansible, но мне докер тут удобнее.
В случае если я пушу один php файл в git, он просто зальётся во все нужные контейнеры и сервер продолжит работу без даунтайма. Если же пушить контейнер с кодом, придётся как минимум перезапустить php-fpm что приведёт к потере некоторых запросов, если по простому, а если по тяжёлому — приведёт к необходимости настройки умных балансировщиков, которые для нас сейчас избыточны. Пуш в продакшн ветку могут сделать несколько разработчиков, для этого либо каждому из них придётся в запускать сборку контейнера с кодом, либо поднимать CI-сервер, который будет это делать для каждого пуша. Я просто не вижу смысла делать ещё одну прослойку между git и сервером, только для того, чтобы соответствовать чьим-то убеждениям, причём без видимого профита от неё и с видимым замедлением и усложнением процесса. Я никого делать так не призываю, мы просто нашли для себя удобное решение и я им поделился.
Код, конфиги и данные у нас вынесены в volume. Сами контейнеры содержат только окружение. Например, если мы хотим обновить php или node.js, мы собираем образ с его новой версией и деплоим через docker-compose. Он пересоберёт образ и стартует его, подцепив volume с кодом и конфигами (которые при необходимости уже подготовлены для работы с новой версией окружения). Это удобно — мы везде быстро получаем одинаковое окружение. Но если слепо идти дальше и, например, мы немного подправили баланс в игре и для этого нужно собрать контейнер и пушнуть его на все сервера и перезапустить — это уже не удобно. Вместо этого мы просто пушим нужные коммиты в продакшн ветку и она вытягивается на все сервера через git. Это на много быстрее и не смешивает всё в кучу — наше приложение и его окружение. Если бы речь шла о каком-то бинарном приложении, которое бы нужно было предварительно скомпилировать и оно имело жесткие релизные интервалы, вариант с контейнером мог бы подойти, но в нашем случае, это будет только мешать.
Беспорядок в npm конечно существует, но все крупные библиотеки уже давно обновляются очень культурно. Ну и они сами по себе не обновятся при сборке образа. Если конечно не указывать в зависимостях что-то типа версия 2 и больше. Мы всегда указываем все версии зависимостей чётко, это гарантирует, что каждый раз будет установлена одна и та же библиотека. Когда нужно обновится — поднимаем версию руками, обновляем, тестируем и уже после этого она попадает в сборку. Обычная практика, это касается любого пакетного менеджера, не только npm.
Использование динамических ip и не использование своих конфигураций — это проблема не Docker, а человека его настраивающего. ip вообще нет необходимости использовать, т.к. всё работает через локальный DNS для контейнеров на одной машине и через DNS внешнего сервиса типа Consul, при работе на нескольких машинах. А конфиги, у нас например, подгружаются из git и чтобы их поменять, нужно только запушить новый конфиг в нужную ветку и перезагрузить контейнер. В образ конфиги мы не зашиваем, чтобы каждый раз не пересобирать.
Особо сложного ничего не делали. Есть набор машин, они создаются через docker-machine create, а всё окружение докера (папка .docker) хранится в гите. Само окружение управления так же запускается внутри контейнера, чтобы всем было проще его у себя запустить и работать с машинами. Проект разбит на микросервисы: 1 контейнер — 1 процесс. node.js, php, mysql, nginx. Код в контейнеры подгружается из git с заданным интервалом из продакшн ветки. Как только всё готово, мы мерджим текущую ветку в продакшн ветку и она вытягивается на сервера. node.js контейнеры при этом дополнительно пинаются, чтобы изменения подхватились. Поднят свой registry, в него собираем свои образы, заточенные под удобство конкретного проекта. Из глюков ничего особо серьёзного не было. Пару раз было что докер-демон переставал отвечать на какие-либо команды и даже его рестарт не помогал, приходилось перезагружать весь сервер. Зато, развернуть новый сервер при увеличении нагрузки можно за 15 минут из них 10 уйдёт на оплату сервера и установку ОС.
С данными пока не всё так красиво, как со stateless контейнерами, но шаги в этом направлении делаются. Если с не большими и не сильно требовательными к скорости чтения/записи данными, можно обойтись сетевыми решениями вроде своей NFS или готовых облачных решений, то с базами данных сложнее. Тут либо локальное хранение на том же сервере, либо дорогие высокопроизводительные решения СХД. Недавно появилась возможность именовать и создавать volume отдельно от контейнеров, это немного улучшило управляемость. До этого для данных создавался отдельный контейнер с volume, которые подключались к другим контейнерам (которые этими данными управляют) через volumes_from. Что тоже вполне нормально работало. Перенос больших данных пока не очень удобен, есть ручные действия, хотя есть сторонние решения, типа flocker, которые эту задачу пробуют решить. Но сам пока не пробовал его в бою. На небольших тестовых данных всё хорошо, но не понятно, будет ли всё так же хорошо при копировании 500Гб БД. В любом случае, проблема больших данных лежит немного за рамками Docker, т.к. такие объёмы пока упираются в проблемы, которые Docker решать не предназначен. Бекапить работающую БД путём копирования файлов всё равно не получится. Нужен либо дамп, либо репликация, а вот это уже делается средствами Docker без проблем.
Полгода используем Docker в production. Более 20 серверов, более 300 тысяч уникальных посетителей в сутки. Около 30 различных контейнеров. Экономит время и нервы колоссально, но нужно хорошо разобраться, чтобы начать получать профит. Технологии ешё есть куда расти: бывают небольшие сбои, кое-где некоторые вещи кажутся не логичными, но дело движется. В любом случае, Docker это лучшее, что случалось с управлением серверами за последние годы (по моему мнению). Сейчас у нас вся конфигурация и код в хранится в git, деплой через git (push в prodcution ветку). Уже давно нет никаких конфигов nginx написанных (или подправленных) кем-то в редакторе прямо на сервере. Даже при полном крахе, вся система может быть развернута за минуты на голых серверах. Пока используем машины вне кластера, переключаясь через docker-machine env внутри специального контейнера для управления. Очень хочется перейти на swarm, но пока есть факторы, которые останавливают.
Все ситуации разные. Подход один: когда видим, что память расходуется не так, как должна, делаем дамп heap и разбираем его в профайлере (Google Chrome). Когда нормальный расход процесса, например, 100Мб, а фактический — гигабайт, не сложно будет увидеть, что за объекты наполняют heap. Ну а далее — думаем, почему GC их не собрал. Причины появления в программе разные, но причина не сбора обычно одна — где-то осталась ссылка на объект, возможно и не явная. Мог где-то быть запущен setInterval или установлен EventListener, в область видимости которого попадает объект. Может быть взаимная ссылка между объектами — очень коварный баг. Ещё могут заполняться буферы, если куда-то пишут быстрее, чем читают. Вообще ситуаций полно, каждую раскручивать нужно исходя из того, что именно утекло.
По поводу утечек памяти и перезагрузок. В конечном счёте обычно выясняется, что виноват код, либо ваш, либо npm. У нас игра на nodejs, очень интенсивная, сетевое взаимодействие через websocket с клиентами. Были «детские» проблемы, которые тоже время от времени забивали память и приходилось перезагружать инстанс, но под пристальным анализом они все были выявлены и исправлены, и да, все они были в коде приложения, хотя далеко не все были так очевидны, т.е. на первый взгляд казалось, что всё в коде хорошо. Но анализ дампов heap и примерных ситуаций, в которых они возникали, помог их выявить. Сейчас инстансы работают спокойно столько, сколько нужно. Неделю недавно работали, т.к. долго не апдейтили код.
У меня ещё есть сайт написанный на node.js, там тоже всё отлажено, писал давно его и долго мучился сначала, но после того, как все проблемы устранил — работает без перезагрузок вообще, поскольку код там не обновляется, аптайм там месяцами измеряется. Ну и все относительно популярные модули npm довольно серьёзно относятся к проблемам утечек памяти, в целом с ними там ситуация хорошая, их либо нет, либо их быстро исправляют.
Действительно, помогло, спасибо. С оракловским JDK 1.8 эта настройка ничего не меняет. Точнее какое-то изменение происходит, но глазом его уловить очень сложно.
Шрифты как-то пожирнели. OS X El Capitan. Idea 14 с JDK 1.8 от Oracle. Шрифты казались оптимальными. Сейчас поставил Idea 15. Там всё кажется жирным. MBP 13" Retina в нативном разрешении.
Под Windows очень долго использовал dbForge Studio for MySQL. Считаю, что это лучшее решение для работы с MySQL. Всё сделано очень удобно, что сильно ускоряет работу. Но есть одно «но»: он только Windows. Моя основная рабочая ОС — MacOS, и я не видел ещё ни одного менеджера для MySQL, который хотя бы близко подошёл по удобству работы и функциям к dbForge. Сейчас использую Sequel Pro, он быстрый, достаточно удобный, его хватает для многих задач, но некоторых функций в нём очень не хватает: например нельзя отредактировать индекс. Понятно, что в любом случае нужно будет удалить его и создать новый, но когда нужно добавить поле в составной индекс — очень не удобно расставлять всё с нуля. Было бы здорово, если наконец появится достойный кросплатформенный менеджер БД. Navicat и Mysql Workbench очень далеко пока до удобства, хотя они полны функционалом.
До перехода на макбук пользовался MacMini с MagicKeyboard и Trackpad. Trackpad лично мне было удобно использовать обратной стороной к себе (той, где батарейки и мёртвая зона). В этом положении рука ложится на трекпад, как на мышь и не устаёт совершенно. На ноутбуках похожее расположение ладони за счёт того, что есть небольшой зазор между корпусом и трекпадом и корпус немного выше уровня стола. В обычном же положении трекпада рука находится в напряжении, много случаев, когда нужно держать её на весу. Долго пробовал адаптироваться, но так и не смог, перевёрнутый режим решил проблему на 5+. Так вот, в новом трекпаде нет этого отсека и мёртвой зоны, не представляю теперь, как им пользоваться.
Лицензия продляется от срока её окончания, т.е. потери времени при обновлении нет. По крайней мере, я продлял в прошлый раз задолго до окончания срока лицензии и она продлилась ровно на год от её предыдущей даты завершения.
История пишется в момент открытия, на сколько я понимаю. Часто бывает ситуация, что открыл вкладку месяц(!) назад, а закрыл вот недавно случайно и сейчас хочется её вернуть. Поэтому большой список недавно закрытых или возможность как-то в него посмотреть, действительно пригодилась бы. Оперой не пользуюсь, просто хотел прояснить момент, почему история в данном случае не работает.
У меня ещё есть сайт написанный на node.js, там тоже всё отлажено, писал давно его и долго мучился сначала, но после того, как все проблемы устранил — работает без перезагрузок вообще, поскольку код там не обновляется, аптайм там месяцами измеряется. Ну и все относительно популярные модули npm довольно серьёзно относятся к проблемам утечек памяти, в целом с ними там ситуация хорошая, их либо нет, либо их быстро исправляют.
Слева Idea 15, справа Idea 14.