jHipster App аварийно завершает работу, потому что CloudFoundry активирует облачный профиль - PullRequest
0 голосов
/ 02 января 2019

Сбой при развертывании моего маленького приложения jhipster "customerapp", возможно, из-за того, что облачный литейный завод устанавливает профиль "cloud" в дополнение к профилю "dev".Я использую несколько пространств в облачном литейном производстве для разных этапов разработки: dev, staging и prod.

Я использовал генератор jhipster, добавил некоторые объекты клиентов, адреса и контакты.Приложение работает локально без каких-либо проблем.

Я также использую gitlab-ci для сборки, тестирования и развертывания моего программного обеспечения.Мой .gitlab-ci.yml выглядит следующим образом (я удалил некоторые ненужные части).

image: mydockerregistry.xxxxx.de/jutoro/jhipster_test/jhipster-dockerimage

services:
  - docker:dind

cache:
   key: "$CI_BUILD_REF_NAME"
  paths:
    - node_modules
    - .maven

 before_script:
   - chmod +x mvnw
   - export MAVEN_USER_HOME=`pwd`/.maven

 stages:
   - build
   - package
   - deployToCF

 mvn-build:
   stage: build
   only:
    - dev
    - prod
   script: 
     - npm install
     - ./mvnw compile -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME - 
Dspring.profiles.active=dev

 mvn-package-dev:
  stage: package
  only:
    - dev   
  script:
    - npm install    
    - ./mvnw package -Pdev -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -Dspring.profiles.active=dev
  artifacts:
      paths:
        - target/*.war  

mvn-package-prod:
  stage: package
  only:
    - prod 
  script:    
    - npm install    
    - ./mvnw package -Pprod -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -Dspring.profiles.active=prod
  artifacts:
      paths:
        - target/*.war     

deployToCloudFoundry-dev:
  image: pivotalpa/cf-cli-resource
  stage: deployToCF
  only:
    - dev
  cache:
    paths:
      - bin/
  script:
   - bash ci/scripts/deployToCloudFoundry.sh  

deployToCloudFoundry-prod:
  image: pivotalpa/cf-cli-resource
  stage: deployToCF
  only:
    - prod
  cache:
    paths:
      - bin/
  script:
    - bash ci/scripts/deployToCloudFoundry.sh

DOCKERFILE (который создается и добавляется в наш репозиторий докеров также с помощью gitlab-ci):

# DOCKER-VERSION 1.8.2
FROM openjdk:8
MAINTAINER Robert Zieschang 

RUN apt-get install -y curl
# install node.js
RUN curl -sL https://deb.nodesource.com/setup_10.x | bash -
RUN apt-get install -y nodejs python g++ build-essential && \
apt-get clean && \
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

# install yeoman
RUN npm install -g yo

Сценарий оболочки deplpoyToCloudFoundry.sh:

cf login -a $CF_API_ENDPOINT -u $CF_USER -p $CF_PASS -o "${CF_ORG^^}" -s  ${CI_COMMIT_REF_NAME^^} 
cf push -n $CI_PROJECT_NAME-$CI_COMMIT_REF_NAME 

Мой файл манифеста:

---
applications:
- name: customerapp
  memory: 1024M
  #buildpack: https://github.com/cloudfoundry/java-buildpack#v3.19.2
  path: target/customerapp-0.0.1-SNAPSHOT.war
  services:
  - postgresql
  env:
    #SPRING_PROFILES_ACTIVE: dev
    #SPRING_PROFILES_DEFAULT: dev
    #JAVA_OPTS: -Dspring.profiles.active=dev

Конвейер работает нормально, приложение упаковывается в файл war и загружается вОблачный литейный завод также работает, но он дает сбой, и я предполагаю, что это потому, что каким-то образом облачный литейный завод все еще применяет профиль «облако», и это переопределяет важные конфигурации из профиля dev Jhipsters.

 [...]
2019-01-02T19:03:16.05+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.055  INFO 8 --- [           main] pertySourceApplicationContextInitializer : 'cloud' property source added
2019-01-02T19:03:16.05+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.056  INFO 8 --- [           main] nfigurationApplicationContextInitializer : Reconfiguration enabled
2019-01-02T19:03:16.06+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.064  INFO 8 --- [           main] com.jutoro.cco.CustomerappApp            : The following profiles are active: cloud,dev,swagger     
[...]

Это позже приводит к:2019-01-02T19: 03: 29.17 + 0100 [APP / PROC / WEB / 0] OUT 2019-01-02 18: 03: 29.172 ОШИБКА 8 --- [main] com.jutoro.cco.CustomerappApp: вы неправильно настроиливаше приложение!Он не должен работать одновременно с профилями dev и cloud.[...]

После этого облачный литейный завод останавливает приложение.

2019-01-02T19:04:11.09+0100 [CELL/0] OUT Cell 83899f60-78c9-4323-8d3c-e6255086c8a7 stopping instance 74be1834-b656-4445-506c-bdfa

Сгенерированные application-dev.yml и bootstrap.yml были просто изменены в некоторых местах:

bootstrap.yml

        uri: https://admin:${jhipster.registry.password}@url.tomy.jhipsterregistryapp/config

        name: customerapp
        profile: dev # profile(s) of the property source
        label: config-dev 

application-dev.yml

client:
    service-url:
        defaultZone: https://admin:${jhipster.registry.password}@url.tomy.jhipsterregistryapp/eureka/

Что я пытался установить профиль разработчика в cf:

  • добавлено-Dspring.profiles.active = dev в gitlab-ci.yml в дополнение к -Pdev
  • добавлено SPRING_PROFILES_ACTIVE: dev в манифесте env: section
  • добавлено SPRING_PROFILES_DEFAULT: dev в манифесте env:section
  • добавлено SPRING_APPLICATION_JSON: {"spring.cloud.dataflow.applicationProperties.stream.spring.profiles.active": "dev"} (как упомянуто в https://github.com/spring-cloud/spring-cloud-dataflow/issues/2317)
  • добавлено JAVA_OPTS: -Dspring.profiles.active = dev в манифесте env: section (cv env customerapp показывает, что оно установлено)
  • установить JAVA_OPTS -Dspring.profiles.active = dev с помощью cf set-env и cf restage

Любая помощь приветствуется.

С уважением, Роберт

Ответы [ 2 ]

0 голосов
/ 30 января 2019

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

#hibernate.connection.provider_disables_autocommit: true 

В свойствах приложения это исправлено.

0 голосов
/ 10 января 2019

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

Я смог развернуть свое приложение jhipster в облачной среде.Я как-то «исправил» это, но я не знаю о дальнейших последствиях.Пока что.

Оказалось, что у облачного литейного цеха была проблема с мониторингом моего приложения jhipster через стандартный http-код проверки работоспособности, который должен быть "heartbeat"?Поэтому я решил переключить режим мониторинга не на сердцебиение.Просто переключите тип проверки работоспособности в свой файл manifest.yml.

health-check-type: process

Приложение теперь запущено.

...