Public URI and cloud deployment question
We are installing RTC, RQM, and RRC on a cloud instance for training and demonstration purposes. We will spin up a new instance when needed and terminate it when finished. The question is, what value to use for the public URI? Each VM instance will have a new URI.
Can we change the public URI after spinning up an instance if we have not deployed any applications (and therefore no linked data)? Many thanks. |
5 answers
At this point, server URLs cannot be changed. We are looking at lifting this restriction in subsequent release, but until this is available, you need to resort to DNS tricks to keep current URLs alive.
Are you intending a generic URL for your deployment, and multiple instances supporting it (one after each other), or rather separate deployments (one per VM instance). What exactly are you meaning by "spinning up an instance but not deploying any apps" ? |
|
Thank you for the response. We installed RTC/RRC/RQM on a server in Amazon's cloud (AWS). And we also install the JKE Banking lifecycle project example. Then we save off that server so we can start new instances any time we wish. But those new instances will have different URLs.
So they question is, what do we use for the public URI? Seems like we need to select "localhost" so the new servers can see themselves. But we are concerned about access from outside the server and than also about any cross-product links. For example, will the JKE Banking example links continue to work? Thanks for any comments and/or recommendations. |
We are currently not planning to support cloning instances in this manner. There is specific instance data above and beyond the public URL for each setup. This is discussed further in:
174975: Track issues with repository cloning and colliding UUIDs https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/174975 We are, however, adding better support for scriptable automated setup, to allow for activation of an instance post-install. So you could create an instance after the bits are installed but before setup is run or JKE Banking is set up, and automate those later steps. See also: 170934: Automate support for JTS/Application setup https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/170934 Would this work for your use cases? |
Ian Barnard (2.3k●7●14)
| answered Jan 24 '12, 5:52 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
One very hacky/unsupported ways of getting something working (but clearly not for production!) which I've used on IBM SmartCloud Enterprise and should also work on AWS:
1a. In the reference image, configure JTS using a dummy hostname e.g. dummy.jke.com and put an entry in the hosts file in the image which resolves dummy.jke.com to 127.0.0.1 1b. When a user gets an instance from the image, edit the user's local hosts file so that dummy.jke.com resolves to the actual instance IP address The other way to do it is that the reference image just has everything installed but JTS is not configured - then the first steps for each new instance is to configure JTS using the actual hostname of the instance HTH Ian |
I would recommend this latter approach. If execution time is an issue, this may be optimized by precreating the database tables. See https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/190699 (190699: Perform Cloud server installation in 2 steps, with pre-creation of the DB) |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.