I am developing a simple command line application. I would like to use CloudBees to:
Git repo (OK, even a private one)
Jenkins Continuous Build (OK, trigger the build when I push to the repo, perfect)
Deploy to RUN#Cloud (OK, but painful SDK installation)
My question would be: is there a way to deploy a Java App (not a Web App) with the Maven CloudBees plugin ? (It is also to record my experience).
Running a raw Java container is documented: http://developer.cloudbees.com/bin/view/RUN/Java+Container
The bees-maven-plugin is documented here: https://developer.cloudbees.com/bin/view/RUN/MavenGuide . But the plugin does not seems to do all what the SDK can do. So I couldn't use it in Jenkins.
What I did is adding a "Script Shell / Post build step" in the Jenkins job. With the following script:
. /private/brnvrn/scripts/setup-sdk
bees app:deploy -a brnvrn/gdataaccess -t java -R class=com.brnvrn.test.Main -R classpath=gdataaccess.jar target/gdataaccess-1.0-SNAPSHOT.jar waitForApplicationStart=false
How to install the SDK in Jenkins is explained here: http://wiki.cloudbees.com/bin/view/DEV/Scripting+Bees+SDK+in+Jenkins and here is how to mount DAV directory: http://wiki.cloudbees.com/bin/view/DEV/Mounting+DAV+Repositories. (Just be aware that the files you upload in /private/ will be available in /private/$account_name/ ...
I managed to make it work and then realized that there is really no point to deploy a command line App to RUN#Cloud. Still I would like to known if the bees-maven-plugin would be able to do the job without all the SDK installation trouble.
The CloudBees maven plugin only supports deployment of WAR files. As an alternative, you can use the CloudBees Deployer plugin for Jenkins to setup a post-build action to deploy the JAR artifact (this is pre-installed in DEV#cloud Jenkins instances). You can also use the CloudBees SDK to deploy your JAR artifact (bees app:deploy -a APPID JAR_FILE)
Related
I have a maven project structured:
/root
/CommonProject
/executable1
/executable2
/subroot
/subrootCommon
/...
So far I am trying to just deploy executable1.
I wanted to the project to use Java 19, I am fine with Java 17 if it's easier.
When I activate cloud shell, I am able to:
Change $JAVA_HOME to jdk 17
clone project
maven package it
run it in cloud shell.
However my project has no mapping for "/", just specific endpoints like "/test/hello" and I do not see anything in WebPreview on port 8080.
I have tried different ways to deploy, I am not familiar enough with Docker, so I tried CloudRun with Cloud Build with trigger from Source.
Here lies my current problem - every build has failed so far. It is using jdk 11 which is a problem (or at least one of them).
I have tried also adding cloudbuild.yaml or local Dockerfile just to deploy jar built manually, but I am still failing.
+FROM openjdk:17
+COPY root/target/executable1-1.0-SNAPSHOT-jar-with-dependencies.jar /home/user/var/run/executable1.jar
+CMD ["java", "-jar", "/home/user/var/run/executable1.jar"]
I have done the same steps to deploy, which were shown in how-to-guides or available online labs, so I think the issue is with the fact that maybe buildpacks do not process correctly projects with dependencies?
executable1 and executable2 depend on CommonProject. Do I need to split my big maven project into separate projects, to build each of them individually?
I have tried Dockerfile, cloudbuild.yaml, something like project.toml.
I would like to deploy for now just 1 project, at one point in the future all executable projects from this maven.
I have a Jenkins job that uses a script to build my project. On the following line, the script fails mvn -e -X -Dgit='$git' release:prepare.
Because I want to search for the cause of this, I want to go to the Jenkins server and run mvn -e -X -Dgit='$git' release:prepare from the command line, to see if it works.
Does Jenkins store the projects' source code somewhere, such that I can go to that folder and call Maven?
If yes, then where?
Yes, It Stores the project files for the job by default at
/var/lib/jenkins/workspace/{your-job-name}
This is where jenkins suppose the project files to be present or it pulls it from a source before start working/building from it.
Quote from Andrew M.:
"Hudson/Jenkins doesn't quite work that way. It stores configurations and job information in /var/lib/jenkins by default (if you're using the .deb package). If you want to setup persistence for a specific application, that's something you'll want to handle yourself - Hudson is a continuous integration server, not a test framework.
Check out the Wiki article on Continuous Integration for an overview of what to expect."
From this Question on serverfault.
This worked for me:
/var/jenkins/workspace/JobNameExample
but, if your build machine (node) is a different than the one where Jenkins is running (manager), You need specify it:
/var/jenkins/workspace/JobNameExample/label/NodeName
Where you can define label too:
jenkins stores its workspace files currently in /var/jenkins_home/workspace/project_name
I am running from docker though!
I am building my war folder using
mvn clean install
And I am deploying the project using :
gcloud preview app deploy /{PATH}/appengine-staging/app.yaml /{PATH}/appengine-staging/index.yaml /{PATH}/appengine-staging/cron.yaml --version=version-7 --project=project1-test
The previous two steps requires the Staging yaml files using
appengine-java-sdk/bin/appcfg.sh stage <WAR-dir> <yaml-dir>
is there any way to do the staging step (without deploying ) using maven ?
Take a look at the recently released appengine-maven-plugin. You probably wish to use:
mvn clean package appengine:stage
Standard (Using) (Reference)
Flexible (Using) (Reference)
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.
What is the recommended/available approaches to remote deploying a Mule application to a remote Mule server? I'm using Maven for build btw.
I saw that the appkit can remote deploy to Cloudhub: http://blogs.mulesoft.org/using-continuous-deployment-with-cloudhub/
and theres a rest maven plugin for the management console but I'm using the standalone community edition and can not use either one. I also saw a cargo implementation on Github, but this only handle local deployments
I would write a script that:
scp the application to /tmp
remote mv the application to $MULE/apps
Moving a file being an atomic operation prevents potential issues of uploading directly in the /apps directory and have Mule pick-up a partially uploaded application.
"scp the application to /tmp" reminds me this! ...