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

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

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

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

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

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

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

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

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

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

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

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

  • Data Virtualization - Это метод абстрагирования и ухода от традиционного метода управления данными.

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

  • Storage Virtualization - Это процесс объединения нескольких запоминающих устройств в одно запоминающее устройство, которым управляют с единой центральной консоли.

  • Network Virtualization - Это метод, при котором все доступные сетевые ресурсы объединяются путем разделения доступной полосы пропускания и каналов, каждый из которых не зависит друг от друга.

OpenShift

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

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

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

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

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

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

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

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

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

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

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

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

Free - Этот план ограничен тремя годами с 1 ГБ места на каждый.

Bronze - Этот план включает 3 года и расширяется до 16 лет с 1 ГБ пространства в год.

Sliver - Это бронзовый план на 16 лет, однако он имеет емкость 6 ГБ без дополнительных затрат.

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

Особенности

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

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

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

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

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

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

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

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

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

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

OpenShift Online

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

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

Step 1 - Зайдите в браузер и посетите сайт https://manage.openshift.com/

Step 2 - Если у вас есть учетная запись Red Hat, войдите в учетную запись OpenShift, используя идентификатор входа и пароль Red Hat, используя следующий URL-адрес. https://developers.redhat.com

Step 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 доступна в two package levels.

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

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

Выделенный OpenShift

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

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

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

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

  • Extensible and Open - Он построен на открытой концепции Docker и развернут в облаке, поэтому он может расходовать себя по мере необходимости.

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

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

  • Automation - Эта версия 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 - CloudStack от Apache - это проект, разработанный Citrix и призванный стать прямым конкурентом OpenShift и OpenStack.

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

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

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

Компоненты OpenShift

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

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

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

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

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

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

Компоненты узла Kubernetes

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

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

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

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

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

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

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

Image- Образы Kubernetes (Docker) являются ключевыми строительными блоками контейнерной инфраструктуры. На данный момент Kubernetes поддерживает только образы Docker. У каждого контейнера в модуле есть свой образ Docker, работающий внутри него. При настройке модуля свойство image в файле конфигурации имеет тот же синтаксис, что и команда Docker.

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

Container - Это те, которые создаются после развертывания образа на узле кластера Kubernetes.

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

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

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

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

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

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

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

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

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

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

  • Не менее 8 ГБ оперативной памяти.

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

Конфигурация узлового компьютера

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

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

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

Step 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 на соответствующих машинах.

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

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

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

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

# ssh-keygen

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

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

Step 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 и другие вещи.

Step 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

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

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

# mkdir /images

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

# oc login
Username: system:admin

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

# oc project default

Step 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

Step 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}'

Step 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; };
};

Step 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 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 внутри него.

Модули и службы

Стручки

Под можно определить как набор контейнеров и их хранилище внутри узла кластера 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

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

Service- Поскольку у нас есть набор контейнеров, работающих внутри модуля, точно так же у нас есть служба, которую можно определить как логический набор модулей. Это абстрактный уровень над модулем, который предоставляет единый 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 run.

  • Docker Build - Это процесс, в котором образы создаются с использованием файла 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"

Image Streams- Потоки изображений создаются после извлечения изображений. Преимущество потока изображений заключается в том, что он ищет обновления для новой версии изображения. Это используется для сравнения любого количества образов контейнеров в формате 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 как стандартный объект, который можно использовать несколько раз. Он параметризован списком заполнителей, которые используются для создания нескольких объектов. Это может быть использовано для создания чего угодно, от модуля до сети, для чего пользователи имеют право создавать. Список объектов может быть создан, если шаблон из интерфейса командной строки или графического интерфейса пользователя в изображении загружен в каталог проекта.

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 является настройкой по умолчанию для мастера, по умолчанию используется поставщик удостоверений 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, которая используется для проверки подлинности пользователя. Это означает, что он проверяет пользователя, который пытается выполнить действие, чтобы узнать, авторизован ли пользователь для выполнения этого действия в данном проекте. Это помогает администратору контролировать доступ к проектам.

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

  • Rules
  • Roles
  • Bindings

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

  • Identity
  • Action
  • Bindings

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

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

OpenShift состоит из двух типов медианов для создания и развертывания приложений с помощью графического интерфейса или интерфейса командной строки. В этой главе мы будем использовать интерфейс командной строки для создания нового приложения. Мы будем использовать клиент 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 и развернуть приложение в этом пространстве имен.

Create a new namespace

$ 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"
      }
   }
},

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

Secret definition in a template

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

Service definition in a template

{
   "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": {}
   }
},

Route definition in a template

{
   "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": ""
   }
},

Build config definition in a template

{
   "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
      }
   }
},

Deployment config in a template

"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": {}
},

Service definition in a template

{
   "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": {}
   }
},

Deployment config definition in a template

{
   "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 у нас есть несколько методов автоматизации конвейера сборки. Для этого нам нужно создать ресурс BuildConfig для описания процесса сборки. Поток в BuildConfig можно сравнить с определением задания в определении задания Jenkins. При создании потока сборки мы должны выбрать стратегию сборки.

Файл 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 можно использовать в нескольких местах, начиная с пути к файлу, без кеша и принудительного извлечения.

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

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

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

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

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

  • Открыть сокет Docker
  • Secrets
  • Сила тяги

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

Стратегия конвейера используется для создания настраиваемых конвейеров сборки. Это в основном используется для реализации рабочего процесса в конвейере. Этот поток сборки использует настраиваемый поток конвейера сборки с использованием языка 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}"

Using build pipeline

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 из командной строки. OpenShift CLI имеет возможность управлять непрерывным жизненным циклом приложения. В общем, мы будем использовать OC, который является клиентом OpenShift для связи с OpenShift.

Настройка OpenShift CLI

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

OC Client для Windows

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

Step 2 - Разархивируйте пакет по целевому пути на машине.

Step 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;

Step 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 Client для Mac OS X

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

Alternatively

Мы можем использовать 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 может выполнять все основные и дополнительные функции настройки, управления, добавления и развертывания приложений.

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

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

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

Sr.No. Команды и описание
1

Types

Введение в концепции и тип

2

Login

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

3

new-project

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

4

new-app

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

5

Status

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

6

Project

Перейти к другому проекту

7

Projects

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

8

Explain

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

9

Cluster

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

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

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

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

Usage

oc login [URL] [options]

Example

# 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 <Command Name> --help команда.

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

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

Sr.No. Команды и описание
1

Rollout

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

2

Deploy

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

3

Rollback

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

4

new-build

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

5

start-build

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

6

cancel-build

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

7

import-image

Импортирует образы из реестра Docker

8

Tag

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

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

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

Sr.No. Команды и описание
1

Get

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

2

Describe

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

3

Edit

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

4

Set

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

5

Label

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

6

Annotate

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

7

Expose

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

8

Delete

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

9

Scale

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

10

Autoscale

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

11

Secrets

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

12

Serviceaccounts

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

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

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

Sr.No. Команды и описание
1

logs

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

2

Rsh

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

3

Rsync

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

4

port-forward

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

5

Debug

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

6

Exec

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

7

Procy

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

9

Attach

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

10

Run

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

11

Cp

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

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

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

Sr.No. Команды и описание
1

adm

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

2

create

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

3

replace

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

4

apply

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

5

patch

Обновить поля ресурса с помощью стратегического патча слияния

6

process

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

7

export

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

8

extract

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

9

idle

Простаивающие масштабируемые ресурсы

10

observe

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

11

policy

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

12

auth

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

13

convert

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

14

import

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

Установка команд

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

Sr.No. Команды и описание
1

Logout

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

2

Config

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

3

Whoami

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

4

Completion

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

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

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

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

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

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

Interactive method

$ atomic-openshift-installer install

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

Unattended installation method

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

$ 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, в которой присутствует полная конфигурация хоста и определение переменных, касающихся конфигурации мастера и узла. Он содержит все подробности, касающиеся конфигурации.

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

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

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

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

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

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

$ 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 stack- Этот стек полезен при попытке собрать журналы со всех узлов и представить их в систематизированном формате. Стек ELK в основном делится на три основные категории.

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

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

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>

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

Обновление кластера включает обновление нескольких вещей в кластере и обновление кластера новыми компонентами и обновлениями. Это включает в себя -

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

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

  • atomic-openshift-utils
  • atomic-openshift-excluder
  • atomic-openshift-docker-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 мы начинаем обновление с обновления файла etcd, а затем переходим к Docker. Наконец, мы запускаем автоматизированный исполнитель, чтобы установить кластер в нужное положение. Однако перед началом обновления нам нужно сначала активировать атомарные пакеты openshift на каждом из мастеров. Это можно сделать с помощью следующих команд.

Step 1 - Удалить пакеты atomic-openshift

$ atomic-openshift-excluder unexclude

Step 2 - Обновить etcd на всех мастерах.

$ yum update etcd

Step 3 - Перезапустите службу etcd и проверьте, успешно ли она запустилась.

$ systemctl restart etcd
$ journalctl -r -u etcd

Step 4 - Обновите пакет Docker.

$ yum update docker

Step 5 - Перезапустите службу Docker и проверьте, правильно ли она работает.

$ systemctl restart docker $ journalctl -r -u docker

Step 6 - После этого перезагрузите систему с помощью следующих команд.

$ systemctl reboot $ journalctl -r -u docker

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

$ atomic-openshift-excluder exclude

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

$ oadm policy reconcile-cluster-roles

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

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

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

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

$ atomic-openshift-excluder unexclude

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

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

Step 3 - Реплицируйте весь узел с текущего хоста на другой хост.

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

Step 4 - Обновите установку Docker на хосте.

$ yum update docker

Step 5 - Перезапустите службу Docker, а затем запустите узел службы Docker.

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

Step 6 - Проверьте, правильно ли они оба запустились.

$ journalctl -r -u atomic-openshift-node

Step 7 - После завершения обновления перезагрузите узел.

$ systemctl reboot
$ journalctl -r -u docker

Step 8 - Повторно включите планирование на узлах.

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

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

$ atomic-openshift-excluder exclude

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

$ oc get nodes

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

Автомасштабирование - это функция OpenShift, в которой развернутые приложения могут масштабироваться и уменьшаться по мере необходимости в соответствии с определенными спецификациями. В приложении OpenShift автомасштабирование также известно как автомасштабирование пода. Есть дваtypes of application scaling следующим образом.

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

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

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

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

В OpenShift есть two methods to enable the scaling feature.

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

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

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

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 следующиеimportant types of deployment strategies.

  • Скользящая стратегия
  • Воссоздать стратегию
  • Индивидуальная стратегия

Ниже приведен пример файла конфигурации развертывания, который используется в основном для развертывания на узлах 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 нам нужно использовать команду 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

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

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

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

Учетная запись службы использует пару ключей из открытого и закрытого ключей для аутентификации. Аутентификация в 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-master

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

Узловая машина

/ и т.д. / sysconfig / openshift-node

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 можно использовать для обновления существующей среды env.

Хранилище OpenShift с 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 построен на основе Docker и Kubernetes. Все контейнеры построены на основе кластера Docker, который, по сути, представляет собой службу Kubernetes поверх компьютеров Linux, с использованием функции оркестровки Kubernetes.

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

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

  • Images
  • POD
  • Service
  • Контроллер репликации
  • Набор реплик
  • Deployment

Картинки

Образы 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

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

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

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

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

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

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

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

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

Набор реплик

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

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.

For POD

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

For Replication Controller

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

For Service

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

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

Безопасность 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 - Имеется безопасная система маркировки, которая точно и неопровержимо определяет, откуда взялись контейнеры, работающие в производственной среде.

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

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

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

Runtime Threat Detection - Возможность обнаружения активных угроз для контейнерных приложений во время выполнения и автоматического реагирования на них.

Access Controls - Модули безопасности 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 параметр.

Example

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 command из 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 / экспорт доступен UID454265 и группа 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 использует идентификатор пользователя для связи. Это используется при определении образа контейнера в определении модуля. При необходимости можно использовать один идентификатор пользователя во всех контейнерах.

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

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265