Не только у нас как-то всплыла эта проблема.

И на что в итоге перешли? :)

Есть ещё http://vmware.github.io/harbor/

На ceph

Омг

На ceph

я слышал цеф и пришёл вам за него рассказать)

Внезапно)

https://microbadger.com/ вот ещё интересный инструмент What's inside your Docker containers? Have you ever found an image on Docker Hub and wondered what code it was built from? Or tried to locate the Docker image for a source code repo? MicroBadger makes it easy to see the contents of a container image, including the layers, the base image it depends on, and its labels & other metadata.

Например можно так https://microbadger.com/images/puppet/puppetserver

я слышал цеф и пришёл вам за него рассказать)

Ждем-с

Ждем-с

а тебе я вроде рассказывал

Всегда люблю послушать офигенные истории!

Всегда люблю послушать офигенные истории!

Надо было приходить на митап опенстека

1. Никто не гарантирует, что все контейнеры докера однажды накроются медным тазом во время очередного обновляния ядра, какого-то пакета или еще чего-то. 2. Никто не гарантирует, что при перезапуске база сможет запустится. Только и всего. Я считаю, что запускать с проброшенной папкой в хостовую систему еще можно, но volume - это точно зона риска.

Но ведь эти же самые риски справедливы и для базы вне докера? Точно также можно основной системы поломать что-то, точно также можно словить проблемы с фс. Просто применяйте обще принятые для этого стратегии, отдельный сервер для базы, бэкапы на другой сервер, наличие реплики

здаров посоны!

как заставить docker использовать http, вместо https?

прописал в /etc/docker/daemon.json нужный хост

грубо говоря { "insecure-registries":["1.2.3.4:5000"] }

docker info выдаёт: Insecure Registries: 1.2.3.4:5000 127.0.0.0/8

А да. Сорян)) он уже тут. ))

> docker -v Docker version 1.12.6, build 78d1802

level=error msg="Attempting next endpoint for pull after error: Get https://1.2.3.4:5000/v2/: http: server gave HTTP response to HTTPS client"

в логах

Но ведь эти же самые риски справедливы и для базы вне докера? Точно также можно основной системы поломать что-то, точно также можно словить проблемы с фс. Просто применяйте обще принятые для этого стратегии, отдельный сервер для базы, бэкапы на другой сервер, наличие реплики

Но проблема в том, что это дополнительные риски, которые, честно говоря, не то что бы окупаются. Объеденять бд в кластер, со свободным плаваньем контейнеров весьма опасно, а просто запускать бд в докере или просто установленную ... ну, не такяа большая разница

разница в том что в контейнере удобнее, но конечно если база всего один инст глобальный на два десятка php сайтиков, то вероятно смысла особого и нет держать в контейнере

я примерно 6+ лет занимаюсь разработкой веб проектов разной сложности, и вот на моей памяти базы умирали потому что админ чего не то обновил насервере, изза того что программист написал корявую миграцию или полез на сервер с какойнить gui тулзой, изза того что харду пришла жопа, изза того что проект был написан индусами, которые оставили бэкдор, и потом пришли и удалили базу к херам. Последнии два года юзаю базы в докере, не спорю, у меня не было нагрузок, проектики стартапчки разношерстные, но не было такого чтобы база упала изза докера, или данные базы потерлись потому что бэкэнд фс докера погнал. Поэтому риск есть, вы правы, но вероятность его по моему опыту не больше чем выше перечисленные причины

возможно смерть базы от рук докера, еще у меня в переди 😃

почему базы не хранить на хост машине? я так поступаю

мне интересно, при перезагрузке сервера или перезапуске контейнера, какой командой внутри докера бд складывается ?

в обычной системе есть уровни запуска и при выключении БД гасится правильно

думаю риск в том, что в докере, это не всегда так

точно такой же, докер шлёт процесу сигнал, и та корректно останавливается

https://docs.docker.com/engine/reference/commandline/stop/ The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL.

надо только учитывать, что если вы запускаете какой то демон через свой bash скрипт, то SIGNTERM получит баш скрипт, а демону он не передаст его. Я когда сервисы на golang деплоил, столкнулся с этим, ни как не мог понять почему уменя сервис корректно не завершался

точно такой же, докер шлёт процесу сигнал, и та корректно останавливается

вот это кстати не всегда так получается. тут есть нюанс. докер шлет контейнеру SIGTERM, база начинает останавливаться. Для больших БД это операция может занять довольно продолжительное время, а у докера по умолчанию таймаут в 10 секунд и если база не успела всё доделать, что положено при её нормальном завершении - докер просто прибьёт её через SIGKILL через 10 секунд. И вот на этом месте можно очень легко получить побитые данные, хотя в большинстве случаев современные бд могут их восстановить после запуска - вероятность остается.

в общем надо быть втройне внимательней, при использовании БД в докере, т.к. много подводных камней, поэтому и не рекомендуют БД в него

не спорю, но с базами всегда надо быть в тройне внимательнее ))

но мы используем разные бд в докере и всё хорошо: perocona, elasticsaearch. mongodb. проблем небыло, если бысть осторожным всё ок.

но ведь на практике, ты никогда не узнаешь, когда у тебя база начнёт складываться больше 10 секунд...

или узнаешь, но уже в результате расследования фейла

для базы надо увеличивать таймаут завершения

для базы надо увеличивать таймаут завершения

Интересно, как это сделать можно? При ручной остановке понятно -t 30, а вот когда просто делается ребут хоста то тут как быть?

https://docs.docker.com/compose/compose-file/#/stopgraceperiod через композ можно задать

https://docs.docker.com/compose/compose-file/#/stopgraceperiod через композ можно задать

Благодарю!

Господа, а кто-нибудь в курсе как в нативном докере xdebug настроить? У меня наотрез отказывается: выводить в докер порт хоста (9000) так чтобы контейнер думал, что хост локальный и порт тоже локальный. Как?

Господа, а кто-нибудь в курсе как в нативном докере xdebug настроить? У меня наотрез отказывается: выводить в докер порт хоста (9000) так чтобы контейнер думал, что хост локальный и порт тоже локальный. Как?

Там опция есть, конектится к тому кто делает запрос, забыл как называется. Вот её вставляешь и не паришься

xdebug.remote_connect_back

Там проблема, что IP запрашивающего и Хоста почему то не совпадают. Кто сталкивался? Как лечить?

Так с чего они совпадать то будут, ты же в докер сеть через бридж ходишь

я тебе точно говорю, пропиши remote_connect_back, и всё будет ок, я же так дебажил, без проблем всё пашет

аналог только прописывать жестко айпи хост машины в конфиг, но это гемор

zend_extension=xdebug.so xdebug.remote_autostart=0 xdebug.remote_connect_back=1 xdebug.remote_port=9000 xdebug.remote_enable=1

а хотя да, я тебя обманываю, ты прав, не пройдет бэк конект изза различающегося айпи

я же всё равно прописывал remote_host

ставишь себе статичный айпи, и в конфиг его

А как статичный IP Хоста внутри контейнера выставить?

Ребят, подскажите такую штуку: есть два приложения, на php и python, в разных контейнерах. Нужно запустить их на одном сервере, чтобы к ним обоим можно было обращаться по http, в зависимости от dns запроса. Как это реализовать?

Ребят, подскажите такую штуку: есть два приложения, на php и python, в разных контейнерах. Нужно запустить их на одном сервере, чтобы к ним обоим можно было обращаться по http, в зависимости от dns запроса. Как это реализовать?

делаешь третий контейнер nginx, помещаешь его в сеть с теми двумя, и в зависимости от запроса направляешь

proxy_pass

proxy_pass

Спасибо, попробую

Айпи не забудь пробросить

А то окажеися что у всех пользователей айпи 127.0.0.1

Гаспада. А какие есть решения для того, чтобы контейнер мог использовать ssh-ключи с виндового хоста?

-v не получится?

нет, разрешения на файл не те, а "те" разрешения поставить невозможно

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

сделать свой образ, на базе нужного образа, и при билде что нужно скопировать

ммммм

и все?

т.е. других альтенатив нет?

а что вообще делаешь?

может ты вообще не тем путем идёшь изначально

я хочу, чтобы некие скрипты, которые бегают в контейнере, могли использовать мои ключи для авторизации

http://serverfault.com/questions/81746/bypass-ssh-key-file-permission-check ну как вариант обойти проверку прав ключей

'AFAIK, there is no way to bypass the keyfile permission check with ssh or ssh-add (and you can't trick it with named pipe or such)'

кстати да, там чуваки ниже пишут, ты же можешь поднять локально ssh-agent и пробросить его сокет внутрь контейнера, и тогда скрипты будут юзать аус сокет

не, там чел описывает сложный способ, но он рили сложный, и к докеру не применим скорее всего, ссылку кинул не глянув

а вот с проброской аус сокета вполне реальный способ

https://gist.github.com/d11wtq/8699521 вот чуваки тут делают так, но у них походу не винда

но по мне так проще всё же забилдить свой образ на базе нужного, и добавить в него ключей, всё остальное геморой какой то

ну, как один чувак написал Many developers implement either insecure or inconsistent cut-offs, for example, embedding secrets into the image or installing gems at run time instead of build time. These approaches can be sufficient for quickly getting applications up and running, but they create a technical debt by introducing architecture that isn’t consistent with common security requirements and continuous delivery principle