Евгений Штольц - Из разработчика в архитекторы. Практический путь

Контейнеризация

История развития инфраструктуры

Limoncelli (автор "The Practice of Cloud System Administration"), работавший долгое в Google Inc, считает, что 2010 год – год перехода от эры традиционного интернет к эре облачных вычислений.

* 1985–1994 – время мэйнфреймов (больших компьютеров) и внутрикорпоративного обмена данных, при котором

можно легко планировать нагрузку

* 1995–2000 – эра появления интернет компаний,

* 2000-2003

* 2003-2010

* 2010-2019

Увеличение производительно отдельно машины меньше, чем прирост стоимости, например, увеличении производительности в 2 раза приводит к увеличению стоимости существенно большей, чем в 2 раза. При этом, каждое следующее увеличении производительности обходится кратно дороже. Следовательно, каждый новый пользователь обходился дороже.

Позже, в период 2000–2003 годах, смогла сформироваться экосистема, предоставляющая принципиально другой подход:

* появление распределённых вычислений

* появление маломощных массовой аппаратуры

* созревание OpenSource решений, позволяющие устанавливать программное обеспечение на множество машин,

не связанное связкой лицензия процессор

* созревание телекоммуникационной инфраструктуры

* увеличении надёжности за счёт распределения точек отказов

* возможность наращивания производительности при потребности в будущем за счёт добавления новых

компонентов

Следующим этапом слала унификация, наибольшее проявлявшаяся в 2003–2010 годах:

* предоставление в дата центре не места в шкафу (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, при