We Keep Coding

Deploy maven multi module project in GC

I'm new to google cloud and I need to deploy my java application there.
Currently it consists of 1 one web-module and directory structure looks like this:
clinic_project
acms-frontend
pom.xml
pom.xml
And start script:
#!/bin/bash
nohup mvn clean install
serv=acms-frontend
cd $serv
nohup mvn spring-boot:run -Dspring.profiles.active="dev" -DAUTH0_CLIENT_ID=".." -DAUTH0_CLIENT_SECRET=".." -DACMS_CRYPTO_KEY=".." -DACMS_NODE_NAME="n/a" -DACMS_POD_IP="n/a" -DACMS_POD_NAMESPACE="n/a" -DACMS_POD_NAME="n/a"
Inside web-module I have .yml file with default port and other variables.
I've installed gcloud SDK and understand how I can deploy single module application.
But how can I tell google cloud to deploy my multi-module project with commands sequence from script?

If you want to deploy multiple modules, you can do so with the following command: gcloud app deploy ~/my_app/app.yaml ~/my_app/another_service.yaml as mentioned in the gcloud app deploy documentation examples.
Make sure to add the module/service name in the app.yaml files as mentioned in this other document, otherwise you may run into some naming issues with them.
Hope you find this useful!

Deploy .war file in docker container: No main manifest attribute in app.war

I have a .war-file of my java application and would like to deploy that to a docker container.
My Dockerfile looks like this:
FROM java:8
EXPOSE 8080
ADD /App.war app.war
ENTRYPOINT ["java", "-jar", "app.war"]
I have my App.war in the same directory.
When I want to run it with the following command:
docker run -p 8080:8080 -t app
it throws the following exception:
no main manifest attribute, in app.war
However, when I inspect app.war, there's a manifest in /META-INF/MANIFEST.MF stating the following options:
Manifest-Version: 1.0
Start-Class: com.package.app.AppMainClass
Spring-Boot-Classes: WEB-INF/classes/
Spring-Boot-Lib: WEB-INF/lib/
Spring-Boot-Version: 1.4.0.RELEASE
Main-Class: org.springframework.boot.loader.WarLauncher
So as far as I understand the error message it states that a Main-Class attribute is missing in the manifest (which is impossible because it's there).
I have also tried adding the real class as Main-Class.
That led to the same error.
Can someone please help me back on track?

First of all don't build a spring boot project as WAR. You would only need WAR if you had some old ancient project which forced you to deploy the app to a web server/servlet container. You'll need to remove war related logic from your build script.
Second. Make sure you're building the project correctly. If it is gradle, you need to build it with ./gradlew build, for maven use mvn package. That will package your archive as an uberjar - including all needed dependencies and making the proper archive structure.
Find more details on how to put a spring boot application to Docker in the user guides.
If and only if by some strange occurrences you need to build it as WAR and run it as an executable archive make sure you do it using the war-plugin provided by spring boot (not the built in war plugin). That's the only working way to build an executable war archive.

Dockerfile best practice regarding Nexus artifacts and build instructions

I am sort of new to Docker and I am trying to understand some best practice recommendations regarding the build process in the Dockerfile.
I know that for a traditional JAVA application, we will typically use maven to pull dependent libraries from Nexus repository, source code from GIT or other CM and then build the application. Finally, the output .war file will again be stored in a tagged release folder in Nexus repository to be copied over to different environments (dev/qa/production etc.). But one challenge that remained was inconsistencies between the different environments and we are trying to use containers to solve that problem - meaning once it is tested in a container, we can just push that container up the pipeline to different environment and they should work without any issue since the container includes the environmental dependencies plus everything the web application needs as a package.
But my question is regarding the Dockerfile. So is the Dockerfile supposed to replace the function of Maven ? Should it include the complete build instructions for the application ? I know we still pull the source code from GIT and dependent libraries from Nexus by referencing them in the Dockerfile but where does the output .war file go ? Is there still a need to store that in Nexus ? Since we can version the Docker containers through some of the tools such as OpenShift and roll back as necessary, what will be the purpose of storing the output .war file in Nexus.
One scenario I can think of is related to patching. When an OS/security patch is available, we update the base Docker image and rebuild the Application specific Docker image to apply the patch. But what happens to the application in this case ? Do we need to rebuild the application every time we need to apply a patch ? If application build instructions are embedded into the Dockerfile, and we have to rebuild the application container image, doesn't the application also get rebuilt automatically ? Or can Dockerfile only execute certain instructions - skip build application part if no code change or when you tell it to skip etc.) . Should Dockerfile reference to a Nexus repository for the application .war file so in the case the .war file doesn't change, it doesn't rebuild ?
I will appreciate any help.
Thanks.

I would say it'd be a good idea to version control the application build artifacts (war, jar etc.) separately in Nexus and not doing the application build process as part of the docker build. We have a similar pipeline and the way we do it is this:
Checkout source code from SCM
Build with Maven and upload the build artifact to Nexus for version control
Inject the built artifact in the base Docker image(i.e. openjdk) as part of the docker build step
Push the image to the registry
CD kicks in and deploys the latest image
Should Dockerfile reference to a Nexus repository for the application .war file so in the case the .war file doesn't change, it doesn't
rebuild?
Yes, that's correct, you can use curl command in your Dockerfile to download the artifacts from Nexus, no need to rebuild application everytime you make change to your Dockerfile.

How to Dockerize a tomcat app

I am trying to dockerize some Tomcat application but I never touch Java application before so the lack of understand it makes it really hard to understand what should I do.
So far I have this but it doesn't work and I don't if it's the correct path as well
FROM tomcat:6
ENV APP_ROOT /app_name
RUN apt-get update && apt-get install -y default-jdk
COPY . $APP_ROOT/
WORKDIR $APP_ROOT
RUN jar -cvf app_name.war *
# this fail for some reason, when I do `ls` the file is there but if fail to copy it
COPY app_name.war $CATALINA_BASE/webapps/app_name.war
I am just going on loop on this because I don't understand and Google Search do not help me that much (I don't know how to ask).
Should I use the jar command in the build? If not, I guess I have to build it locally and just make sure that the .war is there right?!
How the building of the Java with Tomcat app works? and How to integrate with Docker?
Sorry for being too generic but I don't understand anything about Java

Looking at your code this is what I could gleam:
You have some java files stored in current directory (.)
When you call COPY you copy all these contents to /app_name
You create a .war on the file
There are some things to note, first is that the app_name.war is not on the host disk, it is currently inside of the docker file system. What this means is that you cannot COPY the .war.
What you are really after is this: RUN cp app_name.war $CATALINA_BASE/webapps/app_name.war
This would look like the following:
Dockerfile
FROM tomcat:6
ENV APP_ROOT /app_name
RUN apt-get update && apt-get install -y default-jdk
COPY . $APP_ROOT/
WORKDIR $APP_ROOT
RUN jar -cvf app_name.war *
RUN cp app_name.war $CATALINA_BASE/webapps/app_name.war
Adding the docker COPY reference here as it explains the command in detail. It might also be helpful for you to make a script called provision.sh, then do something like:
COPY provision.sh /tmp/provision.sh
RUN sh /tmp/provision.sh
That way you can put all your building, configuring and other in a single script that you can test locally (again if it helps)
EDIT: Adding mention about building locally and copying into dockerfile
You can build the .war on your machine, use COPY to put is on the machine.
Dockerfile
FROM tomcat:6
ENV APP_ROOT /app_name
RUN apt-get update && apt-get install -y default-jdk
COPY app_name.war $CATALINA_BASE/webapps/app_name.war
WORKDIR $APP_ROOT
The above copies the file app_name.war then add it to the filesystem of the container at the path $CATALINA_BASE/webapps/app_name.war. So for that you do this:
Build the .war on your machine with java
Put .war in directory with Dockerfile
COPY app_name.war into the container's filesystem

You can try to do this "by hand" before trying to automate it, it should help to understand the process. You don't need to extend a tomcat official image to be able to deploy a war on a dockerized tomcat, you can use the image directly if you don't need to customize permissions and users (in production, you need).
If you need Tomcat 6.x because your webapp implements servlet API < 3, do this :
sudo docker run --name tomcat --detach --port 8080:8080 tomcat:6
Now, your Tomcat is running in background (--detach), waiting for a deployment. You've exported port 8080 from the container and mapped it to port 8080 from you host, so the app will be available at http://localhost:8080/ on your host.
From now if you copy your .war in /usr/local/tomcat/webapps into the container, the app will be deployed :
sudo docker cp app_name.war tomcat:/usr/local/tomcat/webapps/

I don't use docker, I use a similar AWS product called codedeploy for provisioning instances, so I tell you what I do for Tomcat setup in my provisioning scripts. Should be easy to port to docker as just bash comands.
1) Build the WAR
Most java applications these days are built using Maven but Gradle is catching up. Maven and the WAR plugin are used to turn java code into a WAR file which you can deploy on Tomcat. But it looks like you already have the WAR built by someone else? Either way, you dont run the war directly, you put it in Tomcat, unless you've bundled Tomcat into the app, in which case it would be a JAR but lets not talk about that....The simple solution is build the war from java code using a build tool like Maven or Gradle. By build, I mean turn it from source code to binary.
2) Install Tomcat
yum install tomcat6,7,8 etc etc (Whichever version you need)
Then turn it on
service start tomcat8
3) Deploy the war
To run the war place it in the webapps folder of the Tomcat installation. I generally like to shut tomcat off when I do this but you can do it while its running. After a few seconds the WAR, which is really just a zip file, will be exploded/unzipped to create a directory.
4) Accessing the application/site
If you rename your war to ROOT.war then you can access the applicaition at http://localhost:8080 if your configuration is to have it listen on 8080. If you war is named pets.war then your webapp URL would be http://localhost:8080/pets. You configure which port for Tomcat to listen on in the server.xml file in its conf folder.
Most Important
Tomcat documentation is very good once you know what to look for. The primary configuration files are web.xml, context.xml, and server.xml. The central tomcat guides explain each component https://tomcat.apache.org/tomcat-7.0-doc/setup.html you just need to find the doc that corresponds to your version of Tomcat.

How to hot deploy sources with gradle into tomcat7?

Does anybody know a gradle 'hot deployment' plugin (or middleware as shell script) which is coping files from source folder directly into project folder at tomcat's webapps directory (not embedded server like gretty or gradle tomcat plugin; version7, environment independent)?
At the end I want to realize a smart dev workflow to (re-, un-) deploy a java web application during code crafting. I'm searching for something like grunt watch tasks.
Scenario: Java web application with self contained, executable jar file at WEB-INF/lib folder.
register watcher tasks on top on gradle task
java source is changed
tomcat stopped
remove jar file at WEB-INF/lib folder
deploy jar file
copy jar into WEB-INF/lib folder
(delete all log files)
start tomcat
Restart tomcat is not needed if static sources are changed (e.g. JSP, JS, ect.).
Solution
I thought about our working practices at the office. My colleagues and I, we program on Windows machines and we use a key map configuration in IDEA to start and stop our local installed Tomcat.
The easiest way for me is to define a user related CATALINA_HOME system environment variable which references the path to Tomcat server.
CATALINA_HOME = C:\Program Files\apache-tomcat-7.0.56
I define a deploy task which copy compiled war file into webapps folder ((re)start Tomcat manually via IEDA).
task deploy(type: Copy) {
def WEBAPPS_HOME = System.getenv()['CATALINA_HOME'] + '/webapps'
from 'build/libs/app.war' into WEBAPPS_HOME
dependsOn war
}
Nobody need to change Tomcat path inside build.gradle file or there is no additional user.config file which is ignored by git.
But I don't like manual Tomcat handling and it is unusual to work with environment variables on Mac's.
So, I decide to search an embedded Tomcat server as Gradle cargo plugin for local development. It is recommanded from Benjamin Muschko (Gradleware Engineer) at How to use local tomcat?... and he describe the differences between Cargo or Tomcat plugin....
Setup of this plugin is quite easy. I don't need to explain.
Nobody need to install there own Tomcat and everybody work with same version server.
For our nigthly build I use the power of Gradle wrapper as Jenkins task configuration.
I execute a wintods batch command.
cd "%WORKSPACE%\app"
gradlew.bat clean build

I use Jenkins to manage deployments for our applications.
There are a number of plugins which help with such tasks along with having the ability to write your own scripts.
Jenkins is highly configurable so you are able to adapt it to your own needs.
Jenkins URL