Евгений Штольц
Из разработчика в архитекторы. Практический путь
Контейнеризация
История развития инфраструктуры
Limoncelli (автор "The Practice of Cloud System Administration"), работавший долгое в Google Inc, считает, что 2010 год год перехода от эры традиционного интернет к эре облачных вычислений.
* 19851994 время мэйнфреймов (больших компьютеров) и внутрикорпоративного обмена данных, при котором
можно легко планировать нагрузку
* 19952000 эра появления интернет компаний,
* 2000-2003
* 2003-2010
* 2010-2019
Увеличение производительно отдельно машины меньше, чем прирост стоимости, например, увеличении производительности в 2 раза приводит к увеличению стоимости существенно большей, чем в 2 раза. При этом, каждое следующее увеличении производительности обходится кратно дороже. Следовательно, каждый новый пользователь обходился дороже.
Позже, в период 20002003 годах, смогла сформироваться экосистема, предоставляющая принципиально другой подход:
* появление распределённых вычислений
* появление маломощных массовой аппаратуры
* созревание OpenSource решений, позволяющие устанавливать программное обеспечение на множество машин,
не связанное связкой лицензия процессор
* созревание телекоммуникационной инфраструктуры
* увеличении надёжности за счёт распределения точек отказов
* возможность наращивания производительности при потребности в будущем за счёт добавления новых
компонентов
Следующим этапом слала унификация, наибольшее проявлявшаяся в 20032010 годах:
* предоставление в дата центре не места в шкафу (power-location), а уже унифицированного железа
закупленного оптом для всего цента
* экономия на ресурсах
* виртуализация сети и компьютеров
Следующую веху положил Amazon в 2010 году и ознаменовал эру облачных вычислений. Этап характеризуется строительством масштабных дата центов с заведомым избытком по мощностям для получения меньшей стоимости вычислительных мощностей за счёт опта в расчёте на экономию для себя и выгодную продажу их избытка в розницу. Такой подход применяется не только к вычислительной мощности, инфраструктуре, но и программному обеспечению, формирую его как сервисы для удешевления их использования за счёт их продажи в розницу как большим компаниям, так и начинающим.
Необходимость однотипности окружения
Обычно начинающие разработчики разрабатывающие под Linux предпочитают работать из под Windows, чтобы не изучать незнакомую ОС и набивать на ней свои шишки, ведь раньше всё было далеко не всё так просто и так отлажено. Часто разработчики вынуждены работать из под Windows из-за корпоративных пристрастий: 1C, Directum и другие системы работают только на Windows, и вся остальная, а главное сетевая, инфраструктура заточена под эту операционную систему. Работа из Windows приводит к большим потерям рабочего времени как разработчиков, так и DevOps на устранения как мелких, так и крупных отличий в операционных системах. Эти отличия начинают проявляться от самых простых задач, например, что может быть проще сверстать страничку на чистом HTML. Но неправильно настроенный редактор поставит в BOM и переводы строк, принятые в Windows: "\n\r" вместо "\n"). BOM при склейке шапки, тела и подвала страницы создаст отступы между ними, они не будут видны в редакторе, так как эти они образуются байтами метаинформации о типе файла, в Linux которые не имеют такого значения и воспринимаются как перевод отступ. Другие переводы строк в GIT не позволяет увидеть сделанные вами отличие, ведь отличие в каждой строке.
Теперь возьмём front разработчика. С первого взгляда, что сложного, ведь JS (JavaScript), HTML и CSS нативно интерпретируются браузером. Раньше делалась вёрстка всех разных страниц проверялась дизайнером и заказчиком и отдавалась php разработчику на интеграцию с фреймворком или cms. Для того, чтобы не править шабпку на каждой страницы, а потом долго выяснять, когда они начали отличаться и какая из них правильнее использовался HAML. HAML добавляет дополнительный синтаксис в HTML, чтобы избежать булирования: циклы, подключения файлов, в нашем случае единую шапку и подвал страницы. Но он требует специальной программы, перегоняющий HTML в чистый HTML. В MS Windows это решается установкой программы компилятора и подключением её к IDE, благо все эти возможности есть в IDE WebStorm. С CSS и его размером, дублями, зависимостями и поддержкой для разных браузеров всё гораздо сложнее там использовался LESS, а сейчас возглавил более функциональный SASS и библиотеками поддержки разных браузеров, который требует компилятора Rubi и подобная связка, обычно, с первого раза не работает. А для JS использовался CoffeScript. Всё это нужно прогонять через программы сжатия и валидации (валидировать html обычно не нужно).
Когда проект начинает расти и перестаёт быть отдельными страницами с "JS вставками", а становится SPA (Single Page Application, одно страничными веб приложениями), где всё создаётся js, и уже сборщиков (Galp, Grunt), менеджеров пакетов и NodeJS не собирается, сложностей становится всё больше. Все эти программы бесплатные и изначально разрабатывались для Linux, предназначены для работы из консоли Bash и под Windows ведёт себя не всегда хорошо и трудно автоматизируются в графических интерфейсах, не смотря на старания IDE разработчиков. Поэтому, многие Web разработчики перешли с MS Windows на MacOS, который является ответвление UNIX систем, в него изначально встроен bash.
Docker как легковесные виртуальные машины
Изначально, проблема изоляции положений и проектов решалась виртуализацией системным программный обеспечением, которое эмулирует на определённом уровне среду, которой может быть аппаратное обеспечение (компьютер как набор компонентов, таких как процессор, оперативная память, сетевое устройство и другие при необходимости) или, реже, операционная система. Системный администратор выбирает объём оперативной памяти (не более свободной), процессор, сетевое устройство. Устанавливает операционную систему и, при необходимости, драйвера, устанавливает необходимые программы. Если нужно рабочее место для второго разработчика совершает те же действия. Для установки программ смотрит в каталог /bin первого и устанавливает недостающие. И тут возникает первая тихая проблема, пока не проявившаяся, что программы устанавливаются разных версий, но это будет головной болью уже разработчиков, если у одного разработчика наработает, а у другого нет, или головной болью этого сисадмина если у разработчика работает, на продакшне нет.
С ростом числа рабочих мест, добавляются следующие проблемы:
* Вам доступно менее 30 % производительности от родительской системы, ведь все команды, которые должен выполнять
процессор, выполняются программой виртуализации. Повысить производительность позволяет режим процессора VT-X, при
котором процессор напрямую выполняет команды из виртуального окружения, а в случаи несовместимости кидает
исключение. Правда эти броски в сотни раз затратнее обычных команд, поэтому взрослые системы виртуализации
(VirtualBox, VMVare, и другие) стараются отфильтровать и модифицировать потенциально несовместимые команды, что
позволяет существенно повысить производительность.
* Каждое рабочее место приходится создавать заново, для этого системный администратор пишет скрипт
автоматизирующий этот процесс, но он естественно не идеален, и его приходя постоянно актуализировать, вносить
патчи несовместимостей того, что устанавливали программисты.
* Линейное увеличение занимаемого дискового пространства от числа контейнеров, и экспоненциальное от версий
продукта, при том, что один инстанс занимает очень много места. То есть, каждая песочница содержит инстанс
эмуляции программы, образ операционной системы, все установленные программы и код разработчика, что весьма
немало. Единственное, что одно установка самой виртуальной машины, и то, только в рамках одного физического
сервера. Например, если разработчиков у нас 10, то и размер будет в 10 раз больше, при 3 версиях продукта в
30.
Все эти недостатки для Web призван решить Docker. Здесь и далее мы будем говорить о Docker для Linux, и не будем рассматривать несколько отличающиеся реализацию ядра у FreeBSD, и реализацию для Windows 10 Professional, внутри которой закупается либо урезанное ядро Linux, либо независимая разработка контейнеризации Windows. Основная идея заключается не в создании прослойки (виртуализации аппаратного обеспечения, своей ОС и гипервизора), а в разграничении прав. Вы не множите поставить в контейнер MS Windows, но можете поставить и RedHut и Debian, так как ядро одно, а отличии в файлах, создавая песочницу (отдельный каталоги и запрещая выходить за его приделы) с этими файлами. Также, мы говорим о Web решениях, так как для нативных решений могут возникнуть проблемы, когда программе не обходимо иметь монопольный доступ из контейнера (песочницы Docker) к ядру ОС, например, для нативной отрисовки окон. Также можно ограничить объём памяти, процессорного времени, количества процессов.
Легковесная виртуализация или невесомая изоляция взгляд на реализацию Docker
Давайте взглянем на историю появления предпосылок появления Docker, именно предпосылок, так как сам Docker не реализует ни изоляции, ни тем более виртуализации, а организует работу с ней с первой. В отличии от виртуализации напоминающей ангар со своим миром и своим фундаментом на который можно наложить, что душе пожелает, например, выдаём и лужайку, то для изоляции можно провести аналогию с забором. Изоляция появлялась в ядре Linux постепенно, частями, отвечающих за разные уровни, а параллельно появлялись программы обеспечивающие интерфейс и концепцию применения этой изоляции в реальных проектах. Изоляция состоит из 6 типов ограничения ресурсов.