Getting Started
We start by creating a very simple pass through proxy in Developer Studio using the echo service (http://localhost:8280/services/echo) as the endpoint. This proxy is stored in the 8WAYSPROJECT and has a Composite Application (C-app) called 8WAYSCAR.
There is nothing fancy about it, just that it is a simple proxy we can deploy. Invoking the proxy will echo a message that is sent to it. We will actually take this as a starting point so we will not go into detail as to how we create these artifacts or, even more highlevel, install WSO2 EI, Java and the Developer Studio tooling. Please see our other Yenlo blogs for this kind of information.
Beginning and end
There is a beginning and an end to deploying the CAR file. That beginning is something like Maven where a mvn clean install command will build the artifacts to deploy, this will create the zipfile (with extension CAR) that will be deployed. Throughout this blog the term ‘zipfile’ will pass by regularly often, this typically refers to the actual CAR file that will be or is deployed. A CAR file is nothing more than a specific collection of files inside a ZIP file hence the term zipfile.
The end is the carbonapps directory where the file will be stored. Between the beginning and the end there are eight roads as you can see from the image below.
We will use this CAR to deploy it in eight different ways;
- Adding / Redeploying it using Developer Studio
- Exporting using Developer Studio in carbonapps
- Building it using mvn install and copy to carbonapps
- Dropping it in the carbonapps directory
- Uploading it using the Management UI
- Building and deploying using Maven Deploy
- Deployment using admin services
- Deployment synchronization in a clustered setup
1. Adding / Redeploying it using Developer Studio
When you define a server in Developer Studio you can add/remove car files to the server. This can particularly speed up development of WSO2 services as this allows for fast redeployments of altered components.
The option of redeploying a car file is also available. In that case it will actually push a new CAR file to the server overwriting the previously installed CAR file (if it was there).
Developer Studio use its own build procedure that is not Maven driven. Developer studio packs all components selected in the CAR editor and creates and deploys the CAR file for you automatically.
2. Exporting using Developer Studio in carbonapps
You can export the car file to the desktop or directly into the carbonapps directory (not shown). This will trigger the deployment.
3. Building it using mvn install and copy to carbonapps
Building it using a mvn clean install or the car file and manually copying it to the carbon apps directory. The maven build will take some time, especially the first time since it needs to download dependencies. Also, keep in mind that all individual artifacts need to be built separately.
This has to do with the standard WSO2 project structure that is created when you create a WSO2 project structure using the developer studio.
4. Dropping it in the carbon apps directory
Dropping the file in the carbon apps directory will trigger deployment. In this Windows example, you see the directory and the CAR file.
The file will be picked up, in this case simply at startup, as can be seen at the top of this screenshot.
The proxy is now available in the Management UI when we open the list of services.
5. Uploading it using the Management UI
When we have the zip file we can actually deploy it in a very simple way using the management UI of the EI. This situation occurs for instance when you get a CAR file from someone else and simply need to deploy it to the server.
We go to the management UI (assuming local deployment i.e. http://localhost:9443/carbon) and sign in using admin/admin credentials. Click on Add Carbon application on the Main tab and select the CAR file.
You will get a message saying that it is uploaded.
After a minute or so it is actually available.
We delete the CAR file again using delete.
And again, after a minute or so it is gone.
6. Building and deploying using Maven Deploy
Building the CAR file and using Maven Deploy will directly send it to the server. This is done curtesy of the plugin developed by the Developer Studio team from WSO2. What you need to do is that you add the plugin to the POM file of the CaPP as follows:
<plugin> <trustStorePath>${basedir}/src/main/resources/security/wso2carbon.jks</trustStorePath> <trustStorePassword>wso2carbon</trustStorePassword> <trustStoreType>JKS</trustStoreType> <serverUrl>https://localhost:9443</serverUrl> <userName>admin</userName> <password>admin</password> <operation>deploy|undeploy</operation> </CarbonServer> <CarbonServer> ... </CarbonServer> </carbonServers> </configuration></plugin> |
As you can see you can deploy to multiple servers by indicating the servers as <CarbonServers> in the plugin. What you need to indicate is the path to the server’s truststore, the password, ServerUrl and the user Name and password as well as the deploy / undeploy operation.
In order to make it work you need to add two parameters to the POM file of the CaPP
<properties> <!--other lines are omitted --> <maven.car.deploy.skip>false</maven.car.deploy.skip> <maven.deploy.skip>true</maven.deploy.skip> </properties> |
We do a mvn clean deploy and the car file is deployed on the WSO2 server.
7. Deployment using admin services
The admin services are the soap based services that are used by WSO2 EI itself when services are invoked using the Management UI but also internally. Admin services are per default not available for use by you, to enable them to be used you need change the carbon.xml and to set the value of HideAdminServiceWSDLs to false.
<!-- If this parameter is set, the ?wsdl on an admin service will not give the admin service wsdl. --> <HideAdminServiceWSDLs>false</HideAdminServiceWSDLs> |
Starting the WSO2 EI with the -DosgiConsole parameter (sh integrator.sh -DosgiConsole or integrator.bat -DosgiConsole) you can list the admin services using the ‘listAdminServices’ command.
Using the service CarbonAppUploader(?wsdl) allows you to upload the car file using this soap based service. It is a secured service (with Basic authentication userid & password) and the car file as an attachment.
8. Deployment synchronization in a clustered setup
Finally, you can do deployment synchronization in a manager – worker Hazelcast setup. In that case a Subversion(SVN) repository is used and a deployed car file on the manager is pushed to the SVN repository and the workers are sent a message to retrieve the car file by syncing with the SVN repository.
This setup, or at least the principle of pushing deployments to the worker nodes can also be done using rsync or a fileshare structure by the way. Please see the WSO2 docs on how to setup such a master-worker setup and using the deployment synchronizer or filesystem-sync approach.
Conclusion
There are many ways to deploy a car file, but as you can see most of them are actually variations on a similar theme. Do you have any questions left? Don’t hesitate to ask them in the comment section.
Yenlo is the leading, global, multi-technology integration specialist in the field of API-management, Integration technology and Identity Management. Known for our strong focus on best-of-breed hybrid and cloud-based iPaaS technologies.
Yenlo is the product leader and multi-award winner in WSO2, Boomi, MuleSoft and Microsoft Azure technologies and offers best-of-breed solutions from multiple leading integration vendors.
With over 240+ experts in the API, integration, and Identity Access Management domain and over $35 million in annual revenue, Yenlo is one of the largest and best API-first and Cloud-first integration specialists worldwide.
