I deployed my app on Cloud Run service of google. It shows error "Cloud Run error: Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable. Logs for this revision might contain more information.
". I run this image on Cloud Shell to test, it still runs with PORT 8080 and bind 0.0.0.0, I can not find more error in log of cloud run. My project is laravel project. Please help me, how to find out more logs and debug this case.
Check Image
Port running
I fixed it. When i run with supervisor at local it runs, but on Cloud Run it's not ok. So i've changed to entrypoint to start php-fpm and nginx, it's okie on Cloud Run
You can look at this step by step guide that might help for this or similar problems with Laravel and Google Cloud Run.
Related
I'm testing neo4j enterprise 3.3.3 on AWS and trying to run an online backup on a db, which is located on a different server.
I run on my AWS instance:
neo4j-admin backup --backup-dir=~/backup --name=graph.db-backup --from=0.0.0.0:4444
where I change 0.0.0.0 for my open IP for the external neo4j db and 4444 for my port.
But then I get this error:
Failed to load private key: /var/lib/neo4j/certificates/neo4j.key
UPDATE
I fixed that by running the command with sudo (on Amazon AWS).
However, now I'm getting another error:
Failed to run a backup using the available strategies.
The documentation on backups says that you only need to uncomment some settings in neo4j.conf, which is what I've done, both on the server which is being backed up and the one that is actually running backup.
Could it be that the issue is because on AWS you have to run commands with
systemctl
And if so, how do I run neo4-admin with it?
It doesn't work if I use
systemctl neo4j-admin ...
Somebody from Neo4J — can you please help? Backup is one of the main reason to get the Enterprise version but there is not enough documentation on how to use it.
I'm deploying a docker image from Github to AWS elastic beanstalk using travis. That part goes OK, the actual deployment exits with 0 and there is a .zip file in the S3 bucket.
The issue is that, since this is my first time using AWS I created the app using the Sample Application since the code is deployed from Github, and after the deployment I get the health status as degraded (red exclamation sign) with this message:
ERROR
During an aborted deployment, some instances may have deployed the new application version. To ensure all instances are running the same version, re-deploy the appropriate application version.
If I go to Causes I find this:
Application deployment failed at 2020-05-01T16:01:58Z with exit status 1 and error: Engine execution has encountered an error.
Incorrect application version "travis-e55e05342a8cc16f3f28f8e184735667a9531ffa-1588311901" (deployment 4). Expected version "Sample Application" (deployment 1).
I even deleted the sample application and re-deployed the one that was uploaded and got that particular error. As you can see in the last message I've deployed this 3 times already, getting the same result.
Finally I downloaded the zip file from the S3 bucket and I found inside basically the src and public folders along with all the files in the root folder such as package.json, .gitignore all the docker files, etc.
EDIT
I created two separate repos in github to test this.
The first repo is a static page in a Docker container, quite simple. I create an environment in EB and start everything with the sample app. Then I push the changes to github, travis does it's thing and deploys the app to AWS. This works fine and the app's env is updated with no errors. This is the repo:
https://github.com/rhernandog/docler-static-page-aws
The second repo is a simple react app. Same procedure, create the environment in EB with the sample app. Push the code to github, travis does it's thing and deploys to AWS. This fails and I keep getting the same error:
Environment health has transitioned from Info to Degraded. Command failed on all
instances. Incorrect application version found on all instances. Expected version
"Sample Application" (deployment 1). Application update failed 1 second ago and
took 2 minutes.
This is the repo for the react app:
https://github.com/rhernandog/react-docker-awseb
In terms of Docker, everything works fine in my local machine.
EDIT 2
Based on #stefansundin suggestion I re-deployed the app to EB and check the logs. I ended looking at the full logs for more information and found this:
/var/log/cfn-hup.log
2020-05-14 17:07:42,605 [WARNING] Action for aws-eb-command-handler exited with 1, returning FAILURE
The only place where I found an error was in the engine log file:
/var/log/eb-engine.log
2020/05/14 17:07:42.514601 [INFO] Executing instruction: Docker Specific Build Application
2020/05/14 17:07:42.514605 [INFO] start build docker app
2020/05/14 17:07:42.514615 [INFO] fetch image name
2020/05/14 17:07:42.514639 [INFO] authenticate with ECR if the image is in an ECR repo
2020/05/14 17:07:42.514644 [INFO] pull docker image if update is not false in dockerrun.aws.json
2020/05/14 17:07:42.514657 [INFO] Running command /bin/sh -c docker pull node:12-alpine AS builder
2020/05/14 17:07:42.558923 [ERROR] "docker pull" requires exactly 1 argument.
So basically this is complaining about this in the dockerfile: FROM node:12-alpine AS builder. You can see the whole file in the repo: https://github.com/rhernandog/react-docker-awseb/blob/master/Dockerfile
The point is: Why this doesn't happen in my local machine? And how can I actually get the files from the build command and copy them to the nginx folder?
That is actually the only error I found in the log files.
I solved the issue here:
AWS Elastic Beanstalk Docker Does not support Multi-Stage Build
it is a stage-naming problem of multi-stage Dockerfile. Just use an Unamed one
I also got a similar error in my node app:
Incorrect application version "travis-e55e05342a8cc16f3f28f8e184735667a9531ffa-1588311901" (deployment 4). Expected version "Sample Application" (deployment 1)
What turned out to be an issue with my building and deployment scripts were corrected (debugged in Jenkins) the application successfully deploys in beanstalk with no error.
Turns out the issue was not with Beanstalk or app version but with the build mechanism. Something to look into when nothing else works :)
I had the same issue for java app in docker container.
I tried all the recommendations from this topic, links from this topic and nothing helped.
In the end, the following action helped:
Enable enhanced health panel https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/health-enhanced-enable.html#health-enhanced-enable-console
Go to the extended panel of the desired environment
Select the instance that crashed due to this "version" issue and click reboot
Additionally:
In one of the cases, I had to delete all previous versions (section on the left panel) and push a new one and only after that make the above recommendations.
Also make sure you have sufficient rights to deploy (codepipeline/deployment)
AWS Docs say that
To solve this issue, start another deployment. You can redeploy a previous version that you know works, or configure your environment to ignore health checks during deployment and redeploy the new version to force the deployment to complete.
You can also identify and terminate the instances that are running the wrong application version. Elastic Beanstalk will launch instances with the correct version to replace any instances that you terminate. Use the EB CLI health command to identify instances that are running the wrong application version.
Can you try to delete the instances that runs your applications and start a fresh install?
Also, you can use CodePipeline to deploy your codes to Elastic Beanstalk, you can use your S3 folder for the source stage and skip the build process if your code is build on travis and deploy using the deploy stage to install your new app to your Elastic Beanstalk. There might be some misconfiguration while installing the new app to your environment.
I suggest you to terminate your instances and start new instances sorry if I got your question wrong.
I haven't used Docker on Elastic Beanstalk. When my Ruby on Elastic Beanstalk deployments fail, I find that I usually find the problem if I request the 100 last lines from the logs. If you navigate to "Logs" -> "Request Logs" -> "Last 100 Lines", that may help you.
If that fails, I SSH in to the instance and look in the logs in /var/log. Maybe docker ps and docker logs may help you.
While creating a new webserver environment on platform branch select "Docker running on 64bit Amazon Linux" it will work.
I am running a virtual machine in Google Cloud. I have installed the default Debian OS, and configured the desktop environment for remote connection, as explained here: https://cloud.google.com/solutions/chrome-desktop-remote-on-compute-engine
I have been able to connect to the instance via Chrome Remote Desktop, however periodically I have the problem that the Remote Desktop says the vm instance is online, however if I try to connect to it I get:
Looking at the Google Cloud console, the instance is clearly running. Normally if I restart the instance the problem is solved, however I have processes running on the instance that I do not want to stop.
UPDATE:
Following the advice from Serhii Rohoza I ran
sudo systemctl status chrome-remote-desktop
The status looked normal, listing:
Active: active (exited) since...
I then ran
sudo systemctl restart chrome-remote-desktop
and this solved the problem, I could log into remote desktop again, but it seemed the VM instance had restarted, which is a big problem since I am running processes on it that should not shut down. I guess this is a problem to send to Google Cloud Services support.
UPDATE 2:
I'm still running into this problem. I normally have a Jupyter Notebook running on the VM - this Notebook must keep running. When I saw the message saying that the remote computer is offline, I logged in via ssh and checked if the Jupyter Notebook is running:
jupyter notebook list
This returned:
http://localhost:8888/?token=9110bf40789971b5e252a272e9497039b4f3b45e506348df :: /home/qgenixtech
So the Notebook was running. I then ran:
sudo systemctl restart chrome-remote-desktop
and after that again:
jupyter notebook list
and then it shows no Notebooks running. So the restart command closed down the Notebook (and also all other open windows on the desktop).
UPDATE 3:
I spoke to a support technician at Google. The problem is on the Remote Desktop side, not the virtual machine. According to the technician this is a known problem, by he didn't have a solution for it. He referred me to these two links from Google Support:
https://support.google.com/chrome/thread/10213547?hl=en
https://support.google.com/chrome/thread/3333421?hl=en
The next option for me is to look at something like X2go
To solve your issue you should follow documentation Troubleshooting and check status of the Chrome Remote Desktop service with command:
sudo systemctl status chrome-remote-desktop
and check log messages at /tmp/chrome_remote_desktop_DATE_TIME_*.
To investigate why your VM instance was restarted you should look for some clues at the logs:
Go to Compute Engine -> VM instances -> click on NAME_OF_YOUR_VM -> find section Logs -> click on Stackdriver Logging. More information you can find in the documentation Viewing logs (Classic)
Go to Compute Engine -> VM instances -> click on NAME_OF_YOUR_VM -> find section Logs -> click on Serial port 1 (console). More information in the documentation Viewing Serial Port Output
You can contact with Google Cloud Support as well.
In addition, have a look at the documentation Setting instance availability policies.
same issue. when checking logs i see:
2021-01-05 14:29:38,319:INFO:Starting Xvfb on display :20
xdpyinfo: unable to open display ":20".
2021-01-05 14:29:40,837:INFO:X server is active.
restarting service or even VM doesn't work.
i need to delete connection on "client" and re-auth with /headless link
This question seems very basic, but I wasn't able to quickly find an answer at https://cloud.google.com/compute/docs/instances/create-start-instance. I'm running a MicroMDM server on a Google Cloud VM by connecting to is using SSH (from the VM instances page in the Google Cloud Console) and then running the command
> sudo micromdm serve
However, I notice that when I shut down my laptop, the server also stops, which is actually why I wanted to run the server in a VM in the first place.
What would be the recommended way to keep the server running? Should I use systemd or perhaps run the process as a Docker container?
When you run the service from the command line, you "attach" it to your shell process, when you terminate your ssh session, your job gets terminated also.
To make a process run in background, simply append the & at the end of the command, in your case:
sudo micromdm serve &
This way your server is alive even after you quit your session.
I also suggest you to add that line in the instance startup script, if you want that server to always be up, so that you don't have to run the command by hand each time :)
More on Compute Engine startup scripts here.
As the Using MicroMDM with systemd documentation, it suggested to use systemd command to run MicroMDM service on linux.First, on our linux host, we create the micromdm.service file, then we move it to the location ‘/etc/systemd/system/micromdm.service’ . We can start the service. In this way, it will keep the service running, or restart service after the service fails or server restart.
I am running composer playground locally and while I am connected to the Internet, it is unable to load the sample business networks when I attempt to deploy a new business network. I get following error message:
Error: could not get any sample networks.
Had the same issue. Make sure u have all your 3 Docker containers are up and running. So here is how it goes :
When u run locally, u gotta run Docker containers on your local machine.
When u want to deploy, u can do so in the Docker file or also upload to Docker hub and call the images from that path.
Good luck mate.
This error could be due to the fact that Composer Playgrounds (cp) is looking to a previous project. Besides the deletion of browser cookies for localhost:cp-listening-port (8080 by default), check that that your browser points to:
http://localhost:cp-listening-port/login