в очередь я вкладываю понимание, что это queue куда кладут, в общем случае, данные. Кладут и достают последовательно. Конечно, очередь можно использовать мнoго для чего разного, например RPC, но насколько я понимаю, в статье не об этом речь. Конвейер, в моем понимании, это последовательность функциональных шагов для обработки неких данных.

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

по поводу транслятора — по моему мнению лучше это поменять на оригинал до прогона через перводчик. То, что там читать трудно, а понять — невозможно.

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

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

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

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

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

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

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

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

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

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

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

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

С трудом могу себе представить эту ценность. Возможно, для этого нужны какие-то совсем дикие многофункциональные контейнеры, которые муторно и сложно описать обычным образом, но мне это видится кривой дорогой — я за контейнер-на-сервис, а не контейнер-как-легкая-vm.

Dockerfile примерно такой же «shell-script» как и ансибловый yaml. Ну да, там в RUN пиши что надо, но примерно с тем же успехом можно сказать, что и ansible это такой «shell-script» с ssh запускалкой.

Короче, как по мне, так очень странная затея. Понятно, почему это надо ansible, но как (а главное зачем) этим будут пользоваться живые люди я все еще не могу понять. Мотивация «этот язык описания мне нравится больше» мне кажется какой-то неубедительной для введения такого сомнительного велосипеда в свой процесс построения контейнеров.

Что-то я упускаю прелесть этой идеи. В моем понимании построение контейнера, это часть построения сервиса/программы, которое создает артифакты в виде docker image и пушит, и все это происходит в CI системе и, строго говоря, никакого отношения к asnible не имеет. Именно тут нужен Dockerfile, и он нужен на уровне сервиса а не на уровне композа, т.е. каждый сервис строится со своим собственным Dockerfile и никакой зависимости с прочими частями, типа nginx ему не надо.

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

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

Кроме того, реализация своего сборщика, это дело муторное и требующее постоянной гонки за обновлениями docker. Даже они сами не поспевают с этим, и compose иногда обновляется сильно позже чем та или иная фича добавилась в докер. А тут теперь надо будет ждать пока и ansible это добавит.

ну, строго говоря, мы тут и так городим свой entrypoint.sh. Без особого труда тут можно сделать и какой sed для автоматической замены SHELL на то, что надо, и больше об этом не думать.

откуда, в моем примере, следует что данные надо скачивать и именно в файловую систему? Даже если и речь идет о подобных данных, то есть масса случаев когда они не персистент и это ответственность сервиса/контейнера их себе добыть. Это никак не ухудшает переносимость. Однако, в случаях когда данные прокидываются, тоже есть большая разница откуда вызывать скрипт. Если это скрипт (хотя я про скрипты ничего не говорил) делает нечто, что часть вашего сервиса, то его оторванность от вашего сервиса это совсем не тоже самое, как технически так и концептуально. И идея запускать это нечто на хосте, означает, что хост к такому должен быть подготовлен, что непонятно зачем надо. Ну и перенести это все просто средствами докера будет невозможно, т.к. часть работы делает внешний скрипт.

Есть много случаев, когда задачи по расписанию чего-то в контейнере – это его внутреннее дело. Например, есть микросервис, который раз в день берет немного данных из внешнего мира, парсит их и вносит новые в некий store, специально для этого сервиса существующий. А все остальное время этот сервис отдает данные по запросам. Мониторинг к этому всему слабо относится — т.е. он никак не мешает мониторить как процесс так и конечное состояние.

cron бежит со своим окружением. это не специфика контейнера/докера, но крона

помочь в каком случае? передать env в контейнер это не проблема, проблема – как передать env в cron

по поводу плясок вокруг «как крону передать env» — по моему можно несколько проще. В entrypoint сделать export > env.file а в кроне, в качестве SHELL, дать скрипт, который первым делом этот env.file применит.

В отличии от комментаторов выше, я не вижу ничего странного в том, что в контейнере запускается нечто по расписанию. На мой взгля, во многих случаях это вовсе не «пытаются использовать его как виртуальную машину» и никак не противоречит мифической «документации по docker». Если, например, внутри контейнера живет процесс которому надо по расписанию нечто активировать, например обновить какие данные, нечто очистить/загрузить и прочее в этом роде, то дернуть процесс (сигналом либо каким прочим вызовом) из контейнерного крона вполне нормально, Идея делать это с хостовой машины — это, как мне кажется, совсем плохая идея, убивающая переносимость и прибивающая конкретный контейнер к конкретному инстансу ржавыми гвоздями.

Нет никакой особой разницы как именно генерируется этот «специальный сигнал по времени» внутри контейнера. Можно прикрутить нечто прямо в процесс сервиса если есть такое религиозное неприятие к второму процессу, но оно ничем не лучшее обычного крона.

нет, не было таких.

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

меня вовсе не "бомбит", однако я подозреваю, что определенная неграмотность замечания и вызвала то, что ты видишь. Совсем непонятно о чем это ты говорил, если про write concern который в какой-то древней версии несколько лет назад был по умолчанию самый низкий — ну это вполне понятно удивляет некоторой… неактуальностью. Кроме того "не гарантировала strong consistency" видимо подразумевает что сейчас оно это гарантирует? Тут тоже много удивлений может быть вызвано у читателя, т.к. во первых там все не так прямо, а во вторых речь идет о продукте, который eventually consistent с разной степенью этой "eventually".

в каком месте он ультрасовременный? Когда я покупал свой ящик несколько лет назад, эта (или очень похожая) "ультрасовременная" модель была уже давно доступна. И почему "конкретно — пистолета", откуда взялось это странное ограничение? Мне никто не мешает там держать револьвер.

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

Если уж предлагать подобный метод «нажми кнопки не понимая что делаешь» то проще делать с spring-boot. Останется такая-же магия для новичков, но хотя бы меньше писать и никаких бубнов «как мне поднять томкат в IDEA» и прочих ненужных телодвижений.

Вот тут они показывают простой и короткий пример — docs.spring.io/spring-boot/docs/current/reference/html/getting-started-first-application.html

Я ничего не имею против Acronis True Image 2016 и Acronis True Image Cloud. Однако, утверждение что они "… позволяют делать резервное копирование данных с учётом всех вышеперечисленных советов и рекомендаций", и идея, что встроенный в ОС TM это то, чему «не стоит полностью доверять» и всего лишь «вспомогательный бэкап-инструмент», а ваш продукт то, чему стоит — мне кажется маркетинговым… преувеличением. Я не знаю вашего продукта, и необходимости его знать у меня нет, однако, я сильно сомневаюсь в его идеальности. Не потому, что вы программы писать не умеете, а потому, что никто не умеет писать идеальные программы.

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

Что касается практических рекомендаций от меня (для дома) — делать бэкап TM на два устройства (локальный диск и nas) и завести альтернативный бэкап в облако (я для этого пользую arq).