Файл: Облачные сервисы (Облачные услуги).pdf

NoOps (акроним от англ. no и operations) – набор практик, призванный к тому, чтобы в компании совсем избавиться от специалистов сопровождения за счёт использования PaaS или полной автоматизации внутренних процессов в инфраструктуре организации. Платформа как сервис подразумевает скрытие внутренних процессов в инфраструктуре от глаз разработчиков и бизнеса.

2.6 BizOps

BizOps (акроним от англ. buziness и operations) – набор практик, которые позволяют представителям бизнеса напрямую обращаться с облачными технологиями и прибегать к их услугам. В большинстве случаев под этим понимается программное обеспечение как услуга. Бизнесу необходимы CRM системы, системы документооборота, различные коммерческие порталы и взаимодействие различных структур облачных технологий.

2.7. LXC

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

2.8. Docker

На смену LXC пришёл Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы. Изначально использовал возможности LXC, но с 2015 года разработал собственную библиотеку, абстрагирующую виртуализационные возможности ядра Linux — libcontainer. С появлением Open Container Initiative начался переход от монолитной к модульной архитектуре, - это открыло новую облачную эру микросервисов. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами..

Разрабатывается и поддерживается одноимённой компанией-стартапом, распространяется в двух редакциях — общественной (Community Edition) по лицензии Apache 2.0 и для организаций (Enterprise Edition по проприетарной лицензии. Написан на языке Go. [4]

2.9. Подходы к разработке программного обеспечения для облачных ресурсов

Сервис-ориентированная архитектура (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.

Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini, CORBA, на основе REST).

Интерфейсы компонентов в сервис-ориентированной архитектуре инкапсулируют детали реализации (операционную систему, платформу, язык программирования) от остальных компонентов, таким образом обеспечивая комбинирование и многократное использование компонентов для построения сложных распределённых программных комплексов, обеспечивая независимость от используемых платформ и инструментов разработки, способствуя масштабируемости и управляемости создаваемых систем.

Такая архитектура позволяет поддерживать DevOps, BizOps и NoOps подходы.

Главное, что отличает SOA — это использование независимых сервисов с чётко определёнными интерфейсами, которые для выполнения своих задач могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу.

SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабосвязанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определённого платформенно-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса.

Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java, работающие на платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.

SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий или фреймворков для документирования сервисов.

Микросервисы — современное представление сервис-ориентированной архитектуры (SOA), используемое для создания распределенных программных систем. Как и в SOA, модули в архитектуре микросервисов взаимодействуют по сети друг с другом для выполнения цели. Ещё одно сходство в том, что микросервисы используют протоколо-независимую технологию. Данная архитектура является первой реализацией SOA, появившейся после внедрения DevOps, и она постепенно становится стандартом для непрерывно развивающихся систем.

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

Иными словами, инкапсулируются определённые контексты приложения в микросервисы, по одному на каждый, а сами микросервисы располагаются на разных серверах, - по большей части под управлением Docker.

Свойства, характерные для архитектуры микросервисов:

Модули можно легко заменить в любое время.
Модули организованы вокруг функций, например, пользовательский интерфейс, логистика, выставление счета и т. д.
Модули могут быть реализованы с использованием различных языков программирования, баз данных, аппаратных средств и программного обеспечения, в зависимости от того, что подходит лучше всего.
Архитектура симметричная, а не иерархическая (производитель — потребитель). [5]

2.10. Системы управления конфигурациями

Chef — система управления конфигурациями, написанная на Ruby (клиентская часть) и Erlang (серверная часть), с использованием предметно-ориентированного языка для описания конфигураций. Используется для упрощения задач настройки и поддержки множества серверов и может интегрироваться в облачные платформы, такие как Rackspace и Amazon EC2, для автоматизации управления текущими и автоматизации процесса настройки новых серверов.

Пользователь Chef создаёт определенные «рецепты» с описанием того, как управлять серверными приложениями (например, Apache, MySQL или Hadoop) и их настроек.

«Рецепт» — это описание состояния ресурсов системы, в котором она должна находиться в конкретный момент времени, включая установленные пакеты, запущенные службы, созданные файлы. Chef проверяет, что каждый из ресурсов системы настроен правильно и пытается исправить состояние ресурса, если оно не соответствует ожидаемому.

Chef может работать как в режиме клиент-сервер, так и в режиме автономной конфигурации, называемом «chef-solo». В режиме клиент-сервер клиент посылает на сервер различные свойства хоста, на котором он расположен. На стороне сервера используется Solr для индексирования свойств и предоставления API для запроса информации клиентом. «Рецепты» могут запрашивать эти свойства и использовать полученные данные для настройки хоста.

Обычно используется для управления Linux-узлами, но последние версии поддерживают Windows. [6]

Ansible - это очень гибкий и легкий инструмент для написания сценариев автоматизации любой сложности. Можно описать в нем как простое окружение разработчика так сложную структуру крупного проекта с несколькими окружениями. Он работает со встроенными в bash командами. Позволяет решать следующие задачи:

Установка/удаление ПО;
Конфигурирование ПО;
Создание/удаление пользователей;
Контроль пользовательских паролей/ключей;
Создание/удаление контейнеров/виртуальных машин;
Деплой кода вашего ПО;
Запуск различных скриптов/тестов. [7]

Puppet — кроссплатформенное клиент-серверное приложение, которое позволяет централизованно управлять конфигурацией операционных систем и программ, установленных на нескольких компьютерах. Написано на языке программирования Ruby. Наряду с Chef отмечается как одно из самых актуальных средств конфигурационного управления по состоянию на 2013 год.

Puppet позволяет просто настроить и впоследствии быстро управлять практически любой сетью на базе любой операционной системы Red Hat Enterprise Linux, CentOS, Fedora, Debian, Ubuntu, OpenSUSE, Solaris, BSD, Mac OS X и Microsoft Windows (через cygwin).

Система Puppet достаточно популярна в среде IT-компаний, в частности, её используют Google, Яндекс, Fedora Project, Стэнфордский университет, Red Hat, Siemens IT Solution, SugarCRM, Mail.Ru.

Узлы сети, управляемые с помощью Puppet, периодически опрашивают сервер, получают и применяют внесённые администратором изменения в конфигурацию. Конфигурация описывается на специальном декларативном предметно-ориентированном языке.

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

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

Оркестровка описывает то, как сервисы должны взаимодействовать между собой, используя для этого обмен сообщениями, включая бизнес-логику и последовательность действий. Оркестровка подчинена какому-то одному из участников бизнес-процесса. В сервис-ориентированной архитектуре оркестровка сервисов реализуется согласно стандарту Business Process Execution Language. Познакомимся с основными инструментами для инженеров DevOps – оркестраторами, которые позволяют автоматизировать процесс деплоя на распределённые системы.

К примеру оркестраторов относятся такие программы, как Docker Swarm, Apache Mesos, Nomad, Kubrenetes. Рассмотрим функционал оркестратора на примере последнего.

Kubernetes предназначен для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а также обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google и теперь поддерживается многими компаниями, среди которых Microsoft, RedHat, IBM и Docker.

Компания Google пользуется контейнерной технологией уже более десяти лет. Она начинала с запуска более 2 млрд контейнеров в течение одной недели. С помощью проекта Kubernetes компания делится своим опытом создания открытой платформы, предназначенной для масштабируемого запуска контейнеров.

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

Работающий кластер Kubernetes включает в себя агента, запущенного на нодах (kubelet) и компоненты мастера (APIs, scheduler, etc), поверх решения с распределённым хранилищем. Приведённая схема показывает желаемое, в конечном итоге, состояние, хотя все ещё ведётся работа над некоторыми вещами, например: как сделать так, чтобы kubelet (все компоненты, на самом деле) самостоятельно запускался в контейнере, что сделает планировщик на 100% подключаемым.