Size: a a a

2020 September 28

A

Anton in DevOps
То есть ничего нового не придумали) Спасибо
источник

DS

Dmitry Sergeev in DevOps
ну traefik'и всякие еще умеют
источник

II

Ivan Igorevich in DevOps
Dmitry Sergeev
ну traefik'и всякие еще умеют
+ , traefik могет в такое
источник
2020 September 29

AS

Aleksey Shirokikh in DevOps
вот вы тут все опять ругаете баш.
источник

AS

Aleksey Shirokikh in DevOps
а мне тем временем опять помог sed
источник

N

Navern in DevOps
Aleksey Shirokikh
а мне тем временем опять помог sed
каеф
источник

AS

Aleksey Shirokikh in DevOps
а всё потому что go отстой.
источник

N

Navern in DevOps
но sed же не -eq bash
источник

AS

Aleksey Shirokikh in DevOps
go вот мне не помог а sed помог
источник

AS

Aleksey Shirokikh in DevOps
а теперь то что я сделал седом надо будет делать на go через столько ада и треша что иногда диву даёшься.
источник

AS

Aleksey Shirokikh in DevOps
и нет я конечно не горжусь что это так. но вот местами ДА БЛЯТЬ!
источник

N

Navern in DevOps
Aleksey Shirokikh
а теперь то что я сделал седом надо будет делать на go через столько ада и треша что иногда диву даёшься.
А в чем ад и треш?)
источник

AS

Aleksey Shirokikh in DevOps
а мне надо было завалидировать ямль. который будет подтягиваться в конфигурацию прометея.
но вот беда. у нас уже модули, а прометей еще без них.
так что взять и поднянуть прометей немного сложновато
поэтому взяли валидатор от виктории. он по слабее но работает.
но вот беда в нем есть доп опции которые пром не распознаёт. их надо вырезать. седом.
и теперь надо идти и
* либо хачить прометеевский код что бы он был совсместим с модулями
* патчить либу виктории
* писать свой валидатор для scrape_config. а там ебанутся.
sed заебок.
источник

AS

Aleksey Shirokikh in DevOps
и вот этот ад и треш теперь решать чо...
источник

N

Navern in DevOps
А почему доп опции не вырезать гошкой?
источник

AS

Aleksey Shirokikh in DevOps
так это хачить струкруру. это второй вариант же
источник

S

SM in DevOps
Парни. Такой вопрос :)

Есть основной сайт front+back на сервере "А".
Так же есть медиасерверы "B" и "C" и т.д.... (добавляемые в базе).

Основной backend находится на domain.com/backend/
Медиасерверы на поддоменах вида media01.domain.com/backend/

Сейчас загрузка видео на проект осуществляется следующим образом.
Видео загружается на основной сервер "А", а затем передаётся на заданный логикой бэкенда медиасервер "B" или "C".

Проблему со storage - решили. Видео хранится где нужно.
Но вот проблему с нагрузкой на основной сервер "A", лишь усугубили. Т.к. мало того что он принимает как и раньше, так ещё теперь и отдаёт на медиасерверы такой же объём данных, являясь своего рода гейтвеем на приём/передачу.

Обращение к медиафайлам уже идёт корректно через поддомен, там всё в порядке.

Как грамотно это поправить? Не хранить же данные о приоритетном серваке для загрузки видео на фронте?
источник

S

SM in DevOps
Проект мой личный, нанял джуна, делает на nodejs + reactjs. Джун до данного решения не дотягивает... Может кто сталкивался, в курсе?
источник

AS

Aleksey Shirokikh in DevOps
SM
Парни. Такой вопрос :)

Есть основной сайт front+back на сервере "А".
Так же есть медиасерверы "B" и "C" и т.д.... (добавляемые в базе).

Основной backend находится на domain.com/backend/
Медиасерверы на поддоменах вида media01.domain.com/backend/

Сейчас загрузка видео на проект осуществляется следующим образом.
Видео загружается на основной сервер "А", а затем передаётся на заданный логикой бэкенда медиасервер "B" или "C".

Проблему со storage - решили. Видео хранится где нужно.
Но вот проблему с нагрузкой на основной сервер "A", лишь усугубили. Т.к. мало того что он принимает как и раньше, так ещё теперь и отдаёт на медиасерверы такой же объём данных, являясь своего рода гейтвеем на приём/передачу.

Обращение к медиафайлам уже идёт корректно через поддомен, там всё в порядке.

Как грамотно это поправить? Не хранить же данные о приоритетном серваке для загрузки видео на фронте?
источник

AS

Aleksey Shirokikh in DevOps
очень рекомендую
источник