фича докера — он умеет работать в контексте удаленной машины. Т.е. исходники и пр брать с локальной машины а собирать образ и все последующие действия — на удаленной. для небольших несвязанных проектов (или микросервисов) довольно удобно.

ручками git pull?

git pull master по хуку

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

ну ваще СI этим занимается, если точнее CI-runner

окай, пасиб. А что с миграциями? В какой момент они запускаются?

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

докер наше все

докер наше все

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

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

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

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

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

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

Глянь еще 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

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

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

не не

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

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

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

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

и усё

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

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

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

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

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

Хуевая затея

Хуевая затея

почему?

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