• 0
    я не вижу никакой проблемы с мounted volumes. Изменения появляются сразу, без всяких костылей с NFS и прочим.
    Что такое dinghy или как ускорить docker
  • 0
    > В любом случае — это особенность, которая в «плюсы» точно не попадает.

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

    > если ждать загрузки страницы на локальной машине приходится по 15 секунд — это ужасно медленно

    Опять непонятно, какую именно проблему предложенное решения адресует. Телепатически могу догадаться, что речь идет о volumes (исходя из разных упоминаний NFS).

    > В комплекте идёт прокси — зачем же изобретать свой велосипед,
    Если это используется как среда для локальной разработки, то я могу (с трудом, но могу) представить пользу от подобного. Но если это использование для чего-то более близкого к тому, как докер используют в реальной жизни, то решать «проблему» портов вот этим велосипедом на настощем, боевом сервере — это не самая лушая идея. Для этого есть много разного, готового и проверенного в бою, что умеет делать динамическое проксирование нормальным образом.
    Что такое dinghy или как ускорить docker
  • +1
    > «В качестве слоя виртуализации он использует HyperKit. Недостаток — вы можете использовать только одну виртуальную машину.»

    Что-то я не понимаю, в чем суть этой «проблемы». Почему это вообще рассматривается как проблема? В реальном, боевом использовании, тоже будет «всего один докер на хосте», зачем такая пляска с бубном нужна на рабочей машине чтоб поднять их несколько?

    По поводу «ужасно медленный» — это про что вообще? Про доступ к хостовой FS? Если он «ужасно медленный» то где результаты того, как он станет «прекрасно быстрым», где бенчмарки подтверждающие это?

    Проблема нескольких контейнеров на одном порту — это вовсе не проблема докера и решать ее надо на уровне прокси, который часть вашей системы, а не добавлением магической надстройки над docker-machine.
    Что такое dinghy или как ускорить docker
  • +1
    у вас, какая-то очень особая точка зрения не факты. Вы уже 5 раз сказали про «393 доллара ЕЖЕМЕСЯЧНО» но упорно отказываетесь слышать, когда вам говорят что речь идет о «monthly premiums» и, обычно (практически всегда в области IT) 90%, а бывает и 100% платит работодатель.

    Что касается «зачем людям нужна государственная страховка Obamacare» — во первых, она не государственная. Во вторых, если вам кажется, что народ стоит в очередь за этой «государственной страховкой», то оно тоже не так.
    Путешествие за бугор и обратно: как не надо устраиваться работать за рубежом
  • +7
    это мне кажется просто классическим примером пожелания, нарушающего все идеи и все методы/подходы принятия решений об изменениях в этом языке. То, что такое предложения вообще возникло, скорее всего означает нарушение первого пункта («используй язык, набирай опыт»). Я не могу себе представить как кто-то, кто разрабатывает на Go предложит настолько радикально и калечаще поменять нечто, что совершенно не важно для тех, кто этот код на самом деле пишет. И тут подходим к нарушению второго пункта — а какую проблему это должно решить? Проблемы тут нет никакой, но есть «мне так приятней/привычней, и вообще — хочу как в питоне».
    На пути к Go 2
  • +1
    Какая-то, на мой взгляд, бесмысленная тема — «Кто первый сделал запускалку для своих продуктов». Сам смысл этих запускалок не особо ясен, ничего не мешает это сделать 33 другими способами, включая средства ОС и разные универсальные ланчеры типа Alfred. А тут это подается как достижение программистской мысли. Я сильно сомневаюсь, что есть живые люди которые выберут одну IDE вместо другой из за того, что там есть Launcher/Toolbox или нет. Этот фактор, лично для меня, не то что не в первой десятке причин для выбора, но даже и не в первой сотне.
    IntelliJ против Eclipse: JetBrains Toolbox или Yatta Launcher?
  • 0
    это не баг, но отсутствие очевидной фичи — https://gitlab.com/gitlab-org/gitlab-ce/issues/17801
    Вышел GitLab 8.15
  • 0
    назвать это гордо «интрументом» я бы не решиился. Там весь код это 50-60 строк определяющие структуру параметров, заворачивающие «templates» со всем, что человек туда положил в bindata и делающее по всем файлам в нем filepath.Walk с ExecuteTemplate. Могу, конечно, выложить, просто мне казалось это тривиальным.
    Микросервис на Golang
  • 0
    Я нежно люблю и активно исползьую gitlab и этот релиз мне нравится, однако приоритеты разработчиков иногда вводят в ступор. В 8.14 поломали совместимость со всеми текущими версиями git (точнее это git поломал, но результат от этого не меняется) и месяц было невозможно никому пушить в protected branch. Починка там была почти тривиальная, но по непостижимым для меня причинам она ждала 8.15, хотя просто просилась и кричала войти в скорейший, минорный релиз 8.14.х

    То, что авторы прокручивают новые свистелки — это конечнно хорошо, но то, что они стремительно теряют интерес к старым — это грустно. Месяца три как ждем элементарной починки для registry чтоб с ним наконец можно было работать, но нет — новые странные штуки появляются, а допилить то, что было выпущено несколько месяцев назад — никак.

    Вышел GitLab 8.15
  • +2
    насколько я вижу, у тебя это тоже типа middlware, но с нестандартной сигнатурой func(http.ResponseWriter, *http.Request) (http.ResponseWriter, *http.Request). Если поменять на func(h http.Handler) http.Handler то станет как у всех, и самое главное — ты сможешь использовать все подобные, готовые middlware без всяких модификаций.

    Общее замечание: в принципе, идея создания фреймоврка такого рода мнe кажется делом сомнительным. Во первых, есть неплохие и проверенные боем библиотеки, которые это уже делают основнию часть, например chi. Во вторых — идея добавления туда и конфигурации и еще чего мне не кажется полезной. Да, я понимаю, что при создании сервиса хочется упростить начальные телодвижения, однако лично я пошел по другому пути и написал простой кодо-генератор, который делает рабочий скелет приложения с chi, набором middlware для него (у меня в каждом сервисе надо определенный набор, например JWT), логгером, main с флагами и env (github.com/jessevdk/go-flag) перехватчик сигналов и еще по мелочи. Кроме того, оно генерит не только исходный текст, но и все, что надо для сборки и деплоя (Dockerfile, CI yml, ansible yml)
    Микросервис на Golang
  • 0
    в очередь я вкладываю понимание, что это queue куда кладут, в общем случае, данные. Кладут и достают последовательно. Конечно, очередь можно использовать мнoго для чего разного, например RPC, но насколько я понимаю, в статье не об этом речь. Конвейер, в моем понимании, это последовательность функциональных шагов для обработки неких данных.

    Для термина middleware в го мире есть довольно четкое соглашение, что это такое, и что люди под этим подразумевают, особенно в контексте http обработок. Например вот это https://github.com/pressly/chi/tree/master/middleware

    по поводу транслятора — по моему мнению лучше это поменять на оригинал до прогона через перводчик. То, что там читать трудно, а понять — невозможно.
    Микросервис на Golang
  • +3
    Удивительно непонятное описание продукта, просто исключительно странное. Даже мое понимание области в которой автор копает, не вносит ясности. Термины используется так, как я нигде не видел. Видимо очередь это не очередь а конвейер? И что за storage, для чего, куда и почему его основное достоинство это авто–дополнение в IDE? Хотя, похоже и storage это не то, что все под этим понимают, т.к. в нем автор предлагает хранить (?) middleware про которое я тоже уже не уверен, что это такое у автора и зачем его там хранить.

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

    Я не для придирок или прочих издевательств, но в попытке понять о чем это было вообще и как оно относится к микросервисам в частности.

    Микросервис на Golang
  • 0
    У меня к вендорингу есть свои претензии, но похоже, что вы называете этим слово что-то такое, что не относится к обычному, появившимся еще в версии 1.5. С этим вендорингом все IDE и продвинутые редакторы работают как должно. Вопрос «каким вендорингом вы пользовались» заставил меня даже посмотреть на дату сообщения — сейчас есть единый и неповторимый vendor, который понимают все тулзы и все IDE и который не требует переписывания импортов.

    Эту часть «хочу работать попроектно (вендоринг), что в каждом проекте был repeatable build (нестандартный вендоринг)» я не понял вообще. Как попроектно относится к вендорингу? Если речь идет о том, что вы хотите все свои зависимости завендорить — ну так они ничем не отличаются от внешних зависимостей и положив их в vendor вы добьетесь repeatable build без всяких плясок и усилий. И «форкнуть какую-нибудь популярную либ, изменить её и использовать мой форк» тоже не проблема. Форкаем, меняем, кладем в vendor.

    «хочу, чтобы моя IDE не была на Java и работала быстро» — и чтоб синенького цвета? Если надо именно IDE то выбора особого нет, только на java. Если надо продвинутый редактор с пониманием Go – то таких есть штук пять.

    «ещё хочу не только билдить локально, но и деплоить на тестовый сервер по нажатию кнопки в IDE» — а это для Go делается каким-то особым и сложным способом? Я не знаю, какой уровень волшебства вы ожидаете, но у меня вообще ничего не надо нажимать и все это делается по коммиту. Ну и в IDE как и в редакторах это делается десятком разным плагинов, на любой вкус.

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

    Языку программирования Go — семь лет
  • +18
    Добавлю, что кроме ложной уверенности, это еще и набор вредных и весьма опасных практик, собранный в одном флаконе. Кроме того, что оно должно запускаться под root, оно еще смело загружает по http черт знает что из интернета и потом запускает под тем же самым рутом.

    Скрипт для тех, кому лень разбираться в Linux
  • 0
    Ну это ведь о другом. У меня тоже ansible используется из контейнера по понятным причинам — все зависимости, что ему нужны там, все скрипты и все ключи доступны и прочее. Тут ansible просто еще одна докерезированная штука которая мало отличается от любого другого сервиса. Мой комментарий относился к идее запускать плейбук и в самом docker контейнере для инициализации/создания этого контейнера и именно такой кейс я назвал диковинным.
    Ansible-container: новый шаг в управление контейнерами
  • +1
    идея запускать плейбук и в самом docker контейнере мне кажется еще более … диковинной, мягко говоря. Если вдруг по каким-то, совершенно непонятным мне причинам, хочется делать такие странные, полуготовые и мутабельные докер контейнеры и деплоить внутрь код с помощью ansible, то совсем непонятно зачем тут docker вообще, и почему бы не делать это прямо на хост.

    > полагаю, что идея(использования ansible-container) приобретает ценность, когда при помощи ansible-container производится только сборка и push в registry

    С трудом могу себе представить эту ценность. Возможно, для этого нужны какие-то совсем дикие многофункциональные контейнеры, которые муторно и сложно описать обычным образом, но мне это видится кривой дорогой — я за контейнер-на-сервис, а не контейнер-как-легкая-vm.
    Ansible-container: новый шаг в управление контейнерами
  • 0
    Dockerfile примерно такой же «shell-script» как и ансибловый yaml. Ну да, там в RUN пиши что надо, но примерно с тем же успехом можно сказать, что и ansible это такой «shell-script» с ssh запускалкой.

    Короче, как по мне, так очень странная затея. Понятно, почему это надо ansible, но как (а главное зачем) этим будут пользоваться живые люди я все еще не могу понять. Мотивация «этот язык описания мне нравится больше» мне кажется какой-то неубедительной для введения такого сомнительного велосипеда в свой процесс построения контейнеров.
    Ansible-container: новый шаг в управление контейнерами
  • +4
    Что-то я упускаю прелесть этой идеи. В моем понимании построение контейнера, это часть построения сервиса/программы, которое создает артифакты в виде docker image и пушит, и все это происходит в CI системе и, строго говоря, никакого отношения к asnible не имеет. Именно тут нужен Dockerfile, и он нужен на уровне сервиса а не на уровне композа, т.е. каждый сервис строится со своим собственным Dockerfile и никакой зависимости с прочими частями, типа nginx ему не надо.

    Сам деплоймент никакого отношения к этим Dockerfile не имеет, он их даже не видит. Все, что ему надо это docker-compose.yml в котором прописано все сервисы, порты, зависимости и прочее. Это (деплоймент) можно делать с помощью ansible (я так и делаю) но никакой хитрости для этого не надо, просто доставить compose файл плюс что надо еще (конфиги, например) и дернуть docker-compose.

    В какой модели удобно использовать подход описанный здесь, я не могу себе представить. Это если строить на боевом сервер контейнер? И в этом, странном случае, это можно делать с помощью compose. Единственный, но на мой взгляд сомнительный, плюс это разбиение на роли для сборки образов, но я не очень вижу зачем, например dumb-init иметь в виде роли, но не базовым контейнером.

    Кроме того, реализация своего сборщика, это дело муторное и требующее постоянной гонки за обновлениями docker. Даже они сами не поспевают с этим, и compose иногда обновляется сильно позже чем та или иная фича добавилась в докер. А тут теперь надо будет ждать пока и ansible это добавит.
    Ansible-container: новый шаг в управление контейнерами
  • 0
    ну, строго говоря, мы тут и так городим свой entrypoint.sh. Без особого труда тут можно сделать и какой sed для автоматической замены SHELL на то, что надо, и больше об этом не думать.
    Запуск cron внутри Docker-контейнера
  • 0
    откуда, в моем примере, следует что данные надо скачивать и именно в файловую систему? Даже если и речь идет о подобных данных, то есть масса случаев когда они не персистент и это ответственность сервиса/контейнера их себе добыть. Это никак не ухудшает переносимость. Однако, в случаях когда данные прокидываются, тоже есть большая разница откуда вызывать скрипт. Если это скрипт (хотя я про скрипты ничего не говорил) делает нечто, что часть вашего сервиса, то его оторванность от вашего сервиса это совсем не тоже самое, как технически так и концептуально. И идея запускать это нечто на хосте, означает, что хост к такому должен быть подготовлен, что непонятно зачем надо. Ну и перенести это все просто средствами докера будет невозможно, т.к. часть работы делает внешний скрипт.

    Есть много случаев, когда задачи по расписанию чего-то в контейнере – это его внутреннее дело. Например, есть микросервис, который раз в день берет немного данных из внешнего мира, парсит их и вносит новые в некий store, специально для этого сервиса существующий. А все остальное время этот сервис отдает данные по запросам. Мониторинг к этому всему слабо относится — т.е. он никак не мешает мониторить как процесс так и конечное состояние.
    Запуск cron внутри Docker-контейнера
  • +1
    cron бежит со своим окружением. это не специфика контейнера/докера, но крона
    Запуск cron внутри Docker-контейнера
  • 0
    помочь в каком случае? передать env в контейнер это не проблема, проблема – как передать env в cron
    Запуск cron внутри Docker-контейнера
  • 0
    по поводу плясок вокруг «как крону передать env» — по моему можно несколько проще. В entrypoint сделать export > env.file а в кроне, в качестве SHELL, дать скрипт, который первым делом этот env.file применит.
    Запуск cron внутри Docker-контейнера
  • +3
    В отличии от комментаторов выше, я не вижу ничего странного в том, что в контейнере запускается нечто по расписанию. На мой взгля, во многих случаях это вовсе не «пытаются использовать его как виртуальную машину» и никак не противоречит мифической «документации по docker». Если, например, внутри контейнера живет процесс которому надо по расписанию нечто активировать, например обновить какие данные, нечто очистить/загрузить и прочее в этом роде, то дернуть процесс (сигналом либо каким прочим вызовом) из контейнерного крона вполне нормально, Идея делать это с хостовой машины — это, как мне кажется, совсем плохая идея, убивающая переносимость и прибивающая конкретный контейнер к конкретному инстансу ржавыми гвоздями.

    Нет никакой особой разницы как именно генерируется этот «специальный сигнал по времени» внутри контейнера. Можно прикрутить нечто прямо в процесс сервиса если есть такое религиозное неприятие к второму процессу, но оно ничем не лучшее обычного крона.
    Запуск cron внутри Docker-контейнера
  • +2
    Предположение о том, что это такой особый, американский путь переговоров — оно не совсем верное. Т.е. может кто-то тут так и делает, начитавшись подобных… рекомендаций, однако во всех 3х компания, где я набирал людей, вопрос о компенсации и я и мои коллеги всегда прямо задавали кандидату. И это вопрос на который кандидат должен уметь ответить. Он может назвать и нечто, что за пределами бюджета, тогда я пытался понять насколько ему именно такая сумма важна и можем ли мы сойтись на компромиссе или убеждал тех, кто дает бюджет его скорректировать. Иногда бывало и наоборот, когда кандидат просит меньше чем мне кажется адекватным для его позиции и его опыта, и тогда я прямо ему об этом говорил и предлагал больше. Однако, ни одного случая когда человек вообще упирался и не говорил, сколько он хочет, у меня не было. А если бы был, то я бы попрощался с таким «умником» который либо не в состоянии принять решение, либо достаточно глуп чтоб слепо следовать подобным этой рекомендациям.

    Переговоры о зарплате — как не прогореть
  • +4
    меня вовсе не "бомбит", однако я подозреваю, что определенная неграмотность замечания и вызвала то, что ты видишь. Совсем непонятно о чем это ты говорил, если про write concern который в какой-то древней версии несколько лет назад был по умолчанию самый низкий — ну это вполне понятно удивляет некоторой… неактуальностью. Кроме того "не гарантировала strong consistency" видимо подразумевает что сейчас оно это гарантирует? Тут тоже много удивлений может быть вызвано у читателя, т.к. во первых там все не так прямо, а во вторых речь идет о продукте, который eventually consistent с разной степенью этой "eventually".
    За и против: Когда стоит и не стоит использовать MongoDB
  • +3
    Если уж предлагать подобный метод «нажми кнопки не понимая что делаешь» то проще делать с spring-boot. Останется такая-же магия для новичков, но хотя бы меньше писать и никаких бубнов «как мне поднять томкат в IDEA» и прочих ненужных телодвижений.

    Вот тут они показывают простой и короткий пример — docs.spring.io/spring-boot/docs/current/reference/html/getting-started-first-application.html
    Веб-платформа на Java за 30 минут
  • +3
    Я ничего не имею против Acronis True Image 2016 и Acronis True Image Cloud. Однако, утверждение что они "… позволяют делать резервное копирование данных с учётом всех вышеперечисленных советов и рекомендаций", и идея, что встроенный в ОС TM это то, чему «не стоит полностью доверять» и всего лишь «вспомогательный бэкап-инструмент», а ваш продукт то, чему стоит — мне кажется маркетинговым… преувеличением. Я не знаю вашего продукта, и необходимости его знать у меня нет, однако, я сильно сомневаюсь в его идеальности. Не потому, что вы программы писать не умеете, а потому, что никто не умеет писать идеальные программы.

    Совет «пользуйтесь только нашими продуктами» — это очень плохой совет. Привязать бэкапы к единому стороннему поставщику — это очень плохая идея.

    Что касается практических рекомендаций от меня (для дома) — делать бэкап TM на два устройства (локальный диск и nas) и завести альтернативный бэкап в облако (я для этого пользую arq).
    11 ошибок ваших бэкапов
  • 0
    Возможно ваше решение очень крутое и вообще новое слово, но ваша активность затянуть меня в свою секту граничит со спамом. Я никогда не подписывался на этот Bluemix, но вы спамите меня с разными «Hi there (almost) Bluemixer ...» через день.
    IBM упрощает разработку программного обеспечения в облаке с помощью платформы Bluemix
  • 0
    поправка самому себе — свежий плагин для питона таки есть, он просто не обновлялся от версии 4.чего.то.там то 5 пока я не переустановил его. Так что все не так плохо как казалось.
    Вышел JetBrains Toolbox со всеми обновленными десктопными продуктами
  • 0
     А IDEA 15 для которой нет совместимого с ней питона, это действительно называется «обновленная версия»? Или просто забыли обновить до конца? Или я что-то совсем не так понял? Или теперь стабильные версии это как раньше были EAP?
    Я искренне не понимаю, как новая, видимо стабильная версия продукта, может прийти без одного из «встроенных» плагинов.
    Вышел JetBrains Toolbox со всеми обновленными десктопными продуктами
  • +3
    у меня нет вопросов и я знаю ответы. Единственная цель моих комментариев это оградить незрелые в докер умы, от вредных советов.
    Рецепты Docker: Monkey patch, часть третья
  • +2
    хмм, это как минимум «неспортивно» редактировать свой ответ после того, как на него пришел комментарий. Я даже удивлен что хабр такое позволяет. И нет, «и каждому нужен репозиторий» это ерунда. Ну на самом деле, стоит почитать про docker registry а не придумывать себе что оно такое и станет понятно, что он нужен один, а не на приложение.
    Рецепты Docker: Monkey patch, часть третья
  • +5
    Я дал ссылку на docker-registry, за него не надо ничего платить. То, что вы показали это их сервис для корпораций. По моей ссылке есть простая и ясная инструкция, как поднять registry у себя. Ну вот еще одна, которая прямо так и называется «Deploying a registry server».

    И при чем тут «когда приложение в hub»? Что мешает сделать build без хаба из своих исходных Dockerfile?
    Рецепты Docker: Monkey patch, часть третья
  • +5
    А теперь как оно на самом деле:

    1. Официальные образы это всего лишь образы, никакой особой мистики в них нет. Они могут кому-то подойти «как-есть», кому-то послужить базовыми а кому-то как источник информации о том, как сделать нечто свое из них.
    2. Когда мы собрали свой образ то ему можно сделать push. Но его вовсе не обязательно делать в публичный или даже приватный docker hub. Поднимаем docker-registry и пушим туда, как все нормальные люди, которым надо приватный репозиторий для докера.
    3. Кроме того, когда сборка включает в себя все, что надо и Dockerfile является тем, чем он обычно является, ничего не мешает раздавать не образ, но именно этот самый Dockerfile с тем, что надо для его сборки. Это прекрасно сохраняется в любой системе контроля версий.
    Рецепты Docker: Monkey patch, часть третья
  • +7
    Самый странный способ неправильного использования docker, что я видел. Я бы не называл это «рецептом Docker» но анти-рецептом. Вместо вменяемого создания Dockerfile автор всю кастомизацию стандартных контейнеров делает через volumes. То, что после этого контейнер будет прибит гвоздями к именно этому хосту видимо его не волнует. Причина этих странных телодвижений видимо должна быть понятна из habrahabr.ru/post/267451, но я не в состоянии ее понять. Единственное, что я смог там увидеть, это ошибочная уверенность автора в том, что при обычном, вменяемом использовании контейнеров и расширения иx функциональности для себя конвенциональными способами, надо «заплатить за хранение на Docker Hub».

    Рецепты Docker: Monkey patch, часть третья
  • 0
    и да, с практической точки зрения вам надо использовать heartbeat, где можно задать для пула и частоту, и таймаут и все прочее (в java driver это heartbeatConnectRetryFrequency и прочие heartbeatConnectTimeout). Тогда зависший коннект не подвесит весь мир.
    Почему не все так просто с MongoDB
  • 0
    > потому что read тоже зависает. чтобы он не зависал при гибели мастера нужно чтобы он читал с secondary

    это какая-то мистика. ReadPreference.SECONDARY_PREFERRED не значит, что «если мастер недоступен, то читать с slave», но значит, что мы всегда позволяем читать с него. Единственное, чему это поможет в смысле высокой доступности, что чтение будет доступно пока не закончились выборы нового мастера.

    > зачем? мне интересна именно смерть инстанса а не смерть процесса.

    Затем, что если остановка инстанса не закрывает коннект (я такое читал на их форуме) по причинам/особенностям организации сетевого стека AWS, то это тогда не про «монго не поняла / работает не так», но коннект не сбросился на стороне амазона, что относится к монго ровно настолько, насколько оно относится к любому приложению работающему с сокетами.

    > Только это совсем не элементарно и не интуитивно понятно

    А какого волшебного поведения вы в этой ситуации ожидали? Что произойдет что именно? На фоне отсутствия транзакций, такое поведение как раз вполне ожидаемо. Если хочется транзакций — ну так либо сделайте их сами, либо принимайте то, что в монге их нет и обеспечение целостности данных это задача приложения.

    Почему не все так просто с MongoDB
  • +1
    А зачем ReadPreference.SECONDARY_PREFERRED, как оно вообще относится к отказо-устойчивам write?

    По поводу проблем подвисания коннекта, я советую попробовать вместо остановки инстанса в вашем тест убить процесс монги — результат может удивить. Я не на 100% уверен, т.к. с питоновым драйвером почти не общался, но у меня есть такое ощущение, что проблема вечного коннекта и неполучения отлупа это либо специфика AWS сетевой инфраструктуры, либо косяк в питоновом драйвере.

    А что касается многократной записи и дупликатов — в относительно свежих версиях java драйвера есть поддержка retry policy, которая как раз для этого придумана. Ну и очевидно, что и без всякой поддержки в драйвере это решается элементарно, созданием DBObject (или что там вместо него в питоне) вне цикла, и запись с одним и тем же _id не пройдет.

    По поводу выбора нового мастера за минуту — ни разу такого не видел, обычно это вопрос 2-5 секунд.

    > Если через 5ть секунд драйвер PyMongo не получает от базы никакого ответа, то он сбрасывает соединение и выплевывает ошибку. Не самое классное решение — вдруг база перенагружена или запрос очень тяжелый и выполняется более 5ти секунд

    Тут какая-то путаница. Эти 5 секунд не таймаут на запрос, но таймаут на коннект. И если запрос выполняется даже 10 минут, драйвер его не сбросит, во всяком случае нормально написанный драйвер.

    Я бы скорее назвал статью «особенности питонового драйвера монги в AWS инфраструктуре», чем такое желтоватое как сейчас.
    Почему не все так просто с MongoDB