Skip to main content

JBoss BRMS - 在Open Shift 上安裝BRMS

前幾個禮拜跟朋友去聚會,因為大家都是一堆IT宅,不可避免地聊著聊著,就聊到大家的公司,最近在做些什麼... 出乎意料之外的,發現大家對雲端的Paas 都很有興趣哩~
還有的朋友把程式也放到雅馬遜的EC2 上。。 其實,EC2 的底層也有JBoss 呢!

========================================
=====vvv在安裝之前,請先確定以下都安裝好了vvv=====
========================================
1.到 OpenShift 註冊一個帳號
(這個因為只是普通的註冊,就不多說了。。。)

2. 在電腦裡面安裝 rhc的執行指令

(等我以後有空再寫,其實不難,請到官網上看...)
========================================

因為OpenShift 上面跑的應用程式平台是JBoss EAP 6, 這間接證明了一件事,哈,那就是,BRMS 是可以跑在 JEAP 6 上的喔!
好,廢話不多說,

1. 建立一個Application (應用程式)

rhc app create -a brms53 -t jbosseap-6.0


2. 把eric 提供的程式碼放到Open Shift幫你自動建立的 github repo 裡面

3. 把程式放到server中

以一般JBoss 的安裝思維,這樣應該就裝好了... 但是... 世界當然沒有這麼美好,因為畢竟是Openshift, 所以還是要有一些單獨調整的設定,但是希望總有一天可以接自動化就安裝好了...

設定筆記

這個Project要感謝 Kaushik Bhattacharya,大家有空可以去他的專案總部大聲說謝謝捏: https://github.com/kbhattac/brms53

1) 設定jboss-brms 裡面的 jackrabbit repo, 在jboss-brms.war 中的 components.xml。所以要先找到你自己的UUID,方法如下


rhc app show -a brms5.3



找到後,請將UUID 寫在你的components.xml裡面。





2) 到 designer.war 裡面的 profiles/jbpm.xml 修改host 的 ip 位置,請ssh 進去,跑cmd 模式執行 export $OPENSHIFT_INTERNAL_IP 去找到你的IP 然後放到XML裡面。



3)因為記憶體有限,有的時候,同時部署jboss-brms.war 跟 designer.war 會失敗,所以,我們讓jboss-brms.war 先自動部署。等jboss-brms.war 部署完畢後,我們再把designer.war.dodeploy.delayed 重新命成designer.war.dodeploy,這樣就會自動觸發系統重新部署了。

$ ssh [UUID]@brms53-$your_domain.rhcloud.com
$ mv brms53/jbosseap-6.0/standalone/deployments/designer.war.dodeploy.delayed  /
     brms53/jbosseap-6.0/standalone/deployments/designer.war.dodeploy

如果要看designer.war部署的狀況,可以用以下方式看log

$ rhc-tail-files -a brms53

成功之後你就可以到下列網址看到你的BRMS了! 

http://brms53-$your_domain.rhcloud.com/jboss-brms

成功後你就可以把import_demo_to_brms.zip 這個檔案透過brms的console中的 Administration -> Import Export tab匯入使用拉!

Eric的原版英文網頁網址:http://www.schabell.org/2012/07/jboss-brms-53-running-in-openshift.html

Comments

Popular posts from this blog

Red Hat Fuse - Announcing Fuse 7 Tech preview 3 release.

Red Hat Fuse 7.0 technical preview three is out today! On the pathway to become one of the best cloud-native integration platform, Fuse gives developer freedom to choose how they want to develop the integration solution, where they want to deploy it and capabilities to address new integration personas that do not have development experience.
By supporting the three major runtime, developer is free to work on the runtime of their choice.By supporting standalone and cloud deployment, it simplifies the complexity to distinguish between these environments, allowing application to deploy freely among the environment of your choice. All levels of developers are welcome, you can either dive deep into creating customize complex integration logic, or using the new low code platform to quickly build a simple integration. In this Tech Preview release you get it all.
Fuse StandaloneSpring-boot for microserviceKaraf 4 for OSGi loverJBoss EAP for JavaEE developersFuse on OpenShiftPlugins for easy co…

JBoss EAP 6 - 效能調校 (一) DataSource 的 Connection Pool

效能沒有什麼Best Practice, 反正能調整的就那些。 通常,一個程式的效能大概有70-80% 都跟程式怎麼寫的其實比較有關係。

最近我最疼愛的小貓Puji 因為膀胱結石開刀的時候過世了,心情很差請原諒我的口氣沒有很好,也沒有心情寫部落格。

Puji R.I.P.

=======================正文=======================

這個題目很多人叫我寫,可是這題目好大,這分明就是整死我咩~
所以我會分幾段慢慢寫。

JBoss 的 SubsystemDatasource WebWeb Service EJB Hibernate JMSJCAJVM 調校OS (作業系統)

先來看一下 DataSource Subsystem, DataSource 的部分主要是針對Connection Pool 做調校。

通常,程式都會需要跟資料庫界接,電腦在本機,尤其是在記憶體的運算很快,但是一旦要外部的資源連接,就是會非常的耗資源。所以現在的應用程式伺服器都會有個Pool 放一些先連接好的 資料庫connection,當程式有需要的時候就可以馬上提供,而不用花那些多餘的資源去連接資料庫。

這就是為什麼要針對Connection Pool 去做調校。

以下會討論到的參數,都是跟效能比較有關係,Datasource 還有很多參數,像是檢核connection 是否正確的,我都不會提到。如果你追求的是非常快速的效能,那我建議你一個檢核都不要加。當然,這樣就會為伺服器上面執行的程式帶來風險。這就是你要在效能與正確,安全性上面的取捨了。 (套句我朋友說的話,不可能又要馬兒好,又要馬兒不吃草的..)

最重要的調校參數就是 Connection 的 Pool 數量。(也就是那個Pool 裡面要放幾條的connection.) 這個參數是每一個應用程式都不一樣的。

min-pool-size 

Connection Pool 最少會存留的connection 數量

max-pool-size 

Connection Pool 最多可以開啓的 connection 數量

prefill

事先將connection pool 裡面建立好min-pool-size 的connection.

我的建議是觀察一下平常程式要用到的量設定為 min-pool-size 。
加上…

Fuse - Contract First API Design with Apicurio and Fuse/Camel - Part One

This is part one of my two-article series that demonstrates the approach of implementing contract-first API design using Apicurioand Red Hat Fuse.

It covers how to create an OpenAPI standard document as the contract between API providers and consumers using Apicurio. It also shows how to quickly create mock tests using Red Hat Fuse.

There are two common approaches of creating these APIs.
Code FirstContract First Coming from a old time ESB developer, these are not new. We have been doing this forever. Before, it was the WSDL that define the contract of the service. we were doing a lot more code first, for me it's simply because it's much easier for me to write couple of Java classes and generate the WSDL for my consumer. 

It's often pretty straightforward if the consumer of your application has finalized how they want the service to be like. But you and I all know this is not often the case. So I had to go back to my code, and make the changes accordingly and pray I did not …