как код попадает на сервер?

разные сервера есть же - есть дев, есть прод, там совсем разные геморрои по аппруву тикета на прод могут быть например

ок, докер. В какой момент в докере? При каждом старте контейнера?

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

А как у кого выглядит деплой приложения. Вот ты допилил фичу, прогнал тесты, все ок. Что дальше? Как на прод? Не ручками же собирать, заливать и перезапускать?

Глянь еще jenkins

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

ок, докер. В какой момент в докере? При каждом старте контейнера?

у меня по колхозному, без си-аев. поэтому по команде "докер-композ, дружок, собери теперь вот это вот все на проде"

Вытягивал, тесты прогонял, обновлял прод тебе и т.д.

у меня по колхозному, без си-аев. поэтому по команде "докер-композ, дружок, собери теперь вот это вот все на проде"

простейший сиай на коленке делается за день же

тимситя до 10 чел бесплатна и тд

простейший сиай на коленке делается за день же

я ващет дизайнер интерфейсов =)

я ващет дизайнер интерфейсов =)

ну это ниче не меняет - можно тимситю в пару кликов поставить

или дженкинса или что там душе угодно

ну это ниче не меняет - можно тимситю в пару кликов поставить

как бы я просто еще не сталкивался с стеми задачами которые оно мне может решить, видимо =) понятно, что щас-то с докером любую вундервафлю можно с пол-тычка запустить

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

Не понял про каждый чих. Пример. Есть прод. Собирается по новому коммиту в мастере. Вот я пушнул коммит в мастер, там добавил новую таблицу, поэтому нужно запустить миграцию. Что делать в хуке? git pull origin master && docker-compose up ?

как бы я просто еще не сталкивался с стеми задачами которые оно мне может решить, видимо =) понятно, что щас-то с докером любую вундервафлю можно с пол-тычка запустить

не ну это совсем разные вещи - докер и сиай

Не понял про каждый чих. Пример. Есть прод. Собирается по новому коммиту в мастере. Вот я пушнул коммит в мастер, там добавил новую таблицу, поэтому нужно запустить миграцию. Что делать в хуке? git pull origin master && docker-compose up ?

хуке на сервере или у клиента?

я понимаю, что разные

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

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

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

тфс?

тфс?

team foundation server - который microsoft

умеет не только хранить сорсы но и собирать и деплоить

ага, спс

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

А прям на проде не круто делать git pull & docker-compose up?)

А прям на проде не круто делать git pull & docker-compose up?)

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

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

не не, мне надо для нужд небольшой команды а то и для себя одного :)

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

так то обычно это больше работа каких-нть отдельных девопсов

спасибо

Добрый день/вечер! Есть интересная задачка. Буду писать на примере. Клиент на сервис отправляет данные. Происходит проверка, могут ли обрабатыватся данные в текущее время, если нет, то задачу необходимо поставить на следующий день в определенное время. И вот здесь самое главное. Таких задач, формально назовем их "не по расписанию", может быть очень много, они должны попасть в очередь на следующий промежуток времени (к примеру завтра с 11:00), и выполняться, ВНИМАНИЕ, по очереди. У задач есть зависимость друг от друга. Т.е. если выполнилась одна задача - запускаем следующую и т.д. до самого конца выполнения.

Что посоветуете?

agenda?

https://www.npmjs.com/package/agenda

ребят, была у кого вот эта срань? Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call? пытаюсь миграции накатить, куда рыть не понимаю уже. все это делается в вагранте, на госте ubuntu 14.04, хост винда. pg_hba.conf host all all 0.0.0.0/0 trust postgresql.conf `listen_addresses: *`` vagrant file config.vm.network "private_network", ip: циферки

Первоначальная мысль следующая: Когда приходят данные не по расписанию, создавать блок задач на следующий промежуток времени и "складировать задачи" внутри блока. Блок - Delayed задача. При наступелнии времени - уничтожать блок в очереди, доставать первую задачу, выполнять ее, далее вытаскивать следующую и т.д. по порядку.

ребят, была у кого вот эта срань? Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call? пытаюсь миграции накатить, куда рыть не понимаю уже. все это делается в вагранте, на госте ubuntu 14.04, хост винда. pg_hba.conf host all all 0.0.0.0/0 trust postgresql.conf `listen_addresses: *`` vagrant file config.vm.network "private_network", ip: циферки

говорят же пулл забился, проверь может реально забился

да я уже переставлял вообще с нуля ее

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

при чем тут с нуля или нет

ок, рестарт вагранта - аргумент?

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

вот я тебе говорю - после рестарта вагранта с голой ПГ

та же фигня

https://www.npmjs.com/package/agenda

Спасибо! Но вопрос с точки зрения архитектурного подхода.

вот я тебе говорю - после рестарта вагранта с голой ПГ

а вообще базу видно? оно на таймер доступа к базе ругается же

порты проброшены все что надо?

да

config.vm.network "forwarded_port", guest: 5432, host: 5432 # postgresql

да и что мне с портами-то его

knex под вагрантом же прям там миграции и накатывает

Спасибо! Но вопрос с точки зрения архитектурного подхода.

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

knex под вагрантом же прям там миграции и накатывает

ты снаружи или изнутри миграции накатываешь? если снаружи то играет роль же

изнутри

сорян, забыл про это сказать

Т.е. складировать их в одной задаче - которая Delayed и далее стартовать по одной.

Т.е. складировать их в одной задаче - которая Delayed и далее стартовать по одной.

крон системный заюзай и все

https://github.com/tgriesser/knex/issues/1381

чуваки говорят подымай дебаглевел

да я ебнусь там)

эхх...

pool.requestTimeout being less than acquireConnectionTimeout

настройки дефолтные для всего?

оно из коробки не работает или у тебя свои какие-то пляски накручены?

не не

все вроде как коробочное

тогда быстрее будет на гитхаб наверное запостить матюки

ERROR: S client not available

ща попробую все таки дебаг

а то блин гугль по этой проблеме 4 ссылки выдал

и усё

Первоначальная мысль следующая: Когда приходят данные не по расписанию, создавать блок задач на следующий промежуток времени и "складировать задачи" внутри блока. Блок - Delayed задача. При наступелнии времени - уничтожать блок в очереди, доставать первую задачу, выполнять ее, далее вытаскивать следующую и т.д. по порядку.

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

И вот от такое ерунды крыша едет ??

да заюзай же ты системный крон будь человеком

да заюзай же ты системный крон будь человеком

Хуевая затея

Хуевая затея

почему?

зачем ему нода тогда с JS'ом, если крон юзать) писал бы все тогда уж через крон-скрипты чё)))

Хуевая затея

+

да заюзай же ты системный крон будь человеком

node-cron

почему?

Сломать себе мозг, как и архитектуру- раз плюнуть

Нагородить велосипедов, а потом с этим же возиться..

крон не про очереди

Именно

крон не про очереди

Коллега?

общесистемные одминские задачи - пожалуйста. но очереди in app - фу фу фу

Сломать себе мозг, как и архитектуру- раз плюнуть

ок заюзать любой другой готовый планировщик, вон нод крон советуют, сути дела не меняет - не велосипедить это

зачем планировщик для очередей?

+

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

Если тебе важна очередность- создавай по очереди на каждый период времени (какой- установи сам) и начни исполнять очередь в нужный тебе момент

от того что топором можно забить гвоздь, топор молотком не станет

Для очередей redis нелохо затачивается, если чо.

у него там частично функционал планировщика, частично очереди - очередь любую можно взять - async js например или чето еще более простое

да берите любой bull/kue/bee и иже с ними

Блядь, да задача в изи решается, какой блядь крон блядь Столько мата вставил спецом (я художник я так вижу)

редис то как-то дофига жирно для тулы на коленке

Блядь, да задача в изи решается, какой блядь крон блядь Столько мата вставил спецом (я художник я так вижу)

???

янукович жпег

redis это не Oracle. что в нем жирного-то???

редис то как-то дофига жирно для тулы на коленке

а крон нет?