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

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

umputun
+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)
umputun
0
в очередь я вкладываю понимание, что это queue куда кладут, в общем случае, данные. Кладут и достают последовательно. Конечно, очередь можно использовать мнoго для чего разного, например RPC, но насколько я понимаю, в статье не об этом речь. Конвейер, в моем понимании, это последовательность функциональных шагов для обработки неких данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я бы скорее назвал статью «особенности питонового драйвера монги в AWS инфраструктуре», чем такое желтоватое как сейчас.
umputun
0
это, как мне кажется, не самый адекватный способ сравнения. Большое число реальных задач у меня требуют эластичной мощности и высокой доступности/надежности, и значит я могу арендовать эти мощности только тогда, когда они реально нужны. Для 24х7 есть RI, которые на 1/3 дешевле. И кроме того из за возможности гибко брать столько, сколько надо, плотность использования мощностей в AWS у меня получается значительно выше.
umputun
0
почему дороже? У нас, одна из целей переезда была уменьшить цену. В результате, сейчас плата за AWS несколько ниже (процентов на 20%) чем то, что мы платили за «голые» дата центры. При этом я не учитываю того, что в ДЦ надо было где-то покупать железо и сопровождать его и то, что у нас в AWS примерно в 2 раза больше мощностей. Ну и конечно, некоторые сервисы из тех, что мы сейчас активно используем, нам были просто недоступны на своем железе.

Короче говоря, трудно сравнить лоб-в-лоб, но по моим подсчетам нам жить в облаке обходится процентов на 50 дешевле.
umputun
0
Если бы говорим «как спастись от подобной потери» то, в определенных случаях, такой S3 для сырых данных и даже для «проваренных» бэкапов это хорошо, но мало, особенно в ситуации, когда накатывать обратно данные это долго, тяжело и дорого. Например, восстановление больших данных в монгу. При таком раскладе конечно иметь s3 бэкап для исходных данных и для дампов — это правильно на крайний случай (разрушена целостность, новая версия все сломала и т.п.), но гораздо более практично иметь реплику в нескольких зонах, где у каждого нода свой EBS том.

Если речь идет о ноде, который только обрабатывает данные, то даже для него не всегда возможна предложенная выше схема «берем все с S3 и туда же кладем». Для некоторых задач объектное хранилище не подходит, но может подойти dynamodb или RDS или, как в моем случае, монга.
umputun
0
Конечно данные можно реплицировать. Однако, в описанной катастрофе, это вероятно ничему бы не помогло т.к. была нарушена логическая целостность оригинала.