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.
Related
I'm pretty new on Google Cloud, and I just wanted to deploy my first streamlit webapp. I'm on Windows in command line. I already did the Google Cloud "Hello World" Example, which worked without any error.
When I deploy the streamlit webapp, I got after 3-4 minutes waiting "Updating Server" the following error:
ERROR: (gcloud.app.deploy) Error Response: [9] Flex operation projects/XXXX/regions/us-central1/operations/f0c89d22-2d09-410d-bf99-fc49ad337800 error [FAILED_PRECONDITION]: An internal error occurred while processing task /app-engine-flex/flex_await_healthy/flex_await_healthy>2021-05-27T06:13:50.278Z10796.jc.0: 2021-05-27 06:15:32.787 An update to the [server] config option section was detected. To have these changes be reflected, please restart streamlit.
That's my app.yaml file:
service: default
runtime: custom
env: flex
manual_scaling:
instances: 1
resources:
cpu: 1
memory_gb: 0.5
disk_size_gb: 10
Posting my comment as an answer for better visibility and to summarize.
In this particular case, the error was caused by a mistake in the Dockerfile.
Here are some steps you can follow to fix or narrow down the error:
Try to deploy a test app to see the differences in configuration. Example.
Try deploying your app after updating the gcloud with gcloud components update command.
Make sure you run the SDK as an Admin.
If the error recurs, run the gcloud app deploy app.yaml --verbosity=debug to try getting more specified error.
It's good practice to include references in questions for folks who aren't familiar with e.g. Streamlit. I assume it's this: https://streamlit.io/
I suspect (!) that Streamlit does not (by default) satisfy App Engine's requirements:
A web app on port 8080
No additional (apt get) dependencies
No C-based dependencies
The Streamlit wiki references various deployment alternatives and includes Google Kubernetes Engine (aka GKE) (see below) but not App Engine.
This doesn't mean that it won't work on App Engine (standard) just that it may not be trivial.
The GKE instructions reference installing Cython an optimizing c-compiler and that gives me pause about using App Engine standard. Unless you're familiar with Kubernetes, I'd discourage you from trying GKE as there's more complexity.
So, it would be helpful if others with experience with Streamlit weigh in but, until then, you may wish to consider using Streamlit sharing.
It would be helpful if someone who has deployed Streamlit to App Engine (flexible?) or perhaps Cloud Run can provide an overview.
I had deployed the app last on friday and it got deployed successfully.But since, today morning the deployment is not happening at all.It is checking for conflicting process and failing.
I'm doing this from the webide and i'm not able to check what are the conflicting process and how to resolve it.
WebIDE lacks the ability to do proper investigation on deploying apps to SAP Cloud Foundry.
The best way to do this is to install the Cloud Foundry Multi-apps plugin (see this tutorial). This will allow you to use the local terminal to control the deployment (or alternatively use SAP Business Application Studio which already has the commands built in).
Then use the command cf mta-ops to get the list of ongoing operations and cf dmol <operation_id> to download the logs for that operation. cf deploy can be used to abort/retry operations.
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.
Over the last few months I've become familiar with the AWS OpsWorks deployment process as it pertain to Node.js - deployment for Go seems to be another animal.
From what I've gathered, this is what I need to compile a successful Go deployment:
Install go on the EC2 box
Pull the private repository from GitHub
Pull in all dependencies
Compile the main package for the box's arch
Start the binary with a couple of flags that I use
Everywhere I have read seems to tout the ease of Go deployments because dependencies are included in the binary, but that seems to imply that you are compiling the application in your development environment and pushing that up to the cloud. This doesn't seem like a process that works well across a development team.
https://github.com/crowdmob/chef-golang-web-server-cookbook
I have been attempting to get the Chef Scripts from CrowdMob working, but to no avail. I continue to get errors that look like this:
[2014-08-01T16:08:22+00:00] WARN: Cookbook 'templates' is empty or entirely chefignored at /opt/aws/opsworks/current/merged-cookbooks/templates
What is the proper way to deal with dependencies during deployment?
Are there any established practices for deploying Go onto AWS with Chef?
Use a continuous integration service like CircleCi, Travis or your own setup Jenkins.
On the Continuous integration service then
Add a github post commit hook .
Test / Build the binary
Create the zip file as artifact
At this point you can create an new version on Elastic Beanstalk using the AWS commandline and the zip file created from this version.
venv/bin/aws elasticbeanstalk create-application-version ...
Then just select which version to deploy from the EB dashboard.
For simple services using Chef is overkill IMHO. Docker offers a simple workflow.
Use the Docker container option and then use elastic beanstalk's command-line client to initialize your environment in the project root directory and then you can simply do a 'git aws.push' from the same place.
With the correctly configured Dockerfile in your project and pushed to eb, the EBS' docker container app will pull the correct image with golang installed, then do a go get on your projects dependencies, and then compile and run your app. It sounds way more complicated but it's actually very easy.
Below is a link to a video walkthrough I did for running a simple golang webapp on EBS. The method for uploading the project does not use git. Instead, I zip it up and upload it, but the git method is recommended (and I do it) for automating deployment.
YouTube: How to run a go web app on Amazon's Elastic Beanstalk
I also had some problems to setup a good building process with Elastic Beanstalk and Go.. I don't want to use Docker, and all the people seems to be going on this direction.. so.. you can take a look at this project: https://github.com/battle-arena/heimdall
There you will find a custom setup using the Buildfile and the Procfile.. and I rely on a CI system to build the release package...
Basically I do the following:
Hook the commits to a CI system
On the CI system I run the test and the install.sh if all good
The install.sh will create a build folder and a structure that will be sended to the Elastic Beanstalk with the aws-cli tool
After send to the EB the Buildfile will run the build.sh that will basically extract the compressed package with the proper structure, and run a go get ./... and go build
The Procfile will run the generated binary
I think the result is pretty good, and you can use with any CI tool.
In fact, I'm trying to see which would be the best approach to achieve play framework native support on openshift.
Play has it's own http server developed with netty. Right now you can deploy a play application to openshift, but you have to deploy it as a war, in which case play uses Servlet Container wrapper.
Being able to deploy it as a netty application would allow us to use some advanced features, like asynchronuos request.
Openshift uses jboss, so this question would also involve which would be the recommended approach to deploy a netty application on a jboss server, using netty instead of the servlet container provided by jboss.
Here is request for providing play framework native support on openshift There's more info there, and if you like it you can also add your vote ;-)
Start with creating 'raw-0.1' application.
SSH into the server and
cd $OPENSHIFT_DATA_DIR
download and install play into a directory here. $OPENSHIFT_DATA_DIR is supposed to survive redeploys of your application.
Now you can disconnect from SSH.
Clone the application repository. In the repository, there is a file .openshift/actions_hooks/start. It's task is to start the application using a framework of your choice. The file will need to contain at least (from what I know about Play)
cd $OPENSHIFT_REPO_DIR
$OPENSHIFT_DATA_DIR/play-directroy/play run --http.port=$OPENSHIFT_INTERNAL_PORT --some-other-parameters
Important
You have to bind to $OPENSHIFT_INTERNAL_IP:$OPENSHIFT_INTERNAL_PORT. Trying to bind to different interface is not allowed, also most of the ports are blocked.
To create some sort of template, save the installation steps into .openshift/action_hooks/build file. Check if play is installed, if it is do nothing, if it's not, execute the installation process.