Это очень трогательная история, но лучше поправить "в 2019 году люди женщина из Нью-Джерси", иначе сложно сопреживать пострадавшим венам. В тоже время, день начинается с хорошего настроения, спасибо!
В целом с Вами соглашусь, есть вещи, которые лучше не делать, потому что потом дороже разбираться. В любом случае, в обсуждаемых сценариях можно комбинировать разные подходы. Volumes табуировать тоже не стоит, просто надо понимать принципы работы AUFS, не забывать про uid/gid пользователей хост системы и контейнера. Так что, на мой взгляд, все сводится именно к осознанности в практике применения этих строительных блоков.
*повторение последнего предложения из предыдущего комментария*
Думаю, что для сценария CI/CD это достаточно удачное решение.
Например, если используется Jenkins и универсальный build контейнер для NodeJs приложений, то такому контейру очень выгодно иметь актуальный репозиторий без накладных расходов, которые непременно сопровождают npm.
Вообще, для production я не встречал предложений использовать какой-нибудь ng serve (Angular), сервер в этом режиме даже заботливо предупреждает о том, что так не стоит делать.
Исходя из этой логики, любое test/staging/prod окружение по-хорошему работает с (далее конкатенировать по степени важности) собранным, упакованным, перепакованным, оптимизированным, обфусцированным, минифицированным кодом. А значит, обсуждая npm/yarn/pnpm, логично предположить, что либо речь о перчисленных выше шагах, либо это сугубо локальное окружение.
Первый вариант выше уже подробно раскрыт, а во втором не так важно куда идти - к докеру или от него.
Опять же, можно прокидывать fs в докер, а можно держать image/контейнер, который использует преимущества pnpm и в случае image просто обнуляется собранный кэш, контейнер же позволяет инкрементально наращивать репозиторий.
И все ради благой цели - быстро и надежно доставлять код!
Огромная благодарность за данную статью.
И, так как мне по воле случая потребовалось написать похожее решение на Java, выкладываю ссылку.
Задача, правда, немного отличалась: было необходимо лишь организовать загрузку и сохранение XML.
Вместо работы с getLastDumpDate реализован цикл, сохраняющий результаты в файлы с цифровым инкрементом в названии.
Блокирования ресурсов не требовалось.
Сорсы там же, настройки в ".properties".
Вдруг кому-то пригодится.
Кстати, так же отмечу, что в формате RAW решается проблема с полями AUTO_INCREMENT, т.к. реплицируемые данные содержат точную информацию о содержимом полей, вставленных на master-ноде.
Т.е. id в нашем случае успешно реплицируются в Oracle, что не может не радовать.
p.s. думаю, для людей умных это не новость, но раз уж мы добрались до освещения данной темы, то расскажем обо всех чудесных и удивительных открытиях, а так же об изобретении колеса и восьми-битного байта. В общем, обо всем, с чем столкнулись и что пришлось гуглить :)
Добавлю, что бинлоги в формате Statement обрабатывать можно, но, учитывая, что это просто строка, реплицировать в БД, синтаксис которой хоть в чем-то отличается, уже проблематично.
К этому можно добавить iPhone/Android/etc… приложение.
И получить на выходе универсальное удобное и постепенно набирающее доверие (история операций incl) средство оплаты (в условиях MO-тарификации), think about it :)
Это очень трогательная история, но лучше поправить "в 2019 году люди женщина из Нью-Джерси", иначе сложно сопреживать пострадавшим венам. В тоже время, день начинается с хорошего настроения, спасибо!
Ну как бы да. Навскидку из имплементаций: https://github.com/AsyncHttpClient/async-http-client
Обсуждение потоков/асинхронного выполнения, когда bottleneck на уровне сети и опрашиваемой серверной части, вызывает много вопросов.
В целом с Вами соглашусь, есть вещи, которые лучше не делать, потому что потом дороже разбираться. В любом случае, в обсуждаемых сценариях можно комбинировать разные подходы. Volumes табуировать тоже не стоит, просто надо понимать принципы работы AUFS, не забывать про uid/gid пользователей хост системы и контейнера. Так что, на мой взгляд, все сводится именно к осознанности в практике применения этих строительных блоков.
*повторение последнего предложения из предыдущего комментария*
Думаю, что для сценария CI/CD это достаточно удачное решение.
Например, если используется Jenkins и универсальный build контейнер для NodeJs приложений, то такому контейру очень выгодно иметь актуальный репозиторий без накладных расходов, которые непременно сопровождают npm.
Вообще, для production я не встречал предложений использовать какой-нибудь ng serve (Angular), сервер в этом режиме даже заботливо предупреждает о том, что так не стоит делать.
Исходя из этой логики, любое test/staging/prod окружение по-хорошему работает с (далее конкатенировать по степени важности) собранным, упакованным, перепакованным, оптимизированным, обфусцированным, минифицированным кодом. А значит, обсуждая npm/yarn/pnpm, логично предположить, что либо речь о перчисленных выше шагах, либо это сугубо локальное окружение.
Первый вариант выше уже подробно раскрыт, а во втором не так важно куда идти - к докеру или от него.
Опять же, можно прокидывать fs в докер, а можно держать image/контейнер, который использует преимущества pnpm и в случае image просто обнуляется собранный кэш, контейнер же позволяет инкрементально наращивать репозиторий.
И все ради благой цели - быстро и надежно доставлять код!
И, так как мне по воле случая потребовалось написать похожее решение на Java, выкладываю ссылку.
Задача, правда, немного отличалась: было необходимо лишь организовать загрузку и сохранение XML.
Вместо работы с getLastDumpDate реализован цикл, сохраняющий результаты в файлы с цифровым инкрементом в названии.
Блокирования ресурсов не требовалось.
Сорсы там же, настройки в ".properties".
Вдруг кому-то пригодится.
Т.е. id в нашем случае успешно реплицируются в Oracle, что не может не радовать.
p.s. думаю, для людей умных это не новость, но раз уж мы добрались до освещения данной темы, то расскажем обо всех чудесных и удивительных открытиях, а так же об изобретении колеса и восьми-битного байта. В общем, обо всем, с чем столкнулись и что пришлось гуглить :)
И получить на выходе универсальное удобное и постепенно набирающее доверие (история операций incl) средство оплаты (в условиях MO-тарификации), think about it :)