I have been trying to deploy Talend Agent as app in PCF, I literally have no idea about Talend. However for PCF guy, its an java jar file for me what i got from DATA team.
I am getting no buildpack supported error. I also tried passing java buildpack by command but failed again with incompatible buildpack.
Error: No container can run this application. Please ensure that you've pushed a valid JVM artifact or artifacts using the -p command line argument or path manifest entry. Information about valid JVM artifacts can be found at https://github.com/cloudfoundry/java-buildpack#additional-documentation.
Failed to compile droplet: Failed to run finalize script: exit status 1
I was expecting this to be deployed as an App which i can access.
Do we have any one who can help me with this?
The CF Java buildpack expects a Java jar file to have certain characteristics in order for it to know how to execute the code in the jar file. The most common characteristics are a self-executable Spring Boot app, an app containing a Main class, and an app containing Tomcat.
I don't know anything about the Talend Agent, but a typical Java agent jar file is not meant to be executed as a stand-alone app. An agent is meant to be installed in the JVM used to run an app, in order to instrument the JVM and/or the app. An typical agent jar file won't have any of the execution entry points recognized by the CF Java buildpack, and therefore the buildpack will reject it with an error message similar to the one you show.
The CF Java buildpack does understand how to install several specific agents (listed under Standard Frameworks in the buildpack docs) into the JVM when an app is deployed. The Talend Agent is not currently in this list. If it is in fact a typical Java agent jar file, you would have to modify the Java buildpack to add support for it.
Related
I get the above error after running mvn -DskipTests package appengine:deploy. Here's the whole error:
Exception calling IAM: There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff. The request's ETag '\007\005\364\274\033.\262\307' did not match the current policy's ETag '\007\005\364\274\033\177\220\315'.
From my reading, this occurs when there multiple policy changes at the same time. The other questions I've seen throw this error in regard to a POST request but this is to do with an appengine:deploy
What IAM policy does the service account need to work?
This is the IAM account that I believe was created by the appengine:deploy process and it's permissions:
Note - I don't think it's applicable but I added this deploy to appengine step to a Spring Boot app speakiong to a Postgres db.
EDIT
As mentioned in the comment, #Robina's answer has moved me along but not the logs show this error:
UnsupportedClassVersionError: org/springframework/boot/loader/JarLauncher has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtome only recognizes class file version up to 55.0
But setting the java version to 17 throws a build error; here's my appengine.yaml:
runtime: java11
instance_class: F1
EDIT 2
I came across this while reading through the Google guide here which said:
Deploying an executable JAR
Use any build framework to build an executable JAR locally, then do one of the following depending on whether you created an app.yaml file for your app:
If you created an app.yaml file:
Copy the file into the same directory as the executable JAR file you created.
From the directory that contains the app.yaml and your JAR, enter the following command:
gcloud app deploy
gcloud app deploy will create an app.yaml file that contains the
minimum settings, using all default values.
I thought, why not? So I deleted the appengine folder and its app.yaml and then ran the command from above, minus the jar:
gcloud app deploy
After, probably 10 minutes of the command running the app was deployed and points to the Postgres database without any problems. Thanks #Robina for the help!
The service account must have the App Engine Deployer role in order to deploy an application to App Engine. The IAM policy needed for the service account to function depends on what it is used for. Your application is probably being deployed to Google App Engine using the service account if you are using appengine:deploy.
A gcloud command example for granting the role:
gcloud projects add-iam-policy-binding [PROJECT_ID] --member=serviceAccount:[SERVICE_ACCOUNT_EMAIL] --role=roles/appengine.deployer
[PROJECT ID] and [SERVICE ACCOUNT EMAIL] should be changed to reflect your project ID and service account email, respectively.
I have two SAM applications, both of which have a set of Python Lambdas in common. I have a different template file for each application.
When I run sam deploy for the first one it correctly deploys the Lambdas with their dependencies. For the second it only deploys the application code.
I can see all the dependencies correctly there in the .aws-sam/build directory.
Using --debug doesn't give me any useful information.
How do I go about debugging this?
Should the zip files that it deploys be available somewhere on my local system, and if so where?
i have a Spring Cloud Task fat jar that i have successfully deployed to SCDF running on PCF. i have created a definition for it and can therefore run it from the dashboard. fwiw it reads and writes from a database using Spring JDBC.
i'm trying to now set it up to run in a scheduled way and am having issues. i created a stream with a triggertask source and a task-launcher-local sink, and have configured the triggertask URI to point to the fat jar (via http, using a staticfile PCF pushed app).
the dashboard shows the two PCF apps (one for triggertask, one for task-local-launcher) both starting successfully, and it all runs, but the task fails every time with the error:
Caused by: java.io.IOException: Cannot run program "java" (in directory "/home/vcap/tmp/spring-cloud-dataflow-5903184636016162160/Task--582903409-1502669137014/Task--582903409"): error=2, No such file or directory
from what i can tell and surmise, the PCF app running the stream tries to fork and exec a java call, but since java is not in the path for PCF app containers i get the error
am i right? either way, how can i get the Spring Cloud Task (jar) to successfully run?
Spring Cloud Data Flow: Server
1.2.3 (using built spring-cloud-dataflow-server-cloudfoundry-1.2.3.BUILD-SNAPSHOT.jar)
Spring Cloud Data Flow: Shell
1.2.3 (using downloaded spring-cloud-dataflow-shell-1.2.3.RELEASE.jar)
Deployment Environment
PCF v1.11.6 (on Azure)
pcf dev v0.26.0 (on mac)
App Starters
http://bit-dot-ly/1-0-4-GA-stream-applications-rabbit-maven
Logs
link to log
The stream definition is missing from the post. It is possible that you're using the tasklauncher-local sink, which is compatible only when using SCDF's local-server and it will fail with the attached error when running in CF. Please make sure you're using tasklauncher-cloudfoundry sink. This application was added in the latest release of app-starters.
As pointed in the previous SO thread, it is highly recommended that you use the latest release of app-starters (1.0.4 is at least 10 months old). The latest releases can be found at the project site.
I have created an application on Play framework 2.5.6. I am trying to find out what is the best way to deploy the application on production. I have tomcat installed on my Ubuntu machine. How to create war file and How to deploy on tomcat? I am using Scala Eclipse IDE for development.
Have a look at this other thread which is very similar to what you're asking here (albeit directed at GAE).
In a nutshell, the disadvantages of deploying your app to Tomcat are:-
you have extra work to do to package your application as a WAR
extra work to deploy it
your application may not be fully asynchronous running in Tomcat
As that outdated documentation suggests - the simplest way of deploying your app in production is just using the version of Netty which is packaged as part of a Play application. See the relevant version of the docs to create a distribution. You only need a relevant version of a JVM on your prod server in this case.
The flow is generally:-
Run $ dist to build the binary (this is a zip by default, but you can also build a tar if you prefer using $ universal:packageZipTarball instead of dist).
Move it into your Linux production environment
Unpack it
Set permissions if you build a zip $ chmod +x /path/to/bin/<project-name> (not required if you created the tar)
Run the app start script (created by the dist task) eg. $ target/universal/stage/bin/<project-name>
I tried to launch our Scala application on the Swisscom Cloud Foundry (CF) infrastructure. To do so, the matching Heroku buildpack was used:
https://github.com/heroku/heroku-buildpack-scala
As this did not work, I tried to deploy the 'hello-scala' example using this buildpack.
My fork to be able to build the slightly outdated example:
https://github.com/AlwinEgger/hello-scala
I have to underline that I am fetching the port I have to use as env variable 'PORT'.
Unfortunately, there is not much on the log. "failed to accept connections within health check timeout" message indicates that there is no one listening...
My questions: Did anyone succeed in deploying Scala apps on CF infrastructures (# Swisscom)?
A workaround I found:
I'm not using the scala- but the java-buildback. This with the major advantage and inconvenience that the project is not any more build on the instance.
Advantage: It speeds up the whole process considerably
Inconvenience: A build server is needed
So what do we have to do?
An example may be found here (this is the actual application):
https://github.com/OpenOlitor/openolitor-server
Add the sbt-native-packager to your project
Execute the action 'universal:packageBin' building by hand or configure your build server to do so
Change the buildpack in the manifest.yml and add some parameters, if necessary. Configure the path of the artifact to deploy.
Run cf push or let the build server do so.