I am currently building a java web application (with netbeans).
I use Jenkins to create a release version with the following pipeline (for Jenkins):
Build -> Test -> Deploy (to a remote test webserver)
Build and Test are OK but I have a question about the deploy job.
The deploy job is currently taking my previously generated .war file and simply transfer it to a remote web server (with the "Deploy to container" plugin).
But I would like to change the database parameters of my web application first ! (in order to use another remote test database).
I would be glad to modify the java file with shell command but I can't because my .war is only composed of the compiled .class java.
So how could I change some of my web application java code (for database credentials) from the .war file before deploying it to the remote web server ?
If you have multiple environments which have different databases, then the best way to handle this would be application with command line parameters. You can modify your java application to read the command line parameters and use these parameters in application.
For example --dburl = <database url> --dbusername= <db username>
And the another way will be take these paramters from environment variable. And define these variables in the system where you are deploying the applications.
Related
I want to deploy a Spring Boot application on an OpenShift cluster that I want to monitor with elastic-apm, therefore, with the JAVA elastic agent.
I managed to deploy in a project an Elasticsearch instance, a Kibana instance and an apm-server.
Next to that, I also managed to deploy my Spring Boot application. For this I used the web console. I imported my project from GitLab, and chose the Java 8 image builder. However, using this method, I didn't find a way to launch my application by associating the java-agent elastic-apm-agent.
Locally, I run this command to start my application:
mvn package && java -javaagent:elastic-apm-agent/elastic-apm-agent-1.26.0.jar \
-Delastic.apm.service_name=ms-salarie \
-Delastic.apm.server_urls=http://localhost:8200 \
-Delastic.apm.secret_token= \
-Delastic.apm.environment=development \
-Delastic.apm.application_packages=com.leanerp.salarie \
-Delastic.apm.config_file=elastic-apm-agent/elasticapm.properties \
-jar target/salarie-1.1.3-SNAPSHOT.jar
Is there a way to override the command launched by the container of my application? Or another solution allowing me to use the elastic-apm-agent?
I am a newbie on OpenShift, so I don't fully understand all the concepts.
Ok, so the answer was adding this environment variable :
JAVA_OPTS_APPEND=-javaagent:{{path_to_elastic_apm_agent}}
this command allows you to launch your java application with options.
The Java agent allows multiple ways to configure it, one of which are command line system properties. Others include packaging an elasticapm.properties resource file or setting environment variables.
Check out the docs. Small excerpt:
Properties file: The elasticapm.properties file is located in the same folder as the agent jar, or provided through the config_file option. dynamic config.
Environment variables: All configuration keys are in uppercase and prefixed with ELASTIC_APM_.
Different option sources have different priority and precedence.
To attach the agent to a running JVM process (from within your application), you can use the API to self-attach.
There are 3 environments: Dev, QA and Prod. And in Github, 3 environment-specific-properties-files namely dev.db.properties, qa.db.properties and prod.db.properties are available in the spring based application code base.
There in the code base, inside the context.xml file, the url and passwords are mentioned in such a way to use the db properties from the environment specific properties file, during or after the deployment of the app.war file on the apache tomcat server running on each of the environments. Below, is the abstract view of context.xml and the env. specific properties files:
context.xml- url="jdbc:oracle:thin:##dbhost##:##dbport##/##dbservicename##" password=##dbpassword##
dev.db.properties and qa.db.properties are having their own dbhost, dbport, dbservicename respectively.
My question is, during or after the deployment onto the individual environments, how would the tomcat server, running on each of the environment, decides which environment specific file to pick. For e.g. suppose one need to deploy the app.war file, which consists of both the properties files, onto the QA environment, then how would the Tomcat server which is running on the QA environment decides that it need to pick the qa.db.properties file and not the dev.db.properties file?
Is it a case that the tomcat server's context.xml file in QA environment is configured in such a way to pick the qa.db.properties file only?
Thanks in advance!
I am using Jenkins version 1.644 and trying to deploy a web application to Websphere 8.5 application server. Jenkins job completed successfully and application is visible through admin console. After the first install, i manually configured Three application configurations namely,
1. Virtual Host
2. Context Root and
3 Modules
after these setup application comes up fine.
Now when i run the Jenkins Job again (option used is Install/Update application), it overrides all the configurations.
Please Let me know how to keep the configurations after each build from Jenkins.
Websphere Plugin Configuration
You can create a build deploy job which will call wsadmin tool and there you can pass parameter in key value pairs
Here is an article which talks about how to build job with parameterized configuration.
http://www.touchdownconsulting.nl/2011/03/building-and-deploying-websphere-applications-with-jenkins-ci/
I have not tried this but looks like it suits your requirement.
Hope this helps!
Current Jenkins Websphere deploy plugin (1.3.4) version does not allow to pass
1. Virtual Host
2. Context Root and
3. Modules
I created a Jython script using AdminApp WAS Utility and updated these parameters
AdminApp.edit("appname", ['-MapWebModToVH', [["appname", "appname.war,WEB-INF/web.xml", "api_host"]]])
AdminApp.edit("appname", ['-CtxRootForWebMod', [["appname", "appname.war,WEB-INF/web.xml", "/appname"]]])
AdminApp.edit("appname",['-MapModulesToServers', [["appname","appname.war,WEB-INF/web.xml","WebSphere:cell=appcell01,node=node12v,server=web2+WebSphere:cell=Cell01,node=node11v,server=web1+WebSphere:cell=Cell01,cluster=api-cluster"]]])
AdminConfig.save()
Used Jenkins Remote SSH Plugin to invoke this script.
I am in process of moving configuration parameters out of Java application. I discover that the best approach is to extend your classpath and use .properties files (leave ZooKeeper alone for another requirement).
So my WAR file no longer have any hosts/IPs/URLs, users/passwords.
DevOps distribute configs manually across test, stage, stable installations.
Now time for Jenkins to run tests. But they fail as there are no required .propeties files in classpath.
How can I load this config files to Jenkins and how to make in available in test classpath?
maven-surefire-plugin allow extending classpath and passing system-properties.
So only question how to get separate directory in Jenkins hosting server and load files to this directory and create alias/placeholder/envvar per build job to refer to this path in build config.
This job can be done with SSH access, but I think that this is "wrong way". I expect that this can be done via Jenkins UI (any manager can upload file in WEB browser).
UPDATE I have no requirements for distributed slave/master builds but it whould nice to have solution that migrate configuration files to slaves automatically...
In this way sshing to host or ftp/scp - bad thing.
I read most of Jenkins docs, ask at mail list and IRC. Yea - Jenkins community is silent. At docs I found link to Config File Provider Plugin, after that I visit http://builder.evil.com/jenkins/pluginManager/available page and look for config keyword.
There are a lot related plug-ins with various usefulness to my subject (most useless first):
https://wiki.jenkins-ci.org/display/JENKINS/Envfile+Plugin - This plugin enables you to set environment variables via a file.
https://wiki.jenkins-ci.org/display/JENKINS/Credentials+Binding+Plugin - Allows credentials to be bound to environment variables for use from miscellaneous build steps.
https://wiki.jenkins-ci.org/display/JENKINS/Environment+Script+Plugin - Allows you to run a script before each build that generates environment variables for it.
https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin - This plugin makes it possible to have an isolated environment for your jobs.
https://wiki.jenkins-ci.org/display/JENKINS/Copy+Data+To+Workspace+Plugin - Copies data to workspace directory for each project build.
https://wiki.jenkins-ci.org/display/JENKINS/Copy+To+Slave+Plugin - This plugin allows to copy a set of files, from a location somewhere on the master node, to jobs' workspaces. It also allows to copy files back from the workspaces of jobs located on a slave node to their workspaces on the master one.
https://wiki.jenkins-ci.org/display/JENKINS/Config+File+Provider+Plugin - Adds the ability to provide configuration files (i.e., settings.xml for maven, XML, groovy, custom files, etc.) loaded through the Jenkins UI which will be copied to the job's workspace.
Only last plug-in - Config File Provider Plugin allow editing configs via Jenkins WEB interface. And it have brother - Managed Script Plugin - for uploading/managing/editing custom scripts. No question now I use Config File Provider Plugin!
You should keep the configs required for the tests together with the rest of source code, so that after compilation, your unit tests can run.
After deploying the .war, the DevOps team should overwrite the in-war configs with whatever per-environment configs that they have.
So, I'm writing the build and the deploy scripts. To create the build, I used ant. The continuous build is done with Jenkins.
The build generates 3 different artifacts:
The war file
A zip with layouts
A zip with images
So far, so good, but now I need to write the deploy script, which should:
Deploy the war (artifact 1) to the tomcat running at server 1
Place the artifact 2 at server 1 in a specific directory
Place the artifact 3 at server 2 in a specific directory
So I was talking with my colleague and he said that we should also generate an artifact (maybe deploy.xml) that deploys these artifacts when placed at the correct server.
So there would be another script, that would:
Download the jenkins artifacts
scp to each server and place the deploy.xml there
remotely invoke the deploy.xml
What makes me a little uncomfortable is the act of having the deploy.xml as a build artifact. The motivation behind this would be to be able to make a deploy without needing to have access to the VCS repositories, so a build would be self-contained, ie, any build could go into production only with what was generated by Jenkins.
Where should the deploy scripts be placed? Should they be only at the VCS or should they be build artifacts too?
Please provide if any sample deploy scripts
I wrote my own deployment framework, consisting of different shell, batch, python, and .... scripts. It neatly separates environment information from application information and allows me to quickly update deployment information and add new apps or environment. However, the orchestration of the different parts is done by Jenkins. When just copying files to a Windows server, my Jenkins master (running on Windows) just copies the files to a network share that exposes the target directory. Services I can restart remotly using sc.exe. When crossing the borders to AIX, I use jenkins slaves that are started via ssh on the target system. So distribution is managed by Jenkins. The actual work is done by the scripts.