Возможно ваше решение очень крутое и вообще новое слово, но ваша активность затянуть меня в свою секту граничит со спамом. Я никогда не подписывался на этот Bluemix, но вы спамите меня с разными «Hi there (almost) Bluemixer ...» через день.
поправка самому себе — свежий плагин для питона таки есть, он просто не обновлялся от версии 4.чего.то.там то 5 пока я не переустановил его. Так что все не так плохо как казалось.
А IDEA 15 для которой нет совместимого с ней питона, это действительно называется «обновленная версия»? Или просто забыли обновить до конца? Или я что-то совсем не так понял? Или теперь стабильные версии это как раньше были EAP?
Я искренне не понимаю, как новая, видимо стабильная версия продукта, может прийти без одного из «встроенных» плагинов.
хмм, это как минимум «неспортивно» редактировать свой ответ после того, как на него пришел комментарий. Я даже удивлен что хабр такое позволяет. И нет, «и каждому нужен репозиторий» это ерунда. Ну на самом деле, стоит почитать про docker registry а не придумывать себе что оно такое и станет понятно, что он нужен один, а не на приложение.
Я дал ссылку на docker-registry, за него не надо ничего платить. То, что вы показали это их сервис для корпораций. По моей ссылке есть простая и ясная инструкция, как поднять registry у себя. Ну вот еще одна, которая прямо так и называется «Deploying a registry server».
И при чем тут «когда приложение в hub»? Что мешает сделать build без хаба из своих исходных Dockerfile?
1. Официальные образы это всего лишь образы, никакой особой мистики в них нет. Они могут кому-то подойти «как-есть», кому-то послужить базовыми а кому-то как источник информации о том, как сделать нечто свое из них.
2. Когда мы собрали свой образ то ему можно сделать push. Но его вовсе не обязательно делать в публичный или даже приватный docker hub. Поднимаем docker-registry и пушим туда, как все нормальные люди, которым надо приватный репозиторий для докера.
3. Кроме того, когда сборка включает в себя все, что надо и Dockerfile является тем, чем он обычно является, ничего не мешает раздавать не образ, но именно этот самый Dockerfile с тем, что надо для его сборки. Это прекрасно сохраняется в любой системе контроля версий.
Самый странный способ неправильного использования docker, что я видел. Я бы не называл это «рецептом Docker» но анти-рецептом. Вместо вменяемого создания Dockerfile автор всю кастомизацию стандартных контейнеров делает через volumes. То, что после этого контейнер будет прибит гвоздями к именно этому хосту видимо его не волнует. Причина этих странных телодвижений видимо должна быть понятна из habrahabr.ru/post/267451, но я не в состоянии ее понять. Единственное, что я смог там увидеть, это ошибочная уверенность автора в том, что при обычном, вменяемом использовании контейнеров и расширения иx функциональности для себя конвенциональными способами, надо «заплатить за хранение на Docker Hub».
и да, с практической точки зрения вам надо использовать heartbeat, где можно задать для пула и частоту, и таймаут и все прочее (в java driver это heartbeatConnectRetryFrequency и прочие heartbeatConnectTimeout). Тогда зависший коннект не подвесит весь мир.
> потому что read тоже зависает. чтобы он не зависал при гибели мастера нужно чтобы он читал с secondary
это какая-то мистика. ReadPreference.SECONDARY_PREFERRED не значит, что «если мастер недоступен, то читать с slave», но значит, что мы всегда позволяем читать с него. Единственное, чему это поможет в смысле высокой доступности, что чтение будет доступно пока не закончились выборы нового мастера.
> зачем? мне интересна именно смерть инстанса а не смерть процесса.
Затем, что если остановка инстанса не закрывает коннект (я такое читал на их форуме) по причинам/особенностям организации сетевого стека AWS, то это тогда не про «монго не поняла / работает не так», но коннект не сбросился на стороне амазона, что относится к монго ровно настолько, насколько оно относится к любому приложению работающему с сокетами.
> Только это совсем не элементарно и не интуитивно понятно
А какого волшебного поведения вы в этой ситуации ожидали? Что произойдет что именно? На фоне отсутствия транзакций, такое поведение как раз вполне ожидаемо. Если хочется транзакций — ну так либо сделайте их сами, либо принимайте то, что в монге их нет и обеспечение целостности данных это задача приложения.
А зачем ReadPreference.SECONDARY_PREFERRED, как оно вообще относится к отказо-устойчивам write?
По поводу проблем подвисания коннекта, я советую попробовать вместо остановки инстанса в вашем тест убить процесс монги — результат может удивить. Я не на 100% уверен, т.к. с питоновым драйвером почти не общался, но у меня есть такое ощущение, что проблема вечного коннекта и неполучения отлупа это либо специфика AWS сетевой инфраструктуры, либо косяк в питоновом драйвере.
А что касается многократной записи и дупликатов — в относительно свежих версиях java драйвера есть поддержка retry policy, которая как раз для этого придумана. Ну и очевидно, что и без всякой поддержки в драйвере это решается элементарно, созданием DBObject (или что там вместо него в питоне) вне цикла, и запись с одним и тем же _id не пройдет.
По поводу выбора нового мастера за минуту — ни разу такого не видел, обычно это вопрос 2-5 секунд.
> Если через 5ть секунд драйвер PyMongo не получает от базы никакого ответа, то он сбрасывает соединение и выплевывает ошибку. Не самое классное решение — вдруг база перенагружена или запрос очень тяжелый и выполняется более 5ти секунд
Тут какая-то путаница. Эти 5 секунд не таймаут на запрос, но таймаут на коннект. И если запрос выполняется даже 10 минут, драйвер его не сбросит, во всяком случае нормально написанный драйвер.
Я бы скорее назвал статью «особенности питонового драйвера монги в AWS инфраструктуре», чем такое желтоватое как сейчас.
это, как мне кажется, не самый адекватный способ сравнения. Большое число реальных задач у меня требуют эластичной мощности и высокой доступности/надежности, и значит я могу арендовать эти мощности только тогда, когда они реально нужны. Для 24х7 есть RI, которые на 1/3 дешевле. И кроме того из за возможности гибко брать столько, сколько надо, плотность использования мощностей в AWS у меня получается значительно выше.
почему дороже? У нас, одна из целей переезда была уменьшить цену. В результате, сейчас плата за AWS несколько ниже (процентов на 20%) чем то, что мы платили за «голые» дата центры. При этом я не учитываю того, что в ДЦ надо было где-то покупать железо и сопровождать его и то, что у нас в AWS примерно в 2 раза больше мощностей. Ну и конечно, некоторые сервисы из тех, что мы сейчас активно используем, нам были просто недоступны на своем железе.
Короче говоря, трудно сравнить лоб-в-лоб, но по моим подсчетам нам жить в облаке обходится процентов на 50 дешевле.
Если бы говорим «как спастись от подобной потери» то, в определенных случаях, такой S3 для сырых данных и даже для «проваренных» бэкапов это хорошо, но мало, особенно в ситуации, когда накатывать обратно данные это долго, тяжело и дорого. Например, восстановление больших данных в монгу. При таком раскладе конечно иметь s3 бэкап для исходных данных и для дампов — это правильно на крайний случай (разрушена целостность, новая версия все сломала и т.п.), но гораздо более практично иметь реплику в нескольких зонах, где у каждого нода свой EBS том.
Если речь идет о ноде, который только обрабатывает данные, то даже для него не всегда возможна предложенная выше схема «берем все с S3 и туда же кладем». Для некоторых задач объектное хранилище не подходит, но может подойти dynamodb или RDS или, как в моем случае, монга.
Конечно данные можно реплицировать. Однако, в описанной катастрофе, это вероятно ничему бы не помогло т.к. была нарушена логическая целостность оригинала.
тут какая-то путаница — EBS никакого отношения к «компьютеру» не имеет. Это амазоновский способ подключать высоко-производительные блочные устройства к любым инстансам в зоне.
Никакого отношения с django у меня нет и задачи раздачи статики (как впрочем и раздачи чего угодно прочего) из S3 и/или через CDN я не решаю. S3 в качестве хранилища я, конечно, использую, но для моих систем идея использовать S3 для чего-то более другого чем относительно медленные склады объектов, не подходит совсем.
не уверен, что понимаю вопрос. Данные где-то хранить надо, и особого выбора тут нет — либо на EBS, либо где? Понятно, что определенные данные, например архивы, можно держать в S3, но без EBS никак не получится. Я себе с трудом представляю где еще, например, монго может свои данные хранить. Речь ведь не идет об instance storage? Там слово «хранить» неприменимо.
не факт. Снэпшоты это типа инкрементальных бэкапов, и видимо возможно получить поломанные снэпшоты если произошел сбой при создании первого, а они это проворонили. Вообще это чистой воды спекуляция, может быть еще дюжина теорий что именно пошло не так.
Физически все снэпшоты в AWS хранятся на S3, выбора хранить их на S3 или где-то еще нет. И нет, проблемы с AMI не было, с этого образа строилось много чего разного и всегда (до и после происшествия) успешно.
Что касается «нигде и никак не использовать EBS» – сейчас это практически невозможно. Большая часть новых типов инстансов EBS-only.
Я искренне не понимаю, как новая, видимо стабильная версия продукта, может прийти без одного из «встроенных» плагинов.
И при чем тут «когда приложение в hub»? Что мешает сделать build без хаба из своих исходных Dockerfile?
1. Официальные образы это всего лишь образы, никакой особой мистики в них нет. Они могут кому-то подойти «как-есть», кому-то послужить базовыми а кому-то как источник информации о том, как сделать нечто свое из них.
2. Когда мы собрали свой образ то ему можно сделать push. Но его вовсе не обязательно делать в публичный или даже приватный docker hub. Поднимаем docker-registry и пушим туда, как все нормальные люди, которым надо приватный репозиторий для докера.
3. Кроме того, когда сборка включает в себя все, что надо и Dockerfile является тем, чем он обычно является, ничего не мешает раздавать не образ, но именно этот самый Dockerfile с тем, что надо для его сборки. Это прекрасно сохраняется в любой системе контроля версий.
это какая-то мистика. ReadPreference.SECONDARY_PREFERRED не значит, что «если мастер недоступен, то читать с slave», но значит, что мы всегда позволяем читать с него. Единственное, чему это поможет в смысле высокой доступности, что чтение будет доступно пока не закончились выборы нового мастера.
> зачем? мне интересна именно смерть инстанса а не смерть процесса.
Затем, что если остановка инстанса не закрывает коннект (я такое читал на их форуме) по причинам/особенностям организации сетевого стека AWS, то это тогда не про «монго не поняла / работает не так», но коннект не сбросился на стороне амазона, что относится к монго ровно настолько, насколько оно относится к любому приложению работающему с сокетами.
> Только это совсем не элементарно и не интуитивно понятно
А какого волшебного поведения вы в этой ситуации ожидали? Что произойдет что именно? На фоне отсутствия транзакций, такое поведение как раз вполне ожидаемо. Если хочется транзакций — ну так либо сделайте их сами, либо принимайте то, что в монге их нет и обеспечение целостности данных это задача приложения.
По поводу проблем подвисания коннекта, я советую попробовать вместо остановки инстанса в вашем тест убить процесс монги — результат может удивить. Я не на 100% уверен, т.к. с питоновым драйвером почти не общался, но у меня есть такое ощущение, что проблема вечного коннекта и неполучения отлупа это либо специфика AWS сетевой инфраструктуры, либо косяк в питоновом драйвере.
А что касается многократной записи и дупликатов — в относительно свежих версиях java драйвера есть поддержка retry policy, которая как раз для этого придумана. Ну и очевидно, что и без всякой поддержки в драйвере это решается элементарно, созданием DBObject (или что там вместо него в питоне) вне цикла, и запись с одним и тем же _id не пройдет.
По поводу выбора нового мастера за минуту — ни разу такого не видел, обычно это вопрос 2-5 секунд.
> Если через 5ть секунд драйвер PyMongo не получает от базы никакого ответа, то он сбрасывает соединение и выплевывает ошибку. Не самое классное решение — вдруг база перенагружена или запрос очень тяжелый и выполняется более 5ти секунд
Тут какая-то путаница. Эти 5 секунд не таймаут на запрос, но таймаут на коннект. И если запрос выполняется даже 10 минут, драйвер его не сбросит, во всяком случае нормально написанный драйвер.
Я бы скорее назвал статью «особенности питонового драйвера монги в AWS инфраструктуре», чем такое желтоватое как сейчас.
Короче говоря, трудно сравнить лоб-в-лоб, но по моим подсчетам нам жить в облаке обходится процентов на 50 дешевле.
Если речь идет о ноде, который только обрабатывает данные, то даже для него не всегда возможна предложенная выше схема «берем все с S3 и туда же кладем». Для некоторых задач объектное хранилище не подходит, но может подойти dynamodb или RDS или, как в моем случае, монга.
Никакого отношения с django у меня нет и задачи раздачи статики (как впрочем и раздачи чего угодно прочего) из S3 и/или через CDN я не решаю. S3 в качестве хранилища я, конечно, использую, но для моих систем идея использовать S3 для чего-то более другого чем относительно медленные склады объектов, не подходит совсем.
Что касается «нигде и никак не использовать EBS» – сейчас это практически невозможно. Большая часть новых типов инстансов EBS-only.