[BETA] Deploying to OpenShift Permalink to "[BETA] Deploying to OpenShift"
WARNING! This is a new sub-generator, of BETA quality WIP release! Feedback is highly welcome!! Happy OpenShifting!!!
Work-in-progress Permalink to "Work-in-progress"
- Mongo and Cassandra replication mode is not yet tested
Install Options Permalink to "Install Options"
OpenShift offers two options,
- OpenShift Origin - is the open source upstream project that powers OpenShift
- OpenShift Container Platform - is the enterprise container application platform supported by Red Hat
Minishift Permalink to "Minishift"
Minishift is a toolkit that helps to run the all in one OpenShift VM locally. Minishift runs a single-node OpenShift cluster inside a VM on a laptop for users to try it out locally.
Minishift requires a hypervisor to start the virtual machine on which the OpenShift cluster is provisioned. Make sure that the hypervisor of your choice is installed and enabled on your system before you start Minishift.
Pre-requisites Permalink to "Pre-requisites"
You have to install:
- Hypervisor - Depending on your OS, you have the choice of different options
You must have a Docker registry. If you don’t have one, you can use the official Docker Hub
Minishift allows you to try out both Origin and Container Platform locally,
- OpenShift Origin
- OpenShift Container Platform - Red Hat Container Development Kit provides a Minishift packaged pre-built Container Development Environment based on Red Hat Enterprise Linux. Developers can now get Red Hat Container Development Kit via the no-cost Red Hat Enterprise Linux® Developer Suite subscription for development purposes by registering and downloading through redhat.com.
The sub-generator works fine with both Origin and Container Platform and uses the same image versions as Docker.
Running the sub-generator Permalink to "Running the sub-generator"
To generate config files for OpenShift, run this command in the project/root folder:
Then answer all the questions to deploy your application.
Which type of application would you like to deploy? Permalink to "Which type of application would you like to deploy?"
Type of application depends on whether you wish to deploy a microservices or monoliths.
Enter the root directory where your applications are located Permalink to "Enter the root directory where your applications are located"
Enter the path. All the OpenShift generator files will be persisted in this path
Which applications do you want to include in your OpenShift configuration? Permalink to "Which applications do you want to include in your OpenShift configuration?"
Select your applications.
Enter the admin password used to secure the JHipster Registry admin Permalink to "Enter the admin password used to secure the JHipster Registry admin"
This question is only displayed if you choose microservices architecture.
What should we use for the OpenShift namespace? Permalink to "What should we use for the OpenShift namespace?"
This is the OpenShift project space where all the services get deployed and the generated files are tagged to this template
Which type of database storage would you like to use? Permalink to "Which type of database storage would you like to use?"
This question is only displayed if any of the chosen apps has database type selected. This prompts for ephemeral or persistent storage options. Containers by very nature are ephemeral (data will not be retained between restarts/faults). Persistent storage option allows to mount external storage like NFS, EBS etc,. so that data survives between restarts and faults.
What should we use for the base Docker repository name? Permalink to "What should we use for the base Docker repository name?"
If you choose Docker Hub as main registry, it will be your Docker Hub login.
What command should we use for push Docker image to repository? Permalink to "What command should we use for push Docker image to repository?"
The default command to push to Docker Hub is
docker image push
For example, if you use the Google Cloud to publish your Docker images, it will be:
gcloud docker push
Updating your deployed application Permalink to "Updating your deployed application"
Preparing a new deployment Permalink to "Preparing a new deployment"
When your application is already deployed, you can re-deploy it by building a new Docker image:
./mvnw package -Pprod -DskipTests jib:dockerBuild
Or when using gradle:
./gradlew -Pprod bootJar jibDockerBuild -x test
If you face any issue in running the image built by jib plugin (like
chmod +x entrypoint.sh not permitted), then you might have to update scc. Do the following change,
oc edit scc restricted and update
runAsUser.Type strategy to
Pushing to Docker Hub Permalink to "Pushing to Docker Hub"
Tag locally your image:
docker image tag application username/application
Push your image to Docker Hub:
docker image push username/application
Deploying application(s) Permalink to "Deploying application(s)"
You can deploy all your apps by either running:
oc apply -f <directoryPath>/ocp/registry
oc apply -f <directoryPath>/ocp/app1gw
and then install the apps from OpenShift console by choosing the template created in the chosen namespace
It will create a OpenShift deployment for your application and its associated dependent services (database, elasticsearch…) as well as OpenShift service for pod to pod communications(inter service) and a route to access the application from outside.
Info regarding microservice application(s) Permalink to "Info regarding microservice application(s)"
Deploying a Service Registry Permalink to "Deploying a Service Registry"
Although, OpenShift does feature its own internal service discovery with Kube-DNS, centralized config management with ConfigMaps and centralized logging through EFK stack, as JHipster relies on Spring Cloud for configuration management, Eureka/Consul for service discovery and jhipster-console(ELK) for log management, OpenShift deployment does support the same as well.
Consequently, for microservices applications, the JHipster OpenShift sub-generator will generate manifest files to deploy the JHipster-Registry (based on Eureka) or Consul. Moreover, the generated microservices and gateway manifests will contain the appropriate configuration to register themselves to their central registry service.
Managing the JHipster Registry or Consul Permalink to "Managing the JHipster Registry or Consul"
For the JHipster Registry and Consul, StatefulSets configurations are provided. Those are a certain kind of deployment artifact that can handle stateful applications and will let you scale your service registries for high-availability. Kindly note StatefulSets are not yet production ready feature in OpenShift. It is in technology preview (BETA) and you need OpenShift version >=3.5 to use this feature.
Centralized configuration Permalink to "Centralized configuration"
Centralized configuration is also setup using either Spring Cloud Config Server (when using the JHipster-Registry) or the Consul Key/Value store (when using Consul). By default, both configuration servers load their configuration from a OpenShift ConfigMap which contains property files in this format :
apiVersion: v1 kind: ConfigMap metadata: name: application-config namespace: default data: application.yml: |- # global properties shared by all applications jhipster: security: authentication: jwt: secret: secret gateway-prod.yml: |- # gateway application properties for the "prod" profile foo: bar: foobar
Troubleshooting Tips Permalink to "Troubleshooting Tips"
- If you are running All-in-one VM, make sure to run the following command before pushing docker images,
eval $(docker-machine env <machine_name>)
- If you face issues running StatefulSets or Services with persistent storage, make sure persistent volumes are properly initialized.
- If you face issues running StatefulSets, check the persistent volume claims. If PVCs’ take longer time than usual while initializing, try creating it manually.
- After running the generators, make sure you are in the chosen namespace oc project <namespace> before applying the oc commands.
- Image pulling for services like elasticsearch, registry, console etc,. for the first time will take some time as it needs to be pulled from public registry to the container registry. If any of the dependent services fail because of this, try deploying it once the services with which it is dependent on are up and running.
- Please make sure you have the necessary privilege (may require admin) to run scc service that is required to run some of the pods.