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 adminStep 6- Поскольку OpenShift использует реестр Docker для настройки образов, нам необходимо настроить реестр Docker. Это используется для создания и хранения образов Docker после сборки.
Создайте каталог на компьютере узла OpenShift, используя следующую команду.
# mkdir /imagesЗатем войдите на главный компьютер, используя учетные данные администратора по умолчанию, которые создаются при настройке реестра.
# oc login
Username: system:adminПереключитесь на созданный по умолчанию проект.
# oc project defaultStep 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 = /imagesStep 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 namedvi /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.ymlMulti-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: DenyAllPasswordIdentityProviderHTPasswd
Чтобы использовать 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-AuthOC Client для Mac OS X
Мы можем загрузить двоичные файлы установки Mac OS в то же место, что и для Windows, а затем разархивировать его в определенном месте и установить путь к исполняемому файлу в переменной среды PATH.
Alternatively
Мы можем использовать Home brew и настроить его с помощью следующей команды.
$ brew install openshift-cliOC 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 unexcludeStep 2 - Обновить etcd на всех мастерах.
$ yum update etcdStep 3 - Перезапустите службу etcd и проверьте, успешно ли она запустилась.
$ systemctl restart etcd
$ journalctl -r -u etcdStep 4 - Обновите пакет Docker.
$ yum update dockerStep 5 - Перезапустите службу Docker и проверьте, правильно ли она работает.
$ systemctl restart docker $ journalctl -r -u dockerStep 6 - После этого перезагрузите систему с помощью следующих команд.
$ systemctl reboot $ journalctl -r -u dockerStep 7 - Наконец, запустите atomic-executer, чтобы вернуть пакеты в список исключений yum.
$ atomic-openshift-excluder excludeНет такого принуждения к обновлению политики, ее нужно обновлять только в случае рекомендации, что можно проверить с помощью следующей команды.
$ oadm policy reconcile-cluster-rolesВ большинстве случаев нам не нужно обновлять определение политики.
Обновление компонентов узла
После завершения основного обновления мы можем приступить к обновлению узлов. Следует иметь в виду, что период обновления должен быть коротким, чтобы избежать каких-либо проблем в кластере.
Step 1 - Удалите все атомарные пакеты OpenShift со всех узлов, на которых вы хотите выполнить обновление.
$ atomic-openshift-excluder unexcludeStep 2 - Затем отключите планирование узлов перед обновлением.
$ oadm manage-node <node name> --schedulable = falseStep 3 - Реплицируйте весь узел с текущего хоста на другой хост.
$ oadm drain <node name> --force --delete-local-data --ignore-daemonsetsStep 4 - Обновите установку Docker на хосте.
$ yum update dockerStep 5 - Перезапустите службу Docker, а затем запустите узел службы Docker.
$systemctl restart docker $ systemctl restart atomic-openshift-nodeStep 6 - Проверьте, правильно ли они оба запустились.
$ journalctl -r -u atomic-openshift-nodeStep 7 - После завершения обновления перезагрузите узел.
$ systemctl reboot
$ journalctl -r -u dockerStep 8 - Повторно включите планирование на узлах.
$ oadm manage-node <node> --schedulable.Step 9 - Запустите программу-исполнитель atomic-openshift, чтобы вернуть пакет OpenShift на узел.
$ atomic-openshift-excluder excludeStep 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: DenyAllPasswordIdentityProviderHTPasswd
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”] -------------------> 5POD
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/nfsfsGroup
fsGroup обозначает группу файловой системы, которая используется для добавления дополнительных групп контейнера. Идентификатор группы дополнений используется для общего хранилища, а fsGroup - для блочного хранилища.
kind: Pod
spec:
containers:
- name: ...
securityContext:
fsGroup: 2325runAsUser
runAsUser использует идентификатор пользователя для связи. Это используется при определении образа контейнера в определении модуля. При необходимости можно использовать один идентификатор пользователя во всех контейнерах.
При запуске контейнера определенный идентификатор сопоставляется с идентификатором владельца при экспорте. Если указанный идентификатор определен снаружи, он становится глобальным для всех контейнеров в модуле. Если он определен с конкретным модулем, то он становится специфичным для одного контейнера.
spec:
containers:
- name: ...
securityContext:
runAsUser: 454265