Пока всё находится на стадии разработки, поэтому не проработано до мелочей. Спасибо за ваш комментарий.
Сортировку пока скидываем изнутри, через её развернутое представление.
Справедливое замечание.
В этом случае шапка принимает компактный вид.
Да, появляется. Списки действительно большие, и это удобно.
Специфика проектов, для которых мы делали карточки, такова, что пользователи обычно опознают карточки по названию. Номер пригождается реже, в конкретных случаях, когда что-то случилось и нужно быстро найти карточку.
Отличная идея про выделение параметров маркером. Спасибо! Возьмем на заметку.
Разворачивание кластера, анализ ошибок/предупреждений в логах докера/кубернетиса, запуск тестовых приложений и снова анализ логов.
В связке Oracle Linux + docker + k8s из стандартных репозиториев не было ошибок вообще, а предупреждений было 7 штук и все они совершенно некритичные. После этого мы развернули нашу микросервисную систему и провели нагрузочное тестирование (смоделировали работу приложения в пиковом режиме нагрузки) — ничего не упало, ошибок в логах платформы не было, а сама система отработала в расчетное время с верными результатами.
БД мы вынесли за пределы контейнеров/Кубернетиса, так как у нее свои регламенты обновления/бэкапа/администирования. В тестовых окружениях мы разворачивали её вне контейнеров, а в проде вынесли на отдельную виртуальную машину.
Вы можете развернуть систему в K8S и так, если уже упаковали её в Docker. Цель нашей статьи рассказать про K8S как про один из инструментов, позволяющий достичь цели time to market (быстрой доставки решений до продашна): быстро и надёжно разворачивать приложения на любой инфраструктуре, обеспечивать высокую степень отказоустойчивости, обновлять систему незаметно для пользователей. Но для того чтобы воспользоваться всеми этими возможностями, мы рекомендуем разделить систему на микросервисы.
Наверняка частые релизы означают, что большинство этих действий уже сделаны. Да и не все 100% действий из шпаргалки нужны и применимы для всех решений.
Наш чеклист скорее предназначен для вывода нового решения в прод, когда ничего не было, и вот появилось, выведено в эксплуатацию. А это событие случается реже двух раз в месяц.
Фамилия нужна, чтобы идентифицировать пассажира. В одной брони бронировании может оказаться несколько человек. Например, семья или группа коллег, летящих вместе.
Так как опрос связан с конкретным путешествием, бронь и фамилия, как данные, идентифицирующие это путешествие, важны и передаются в авиакомпанию (впрочем, компания владеет этой информацией и без опроса).
Это не только ради бонусов. Диалог между компанией и клиентом сейчас — это вполне привычная практика. Главное предоставить действительно удобный инструмент, и люди готовы идти навстречу.
Иногда клиентам есть что сказать. Иногда хочется поблагодарить. А иногда и бонусы не лишние, но они только один из поводов.
Во-первых, Job’ы сложно тестировать, нет готового инструмента для того, чтобы протестировать ваш Job, кроме проверки синтаксиса файла .gitlab-ci.yml.
Во-вторых, не совсем очевидно работают секции only & except. При написании первого пайплайна ожидали, что условия в only будут “И”, а они оказались “ИЛИ”. Чтобы выйти из положения, нужно в except писать все исключения, например:
чтобы запускать сборку по расписанию в ветке develop нужно
only:
-web
-schedules
except:
-master
-/^feature/.$/
-/^bug/.$/
-/^bugfix/.$/
-/^cherry-pick-.$/
В-третьих, до недавнего времени не было возможности разделить конфигурацию на несколько файлов, и наш текущий файл .gitlab-ci.yml уже слишком большой.
Остальные сложности были связаны скорее с тем, что не понимали формат и учились в процессе.
Сейчас используем почти весь функционал Gitlab-CI кроме environment, если у вас есть какие-то вопросы, то можно поговорить более предметно.
Спасибо! Не можем сказать, что готовы расстаться с какой-то технологией. Но с каждой были сложности, которые мы осознали не сразу.
Например, Hazelcast довольно сложен, если вам нужно разобраться, почему он вдруг начинает работать медленно или почему он делает неожиданные вещи. Последнее, что мы пытались настроить в Hazelcast, но не очень успешно — это логирование медленных операций. И мы так и не добились от него вменяемой информации по этому вопросу.
По части Eureka: мы используем не самую актуальную версию, и в UI у Eureka есть проблемы, но мы с этим живем.
Gitlab CI только на первый взгляд имеет очевидный язык настройки Job’ов.
И если бы начинали сейчас, то сразу подумали бы о правильном тестировании микросервисов.
И ещё хотели добавить вот что. Наличие одной БД для нескольких микросервисов, которые используют liquibase, приводит к конкуренции за таблицы liquibase при старте приложения и может привести как к замедлению, так и к незапуску. Это в копилку знаний, почему нужно делать отдельные БД :)
Вы правы, все микросервисы должны иметь изолированную базу, и мы идем к этому. До сих пор не перешли, поскольку есть более приоритетные задачи. А также осложнения:
база данных используется как источник для других служб,
есть резервное копирование и восстановление данных, которое работает на основе базы, которая была на монолите.
По поводу “может случайно (или намеренно) создать сайдэффекты” – такого с БД не было. В этой плоскости у нас нет проблем.
При разделении монолитного приложения мы прошли несколько этапов. Изначально все Entity базы данных хранились в одном модуле Maven, и была настроена политика обновления схемы на основе изменений Entity классов hibernate.hbm2ddl.auto: update. Когда мы выделили первый микросервис, то сразу столкнулись с проблемой двойного апдейта базы, так как было два приложения, которые на старте пытались инициализировать новую схему БД. Авто-апдейт схемы выключили и перешли на написание скриптов и их запуск при деплое на окружении. Изначально это делалось руками, потом внедрили Liquibase.
Постепенно мы разносили Entity классы по микросервисам, которым они «принадлежат». В текущий момент мы все ещё имеем одну БД, но таблицы в этой БД принадлежат разным микросервисам.
Для записи в БД мы так же используем Hazelcast, то есть мы не пишем в БД напрямую, а бросаем Event на событие, и каждый микросервис (в том числе и тот, который бросил Event) записывает в БД. Это сделано не для всех случаев, но это необходимо, чтобы между микросервисами не было интеграции через БД.
Мы выбрали Hazelcast по нескольким причинам:
Действительно, был опыт работы с ним. Redis использовали только как кэш или для хранения сессий, но не было опыта работы как с event-bus. С Hazelcast, напротив, был опыт подобной работы, хоть и не большой.
Наличие необходимого функционала из коробки (ex. reliable topic).
По поводу писем со 100 ченджами, наверное вы имеете ввиду что-то типа Release Notes. Это немножко другое. Release Notes это все же техническая коммуникация для технически-подкованных пользователей. Мы же про то, как объяснить не сильно подвинутому в технологиях ключевому пользователю (кассир, бухгалтер, менеджер…), что в его работе поменялось.
(Плюс не писать про все и сразу нам помогают таргетированные рассылки для пользователей с разными ролями. Технологам — одни, системным администраторам — другие, пользователям — третьи. Ведь каждого из них касается только часть).
Главное помнить, что мы хотим рассказать о ключевых (а в идеале одном ключевом) изменениях, вошедших в релиз, а не обо всех фичах.
Маркетологи здесь могут вам помочь, так как они, во-первых, на это заточены (и тут дело не в рекламе, а в вычленении главного), а во-вторых, человеку, который глубоко включен в проект зачастую это сложно.
Но на наш взгляд идеальная схема выглядит следующим образом — менеджеры проекта готовят драфт, проверяют его на ключевом пользователе, и отдают маркетологам на финальное облагораживание. Понятно, что это требует времени, но ведь для этого релизы и планируются.
Пользователи в домене, но это внешние пользователи, поэтому к себе на винду и в почту они ходят под своими учетками, а доменные учетные записи они используют для того, чтобы ходить в рабочие приложения.
Да, вы правы, не хватает упоминания Mass Transit. Внесли правки в текст.
Пока всё находится на стадии разработки, поэтому не проработано до мелочей. Спасибо за ваш комментарий.
Разворачивание кластера, анализ ошибок/предупреждений в логах докера/кубернетиса, запуск тестовых приложений и снова анализ логов.
В связке Oracle Linux + docker + k8s из стандартных репозиториев не было ошибок вообще, а предупреждений было 7 штук и все они совершенно некритичные. После этого мы развернули нашу микросервисную систему и провели нагрузочное тестирование (смоделировали работу приложения в пиковом режиме нагрузки) — ничего не упало, ошибок в логах платформы не было, а сама система отработала в расчетное время с верными результатами.
БД мы вынесли за пределы контейнеров/Кубернетиса, так как у нее свои регламенты обновления/бэкапа/администирования. В тестовых окружениях мы разворачивали её вне контейнеров, а в проде вынесли на отдельную виртуальную машину.
Вы можете развернуть систему в K8S и так, если уже упаковали её в Docker. Цель нашей статьи рассказать про K8S как про один из инструментов, позволяющий достичь цели time to market (быстрой доставки решений до продашна): быстро и надёжно разворачивать приложения на любой инфраструктуре, обеспечивать высокую степень отказоустойчивости, обновлять систему незаметно для пользователей. Но для того чтобы воспользоваться всеми этими возможностями, мы рекомендуем разделить систему на микросервисы.
В этой статье рассказали о самой концепции, а о тонкостях и примерах обязательно расскажем в следующих материалах.
Наверняка частые релизы означают, что большинство этих действий уже сделаны. Да и не все 100% действий из шпаргалки нужны и применимы для всех решений.
Наш чеклист скорее предназначен для вывода нового решения в прод, когда ничего не было, и вот появилось, выведено в эксплуатацию. А это событие случается реже двух раз в месяц.
В базе, мы используем Entity Framework, но можно и другие http://masstransit-project.com/MassTransit/advanced/sagas/persistence.html
Скорее всего, да, только надо использовать для корелляции ивента не CorrelateById, а CorrelateBy.
Спасибо, поправили!
Фамилия нужна, чтобы идентифицировать пассажира. В одной брони бронировании может оказаться несколько человек. Например, семья или группа коллег, летящих вместе.
Так как опрос связан с конкретным путешествием, бронь и фамилия, как данные, идентифицирующие это путешествие, важны и передаются в авиакомпанию (впрочем, компания владеет этой информацией и без опроса).
Это не только ради бонусов. Диалог между компанией и клиентом сейчас — это вполне привычная практика. Главное предоставить действительно удобный инструмент, и люди готовы идти навстречу.
Иногда клиентам есть что сказать. Иногда хочется поблагодарить. А иногда и бонусы не лишние, но они только один из поводов.
Во-первых, Job’ы сложно тестировать, нет готового инструмента для того, чтобы протестировать ваш Job, кроме проверки синтаксиса файла .gitlab-ci.yml.
Во-вторых, не совсем очевидно работают секции only & except. При написании первого пайплайна ожидали, что условия в only будут “И”, а они оказались “ИЛИ”. Чтобы выйти из положения, нужно в except писать все исключения, например:
чтобы запускать сборку по расписанию в ветке develop нужно
only:
-web
-schedules
except:
-master
-/^feature/.$/
-/^bug/.$/
-/^bugfix/.$/
-/^cherry-pick-.$/
В-третьих, до недавнего времени не было возможности разделить конфигурацию на несколько файлов, и наш текущий файл .gitlab-ci.yml уже слишком большой.
Остальные сложности были связаны скорее с тем, что не понимали формат и учились в процессе.
Сейчас используем почти весь функционал Gitlab-CI кроме environment, если у вас есть какие-то вопросы, то можно поговорить более предметно.
Спасибо! Не можем сказать, что готовы расстаться с какой-то технологией. Но с каждой были сложности, которые мы осознали не сразу.
Например, Hazelcast довольно сложен, если вам нужно разобраться, почему он вдруг начинает работать медленно или почему он делает неожиданные вещи. Последнее, что мы пытались настроить в Hazelcast, но не очень успешно — это логирование медленных операций. И мы так и не добились от него вменяемой информации по этому вопросу.
По части Eureka: мы используем не самую актуальную версию, и в UI у Eureka есть проблемы, но мы с этим живем.
Gitlab CI только на первый взгляд имеет очевидный язык настройки Job’ов.
И если бы начинали сейчас, то сразу подумали бы о правильном тестировании микросервисов.
И ещё хотели добавить вот что. Наличие одной БД для нескольких микросервисов, которые используют liquibase, приводит к конкуренции за таблицы liquibase при старте приложения и может привести как к замедлению, так и к незапуску. Это в копилку знаний, почему нужно делать отдельные БД :)
Вы правы, все микросервисы должны иметь изолированную базу, и мы идем к этому. До сих пор не перешли, поскольку есть более приоритетные задачи. А также осложнения:
По поводу “может случайно (или намеренно) создать сайдэффекты” – такого с БД не было. В этой плоскости у нас нет проблем.
При разделении монолитного приложения мы прошли несколько этапов. Изначально все Entity базы данных хранились в одном модуле Maven, и была настроена политика обновления схемы на основе изменений Entity классов hibernate.hbm2ddl.auto: update. Когда мы выделили первый микросервис, то сразу столкнулись с проблемой двойного апдейта базы, так как было два приложения, которые на старте пытались инициализировать новую схему БД. Авто-апдейт схемы выключили и перешли на написание скриптов и их запуск при деплое на окружении. Изначально это делалось руками, потом внедрили Liquibase.
Постепенно мы разносили Entity классы по микросервисам, которым они «принадлежат». В текущий момент мы все ещё имеем одну БД, но таблицы в этой БД принадлежат разным микросервисам.
Для записи в БД мы так же используем Hazelcast, то есть мы не пишем в БД напрямую, а бросаем Event на событие, и каждый микросервис (в том числе и тот, который бросил Event) записывает в БД. Это сделано не для всех случаев, но это необходимо, чтобы между микросервисами не было интеграции через БД.
Мы выбрали Hazelcast по нескольким причинам:
Фичи да — пишите актуальные в Release Notes. Кстати, как мы автоматизировали формирование Release Notes, рассказывали вот тут.
Коммуникация привязана не к фичам, а к ключевому функционалу. Поэтому
Поэтому если интересующее нас изменение не случился в этом релизе — значит коммуникация будет ждать того релиза, когда он выйдет.
Спасибо за конструктивный комментарий!
По поводу писем со 100 ченджами, наверное вы имеете ввиду что-то типа Release Notes. Это немножко другое. Release Notes это все же техническая коммуникация для технически-подкованных пользователей. Мы же про то, как объяснить не сильно подвинутому в технологиях ключевому пользователю (кассир, бухгалтер, менеджер…), что в его работе поменялось.
(Плюс не писать про все и сразу нам помогают таргетированные рассылки для пользователей с разными ролями. Технологам — одни, системным администраторам — другие, пользователям — третьи. Ведь каждого из них касается только часть).
Главное помнить, что мы хотим рассказать о ключевых (а в идеале одном ключевом) изменениях, вошедших в релиз, а не обо всех фичах.
Маркетологи здесь могут вам помочь, так как они, во-первых, на это заточены (и тут дело не в рекламе, а в вычленении главного), а во-вторых, человеку, который глубоко включен в проект зачастую это сложно.
Но на наш взгляд идеальная схема выглядит следующим образом — менеджеры проекта готовят драфт, проверяют его на ключевом пользователе, и отдают маркетологам на финальное облагораживание. Понятно, что это требует времени, но ведь для этого релизы и планируются.
Пользователи в домене, но это внешние пользователи, поэтому к себе на винду и в почту они ходят под своими учетками, а доменные учетные записи они используют для того, чтобы ходить в рабочие приложения.