Thank you for reading this post, don't forget to subscribe!
1.обзор
2.типы
3.архитектура
4.настройка среды
5.основная концепция
6.начало работы
7.автоматизация сборки
8.интерфейс командной строки
9.операции через интерфейс командной строки
10.Кластеры
11.масштабирование приложений
12.администрирование
13.безопасность
OpenShift - это платформа облачной разработки как услуга (PaaS), разработанная Red Hat. Это платформа разработки с открытым исходным кодом, которая позволяет разработчикам разрабатывать и развертывать свои приложения в облачной инфраструктуре. Это очень полезно при разработке облачных сервисов. Это руководство поможет вам понять 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 возник из своей базы под названием OpenShift V2, которая в основном была основана на концепции механизма и картриджей, где каждый компонент имеет свои спецификации, начиная от создания машины до развертывания приложения, прямо от сборки до развертывания приложения.
Cartridges - Они были центром создания нового приложения, начиная с того типа приложения, которое требуется среде для их запуска, и всех зависимостей, удовлетворяемых в этом разделе.
Gear- Его можно определить как металлическую машину или сервер с определенными характеристиками в отношении ресурсов, памяти и процессора. Они считались фундаментальной единицей для запуска приложения.
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, используя следующую ссылку.
После входа вы увидите следующую страницу.
Когда все будет готово, 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 - Архитектура
OpenShift - это многоуровневая система, в которой каждый уровень тесно связан с другим уровнем с помощью Kubernetes и кластера Docker. Архитектура OpenShift спроектирована таким образом, что она может поддерживать и управлять контейнерами Docker, которые размещаются поверх всех слоев с использованием Kubernetes. В отличие от более ранней версии OpenShift V2, новая версия OpenShift V3 поддерживает контейнерную инфраструктуру. В этой модели Docker помогает в создании легких контейнеров на базе Linux, а Kubernetes поддерживает задачу оркестровки и управления контейнерами на нескольких хостах.
Компоненты OpenShift
Одним из ключевых компонентов архитектуры OpenShift является управление контейнерной инфраструктурой в Kubernetes. Kubernetes отвечает за развертывание инфраструктуры и управление ею. В любом кластере Kubernetes у нас может быть более одного главного и нескольких узлов, что гарантирует отсутствие точки отказа в настройке.
Компоненты Kubernetes Master Machine
Etcd- В нем хранится информация о конфигурации, которая может использоваться каждым из узлов кластера. Это хранилище значений ключа высокой доступности, которое можно распределить между несколькими узлами. Он должен быть доступен только серверу API Kubernetes, так как он может содержать конфиденциальную информацию. Это распределенное хранилище значений ключей, доступное всем.
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.
Системные требования
Чтобы настроить корпоративный 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 root@ose3-node.test.com
После того, как вы выполнили все вышеперечисленные настройки, следует установить OpenShift версии 3 на главном компьютере.
Step 4 - На главном компьютере выполните следующую команду curl.
Приведенная выше команда установит установку для OSV3. Следующим шагом будет настройка OpenShift V3 на машине.
Если вы не можете загрузить напрямую из Интернета, его можно загрузить с https://install.openshift.com/portable/oo-install-ose.tgz как tar-пакет, из которого установщик может запускаться на локальном главном компьютере.
После того, как мы подготовили установку, нам нужно начать с фактической настройки OSV3 на машинах. Эта настройка очень специфична для тестирования среды для реального производства, у нас есть LDAP и другие вещи.
Step 5 - На главном компьютере настройте следующий код, расположенный в /etc/openshift/master/master-config.yaml
1 2 3 4 5 6 7 8 9 10 11 |
# vi /etc/openshift/master/master-config.yaml identityProviders: - name: my_htpasswd_provider challenge: true login: true provider: apiVersion: v1 kind: HTPasswdPasswordIdentityProvider file: /root/users.htpasswd routingConfig: subdomain: testing.com |
Затем создайте стандартного пользователя для администрирования по умолчанию.
# htpasswd -c /root/users.htpasswd admin
Step 6- Поскольку OpenShift использует реестр Docker для настройки образов, нам необходимо настроить реестр Docker. Это используется для создания и хранения образов Docker после сборки.
Создайте каталог на компьютере узла OpenShift, используя следующую команду.
# mkdir /images
Затем войдите на главный компьютер, используя учетные данные администратора по умолчанию, которые создаются при настройке реестра.
# oc login
Username: system:admin
Переключитесь на созданный по умолчанию проект.
# oc project default
Step 7 - Создайте реестр Docker.
Отредактируйте права пользователя.
1 2 3 4 |
#oc edit scc privileged users: - system:serviceaccount:openshift-infra:build-controller - system:serviceaccount:default:registry |
Создайте и отредактируйте реестр образов.
1 2 3 4 5 |
#oadm registry --service-account = registry -- config = /etc/openshift/master/admin.kubeconfig -- credentials = /etc/openshift/master/openshift-registry.kubeconfig -- images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' -- mount-host = /images |
Step 8 - Создайте маршрутизацию по умолчанию.
По умолчанию OpenShift использует OpenVswitch как программную сеть. Используйте следующую команду для создания маршрутизации по умолчанию. Это используется для балансировки нагрузки и маршрутизации прокси. Маршрутизатор похож на реестр Docker, а также работает в реестре.
Затем отредактируйте привилегии пользователя.
1 2 3 4 5 6 7 8 9 |
#oc edit scc privileged users: - system:serviceaccount:openshift-infra:build-controller - system:serviceaccount:default:registry - system:serviceaccount:default:router #oadm router router-1 --replicas = 1 -- credentials = '/etc/openshift/master/openshift-router.kubeconfig' -- images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' |
Step 9 - Настроить DNS.
Для обработки запроса URL OpenShift требуется рабочая среда DNS. Эта конфигурация DNS требуется для создания подстановочного знака, который требуется для создания подстановочного знака DNS, указывающего на маршрутизатор.
yum install bind-utils bind
# systemctl start named
systemctl enable named
1 2 3 4 5 6 7 8 9 10 11 12 |
vi /etc/named.conf options {listen-on port 53 { 10.123.55.111; }; forwarders { 10.38.55.13; ; }; zone "lab.com" IN { type master; file "/var/named/dynamic/test.com.zone"; allow-update { none; }; }; |
Step 10- Последним шагом будет установка сервера github на главной машине OpenShift V3, что не является обязательным. Это легко сделать с помощью следующей последовательности команд.
#yum install curl openssh-server
systemctl enable sshd
# systemctl start sshd
# firewall-cmd --permanent --add-service = http
# systemctl reload firewalld
#curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-
#yum install gitlab-ce
# gitlab-ctl reconfigure
Как только описанная выше настройка будет завершена, вы можете проверить это с помощью тестирования и развертывания приложений, о которых мы узнаем больше в следующих главах.
OpenShift - основная концепция
Прежде чем начать фактическую настройку и развертывание приложений, нам нужно понять некоторые основные термины и концепции, используемые в OpenShift V3.
Контейнеры и изображения
Картинки
Это основные строительные блоки OpenShift, которые формируются из образов Docker. В каждом модуле OpenShift кластер имеет свои собственные изображения, работающие внутри него. Когда мы настраиваем модуль, у нас есть поле, которое будет объединено из реестра. Этот файл конфигурации извлечет образ и развернет его на узле кластера.
1 2 3 4 5 6 7 8 9 10 |
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.
1 2 3 4 5 6 |
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 |
Ниже приведены спецификации для определения контейнера, в котором запущено несколько изображений.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
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 следующим образом.
1 2 3 4 5 6 7 8 9 10 11 |
apiVersion: v1 kind: Pod metadata: name: apache spec: containers: - name: apache image: apache: 8.0 ports: - containerPort: 7500 imagePullPolicy: Always |
После создания указанного выше файла он сгенерирует модуль с помощью следующей команды.
$ oc create –f apache.yml
Multi-Container Pod- Многоконтейнерные поды - это те контейнеры, в которых у нас работает более одного контейнера. Они создаются с использованием файлов yaml следующим образом.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
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 для создания нового экземпляра.
1 2 3 4 5 6 7 8 |
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 не является обязательным. Конфигурации из исходного кода выглядят следующим образом.
1 2 3 4 5 6 7 |
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 используется в качестве входных данных в файле конфигурации.
1 2 3 4 |
source: type: "Dockerfile" dockerfile: "FROM ubuntu: latest RUN yum install -y httpd" |
Image Streams- Потоки изображений создаются после извлечения изображений. Преимущество потока изображений заключается в том, что он ищет обновления для новой версии изображения. Это используется для сравнения любого количества образов контейнеров в формате Docker, идентифицированных тегами.
Потоки изображений могут автоматически выполнять действие при создании нового изображения. Все сборки и развертывания могут отслеживать действия с изображениями и выполнять соответствующие действия. Ниже показано, как мы определяем сборку потока.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
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 и веб-сокет
При настройке службы селекторы используются для настройки службы и поиска конечной точки, использующей эту службу. Ниже приводится пример того, как мы создаем службу и маршрутизацию для этой службы с использованием соответствующего протокола.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
{ "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
Так выглядит сервис после создания.
1 2 3 4 5 6 7 8 9 10 11 |
$ 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. |
Создайте маршрутизацию для обслуживания, используя следующий код.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "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 как стандартный объект, который можно использовать несколько раз. Он параметризован списком заполнителей, которые используются для создания нескольких объектов. Это может быть использовано для создания чего угодно, от модуля до сети, для чего пользователи имеют право создавать. Список объектов может быть создан, если шаблон из интерфейса командной строки или графического интерфейса пользователя в изображении загружен в каталог проекта.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
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
- Базовая аутентификация
Позволять все
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
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 |
Запретить все
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
apiVersion: v1 kind: Pod metadata: name: redis-master spec: containers: image: dockerfile/redis name: master ports: - containerPort: 6379 protocol: TCP oauthConfig: identityProviders: - name: my_allow_provider challenge: true login: true provider: apiVersion: v1 kind: DenyAllPasswordIdentityProvider |
HTPasswd
Чтобы использовать HTPasswd, нам нужно сначала настроить Httpd-tools на главном компьютере, а затем настроить его так же, как мы делали для других.
1 2 3 4 5 6 7 |
identityProviders: - name: my_htpasswd_provider challenge: true login: true provider: apiVersion: v1 kind: HTPasswdPasswordIdentityProvider |
Авторизация
Авторизация - это функция мастера OpenShift, которая используется для проверки подлинности пользователя. Это означает, что он проверяет пользователя, который пытается выполнить действие, чтобы узнать, авторизован ли пользователь для выполнения этого действия в данном проекте. Это помогает администратору контролировать доступ к проектам.
Политики авторизации контролируются с помощью -
- Rules
- Roles
- Bindings
Оценка авторизации выполняется с использованием -
- Identity
- Action
- Bindings
Использование политик -
- Кластерная политика
- Местная политика
OpenShift - Начало работы
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 - это в основном шаблон, который можно использовать для развертывания.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
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"
Шаблон
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
{ "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
1 2 3 4 5 6 7 8 9 10 |
"objects": [ { "kind": "Secret", "apiVersion": "v1", "metadata": {"name": "dbsecret"}, "stringData" : { "mysql-user" : "${MYSQL_USER}", "mysql-password" : "${MYSQL_PASSWORD}" } }, |
Service definition in a template
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
{ "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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
{ "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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 |
{ "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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 |
"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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
{ "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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 |
{ "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-файл после завершения.
Нам нужно запустить следующую команду, чтобы создать приложение.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
$ 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. |
Если мы хотим отслеживать сборку, это можно сделать с помощью -
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
$ oc get builds NAME TYPE FROM STATUS STARTED DURATION openshift-sample-build-1 Source Git@bd94cbb Running 7 seconds ago 7s Мы можем проверить развернутые приложения на OpenShift, используя - $ oc get pods NAME READY STATUS RESTARTS AGE database-1-le4wx 1/1 Running 0 1m frontend-1-e572n 1/1 Running 0 27s frontend-1-votq4 1/1 Running 0 31s opeshift-sample-build-1-build 0/1 Completed 0 1m Мы можем проверить, созданы ли службы приложения в соответствии с определением службы, используя $ oc get services NAME CLUSTER-IP EXTERNAL-IP PORT(S) SELECTOR AGE database 172.30.80.39 <none> 5434/TCP name=database 1m frontend 172.30.17.4 <none> 5432/TCP name=frontend 1m |
OpenShift - автоматизация сборки
В OpenShift у нас есть несколько методов автоматизации конвейера сборки. Для этого нам нужно создать ресурс BuildConfig для описания процесса сборки. Поток в BuildConfig можно сравнить с определением задания в определении задания Jenkins. При создании процесса сборки мы должны выбрать стратегию сборки.
Файл BuildConfig
В OpenShift BuildConfig - это объект отдыха, используемый для подключения к API и последующего создания нового экземпляра.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
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 существует четыре типа стратегий сборки.
- Стратегия преобразования источника в изображение
- Докерская стратегия
- Индивидуальная стратегия
- Трубопроводная стратегия
Стратегия преобразования источника в изображение
Позволяет создавать образы контейнеров, начиная с исходного кода. В этом потоке фактический код сначала загружается в контейнер, а затем компилируется внутри него. Скомпилированный код развертывается в том же контейнере, и образ создается из этого кода.
1 2 3 4 5 6 7 |
strategy: type: "Source" sourceStrategy: from: kind: "ImageStreamTag" name: "builder-image:latest" forcePull: true |
Есть несколько стратегических политик.
- Forcepull
- Дополнительные сборки
- Внешние сборки
Докер стратегия
В этом потоке OpenShift использует Dockerfile для создания образа, а затем загружает созданные образы в реестр Docker.
1 2 3 4 5 6 |
strategy: type: Docker dockerStrategy: from: kind: "ImageStreamTag" name: "ubuntu:latest" |
Параметр файла Docker можно использовать в нескольких местах, начиная с пути к файлу, без кеша и принудительного извлечения.
- Из изображения
- Путь к Dockerfile
- Нет кеша
- Сила тяги
Индивидуальная стратегия
Это один из различных видов стратегии сборки, в которой нет такого принуждения, что выходом сборки будет изображение. Это можно сравнить с работой Дженкинса в свободном стиле. С его помощью мы можем создавать Jar, rpm и другие пакеты.
1 2 3 4 5 6 |
strategy: type: "Custom" customStrategy: from: kind: "DockerImage" name: "openshift/sti-image-builder" |
Он состоит из нескольких стратегий сборки.
- Открыть сокет Docker
- Secrets
- Сила тяги
Трубопроводная стратегия
Стратегия конвейера используется для создания настраиваемых конвейеров сборки. Это в основном используется для реализации рабочего процесса в конвейере. Этот поток сборки использует настраиваемый поток конвейера сборки с использованием языка Groovy DSL. OpenShift создаст задание конвейера в Jenkins и выполнит его. Этот конвейерный поток также можно использовать в Jenkins. В этой стратегии мы используем Jenkinsfile и добавляем его в определение buildconfig.
1 2 3 4 |
Strategy: type: "JenkinsPipeline" jenkinsPipelineStrategy: jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}" |
Using build pipeline
1 2 3 4 5 6 7 8 9 10 11 12 13 |
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 - интерфейс командной строки
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 - Отредактируйте переменную среды пути в системе.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
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® Management Engine Components\DAL;C:\Program Files\Intel\Intel® Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel® Management Engine Components\DAL; |
Step 4 - Проверьте настройку OC в Windows.
1 2 3 4 |
C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc version oc v3.6.0-alpha.2+3c221d5 kubernetes v1.6.1+5115d708d7 features: Basic-Auth |
OC Client для Mac OS X
Мы можем загрузить двоичные файлы установки Mac OS в то же место, что и для Windows, а затем разархивировать его в определенном месте и установить путь к исполняемому файлу в переменной среды PATH.
Alternatively
Мы можем использовать Home brew и настроить его с помощью следующей команды.
1 |
<span class="hljs-variable">$ </span>brew install openshift-cli |
OC Client для Linux
На той же странице у нас есть tar-файл для установки Linux, который можно использовать для установки. Позже можно задать переменную пути, указывающую на это конкретное исполняемое место.
https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2
Распакуйте tar-файл, используя следующую команду.
$ tar –xf < path to the OC setup tar file >
Выполните следующую команду, чтобы проверить аутентификацию.
C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc login
Server
Файлы конфигурации CLI
Файл конфигурации OC CLI используется для управления несколькими подключениями к серверу OpenShift и механизмом аутентификации. Этот файл конфигурации также используется для хранения и управления несколькими профилями, а также для переключения между ними. Обычный файл конфигурации выглядит следующим образом.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
$ 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
Для установки учетных данных пользователя
1 2 3 |
$ 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>] |
Для настройки кластера
1 2 3 |
$ 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
Для настройки контекста
1 2 |
$ oc config set-context <context_nickname> [--cluster = <cluster_nickname>] [--user = <user_nickname>] [--namespace = <namespace>] |
Профили CLI
В одном файле конфигурации CLI мы можем иметь несколько профилей, каждый из которых имеет свою конфигурацию сервера OpenShift, которую позже можно использовать для переключения между разными профилями CLI.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
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.
Если мы хотим проверить текущий используемый профиль, это можно сделать с помощью -
1 2 3 4 5 6 |
$ 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". |
Если мы хотим переключиться на другой интерфейс командной строки, это можно сделать из командной строки с помощью следующей команды.
1 2 3 |
$ oc project openshift-project Now using project "Openshift-project" on server " https://vklnld908.int.example.com:8443". |
Используя указанную выше команду, мы можем переключаться между профилями. В любой момент, если мы хотим просмотреть конфигурацию, мы можем использовать команду $ oc config view.
OpenShift - Операции через интерфейс командной строки
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
1 2 3 4 5 6 7 8 |
# 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 использует два метода установки для настройки кластера 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 используется в качестве резервной копии установки.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
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>" |
Здесь у нас есть переменная для конкретной роли, которую можно определить, если кто-то хочет установить какую-то конкретную переменную.
После этого мы можем проверить установку, используя следующую команду.
1 2 3 4 5 |
$ 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, а затем добавляем в этот файл сведения о новом узле или сервере. Файл конфигурации выглядит следующим образом.
1 2 3 4 5 |
[OSEv3:children] masters nodes new_nodes new_master |
В том же файле Ansible hosts добавьте подробные сведения о новом узле, как показано ниже.
1 2 |
[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 на главной машине, что можно сделать с помощью следующих команд.
1 2 3 4 |
$ ETCD_DATA_DIR = /var/lib/origin/openshift.local.etcd $ etcdctl backup \ --data-dir $ETCD_DATA_DIR \ --backup-dir $ETCD_DATA_DIR.bak.<date> |
Обновление основных компонентов
В мастере OpenShift мы начинаем обновление с обновления файла etcd, а затем переходим к Docker. Наконец, мы запускаем автоматизированный исполнитель, чтобы установить кластер в нужное положение. Однако перед запуском обновления нам нужно сначала активировать атомарные пакеты openshift на каждом из мастеров. Это можно сделать с помощью следующих команд.
Step 1 - Удалите пакеты atomic-openshift
$ atomic-openshift-excluder unexclude
Step 2 - Обновить etcd на всех мастерах.
$ yum update etcd
Step 3 - Перезапустите службу etcd и проверьте, успешно ли она запустилась.
$ systemctl restart etcd
$journalctl -r -u etcd
Step 4 - Обновите пакет Docker.
$ yum update docker
Step 5 - Перезапустите службу Docker и проверьте, правильно ли она работает.
$ systemctl restart docker
$ journalctl -r -u docker
Step 6 - После этого перезагрузите систему с помощью следующих команд.
$ systemctl reboot
$ journalctl -r -u docker
Step 7 - Наконец, запустите atomic-executer, чтобы вернуть пакеты в список исключений yum.
$ atomic-openshift-excluder exclude
Нет такого принуждения к обновлению политики, ее нужно обновлять только в случае рекомендации, что можно проверить с помощью следующей команды.
$ oadm policy reconcile-cluster-roles
В большинстве случаев нам не нужно обновлять определение политики.
Обновление компонентов узла
После завершения основного обновления мы можем приступить к обновлению узлов. Следует иметь в виду, что период обновления должен быть коротким, чтобы избежать каких-либо проблем в кластере.
Step 1 - Удалите все атомарные пакеты OpenShift со всех узлов, на которых вы хотите выполнить обновление.
$ atomic-openshift-excluder unexclude
Step 2 - Затем отключите планирование узлов перед обновлением.
$ oadm manage-node <node name> --schedulable = false
Step 3 - Реплицируйте весь узел с текущего хоста на другой хост.
$ oadm drain <node name> --force --delete-local-data --ignore-daemonsets
Step 4 - Обновите установку Docker на хосте.
$ yum update docker
Step 5 - Перезапустите службу Docker, а затем запустите узел службы Docker.
$systemctl restart docker
$ systemctl restart atomic-openshift-node
Step 6 - Проверьте, правильно ли они оба запустились.
$ journalctl -r -u atomic-openshift-node
Step 7 - После завершения обновления перезагрузите узел.
$ systemctl reboot
$ journalctl -r -u docker
Step 8 - Повторно включите планирование на узлах.
$ oadm manage-node <node> --schedulable.
Step 9 - Запустите программу-исполнитель atomic-openshift, чтобы вернуть пакет OpenShift на узел.
$ atomic-openshift-excluder exclude
Step 10 - Наконец, проверьте, все ли узлы доступны.
1 2 3 4 5 6 |
$ oc get nodes NAME STATUS AGE master.example.com Ready 12d node1.example.com Ready 12d node2.example.com Ready 12d |
OpenShift - масштабирование приложений
Автомасштабирование - это функция OpenShift, при которой развернутые приложения могут масштабироваться и уменьшаться по мере необходимости в соответствии с определенными спецификациями. В приложении OpenShift автомасштабирование также известно как автомасштабирование пода. Есть дваtypes of application scaling следующим образом.
Вертикальное масштабирование
Вертикальное масштабирование - это все о добавлении все большей и большей мощности одной машине, что означает добавление большего количества ЦП и жесткого диска. Это старый метод OpenShift, который сейчас не поддерживается выпусками OpenShift.
Горизонтальное масштабирование
Этот тип масштабирования полезен, когда необходимо обрабатывать больше запросов за счет увеличения количества машин.
В OpenShift есть two methods to enable the scaling feature.
- Использование файла конфигурации развертывания
- При запуске образа
Использование файла конфигурации развертывания
В этом методе функция масштабирования включается через yaml-файл конфигурации развертывания. Для этого используется команда OC autoscale с минимальным и максимальным количеством реплик, которые должны выполняться в любой заданный момент времени в кластере. Нам нужно определение объекта для создания автомасштабирования. Ниже приведен пример файла определения автомасштабирования модуля.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
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
Скользящая стратегия
Стратегия прокатки используется для последовательного обновления или развертывания. Этот процесс также поддерживает хуки жизненного цикла, которые используются для внедрения кода в любой процесс развертывания.
1 2 3 4 5 6 7 8 |
strategy: type: Rolling rollingParams: timeoutSeconds: <time in seconds> maxSurge: "<definition in %>" maxUnavailable: "<Defintion in %>" pre: {} post: {} |
Воссоздать стратегию
Эта стратегия развертывания имеет некоторые из основных функций стратегии скользящего развертывания, а также поддерживает привязку жизненного цикла.
1 2 3 4 5 6 |
strategy: type: Recreate recreateParams: pre: {} mid: {} post: {} |
Индивидуальная стратегия
Это очень полезно, когда кто-то хочет предоставить свой собственный процесс или поток развертывания. Все настройки могут быть выполнены в соответствии с требованиями.
1 2 3 4 5 6 7 8 |
strategy: type: Custom customParams: image: organization/mongoDB command: [ "ls -l", "$HOME" ] environment: - name: VipinOpenshiftteat value: Dev1 |
OpenShift - Администрирование
В этой главе мы рассмотрим такие темы, как управление узлом, настройка учетной записи службы и т. Д.
Конфигурация мастера и узла
В OpenShift нам нужно использовать команду start вместе с OC для загрузки нового сервера. При запуске нового мастера нам нужно использовать мастер вместе с командой запуска, тогда как при запуске нового узла нам нужно использовать узел вместе с командой запуска. Для этого нам необходимо создать файлы конфигурации как для мастера, так и для узлов. Мы можем создать базовый файл конфигурации для мастера и узла, используя следующую команду.
Для главного файла конфигурации
$ openshift start master --write-config = /openshift.local.config/master
Для файла конфигурации узла
$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>
После выполнения следующих команд мы получим файлы базовой конфигурации, которые можно использовать в качестве отправной точки для настройки. Позже у нас может быть тот же файл для загрузки новых серверов.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 |
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 |
Файлы конфигурации узла
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
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 |
Так выглядят файлы конфигурации узла. Когда у нас есть эти файлы конфигурации, мы можем запустить следующую команду для создания главного и узлового серверов.
1 2 3 |
$ openshift start --master-config = /openshift.local.config/master/master- config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node- config |