История изменений

Ах да, я забыл, у нас же кроме докера оркестровки вообще никакой же не существует.

Я этого не говорила.

Интересная компания у которой весь прод на единственном сервере крутится. А те, у кого сервер не один, те весь прод в одной группе в SCMS сидят.

В моей прошлой конторе было пять датацентров, 600 серверов, 8 инстансов java-на сервер, оркестрация через salt и раскладывание джарников и их конфигов по серверам.

Первое, что сделали админы в этой компании - это для каждого джарника подняли свой инстанс tomcat в /opt. Потому что хотя tomcat вообще-то должен уметь крутить сколько угодно сервисов, на хайлоаде «так надёжнее». То есть на каждом серваке крутилось 8 разных томкатов из восьми разных распакованных архивов.

Ну и salt-конфиги, которые настраивали порты для этих томкатов - это отдельная песня. Потому что у джава-сервиса не один порт. У него один порт для web, один для jmx, один для debug, и один для админки. И всё это накостылено в помеси баш-скрипта с jinja-темплейтом.

Конфиги приложения тоже надо было менять в зависимости от датацентра, от инстанса и от фазы луны. При этом часть конфигов лежала в salt-репах под контролем админов, а часть в гите исходного приложения с захардкоженным маппингом на hostname целевой системы.

Первый вопрос который я задала был - «почему шардов 8, а не 12». В ответ тимлид команды разработчиков разрыдался а тимлид команды админов возвел очи горе, и сказал что-то наподобие «вы, юные хипстеры просто не понимаете масштабов и сложности прода который мы администрируем, и бегаете тут со своими идеями. А я, админ с 20-летним стажем, и ответственно заявляю что в наших salt-конфигах инстансов сделано восемь от начала времён и изменить это физически нельзя.»

Бонусом ко всему: полный архив инстанса который деплоили salt-ом весил около гигабайта, поэтому релиз новой версии по всем серверам занимал примерно два дня.

Когда я пришла переводить это добро на контейнерную доставку мне первым делом расписали что «это не взлетит» потому что контейнеры большие и будут долго деплоиться. Тут пришлось читать местным «топовым админам» лекцию о слоях у контейнеров и зачем они нужны.

В итоге наши контейнеры состояли из одного базового слоя с jvm без всяких томкатов, и слоя на 1MB, в котором находился джарник с сервисом. На один сервак мы деплоили до 30 штук сервисов с динамическим шардингом, релиз занимал минуты, и у меня были метрики, админка, доступ к debug-портам и всё контролировалось напрямую разработчиками.

Так что да, оркестрация бывает разная. И её разную надо уметь готовить.

Ах да, я забыл, у нас же кроме докера оркестровки вообще никакой же не существует.

Я этого не говорила.

Интересная компания у которой весь прод на единственном сервере крутится. А те, у кого сервер не один, те весь прод в одной группе в SCMS сидят.

В моей прошлой конторе было пять датацентров, 600 серверов, 8 инстансов java-на сервер, оркестрация через salt и раскладывание джарников и их конфигов по серверам.

Первое, что сделали админы в этой компании - это для каждого джарника подняли свой инстанс tomcat в /opt. Потому что хотя tomcat вообще-то должен уметь крутить сколько угодно сервисов, на хайлоаде «так надёжнее». То есть на каждом серваке крутилось 8 разных томкатов из восьми разных распакованных архивов.

Ну и salt-конфиги, которые настраивали порты для этих томкатов - это отдельная песня. Потому что у джава-сервиса не один порт. У него один порт для web, один для jmx, один для debug, и один для админки. И всё это накостылено в помеси баш-скрипта с jinja-темплейтом.

Конфиги приложения тоже надо было менять в зависимости от датацентра, от инстанса и от фазы луны. При этом часть конфигов лежала в salt-репах под контролем админов, а часть в гите исходного приложения с захардкоженным маппингом на hostname целевой системы.

Первый вопрос который я задала был - «почему шардов 8, а не 12». В ответ тимлид команды разработчиков разрыдался а тимлид команды админов возвел очи горе, и сказал что-то наподобие «вы, юные хипстеры просто не понимаете масштабов и сложности прода который мы администрируем, и бегаете тут со своими идеями. А я, админ с 20-летним стажем, и ответственно заявляю что в наших salt-конфигах инстансов сделано восемь от начала времён и изменить это физически нельзя.»

Бонусом ко всему: полный архив инстанса который деплоили salt-ом весил около гигабайта, поэтому релиз новой версии по всем серверам занимал примерно два дня.

Когда я пришла переводить это добро на контейнерную доставку мне первым делом расписали что «это не взлетит» потому что контейнеры большие и будут долго деплоиться. Тут пришлось читать местным «топовым админам» лекцию о слоях у контейнеров и зачем они нужны.

В итоге наши контейнеры состояли из одного базового слоя с jvm без всяких томкатов, и слоя на 1MB, в котором находился джарник с сервисом. На один сервак мы деплоили до 30 штук сервисов, релиз занимал минуты, и у меня были метрики, админка, доступ к debug-портам и всё контролировалось напрямую разработчиками.

Так что да, оркестрация бывает разная. И её разную надо уметь готовить.

Ах да, я забыл, у нас же кроме докера оркестровки вообще никакой же не существует.

Я этого не говорила.

Интересная компания у которой весь прод на единственном сервере крутится. А те, у кого сервер не один, те весь прод в одной группе в SCMS сидят.

В моей прошлой конторе было пять датацентров, 600 серверов, 8 инстансов java-на сервер, оркестрация через salt и раскладывание джарников и их конфигов по серверам.

Первое, что сделали админы в этой компании - это для каждого джарника подняли свой инстанс tomcat в /opt. Потому что хотя tomcat вообще-то должен уметь крутить сколько угодно сервисов, на хайлоаде «так надёжнее». То есть на каждом серваке крутилось 8 разных томкатов из восьми разных распакованных архивов.

Ну и salt-конфиги, которые настраивали порты для этих томкатов - это отдельная песня. Потому что у джава-сервиса не один порт. У него один порт для web, один для jmx, один для debug, и один для админки. И всё это накостылено в помеси баш-скрипта с jinja-темплейтом.

Конфиги приложения тоже надо было менять в зависимости от датацентра, от инстанса и от фазы луны. При этом часть конфигов лежала в salt-репах под контролем админов, а часть в гите исходного приложения с захардкоженным маппингом на hostname целевой системы.

Первый вопрос который я задала был - «почему шардов 8, а не 12». В ответ тимлид команды разработчиков разрыдался а тимлид команды админов возвел очи горе, и сказал что-то наподобие «вы, юные хипстеры просто не понимаете масштабов и сложности прода который мы администрируем, и бегаете тут со своими идеями. А я, админ с 20-летним стажем, и ответственно заявляю что в наших salt-конфигах инстансов сделано восемь от начала времён и изменить это физически нельзя.»

Бонусом ко всему: полный архив инстанса который деплоили salt-ом весил около гигабайта, поэтому релиз новой версии по всем серверам занимал примерно два дня.

Когда я пришла переводить это добро на контейнерную доставку мне первым делом расписали что «это не взлетит» потому что контейнеры большие и будут долго деплоиться. Тут пришлось читать местным «топовым админам» лекцию о слоях у контейнеров и зачем они нужны.

В итоге наши контейнеры состояли из одного базового слоя с jvm без всяких томкатов, и слоя на 1MB, в котором находился джарник с сервисом. На один сервак мы деплоили до 30 штук сервисов, релиз занимал минуты, и у меня были метрики, админка, доступ к debug-портам и всё контролировалось из команды разрабов напрямую разработчиками.

Так что да, оркестрация бывает разная. И её разную надо уметь готовить.

Ах да, я забыл, у нас же кроме докера оркестровки вообще никакой же не существует.

Я этого не говорила.

Интересная компания у которой весь прод на единственном сервере крутится. А те, у кого сервер не один, те весь прод в одной группе в SCMS сидят.

В моей прошлой конторе было пять датацентров, 600 серверов, 8 инстансов java-на сервер, оркестрация через salt и раскладывание джарников и их конфигов по серверам.

Первое, что сделали админы в этой компании - это для каждого джарника подняли свой инстанс tomcat в /opt. Потому что хотя tomcat вообще-то должен уметь крутить сколько угодно сервисов, на хайлоаде «так надёжнее». То есть на каждом серваке крутилось 8 разных томкатов из восьми разных распакованных архивов.

Ну и salt-конфиги, которые настраивали порты для этих томкатов - это отдельная песня. Потому что у джава-сервиса не один порт. У него один порт для web, один для jmx, один для debug, и один для админки. И всё это накостылено в помести баш-скрипта с jinja-темплейтом.

Конфиги приложения тоже надо было менять в зависимости от датацентра, от инстанса и от фазы луны. При этом часть конфигов лежала в salt-репах под контролем админов, а часть в гите исходного приложения с захардкоженным маппингом на hostname целевой системы.

Первый вопрос который я задала был - «почему шардов 8, а не 12». В ответ тимлид команды разработчиков разрыдался а тимлид команды админов возвел очи горе, и сказал что-то наподобие «вы, юные хипстеры просто не понимаете масштабов и сложности прода который мы администрируем, и бегаете тут со своими идеями. А я, админ с 20-летним стажем, и ответственно заявляю что в наших salt-конфигах инстансов сделано восемь от начала времён и изменить это физически нельзя.»

Бонусом ко всему: полный архив инстанса который деплоили salt-ом весил около гигабайта, поэтому релиз новой версии по всем серверам занимал примерно два дня.

Когда я пришла переводить это добро на контейнерную доставку мне первым делом расписали что «это не взлетит» потому что контейнеры большие и будут долго деплоится. Тут пришлось читать местным «топовым админам» лекцию о слоях у контейнеров и зачем они нужны.

В итоге наши контейнеры состояли из одного базового слоя с jvm без всяких томкатов, и слоя на 1MB, в котором находился джарник с сервисом. На один сервак мы деплоили до 30 штук сервисов, релиз занимал минуты, и у меня были метрики, админка, доступ к debug-портам и всё контролировалось из команды разрабов напрямую разработчиками.

Так что да, оркестрация бывает разная. И её разную надо уметь готовить.