[ English | Deutsch | русский | English (United Kingdom) ]
Манифест OpenStack-Ansible¶
Этот проект будет проектом Battery included. Это означает, что оператор может ожидать, что развертывание из любой из названных функциональных ветвей или меток должно предоставить облако OpenStack, созданное для рабочего окружения, которое будет доступно после успешного завершения развертывания.
Рамки проекта¶
Этот проект будет проектом Battery included. Это означает, что оператор может ожидать, что развертывание из любой из названных функциональных ветвей или меток должно предоставить облако OpenStack, созданное для рабочего окружения, которое будет доступно после успешного завершения развертывания.
Не смотря на это, проект исключительно фокусируется на развертывании OpenStack и его требованиях.
Этот проект не загружает хосты по PXE. Установка и жизненный цикл хостов оставляются на усмотрение оператора. Данный проект также требует, чтобы сетевые мосты были настроены на хостах, чтобы позволить контейнерам подключиться к локальным мостам для сетевого доступа. См. также Сеть контейнеров.
Использование Ansible¶
Ansible предоставляет платформу автоматизации для упрощения развертывания систем и приложений. Ansible управляет системами, используя secure shell (SSH) вместо уникальных протоколов, требующих удаленных демонов или агентов.
Ansible использует плейбуки, написанные на языке YAML, для оркестровки. Для получения дополнительной информации см. Ansible - Intro to Playbooks.
Ansible — это простой, но мощный инструмент оркестровки, который идеально подходит для развертывания облаков на базе OpenStack. Декларативная природа Ansible позволяет оператору превратить все развертывание в довольно простой набор инструкций.
Роли в рамках OpenStack-Ansible построены с использованием лучших практик Ansible и содержат переменные пространства имен, которые понятны человеку. Все роли независимы друг от друга и могут быть протестированы отдельно.
Все роли построены как совместимые роли с Galaxy, даже если их отдельное использование не предусмотрено. В то время как проект предлагает множество встроенных ролей, оператор может добавить или переопределить роли внешними при помощи встроенных в Ansible возможностей. Это дает дополнительную гибкость для операторов.
Развертывания на основе исходного кода¶
Когда проект OpenStack-Ansible создавался, было необходимо дать возможность переопределить любой источник исходных кодов OpenStack.
Это означает, что сервисы OpenStack и их python зависимости построены и установлены из исходных кодов, которые найдены в Git репозиториях OpenStack по умолчанию, но операторы также могут указать и собственные репозитории.
Это также позволяет операторам указать на их собственный код для своей работы.
Установка из исходных кодов для Python частей OpenStack имеет смысл при определенных масштабах, когда необходима согласованность на протяжении долгого времени. Оператор должен иметь возможность развернуть одну и ту же версию OpenStack на каждую ноду на протяжении всего жизненного цикла облака, даже когда некоторые компоненты достигли конца жизненного цикла. При помощи репозитория с исходным кодом, развертывание может быть воспроизведено даже спустя годы с момента начального развертывания, предполагая что операционные системы и пакеты останутся теми же.
Это означает, что специфичные пакеты OpenStack, предоставляемые дистрибутивами, никогда не будут использоваться для сервисов OpenStack. Сторонние репозитории, такие как CloudArchive или RDO могут по прежнему быть необходимы для развертывания, но только для удовлетворения зависимостей приложений.
Развертывания с контейнеризацией¶
Этот проект представляет контейнеры как средство абстракции сервисов друг от друга.
Использование контейнеров позволяет, благодаря дополнительной абстракции, использование целых стеков приложений на одном физическом хосте.
«Контейнеризованные» приложения иногда группируются на одном контейнере, когда это имеет смысл, либо же разносятся в несколько контейнеров в зависимости от приложения и архитектурных нужд.
По умолчанию архитектура контейнеров была построена таким образом, что бы была возможность масштабируемости и высокодоступных развертываний.
Простая природа контейнеров позволяет оператору расценивать контейнеры как виртуальные машины. Тот же концепт применим и к контейнерам и к виртуальным машинам: использование операторами существующего набора утилит для исследования проблем с развертыванием и возможность откатить приложение или сервис, находящийся в inventory, в рабочее состояние без необходимости переустановки физического хоста.
Не все сервисы контейнеризованы: запуск некоторых в контейнере не целесообразен. Логика должна быть применена в зависимости от того как сервисы контейнеризуются. Если их требования не могут быть удовлетворены из-за системных ограничений (ядро, основательность приложения и тд), тогда сервис не запускается в контейнере.
Пример неконтейнеризованных служб:
Вычислительная служба nova (для доступа к устройствам виртуализации)
Swift хранилище (для прямого доступа к диску)
Цель контейнеров не в обеспечении дополнительной безопасности системы. Контейнеры были выбраны не для какой-то очевидной защиты. Контейнеры были выбраны из-за своей практичности с целью предоставления более универсальных развертываний OpenStack. Даже если абстракции, которые предоставляют контейнеры, улучшают общую безопасность развертывания, это потенциальные преимущества не были изначальной целью контейнеризации сервисов.
