http://microservices.io/

http://microservices.io/

схоронил

http://microservices.io/

Такая себе штука. Вроде модно-молодёжно, но что, если придётся интегрироваться с внешней системой посредством soap?

писать слой интеграции

Раз зашла тему про микросервисы: подскажите, что есть для управления кластером сервисов, типа кубернетиса для контейнеров?

Дашборд со статусами сервисов, автоматическое поднятие сервиса, если он упал, и т.д.

марафон

Дашборд со статусами сервисов, автоматическое поднятие сервиса, если он упал, и т.д.

ну дашбоарды есть по дефолту в спринг клауде

Спасибо, но это не совсем то

Я про марафон

hystrix dashboard

а вот что касается деплоймента и оркестрации

А есть какие-либо аналоги спиннейкера?

тут я бы сам послушал опытных коллег

вообще, бытует мнение, что серьезные облака - это open stack

мы свою обвязку делаем вокруг марафона/мезоса

Дашборд со статусами сервисов, автоматическое поднятие сервиса, если он упал, и т.д.

Так у k8s есть дашборд

Так у k8s есть дашборд

k8s - это кубернетис?

ага

или что то более специфичное типа как у spring cloud dashboard?

Он крут, но работает только с контейнерами

Где можно почитать best practices об архитектуре приложений?

Так бы взял

Он крут, но работает только с контейнерами

А нужно как?

у вас bare metal деплоймент есть?

просто железные тачки?

А нужно как?

Свой прайвет клауд, мониторить, оркестировать инстансы в нем

похоже на то

Свой прайвет клауд, мониторить, оркестировать инстансы в нем

опен стэк смотрели?

Нет

У нас поверх клауд провайдера своя прослойка

Я ей пользуюсь

Их апи

мы отказались от опен-стека. с ним были какие-то проблемы

ну с ним проблема одна, он сложный)

и там реально пропотеть надо

так а не вариант обернуть сервисы в контейнеры и дальше как все в k8s?

он не работал как надо

так а не вариант обернуть сервисы в контейнеры и дальше как все в k8s?

Так все равно придется писать интеграцию кубернетиса со своим апи

Только поверх будут ненужные контейнеры

Пока наиболее подходяще выглядит спиннейкер

Интересно, есть ли ещё что-нибудь такое

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

а докер сворм никто не юзает?

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

Именно, нам докеры не нужны

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

а докер сворм никто не юзает?

у нас используется. не без проблем

я вас слушаю

волюмы не работают. проблемы с изоляцией сетей и контейнеров, с коллизиями. у нас на нем бамбу агенты крутятся

Именно, нам докеры не нужны

Так вам дашборды всё таки для мониторинга нужны состояния или деливери?

Так вам дашборды всё таки для мониторинга нужны состояния или деливери?

Все нужно

спинекер только CD выполняет

накручивать его на апи провайдера всёравно придётся

причём это ж даже не думаю что просто будет

волюмы не работают. проблемы с изоляцией сетей и контейнеров, с коллизиями. у нас на нем бамбу агенты крутятся

эм, как вольюмы не работают?

а как же быть тогда?

а вообще graphite/grafana и вот весь дашборд)

для каких-то задач сворм может и норм, но точно не для билд-сервера

а что скажете про бд в контейнере + вольюм?

для продакшена?

или лучше бд пер сервер железный?

накручивать его на апи провайдера всёравно придётся

Писать интеграцию в любом случае придется. Я, наверно, хочу провайдер агностик деливери тулзу(со всякими канари, блю/грин депорйментами), простой дашборд со списком инстансов и их статусами, и штуку, которая будет поднимать упавшие инстансы

И чтобы как можно меньше допиливать

https://www.datadoghq.com/dashboarding/

Есть он у нас

Это же метрики

ERROR: S client not available

а что скажете про бд в контейнере + вольюм?

и +, что за ELK стэк скажете?

C ELK всё ок, только говорят и лучше есть тулзы вместо кибаны

ну кибана, это же юай только

C ELK всё ок, только говорят и лучше есть тулзы вместо кибаны

И вместо логстэша

а что скажете про бд в контейнере + вольюм?

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

Например, fluentd

ну мы редис использовали вообще, вмечто логсташ))

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

значит бд пер сервер?

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

чёт я не понял про какие нагрузки идёт речь

а influxdb для метрик кто-то пробовал?

стоит да

вроде справляется с большим количеством метрик. на этом всё)

у нас народ ловил случаи, когда докер намертво вешался

ну для дев окружения наверно и так пойдет

для дев - норм

Так а что за нагрузки? именно когда много стартов, деплоев через docker?

да

при большом количестве контейнеров на одном хосте

ну это на одном хосте если... у вас бааальшой хост?

Чо там по скале если кратко, куда лыжи точить?

Я щас начал работку искать, много где хотят дата инженеров, но это, по-моему, путь в никуда. Чистить данные, готовить пайплайны и графики. Продакшен акки чо-то совсем немного.

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

а скала сейчас и целится в область "язык для бигдаты и друзей"

Это печально. Как девопс младший брат программиста, так и бигдата инженер младший брат дата сайнтиста. Вся иллюзия собственной значимости теряется

ну подучи матан, будешь крутым ценным единорогом)

Скалисты же хотели быть умными джавистами, а эко оно выходит

ну подучи матан, будешь крутым ценным единорогом)

Да там такой хайп, что меня вчерашние студенты на каггле с питоном заганкают

там этот "дата сайнс" на 80% -- университетского уровня матстат

там этот "дата сайнс" на 80% -- университетского уровня матстат

притом на каком-нибудь R