Как вы осуществляли деплой приложения с помощью OpenShift?

При деплое приложения в OpenShift я обычно следовал следующим шагам:

1. Подготовка артефакта приложения: Убедился, что у меня есть готовый образ Docker приложения или исходный код, который OpenShift может собрать.
2. Авторизация в кластере: Использовал команду oc login для подключения к нужной среде OpenShift.
3. Создание нового проекта (namespace): Если проект не существовал, создавал его:

   # Создание нового проекта
   oc new-project my-application-project
   

4. Создание ресурса BuildConfig: Определял, как OpenShift должен собирать образ приложения. Это может быть сборка из Dockerfile или S2I (Source-to-Image) сборка из исходного кода.

   # Пример BuildConfig для S2I сборки из репозитория Git
   apiVersion: build.openshift.io/v1
   kind: BuildConfig
   metadata:
     name: my-app-build
   spec:
     source:
       git:
         uri: https://github.com/my-org/my-app.git # URL репозитория
     strategy:
       sourceStrategy:
         from:
           kind: ImageStreamTag
           name: 'nodejs:latest' # Базовый образ для сборки
           namespace: openshift
     output:
       to:
         kind: ImageStreamTag
         name: 'my-app:latest' # Тег для выходного образа
   

   Затем применял его:

   # Применение BuildConfig
   oc apply -f buildconfig.yaml
   

5. Запуск сборки: Инициировал процесс сборки образа.

   # Запуск сборки по имени BuildConfig
   oc start-build my-app-build --follow
   

6. Создание ресурса DeploymentConfig: Описывал, как приложение должно быть развернуто и управляться в кластере.

   # Пример DeploymentConfig
   apiVersion: apps.openshift.io/v1
   kind: DeploymentConfig
   metadata:
     name: my-app
   spec:
     replicas: 3 # Желаемое количество экземпляров
     selector:
       app: my-app # Селектор для Pod'ов
     strategy:
       type: Rolling # Стратегия развертывания
     template:
       metadata:
         labels:
           app: my-app
       spec:
         containers:
         - name: my-app
           image: 'image-registry.openshift-image-registry.svc:5000/my-application-project/my-app:latest' # Образ из ImageStream
           ports:
           - containerPort: 8080 # Порт приложения
     triggers:
     - type: ConfigChange # Триггер при изменении DeploymentConfig
     - type: ImageChange # Триггер при изменении образа в ImageStream
       imageChangeParams:
         automatic: true
         containerNames:
         - my-app
         from:
           kind: ImageStreamTag
           name: 'my-app:latest'
   

   Применял его:

   # Применение DeploymentConfig
   oc apply -f deploymentconfig.yaml
   

7. Создание ресурса Service: Определял, как Pod'ы приложения будут доступны внутри кластера.

   # Пример Service
   apiVersion: v1
   kind: Service
   metadata:
     name: my-app-service
   spec:
     selector:
       app: my-app # Селектор для Pod'ов
     ports:
     - protocol: TCP
       port: 80 # Внешний порт сервиса
       targetPort: 8080 # Целевой порт в Pod'е
   

   Применял его:

   # Применение Service
   oc apply -f service.yaml
   

8. Создание ресурса Route: Открывал приложение для внешнего доступа.

   # Пример Route
   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
     name: my-app-route
   spec:
     to:
       kind: Service
       name: my-app-service # Сервис, на который направляется трафик
     port:
       targetPort: 80 # Целевой порт сервиса
   

   Применял его:

   # Применение Route
   oc apply -f route.yaml
   

9. Мониторинг развертывания: Следил за статусом развертывания и Pod'ов.

   # Просмотр статуса DeploymentConfig
   oc rollout status dc/my-app
   # Просмотр списка Pod'ов
   oc get pods
   # Просмотр логов Pod'а
   oc logs <имя_пода>
   

В зависимости от конкретных требований, мог использоваться и Kubernetes Deployment вместо OpenShift DeploymentConfig, а также другие ресурсы, такие как PersistentVolumeClaims для управления хранилищем или Secrets и ConfigMaps для инъекции конфигурации. Часто эти шаги автоматизировались с помощью CI/CD пайплайнов (например, OpenShift Pipelines, Jenkins, GitLab CI).