После шести месяцев разработки подготовлен (https://blog.docker.com/2017/01/whats-new-in-docker-1-13/) релиз инструментария для управления изолированными Linux-контейнерами Docker 1.13 (http://www.docker.com/), предоставляющего высокоуровневый API для манипуляции контейнерами на уровне изоляции отдельных приложений. Docker позволяет, не заботясь о формировании начинки контейнера, запускать произвольные процессы в режиме изоляции и затем переносить и клонировать сформированные для данных процессов контейнеры на другие серверы, беря на себя всю работу по созданию, обслуживанию и сопровождению контейнеров. Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups). Код Docker написан на языке Go и распространяется (https://github.com/dotcloud/docker/) под лицензией Apache 2.0.Основные изменения (https://github.com/docker/docker/releases/tag/v1.13.0):
- Расширены возможности режима Swarm (https://docs.docker.com/engine/swarm/), начиная с прошлой версии интегрированного в состав движка Docker и предоставляющего средства кластеризации для упакованных в контейнеры приложений. Swarm даёт возможность управлять кластером из нескольких хостов Docker по аналогии с работой с одним виртуальным хостом. В новой версии обеспечена поддержка использования compose-файлов (docker-compose.yml) для развёртывания сервисов в режиме Swarm (сложный мультисервисный стек теперь можно развернуть на нескольких хостах одной командой "docker stack deploy"). Из плюсов применения docker-compose.yml отмечается возможность указания желаемого числа экземпляров каждого сервиса, применение политики обновления и определения условий запуска сервисов.
- Улучшена обратная совместимость на уровне взаимодействия управляющего демона с инструментарием командной строки (CLI). Если раньше использование новой версии клинта со старой версией демона приводило к проблемам (выводилась ошибка "Error response from daemon: client is newer than server"), то начиная с выпуска 1.13 новые версии CLI учитывают особенности прошлых выпусков демона и могут использоваться для управления ими, что значительно упрощает организацию управления инфраструктурой с одной системы. На случай если клиент пытается выполнить действие, которое ещё не реализовано в демоне в новом выпуске добавлены средства для согласования функциональности клиента и сервера;- Реализованы две новые команды "docker system df" и "docker system prune" для отображения сведений об используемом дисковом пространстве и для выполнения операции очистки неиспользуемых данных;
- Проведена реструктуризация интерфейса командной строки, все команды реорганизованы для более логичного соответствия объектам, с которыми они взаимодействуют. Например, команды "list" и "start", применяемые для вывода списка контейнеров и запуска контейнера, перенесены в команду "docker container" и теперь являются подкомандами ("docker container list" и "docker container start" вместо "docker list" и "docker start"), а команда "docker history" преобразована в "docker image history". Поддержка старого синтаксиса команд сохранена для обеспечения обратной совместимости;
- Расширены средства мониторинга. Добавлена экспериментальная команда "docker service logs", позволяющая упростить отладку сервисов за счёт избавления администратора от ручного сбора логов из отдельных хостов и контейнеров. При выполнении "docker service logs" логи из всех контейнеров, в которых выполняется указанный сервис, будут перенаправлены в текущую консоль. Кроме того, в новой версии появилась точка сбора параметров (/metrics) с метриками контейнеров, образов и состояния управляющего демона, выводящая данные в стиле Prometheus (https://prometheus.io/);
- В команде "docker build" появился новый флаг "--squash", позволяющий агрегировать все производимые при сборке слои файловой системы в один сводный слой, что может оказаться полезным при создании минималистичных образов контейнеров. Ценой такого объединения является увеличение накладных расходов при перемещении образов и невозможность совместного использования таких контейнеров. В команду сборки также добавлен флаг "--compress" для сжатия сборочного контекста, отправляемого из CLI в управляющий демон, что позволяет ускорить сборки, при которых осуществляется взаимодействие с демонами на других хостах;
- Началось бета-тестирование Docker для облачных платформ AWS (https://docs.docker.com/docker-for-aws/) и Azure (https://docs.docker.com/docker-for-azure/).
URL: https://blog.docker.com/2017/01/whats-new-in-docker-1-13/
Новость: http://www.opennet.me/opennews/art.shtml?num=45891
Возможно кто может ответить - как правильно перезапускать контейнер? (У меня в контейнере БД и при stop - start каждый раз начинается процесс recovery.)
Запустить внутри контейнера (docker exec) команду, посылающую сигнал основному процессу для Graceful shutdown/restart. Т.е. сделать так, чтобы контейнер (процесс в нём) сам себя аккуратно прибил, совершив все необходимые ему ритуалы :)
Предполагаю, что у вас процесс базы данных в контейнере запускается как то криво. Например через bash скрипт без использования башевской команды exec. В результате, при остановке контейнера, bash завершается но не пробрасывает сигнал завершения в базу данных. Процесс базы данных не корректно завершается и при следующем запуске начинает recovery.
вы делаете docker stop и mysql процессу прилетает kill -9
как верно подметили выше запустите в докере грубо говоря /etc/init.d/mysql stop
если mysql у вас был основным процессом - то он корректно завершится и контейнер схлопнется
в принципе все эти пляски можно занести в отдельный скрипт и заалиасить например в mysql-docker stop/start/restart
mysqladmin -uroot -p -h127.0.0.1 --protocol=tcp shutdownmysql> SHUTDOWN
> вы делаете docker stop и mysql процессу прилетает kill -9Не совсем так.
The docker stop command attempts to stop a running container first by sending a SIGTERM signal to the root process (PID 1) in the container. If the process hasn't exited within the timeout period a SIGKILL signal will be sent.
Т.е. сначала посылается SIGTERM, и только через 10 секунд (настраивается опцией для команды stop) посылается SIGKILL.
никак
контейнеры steteless by design, если вы положили БД в контейнер, значит, вы используете их неправильно
если минусаторы не могут понять эту простую идею своей пустой головой, не верят мне, пусть хоть прочтут статейку от крутых парней (они сделали xtradb, дефолтный движок mariadb):https://www.percona.com/blog/2016/11/16/is-docker-for-your-d.../
там всё разжёвано для слабоумных
Смотрите, а если у меня такой кейс: есть старое приложение с корявой базой данных. Оно конфликтует с версией базы, установленной глобально (база плохо спроектирована, нарушена целостность). Для этого приложения мне нужна не самая новая версия базы (MySQL), чтобы не прыгать в командой SET global="..." Короче, надо чтобы база была такая же, как на живом сервере. Вроде как Докер напрашивается сам собой? Чем конкретно Докер плох для моего локального компьютера?
> Смотрите, а если у меня такой кейс: есть старое приложение с корявой
> базой данных. Оно конфликтует с версией базы, установленной глобально (база плохо
> спроектирована, нарушена целостность). Для этого приложения мне нужна не самая новая
> версия базы (MySQL), чтобы не прыгать в командой SET global="..." Короче,
> надо чтобы база была такая же, как на живом сервере. Вроде
> как Докер напрашивается сам собой? Чем конкретно Докер плох для моего
> локального компьютера?не оч вас понял, если честно, но docker - отличный инструмент для тестирования, дебага, разработки и деплоя приложений, но толкать в него инфраструктуру (сеть или хранилище, например в виде БД) - идея плохая
XtraDB это пропатченный InnoDB, а не новый движок БД.
XtraDB это расширительный обвес внутри InnoDB с флагами, а не только пропатченный InnoDB.
слово "новый", дорогой аноним, ты придумал, я его не писал
ты, дорогой аноним, пробовал писать патч для innodb так, чтобы оно стало работать быстрее? а xtradb быстрее innodb, потому и принято в mariadb. ребята крутые, не понимаю, к чему эта ремарка.
лол што? вы явно в проде докер или мезос не юзаете. стейт лес это не запрет БД в контейнер, а то что на сам контейнер ведет себя одинакового. volumes вы можете подсовывать самые разные.
Пожалуйста
https://medium.com/@gchudnov/trapping-signals-in-docker...
Использовать systemd контейнере (с соответсвующим ключем) и не ипать себе мозг.
Нужно в скрипте запуска обрабатывать хэндлеры. Пример здесь: https://github.com/oracle/docker-images/blob/master/OracleDa...
До сих пор так и не понял. зачем нужны контейнеры?
Смотреть на то как быстро запускается pid=1 в неймспейсе.
деплоили когда-нибудь софт на python/ruby, требующий десятков модулей определенных версий? а теперь представьте, что вам нужно деплоить новую версию каждый день, да ещё и по 2-3 раза (чтобы потестировать перед продом). в некоторых из этих ситуаций контейнеры здорово упрощают жизнь.
Неужто в python/ruby нет аналога local::lib? Сильно в этом сомневаюсь. Даже если нет, то обычного chroot для решения хватило бы.
Сдается мне, что многие из пользующихся контейнерами не очень и понимают, что это такое.
Это вы не понимаете, что это такое и зачем это использовать.
Так это и есть обычный chroot на стеройдах.
> Так это и есть обычный chroot на стеройдах.ты глупыш, чрут реализует изоляцию только на уровне файловой системы в отличии от докера и прочих контейнеров
Чрут на стеройдах реализует изоляцию не только на уровне файловой системы, в отличие от обычного чрута.
Conda (anaconda miniconda) позволяет менять окружение для каждого проекта.
Так это и virtualenv умеет, только этого мало. Docker позволяет создавать изолированные микросервисы с изолированем и масштабированием. Удобная вещь, но меня не покидает ощущение что он убьет линукс. Теперь можно спокойно работать под вин даже с чисто линуксовыми вещами... Немного печально)
Доля Linux на десктопе и так небольшая, да и вообще слабо коррелирует с возможностью запуска окружений разработки, к тому же те из разработчиков, кто хотел перейти на Linux, уже давно это сделали. А по части серверов подобная ситуация только на руку Linux, потому что у M$ и близко ничего подобного контейнерам нет.
Бздунам под джейлом они не нужны
> Бздунам под джейлом они не нужныа как бздуны нарезают в джейлах лимиты на сеть, диск?
или бздунам лимиты тоже не нужны?
VIMAGE, VNET падает в панику, сеть не нарезают со всем остальным вроде есть успехи.Но да как не была готова это ОС продакшену, так и не будет включая и докер в бсде.
> VIMAGE, VNET падает в панику, сеть не нарезаютА у меня руки из плеч растут - я такого как то не встречал :)
> Но да как не была готова это ОС продакшену,Мази купи от пригара, Ыгспёрд :)
>так и не будет включая и докер в бсде.у них свой с библиотекаршами будет :)
Ну и стандартный в линуксиляторе допилят.
> Ну и стандартный в линуксиляторе допилят.В следующей столетие.
> сеть не нарезаютУх ты, а провайдеры в 2000-х и не знали, что нельзя нарезать сеть бздами.
> Но да как не была готова это ОС продакшену,Расскажите это всяким нетфликсам, а то бедолаги не знают и треть трафика страны разносчиков и причинителей демократи бздами качают, профиты профукивют.
> лимиты на сетьставят 10-мегабитную сетевуху, благо не надо выбирать поддерживающуюся. :-)
>> лимиты на сеть
> ставят 10-мегабитную сетевуху, благо не надо выбирать поддерживающуюся. :-)Правда, оно умело нарезать сеть еще когда многие умники опеннета пешком под стол ходили... Типа, классическое
ipfw pipe 1 config bw 300Kbit/s
но этого местным петросянам знать не обязательно )
о древнее зло которое нарезает медленно
зато стабильно, как бы нужно стремится к стабильности.
> зато стабильно, как бы нужно стремится к стабильности.Некоторым религия не позволяет использовать altq при наличии альтернатив?
queue internet bandwidth 1Mb hfsc (upperlimit 1Mb){inet_jail1,inet_jail2}
queue inet_jail1 bandwidth 49% priority 3 qlimit 500 hfsc (realtime 500Kb)
queue inet_jail2 bandwidth 49% priority 3 qlimit 500 hfsc (realtime 500Kb)
пердежи про стабильный hfsc на фоне гугловского планировщика в linux.
>>> До сих пор так и не понял. зачем нужны контейнеры?
>> Бздунам под джейлом они не нужны
> а как бздуны нарезают в джейлах лимиты на сеть, диск?Альтернативная логика некоторых, излишне лапчатых - если нет контейнера, то нет и лимитов? Правда, джейл вроде как аналог, да и цель прибивания лимитов гвоздями к контейнерам не очень ясна, но насчет этого зилоты похоже особо не задумываются да?
> или бздунам лимиты тоже не нужны?rctl -a jail/process/user:name_or_id:readbps:throttle=10M
rctl -a jail/process/user:name_or_id:writeiops:throttle=1337
А насчет лимитов на сеть даже не вбросно^W смешно. Так что попробуй еще раз.
Скажите знающие люди, контейнеры можно использовать в прдакшене или они годятся только для тестов?
Юзаем контейнеры в проде, есть небольшой пережор по памяти по сравнению со старым подходом, но в целом полет нормальный.
Повезло. Я вот в нём старый Jenkins держу для ~35 девелов\7 проектов ... не скажу что счастлив, но иначе очень уж гимморно всю солянку версий на одном хосте собирать. А тупо по ВМ нарезать - не влазиит, нищeбpoды они :(
> Повезло. Я вот в нём старый Jenkins держу для ~35 девелов\7 проектов
> ... не скажу что счастлив, но иначе очень уж гимморно всю
> солянку версий на одном хосте собирать. А тупо по ВМ нарезать
> - не влазиит, нищeбpoды они :(или Ansible + Terraform
> Повезло. Я вот в нём старый Jenkins держу для ~35 девелов\7 проектов
> ... не скажу что счастлив, но иначе очень уж гимморно всю
> солянку версий на одном хосте собирать. А тупо по ВМ нарезать
> - не влазиит, нищeбpoды они :(OpenNabula + KVM и развешать докеры с Rancher (development, testing, staging, production).
Контейнеры они несколько разные бывают. OpenVZ уже много лет как используется в продакшене для легковесной виртуализации с выдачей клиенту рута. LXC или LXD они на поиграться или только в доверенной среде для удобства. Docker это несколько другой вариант виртуализации, но опять таки подходит больше для доверенной среды, хотя о безопасности там тоже немного заботятся. Но лучше все-таки набор docker контейнеров внутрь KVM помещать, чем напрямую пускать.
https://thehftguy.com/2016/11/01/docker-in-production-an-his.../
Docker - это такой flatpak для серверных приложений? (Сам flatpak, понятно, для десктопных) Объясните.
Примерно так, только в docker еще накрутили управление контейнерами композ и сварм