Size: a a a

2021 February 03

VK

Victor Kulichenko in OmskLUG
один костыль:  прописывается в конфиге docker-а insecure-registries. Но если затевать с docker-registry без всей секьюрности, то её и не будет. Годится только для приват-сетки. Официальный работает нормально.
источник

S

Sergey in OmskLUG
у официального нет всяких cleanup policy и прочих плюшек. Как просто помойка, которую надо обслуживать вручную - вполне ок.
источник

VK

Victor Kulichenko in OmskLUG
unix way ))
источник

VK

Victor Kulichenko in OmskLUG
Sergey
проблема с тем, что project name не доступен через ENV, конечно, актуальна, но не так критична, чтобы прям говорить "валите с compose"
всё это известно и решаемо. Но количество таких мелочей для меня уже превысило комфортный уровень. Я несколько раз подумаю, стоит ли ориентироваться на docker-compose в новом проекте. Тем более что самое первое решение обычно остаётся надолго. Иногда и в проде.
источник

S

Sergey in OmskLUG
косвенно проблема в том, что docker / compose это стандарты в отрасли уже.
если мне нужно будет передавать проект - в случае lxc я кроме упоротого красноглазия себя никак в лучшем свете не покажу
источник

SK

Sergey K. in OmskLUG
Victor Kulichenko
всё это известно и решаемо. Но количество таких мелочей для меня уже превысило комфортный уровень. Я несколько раз подумаю, стоит ли ориентироваться на docker-compose в новом проекте. Тем более что самое первое решение обычно остаётся надолго. Иногда и в проде.
а какие есть аналоги у композа?
источник

SK

Sergey K. in OmskLUG
ну кроме кубера
источник

S

Sergey in OmskLUG
Sergey K.
ну кроме кубера
на проектах, где 1 инстанс сервера, 1 инстанс сервиса без реплики и база без реплики не до кубера)))
источник

SK

Sergey K. in OmskLUG
Sergey
на проектах, где 1 инстанс сервера, 1 инстанс сервиса без реплики и база без реплики не до кубера)))
именно это я имею в виду)
источник

S

Sergey in OmskLUG
😊 (по сценарию тут должна быть фраза в стиле "таким проектам не место в мире" и все такое))
источник

IG

Ivan Grishko in OmskLUG
Sergey K.
а какие есть аналоги у композа?
bash-скрипт 😊
источник

S

Sergey in OmskLUG
а, кстати, норм, но композ чуть чуть удобнее
источник

VK

Victor Kulichenko in OmskLUG
Если проект пойдёт в облако, то kubernetes. Если нет, то тоже куб не плох. Один раз развернуть и научиться. То что проекты простые уже не важно. Они ещё и имеют обыкновение расти. // Аналоги композа наверно есть, видел упоминание какой-то поделки, специально не интересовался.
источник

S

Sergey in OmskLUG
да как не важно то - я вот щас смотрю в деплой проекта, с бюджетом на 1 t3.small инстанс, где джава сервис + монга и nginx как реверс прокси + статика. Какой тут кубернетес? кому он тут нужен?
источник

S

Sergey in OmskLUG
научиться за счет заказчика - это пушка, конечно. А обосновать получится зачем ему платить за это? Особенно на старте проекта
источник

VK

Victor Kulichenko in OmskLUG
для такого и композ не нужен.
источник

S

Sergey in OmskLUG
ну да, ну да. Обновления версий ПО, zero-downtime мы на баше, видимо, будем писать?)
источник

S

Sergey in OmskLUG
даже не говорю про то, что есть всякие фичи типа multistage билдов, которые позволяют весь сборочный хлам не таскать по системе. И это просто удобно.
источник

VK

Victor Kulichenko in OmskLUG
Можно и на баше, но я не против композа. Как-то только для разрботки (и 3 года назад именно с композом) был проект на 15 микросервисов + постгрес, кафка и эластик. Заказчики сказали, разворачивать прод будет другая команда. Разворачивают на systemd без докера. До сих пор не справились. Но в деве мы намучались feature-ветки деплоить.
источник

S

Sergey in OmskLUG
тут да.. только дробить на какие-то осмысленные сегменты. Даже проект на 5+ сервисов уже доставляет неудобство
источник