Deploying from remote server

[sorenlloyd]

I have been using WDT for a couple of years but we are now refactoring to deploy from a kubernetes pod to, hopefully, remote networked, weblogic servers.

The container I have i am running from is from a 12.2.1.3 image but does not itself contain the domains that i am deploying tool. I used this image as it has wlst which is required.

When i do an online deploy it tells me ...

1. WLSDPLY-20008: deployApps argument processing failed: Supplied Domain Home directory /opt/app/Oracle/Middleware/user_projects/domains/patch was not valid: Directory /opt/app/Oracle/Middleware/user_projects/domains/patch is not a directory

This is true locally but not true on the remote server which i am deploying to.

Is it possible to use the tool in this manner, I assumed so due to the use of admin_url to talk to the server.

[robertpatrick]

@sorenlloyd This limitation is for the same reason that we used to only support online discovery from the admin server machine--we need access to the domain directory to collect (and, in your case, lay down) any binaries for/from the archive file. As a first step, we added support for remote discovery by simply skipping the archiving of the binaries. At some point, we would like to add support for remote collection of the binaries (probably relying on SSH/SCP to accomplish this).

We will certainly consider your use case and how it fits in with these remote scenarios. In your use case, what types of changes are you making to the remote server? Does it involve updating binary files (e.g., an application)?

[httpants]

I also would like the ability to run commands remotely, like discoverDomain and updateDomain. If the creation of weblogic resources, like datasources, jms modules etc. was separate from deployment of applications and the creation of resources could be done remotely without requiring the specification of domain_home, that would make weblogic-deploy-tooling more powerful for us.

We have a CI/CD build server that uses a domain model file to update domains in different environments without having to run on the same server as each domains admin server. A work around I'm using, is to create a basic dummy weblogic domain on the build server and specify that as the domain_home when running weblogic deploy tooling, while configuring the admin_url to point to the real domain that I want to run the model file against. After creating the domain resources using updateDomain, we then deploy wars into the domain in a separate step, using the weblogic-maven-plugin deploy goal, specifying upload=true, so the war gets uploaded to the remote servers for us (https://docs.oracle.com/middleware/12213/wls/WLPRG/maven.htm#GUID-C67AB945-8044-4363-8C6E-2F9206525FED). It would be nice if weblogic-deploy-tooling could support this scenario without the work around.

[robertpatrick]

@httpants Have you tried the remote discovery support that was added a few months back? Any feedback on it?

[httpants]

I don't use discoverDomain very often so last time I used it i had to specify domain_home, but will keep in mind it now supports remote discovery. I mainly use createDomain and updateDomain.

[robertpatrick]

@httpants with remote discovery, the -domain_home parameter is still required so that WDT can use it to tokenize paths recorded in the model but physical access to the directory is no longer required.

We would like to increase support for remote operations but are looking for feedback to make sure we are addressing the right problems. We have also discussed allowing customers to leverage SSH connectivity to augment remote operations to remove the limitations around binary collection/deployment.

[httpants]

Binary collection/deployment isn't a feature we currently use. We mainly use weblogic-deploy-tooling to create/update the domain and all the resources, then deploy the binaries separately. We mainly deploy OSB projects (which isn't supported by weblogic-deploy-tooling) and WAR files. We could use weblogic-deploy-tooling for the war files but since deploying OSB projects is a separate step already, we also use a separate step for deploying the war files that also allows us to deploy to remote servers without requiring ssh.

[robertpatrick]

WDT 3.0 released so closing this issue as resolved. Please open a new issue if you encounter problems using WDT 3.0.