В итоге на работе все напрограммированное нами богатство мы переводим в инсталляцию cloud foundry. Подозреваю, но не уверен до конца, что мы рискуем стать самым опытным оператором Cloud Foundry поверх OpenStack в России. Сами компоненты OpenStack управляется не напрямую, а релиз-менеджером bosh, который умеет и установку новых VM с необходимым ПО (релизами), и восстановление упавших вещей, и масштабирование — независимо, это часть CF, или что-то снаружи него стоит (гейт, БД, прочее).
Сам CF по своей сути это опен-сорсная версия облака типа Heroku, которая позволяет единообразно управлять и инфраструктурой исполнения, и загруженным в него ПО. Приложения для запуска можно обернуть в докер-контейнер или собирать билд-паками, специфичными для стека. Все это в итоге пакуется в контейнер -- не докер-образы, а дроплет для CRI-O.
Есть внутренний DNS, внутренняя оверлейная сеть на базе Silk, внутри все нарезается на изолированные "организации" и "пространства", есть SSO, поддерживается Open Service Broker API для подключения туда внешних сервисов типа DBaaS или чего-то другого - например, роутера для A/B деления траффика и т.п. Встроенные инструменты для мониторинга, логгирования, управления доступами, ротирования сертификатов и прочего тоже есть, есть и адаптеры к ELK, prometheus-стеку и т.д.
Штука поддерживает обновление на ходу, перебрасывая нагрузку по любым задачам между узлами, от входных роутеров до узлов, на которых фактически крутятся контейнеры.
Учитывая, что лежащий внизу IaaS размазан по нескольких зонам доступности, в общем случае нам даже пожар в ДЦ не очень страшен - при условии, что будет организована доступность БД, которые стоят вне CF.
Очень хорошо получилось.
Сам CF по своей сути это опен-сорсная версия облака типа Heroku, которая позволяет единообразно управлять и инфраструктурой исполнения, и загруженным в него ПО. Приложения для запуска можно обернуть в докер-контейнер или собирать билд-паками, специфичными для стека. Все это в итоге пакуется в контейнер -- не докер-образы, а дроплет для CRI-O.
Есть внутренний DNS, внутренняя оверлейная сеть на базе Silk, внутри все нарезается на изолированные "организации" и "пространства", есть SSO, поддерживается Open Service Broker API для подключения туда внешних сервисов типа DBaaS или чего-то другого - например, роутера для A/B деления траффика и т.п. Встроенные инструменты для мониторинга, логгирования, управления доступами, ротирования сертификатов и прочего тоже есть, есть и адаптеры к ELK, prometheus-стеку и т.д.
Штука поддерживает обновление на ходу, перебрасывая нагрузку по любым задачам между узлами, от входных роутеров до узлов, на которых фактически крутятся контейнеры.
Учитывая, что лежащий внизу IaaS размазан по нескольких зонам доступности, в общем случае нам даже пожар в ДЦ не очень страшен - при условии, что будет организована доступность БД, которые стоят вне CF.
Очень хорошо получилось.