Как развернуть приложение в openshift
—
Конечно для этого использую доступные возможности самого OpenShift, которых предостаточно.
И так у меня есть подготовленный java артефакт, далее подготавливаю Dockerfile c нужными мне характеристиками и функциональностью
MAINTAINER Rylkov Alexander <arylkov@ххххх.ххх>
COPY demo.springboot.mvn-0.0.1-SNAPSHOT.jar /deployments/app.jar
ENV JAVA_OPTS="$JAVA_OPTS -Xms500m -Xmx1024m"
EXPOSE 8080
EXPOSE 5005
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /deployments/app.jar" ]
Таким образом в папке будет два файла: артефакт и Dockerfile
Состав файлов это условно, если например в Dockerfile потребуются еще дополнительные файлы для docker image, то их добавляем сюда. Сейчас собственно в Dockerfile указан базовый образ java и мое приложение Spring boot, открыто два порта и др.
На этом шаге имеем выбор/свободу в средстве сборки приложения и сборки docker image.
Далее подготавливаю OpenShift template для приложения, эта операция может быть разовой, ее надо только параметризовать. Поскольку он может содержать в себе все возможное для создания, запуска и работы приложения, то через него и будем управлять этими процессами. У меня он будет достаточно простой и состоять из трех самых необходимых конфигураций
- ImageStream
- BuildConfig
- DeploymentConfig
В шаблоне указаны как пример некоторые параметры контейнера, указаны например ресурсы/лимиты, перемененная окружения TZ, указан один параметр шаблона — имя приложения (APP_NAME). Адрес docker реестра указан для версии minishift (172.30.1.1:5000/myproject/ ее использую локально для разработки) и др.
Но для моего сценария самое главное указано здесь
В BuildConfig сказано что источником будет являться бинарный файл(ы), а управлять стратегией подготовки docker image — Dockerfile (type: Docker)
Создадим этот шаблон в OpenShift
oc create -f template.yaml
Этот шаблон появится в каталоге шаблонов (можно будет организовать процесс и из web UI консоли, но не здесь).
По этому шаблону далее создадим приложение (по факту это только имя и не более)
oc new-app java-app-sample -p APP_NAME=app-sample
укажем имя шаблона и параметр имя приложения
Создались три мои конфигурации
Запускаем сам процесс сборки и развертывания приложения в контейнере.
>oc start-build app-sample --from-dir . --follow
Видим, что содержимое папки было загружено в OpenShift, который запустил процесс Docker для подготовки Image по Dockerfile и в заключении поместил образ в docker registry.
В web консоли OpenShift видно стартовало приложение
Указанные в конфигурации параметры контейнера
Указанная в конфигурации переменная окружения
В логе
Таким образом без дополнительных плагинов, с максимальным контролем и свободой выбора удалось разместить приложение в OpenShift.
Материалы
Installing Minishift
для изучения темы OpenShift я бы посоветовал начать с Minishift
Сначала извинюсь, тут малость сыро, хотя и работает, а сейчас работает "влет", но без телефонии возможности ограничены. В основном был описан вариант для разработки, когда основной каталог $OPENSHIFT_REPO_DIR (
/app-root/repo) и Вы в своем локальном репозитории имеете копию, делаете правки, OpenShift — это Ваша песочница.
Но есть вариант установки "для эксплуатации". Он упомянут в конце вышеуказанной статьи, но без деталей. В этом случае Вы используете $OPENSHIFT_DATA_DIR (
/app-root/data). Разница в том, что локальный репозиторий содержит настроечные скрипты (action_hooks, см. ниже) и файлы данных, патчи, etc. Но не само приложение целиком.
Руководство "step-by-step", основанное на реальном примере.
Перед началом
Установка на любой PaaS-хостинг(тот же Redhat Openshift) требует, соблюдения его спецификаций:
Openshift глобально предоставит Вам каталог пользователя со стандартным набором подкаталогов: тут. Особенность движка — в самом домашнем каталоге конфиги установленного ПО принадлежат root. Ваше имя длинная такая цифирь типа хэша (очень docker напоминает) .
Все необходимые данные хранятся в переменных окружения вида OPENSHIFT_, справочник.
Приступаем
Создаем "заглушку" и клонируем ее в свой домашний каталог.
$rhc app create example php-5.3 mysql-5.5
$cd example
Служебный каталог Openshift
$ tree .openshift/
.openshift/
├── action_hooks
│ └── README.md
├── cron
│ …
├── markers
│ └── README.md
├── pear.txt
└── README.md
Строго говоря нас интересуют action_hooks. Это набор скриптов для различных целей, но для нашего примера мы используем только build и deploy, вообще имена скриптов соответствуют производимому действию. Будем решать простенькую задачу:
Выкачать исходники на PaaS-хостинг.
Развернуть их в
Внести изменения (как правило, обязательно заменить переменные доступа к СУБД на встроенные OpenShift).
И поместим туда
В скрипте накладывается патч (та самая подстановка переменных среды для подключения к СУБД MySQL) и добавляется установочный .htaccess. У вас могут быть свои, то есть для примера возьмите готовые.
Развертываем приложение на PaaS Openshift:
$git push
Что эквивалентно $git push origin master.
В этой статье описывается, как развернуть приложение в кластере Azure Red Hat OpenShift с помощью OpenShift Serverless. OpenShift Serverless помогает разработчикам развертывать и запускать приложения, которые будут масштабироваться по запросу, устраняя потребление ресурсов, когда они не используются.
Код приложения может быть упакован в контейнер вместе с соответствующими средами выполнения, а бессерверные функции будут запускать контейнеры приложений, когда они активируются событием. Приложения могут активироваться различными источниками событий. Это могут быть события из ваших приложений, облачных служб от нескольких поставщиков, систем SaaS и других служб.
Управление всеми аспектами развертывания любого контейнера в бессерверном режиме осуществляется непосредственно в интерфейсе OpenShift. Разработчики могут визуально определять события, активирующие запуск их контейнерных приложений, и несколькими способами изменять параметры событий. Приложения OpenShift Serverless можно интегрировать с другими службами OpenShift, такими как OpenShift Pipelines, Service Mesh и Monitoring, предоставляя полноценную среду разработки и развертывания бессерверных приложений.
Подготовка к работе
Создайте кластер.
Следуйте инструкциям руководства Создание кластера Azure Red Hat OpenShift. Если решено установить и использовать CLI локально, то для работы с этим учебником понадобится Azure CLI 2.6.0 или более поздней версии. Чтобы узнать версию, выполните команду az --version . Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.
Подключение к кластеру
Для управления кластером Azure Red Hat OpenShift используется oc, клиент командной строки OpenShift.
Следуйте указаниям руководства, чтобы установить интерфейс командной строки, получить учетные данные кластера и подключиться к кластеру с помощью веб-консоли и интерфейса командной строки OpenShift.
Установка программы командной строки Knative (kn)
Если вы используете команды в Azure Cloud Shell, скачайте последнюю версию Knative CLI для Linux.
Запуск веб-консоли
Чтобы узнать URL-адрес веб-консоли кластера, выполните следующую команду.
Полученный URL-адрес должен иметь следующий вид.
Перейдите по URL-адресу консоли в браузере и войдите с помощью учетных данных kubeadmin .
Установка оператора OpenShift Serverless
После входа в веб-консоль OpenShift убедитесь, что вы находитесь в перспективе Administrator (Администратор). Откройте раздел Operator Hub, найдите оператор OpenShift Serverless и выберите его.
Затем откройте страницу установки оператора, щелкнув Install (Установить).
Выберите соответствующий канал обновления для версии кластера Azure Red Hat OpenShift и установите оператор в пространство имен openshift-serverless . Прокрутите вниз и нажмите кнопку Install (Установить).
Через несколько минут на странице состояние должно быть указано, что оператор установлен и готов к использованию. Для продолжения нажмите кнопку View Operator (Просмотреть оператор).
Установка Knative Serving
Возможность запуска любого контейнера в бессерверном режиме для OpenShift Serverless реализуется благодаря вышестоящему экземпляру Knative. Knative расширяет возможности Kubernetes, предоставляя набор компонентов для развертывания и запуска современных приложений, а также управления ими с помощью бессерверной методологии.
Создание экземпляра Knative Serving
Перейдите к пространству имен knative-serving , щелкнув раскрывающийся список проектов в левом верхнем углу. В разделе Provided APIs (Предоставленные API) щелкните Create Instance (Создать экземпляр) на карте Knative Serving.
Оставьте значения по умолчанию и прокрутите вниз страницу Create Knative Serving (Создание Knative Serving), чтобы нажать кнопку Create (Создать).
Дождитесь, пока в столбце Status (Состояние) на появится значение Ready (Готово). Теперь экземпляр OpenShift Serverless установлен и готов к созданию проекта OpenShift Serverless.
Создание бессерверного проекта
Для создания нового проекта с именем demoserverless выполните следующую команду.
Выходные данные должны иметь следующий вид.
Выберите перспективу Разработчик вместо перспективы Администратор в меню слева и выберите demoserverless в списке проектов. Должна открыться страница Топология для проекта.
Развертывание с использованием веб-консоли
OpenShift определяет, что это проект Python, и выбирает соответствующий образ для инструмента сборки.
Прокрутите страницу вниз до раздела Resources (Ресурсы) и убедитесь, что для создаваемого ресурса выбран тип Knative Service (Служба Knative). Это действие создаст службу Knative — то есть тип развертывания, который позволяет масштабировать среду OpenShift Serverless при простое.
Когда все готово, внизу страницы щелкните Создать. При этом будут созданы ресурсы для управления сборкой и развертыванием приложения. Затем будет выполнено перенаправление к обзору топологии проекта.
Обзор топологии обеспечивает визуальное представление развернутого приложения. В этом представлении можно увидеть общую структуру приложения.
Дождитесь завершения сборки. Это может занять несколько минут. После завершения сборки в левом нижнем углу службы появится зеленая галочка.
Просмотр масштаба приложения
В списке Display Options (Параметры отображения) в верхней части представления топологии щелкните Pod Count (Число pod). Дождитесь, пока число pod не будет уменьшено до нуля. Такое вертикальное уменьшение масштаба может занять несколько минут.
Щелкните значок Open URL (Открыть URL-адрес) в правом верхнем углу панели службы Knative. На новой вкладке браузера откроется приложение. Закройте эту вкладку и вернитесь к представлению топологии. В представлении топологии можно увидеть, что приложение масштабировано до одного pod в соответствии с вашим запросом. Через несколько минут приложение масштабируется до 0 pod.
Принудительная установка новой редакции и настройка распределения трафика
При каждом обновлении конфигурации службы создается новая редакция службы. По умолчанию маршрут службы направляет весь трафик в последнюю готовую редакцию. Это поведение можно изменить, определив редакцию, которая будет получать часть трафика. Службы Knative позволяют применять сопоставление трафика. Это означает, что редакции службы можно сопоставить с выделенной частью трафика. Сопоставление трафика также дает возможность создавать уникальные URL-адреса для конкретных редакций.
В представлении Topology (Топология) щелкните редакцию в службе, чтобы просмотреть сведения о ней. Эмблемы под кольцом pod и в верхней части панели сведений должны быть в состоянии (REV) . Прокрутите вниз вкладку Resources (Ресурсы) на боковой панели и щелкните конфигурацию, связанную со службой.
Принудительно обновите конфигурацию, перейдя на вкладку YAML и прокрутив ее вниз, чтобы изменить значение timeoutSeconds на 301 . Щелкните Save (Сохранить), чтобы сохранить обновленную конфигурацию. В реальном сценарии такое обновление конфигурации также может быть активировано обновлением тега образа контейнера.
Вернитесь к представлению Topology (Топология). Вы увидите, что была развернута новая редакция. Щелкните службу, после которой указана эмблема (KSVC) , и нажмите кнопку Set Traffic Distribution (Задать распределение трафика). Теперь вы можете разделить трафик между разными редакциями службы.
Представление Topology (Топология) теперь показывает, как распределяется трафик между двумя редакциями.
Использование программы командной строки Knative (kn)
На предыдущих шагах вы использовали веб-консоль OpenShift для создания и развертывания приложения в OpenShift Serverless. Так как OpenShift Serverless работает под управлением Knative, можно также использовать программу командной строки Knative (kn) для создания служб Knative.
Если вы еще не установили интерфейс командной строки kn , обязательно выполните действия, описанные в разделе предварительных требований этой статьи. Также убедитесь, что вы выполнили вход с помощью программы командной строки OpenShift oc .
Мы будем использовать образ контейнера, который уже создан в quay.io/rhdevelopers/knative-tutorial-greeter .
Развертывание службы
Чтобы развернуть службы, выполните следующую команду.
Должен отобразиться результат, как показано ниже.
Вы можете получить список маршрутов в проекте, выполнив следующую команду.
Вы получите список маршрутов в пространстве имен. Откройте URL-адрес в браузере, чтобы увидеть развернутую службу.
Развертывание новой версии службы
Разверните новую версию приложения, выполнив приведенную ниже команду. Передайте в нее тег образа :latest и переменную среды MESSAGE_PREFIX .
Вы получите подтверждение того, что была развернута новая редакция, greeter-v2 .
Чтобы просмотреть список всех редакций и распределение трафика между ними, выполните следующую команду.
Вы получите список, аналогичный приведенному ниже. Обратите внимание на то, что новая редакция получает 100 % трафика.
Развертывания blue-green и canary
По умолчанию при развертывании новой редакции она получает 100 % трафика. Предположим, что необходимо реализовать стратегию развертывания blue-green, где можно быстро выполнить откат до более старой версии приложения. Knative упрощает это.
Обновите службу, чтобы создать три тега трафика при отправке 100 % трафика:
- current указывает на текущую развернутую версию;
- prev указывает на предыдущую версию;
- latest всегда указывает на последнюю версию.
Вы получите подтверждение, аналогичное приведенному ниже.
Выведите список маршрутов, используя следующую команду.
Вы получите выходные данные, содержащие URL-адреса для каждого из тегов и сведения о распределении трафика.
Предположим, что вы хотите быстро выполнить откат до предыдущей версии. Вы можете изменить распределение трафика, чтобы отправлять 100 % трафика по тегу предыдущей версии.
Повторите проверку, выведя список маршрутов с помощью следующей команды.
Вы получите выходные данные, в которых показано, что 100 % трафика направляется к предыдущей версии.
Очистка ресурсов
После завершения работы с приложением можно запустить следующую команду, чтобы удалить проект.
Также можно удалить кластер, следуя инструкциям в документе Руководство: удаление кластера Azure Red Hat OpenShift 4.
Дальнейшие шаги
Из этого руководства можно получить следующую информацию.
- Установка оператора OpenShift Serverless и Knative Serving.
- Развертывание бессерверного проекта с помощью веб-консоли.
- Развертывание бессерверного проекта с помощью Knative CLI (kn).
- Настройка развертываний blue-green и развертываний canary с помощью Knative CLI (kn).
Узнайте больше о том, как создавать и развертывать бессерверные, управляемые событиями приложения в Azure Red Hat OpenShift с использованием OpenShift Serverless. Обратитесь к документации по началу работы с OpenShift Serverless, а также к документации по созданию бессерверных приложений и управлению ими.
OpenShift состоит из двух типов медиан для создания и развертывания приложений с помощью графического интерфейса или интерфейса командной строки. В этой главе мы будем использовать CLI для создания нового приложения. Мы будем использовать клиент OC для связи со средой OpenShift.
Создание нового приложения
В OpenShift есть три способа создания нового приложения.
- Из исходного кода
- Из изображения
- Из шаблона
Из исходного кода
Когда мы пытаемся создать приложение из исходного кода, OpenShift ищет файл Docker, который должен присутствовать в репозитории, который определяет процесс сборки приложения. Мы будем использовать oc new-app для создания приложения.
Первое, что следует иметь в виду при использовании репо, это то, что он должен указывать на источник в репо, откуда OpenShift будет извлекать код и собирать его.
Если репозиторий клонирован на компьютере Docker, на котором установлен клиент OC, и пользователь находится в том же каталоге, его можно создать с помощью следующей команды.
Ниже приведен пример попытки построить из удаленного репо для определенной ветви.
При указании файла Docker в хранилище мы должны определить стратегию сборки, как показано ниже.
Из изображения
При создании приложения с использованием изображений изображения присутствуют на локальном сервере Docker, во внутреннем хранилище Docker или в концентраторе Docker. Единственное, в чем пользователь должен убедиться, это то, что он может без проблем извлекать изображения из концентратора.
OpenShift имеет возможность определять используемый источник, будь то образ Docker или поток источника. Однако, если пользователь желает, он может явно определить, является ли это потоком изображения или изображением Docker.
Из шаблона
Шаблоны могут быть использованы для создания нового приложения. Это может быть уже существующий шаблон или создание нового шаблона.
Читайте также: