Евгений Штольц
Облачная экосистема
Аннотация
В книге на практике рассматриваются более 70 (76) инструментов:
* платформы Google Cloud Platform, Amazone WEB Services, Microsoft Azure;
* консольные утилиты: cat, sed, NPM, node, exit, curl, kill, Dockerd, ps, sudo, grep, git, cd, mkdir, rm, rmdir, mongos, Python, df, eval, ip, mongo, netstat, oc, pgrep, ping, pip, pstree, systemctl, top, uname, VirtualBox, which, sleep, wget, tar, unzip, ls, virsh, egrep, cp, mv, chmod, ifconfig, kvm, minishift;
* стандартные инструменты: NGINX, MinIO, HAProxy, Docker, Consul, Vagrant, Ansible, kvm;
* инструменты DevOps: Jenkins, GitLab CI, BASH, PHP, Micro Kubernetes, kubectl, Velero, Helm, "http нагрузочное тестирование";
* облачные Traefic, Kubernetes, Envoy, Istio, OpenShift, OKD, Rancher,;
* несколько языков программирования: PHP, NodeJS, Python, Golang.
Контейнеризация
История развития инфраструктуры
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 решений, позволяющие устанавливать программное обеспечение на множество машин, не связанное связкой лицензия процессор;
* созревание телекоммуникационной инфраструктуры;
* увеличении надёжности за счёт распределения точек отказов;
* возможность наращивания производительности при потребности в будущем за счёт добавления новых компонентов.
Следующим этапом слала унификация, наибольшее проявлявшаяся в 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 и библиотеками поддержки разных браузеров, который требует компилятора RUBY и подобная связка, обычно, с первого раза не работает. А для JS использовался CoffeScript. Всё это нужно прогонять через программы сжатия и валидации (валидировать HTML обычно не нужно).