# изоляция кода

Важно всегда помнить что самый надежный уровень изоляции чего-либо - физический уровень. Если разные приложения запускаются на разных компьютерах и эти компьютеры не соединены друг с другом - то и влияния друг на друга приложения иметь не будут.

Исторически проблема изоляции прикладного кода преследует нас со времени зарождения операционных систем. С появлением DOS и первых оконных менеджеров возникли сложности с ошибками приводящими к зависанию всей системы. Развитие концепции резидентных прогарам (ака демоны) усугубило ситуацию. И настоящим прорывом в решении это проблемы стала поддержка защищенного режима работы процессора в архитектуре x86. Для операционных систем нового поколения (windows, linux, freebsd) свойственно разделение кода операционной системы и прикладного кода.
Ядро операционной системы выполняется в привилигированном режиме, в котором оно обладает прямым доступом к памяти и аппаратным прерываниям.
В то время как пользовательские приложения выполняются в защищенном режиме работы, который является песочницей для них. Каждое приложение имеет свою песочницу (виртуальную память), и в штатном режиме никак не может навредить соседним приложениям.

Следующим шагом эволюции стали технологии виртуализации. Это не следствие плохого дизайна защищенного режима работы процессора - он прекрасно справляется со своей задачей, более того его возможности полностью не используются современными ОС. Это своеобразное развитие технологии. Постепенно в пользовательской части ОС у приложений начало собираться столько персистирующих настроек, которые часто не совместимы меджу собой, что идея запустить в одной ОС несколько дочерних ОС перестала казаться контр продуктивной. Добавив набор расширеных инструкций для управления памятью и не только был реализован механизм виртуализации, позволивший запускать внутри ОС контейнеры виртуальных ПК, со своими собстсвенными (разными) ОС внутри.
Витруализация перевернула мир серверного ПО, породив разнообразные подходы к управлению инфарструктурой, сутью которых в целом было простое утрверждение - одна роль = одна виртуальная машина. Существует много разных реализаций виртуализации, от HyperV и VMWare, до KVM, OpenVZ и других.
Системы виртулизации соответсвтенно делят все ОС на Хост и Гостевые. Хост система может делать что угодно с гостевыми, поэтому обычно она хорошо защищена, в то время как гостевая система это фактически песочница, работающая с виртуальным процессором, виртуальной памятью и виртуальным диском. Таким образом виртуализция это дорогой, но в целом очень безопасный способ разграничения контекстов безопасности. Запуск двух гостевых систем без соединения их виртуальной сетью фактически считается равносильным запуску двух разных компьютеров.
Так же подход с виртуализацией сущесвтенно улучшил возможности по компоновке приложений в серверах - виртуальные машины переносимы, таким образом поверх физического уровня появился уровень абстракции в виде хост систем позволивший более гибко нарезать ресурсы физического оборудования, а так же перераспределять их по мере надобности.
Однако на этом прогресс не остановился - если мы поднимаем гостевую ОС, то мы поднимаем копию всех системынх служб. И получается что у нас на компьютерес 5ю гостевыми системами запущенно грубго говоря 6ть ядер операционной системы. Это фактическая стоимость виртуализации. Но что если мы можем разделить одно ядро между несколькими гостевыми ОС? На самом деле не можем.
Но появилась идея контейнерезации, когда в ОС заводится контейнер для запука приложения, который помимо виртуальной памяти предоставляет процессу еще и слепок файловой системы, доступные приложения и т.п. Грубо говоря мы пакуем вместе с приложением его окружение - файловую системы, зависимости и т.п. Несколько таких контейнеров будут использовать одно ядро операционной системы, что явно дешевле в плане затрат ресурсов.
Контейнерная изоляция очень дешевая в плане ресурсов, но не есть по факту признанно безопасной. Дело в том что приложение запщенное в контейнере имеет доступ к ядру ОС, и может атаковать его, что приведет к поломке всех контейнеров запущенных в ОС. Поэтому безопасности контейнеров уделяется много внимания и в продакшен среде не запускаются контейнеры неопределенного происходждения на узлах с критически важными елементами инфраструктуры.
Развитие подходов контейнеризации привело к появлению сложных систем оркестрации для запука тысячь контейнеров (k8s, swarm etc). Но в плане изоляции кода - это как был не самый надежный механизм, так им и остается.