Исходное сообщение
"Выпуск Kata Containers 3.0 с изоляцией на основе виртуализац..." Отправлено Всем Анонимам Аноним, 16-Окт-22 12:27
Контейнеры уже давно не средство экономии, а средство для выполнения приложений. В VM-ке получается смесь основной системы, настройки сетей, драйверов, мониторинга и прочего. Для получения VM-ки нужно или кому-то писать или самому создавать и потом поверх ставить всё. Часто эта VM-ка висит потом одна в одной копии и если она упадет, то несколько уровней начальства может быть задействовано чтобы восстановить. Апгрейд такого - еще такой квест, когда начинается конфликт библиотек и т.п. Вначале команда, занимающаяся инфраструктурой должна подготовить релиз новый со всеми делами, потом только уже приложения можно пробовать. В результате процесс на год или больше выходит и куча ручной работы. Все это знаю сам по опыту. А если нужно патчить всё каждый месяц? Контейнер отделяет приложения от инфраструктуры. Можно использовать любую основу, не обязательно то, что стоит на хосте. Image приложения будет такой же, как у программиста, так и в production. не будет такого, что какой-то пакет новый вышел, обновился на prod и все сломалось, к примеру. Но еще, что важно, сам контейнер можно положить уже в kubernetes, где программисту вообще ничего не нужно знать об инфраструктуре. Его приложение будет перемещаться само при сбоях. Он может использовать классные плюшки типа ingress или mesh или сквзного шифрования (важно для PCI). Патчить хосты вообще легкая задача, каждый месяц без проблем, можно автоматом просто даже. Горизонтальное масштабирование - одной командой. FYI работал как с 30 тыс физических серваков, так и 1000 приложений от разных команд.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Контейнеры уже давно не средство экономии, а средство для выполнения приложений. В > VM-ке получается смесь основной системы, настройки сетей, драйверов, мониторинга и прочего. > Для получения VM-ки нужно или кому-то писать или самому создавать и > потом поверх ставить всё. Часто эта VM-ка висит потом одна в > одной копии и если она упадет, то несколько уровней начальства может > быть задействовано чтобы восстановить. Апгрейд такого - еще такой квест, когда > начинается конфликт библиотек и т.п. Вначале команда, занимающаяся инфраструктурой должна > подготовить релиз новый со всеми делами, потом только уже приложения можно > пробовать. В результате процесс на год или больше выходит и куча > ручной работы. Все это знаю сам по опыту. А если нужно > патчить всё каждый месяц? > Контейнер отделяет приложения от инфраструктуры. Можно использовать любую основу, не обязательно > то, что стоит на хосте. Image приложения будет такой же, как > у программиста, так и в production. не будет такого, что какой-то > пакет новый вышел, обновился на prod и все сломалось, к примеру. > Но еще, что важно, сам контейнер можно положить уже в kubernetes, где > программисту вообще ничего не нужно знать об инфраструктуре. Его приложение будет > перемещаться само при сбоях. Он может использовать классные плюшки типа ingress > или mesh или сквзного шифрования (важно для PCI). Патчить хосты вообще > легкая задача, каждый месяц без проблем, можно автоматом просто даже. Горизонтальное > масштабирование - одной командой. > FYI работал как с 30 тыс физических серваков, так и 1000 приложений > от разных команд.
	Введите код, изображенный на картинке: