Из разработчика в архитекторы. Практический путь

Евгений Сергеевич Штольц, 2020

В этой книге главный Архитектор Департамента Архитектуры Управления Технической Архитектры Центра Облачных Компетенций Cloud Native Сбербанка делится знанием и опытом с читателей, накопленным при разработке своих и оценке чужих архитектур, предоставляя базис для профессионального и карьерного роста.

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

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

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, при

котором процессор напрямую выполняет команды из виртуального окружения, а в случаи несовместимости — кидает

исключение. Правда эти броски в сотни раз затратнее обычных команд, поэтому взрослые системы виртуализации

(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 типов ограничения ресурсов.

Первым в ядро была изоляция файловой системы, позволяющий создать песочницу с помощью команды chroot ещё в 1979 году, из вне песочница видна полностью, но при переходе внутрь папка над которой выполнена команда становится корневой, и вернуться уже не удастся. Следующий было разграничение процессов, так песочница существует и хостовая система, пока существует процесс с pid (номером) 1. Для песочницы он свой, вне песочницы он обычный процесс. Далее подтянулись стальные разграничения CGrups: групп пользователей, памяти и другие. Всё это существует в ядре любого Linux, независимо от того, установлен Docker или нет у вас. На всём протяжении истории принимались попытки, OpenSource и коммерческие, создавать контейнера, разрабатывая функционал самими и подобные решения находили своих пользователей, но они не проникли в широкие массы. Docker в начале своего существования использовал довольно стабильное, но сложное в использовании решение контейнеризации LXC. Постепенно он заменил LXC на нативные CGroup. Также Docker поддерживает солёность своего образа (об этом далее), но сам её не реализует, а использует UnuonFS (UFS).

Docker и дисковое пространство

Поскольку Docker не реализует функционал, а использует заложенный в ядро Linux, и не имеет под капотом графического интерфейса, сам он занимает очень мало места.

Поскольку контейнер использует ядро хостовой ОС, то в базовом образе (обычно ОС) содержатся только дополняющие его пакеты. Так Docker образ Debian занимает 125Mb, а ISO образ — 290Mb. Для проверки, что используется одно ядро в контейнере выведем о нём информацию: uname — a или cat /proc/version, а информацию о самом окружении контейнера cat /etc/ussue

Docker создаёт образ на основе инструкции в файле Dockerfile, который может быть находится удалённо или локально, и по нему может быть создан в любой момент. Поэтому, если вы не используете образ в данный момент, то можно удалить его. Исключением является образ, созданный на основе контейнера командой docker commit, но так создавать не очень правильно, и всегда можно выделить из образа Dockerfile командой docker history и удалить образ. Преимуществом хранения образов является то, что не требуется ожидать, пока он создаётся: скачивается ОС и библиотеки.

Сам Docker использует образ под названием Image, который создаётся на основе инструкций в файле Dockerfile. При создании нескольких контейнеров на его основе место практически не увеличивается, так как контейнер — всего лишь процесс и конфиг настроек. При изменении файлов в контейнере сами файлы не сохраняются, а сохраняются внесённые изменения, который будут удалены после переброски контейнера. Это гарантирует в 99 % случаев полностью идентичное окружение, и как следствие не важно помещать подготовительные операции, общие для всех контейнеров по установке специфичных программ в образ, побочным эффектом которого является отсутствии их дублирования. Чтобы иметь возможность сохранять данные используется монтирование папок и файлов к хостовой (родительской) системе. Поэтому вы можете на обычном компьютере запустить сто и более контейнеров, при этом не увидите изменения в свободном местное на диске. При этом, если разработчики пользуются гит, а как же без него, и часто коммитятся, то может отпасть необходимость в монтировании папок с исходным кодом.

Образ докеров не представляет из себя монолитный образ вашего продукта, а — слоёный пирог образов, слои которого кэшируется. Это позволяет значительно сэкономить время на создание образа. Кэширование можно отключить ключом команды build — no-cache=true, если Docker не распознаёт, что данные изменяемы. Докер может увидеть изменения в инструкции ADD, добавляющий файл из хостовой системы в контейнер по хэшу файла, Так если вы создадите два контейнера, один с Nginx, а другой с MySQL, оба которых основаны на ОС Ubuntu 14.04, то будет существовать три слоя образа: MySQL, Nginx и Ubuntu. Сдоли образа можно посмотреть командой docker history. Также это работает и для ваших проектов — при копировании в Ваш образ 2 версий кода командой ADD с вашим продуктом, у вас будет 3 слоя и два образа: базовый, с кодом первой версии и кодом второй версии, независимо от количества контейнеров. Количество слоёв ограниченно 127. Важно заметить, что при клонировании проекта нужно указать версию, а не просто git clone, а git clone — branch v1 и git clone — branch v2, иначе Docker закэширует слой, создаваемый командой git clone и при создании второго образа мы получим тоже самое.

Docker не занимает ресурсы, а лишь их ограничивает, если это задано в настройках при создании контейнера (для памяти ключ m, для процессора — c). Поскольку Docker поддерживает разные файловые системы контейнеризации, настраивать, унифицированного интерфейса нет. Но, в любом случае, потребляется ресурс столько, сколько требуется, а не столько сколько выделено, как в виртуальных машинах.

Такая забота о занимаемом дисковом пространстве и невесомость самих контейнеров влечёт безответственность в скачивании образов и создании контейнеров.

Сборка мусора контейнером

За счёт того, что контейнер даёт намного большие возможности, чем виртуальная машина, ситуация осложняется оставление мусора после работы docker. Проблема решается просто запуском сборщика мура, появившегося в версии 1.13 или более сложно для более ранних версий написанием нужно Вам скрипта.

Так же, как просто создать контейнере docker run name_image, также просто его и удалить docker rm — f id_container. Часто, для того, чтобы просто поэкспериментировать, удобно запустить контейнер в интерактивном режиме docker run — ti name_image bash и мы стразу же окажемся в контейнере. Когда мы выйдем из него Cntl+D, он будет остановлен. Для того, чтобы поле выхода он был автоматически удалён используйте параметр — rm. Но, поскольку контейнеры столь невесомы, их так просто создать, их часто бросают и не удаляют, что приводит к их стремительному росту. Посмотреть на работающие можно командой docker ps, а и на остановленные — docker ps — a. Для предотвращения этого используйте сборщик мусора docker containers prune, который появился в версии 1.13 и который удалит все остановленные контейнера. Для более ранних версий используйте скрипт dorker rm $(docker ps — q — f status=exited). Если её запуск для Вас не желателен, скорее всего вы неправильно используете docker, так как запасть контейнер из образа практически также быстро и просто, как и восстановить его работу. Если в контейнере нужно сохранять состояние, то для этого используется монтирование папок или томов.

Чусть более сложная ситуация обстоит с образами. При создании контейнера, если нет образа, он будет скачен. По скольку, один образ может быть для нескольких контейнеров, то при удалении самого контейнера он не удаляется. Его прийдётся удалять вручную docker rmi name_image, а если он используется — просто будет выдано предупреждение. За экономию дискового пространства приходится платить тем, что docker не может просто определить, нужен образ ещё или нет. С версии 1.13 он может, с помощью команды docker imgae prune — a может проанализировать, какие образа не используются контейнерами и их удалить. Здесь нужно быть более осторожным, если docker не может получить образ снова, но допущение подобной ситуации не очень правильно. Одной такой ситуацией является создание класторного образа, при этом конфиг Dockerfile, описывающий процесс его создания, был утерян, в противном случае из Dockerfile можно получить образ командой docker build name_image. Правильно же сразу же принять меры и восстановить Dockerfile из образа, посмотрев на команды создающие образа с помощью docker history name_image. Второй ситуаций является создание образа из работающего контейнера командой docker commit, а не из Dockerfile, так активно популяризуемого, но также активно осуждаемого.

Так как образ состоит из слоёв, совместно используемых в разных образах, то в разных нештатных ситуациях эти слои остаются. Поскольку отдельно мы их использовать не можем, то безопасно их удалить командой docker image prune.

Для сохранения результатов работы контейнера можно примонтировать папку хостовой машины к папке контейнера. Мы можем явно указать папку на хостовой манине, например, docker run — v /page_host:/page_container nama_image, или дать возможность сгенерировать её docker run — v /page_container nama_image. Для удаления сгенерированных папок (томов), которые уже не используются контейнерами введите команду docker valume prune. Для сборки неиспользуемых сетей, также есть свой сборщик мусора.

Также есть единый сборщик мусора, по факту, просто объединяющий специализированные в один с логически совместимыми параметрами docker system prune. Имеется тенденция его ставить в крон. Можно также посмотреть на занимаемое место всеми контейнерами, всеми образами и всеми томами с помощью команды docker system df, а также без группировки — docker system df — v.

Многие проблемы, описанные здесь созданием мусора решаются программой docker-compose. К тому же она существенно упрощает жизнь, если только вы не запустили контейнера разово для экспериментов. Так команда docker-compose up запускает контейнера, а docker-compose down — v их удаляет, также удаляются все зависимости между ними. Все параметры запуска контейнера описываются в docker-compose.yml, а также связи между ними. Благодаря этому, при изменении параметров запуска контейнеров не нужно заботиться, чтобы удалить старые и создать новые, не нужно прописывать все параметры контейнеров — просто запасть с параметром up и она либо пересоздаст, либо обновит конфигурацию контейнера.

Для недопущения захламления системы в docker имеется встроенное настраиваемое ограничение на количество контейнеров и образов, напоминающее о необходимости производить чистку системы запуском сборщика мусора.

Экономия времени на создание контейнера

Мы уже познакомились в предыдущей теме об образах, об их слоях и кэшировании. Давайте рассмотрим их с точки зрения времени создания контейнера. Почему же это столь важно, ведь по аналогии с виртуализацией, системный администратор запустил создание контейнера и пока он передаёт его программисту, к этому времени он уже точно соберётся. Важно заметить, что много с тех пор изменилось, а именно поменялись принципы и требования к экосистеме и её использования. Так, например, если раньше разработчик, разработав и проверив свой код на своём рабочем месте отправлял его QA менеджеру для тестирования на соответствии бизнес требованиям, и уже когда дойдёт очередь у него к этому коду, тестировщик на своём рабочем месте запустит этот код и проверит. Теперь инфраструктурой занимается DevOps, который налаживает непрерывный процесс доставки разработанных программистами фич, а контейнеры создают в автоматическом режиме при каждом отправкой, в ветку продакшна для проведения автоматического тестирования. При этом, чтобы работа одних тестов не влияла на работу других, под каждый тест создаётся отдельный контейнер, а зачастую тесты идут параллельно, чтобы моментально показать результат разработчику, пока он помнит, что он сделал и не переключил своё внимание на другую задачу.

Для стандартных программы: не нужно устанавливать, не нужно поддерживать

Мы, часто используем огромного количество готовых решений. При выборе решения, мы сталкиваемся с дилеммой: с одной стороны оно более универсальное и более проверенное, чем мы можем себе позволить сделать, с другой оно достаточно сложное, чтобы самим разобраться как правильно его установить и настроить, чтобы установить все зависимости, разрешить конфликты, настроить на первоначальное использование. Теперь установка и настройка стала гораздо проще, стандартизированней, во многом отсутствуют низкоуровневые проблемы. Но прежде чем продолжать, давайте отвлечёмся и посмотрим на процесс от начала получения до начало использования приложения в рамках истории:

* В те времена, когда все программы писались на ассемблере, программы распространялись по почте, у уже

пользователи устанавливали и тестировали, ведь тестирование в компаниях не было предусмотрено. В случае

возникновения проблем, пользователь сообщал компании разработчику о проблемах и после их устранения, получал по

почте уже исправленную версию на диске. Процесс очень долгий и пользователь сам тестировал.

* Во время распространения на дисках уже компании писали свои программные продукты на более высокоуровневых

языках, проверяли под разные версии ОС. Здесь и далее будем рассматривать свободное ПО. Программа уже содержала

MakeFile, который сам компилировал программу и её устанавливал.

* С появление интернета массово ПО устанавливается с помощью пакетных менеджеров, при выходе которых, из

удалённого репозитория ОС оно скачивается и устанавливается. Он старается следить и поддерживать совместимость

совместимость программ. Дальнейшее изучение и использование программы: как запустить, как настроить, как понять

что она работает ложится на пользователя или системного администратора.

* С появлением Docker Hub и Web приложения скачиваются и запускаются контейнером. Его, обычно, для начальной

работы не нужно настраивать.

Безопасность и надёжность

но и для контейнеров и образов в целом у сервера: объёма свободно места и занимаемого пространства. По умолчания для всех контейнеров и образов отводится 10G, при этом из этого объёма должно оставаться как dm.min_free_space=5 %, но лучше поместить в конфиг, который возможно прийдётся создать как /etc/docker/daemon.json:

{

"storage-opts": [

"dm.basesize=50G",

"dm.min_free_space=5 %",

]

}

Можно ограничить ресурсы потребляемые контейнером в его настройках:

* — m 256m — максимальный размер потребления оперативной памяти (здесь 256Mb);

* — c 512 — вес приоритета на использование процессора (по умолчанию 1024);

* — cpuset="0,1" — номера разрешённых к использованию ядер процессора.

Управление контейнерами

Мы управляем контейнерами с помощью команды Docker. Теперь, допустим, появилась необходимость управлять удалённо. Использовать VNC, SSH или другое для управления командой Docker наверное, будет слишком трудоёмким если задача усложнится. Правильно, сперва будет разобраться, что из себя представляет Docker, ведь команда Docker и программа Docker не одно и тоже, а точнее команда Docker является консольным клиентом для управления клиент серверным приложение Docker Engine. Команда взаимодействует с сервером Docker Mashine через Docker REST API, который и предназначен для удалённого взаимодействия с сервером.

Передача и распространение продукта

Для передачи проекта, например, заказчику, и распространения между разработчиками и серверами можно использовать установочные скрипты, архивы, образа и контейнера. Каждый из этих способов распространения проекта имеет свои особенности, недостатки и преимущества. Давайте о них поговорим и сравним.

строк, но главное, что у неё есть специальный режим, включаемый ключом — p, который выводит динамически нужно нам количество строк, при поступлении новых — обновляет вывод, например, docker logs name_container tail — p.

Когда приложений становится слишком много, чтобы вручную мониторить их работу по отдельности целесообразно логи приложений централизовать. Для централизации могут быть использованы многочисленные программы, которые собирают логи от разных сервисов и направляют их в центрально хранилище, например, Fluentd. Для хранения логов удобно использовать ElasticSearch, просто записывая их в поисковик. Очень желательно, чтобы логи были в структурированном формате — json. Это позволит их сортировать, отбирать нужные, выявлять тенденции с помощью встроенных агрегатных функций, проводить анализ и прогнозирование, а не только поиск по тексту. Для анализа веб-интерфейс Kibana, в ходящий в состав стека Elastic.

Не только для долгоиграющих приложений важно логирование. Так для тестовых контейнеров, удобно получить вывод пройденных тесто. Так можно сделать, прописав в DockerFile в секции CMD: npm run, который прогонит тесты.

Хранилище образов:

* публичный и приватный docker hub (http://hub.docker.com)

* для закрытых и секретных проектов можно создать собственное хранилище образов. Образ называется reginstry

Docker для создания приложений и одноразовые работы

В отличии от виртуальных машин запуск которых сопряжён с значительными человеческими и вычислительными затратами Docker часто применяется для для выполнения одноразовых действий, когда программное обеспечение требуется запустить разово, и желательно не тратить усилии на установку и удаление его. Для этого запускается контейнер, который примонтирован к папке с нашим приложением, который выполняет над ним требуемые действия и после их выполнения удаляется. В качестве примера можно проект на JavaScript, для которого нужно провести сборку и выполнить тесты. При этом сам проект не использует NodeJS, а содержит только конфиги сборщика, например, WebPack-ка, и написанные тесты. Для этого запускаем контейнер сборки в итеративном режиме, в котором можно управлять процессом сборки, если потребуется и после выполнения сборки контейнер остановится и само удалится, например, можно запустить в корне приложение что-то подобное: docker run — it — rm — v $(pwd):app node-build. Аналогичным образом можно провести тесты. В результате приложение собрано и протестировано на тестовом сервере, но при этом программное обеспечение не требующееся для его работы на продакшн сервере не буде усыновлено и потреблять ресурсы, и может быть перенесено на продакшн сервер, наприер с помощью контейнера. Чтобы не писать документация на запуску сборки и тестированию можно положить два соотвующих конфига docker-compose-build.yml и docker-compose-test.yml и вызывать их docker-compose up — f./docker-compose-build.

Управление и доступ

По умолчанию, для безопасности, клиент общается с сервером через unix сокет (специльаный файл /var/run/socket.sock), а не через сетевой сокет. Дял работы через unix сокет можно использовать указать программе отправки запросов curl его использовать curl — unix-socket /var/run/docker.sock http:/v1.24/containers/json, но это возможность поддерживается с версии curl 1.40, которая пока не поддерживается в CentOS. Для решения этой проблемы и взаимодействия между удалёнными серверами используем сетевой сокет. Для активации его останавливаем сервер systemctl stop docker и запускаем его с настройками dockerd — H tcp://0.0.0.0:9002 & (слушать всех на порту 9002, что не допустимо для продакшна). После запуска команда docker ps не будет работать, а будет docker — H 5.23.52.111:9002 ps или docker — H tcp://geocode1.essch.ru:9202 ps. По умолчанию docker использует для http порт 2375, а для https — 2376. Чтобы не менять везде код и каждый раз не указывать сокет, пропишем его в переменных окружения:

export DOCKER_HOST=5.23.52.111:9002

docker ps

docker info

unser DOCKER_HOST

Важно прописать export для обеспечения доступности переменной всем программам: дочерним процессам. Также не должно стоять пробелов вокруг =. Теперь мы так можем обращаться из любого места находящимся в одной сети сервером dockerd. Для управления удалёнными и локальными Docker Engine (Docker на хостах) разработана программа Docker Mashine. Взаимодействие с ней осуществляется с помощью команды docker-machine. Для начала установим:

base=https://github.com/docker/machine/releases/download/v0.14.0 &&

curl — L $base/docker-machine-$(uname — s)-$(uname — m) >/usr/local/bin/docker-machine &&

chmod +x /usr/local/bin/docker-machine

Группа взаимосвязанных приложений

У нас уже есть несколько разных приложений, допустим, таких как Nginx, MySQL и наше приложение. Мы их изолировали в разных контейнерах, теперь она не конфликтуют между собой и Nginx и NySQL мы не стали тратить время и усилия на изготовление собственной конфигурации, а просто скачали: docker run mysql, docker run Nginx, а для приложения docker build.; docker run myapp — p 80:80 bash. Как видно, казалось бы, всё очень просто, но есть два момента: управление и взаимосвязь.

Для демонстрации управления возьмём контейнер нашего приложения, и реализуем две возможности — старт и создание (переборку). Для ручного старта, когда мы знаем, что контейнер уже создан, но просто остановлен, достаточно выполнить docker start myapp, но для автоматического режима этого недостаточно, а нам нужно написать скрипт, который бы учитывал, существует ли уже контейнер, существует ли для него образ:

if $(docker ps grep myapp)

then

docker start myapp

else

if! $(docker images grep myimage)

docker build.

fi

docker run — d — name myapp — p 80:80 myimage bash

fi

А для создания нужно удалить контейнер, если он существует:

if $(docker ps grep myapp)

docker rm — f myapp

fi

if! $(docker images grep myimage)

docker build.

fi

docker run — d — name myapp — p 80:80 myimage bash

Понятно, что нужно общими параметры, название образа, контейнера вывести в переменные, проверить, что Dockerfile есть, он валидный и только после этого удалять контейнер и много другого. Для понимания реального масштаба, на вдаваясь во взаимодействие контейнеров, о клонировании (масштабирование) этих групп и тому подобного, а только упомяну, то что команда docker run может превышать один — два десятка строк. Например, десяток проброшенных портов, монтируемых папок, ограничения на память и процессор, связи с другими контейнерами и ещё немного специфичных параметров. Да, это нехорошо, но делить в таком варианте на множество контейнеров сложно, из-за отсутствия карты взаимодействия контейнеров. Но возникает вопрос: Не много ли нужно делать, чтобы просто предоставить пользователю возможность стартовать контейнер или пересобрать? Зачастую ответ системного администратора сводится к тому, что давать доступы можно только избранным. Но и тут есть решение: docker-compose — инструмент для работы с группой контейнеров:

#docker-compose

version: v1

services:

myapp:

container-name: myapp

images: myimages

ports:

— 80:80

build:.

Для старта docker-compose up — d, а для переборки docker down; docker up — d. Причём, при изменении конфигурации, когда не нужна полная переборка, произойдёт просто её обновление.

Теперь, когда мы упрости процесс управления одиночным контейнером, давайте поработаем с группой. Но тут, для нас изменится только сам конфиг:

#docker-compose

version: v1

services:

mysql:

images: mysql

Nginx:

images: Nginx

ports:

— 80:80

myapp:

container-name: myapp

build:.

depence-on: mysql

images: myimages

link:

— db: mysql

— Nginx: Nginx

Здесь мы видим всю картину в целом, контейнера связаны одной сетью, где приложение может обращаться к mysql и Nginx по хостам db и Nginx, соответственно, контейнер myapp будет создан, только когда после поднятия базы данных mysql, даже если это займёт некоторое время.

Service Discovery

С ростом кластера вероятность падения нод вырастает и ручное обнаружение произошедшего усложняется, для автоматизации обнаружение вновь появившихся сервисов и их исчезновение предназначены системы Service Discovery. Но, чтобы кластер мог обнаруживать состояние но, учитывая, что система децентрализована — ноды должны уметь обмениваться сообщениями с друг другом и выбирать лидера, примерами могут быть Consul, ETCD и ZooKeeper. Мы рассмотрим Consul исходя их следующих его особенностей: вся программа — одни файл, крайне прост в работает и настройке, имеет высокоуровневый интерфейс (Zookiper его не имеет, полагается, что со временем должны появиться сторонние приложения, его реализующие), написан на не требовательном языке к ресурсам вычислительной машины (Consul — Go, Zookeeper — Java) и пренебрегли его поддержкой в других системах, такай как, например, ClickHouse (поддерживает по умолчанию ZooKeeper).

Проверим распределение информации между нодами с помощью распределенного key-value хранилища, то есть, если мы в одну ноду добавили записи, то они должны распространиться и на другие ноды, при этом жёстко заданного координирующего (Master) ноды у неё не должно быть. Поскольку Consul состоит из одного исполняемого файла — скачиваем его с официального сайта по ссылке https://www.consul.io/downloads.html на каждой ноде:

wget https://releases.hashicorp.com/consul/1.3.0/consul_1.3.0_linux_amd64.zip — O consul.zip

unzip consul.zip

rm — f consul.zip

Теперь необходимо запустить одну ноду, пока, как master consul — server — ui, а другие как slave consul — server — ui и consul — server — ui. После чего остановим consul, находящийся в режиме master, и запускаем его как равного, в результате consul-ы переизберут временного лидера, а в случае иго падения, переизберут снова. Проверим работу нашего кластера consul members:

consul members;

И так проверим распределение информации нашего хранилища:

curl — X PUT — d 'value1…..:8500/v1/kv/group1/key1

curl — s…..:8500/v1/kv/group1/key1

curl — s…..:8500/v1/kv/group1/key1

curl — s…..:8500/v1/kv/group1/key1

Настроим мониторинг сервисов, подробнее в документации https://www.consul.io/docs/agent/options.html#telemetry, для этого…. https://medium.com/southbridge/monitoring-consul-with-statsd-exporter-and-prometheus-bad8bee3961b

Чтобы не настраивать, воспользуемся контейнером и режимом для разработки с уже настроенным IP-адресом на 172.17.0.2:

essh@kubernetes-master:~$ mkdir consul && cd $_

essh@kubernetes-master:~/consul$ docker run — d — name=dev-consul — e CONSUL_BIND_INTERFACE=eth0 consul

Unable to find image 'consul: latest' locally

latest: Pulling from library/consul

e7c96db7181b: Pull complete

3404d2df15cb: Pull complete

1b2797650ac6: Pull complete

42eaf145982e: Pull complete

cef844389e8c: Pull complete

bc7449359c58: Pull complete

Digest: sha256:94cdbd83f24ec406da2b5d300a112c14cf1091bed8d6abd49609e6fe3c23f181

Status: Downloaded newer image for consul: latest

c6079f82500a41f878d2c513cf37d45ecadd3fc40998cd35020c604eb5f934a1

essh@kubernetes-master:~/consul$ docker inspect dev-consul jq.[] .NetworkSettings.Networks.bridge.IPAddress'

"172.17.0.4"

essh@kubernetes-master:~/consul$ docker run — d — name=consul_follower_1 — e CONSUL_BIND_INTERFACE=eth0 consul agent — dev — join=172.17.0.4

8ec88680bc632bef93eb9607612ed7f7f539de9f305c22a7d5a23b9ddf8c4b3e

essh@kubernetes-master:~/consul$ docker run — d — name=consul_follower_2 — e CONSUL_BIND_INTERFACE=eth0 consul agent — dev — join=172.17.0.4

babd31d7c5640845003a221d725ce0a1ff83f9827f839781372b1fcc629009cb

essh@kubernetes-master:~/consul$ docker exec — t dev-consul consul members

Node Address Status Type Build Protocol DC Segment

53cd8748f031 172.17.0.5:8301 left server 1.6.1 2 dc1 < all>

8ec88680bc63 172.17.0.5:8301 alive server 1.6.1 2 dc1 < all>

babd31d7c564 172.17.0.6:8301 alive server 1.6.1 2 dc1 < all>

essh@kubernetes-master:~/consul$ curl — X PUT — d 'value1 172.17.0.4:8500/v1/kv/group1/key1

true

essh@kubernetes-master:~/consul$ curl $(docker inspect dev-consul jq — r.[] .NetworkSettings.Networks.bridge.IPAddress'):8500/v1/kv/group1/key1

[

{

"LockIndex": 0,

"Key":"group1/key1",

"Flags": 0,

"Value":"dmFsdWUx",

"CreateIndex": 277,

"ModifyIndex": 277

}

]

essh@kubernetes-master:~/consul$ firefox $(docker inspect dev-consul jq — r.[] .NetworkSettings.Networks.bridge.IPAddress'):8500/ui

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

dockerd — H fd:// — cluster-store=consul://192.168.1.6:8500 — cluster-advertise=eth0:2376

* — cluster-store — можно получать данные о ключах

* — cluster-advertise — можно сохранять

docker network create — driver overlay — subnet 192.168.10.0/24 demo-network

docker network ls

Простая кластеризация

В данной стать мы не будем рассматривать как создать кластер вручную, а воспользуемся двумя инструментами: Docker Swarm и Google Kubernetes — наиболее популярные и наиболее распаренные решения. Docker Swarm проще, он является частью Docker и поэтому, имеет наибольшую аудиторию (субъективно), а Kubernetes предоставляет гораздо большие возможности, большее число интеграций с инструментами (например, распределённое хранилище для Volume), поддержка в популярных облаках и более просто масштабируемый для больших проектов (большая абстракция, компонентный подход).

Рассмотрим, что такое кластер и что он нам хорошего принесёт. Кластер — это распределённая структура, которая абстрагирует независимые сервера в одну логическую сущность и автоматизирует работу по:

* случае падения одного сервера, переброс контейнеров (создания новых) на другие сервера

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

* создание контейнера на сервере, подходящем по свободным ресурсам

* Разворачивание контейнера, в случае выхода его из строя

* единый интерфейс управления из одной точки

* выполнения операций с учётом параметров серверов, например, размера и типа диска и особенностей

контейнеров, заданных администратором, например, связанные контейнера единым точкой монтирования

размещаются на данном сервере

* унификация разных серверов, например, на разных ОС, облачных и не облачных

Теперь мы перейдём от рассмотрения Docker Swarm к Kubernetes. Обе эти системы — системы оркестрации, обе работаю с контейнерами Docker (Kubernetes также поддерживает RKT и Containerd), но взаимодействий между контейнерами принципиально другое из-за дополнительного уровня абстракции Kubernetes — Pod. И Docker Swarm, и Kubernetes управляют контейнерами на основе IP адресов и распределяют их по нодам, внутри которых всё работает через localhost, проксируемый мостом, но в отличии от Docker Swarm, который работает для пользователя с физическими контейнерами, Kubernetes для пользователя работает с логическими — Pod. Логический контейнер Kubernetes состоит из физических контейнеров, сетевое взаимодействие между которыми происходит через их порты, поэтому они не дублируются.

Обе системы оркестрации используют оверлейную сеть (Overlay Network) между нодами хостами для эмуляции нахождения управляемых единиц в едином локальном сетевом пространстве. Данный тип сети является логическим типом, который использует для транспорта обычные сети TCP/IP и призвана эмулировать нахождение нод кластера в единой сети для управления кластером и обмена информации между его нодами, тогда как на уровне TCP/IP они не могут быть связанны. Дело в том, что, когда разработчик разрабатывает кластер, он может описать сеть только для одной ноду, а при развёртывании кластера создаётся несколько его экземпляров, причём их количество может динамически меняться, а в одной сети не может существовать трёх нод с одним IP адресами и подсетями (например 10.0.0.1), а требовать от разработчика указывать IP адреса неправильно, поскольку не известно, какие адреса свободны и сколько их потребуется. Данная сеть берёт на себя отслеживания реальных IP адресов узлов, которые могут выделяться из свободных рандомно и меняться по мере пересоздания нод к кластере, и предоставляет возможность обращаться к ним через ID контейнеров/подов. При таком подходе пользователь обращается к конкретным сущностям, а не динамики меняющимся IP адресам. Взаимодействие осуществляется с помощью балансировщика, который для Docker Swarm логически не выделен, а в Kubernetes он создаётся отдельной сущностью для выбора конкретной реализации, как и другие сервисы. Подобный балансировщик должен присутствовать в каждом кластере и но называется в рамках экосистемы Kuberntes сервисом (Service). Его можно объявить, как отдельно как Service, так и в описании с кластером, например, как Deployment. К сервису можно обратиться по его IP-адресу (посмотреть в его описании) или по имени, которое регистрируется как домен первого уровня во встроенном DNS сервере, например, если имя сервиса, заданного в метаданных my_service, то к кластеру можно обратиться через него так: curl my_service;. Это является довольно стандартным решением, когда компоненты системы вместе с их IP адресами меняются со временем (пересоздаются, добавляются новые, удаляются старые) — направлять трафик через прокси сервер, I P — или DNS адреса для внешней сети остаются постоянными, а внутренние могут меняться, оставляя заботу согласование их на прокси сервере.

Обе системы оркестрации использую оверлейную сеть Ingress для предоставления к себе доступа из внешней сети через балансировщик, который согласует внутреннею сеть с внешней на основе таблиц соответствия IP адресов ядра Linux (iptalbes), разделяя их и позволяя обмениваться информацией, даже при наличи одинаковых IP адресов во внутренней и внешней сети. А, вот, для поддержания соединения между этими потенциально конфликтными на IP уровне сетями используется оверлейнера Ingress сеть. Kubernetes предоставляет возможность создать логическую сущность — контроллер Ingress, который позволит настроить сервис LoadBalancer или NodePort в зависимости от содержимого трафика на уровне выше HTTP, например, маршрутизацию на основе путей адресов (application router) или шифрование трафика TSL/HTTPS, как это делаю GCP и AWS.

Kubernetes — результат эволюции через внутренних проектов Google через Borg, затем через Omega, на полученном опыте от экспериментов сложилась довольно масштабируемая архитектура. Выделим основные типы компонентов:

* Pod — обычный под

* ReplicaSet, Deployment — масштабируемые поды

* DaemonSet — в каждой ноде кластера он создаётся

* сервисы (отсортированы по мере важности): ClusterIP (по умолчанию, базовый для остальных), NodePort

(перенаправляет порты, открытые в кластере, у каждого пода, на порты из диапазона 30000-32767 для

обращения к конкретным подам из внешней), LoadBalancer (NodePort с возможностью создания публичного

IP-адреса для доступа в интернет в таких публичных облаках, как AWS и GCP), HostPort (открывает порты

на хостовой машине соответствующие контейнеру, то есть если в контейнере открыт порт 9200, он будет

открыт и на хостовой машине для прямого перенаправления трафика) и HostNetwork (контейнеры в поде

будут находиться в сетевом пространстве хоста)

Мастер как минимум содержит: kube-apiserver, kube-sheduler и kube-controller-manager. Состав слейва:

* kubelet — проверка работоспособности компонента системы (ноды), создание и управление контейнерами. Он находится на каждой ноде,

обращается к kube-apiserver и приводит в соответствие ноду, на которой расположен.

* cAdviser — мониторинг ноды

//http://linux-notes.org/nastrojka-docker-swarm-klastera-v-unix-linux/

Допустим у на есть хостинг и мы создали три AVS сервера. Теперь необходимо на каждый сервер установить docker и docker-machine, о том как это сделать было рассказано выше. Docker-machine сама является виртуальной машиной для doker контейнеров, мы собирем лишь внутренний для неё драйвер — virtualbox — чтобы не устанавливать дополнительные пакеты. Теперь, из операций, которые должны быть выполнены на каждом сервере останется создать doker машины, остальные же операции по настройки и созданию контейнеров на них можно выполнять из master-ноды, а они буду автоматически запущены на свободных нодах и перераспределяться при изменении их количества. Итак. запустим docker-machine на первой ноде:

docker-machine create — driver virtualbox — virtualbox-cpu-count «2» — virtualbox-memory «2048» — virtualbox-disk-size «20000» swarm-node-1

docker-machine env swarm-node-1 // tcp://192.168.99.100:2376

eval $(docker-machine env swarm-node-1)

Запускаем вторую ноду:

docker-machine create — driver virtualbox — virtualbox-cpu-count «2» — virtualbox-memory «2048» — virtualbox-disk-size «20000» swarm-node-2

docker-machine env swarm-node-2

eval $(docker-machine env swarm-node-2)

Запускаем третью ноду:

docker-machine create — driver virtualbox — virtualbox-cpu-count «2» — virtualbox-memory «2048» — virtualbox-disk-size «20000» swarm-node-3

eval $(docker-machine env swarm-node-3)

Подключимся к первой ноде инициализируем в ней распределённое хранилище и передаём ему адрес ноды менеджера (лидера):

docker-machine ssh swarm-node-1

docker swarm init — advertise-addr 192.168.99.100:2377

docker node ls // выведет текущий

/// docker swarm join-token worker

Если токены будут забыты, их можно получить, выполнив в ноде с распределённым хранилищем команды docker swarm join-token manager и docker swarm join-token worker.

Для создания кластера необходимо зарегистрировать (присоединить) все его будущие ноды командой docker swarm join — token… 192.168.99.100:2377, для аутентификации используется токен, для их обнаружения необходимо, чтобы они находились в одной подсети. Посмотреть все сервера можно командой docker node info

Команда docker swarm init создаст лидера кластера, пока одинокого, но в полученном ответе будет на неё будет придана команда, необходимая для подключение других нод к этому кластеру, важная информация в котором — токен, например docker swarm join — token… 192.168.99.100:2377. Подключимся к оставшимся нодам по ssh командой docker-machine ssh name_node и выполним её.

Для взаимодействия контейнеров используется сеть brige, которая является свитчем. Но для работы нескольких реплик нужна подсеть, так как все реплики будут с одинаковыми портами, а проксирование производится по ip с помощью распределённого хранилища, при этом не имеет значение физически они расположены на одном сервере или разных. Следует сразу заметить, что балансировка осуществляется по правилу roundrobin, то есть поочерёдно к каждой реплике. Важно создать сеть типа overlay для создания DNS по верх неё и возможности обращаться к репликам по им именам. Создадим подсеть:

docker network create — driver overlay — subnet 10.10.1.0/24 — opt encrypted services

Теперь нам нужно наполнить на кластер контейнерами. Для этого создаём не контейнер, а сервис, который является шаблоном для создания контейнеров на разных нодах. Количество создаваемых реплик указывается при создании в ключе — replicas, причём распределение случайное по нодам, но по возможности равномерное. Помимо реплик, сервис имеет балансировщик нагрузки, порты с которого на которые (входные порты для всех реплик) происводится проксирование указывается к ключе — p, а Servis Discovery (обнаружение работающих реплик, определение их ip-адресов, перезапуск) реплик балансировщик осуществляет самостоятельно.

docker service create — p 80:80 — name busybox — replicas 2 — network services busybox sleep 3000

Проверим состояние сервиса docker service ls, состояние и равномерность распределения реплик контейнеров docker service ps busybox и его работу wget — O — 10.10.1.2. Сервис — более высокоуровневая абстракция, которая включает в себя контейнер и организующее его обновление (далеко не только), то есть для обновления параметров контейнера не нужно его удалять и создавать, а просто обновить сервис, а уже сервис сперва создаст новый с обновлённой конфигурацией, а только после того как он запустится удалит старый.

Docker Swarm имеет свой балансировщик нагрузки ingress load balacing, который балансирует нагрузку между репликами на порту, объявленном при создании сервиса, в нашем случае это 80 порт. Входной точкой может быть любой сервер с этим портом, но ответ будет получен от сервера на который был перенаправлен запрос балансировщиком.

Мы также можем сохранять данные на хостовую машину, как и в обычном контейнере, для этого есть два варианта:

docker service create — mount type=bind, src=…, dst=…. name=…….. #

docker service create — mount type=volume, src=…, dst=…. name=…….. # на хост

Развёртывание приложения производится через docker-compose, запущенного на нодах (репликах). При обновлении конфигурации docker-compose нужно обновить docker stack, и кластер будет последовательно обновлён: одна реплика будет удалена и в место неё будет создана новая в соответствии с новым конфигом, далее следующая. Если произошла ошибка — буде произведён откат к предыдущей конфигурации. Что ж, приступим:

docker stack deploy — c docker-compose.yml test_stack

docker service update — label-add foo=bar Nginx docker service update — label-rm foo Nginx docker service update — publish-rm 80 Nginx docker node update — availability=drain swarm-node-3 swarm-node-3

Docker Swarm

$ sudo docker pull swarm

$ sudo docker run — rm swarm create

docker secrete create test_secret docker service create — secret test_secret cat /run/secrets/test_secret проверка работоспособности: hello-check-cobbalt пример pipeline: trevisCI — > Jenkins — > config — > https://www.youtube.com/watch?v=UgUuF_qZmWc https://www.youtube.com/watch?v=6uVgR9WPjYM

Docker в масштабах компании

Давайте посмотрим в масштабах компании: у нас есть контейнера и есть сервера. Не важно, это две виртуалки и несколько контейнеров или это сотни серверов и тысячи контейнеров, проблема в том, чтобы распределить контейнера на серверах нужен системный администратор и время, если мало времени и много контейнеров, нужно много системных администраторов, иначе они будут неоптимальное распределены, то есть сервер (виртуальная машина) работает, но не в полную силу и ресурсы продают. В этой ситуации для оптимизации распределения и экономии человеческих ресурсов предназначены системы оркестрации контейнеров.

Рассмотрим эволюцию:

* Разработчик создаёт необходимые контейнера руками.

* Разработчик создаёт необходимые контейнера используя для этого заранее подготовленные скрипты.

* Системный администратор, с помощью какой-либо системы управления конфигурации и развёртывания, таких как Chef,

Pupel, Ansible, Salt, задаёт топологию системы. В топологии указывается какой контейнер в на каком месте

располагается.

* Оркестрация (планировщики) — полуавтоматическое распределение, поддержание состояния и реакция на изменение

системы. Например: Google Kubernetes, Apache Mesos, Hashicorp Nomad, Docker Swarm mode и YARN, который мы

рассмотрим. Также появляются новые: Flocker (https://github.com/ClusterHQ/Flocker/),

Helios (https://github.com/spotify/helios/)

Существует нативное решение docker-swarm. Из взрослых систем наибольшую популярность показали Kubernetes (Kubernetes) и Mesos, при этом первый представляет из себя универсальную и полностью готовую к работе систему, а второй — комплекс разнообразных проектов, объединённых в единый пакет и позволяющие заменить или изменять свои компоненты. Cуществует, также, огромное количество менее популярных решений, не продвигаемы такими гигантами, как Google, Twitter и другими: Nomad, Scheduling, Scalling, Upgrades, Service Descovery, но мы их рассматривать не будем. Здесь мы будем рассматривать наиболее готовое решение — Kuberntes, которое завоевало большую популярность за низкий порог вхождения, поддержки и достаточную гибкость в большинстве случае, вытеснив Mesos в нишу кастомизуруемых решений, когда кастомизация и разработка экономически оправдана.

У Kubernetes есть несколько готовых конфигураций:

* MiniKube — кластер из одной локальной машины, предназначен для преодоления порога вхождения и экспериментов

* kubeadm

* kops

* kubernetes-ansible

* microKubernetes

Мониторинг — Heapster

Наименьшая структурная единица называется Pod, которая соответствует yml-файлу в docker-compose. Процесс создания Pod, как и других сущностей производится декларативно: через написание или изменение конфигурационного yml-файла и применение его к кластеру. И так, создадим Pod:

# test_pod.yml

# kybectl create — f test_pod.yaml

containers:

— name: test

image: debian

Для запуска нескольких реплик:

# test_replica_controller.yml

# kybectl create — f test_replica_controller.yml

apiVersion: v1

kind: ReplicationController

metadata:

name: Nginx

spec:

replicas: 3

selector:

app: Nginx // метка, по которой реплика определяет наличие запущенных контейнеров

template:

containers:

— name: test

image: debian

Для балансировки используется разновидность service (логическая сущность) — LoadBalancer, кроме которого существует ещё ClasterIP и Node Port:

appVersion: v1

kind: Service

metadata:

name: test_service

apec:

type: LoadBalanser

ports:

— port: 80

— targetPort: 80

— protocol: TCP

— name: http

selector:

app: Web

Плагины overlay сети (создаётся и настраивается автоматически): Contiv, Flannel, GCE networking, Linux bridging, Callico, Kube-DNS, SkyDNS. #configmap apiVersion: v1 kind: ConfigMap metadata: name: config_name data:

Аналогично секретам в docker-swarm существует секрет и для Kubernetes, примером которых могут быть настройки Nginx:

#secrets

apiVersion: v1

kind: Secrets

metadata: name: test_secret

data:

password:….

А для добавления секрета в под, нужно его указать в конфиге пода:

….

valumes:

secret:

secretName: test_secret

…

У Kubernetes больше разновидностей Valumes:

* emptyDir

* hostPatch

* gcePersistentDisc — диск на Google Cloud

* awsElasticBlockStore — диск на Amazon AWS

volumeMounts:

— name: app

nountPath:""

volumes:

— name: app

hostPatch:

….

Особенностью буде UI: Dashbord UI

Дополнительно имеется:

* Main metrics — сбор метрик

* Logs collect — сбор логов

* Scheduled jobs

* Autentification

* Federation — распределение по дата-центрам

* Helm — пакетный менеджер, аналог Docker Hub

https://www.youtube.com/watch?v=FvlwBWvI-Zg

Альтернативы Docker

* Rocket или rkt — контейнеры для операционной среды CoreOS от RedHut, специально созданной на использование

контейнеров.

* Hyper-V — среда для запуска Docker в операционной системе Windows, представляющая из себя обертку (легковесную

виртуальную машину) контейнера.

От Docker ответвились его базовые компоненты, которые используются им как примитивы, ставшие стандартными компонентами для реализации контейнеров, таких как RKT, объединенных в проект containerd:

* CRI-O — OpanSource проект, с самого начала нацеленный на полную поддержку стандартов CRI (Container Runtime

Interface), github.com/opencontainers/runtime-spec/">Runtime Specification и github.com/opencontainers/image-spec">Image Specification как общего интерфейса

взаимодействия системы оркестровки с контейнерами. Наряду c Docker, добавлена поддержка CRI-O 1.0 в Kubernetes

(речь пойдёт дальше) с версии 1.7 в 2007, а также в MiniKube и Kubic. Имеет реализацию CLI (Common Line

Interface) в проекте Pandom, практически полностью повторяющий команды Docker, но без оркестровки (Docker

Swarm), который по умолчанию является инструментом в Linux Fedora.

* CRI (kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/">Container

Runtime Interface) — среда для запуска контейнеров, универсально предоставляющие примитивы (Executor,

Supervisor, Metadata, Content, Snapshot, Events и Metrics) для работы с Linux контейнерами (пространствами

процессов, групп и т. д.).

* CNI (Container Networking Interface) — работа с сетью

Portainer

Простейшим вариантом мониторинга будет Portainer:

essh@kubernetes-master:~/microKubernetes$ cat << EOF > docker-compose.monitoring.yml

version: 2

>

services:

portainer:

image: portainer/portainer

command: — H unix:///var/run/docker.sock

restart: always

ports:

— 9000:9000

volumes:

— /var/run/docker.sock:/var/run/docker.sock

–./portainer_data:/data

>

EOF

essh@kubernetes-master:~/microKubernetes$ docker-compose — f docker-compose.monitoring.yml up — d

Облачные системы, как источник непрерывного масштабирования: Google Cloud и Amason AWS

Кроме хостинга и аренды сервера, в частности виртуального VPS, можно воспользоваться облачными решениями (SAS, Service As Software) решениями, то есть осуществлять работу нашего Web приложения (ий) только через панель управления используя готовую инфраструктуру. Этот подход имеет как плюсы, так и минусы, которые зависит от бизнеса заказчика. Если с технической стороны сам сервер удалён, но мы можем к нему подключиться, и как бонус получаем панель администрирования, то для разработчика различия более существенны. Разделим проекты на три группы по месту развёртывания: на хостинге, в своём дата центре или использующие VPS и в облаке. Компании использующие хостинг в силу существенных ограничений налагаемых на разработку — невозможность установить своё программное обеспечение и нестабильность и размер предоставляемой мощности — в основном специализируются на заказной (потоковой) разработке сайтов и магазинов, которая в силу малых требований к квалификации разработчиков и нетребовательности к знаниям инфраструктуры рынок готов оплачивать их труд по минимум. Ко второй группе относятся компании реализующие состоявшиеся проекты, но разработчики отстранены от работы с инфраструктурой наличием системных администраторов, build инженеров, DevOps и других специалистов по инфраструктуре. Компании, выбирающие облачные решения, в основном оправдывают переплату за готовую инфраструктуру и мощности их расширяемостью (актуально для стартапов, когда рост нагрузки не предсказуем). Для реализации подобных проектов в основном берут высококвалифицированных специалистов широкого круга для реализации нестандартных решений, где инфраструктура уже является просто инструментом, а специалисты по ней просто отсутствуют. На разработчиков возлагаются функции по проектированию проекта в целом, как единого целого, а не программы в отрыве от инфраструктуры. В основном это зарубежные компании, готовые хорошо оплачивать труд ценных сотрудников.

Для развёртывания будем использовать Kubernetes для противодействия vender lock, когда инфраструктура проекта завязана на api конкретного облачного провайдера и не позволят перейти на другие или собственные облака без существенных изменений в самом приложении. Kubernetes поддерживается Amazon AWS, Google Cloud, Microsorft Azure, локальной установкой одного иснтанца с помощью MiniKube.

Воспользуемся Google Cloud, на текущий 2018 год он предоставляет бесплатное использование на один год ограниченных ресурсов (300 долларов США), при этом существуют лимиты, которые можно посмотреть в меню IAM и администрирование — > Квоты. Важно заметить, облачные провайдеры не предоставляют тарифов в современном диапазоне, а предоставляют тарифы на использовании определённых мощностей, то есть сайт мало посещаем — платим мало, сложно обрабатываем много данных — платим много. По этой причине, когда потребности в вычислительных мощностях у компании предсказуемы (не стартап) может быть целесообразно использовать собственные возможности для постоянной нагрузки, что может быть экономически целесообразно, не рискую ограниченностью вычислительными мощностями.

И так заходим на cloud.google.com регистрируется, привязываем дебетовую карту с минимальным балансом и переходим в консоль console.cloud.google.com, в котором можно пройти обучение по интерфейсу для общего ознакомления. В меню нажимаем пункт Оплата: у меня нетронутые демо-деньги 300 долларов США и осталось 356 дней (средства списываются не в режиме реального времени).

Если смотреть на как основу для Back-End для мобильной разработки (MBasS, Mobile backend as a service), то его предоставляют разные провайдеры: Google Firebase, AWS Mobile, Azure Mobile

Google App Engine

Создание кластера через Web-интерфейс

Предварительно проверим ограничения (квоты) Меню — > Продукты — > IAM и администрирование — > Квоты, а если вы находитесь на тестовом аккаунте, то Static IP addresses будет равен 1, то не сможет создаться балансировщик и придётся удалять кластер. Создадим кластер в Меню — Ресурсы — Kubernetes Engine в тремя репликами микромашины и последней версией Kubernetes. В левом нижнем углу в пункте Marketplace создадим 2 инстанса Nginx. После создания кластера кликнем по вкладке Сервисы и перейдём по IP-адресу.

MarketPlace: Сеть, Бесплатные, Приложения Kubernetes: Nginx Создадим кастомный кластер standard-cluster-Nginx, выбрав минимум CPU и RAM, 2 ноды вместо 3 и последнюю вер сию Kubernetes (я выбрал 1.11.3, а мой код будет совместим с — не ниже 1.10). В Меню — Ресурсы — Kubernetes Engine во кладке Кластера нажмём кнопку Подключиться. Управлением кластером в командной строке осуществляется с помощью команды cubectl, о ней можно почитать в документации https://kubernetes.io/docs/reference/kubectl/overview/ и список по https://gist.github.com/ipedrazas/95391ffd88190bea94ca188d3d2c1cbe.

Создание виртуальной машины:

Можно создать программный проект, но пользоваться им можно будет только на платном аккаунте:

NAME_PROJECT=bitrix_12345;

NAME_CLUSTER=bitrix;

gcloud projects create $NAME_CLUSTER — name $NAME_CLUSTER;

gcloud config set project $NAME_CLUSTER;

gcloud projects list;

Несколько тонкостей: ключ — zone обязателен и ставится в конце, диска не должен быть меньше 10Gb, а тип машин можно взять из https://cloud.google.com/compute/docs/machine-types. Если реплика у нас одна, то по умолчанию создаётся минимальная конфигурация для тестирования:

gcloud container clusters create $NAME_CLUSTER — zone europe-north1-a

Вы можете увидеть в админке, развернув выпадающий список в шапке, и открыв вкладку Все проекты.

gcloud projects delete NAME_PROJECT;

, если больше — стандартная, параметры которой мы подредактируем:

$ gcloud container clusters create mycluster \

— machine-type=n1-standard-1 — disk-size=10GB — image-type ubuntu \

— scopes compute-rw,gke-default \

— machine-type=custom-1-1024 \

— cluster-version=1.11 — enable-autoupgrade \

— num-nodes=1 — enable-autoscaling — min-nodes=1 — max-nodes=2 \

— zone europe-north1-a

Ключ — enable-autorepair запускаем работу мониторинга доступности ноды и в случае её падения — она будет пересоздана. Ключ требует версию Kubernetes не менее 1.11, а на момент написания книги версия по умолчанию 1.10 и по этому нужно её задать ключом, например, — cluster-version=1.11.4-gke.12. Но можно зафиксировать только мажорную версия — cluster-version=1.11 и установить автообновление версии — enable-autoupgrade. Также зададим авто уверение количества нод, если ресурсов не хватает: — num-nodes=1 — min-nodes=1 — max-nodes=2 — enable-autoscaling.

Теперь поговорим об виртуальный ядрах и оперативной памяти. По умолчанию поднимается машина n1-standart-1, имеющая одно виртуальное ядро и 3.5Gb оперативной памяти, в трёх экземплярах, что совокупно даёт три виртуальных ядра и 10.5Gb оперативной памяти. Важно, чтобы в кластере было всего не менее двух виртуальных ядер процессора, иначе их, формально по лимитам на системные контейнера Kubernetes, не хватит для полноценной работы (могут не подняться контейнера, например, системные). Я возьму две ноды по одному ядру и общее количество ядер будет два. Такая же ситуация и с оперативной памятью, для поднятия контейнера с Nginx мне вполне хватало 1Gb (1024Mb) оперативной памяти, а вот для поднятия контейнера с LAMP (Apache MySQL PHP) уже нет, у меня не поднялся системный сервис kube-dns-548976df6c-mlljx, который отвечает за DNS в поде. Не смотря не то, что он не является жизненно важным и нам не пригодится, в следующий раз может не подняться уж более важный вместо него. При этом важно заметить, что у меня нормально поднимался кластер с 1Gb и было всё нормально, я общий объём в 2Gb оказался пограничным значением. Я задал 1080Mb (1.25Gb), учтя, что минимальная планка оперативной памяти составляет 256Mb (0.25Gb) и мой объём должен быть кратен ей и быть не меньше, для одно ядра, 1Gb. В результате в кластера 2 ядра и 2.5Gb вместо 3 ядре и 10.5Gb, что является существенной оптимизацией ресурсов и цены на платном аккаунте.

Теперь нам нужно подключиться к серверу. Ключ у нас уже есть на сервере ${HOME}/.kube/config и теперь нам нужно просто авторизоваться:

$ gcloud container clusters get-credentials b — zone europe-north1-a — project essch

$ kubectl port-forward Nginxlamp-74c8b5b7f-d2rsg 8080:8080

Forwarding from 127.0.0.1:8080 — > 8080

Forwarding from [::1]:8080 — > 8080

$ google-chrome http://localhost:8080 # это не будет работать в Google Shell

$ kubectl expose Deployment Nginxlamp — type="LoadBalancer" — port=8080

Для локального использования kubectl Вам нужно установить gcloud и с помощью него установить kubectl используя команду gcloud components install kubectl, но пока не будем усложнять первые шаги.

В разделе Сервисы админки будет доступен под не только через сервис балансировщик frontend, но и через внутренний балансировщик Deployment. Хоть и после пересоздания и сохранится, но конфиг более поддерживаем и очевиден.

Также есть возможность дать возможность регулировать количество нод в автоматическом режиме в зависимости от нагрузки, например, количества контейнеров с установленными требованиями к ресурсам, с помощью ключей — enable-autoscaling — min-nodes=1 — max-nodes=2.

Простой кластер в GCP

Для создания кластера можно пойти двумя путями: через графический интрефейс Google Cloud Platform или через его API командой gcloud. Посмотрим, как это можно сделать через UI. Рядом с меню кликнем на выпадающей список и создадим отдельный проект. В разделе Kuberntes Engine выбираем создать кластер. Дадим название, 2CPU, зону europe-north-1 (дата-центр в Финляндии ближе всего к СПб) и последнюю версию Kubernetes. После создания кластера кликаем на подключиться и выбираем Cloud Shell. Для создания через api по кнопке в правом верхнем углу выведем консольную панель и введём в ней:

gcloud container clusters create mycluster — zone europe-north1-a

Через некоторое время, у меня это заняло две с половиной минуты, будут подняты 3 виртуальные машины, на них установлена операционная система и примонтирован диск. Проверим:

esschtolts@cloudshell:~ (essch)$ gcloud container clusters list — filter=name=mycluster

NAME LOCATION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS

mycluster europe-north1-a 35.228.37.100 n1-standard-1 1.10.9-gke.5 3 RUNNING

esschtolts@cloudshell:~ (essch)$ gcloud compute instances list

NAME MACHINE_TYPE EXTERNAL_IP STATUS

gke-mycluster-default-pool-43710ef9-0168 n1-standard-1 35.228.73.217 RUNNING

gke-mycluster-default-pool-43710ef9-39ck n1-standard-1 35.228.75.47 RUNNING

gke-mycluster-default-pool-43710ef9-g76k n1-standard-1 35.228.117.209 RUNNING

Подключимся к виртуальной машине:

esschtolts@cloudshell:~ (essch)$ gcloud projects list

PROJECT_ID NAME PROJECT_NUMBER

agile-aleph-203917 My First Project 546748042692

essch app 283762935665

esschtolts@cloudshell:~ (essch)$ gcloud container clusters get-credentials mycluster \

— zone europe-north1-a \

— project essch

Fetching cluster endpoint and auth data.

kubeconfig entry generated for mycluster.

У нас пока нет кластера:

esschtolts@cloudshell:~ (essch)$ kubectl get pods

No resources found.

Создадим кластер:

esschtolts@cloudshell:~ (essch)$ kubectl run Nginx — image=Nginx — replicas=3

deployment.apps «Nginx» created

Проверим его состав:

esschtolts@cloudshell:~ (essch)$ kubectl get deployments — selector=run=Nginx

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE

Nginx 3 3 3 3 14s

esschtolts@cloudshell:~ (essch)$ kubectl get pods — selector=run=Nginx

NAME READY STATUS RESTARTS AGE

Nginx-65899c769f-9whdx 1/1 Running 0 43s

Nginx-65899c769f-szwtd 1/1 Running 0 43s

Nginx-65899c769f-zs6g5 1/1 Running 0 43s

Удостоверимся, что все три реплики кластера распределились равномерно на все три ноды:

esschtolts@cloudshell:~ (essch)$ kubectl describe pod Nginx-65899c769f-9whdx grep Node:

Node: gke-mycluster-default-pool-43710ef9-g76k/10.166.0.5

esschtolts@cloudshell:~ (essch)$ kubectl describe pod Nginx-65899c769f-szwtd grep Node:

Node: gke-mycluster-default-pool-43710ef9-39ck/10.166.0.4

esschtolts@cloudshell:~ (essch)$ kubectl describe pod Nginx-65899c769f-zs6g5 grep Node:

Node: gke-mycluster-default-pool-43710ef9-g76k/10.166.0.5

Теперь поставим балансировщик нагрузки:

esschtolts@cloudshell:~ (essch)$ kubectl expose Deployment Nginx — type="LoadBalancer" — port=80

service «Nginx» exposed

Проверим, что он создался:

esschtolts@cloudshell:~ (essch)$ kubectl expose Deployment Nginx — type="LoadBalancer" — port=80

Конец ознакомительного фрагмента.