Пока я только занимаюсь упражнениями. А что?

переносим сервера дяде

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

Ничего не думаю, т.к. впервые про него узнал. По Википедии впечатление хорошее.

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

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

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

Нарушаешь золотое правило один разработчик - один микросервис

Ну извини, не имею ресурсов кого-нибудь заставить пахать на свои упражнения даром :) Если бы они у меня были, то и работа была бы не нужна.

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

Если приложение работает штатно, то метрики и логи с него всё равно надо собирать (и чем больше, тем лучше).

А когда это разрастается дальше, то хочется что-то интереснее заббикса прикручивать, так как он слишком примитивен и не позволяет проследить какую-нибудь сложную транзакцию.

Как кто-то ниже писал, у MSA есть и плюсы и минусы, и вопросы типа RPC или «обычный» REST тут даже не в первой десятке по значимости.

Но мне нужно найти работу

Сколько лет ты уже не работаешь?

Тут YARN+Spark нужны

пагадика, это у нас тут что, сервис отпочковался? вай вай

в докер, к которому без костыля даже по SSH не подцепишься

милейший, разупоритесь!

ссх к хосту.

эта, за что, говоришь, тебя уволили...?

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

я смутно вспоминаю что мне мама в далеком детстве что-то рассказывала про логи, всякие грейлоги с графянями и проские сказки.

у меня база/сервер/приложение начали медленно отвечать и мне надо нос в лог засунуть?

пылесось логи в спец.логгер. elk, хрен с ним, в помощь. но руками.... в 21ом-то веке... стыдись.

В dev окружение докер ехать не должен, чтобы оттуда не докатиться до prod.

самое смешное, что именно обкатанный дев-образ 1:1 и должен ехать в прод ))

Всё уже решено.

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

Я уже давным-давно не использую чистый syslog. Для такого рода случаев syslog-ng с хранением логов в том же постгресе, это то, что доктор прописал. Порядка 200-300 физических серверов такой конфиг отрабатывает. Ну просто потому, что протоколируются только аварии-ошибки-отказы, а в нормальной системе их не должно быть в массе своей. Втаком случае поиск конкретных данных по логам это по своей сути просто sql-запрос в постгресе. Всё просто и надёжно. И да, syslog-ng от такой нагрузки не ложится.

Если приложение работает штатно, то метрики и логи с него всё равно надо собирать (и чем больше, тем лучше).

Был аналогичный случай. Помню. Один клован другого слова нет, написал некий демон. Демон обрабатывал файлы и много за сутки. Так этот дятел не стал гнать отладочную инфу в лог уровня debug (хотя, что мешало, уровень серьёзности дебаг для этого и предназначен?). Я бы это увидел и начал бы бухтеть и возбухать. Он ни чего лучшего не придумал, как писать статистику на каждый обработанный файл, просто в текстовый файл со статистикой за сутки. Чего там с памятью, сколько записей пришло-ушло и т.д. и т.п. Добросовестно к делу подошёл, скотина... Не отнять. =)))

Вот только сервак тот был боевой и он ни чего лучше не придумал как писать файлы в тот же каталог, который бы рабочим для демона. И это была не /tmp, а что-то от /. Сколько-то сервак проработал, лет несколько, все и забыли уже. Работает и работает. В результате, в один херовый день боевой сервак встал колом. Этот дятел забыл отключить свои говнологи. Ну да, квоты бы настроить, конечно, но кто бы мог подумать? Отродясь такого не было и вот опять...

Вот думаю, использовал бы этот клован syslog, всем было бы проще.

Так тоже бывает...

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

А на сервер мониторинга и оповещения у вас денег не хватило или просто так пожадничали?

Да ни кто и не думал...

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

Система «приработанная». Как реагировать на увеличение нагрузки или выход из строя серверного оборудования (когда добавлять железо) понятно. Но, как выясняется, иной раз не заскучать... =)

UPD. Отдельный мониторинг, типа «общая температура по больнице» там есть. Его вполне довольно как дополнение к syslog, где собираются данные об отказах. Но такую ситуацию навряд ли можно предугадать. Статистику заполненности файловой системы что ли ещё собирать? она там практически одинакова была, когда при эксплуатации смотрели.

В моём мире иметь дотошный мониторинг состояния железа, операционной системы, приложения и сервисов — это стандарт де-факто и синс куа нон. Соответственно ситуация должна была развиваться так: кто-то накосячил -> диск стал заполняться -> на 20% свободного места сработал warning с рассылкой email и отпиской в специальный чатик -> на 10% — то же самое + оповещение по смс. Всё, проблема исключена.

Да тут беда.

Мы же разработка. А админы, которые должны бдить за системами там свои и с нами не связаны. Там своя техподдержка. Вот все дружно и расслабились. Система в принципе качественно сделана, такие сюрпризы это реально нонсенс, а не норма.

Система на отладочных серваках отлаживается и вылизывается, в проде-то зачем? Мы же на реальных, пусть и устаревших данных систему в отладке грузим как финальное тестирование. Там, если косяки есть, всё вылезает. Я не знаю что его сподвигло на боевом серваке это делать.

В общем, epic obser.

Если не секрет, а чем вы занимаетесь? Если подводные ядерные взрывы рассчитываете, я понимаю, но ин да риал продакшен постоянно случаются разные неприятности. То внешний сервис отвалится (или начнёт тормозить в случайных местах, что даже хуже), то ддос какой случится или сертификаты протухнут, а может придут юристы насчёт GDPR поинтересоваться. Т.е. живая, взаимодействующая с внешним миром система в принципе не существует в режиме настроил и забыл. Она постоянно меняется и за ней нужен глаз да глаз.

Ну... Мы пишем софт. =)

Весьма часто для изолированных систем. Нет, ядерные взрывы не считаем, но статистики иной раз бывает ну очень много. И тут, в принципе, могут быть вопросы, но они как правило, связаны с какими-то внутренними вещами, а не с попытками НСД извне. Винчестера могут в рейдах посыпаться или нагрузка возрастает, желательно не упустить эти моменты. В этом плане у нас в чём-то проще. Но за качество софта по данному направлению (а есть и другие направления) могут спросить ну очень и очень жёстко. Поэтому каждый отказ это реально почти ЧП.

UPD. В неизолированной системе там да, там безопасность даже как таковая это не столько состояние, сколько процесс. И процесс постоянный.

Нет необходимости обёртывать результаты в json.

А в протоколе XML-RPC, не появляется необходимость данные в XML обертывать?

Ну для него - если Vuе то это только SPA, а если SPA то это развод лохов. Поэтому Vuе не нужен!!(Как я додумываю и фронт не нужен, да и GUI не нужен. Если этой логике следовать). Поэтому надо бек на микросервисах !!!, т.к. это развод лохов !!!.

И "да" и "нет".

А в протоколе XML-RPC, не появляется необходимость данные в XML обертывать?

В моём случае (я не зря уточняю что использую xmlrpc-c) это всёреализовано в пределах самой библиотеки. И там это выглядит намного более просто и естественно. Обмен по сети, кстати, тоже.

Пример, чтобы не быть голословным (взят из http://tldp.org/HOWTO/XML-RPC-HOWTO/xmlrpc-howto-c.html):

#include <stdio.h>
#include <xmlrpc.h>
#include <xmlrpc_client.h>

#define NAME       "XML-RPC getSumAndDifference C Client"
#define VERSION    "0.1"
#define SERVER_URL "http://xmlrpc-c.sourceforge.net/api/sample.php"

void die_if_fault_occurred (xmlrpc_env *env)
{
    /* Check our error-handling environment for an XML-RPC fault. */
    if (env->fault_occurred) {
        fprintf(stderr, "XML-RPC Fault: %s (%d)\n",
                env->fault_string, env->fault_code);
        exit(1);
    }
}

int main (int argc, char** argv)
{
    xmlrpc_env env;
    xmlrpc_value *result;
    xmlrpc_int32 sum, difference;
    
    /* Start up our XML-RPC client library. */
    xmlrpc_client_init(XMLRPC_CLIENT_NO_FLAGS, NAME, VERSION);
    xmlrpc_env_init(&env);

    /* Call our XML-RPC server. */
    result = xmlrpc_client_call(&env, SERVER_URL,
                                "sample.sumAndDifference", "(ii)",
                                (xmlrpc_int32) 5,
                                (xmlrpc_int32) 3);
    die_if_fault_occurred(&env);
    
    /* Parse our result value. */
    xmlrpc_parse_value(&env, result, "{s:i,s:i,*}",
                       "sum", &sum,
                       "difference", &difference);
    die_if_fault_occurred(&env);

    /* Print out our sum and difference. */
    printf("Sum: %d, Difference: %d\n", (int) sum, (int) difference);
    
    /* Dispose of our result value. */
    xmlrpc_DECREF(result);

    /* Shutdown our XML-RPC client library. */
    xmlrpc_env_clean(&env);
    xmlrpc_client_cleanup();

    return 0;
}

Как видите, всё просто и довольно прозрачно. По сути, если я знаю URL, вызываемый метод и типы аргументов, то тут и думать не нужно.

Где-то с начала февраля.

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

Чел в принципе всё правильно сделал. Логи должны быть настолько просты и надёжны, что упадут после всего. Т.е. после всех сетей, маунтов, постгресов - вместе с ОС и диском. В этом смысле ничего не может быть лучше текстовых файлов в рабочей директории службы. Единственное, он мог бы написать инструкцию с одной фразой «периодически чистить логи» или сделать автоматическое удаление логов старше определённого срока.

А заполнение диска должны были отслеживать соответствующие люди, думаю, что они обычно называются сисадмины. Они и виноваты.

Владимир

Вам «приземлиться» нужно, или искать «космодром».
У меня по жизни космодром, в моих проектах, а рабочая деятельность - стыдно и говорить.

PS: Селяви.

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

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

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

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

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

Это шутка?

В этом смысле ничего не может быть лучше текстовых файлов в рабочей директории службы.

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

Ну я уже молчу что нормальный демон, как правило, роняет свои привилегии до минимальных, так что в /sbin он ни чего не запишет, прав не хватит.

Но зачем тогда есть severity level == 7, он же debug, мне в принципе не ясно. Нахрен придумана централизованная система логов тут тоже не ясно тогда.

В общем, какая-то херня написана.

Я здесь скорее ради тусовки и сам не линуксоид, поэтому не знаю. Под офтопиком крайне редко возникало желание воспользоваться чем-то из штатных средств для чего-бы то ни было. Чем дальше от сделанного в МС, тем лучше. Если эти логи в линуксе работают хорошо, то тогда нужно ими пользоваться, конечно.

Бггг... Спасибо, посмешили...

Есть всякие судовые журналы и прочая. То, куда пишется достаточно много инфы.

Ну слава Богу что не начали рассказывать о том, что «есть книги, написанные кровью», содержащие обязательную к исполнению мудрость. Я лично таких три знаю. ОВУ (Обще-Воинские Уставы), ПДД и ПУЭ и ПТБ (правила устройства энергоустановок...). Но это мелочи.

Я, конечно, не знаю, как сейчас принято в хипсто-кругах, но в нормальном мире это так.

Т.е., #include <syslog.h> это так хипстерня развлекается? Спасибо, посмешили.

В общем, перед поиском работы я бы чего-нибудь про Линукс там почитал... Про протоколирование... Вдруг сгодится. =)))

А так-то да, удачи. И она Вам реально нужна. =)

А. Ясно.

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

Положим, у меня есть реализация (правда, древняя) для конвертации Events из оффтопика в syslog на онтопике в режиме онлайн. Ибо в сислог пишут все и всё. Даже циски, даже васяны. И держать две реализации систем протоколирования, это как минимум накладно. Дешевле винды заточить на трансфер её events в сислог. Там, в принципе, и немного работы-то. Когда-то на С++ было.

Сейчас даже не знаю заведётся код или нет, но когда-то это был единственный способ развести виндовый бардак и хоть как-то его упорядочить.

Я здесь скорее ради тусовки и сам не линуксоид, поэтому не знаю.

Лады.

Ну вы выудили из моего сообщения, за что зацепиться, оно там было. Но это лишь технические детали и только часть. Мне неинтересно играть в зацеплялки. Считайте, что вы победили, мне пофиг.

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

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

Да ладно Вам!

О какой «победе» может идти речь? Полно! Я без тени иронии это пишу.

Это Вам на заметку. Я-то это знаю и использую. А Вам же проще будет.

Удачи.

Владимир

У меня на работе субординация похожа на:
https://www.youtube.com/watch?v=FecC0ru8lbI Монолог из фильма Форест Гамп
И все Ok!

1)По мне так это «слишком сложно», в том же браузере на js эта функция (назовем ее json_rpc) пишется в 5 строк(обернуть данные(имя функции и параметры) в json, послать запрос, распарсить json в объект), и потом вызывается одной строкой.
2)А уж куда писать имя функции в url или json дело вкуса.

А ну тогда нестрашно. Это у тебя такой общий интерес ко всему новому?

Не. Пытаюсь угадать, что перспективно. Голанг вроде пока хорош. Во-первых, сам язык нравится, во-вторых, востребованность возросла за последние два года раз в 50. А микросервисы как бы к нему впридачу идут.

Ну тогда тебе будет сложно почувствовать торжество микросервисов. Ты постараешься съэкономить силы и переиспользовать код вынося его в библиотеки. Результатом будет странная конструкция из нескольких процессов и хттп вместо прямого вызова метода между ними.

А чем отличаются микросервисы от «нескольких процессов и хттп между ними»?

Вынесем за скобки все эти докеры и кубернетосы - они же являются только инфраструктурой.

а чем отличаются микросервисы от «нескольких процессов и хттп между ними»?

Контрактом на api. Независимостью реализации, версионирования и выкатки.

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

А что мешает иметь контракт на API и поддерживать его, невзирая на родственное происхождение самих сервисов?

А сам контракт на API ведь един? И развивается во времени. Значит, контракт на API, условно говоря, «с одного коммита». Неувязочка выходит.

Но я понимаю. Смысл микросервисов в установлении сословных отношений. Архитектор всегда один и он властвует, т.к. в его руках API. А вот исполнители, которые пишут сервисы, должны быть разделены, т.к. это плебс.

Т.е. вместо «вендор лок» получается только «архитектор лок».

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

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

Проблема что люди часто останавливаются на уровне «пучка сервисов» а потом удивляются почему у них сложность выкатки и оркестрации в том же kubernetes получается такой проблемной и «где же все эти бонусы модных технологий?»

Если контракт есть и фиксирован

Контракт фиксирован только в статичном мире. А реальные приложения развиваются. Контракт тоже не может не развиваться.

Api версионируется, и ты должен поддерживать старую и новую его версию, приложение должно уметь выбирать нужную.

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

Ну это-то как раз понятно. Допустим, в моём последнем легаси проекте, где я побыл типо архитектором, было где-то пару миллионов строк. Допустим, 80% из них - шелуха, а 20% - всё же ядро. Значит, там было 400.000 строк содержания. Если мы говорим «микро», то я думаю, в каждом микросервисе должно быть, ну, максимум 4000 строк содержания (и к ним ещё 4 раза по столько же шелухи, и того 20000 в сумме). Т.е. 400.000 строк / 4000 строк = 1000 микросервисов. Понятно, что если у нас есть 1000 каких-то элементов, то их не так легко собрать в работающий пазл.

Api версионируется, и ты должен поддерживать старую и новую его версию, приложение должно уметь выбирать нужную.

Я не про то, а про то, что у приложения всё же есть некая центральная точка, в которой всё получается зависимо.

Непонятно, почему ты решил что api один на всех. Вообще говоря его определяют на уровне сервиса. У такого-то сервиса такой-то api.

Архитектор тут скорее для определения юнитов работы нужен. То есть он должен разделить всю большую задачу на некоторые небольшие бизнес функции, каждая из которых идет отдельным микросервисом.

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

Если ты сделаешь 15 микросервисов, и окажется что им каждому приходится обновлять версию api несовместимым образом раз в неделю, то значит граница была выбрана неверно. И если это такая сырая, плохо структурированная область, возможно начать с пучка сервисов который надо релизить раз в неделю все одновременно будет дешевле.