OpenShift — Обзор

OpenShift — это Платформа облачной разработки как услуга (PaaS), размещенная в Red Hat. Это удобная облачная платформа с открытым исходным кодом, используемая для создания, тестирования и запуска приложений и, наконец, их развертывания в облаке.

OpenShift способен управлять приложениями, написанными на разных языках, таких как Node.js, Ruby, Python, Perl и Java. Одной из ключевых особенностей OpenShift является его расширяемость, которая помогает пользователям поддерживать приложение, написанное на других языках.

OpenShift поставляется с различными концепциями виртуализации в качестве уровня абстракции. Основная концепция OpenShift основана на виртуализации.

Виртуализация

В общем, виртуализация может быть определена как создание виртуальной системы, а не физической или фактической версии чего-либо, начиная с системы, хранилища или операционной системы. Основная цель виртуализации — сделать ИТ-инфраструктуру более масштабируемой и надежной. Концепция виртуализации существует уже несколько десятилетий, и с развитием ИТ-индустрии сегодня она может быть применена к широкому кругу уровней, начиная с системного уровня, аппаратного уровня и заканчивая виртуализацией на уровне сервера.

Как это устроено

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

Физическая и виртуальная архитектура

Типы виртуализации

Виртуализация приложений — в этом методе приложение абстрагируется от базовой операционной системы. Этот метод очень полезен, в котором приложение может быть запущено изолированно, без зависимости от операционной системы.
Виртуализация рабочего стола. Этот метод используется для уменьшения нагрузки на рабочую станцию, на которой можно получить удаленный доступ к рабочему столу с помощью тонкого клиента на рабочем столе. В этом методе рабочие столы в основном работают в центре обработки данных. Классическим примером может служить образ виртуального рабочего стола (VDI), который используется в большинстве организаций.
Виртуализация данных — это метод абстрагирования и отход от традиционного метода управления данными и данными.
Виртуализация сервера. В этом методе виртуализируются ресурсы, относящиеся к серверу, которые включают физический сервер, процесс и операционную систему. Программное обеспечение, обеспечивающее эту абстракцию, часто называют гипервизором.
Виртуализация хранилища — это процесс объединения нескольких устройств хранения в одно устройство хранения, управляемое из единой центральной консоли.
Виртуализация сети — это метод, при котором все доступные сетевые ресурсы объединяются путем разделения доступной полосы пропускания и каналов, каждый из которых не зависит друг от друга.

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

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

Виртуализация данных — это метод абстрагирования и отход от традиционного метода управления данными и данными.

Виртуализация сервера. В этом методе виртуализируются ресурсы, относящиеся к серверу, которые включают физический сервер, процесс и операционную систему. Программное обеспечение, обеспечивающее эту абстракцию, часто называют гипервизором.

Виртуализация хранилища — это процесс объединения нескольких устройств хранения в одно устройство хранения, управляемое из единой центральной консоли.

Виртуализация сети — это метод, при котором все доступные сетевые ресурсы объединяются путем разделения доступной полосы пропускания и каналов, каждый из которых не зависит друг от друга.

OpenShift

OpenShift — это облачная платформа приложений как услуга (PaaS). Это технология с открытым исходным кодом, которая помогает организациям перевести свою традиционную инфраструктуру приложений и платформу из физических, виртуальных сред в облако.

OpenShift поддерживает очень широкий спектр приложений, которые могут быть легко разработаны и развернуты на облачной платформе OpenShift. OpenShift в основном поддерживает три вида платформ для разработчиков и пользователей.

Инфраструктура как услуга (IaaS)

В этом формате поставщик услуг предоставляет виртуальным машинам аппаратного уровня некоторую предопределенную конфигурацию виртуального оборудования. В этом пространстве есть несколько конкурентов, начиная с облачного сервиса AWS Google, Rackspace и многих других.

Основной недостаток IaaS после длительной процедуры настройки и инвестиций заключается в том, что каждый по-прежнему отвечает за установку и обслуживание операционной системы и пакетов серверов, управление сетью инфраструктуры и заботу о базовом системном администрировании.

Программное обеспечение как услуга (SaaS)

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

Платформа как услуга (PaaS)

Это можно рассматривать как промежуточный слой между SaaS и IaaS. Основная цель оценки PaaS — для разработчиков, в которых среду разработки можно раскрутить с помощью нескольких команд. Эти среды спроектированы таким образом, чтобы они могли удовлетворить все потребности разработки, прямо от наличия сервера веб-приложений с базой данных. Для этого вам просто требуется одна команда, и поставщик услуг сделает все за вас.

Зачем использовать OpenShift?

OpenShift предоставляет корпоративным подразделениям общую платформу для размещения своих приложений в облаке, не беспокоясь о базовой операционной системе. Это упрощает использование, разработку и развертывание приложений в облаке. Одной из ключевых особенностей является то, что он предоставляет управляемое оборудование и сетевые ресурсы для всех видов разработки и тестирования. С помощью OpenShift разработчик PaaS может свободно разрабатывать необходимую среду со спецификациями.

OpenShift предоставляет различные виды соглашений об уровне обслуживания, когда речь идет о планах обслуживания.

Бесплатно — этот план ограничен тремя передачами с 1 ГБ места для каждого.

Бронза — этот план включает в себя 3 передачи и расширяется до 16 передач с 1 ГБ пространства на передачу.

Щепка — это бронзовый 16-ступенчатый план, однако он имеет емкость 6 ГБ без дополнительных затрат.

Помимо вышеупомянутых функций, OpenShift также предлагает локальную версию, известную как OpenShift Enterprise. В OpenShift разработчики имеют возможность разрабатывать масштабируемые и немасштабируемые приложения, и эти проекты реализуются с использованием серверов HAproxy.

Характеристики

OpenShift поддерживает несколько функций. Немногие из них —

Поддержка нескольких языков
Поддержка нескольких баз данных
Система расширяемых картриджей
Управление версиями исходного кода
Развертывание в один клик
Поддержка нескольких сред
Стандартизированный рабочий процесс разработчиков
Зависимость и управление сборкой
Автоматическое масштабирование приложения
Отзывчивая веб-консоль
Богатый набор инструментов для командной строки
Удаленный SSH вход в приложения
Поддержка Rest API
Стек приложений самообслуживания по требованию
Встроенные службы баз данных
Непрерывная интеграция и управление релизами
Интеграция с IDE
Удаленная отладка приложений

OpenShift — Типы

OpenShift возникла из его базы под названием OpenShift V2, которая в основном основывалась на концепции шестерен и картриджей, где каждый компонент имеет свои спецификации, начиная от создания машины до развертывания приложения, от сборки до развертывания приложения.

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

Шестерня — Его можно определить как медвежий металл или сервер с определенными характеристиками, касающимися ресурсов, памяти и процессора. Они считались фундаментальной единицей для запуска приложения.

Приложение. Это просто относится к приложению или любому приложению интеграции, которое будет развернуто и запущено в среде OpenShift.

По мере того как мы углубимся в этот раздел, мы обсудим различные форматы и предложения OpenShift. В прежние времена у OpenShift было три основных версии.

OpenShift Origin — это было дополнение сообщества или версия OpenShift с открытым исходным кодом. Он также был известен как основной проект для двух других версий.

OpenShift Online — это публичный PaaS как сервис, размещенный на AWS.

OpenShift Enterprise — это усиленная версия OpenShift с лицензиями независимых поставщиков и поставщиков.

OpenShift Online

OpenShift online — это предложение сообщества OpenShift, с помощью которого можно быстро создавать, развертывать и масштабировать контейнерные приложения в общедоступном облаке. Это платформа для разработки и хостинга приложений в общедоступном облаке Red Hat, которая позволяет автоматизировать предоставление, управление и масштабирование приложений, что помогает разработчику сосредоточиться на написании логики приложения.

Настройка учетной записи в Red Hat OpenShift Online

Шаг 1 — зайдите в браузер и посетите сайт https://manage.openshift.com/

Шаг 2 — Если у вас есть учетная запись Red Hat, войдите в учетную запись OpenShift, используя идентификатор входа и пароль Red Hat, используя следующий URL-адрес. https://developers.redhat.com/auth/realms/rhd/protocol/openid-connect/auth?client_id=oso&redirect_uri=https%3A%2F%2Fmanage.openshift.com%2Faccounts%2Fauth%2Fkeycloak%2Fcallback&response_type=code&scope= + профиль Вконтакте + электронная почта и состояние = b73466d00a5b3b4028ca95eac867e2dd

Шаг 3 — Если у вас нет учетной записи Red Hat, зарегистрируйтесь в онлайн-сервисе OpenShift, используя следующую ссылку.

https://developers.redhat.com/auth/realms/rhd/login-actions/registration?code=G4w-myLd3GCH_QZCqMUmIOQlU7DIf_gfIvGu38nnzZQ.cb229a9d-3cff-4c58-b7f6-7b2c9eb17926

После входа вы увидите следующую страницу.

После того, как у вас все будет на месте, Red Hat покажет некоторые базовые данные учетной записи, как показано на следующем снимке экрана.

Наконец, когда вы вошли в систему, вы увидите следующую страницу.

Контейнерная платформа OpenShift

Контейнерная платформа OpenShift — это корпоративная платформа, которая помогает нескольким группам, таким как команда разработчиков и ИТ-специалистов, создавать и развертывать контейнерную инфраструктуру. Все контейнеры, встроенные в OpenShift, используют очень надежную технологию контейнеризации Docker, которая может быть развернута в любом центре обработки данных публично размещенных облачных платформ.

Контейнерная платформа OpenShift была формально известна как OpenShift Enterprises. Это локальная частная платформа Red Hat как услуга, построенная на основе базовой концепции контейнеров приложений на основе Docker, в которой управление оркестровкой и администрированием осуществляет Kubernetes.

Другими словами, OpenShift объединяет Docker и Kubernetes на уровне предприятия. Это программное обеспечение контейнерной платформы для корпоративных подразделений, позволяющее развертывать и управлять заявителями в инфраструктуре по своему выбору. Например, размещение экземпляров OpenShift на экземплярах AWS.

Контейнерная платформа OpenShift доступна в двух уровнях пакета .

OpenShift Container Local — это для тех разработчиков, которые хотят развертывать и тестировать приложения на локальном компьютере. Этот пакет в основном используется командами разработчиков для разработки и тестирования приложений.

OpenShift Container Lab — предназначена для расширенной оценки приложения, начиная с разработки и заканчивая развертыванием в среде pre-prod.

OpenShift, посвященный

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

Это одно из новейших предложений Red Hat, в котором конечный пользователь может использовать OpenShift для создания тестового развертывания и запуска своего приложения в OpenShift, размещенном в облаке.

Особенности OpenShift Dedicated

OpenShift предлагает специализированную платформу приложений решений в общедоступном облаке, и она унаследована от технологии OpenShift 3.

Расширяемый и открытый. Он основан на открытой концепции Docker и развернут в облаке, благодаря чему он может расходовать средства по мере необходимости.
Портативность. Поскольку приложение построено с использованием Docker, приложения, работающие на Docker, могут быть легко отправлены из одного места в другое, где поддерживается Docker.
Оркестровка — В OpenShift 3 одна из ключевых функций оркестровки контейнеров и управления кластерами поддерживается с помощью Kubernetes, который появился в OpenShift версии 3.
Автоматизация — эта версия OpenShift включена с возможностью управления исходным кодом, автоматизации сборки и автоматизации развертывания, что делает ее очень популярной на рынке в качестве платформы как поставщика услуг.

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

Портативность. Поскольку приложение построено с использованием Docker, приложения, работающие на Docker, могут быть легко отправлены из одного места в другое, где поддерживается Docker.

Оркестровка — В OpenShift 3 одна из ключевых функций оркестровки контейнеров и управления кластерами поддерживается с помощью Kubernetes, который появился в OpenShift версии 3.

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

Конкуренты OpenShift

Google App Engine — это бесплатная платформа Google для разработки и размещения веб-приложений. Механизм приложений Google предлагает платформу для быстрой разработки и развертывания.

Microsoft Azure — Облако Azure размещается Microsoft в своих центрах обработки данных.

Amazon Elastic Cloud Compute — это встроенные сервисы, предоставляемые Amazon, которые помогают в разработке и размещении масштабируемых веб-приложений в облаке.

Cloud Foundry — это платформа PaaS с открытым исходным кодом для приложений Java, Ruby, Python и Node.js.

CloudStack — Apache CloudStack — это проект, разработанный Citrix и призванный стать прямым конкурентом OpenShift и OpenStack.

OpenStack — еще одна облачная технология, предоставляемая Red Hat для облачных вычислений.

Kubernetes — это технология прямого управления и кластерного управления, созданная для управления контейнером Docker.

OpenShift — Архитектура

OpenShift — это многоуровневая система, в которой каждый слой тесно связан с другим уровнем с использованием кластера Kubernetes и Docker. Архитектура OpenShift разработана таким образом, что она может поддерживать и управлять контейнерами Docker, которые размещаются поверх всех слоев с использованием Kubernetes. В отличие от более ранней версии OpenShift V2, новая версия OpenShift V3 поддерживает контейнерную инфраструктуру. В этой модели Docker помогает создавать легкие контейнеры на основе Linux, а Kubernetes поддерживает задачу организации и управления контейнерами на нескольких хостах.

Компоненты OpenShift

Одним из ключевых компонентов архитектуры OpenShift является управление контейнерной инфраструктурой в Kubernetes. Kubernetes отвечает за развертывание и управление инфраструктурой. В любом кластере Kubernetes мы можем иметь более одного главного и несколько узлов, что гарантирует отсутствие сбоя в настройке.

Kubernetes Master Machine Компоненты

Etcd — хранит информацию о конфигурации, которая может использоваться каждым из узлов в кластере. Это хранилище значений ключей высокой доступности, которое может быть распределено по нескольким узлам. Он должен быть доступен только серверу API Kubernetes, поскольку он может содержать конфиденциальную информацию. Это распределенное ключевое значение Store, которое доступно всем.

Сервер API — Kubernetes — это сервер API, который обеспечивает все операции в кластере с использованием API. Сервер API реализует интерфейс, который означает, что различные инструменты и библиотеки могут легко взаимодействовать с ним. Kubeconfig — это пакет вместе с инструментами на стороне сервера, которые можно использовать для связи. Это разоблачает API Kubernetes ».

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

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

Узлы Kubernetes

Ниже приведены ключевые компоненты сервера Node, которые необходимы для связи с мастером Kubernetes.

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

Служба Kubelet — это небольшая служба в каждом узле, которая отвечает за передачу информации в службу уровня управления и обратно. Он взаимодействует с хранилищем etcd для чтения деталей конфигурации и значений Wright. Это связывается с главным компонентом для получения команд и работы. Затем процесс kubelet берет на себя ответственность за поддержание рабочего состояния и сервера узла. Он управляет сетевыми правилами, переадресацией портов и т. Д.

Прокси-сервис Kubernetes — это прокси-сервис, который работает на каждом узле и помогает сделать сервисы доступными для внешнего хоста. Помогает в пересылке запроса на исправление контейнеров. Прокси-сервис Kubernetes способен выполнять примитивную балансировку нагрузки. Это гарантирует, что сетевая среда предсказуема и доступна, но в то же время она также изолирована. Он управляет модулями на узлах, томами, секретами, проверкой работоспособности новых контейнеров и т. Д.

Интегрированный Реестр Контейнеров OpenShift

Реестр контейнеров OpenShift — это встроенное хранилище Red Hat, которое используется для хранения образов Docker. В последней интегрированной версии OpenShift появился пользовательский интерфейс для просмотра изображений во внутреннем хранилище OpenShift. Эти реестры могут содержать изображения с указанными тегами, которые впоследствии используются для создания из него контейнеров.

Часто используемые термины

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

Проект — их можно определить как переименованную версию домена, которая присутствовала в более ранней версии OpenShift V2.

Контейнер — это те, которые создаются после развертывания образа на узле кластера Kubernetes.

Узел . Узел — это рабочая машина в кластере Kubernetes, которая также называется minion для master. Это рабочие единицы, которые могут быть физическими, виртуальными или облачными.

Pod — Модуль — это набор контейнеров и его хранилище внутри узла кластера Kubernetes. Можно создать контейнер с несколькими контейнерами внутри. Например, хранение контейнера базы данных и контейнера веб-сервера внутри модуля.

OpenShift — настройка среды

В этой главе мы узнаем о настройке среды OpenShift.

Системные требования

Чтобы настроить корпоративный OpenShift, необходимо иметь активную учетную запись Red Hat. Поскольку OpenShift работает на архитектуре мастера и узла Kubernetes, нам необходимо установить их на отдельных машинах, где одна машина работает как мастер, а другая работает на узле. Для того, чтобы настроить оба, существуют минимальные системные требования.

Конфигурация главной машины

Ниже приведены минимальные системные требования для конфигурации главной машины.

Базовая машина, размещенная в физической, виртуальной или любой облачной среде.
По крайней мере, Linux 7 с необходимыми пакетами на этом экземпляре.
2 ядра процессора.
Не менее 8 ГБ ОЗУ.
30 ГБ встроенной памяти на жестком диске.

Базовая машина, размещенная в физической, виртуальной или любой облачной среде.

По крайней мере, Linux 7 с необходимыми пакетами на этом экземпляре.

2 ядра процессора.

Не менее 8 ГБ ОЗУ.

30 ГБ встроенной памяти на жестком диске.

Конфигурация узла машины

Физический или виртуальный базовый образ, указанный для главной машины.
По крайней мере, Linux 7 на машине.
Докер установлен с версией не ниже 1.6.
1 ядро процессора.
8 ГБ ОЗУ.
15 ГБ жесткий диск для размещения изображений и 15 ГБ для хранения изображений.

Пошаговое руководство по настройке OpenShift

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

Шаг 1 — Сначала установите Linux на обе машины, где Linux 7 должна быть наименьшей версией. Это можно сделать с помощью следующих команд, если у вас есть активная подписка Red Hat.

# subscription-manager repos --disable = "*"

# subscription-manager repos --enable = "rhel-7-server-rpms"

# subscription-manager repos --enable = "rhel-7-server-extras-rpms"

# subscription-manager repos --enable = "rhel-7-server-optional-rpms"

# subscription-manager repos --enable = "rhel-7-server-ose-3.0-rpms"

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install python-virtualenv

# yum install gcc

# yum install httpd-tools

# yum install docker

# yum update

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

Шаг 2. Настройте Docker таким образом, чтобы он разрешал небезопасную связь только в локальной сети. Для этого отредактируйте файл Docker внутри / etc / sysconfig. Если файл отсутствует, вам нужно создать его вручную.

# vi /etc/sysconfig/docker
OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24

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

Шаг 3 — Сгенерируйте ключи на главном компьютере, а затем скопируйте ключ id_rsa.pub в файл авторизованного ключа узлового компьютера, что можно сделать с помощью следующей команды.

# ssh-keygen

# ssh-copy-id -i .ssh/id_rsa.pub [email protected]

После того, как вы выполнили все вышеперечисленные настройки, далее следует настроить OpenShift версии 3 на главном компьютере.

Шаг 4 — На главном компьютере выполните следующую команду curl.

# sh <(curl -s https://install.openshift.com/ose )

Приведенная выше команда установит установку для OSV3. Следующим шагом будет настройка OpenShift V3 на машине.

Если вы не можете загрузить из Интернета напрямую, его можно загрузить с https://install.openshift.com/portable/oo-install-ose.tgz в виде пакета tar, из которого установщик может работать на локальном главном компьютере.

Как только у нас будет готовая настройка, нам нужно начать с фактической конфигурации OSV3 на машинах. Эта настройка очень специфична для тестирования среды на фактическое производство, у нас есть LDAP и другие компоненты.

Шаг 5 — На главном компьютере настройте следующий код, расположенный в /etc/openshift/master/master-config.yaml

# vi /etc/openshift/master/master-config.yaml
identityProviders:
- name: my_htpasswd_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /root/users.htpasswd
routingConfig:
subdomain: testing.com

Затем создайте стандартного пользователя для администрирования по умолчанию.

# htpasswd -c /root/users.htpasswd admin

Шаг 6 — Поскольку OpenShift использует реестр Docker для настройки изображений, нам нужно настроить реестр Docker. Это используется для создания и хранения образов Docker после сборки.

Создайте каталог на компьютере узла OpenShift с помощью следующей команды.

# mkdir /images

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

# oc login
Username: system:admin

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

# oc project default

Шаг 7 — Создайте реестр Docker.

#echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"registry"}}' | oc create -f -

Изменить пользовательские привилегии.

#oc edit scc privileged
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:registry

Создайте и отредактируйте реестр изображений.

#oadm registry --service-account = registry --
config = /etc/openshift/master/admin.kubeconfig --
credentials = /etc/openshift/master/openshift-registry.kubeconfig --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' --
mount-host = /images

Шаг 8 — Создайте маршрутизацию по умолчанию.

По умолчанию OpenShift использует OpenVswitch в качестве программной сети. Используйте следующую команду для создания маршрутизации по умолчанию. Это используется для балансировки нагрузки и прокси-маршрутизации. Маршрутизатор похож на реестр Docker, а также работает в реестре.

# echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"router"}}' | oc create -f -

Далее отредактируйте привилегии пользователя.

#oc edit scc privileged
users:
   - system:serviceaccount:openshift-infra:build-controller
   - system:serviceaccount:default:registry
   - system:serviceaccount:default:router

#oadm router router-1 --replicas = 1 --
credentials = '/etc/openshift/master/openshift-router.kubeconfig' --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}'

Шаг 9 — Настройте DNS.

Для обработки URL-запроса OpenShift нужна рабочая среда DNS. Эта конфигурация DNS необходима для создания подстановочного знака, который необходим для создания подстановочного знака DNS, указывающего на маршрутизатор.

# yum install bind-utils bind

# systemctl start named

# systemctl enable named

vi /etc/named.conf
options {listen-on port 53 { 10.123.55.111; };
forwarders {
   10.38.55.13;
   ;
};

zone "lab.com" IN {
   type master;
   file "/var/named/dynamic/test.com.zone";
   allow-update { none; };
};

Шаг 10 — Последний шаг — настроить github-сервер на главном компьютере OpenShift V3, что необязательно. Это можно легко сделать с помощью следующей последовательности команд.

#yum install curl openssh-server

#systemctl enable sshd

# systemctl start sshd

# firewall-cmd --permanent --add-service = http

# systemctl reload firewalld

#curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-

#yum install gitlab-ce

# gitlab-ctl reconfigure

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

OpenShift — базовая концепция

Прежде чем начать с фактической настройки и развертывания приложений, нам необходимо понять некоторые основные термины и понятия, используемые в OpenShift V3.

Контейнеры и изображения

Изображений

Это основные строительные блоки OpenShift, которые формируются из образов Docker. В каждом модуле OpenShift кластер имеет свои собственные изображения, работающие внутри него. Когда мы настраиваем модуль, у нас есть поле, которое будет объединено в реестр. Этот файл конфигурации извлечет образ и развернет его на узле кластера.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> Name of Pod
      spec:
containers:
- name: neo4j-server ------------------------> Name of the image
image: <Name of the Docker image>----------> Image to be pulled
imagePullPolicy: Always ------------->Image pull policy
command: [“echo”, “SUCCESS”] -------------------> Massage after image pull

Чтобы вытащить и создать из него образ, выполните следующую команду. OC — это клиент для связи со средой OpenShift после входа в систему.

$ oc create –f Tesing_for_Image_pull

Контейнер

Это создается, когда образ Docker развертывается в кластере OpenShift. При определении любой конфигурации мы определяем секцию контейнера в файле конфигурации. Внутри одного контейнера может быть несколько образов, и все контейнеры, работающие на узле кластера, управляются OpenShift Kubernetes.

spec:
   containers:
   - name: py ------------------------> Name of the container
   image: python----------> Image going to get deployed on container
   command: [“python”, “SUCCESS”]
   restartPocliy: Never --------> Restart policy of container

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

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
   - containerPort: 7500
      imagePullPolicy: Always
      -name: Database
      Image: mongoDB
      Ports:
      - containerPort: 7501
imagePullPolicy: Always

В приведенной выше конфигурации мы определили многоконтейнерный модуль с двумя образами Tomcat и MongoDB внутри.

Стручки и Услуги

Бобы

Pod можно определить как коллекцию контейнера и его хранилище внутри узла кластера OpenShift (Kubernetes). В общем, у нас есть два типа контейнеров, начиная с одного контейнера и заканчивая несколькими контейнерами.

Single Container Pod — Они могут быть легко созданы с помощью команды OC или файла базовой конфигурации yml.

$ oc run <name of pod> --image = <name of the image from registry>

Создайте его с помощью простого файла yaml следующим образом.

apiVersion: v1
kind: Pod
metadata:
   name: apache
spec:
   containers:
   - name: apache
   image: apache: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always

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

$ oc create –f apache.yml

Multi-Container Pod — это несколько контейнеров, в которых у нас работает более одного контейнера. Они создаются с использованием файлов yaml следующим образом.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
      - containerPort: 7501
imagePullPolicy: Always

После создания этих файлов мы можем просто использовать тот же метод, что и выше, для создания контейнера.

Сервис — Поскольку у нас есть набор контейнеров, работающих внутри модуля, таким же образом у нас есть сервис, который можно определить как логический набор модулей. Это абстрактный слой поверх модуля, который предоставляет одно имя IP и DNS, через которое можно получить доступ к модулям. Сервис помогает управлять конфигурацией балансировки нагрузки и очень легко масштабировать модуль. В OpenShift сервис — это объект REST, обожествление которого можно опубликовать в apiService на главном сервере OpenShift для создания нового экземпляра.

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
      - port: 8080
         targetPort: 31999

Строит и Потоки

Строит

В OpenShift сборка — это процесс преобразования изображений в контейнеры. Это обработка, которая преобразует исходный код в изображение. Этот процесс сборки работает по заранее определенной стратегии построения исходного кода для изображения.

Сборка обрабатывает несколько стратегий и источников.

Стратегии сборки

Source to Image — это в основном инструмент, который помогает в создании воспроизводимых изображений. Эти образы всегда находятся в состоянии готовности к запуску с помощью команды запуска Docker.
Сборка Docker — это процесс, в котором изображения создаются с использованием файла Docker с помощью простой команды сборки Docker.
Custom Build — это сборки, которые используются для создания базовых образов Docker.

Source to Image — это в основном инструмент, который помогает в создании воспроизводимых изображений. Эти образы всегда находятся в состоянии готовности к запуску с помощью команды запуска Docker.

Сборка Docker — это процесс, в котором изображения создаются с использованием файла Docker с помощью простой команды сборки Docker.

Custom Build — это сборки, которые используются для создания базовых образов Docker.

Источники сборки

Git — Этот источник используется, когда Git-репозиторий используется для построения изображений. Dockerfile не является обязательным. Конфигурации из исходного кода выглядят следующим образом.

source:
type: "Git"
git:
   uri: "https://github.com/vipin/testing.git"
   ref: "master"
contextDir: "app/dir"
dockerfile: "FROM openshift/ruby-22-centos7\nUSER example"

Dockerfile — Dockerfile используется в качестве входных данных в файле конфигурации.

source:
   type: "Dockerfile"
   dockerfile: "FROM ubuntu: latest
   RUN yum install -y httpd"

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

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

apiVersion: v1
kind: ImageStream
metadata:
   annotations:
      openshift.io/generated-by: OpenShiftNewApp
   generation: 1
   labels:
      app: ruby-sample-build
   selflink: /oapi/v1/namespaces/test/imagestreams/origin-ruby-sample
   uid: ee2b9405-c68c-11e5-8a99-525400f25e34
spec: {}
status:
   dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample
   tags:
   - items:
      - created: 2016-01-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-apache-sample
      generation: 1
      image: vklnld908.int.clsa.com/vipin/test
   tag: latest

Маршруты и шаблоны

Маршруты

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

В OpenShift маршруты создаются с использованием маршрутизаторов, которые развертываются администратором OpenShift в кластере. Маршрутизаторы используются для привязки портов HTTP (80) и https (443) к внешним приложениям.

Ниже приведены различные виды протоколов, поддерживаемых маршрутами.

HTTP
HTTPS
TSL и веб-сокет

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

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-Rservice"},
   "spec": {
      "selector": {"name":"RService-openshift"},
      "ports": [
         {
            "protocol": "TCP",
            "port": 8888,
            "targetPort": 8080
         }
      ]
   }
}

Затем выполните следующую команду, и служба будет создана.

$ oc create -f ~/training/content/Openshift-Rservice.json

Так выглядит сервис после создания.

$ oc describe service Openshift-Rservice

Name:              Openshift-Rservice
Labels:            <none>
Selector:          name = RService-openshift
Type:              ClusterIP
IP:                172.30.42.80
Port:              <unnamed> 8080/TCP
Endpoints:         <none>
Session Affinity:  None
No events.

Создайте маршрутизацию для сервиса, используя следующий код.

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-service-route"},
   "spec": {
      "host": "hello-openshift.cloudapps.example.com",
      "to": {
         "kind": "Service",
         "name": "OpenShift-route-service"
      },
      "tls": {"termination": "edge"}
   }
}

Когда команда OC используется для создания маршрута, создается новый экземпляр ресурса маршрута.

Шаблоны

Шаблоны определяются как стандартный объект в OpenShift, который можно использовать несколько раз. Он параметризован списком заполнителей, которые используются для создания нескольких объектов. Это может быть использовано для создания чего угодно, начиная от модуля и заканчивая сетью, для которого пользователи имеют право создавать. Список объектов может быть создан, если шаблон из интерфейса CLI или GUI в образе загружен в каталог проекта.

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

Аутентификация и Авторизация

Аутентификация

В OpenShift при настройке главной и клиентской структуры мастер предлагает встроенную функцию сервера OAuth. OAuth-сервер используется для генерации токенов, который используется для аутентификации в API. Так как OAuth является настройкой по умолчанию для master, у нас по умолчанию используется провайдер идентификации Allow All. Присутствуют разные провайдеры идентификации, которые можно настроить по адресу /etc/openshift/master/master-config.yaml .

В OAuth есть разные типы провайдеров идентификации.

Позволять все
Запретить все
Htpasswd
LDAP
Базовая аутентификация

Позволять все

apiVersion: v1
   kind: Pod
   metadata:
      name: redis-master
   spec:
      containers:
         image: dockerfile/redis
         name: master
      ports:
      - containerPort: 6379
         protocol: TCP
      oauthConfig:
      identityProviders:
      - name: my_allow_provider
         challenge: true
         login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Запретить все

apiVersion: v1
kind: Pod
metadata:
   name: redis-master
spec:
   containers:
      image: dockerfile/redis
   name: master
   ports:
   - containerPort: 6379
      protocol: TCP
   oauthConfig:
   identityProviders:
   - name: my_allow_provider
      challenge: true
      login: true
   provider:
      apiVersion: v1
      kind: DenyAllPasswordIdentityProvider

Htpasswd

Чтобы использовать HTPasswd, нам нужно сначала настроить Httpd-tools на главном компьютере, а затем настроить его так же, как мы это делали для других.

identityProviders:
   - name: my_htpasswd_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider

авторизация

Авторизация — это функция мастера OpenShift, которая используется для валидации пользователя. Это означает, что он проверяет пользователя, который пытается выполнить действие, чтобы определить, авторизован ли пользователь для выполнения этого действия в данном проекте. Это помогает администратору контролировать доступ к проектам.

Политики авторизации контролируются с помощью —

правила
Роли
Наручники

Оценка авторизации производится с использованием —

тождественность
действие
Наручники

Использование политик —

Кластерная политика
Местная политика

OpenShift — Начало работы

OpenShift состоит из двух типов медиан для создания и развертывания приложений с помощью графического интерфейса или интерфейса командной строки. В этой главе мы будем использовать CLI для создания нового приложения. Мы будем использовать клиент OC для связи со средой OpenShift.

Создание нового приложения

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

Из исходного кода
Из изображения
Из шаблона

Из исходного кода

Когда мы пытаемся создать приложение из исходного кода, OpenShift ищет файл Docker, который должен присутствовать в репозитории, который определяет процесс сборки приложения. Мы будем использовать oc new-app для создания приложения.

Первое, что следует иметь в виду при использовании репо, это то, что он должен указывать на источник в репо, откуда OpenShift будет извлекать код и собирать его.

Если репозиторий клонирован на компьютере Docker, на котором установлен клиент OC, и пользователь находится в том же каталоге, его можно создать с помощью следующей команды.

$ oc new-app . <Hear. Denotes current working directory>

Ниже приведен пример попытки построить из удаленного репо для определенной ветви.

$ oc new-app https://github.com/openshift/Testing-deployment.git#test1

Здесь test1 — это ветка, из которой мы пытаемся создать новое приложение в OpenShift.

При указании файла Docker в хранилище мы должны определить стратегию сборки, как показано ниже.

$ oc new-app OpenShift/OpenShift-test~https://github.com/openshift/Testingdeployment.git

Из изображения

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

OpenShift имеет возможность определять используемый источник, будь то образ Docker или поток источника. Однако, если пользователь желает, он может явно определить, является ли это потоком изображения или изображением Docker.

$ oc new-app - - docker-image tomcat

Использование потока изображений —

$ oc new-app tomcat:v1

Из шаблона

Шаблоны могут быть использованы для создания нового приложения. Это может быть уже существующий шаблон или создание нового шаблона.

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

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

Разработка и развертывание веб-приложения

Разработка нового приложения в OpenShift

Чтобы создать новое приложение в OpenShift, мы должны написать новый код приложения и собрать его, используя команды сборки OpenShift OC. Как уже говорилось, у нас есть несколько способов создания нового изображения. Здесь мы будем использовать шаблон для сборки приложения. Этот шаблон создаст новое приложение при запуске с помощью команды oc new-app.

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

Создать новое пространство имен

$ oc new-project openshift-test --display-name = "OpenShift 3 Sample" --
description = "This is an example project to demonstrate OpenShift v3"

шаблон

{
   "kind": "Template",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-helloworld-sample",
      "creationTimestamp": null,
         "annotations": {
         "description": "This example shows how to create a simple openshift
         application in openshift origin v3",
         "iconClass": "icon-openshift",
         "tags": "instant-app,openshift,mysql"
      }
   }
},

Определения объектов

Секретное определение в шаблоне

"objects": [
{
   "kind": "Secret",
   "apiVersion": "v1",
   "metadata": {"name": "dbsecret"},
   "stringData" : {
      "mysql-user" : "${MYSQL_USER}",
      "mysql-password" : "${MYSQL_PASSWORD}"
   }
},

Определение сервиса в шаблоне

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   },
   "spec": {
      "ports": [
         {
            "name": "web",
            "protocol": "TCP",
            "port": 5432,
            "targetPort": 8080,
            "nodePort": 0
         }
      ],
      "selector": {"name": "frontend"},
      "type": "ClusterIP",
      "sessionAffinity": "None"
   },
   "status": {
      "loadBalancer": {}
   }
},

Определение маршрута в шаблоне

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {
      "name": "route-edge",
      "creationTimestamp": null,
      "annotations": {
         "template.openshift.io/expose-uri": "http://{.spec.host}{.spec.path}"
      }
   },
   "spec": {
      "host": "www.example.com",
      "to": {
         "kind": "Service",
         "name": "frontend"
      },
      "tls": {
         "termination": "edge"
      }
   },
   "status": {}
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "origin-openshift-sample",
      "creationTimestamp": null
   },
   "spec": {},
   "status": {
      "dockerImageRepository": ""
   }
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-22-ubuntu7",
      "creationTimestamp": null 
   },
   "spec": {
      "dockerImageRepository": "ubuntu/openshift-22-ubuntu7"
   },
   "status": {
      "dockerImageRepository": ""
   }
},

Создать определение конфигурации в шаблоне

{
   "kind": "BuildConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-sample-build",
      "creationTimestamp": null,
      "labels": {name": "openshift-sample-build"}
   },
   "spec": {
      "triggers": [
         { "type": "GitHub",
            "github": {
            "secret": "secret101" } 
         },
         {
            "type": "Generic",
            "generic": {
               "secret": "secret101",
               "allowEnv": true } 
         },
         { 
            "type": "ImageChange",
            "imageChange": {} 
         },
         { "type": "ConfigChange”}
      ],
      "source": {
         "type": "Git",
         "git": {
            "uri": https://github.com/openshift/openshift-hello-world.git } 
      },
      "strategy": {
         "type": "Docker",
         "dockerStrategy": {
            "from": {
               "kind": "ImageStreamTag",
               "name": "openshift-22-ubuntu7:latest” 
            },
            "env": [
               {
                  "name": "EXAMPLE",
                  "value": "sample-app"
               } 
            ]
         }
      },
      "output": {
         "to": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      },
      "postCommit": {
         "args": ["bundle", "exec", "rake", "test"]
      },
      "status": {
         "lastVersion": 0
      }
   }
},

Конфигурация развертывания в шаблоне

"status": {
   "lastVersion": 0
}
{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   }
}, 
"spec": {
   "strategy": {
      "type": "Rolling",
      "rollingParams": {
         "updatePeriodSeconds": 1,
         "intervalSeconds": 1,
         "timeoutSeconds": 120,
         "pre": {
            "failurePolicy": "Abort",
            "execNewPod": {
               "command": [
                  "/bin/true"
               ],
               "env": [
                  { 
                     "name": "CUSTOM_VAR1",
                     "value": "custom_value1"
                  }
               ]
            }
         }
      }
   }
}
"triggers": [
   {
      "type": "ImageChange",
      "imageChangeParams": {
         "automatic": true,
         "containerNames": [
            "openshift-helloworld"
         ],
         "from": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      }
   },
   {
      "type": "ConfigChange"
   }
],
"replicas": 2,
"selector": {
   "name": "frontend"
},
"template": {
   "metadata": {
      "creationTimestamp": null,
      "labels": {
         "name": "frontend"
      }
   },
   "spec": {
      "containers": [
         {
            "name": "openshift-helloworld",
            "image": "origin-openshift-sample",
            "ports": [
               { 
                  "containerPort": 8080,
                  "protocol": "TCP” 
               }
            ],
            "env": [
               {
                  "name": "MYSQL_USER",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-user"
                     }
                  }
               },
               {
                  "name": "MYSQL_PASSWORD",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-password"
                     }
                  }
               },
               {
                  "name": "MYSQL_DATABASE",
                  "value": "${MYSQL_DATABASE}"
               }
            ],
            "resources": {},
            "terminationMessagePath": "/dev/termination-log",
            "imagePullPolicy": "IfNotPresent",
            "securityContext": {
               "capabilities": {},
               "privileged": false
            }
         }
      ],
      "restartPolicy": "Always",
      "dnsPolicy": "ClusterFirst"
   },
   "status": {}
},

Определение сервиса в шаблоне

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null 
   },
   "spec": {
   "ports": [
      {
         "name": "db",
         "protocol": "TCP",
         "port": 5434,
         "targetPort": 3306,
         "nodePort": 0
      } 
   ],
   "selector": {
      "name": "database 
   },
   "type": "ClusterIP",
   "sessionAffinity": "None" },
   "status": {
      "loadBalancer": {}
   }
},

Определение конфигурации развертывания в шаблоне

{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null
   },
   "spec": {
      "strategy": {
         "type": "Recreate",
         "resources": {}
      },
      "triggers": [
         {
            "type": "ConfigChange"
         }
      ],
      "replicas": 1,
      "selector": {"name": "database"},
      "template": {
         "metadata": {
            "creationTimestamp": null,
            "labels": {"name": "database"}
         },
         "template": {
            "metadata": {
               "creationTimestamp": null,
               "labels": {
                  "name": "database"
               } 
            },
            "spec": {
               "containers": [
                  {
                     "name": "openshift-helloworld-database",
                     "image": "ubuntu/mysql-57-ubuntu7:latest",
                     "ports": [
                        {
                           "containerPort": 3306,
                           "protocol": "TCP" 
                        }
                     ],
                     "env": [
                        {
                           "name": "MYSQL_USER",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-user"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_PASSWORD",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-password"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_DATABASE",
                           "value": "${MYSQL_DATABASE}" 
                        } 
                     ],
                     "resources": {},
                     "volumeMounts": [
                        {
                           "name": "openshift-helloworld-data",
                           "mountPath": "/var/lib/mysql/data"
                        }
                     ],
                     "terminationMessagePath": "/dev/termination-log",
                     "imagePullPolicy": "Always",
                     "securityContext": {
                        "capabilities": {},
                        "privileged": false
                     } 
                  }
               ],
               "volumes": [
                  { 
                     "name": "openshift-helloworld-data",
                     "emptyDir": {"medium": ""} 
                  } 
               ],
               "restartPolicy": "Always",
               "dnsPolicy": "ClusterFirst” 
            } 
         }
      },
      "status": {} 
   },
   "parameters": [
      { 
         "name": "MYSQL_USER",
         "description": "database username",
         "generate": "expression",
         "from": "user[A-Z0-9]{3}",
         "required": true 
      },
      {
         "name": "MYSQL_PASSWORD",
         "description": "database password",
         "generate": "expression",
         "from": "[a-zA-Z0-9]{8}",
         "required": true
      }, 
      {
         "name": "MYSQL_DATABASE",
         "description": "database name",
         "value": "root",
         "required": true 
      } 
   ],
   "labels": {
      "template": "application-template-dockerbuild" 
   } 
}

Приведенный выше файл шаблона необходимо скомпилировать сразу. Нам нужно сначала скопировать весь контент в один файл и назвать его как файл yaml после того, как он будет сделан.

Нам нужно выполнить следующую команду, чтобы создать приложение.

$ oc new-app application-template-stibuild.json
--> Deploying template openshift-helloworld-sample for "application-template-stibuild.json"

   openshift-helloworld-sample
   ---------
   This example shows how to create a simple ruby application in openshift origin v3
   * With parameters:
      * MYSQL_USER = userPJJ # generated
      * MYSQL_PASSWORD = cJHNK3se # generated
      * MYSQL_DATABASE = root

--> Creating resources with label app = ruby-helloworld-sample ...
   service "frontend" created
   route "route-edge" created
   imagestream "origin-ruby-sample" created
   imagestream "ruby-22-centos7" created
   buildconfig "ruby-sample-build" created
   deploymentconfig "frontend" created
   service "database" created
   deploymentconfig "database" created
   
--> Success
   Build scheduled, use 'oc logs -f bc/ruby-sample-build' to track its progress.
   Run 'oc status' to view your app.

Если мы хотим отслеживать сборку, это можно сделать с помощью —

$ oc get builds

NAME                        TYPE      FROM          STATUS     STARTED         DURATION
openshift-sample-build-1    Source   Git@bd94cbb    Running    7 seconds ago   7s

Мы можем проверить развернутые приложения в OpenShift, используя —

$ oc get pods
NAME                            READY   STATUS      RESTARTS   AGE
database-1-le4wx                1/1     Running     0          1m
frontend-1-e572n                1/1     Running     0          27s
frontend-1-votq4                1/1     Running     0          31s
opeshift-sample-build-1-build   0/1     Completed   0          1m

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

$ oc get services
NAME        CLUSTER-IP      EXTERNAL-IP     PORT(S)      SELECTOR          AGE
database    172.30.80.39    <none>         5434/TCP     name=database      1m
frontend    172.30.17.4     <none>         5432/TCP     name=frontend      1m

OpenShift — автоматизация сборки

В OpenShift у нас есть несколько методов автоматизации конвейера сборки. Для этого нам нужно создать ресурс BuildConfig для описания процесса сборки. Поток в BuildConfig можно сравнить с определением задания в определении задания Дженкинса. При создании потока сборки мы должны выбрать стратегию сборки.

Файл BuildConfig

В OpenShift BuildConfig — это объект отдыха, используемый для подключения к API, а затем для создания нового экземпляра.

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "<Name of build config file>"
spec:
   runPolicy: "Serial"
   triggers:
   -
      type: "GitHub"
      github:
         secret: "<Secrete file name>"
   - type: "Generic"
   generic:
      secret: "secret101"
   -
   type: "ImageChange"
   source:
      type: "<Source of code>"
      git:
   uri: "https://github.com/openshift/openshift-hello-world"
   dockerfile: "FROM openshift/openshift-22-centos7\nUSER example"
   strategy:
      type: "Source"
      
sourceStrategy:
   from:
      kind: "ImageStreamTag"
      name: "openshift-20-centos7:latest"
   output:
      to:
         kind: "ImageStreamTag"
         name: "origin-openshift-sample:latest"
   postCommit:
      script: "bundle exec rake test"

В OpenShift есть четыре типа стратегий сборки.

Стратегия исходного изображения
Стратегия докера
Индивидуальная стратегия
Трубопроводная стратегия

Стратегия исходного изображения

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

strategy:
   type: "Source"
   sourceStrategy:
      from:
         kind: "ImageStreamTag"
         name: "builder-image:latest"
      forcePull: true

Есть несколько стратегий стратегии.

Forcepull
Инкрементные сборки
Внешние сборки

Докерская стратегия

В этом потоке OpenShift использует Dockerfile для создания образа, а затем загружает созданные изображения в реестр Docker.

strategy:
   type: Docker
   dockerStrategy:
      from:
         kind: "ImageStreamTag"
         name: "ubuntu:latest"

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

Из изображения
Путь к Dockerfile
Нет кеша
Сила тяги

Индивидуальная стратегия

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

strategy:
   type: "Custom"
   customStrategy:
      from:
         kind: "DockerImage"
         name: "openshift/sti-image-builder"

Он состоит из нескольких стратегий сборки.

Разоблачить сокет Docker
Секреты
Сила тяги

Трубопроводная стратегия

Конвейерная стратегия используется для создания пользовательских конвейеров сборки. Это в основном используется для реализации рабочего процесса в конвейере. Этот поток сборки использует пользовательский поток конвейера сборки с использованием языка Groovy DSL. OpenShift создаст конвейерное задание в Jenkins и выполнит его. Этот трубопроводный поток также можно использовать в Jenkins. В этой стратегии мы используем Jenkinsfile и добавляем это в определение buildconfig.

Strategy:
   type: "JenkinsPipeline"
   jenkinsPipelineStrategy:
   jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}"

Использование сборки конвейера

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "test-pipeline"
spec:
   source:
      type: "Git"
      git:
         uri: "https://github.com/openshift/openshift-hello-world"
   strategy:
      type: "JenkinsPipeline"
      jenkinsPipelineStrategy:
         jenkinsfilePath: <file path repository>

OpenShift — CLI

OpenShift CLI используется для управления приложениями OpenShift из командной строки. OpenShift CLI имеет возможность управлять сквозным жизненным циклом приложения. В общем, мы будем использовать OC, который является клиентом OpenShift, для связи с OpenShift.

Настройка OpenShift CLI

Чтобы настроить клиент OC в другой операционной системе, нам нужно выполнить другую последовательность шагов.

OC Client для Windows

Шаг 1 — Загрузите oc cli по следующей ссылке https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Шаг 2 — Распакуйте пакет по целевому пути на машине.

Шаг 3 — Отредактируйте переменную окружения пути системы.

C:\Users\xxxxxxxx\xxxxxxxx>echo %PATH%

C:\oraclexe\app\oracle\product\10.2.0\server\bin;C:\Program Files 
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Program Files 
(x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\
v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files 
(x86)\ATI Technologies\ATI.ACE\C

ore-Static;C:\Program Files\Intel\Intel(R) Management Engine 
Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine 
Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;

Шаг 4 — Проверьте настройку OC в Windows.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc version
oc v3.6.0-alpha.2+3c221d5
kubernetes v1.6.1+5115d708d7
features: Basic-Auth

Клиент OC для Mac OS X

Мы можем загрузить двоичные файлы установки Mac OS для того же места, что и для Windows, а затем распаковать его в папку и указать путь к исполняемому файлу в переменной среды PATH.

альтернативно

Мы можем использовать Home brew и настроить его с помощью следующей команды.

$ brew install openshift-cli

OC Client для Linux

На этой же странице у нас есть tar-файл для установки Linux, который можно использовать для установки. Позже, переменная пути может быть установлена, указывая на это конкретное исполняемое местоположение.

https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Распакуйте файл tar, используя следующую команду.

$ tar –xf < path to the OC setup tar file >

Выполните следующую команду, чтобы проверить аутентификацию.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc login
Server [https://localhost:8443]:

Конфигурационные файлы CLI

Файл конфигурации OC CLI используется для управления несколькими серверами OpenShift и механизмом аутентификации. Этот файл конфигурации также используется для хранения и управления несколькими профилями и для переключения между ними. Обычный файл конфигурации выглядит следующим образом.

$ oc config view
apiVersion: v1
clusters:
   - cluster:
      server: https://vklnld908.int.example.com
   name: openshift
   
contexts:
- context:
   cluster: openshift
   namespace: testproject
   user: alice
   name: alice
current-context: alice
kind: Config
preferences: {}
users:
- name: vipin
   user:
      token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Настройка клиента CLI

Для настройки учетных данных пользователя

$ oc config set-credentials <user_nickname>
[--client-certificate = <path/to/certfile>] [--client-key=<path/to/keyfile>]
[--token = <bearer_token>] [--username = <basic_user>] [--password = <basic_password>]

Для настройки кластера

$ oc config set-cluster <cluster_nickname> [--server = <master_ip_or_fqdn>]
[--certificate-authority = <path/to/certificate/authority>]
[--api-version = <apiversion>] [--insecure-skip-tls-verify = true]

пример

$ oc config set-credentials vipin --token = ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Для настройки контекста

$ oc config set-context <context_nickname> [--cluster = <cluster_nickname>]
[--user = <user_nickname>] [--namespace = <namespace>]

Профили CLI

В одном файле конфигурации CLI у нас может быть несколько профилей, каждый из которых имеет свою конфигурацию сервера OpenShift, которую впоследствии можно использовать для переключения между различными профилями CLI.

apiVersion: v1
clusters: --→ 1
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld908.int.example.com:8443
   name: vklnld908.int.example.com:8443
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld1446.int.example.com:8443
   name: vklnld1446.int.example.com:8443
contexts: ---→ 2
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: openshift-project
   user: vipin/vklnld908.int.example.com:8443
   name: openshift-project/vklnld908.int.example.com:8443/vipin
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: testing-project
   user: alim/vklnld908.int.example.com:8443
   name: testproject-project/openshift1/alim
current-context: testing-project/vklnld908.int.example.com:8443/vipin - 3
kind: Config
preferences: {}

users:
- name: vipin/vklnld908.int.example.com:8443
user: ---→ 4
   token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

В приведенной выше конфигурации мы видим, что она разделена на четыре основных раздела, начиная с кластера, который определяет два экземпляра главных машин OpenShift. Второй контекстный раздел определяет два контекста с именами vipin и alim. Текущий контекст определяет, какой контекст используется в данный момент. Он может быть изменен на другой контекст или профиль, если мы изменим определение здесь. Наконец, определяется пользовательское определение и его токен аутентификации, который в нашем случае является vipin.

Если мы хотим проверить текущий профиль в использовании, это можно сделать с помощью —

$ oc status
oc status
In project testing Project (testing-project)
$ oc project
Using project "testing-project" from context named "testing-
project/vklnld908.int.example.com:8443/vipin" on server "https://vklnld908.int.example.com:8443".

Если мы хотим переключиться на другой интерфейс командной строки, это можно сделать из командной строки, используя следующую команду.

$ oc project openshift-project
Now using project "Openshift-project" on server "
https://vklnld908.int.example.com:8443".

Используя приведенную выше команду, мы можем переключаться между профилями. В любой момент времени, если мы хотим просмотреть конфигурацию, мы можем использовать команду $ oc config view.

OpenShift — Операции CLI

OpenShift CLI способен выполнять все основные и расширенные настройки, управления, добавления и развертывания приложений.

Мы можем выполнять различные виды операций, используя команды OC. Этот клиент помогает вам разрабатывать, создавать, развертывать и запускать приложения на любой платформе, совместимой с OpenShift или Kubernetes. Сюда также входят административные команды для управления кластером подкомандой adm.

Основные команды

В следующей таблице перечислены основные команды OC.

Sr.No.	Команды и описание
1	Типы Введение в понятия и тип
2	Авторизоваться Войти на сервер
3	новый проект Запросить новый проект
4	новое приложение Создать новое приложение
5	Статус Показать обзор текущего проекта
6	проект Переключиться на другой проект
7	проектов Показать существующие проекты
8	объяснять Документация ресурсов
9	кластер Запустить и остановить кластер OpenShift

Типы

Введение в понятия и тип

Авторизоваться

Войти на сервер

новый проект

Запросить новый проект

новое приложение

Создать новое приложение

Статус

Показать обзор текущего проекта

проект

Переключиться на другой проект

проектов

Показать существующие проекты

объяснять

Документация ресурсов

кластер

Запустить и остановить кластер OpenShift

Авторизоваться

Войдите на свой сервер и сохраните логин для последующего использования. Пользователи, впервые работающие с клиентом, должны выполнить эту команду, чтобы подключиться к серверу, установить сеанс с проверкой подлинности и сохранить подключение в файле конфигурации. Конфигурация по умолчанию будет сохранена в вашем домашнем каталоге в .kube / config.

Информация, необходимая для входа в систему, такая как имя пользователя и пароль, токен сеанса или сведения о сервере, может быть предоставлена с помощью флагов. Если не указано, команда будет запрашивать ввод пользователя по мере необходимости.

использование

oc login [URL] [options]

пример

# Log in interactively
oc login

# Log in to the given server with the given certificate authority file
oc login localhost:8443 --certificate-authority = /path/to/cert.crt

# Log in to the given server with the given credentials (will not prompt interactively)
oc login localhost:8443 --username = myuser --password=mypass

Варианты —

-p, —password = « — Пароль, предложит, если не указан

-u, —username = « — Имя пользователя , подскажет , если не указано

—certificate-authority = « — Путь к файлу сертификата для центра сертификации.

—insecure-skip-tls-verify = false — если установлено значение true, сертификат сервера не будет проверен на достоверность. Это сделает ваши HTTPS-соединения небезопасными

—token = « — токен на предъявителя для аутентификации на сервере API

Чтобы получить полную информацию о любой команде, используйте команду oc <Имя команды> —help .

Команды сборки и развертывания

В следующей таблице перечислены команды построения и развертывания.

Sr.No.	Команды и описание
1	Посадочная дистанция Управление развертыванием в Kubernetes или OpenShift
2	развертывание Просмотреть, запустить, отменить или повторить развертывание
3	отмена Вернуть часть приложения обратно в предыдущее состояние
4	новое строительство Создать новую конфигурацию сборки
5	запуск сборки Начать новую сборку
6	отменить-сборка Отменить запущенные, ожидающие или новые сборки
7	импорт-изображение Импортирует изображения из реестра Docker
8	Тег Помечать существующие изображения в потоки изображений

Посадочная дистанция

Управление развертыванием в Kubernetes или OpenShift

развертывание

Просмотреть, запустить, отменить или повторить развертывание

отмена

Вернуть часть приложения обратно в предыдущее состояние

новое строительство

Создать новую конфигурацию сборки

запуск сборки

Начать новую сборку

отменить-сборка

Отменить запущенные, ожидающие или новые сборки

импорт-изображение

Импортирует изображения из реестра Docker

Тег

Помечать существующие изображения в потоки изображений

Команды управления приложениями

В следующей таблице перечислены команды управления приложениями.

Sr.No.	Команды и описание
1	Получить Показать один или несколько ресурсов
2	описывать Показать детали конкретного ресурса или группы ресурсов
3	редактировать Редактировать ресурс на сервере
4	Задавать Команды, которые помогают установить определенные функции на объектах
5	этикетка Обновите метки на ресурсе
6	аннотировать Обновите аннотации на ресурсе
7	разоблачать Предоставить реплицированное приложение в качестве службы или маршрута.
8	удалять Удалить один или несколько ресурсов
9	Масштаб Измените количество модулей в развертывании
10	Autoscale Автоматическое масштабирование конфигурации развертывания, развертывания, репликации, контроллера или набора реплик
11	Секреты Управляй секретами
12	Serviceaccounts Управление учетными записями в вашем проекте

Получить

Показать один или несколько ресурсов

описывать

Показать детали конкретного ресурса или группы ресурсов

редактировать

Редактировать ресурс на сервере

Задавать

Команды, которые помогают установить определенные функции на объектах

этикетка

Обновите метки на ресурсе

аннотировать

Обновите аннотации на ресурсе

разоблачать

Предоставить реплицированное приложение в качестве службы или маршрута.

удалять

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

Масштаб

Измените количество модулей в развертывании

Autoscale

Автоматическое масштабирование конфигурации развертывания, развертывания, репликации, контроллера или набора реплик

Секреты

Управляй секретами

Serviceaccounts

Управление учетными записями в вашем проекте

Команды для устранения неполадок и отладки

В следующей таблице перечислены команды устранения неполадок и отладки.

Sr.No.	Команды и описание
1	бревна Распечатать журналы для ресурса
2	Rsh Начать сессию оболочки в модуле
3	Rsync Копировать файлы между локальной файловой системой и модулем
4	Порт вперед Переадресация одного или нескольких локальных портов на модуль
5	отлаживать Запустить новый экземпляр модуля для отладки.
6	Exec Выполнить команду в контейнере
7	Procy Запустите прокси на сервере API Kubernetes
9	Прикреплять Присоединить к работающему контейнеру
10	Бежать Запустить определенное изображение в кластере
11	Cp Копировать файлы и каталоги в и из контейнеров

бревна

Распечатать журналы для ресурса

Rsh

Начать сессию оболочки в модуле

Rsync

Копировать файлы между локальной файловой системой и модулем

Порт вперед

Переадресация одного или нескольких локальных портов на модуль

отлаживать

Запустить новый экземпляр модуля для отладки.

Exec

Выполнить команду в контейнере

Procy

Запустите прокси на сервере API Kubernetes

Прикреплять

Присоединить к работающему контейнеру

Бежать

Запустить определенное изображение в кластере

Копировать файлы и каталоги в и из контейнеров

Расширенные команды

В следующей таблице перечислены дополнительные команды.

Sr.No.	Команды и описание
1	адм Инструменты для управления кластером
2	Создайте Создать ресурс по имени файла или стандартному вводу
3	замещать Заменить ресурс по имени файла или стандартному вводу
4	применять Применить конфигурацию к ресурсу по имени файла или стандартному вводу
5	пластырь Обновите поле (я) ресурса, используя стратегическое исправление слияния
6	процесс Обработать шаблон в список ресурсов
7	экспорт Экспортируйте ресурсы, чтобы их можно было использовать в другом месте.
8	экстракт Извлекать секреты или конфиг карты на диск
9	вхолостую Неактивные масштабируемые ресурсы
10	наблюдать Наблюдайте за изменениями в ресурсах и реагируйте на них (экспериментально)
11	политика Управление политикой авторизации
12	авт Проверить авторизацию
13	перерабатывать Конвертировать конфигурационные файлы между разными версиями API
14	Импортировать Команды, которые импортируют приложения

адм

Инструменты для управления кластером

Создайте

Создать ресурс по имени файла или стандартному вводу

замещать

Заменить ресурс по имени файла или стандартному вводу

применять

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

пластырь

Обновите поле (я) ресурса, используя стратегическое исправление слияния

процесс

Обработать шаблон в список ресурсов

экспорт

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

экстракт

Извлекать секреты или конфиг карты на диск

вхолостую

Неактивные масштабируемые ресурсы

наблюдать

Наблюдайте за изменениями в ресурсах и реагируйте на них (экспериментально)

политика

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

авт

Проверить авторизацию

перерабатывать

Конвертировать конфигурационные файлы между разными версиями API

Импортировать

Команды, которые импортируют приложения

Настройка команд

В следующей таблице перечислены команды настройки.

Sr.No.	Команды и описание
1	Выйти Завершить текущий сеанс сервера
2	конфиг Изменить файлы конфигурации для клиента
3	Кто я Вернуть информацию о текущей сессии
4	завершение Выходной код завершения оболочки для указанной оболочки (bash или zsh)

Выйти

Завершить текущий сеанс сервера

конфиг

Изменить файлы конфигурации для клиента

Кто я

Вернуть информацию о текущей сессии

завершение

Выходной код завершения оболочки для указанной оболочки (bash или zsh)

OpenShift — Кластеры

OpenShift использует два метода установки для настройки кластера OpenShift.

Метод быстрой установки
Расширенный метод настройки

Настройка кластера

Метод быстрой установки

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

Интерактивный метод

$ atomic-openshift-installer install

Это полезно, когда вы хотите запустить интерактивную установку.

Метод автоматической установки

Этот метод используется, когда требуется установить метод автоматической установки, при котором пользователь может определить файл конфигурации yaml и поместить его в ~ / .config / openshift / с именем installer.cfg.yml. Затем можно выполнить следующую команду для установки тега –u .

$ atomic-openshift-installer –u install

По умолчанию он использует файл конфигурации, расположенный в ~ / .config / openshift / . Ansible, с другой стороны, используется в качестве резервной копии установки.

version: v2
variant: openshift-enterprise
variant_version: 3.1
ansible_log_path: /tmp/ansible.log

deployment:
   ansible_ssh_user: root
   hosts:
   - ip: 172.10.10.1
   hostname: vklnld908.int.example.com
   public_ip: 24.222.0.1
   public_hostname: master.example.com
   roles:
      - master
      - node
   containerized: true
   connect_to: 24.222.0.1
   
   - ip: 172.10.10.2
   hostname: vklnld1446.int.example.com
   public_ip: 24.222.0.2
   public_hostname: node1.example.com
   roles:
      - node
   connect_to: 10.0.0.2
   
   - ip: 172.10.10.3
   hostname: vklnld1447.int.example.com
   public_ip: 10..22.2.3
   public_hostname: node2.example.com
   roles:
      - node
   connect_to: 10.0.0.3

roles:
   master:
      <variable_name1>: "<value1>"
      <variable_name2>: "<value2>"
   node:
      <variable_name1>: "<value1>"

Здесь у нас есть ролевая переменная, которую можно определить, если вы хотите установить какую-то конкретную переменную.

После этого мы можем проверить установку с помощью следующей команды.

$ oc get nodes
NAME                    STATUS    AGE
master.example.com      Ready     10d
node1.example.com       Ready     10d
node2.example.com       Ready     10d

Расширенная установка

Расширенная установка полностью основана на конфигурации Ansible, в которой присутствует полная конфигурация хоста и определение переменных, относящихся к конфигурации мастера и узла. Это содержит все детали, касающиеся конфигурации.

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

$ ansible-playbook -i inventry/hosts ~/openshift-ansible/playbooks/byo/config.yml

Добавление хостов в кластер

Мы можем добавить хост в кластер, используя —

Инструмент быстрой установки
Расширенный метод настройки

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

$ atomic-openshift-installer -u -c </path/to/file> scaleup

Формат масштабирования внешнего вида конфигурационного файла приложения можно использовать для добавления как главного, так и узла.

Расширенный метод настройки

В этом методе мы обновляем файл хоста Ansible, а затем добавляем новый узел или сведения о сервере в этот файл. Файл конфигурации выглядит следующим образом.

[OSEv3:children]
masters
nodes
new_nodes
new_master

В том же файле Ansible hosts добавьте переменные детали относительно нового узла, как показано ниже.

[new_nodes]
vklnld1448.int.example.com openshift_node_labels = "{'region': 'primary', 'zone': 'east'}"

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

$ ansible-playbook -i /inventory/hosts /usr/share/ansible/openshift-ansible/playbooks/test/openshift-node/scaleup.yml

Управление кластерными журналами

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

Немногие из перечисленных инструментов доступны для управления журналами.

Fluentd
ELK
Kabna
Nagios
Splunk

Стек ELK — этот стек полезен при попытке собрать журналы со всех узлов и представить их в систематическом формате. Стек ELK в основном делится на три основные категории.

ElasticSearch — в основном ответственный за сбор информации из всех контейнеров и размещение ее в центральном месте.

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

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

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

Лог Диагностика

OpenShift имеет встроенную команду oc adm dignostics с OC, которую можно использовать для анализа множественных ошибок. Этот инструмент можно использовать от мастера в качестве администратора кластера. Эта утилита очень полезна для устранения неполадок и выявления известных проблем. Это работает на главном клиенте и узлах.

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

AggregatedLogging
AnalyzeLogs
ClusterRegistry
ClusterRoleBindings
ClusterRoles
ClusterRouter
ConfigContexts
DiagnosticPod
MasterConfigCheck
MasterNode
MetricsApiProxy
NetworkCheck
NodeConfigCheck
NodeDefinitions
ServiceExternalIPs
UnitStatus

Можно просто запустить их с помощью следующей команды.

$ oc adm diagnostics <DiagnosticName>

Обновление кластера

Обновление кластера включает в себя обновление нескольких компонентов внутри кластера и получение кластера, обновленного новыми компонентами и обновлениями. Это включает в себя —

Обновление основных компонентов
Обновление узловых компонентов
Обновление политик
Модернизация маршрутов
Обновление потока изображений

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

атомно-OpenShift-Utils
атомно-OpenShift-Excluder
атомно-OpenShift-докер-Excluder
пакет etcd

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

$ ETCD_DATA_DIR = /var/lib/origin/openshift.local.etcd
$ etcdctl backup \
   --data-dir $ETCD_DATA_DIR \
   --backup-dir $ETCD_DATA_DIR.bak.<date>

Обновление основных компонентов

В OpenShift master мы запускаем обновление, обновляя файл etcd, а затем переходим к Docker. Наконец, мы запускаем автоматический исполнитель, чтобы получить кластер в нужном положении. Однако перед началом обновления нам нужно сначала активировать атомарные пакеты openshift на каждом из мастеров. Это можно сделать с помощью следующих команд.

Шаг 1 — Удалить пакеты atomic-openshift

$ atomic-openshift-excluder unexclude

Шаг 2 — Обновите etcd на всех мастерах.

$ yum update etcd

Шаг 3 — Перезапустите службу etcd и проверьте, успешно ли она началась.

$ systemctl restart etcd
$ journalctl -r -u etcd

Шаг 4 — Обновите пакет Docker.

$ yum update docker

Шаг 5 — Перезапустите сервис Docker и проверьте, правильно ли он работает.

$ systemctl restart docker
$ journalctl -r -u docker

Шаг 6 — После завершения перезагрузите систему с помощью следующих команд.

$ systemctl reboot
$ journalctl -r -u docker

Шаг 7. Наконец, запустите atomic-execute, чтобы вернуть пакеты в список исключений yum.

$ atomic-openshift-excluder exclude

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

$ oadm policy reconcile-cluster-roles

В большинстве случаев нам не нужно обновлять определение политики.

Обновление узловых компонентов

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

Шаг 1 — Удалите все атомарные пакеты OpenShift со всех узлов, на которых вы хотите выполнить обновление.

$ atomic-openshift-excluder unexclude

Шаг 2 — Затем отключите планирование узлов перед обновлением.

$ oadm manage-node <node name> --schedulable = false

Шаг 3 — Реплицируйте все узлы с текущего хоста на другой хост.

$ oadm drain <node name> --force --delete-local-data --ignore-daemonsets

Шаг 4 — Обновите настройку Docker на хосте.

$ yum update docker

Шаг 5 — Перезапустите службу Docker, а затем запустите узел службы Docker.

$systemctl restart docker
$ systemctl restart atomic-openshift-node

Шаг 6 — Проверьте, правильно ли они запущены.

$ journalctl -r -u atomic-openshift-node

Шаг 7 — После завершения обновления перезагрузите узел компьютера.

$ systemctl reboot
$ journalctl -r -u docker

Шаг 8 — Снова включите планирование на узлах.

$ oadm manage-node <node> --schedulable.

Шаг 9 — Запустите исполнитель atomic-openshift, чтобы вернуть пакет OpenShift на узел.

$ atomic-openshift-excluder exclude

Шаг 10 — Наконец, проверьте, все ли узлы доступны.

$ oc get nodes

NAME                 STATUS   AGE
master.example.com   Ready    12d
node1.example.com    Ready    12d
node2.example.com    Ready    12d

OpenShift — масштабирование приложения

Автоматическое масштабирование — это функция в OpenShift, где развертываемые приложения могут масштабироваться и уменьшаться в зависимости от требований в соответствии с определенными спецификациями. В приложении OpenShift автоматическое масштабирование также называется автоматическим масштабированием. Существует два типа масштабирования приложения следующим образом.

Вертикальное масштабирование

Вертикальное масштабирование — это все больше и больше энергии на одной машине, что означает добавление процессора и жесткого диска. Это старый метод OpenShift, который сейчас не поддерживается в выпусках OpenShift.

Горизонтальное масштабирование

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

В OpenShift есть два способа включить функцию масштабирования .

Использование файла конфигурации развертывания
Во время запуска изображения

Использование файла конфигурации развертывания

В этом методе функция масштабирования включается через файл yaml конфигурации deploymant. Для этого используется команда OC autoscale с минимальным и максимальным количеством реплик, которые необходимо запустить в любой момент времени в кластере. Нам нужно определение объекта для создания автомасштабатора. Ниже приведен пример файла определения pod autoscaler.

apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
   name: database
spec:
   scaleRef:
      kind: DeploymentConfig
      name: database
      apiVersion: v1
      subresource: scale
   minReplicas: 1
   maxReplicas: 10
   cpuUtilization:
      targetPercentage: 80

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

$ oc create –f <file name>.yaml

Во время запуска изображения

Можно также автоматически масштабировать без файла yaml, используя следующую команду oc autoscale в командной строке oc.

$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75
deploymentconfig "database" autoscaled

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

Стратегии развертывания в OpenShift

Стратегия развертывания в OpenShift определяет поток развертывания с различными доступными методами. В OpenShift ниже перечислены важные типы стратегий развертывания .

Роллинг стратегия
Воссоздать стратегию
Индивидуальная стратегия

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

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
   name: "database"
spec:
   template:
      metadata:
         labels:
            name: "Database1"
spec:
   containers:
      - name: "vipinopenshifttest"
         image: "openshift/mongoDB"
         ports:
            - containerPort: 8080
               protocol: "TCP"
replicas: 5
selector:
   name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
   imageChangeParams:
      automatic: true
      containerNames:
         - "vipinopenshifttest"
      from:
         kind: "ImageStreamTag"
         name: "mongoDB:latest"
   strategy:
      type: "Rolling"

В приведенном выше файле Deploymentconfig у нас есть стратегия Rolling.

Мы можем использовать следующую команду OC для развертывания.

$ oc deploy <deployment_config> --latest

Скользящая стратегия

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

strategy:
   type: Rolling
   rollingParams:
      timeoutSeconds: <time in seconds>
      maxSurge: "<definition in %>"
      maxUnavailable: "<Defintion in %>"
      pre: {}
      post: {}

Воссоздать Стратегию

Эта стратегия развертывания имеет некоторые основные функции стратегии развертывания и поддерживает ловушку жизненного цикла.

strategy:
   type: Recreate
   recreateParams:
      pre: {}
      mid: {}
      post: {}

Индивидуальная стратегия

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

strategy:
   type: Custom
   customParams:
      image: organization/mongoDB
      command: [ "ls -l", "$HOME" ]
      environment:
         - name: VipinOpenshiftteat
         value: Dev1

OpenShift — Администрирование

В этой главе мы рассмотрим такие темы, как управление узлом, настройка учетной записи службы и т. Д.

Конфигурация мастера и узла

В OpenShift нам нужно использовать команду start вместе с OC для загрузки нового сервера. При запуске нового мастера нам нужно использовать мастер вместе с командой запуска, тогда как при запуске нового узла нам нужно использовать узел вместе с командой запуска. Чтобы сделать это, нам нужно создать файлы конфигурации для мастера, а также для узлов. Мы можем создать базовый файл конфигурации для мастера и узла, используя следующую команду.

Для главного файла конфигурации

$ openshift start master --write-config = /openshift.local.config/master

Для файла конфигурации узла

$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>

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

apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
   logoutURL: ""
   masterPublicURL: https://172.10.12.1:7449
   publicURL: https://172.10.2.2:7449/console/
      servingInfo:
         bindAddress: 0.0.0.0:7449
         certFile: master.server.crt
         clientCA: ""
keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
   bindAddress: 0.0.0.0:53
etcdClientInfo:
   ca: ca.crt
   certFile: master.etcd-client.crt
   keyFile: master.etcd-client.key
   urls:
   - https://10.0.2.15:4001
etcdConfig:
   address: 10.0.2.15:4001
   peerAddress: 10.0.2.15:7001
   peerServingInfo:
      bindAddress: 0.0.0.0:7001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   servingInfo:
      bindAddress: 0.0.0.0:4001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
   kubernetesStoragePrefix: kubernetes.io
   kubernetesStorageVersion: v1
   openShiftStoragePrefix: openshift.io
   openShiftStorageVersion: v1
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: MasterConfig
kubeletClientInfo:
   ca: ca.crt
   certFile: master.kubelet-client.crt
   keyFile: master.kubelet-client.key
   port: 10250
kubernetesMasterConfig:
   apiLevels:
   - v1beta3
   - v1
   apiServerArguments: null
   controllerArguments: null
   masterCount: 1
   masterIP: 10.0.2.15
   podEvictionTimeout: 5m
   schedulerConfigFile: ""
   servicesNodePortRange: 30000-32767
   servicesSubnet: 172.30.0.0/16
   staticNodeNames: []
masterClients:
   externalKubernetesKubeConfig: ""
   openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
   clusterNetworkCIDR: 10.1.0.0/16
   hostSubnetLength: 8
   networkPluginName: ""
   serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
   assetPublicURL: https://172.10.2.2:7449/console/
   grantConfig:
      method: auto
   identityProviders:
   - challenge: true
   login: true
   name: anypassword
   provider:
      apiVersion: v1
      kind: AllowAllPasswordIdentityProvider
   masterPublicURL: https://172.10.2.2:7449/
   masterURL: https://172.10.2.2:7449/
   sessionConfig:
      sessionMaxAgeSeconds: 300
      sessionName: ssn
      sessionSecretsFile: ""
   tokenConfig:
      accessTokenMaxAgeSeconds: 86400
      authorizeTokenMaxAgeSeconds: 300
policyConfig:
   bootstrapPolicyFile: policy.json
   openshiftInfrastructureNamespace: openshift-infra
   openshiftSharedResourcesNamespace: openshift
projectConfig:
   defaultNodeSelector: ""
   projectRequestMessage: ""
   projectRequestTemplate: ""
   securityAllocator:
      mcsAllocatorRange: s0:/2
      mcsLabelsPerProject: 5
      uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
   subdomain: router.default.svc.cluster.local
serviceAccountConfig:
   managedNames:
   - default
   - builder
   - deployer
   
masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
servingInfo:
   bindAddress: 0.0.0.0:8443
   certFile: master.server.crt
   clientCA: ca.crt
   keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 3600

Файлы конфигурации узла

allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
   execHandlerName: native
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
   mtu: 1450
   networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com

podManifestConfig:
   path: "/path/to/pod-manifest-file"
   fileCheckIntervalSeconds: 30
servingInfo:
   bindAddress: 0.0.0.0:10250
   certFile: server.crt
   clientCA: node-client-ca.crt
   keyFile: server.key
volumeDirectory: /root/openshift.local.volumes

Вот так выглядят файлы конфигурации узла. Как только у нас есть эти файлы конфигурации, мы можем запустить следующую команду для создания главного сервера и сервера узлов.

$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml

Управляющие узлы

В OpenShift у нас есть утилита командной строки OC, которая в основном используется для выполнения всех операций в OpenShift. Мы можем использовать следующие команды для управления узлами.

Для перечисления узла

$ oc get nodes
NAME                             LABELS
node1.example.com     kubernetes.io/hostname = vklnld1446.int.example.com
node2.example.com     kubernetes.io/hostname = vklnld1447.int.example.com

Описание деталей об узле

$ oc describe node <node name>

Удаление узла

$ oc delete node <node name>

Список модулей на узле

$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

Оценка стручков на узле

$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]

Аутентификация конфигурации

В мастере OpenShift есть встроенный сервер OAuth, который можно использовать для управления аутентификацией. Все пользователи OpenShift получают токен с этого сервера, который помогает им общаться с OpenShift API.

В OpenShift есть разные уровни аутентификации, которые можно настроить вместе с основным файлом конфигурации.

Позволять все
Запретить все
Htpasswd
LDAP
Базовая аутентификация
Заголовок запроса

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

Позволять все

oauthConfig:
   ...
   identityProviders:
   - name: Allow_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Запретить все

Это запретит доступ ко всем именам пользователей и паролям.

oauthConfig:
   ...
   identityProviders:
   - name: deny_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: DenyAllPasswordIdentityProvider

Htpasswd

HTPasswd используется для проверки имени пользователя и пароля по отношению к зашифрованному файлу пароля.

Для создания зашифрованного файла, следующая команда.

$ htpasswd </path/to/users.htpasswd> <user_name>

Использование зашифрованного файла.

oauthConfig:
   ...
   identityProviders:
   - name: htpasswd_authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider
         file: /path/to/users.htpasswd

Поставщик удостоверений LDAP

Это используется для аутентификации LDAP, где сервер LDAP играет ключевую роль в аутентификации.

oauthConfig:
   ...
   identityProviders:
   - name: "ldap_authontication"
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: LDAPPasswordIdentityProvider
         attributes:
            id:
            - dn
            email:
            - mail
            name:
            - cn
            preferredUsername:
            - uid
         bindDN: ""
         bindPassword: ""
         ca: my-ldap-ca-bundle.crt
         insecure: false
         url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"

Базовая аутентификация

Это используется, когда проверка имени пользователя и пароля выполняется на основе межсерверной аутентификации. Аутентификация защищена в базовом URL и представлена в формате JSON.

oauthConfig:
   ...
   identityProviders:
   - name: my_remote_basic_auth_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: BasicAuthPasswordIdentityProvider
         url: https://www.vklnld908.int.example.com/remote-idp
         ca: /path/to/ca.file
         certFile: /path/to/client.crt
         keyFile: /path/to/client.key

Настройка учетной записи службы

Учетные записи служб предоставляют гибкий способ доступа к API OpenShift, предоставляя имя пользователя и пароль для аутентификации.

Включение учетной записи службы

Сервисная учетная запись использует пару ключей открытого и закрытого ключей для аутентификации. Аутентификация в API выполняется с использованием закрытого ключа и проверки его по открытому ключу.

ServiceAccountConfig:
   ...
   masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
   - ...

Создание учетной записи службы

Используйте следующую команду для создания учетной записи службы

$ Openshift cli create service account <name of server account>

Работа с HTTP прокси

В большинстве производственных сред прямой доступ к Интернету ограничен. Они либо не подключены к Интернету, либо через HTTP или HTTPS-прокси. В среде OpenShift это определение прокси-машины устанавливается как переменная среды.

Это можно сделать, добавив определение прокси-сервера в файлы master и node, расположенные в / etc / sysconfig . Это похоже на то, что мы делаем для любого другого приложения.

Мастер Машина

/ И т.д. / sysconfig / OpenShift-мастер

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

Узел Машина

/ И т.д. / sysconfig / OpenShift-узел

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

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

Для Docker Pull

/ И т.д. / sysconfig / Докер

HTTP_PROXY = http://USERNAME:[email protected]:8080/
HTTPS_PROXY = https://USERNAME:[email protected]:8080/
NO_PROXY = master.vklnld1446.int.example.com

Чтобы запустить модуль в прокси-среде, это можно сделать с помощью —

containers:
- env:
   - name: "HTTP_PROXY"
      value: "http://USER:PASSWORD@:10.0.1.1:8080"

Команда среды OC может использоваться для обновления существующего окружения.

OpenShift Storage с NFS

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

apiVersion: v1
kind: PersistentVolume
metadata:
   name: storage-unit1
spec:
   capacity:
      storage: 10Gi
   accessModes:
   - ReadWriteOnce
   nfs:
      path: /opt
      server: 10.12.2.2
   persistentVolumeReclaimPolicy: Recycle

Далее с помощью команды OC create создайте постоянный том.

$ oc create -f storage-unit1.yaml

persistentvolume " storage-unit1 " created

Утверждение созданного объема.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
   name: Storage-clame1
spec:
   accessModes:
      - ReadWriteOnce
   resources:
      requests:
         storage: 5Gi

Создайте заявку.

$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created

Управление пользователями и ролями

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

Создание пользователя

Предопределенные шаблоны могут использоваться для создания новых пользователей в OpenShift.

kind: "Template"
apiVersion: "v1"
parameters:
   - name: vipin
   required: true
objects:
   - kind: "User"
   apiVersion: "v1"
   metadata:
   name: "${email}"
   
- kind: "Identity"
   apiVersion: "v1"
   metadata:
      name: "vipin:${email}"
   providerName: "SAML"
   providerUserName: "${email}"
- kind: "UserIdentityMapping"
apiVersion: "v1"
identity:
   name: "vipin:${email}"
user:
   name: "${email}"

Используйте oc create –f <имя файла> для создания пользователей.

$ oc create –f vipin.yaml

Используйте следующую команду, чтобы удалить пользователя в OpenShift.

$ oc delete user <user name>

Ограничение доступа пользователя

ResourceQuotas и LimitRanges используются для ограничения уровней доступа пользователей. Они используются для ограничения стручков и контейнеров в кластере.

apiVersion: v1
kind: ResourceQuota
metadata:
   name: resources-utilization
spec:
   hard:
      pods: "10"

Создание цитаты с использованием вышеуказанной конфигурации

$ oc create -f resource-quota.yaml –n –Openshift-sample

Описание ресурса цитата

$ oc describe quota resource-quota  -n  Openshift-sample
Name:              resource-quota
Namespace:                              Openshift-sample
Resource           Used                  Hard
--------           ----                  ----
pods                3                    10

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

Пользовательские ограничения проекта

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

Сначала нам нужно определить объект, который содержит значение того, сколько проектов может иметь бронзовая, серебряная и золотая категории. Это нужно сделать в файле master-confif.yaml.

admissionConfig:
   pluginConfig:
      ProjectRequestLimit:
         configuration:
            apiVersion: v1
            kind: ProjectRequestLimitConfig
            limits:
            - selector:
               level: platinum
            - selector:
               level: gold
            maxProjects: 15
            - selector:
               level: silver
            maxProjects: 10
            - selector:
               level: bronze
            maxProjects: 5

Перезагрузите главный сервер.

Назначение пользователя определенному уровню.

$ oc label user vipin level = gold

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

$ oc label user <user_name> level-

Добавление ролей пользователю.

$ oadm policy add-role-to-user  <user_name>

Удаление роли от пользователя.

$ oadm policy remove-role-from-user  <user_name>

Добавление роли кластера для пользователя.

$ oadm policy add-cluster-role-to-user  <user_name>

Удаление роли кластера от пользователя.

$ oadm policy remove-cluster-role-from-user  <user_name>

Добавление роли в группу.

$ oadm policy add-role-to-user  <user_name>

Удаление роли из группы.

$ oadm policy remove-cluster-role-from-user  <user_name>

Добавление роли кластера в группу.

$ oadm policy add-cluster-role-to-group  <groupname>

Удаление роли кластера из группы.

$ oadm policy remove-cluster-role-from-group <role> <groupname>

Пользователь для администрирования кластера

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

$ oadm policy add-role-to-user admin <user_name> -n <project_name>

Пользователь с максимальной силой

$ oadm policy add-cluster-role-to-user cluster-admin <user_name>

OpenShift — Докер и Кубернетес

OpenShift построен поверх Docker и Kubernetes. Все контейнеры построены поверх кластера Docker, который в основном представляет собой сервис Kubernetes поверх машин Linux, с использованием функции оркестровок Kubernetes.

В этом процессе мы создаем мастер Kubernetes, который контролирует все узлы и развертывает контейнеры на всех узлах. Основной функцией Kubernetes является управление кластером OpenShift и потоком развертывания с использованием файла конфигурации другого типа. Как и в Kubernetes, мы используем kubctl так же, как мы используем утилиту командной строки OC для создания и развертывания контейнеров на узлах кластера.

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

Изображений
POD
обслуживание
Контроллер репликации
Набор реплик
развертывание

Изображений

Изображения Kubernetes (Docker) являются ключевыми строительными блоками контейнерной инфраструктуры. На данный момент Kubernetes поддерживает только образы Docker . Внутри каждого контейнера в модуле находится изображение Docker.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
   containers:
- name: neo4j-server ------------------------> 2
image: <Name of the Docker image>----------> 3
imagePullPolicy: Always ------------->4
command: [“echo”, “SUCCESS”] -------------------> 5

POD

Модуль — это набор контейнеров и его хранилище внутри узла кластера Kubernetes. Можно создать контейнер с несколькими контейнерами внутри. Ниже приведен пример хранения контейнера базы данных и контейнера веб-интерфейса в одном модуле.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
      image: tomcat: 8.0
      ports:
- containerPort: 7500
imagePullPolicy: Always

обслуживание

Служба может быть определена как логический набор модулей. Его можно определить как абстракцию над модулем, которая предоставляет один IP-адрес и имя DNS, по которым можно получить доступ к модулям. С Service очень легко управлять конфигурацией балансировки нагрузки. Это помогает очень легко масштабировать POD.

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
      targetPort: 31999

Контроллер репликации

Контроллер репликации является одной из ключевых функций Kubernetes, которая отвечает за управление жизненным циклом модуля. Он отвечает за то, чтобы убедиться, что указанное количество реплик pod работает в любой момент времени.

apiVersion: v1
kind: ReplicationController
metadata:
   name: Tomcat-ReplicationController
spec:
   replicas: 3
   template:
   metadata:
      name: Tomcat-ReplicationController
   labels:
      app: App
      component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

Набор реплик

Набор реплик гарантирует, сколько реплик модуля pod должно быть запущено. Это можно рассматривать как замену контроллера репликации.

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
      tier: Backend
   matchExpression:
      - { key: tier, operation: In, values: [Backend]}
   
   app: App
   component: neo4j
spec:
   containers:
   - name: Tomcat-
image: tomcat: 8.0
   ports:
containerPort: 7474

развертывание

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

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
lables:
   app: Tomcat-ReplicaSet
   tier: Backend
spec:
   containers:
name: Tomcat-
   image: tomcat: 8.0
   ports:
   - containerPort: 7474

Все файлы конфигурации могут быть использованы для создания соответствующих им объектов Kubernetes.

$ Kubectl create –f <file name>.yaml

Следующие команды могут быть использованы, чтобы узнать подробности и описание объектов Kubernetes.

Для POD

$ Kubectl get pod <pod name>
$ kubectl delete pod <pod name>
$ kubectl describe pod <pod name>

Для контроллера репликации

$ Kubectl get rc <rc name>
$ kubectl delete rc <rc name>
$ kubectl describe rc <rc name>

Для обслуживания

$ Kubectl get svc <svc name>
$ kubectl delete svc <svc name>
$ kubectl describe svc <svc name>

Для получения более подробной информации о том, как работать с Docker и Kubernetes, пожалуйста, посетите наш учебник Kubernetes, используя следующую ссылку kubernetes .

OpenShift — Безопасность

Безопасность OpenShift — это в основном комбинация двух компонентов, которая в основном обрабатывает ограничения безопасности.

Ограничения контекста безопасности (SCC)
Сервисный аккаунт

Ограничения контекста безопасности (SCC)

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

OpenShift предоставляет набор предопределенных SCC, которые могут быть использованы, изменены и расширены администратором.

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

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

$ oadm policy add-user-to-scc <scc_name> <user_name>
$ oadm policy add-group-to-scc <scc_name> <group_name>

Сервисный аккаунт

Сервисные учетные записи в основном используются для управления доступом к главному API OpenShift, который вызывается при запуске команды или запроса с любого из главного или узлового компьютера.

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

$ oc create serviceaccount Cadmin
$ oc adm policy add-scc-to-user vipin -z Cadmin

Контейнерная безопасность

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

Image Provenance — внедрена защищенная система маркировки, которая точно и неопровержимо определяет, откуда пришли контейнеры, работающие в производственной среде.

Сканирование безопасности — сканер изображений автоматически проверяет все изображения на наличие известных уязвимостей.

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

Изоляция и минимальные привилегии. Контейнеры работают с минимальными ресурсами и привилегиями, необходимыми для эффективного функционирования. Они не могут чрезмерно мешать хосту или другим контейнерам.

Обнаружение угроз во время выполнения — возможность обнаруживать активные угрозы для контейнерного приложения во время выполнения и автоматически реагировать на него.

Контроль доступа — модули безопасности Linux, такие как AppArmor или SELinux, используются для обеспечения контроля доступа.

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

Управление доступом через oAuth
Через веб-консоль самообслуживания
По сертификатам платформы

Управление доступом через OAuth

В этом методе аутентификация для доступа к управлению API архивируется с получением защищенного токена для аутентификации через серверы OAuth, который встроен в главный компьютер OpenShift. Как администратор, вы можете изменять конфигурацию конфигурации сервера OAuth.

Подробнее о настройке сервера OAuth см. В главе 5 этого руководства.

Через веб-консоль самообслуживания

Эта функция безопасности веб-консоли встроена в веб-консоль OpenShift. Эта консоль гарантирует, что все команды, работающие вместе, не имеют доступа к другим средам без аутентификации. Мастер multi-telnet в OpenShift имеет следующие функции безопасности:

Уровень TCL включен
Использует сертификат x.509 для аутентификации
Защищает конфигурацию etcd на главном компьютере

По сертификатам платформы

В этом методе сертификаты для каждого хоста настраиваются во время установки через Ansible. Поскольку он использует протокол связи HTTPS через Rest API, нам необходимо защищенное соединение TCL с различными компонентами и объектами. Это предопределенные сертификаты, однако для доступа можно даже установить собственный сертификат в кластере мастера. Во время первоначальной настройки мастера пользовательские сертификаты могут быть настроены путем переопределения существующих сертификатов с помощью параметра openshift_master_overwrite_named_certificates .

пример

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

Для получения более подробной информации о том, как создавать пользовательские сертификаты, перейдите по следующей ссылке —

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

Сетевая безопасность

В OpenShift для связи используется программно-определяемая сеть (SDN). Сетевое пространство имен используется для каждого модуля в кластере, причем каждый модуль получает свой собственный IP и диапазон портов для получения сетевого трафика на нем. С помощью этого метода можно изолировать модули, из-за которых они не могут взаимодействовать с модулями в другом проекте.

Изоляция проекта

Это может сделать администратор кластера с помощью следующей команды oadm из CLI.

$ oadm pod-network isolate-projects <project name 1> <project name 2>

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

Объем безопасности

Под защитой томов подразумевается защита PV и PVC проектов в кластере OpenShift. В основном в OpenShift есть четыре раздела для управления доступом к томам.

Дополнительные группы
fsGroup
RunAsUser
seLinuxOptions

Дополнительные группы — Дополнительные группы — это обычные группы Linux. Когда процесс выполняется в системе, он запускается с идентификатором пользователя и идентификатором группы. Эти группы используются для управления доступом к общему хранилищу.

Проверьте монтирование NFS с помощью следующей команды.

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

Проверьте сведения о NFS на сервере монтирования, используя следующую команду.

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

/ Opt / nfs / export доступен по UID 454265 и группе 2325 .

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup обозначает группу файловой системы, которая используется для добавления дополнительных групп контейнера. Идентификатор группы дополнений используется для общего хранилища, а fsGroup — для блочного хранилища.

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

RunAsUser

runAsUser использует идентификатор пользователя для связи. Это используется при определении изображения контейнера в определении модуля. Один идентификатор пользователя может быть использован во всех контейнерах, если требуется.

При запуске контейнера указанный идентификатор сопоставляется с идентификатором владельца при экспорте. Если указанный идентификатор определен снаружи, он становится глобальным для всех контейнеров в модуле. Если это определено с определенным модулем, то это становится определенным для единственного контейнера.

OpenShift — Краткое руководство

OpenShift — Обзор

Виртуализация

Как это устроено

Физическая и виртуальная архитектура

Типы виртуализации

OpenShift

Инфраструктура как услуга (IaaS)

Программное обеспечение как услуга (SaaS)

Платформа как услуга (PaaS)

Зачем использовать OpenShift?

Характеристики

OpenShift — Типы

OpenShift Online

Настройка учетной записи в Red Hat OpenShift Online

Контейнерная платформа OpenShift

OpenShift, посвященный

Особенности OpenShift Dedicated

Конкуренты OpenShift

OpenShift — Архитектура

Компоненты OpenShift

Kubernetes Master Machine Компоненты

Узлы Kubernetes

Интегрированный Реестр Контейнеров OpenShift

Часто используемые термины

OpenShift — настройка среды

Системные требования

Конфигурация главной машины

Конфигурация узла машины

Пошаговое руководство по настройке OpenShift

OpenShift — базовая концепция

Контейнеры и изображения

Изображений

Контейнер

Стручки и Услуги

Бобы

Строит и Потоки

Строит

Стратегии сборки

Источники сборки

Маршруты и шаблоны

Маршруты

Шаблоны

Аутентификация и Авторизация

Аутентификация

Позволять все

Запретить все

Htpasswd

авторизация

OpenShift — Начало работы

Создание нового приложения

Из исходного кода

Из изображения

Из шаблона

Разработка и развертывание веб-приложения

Разработка нового приложения в OpenShift

шаблон

Определения объектов

OpenShift — автоматизация сборки

Файл BuildConfig

Стратегия исходного изображения

Докерская стратегия

Индивидуальная стратегия

Трубопроводная стратегия

OpenShift — CLI

Настройка OpenShift CLI

OC Client для Windows

Клиент OC для Mac OS X

OC Client для Linux

Конфигурационные файлы CLI

Настройка клиента CLI

Для настройки учетных данных пользователя

Для настройки кластера

пример

Для настройки контекста

Профили CLI

OpenShift — Операции CLI

Основные команды

Авторизоваться

Команды сборки и развертывания