Most developers will write and test their code locally, either on their PC or in a test environment on the local network. When the application is ready for a wider audience, the developer can push the application to Pivotal Web Services. In many cases, an application that runs locally will run fine when deployed to PWS and no further action is required. If you experience problems running your application on PWS, please read further as this article will walk through the common causes.
Runtime / Language Differences
When running your application locally, you will have a specific version or set of versions of your application's language or runtime installed. These versions may or may not be the one being used on PWS and could possibly have incompatibilities. If you're experiencing application failures on PWS, please compare the version of your language or runtime being used locally against the version on PWS.
The process for determining the version varies by runtime. Some common strategies for locating the runtime version on PWS include looking through the build pack's output when you run `cf push`, which will often show the version, and grabbing the version programmatically and writing it to a log file or a web endpoint.
In addition to the language or runtime version, you should pay attention to the version of any server software being used to by the build pack to deploy your application. This is most relevant to Java users, which have their application deployed in Apache Tomcat, and PHP users who have their application deployed behind Nginx or Apache HTTPD. Again, you'll want to make sure that your local environment matches the PWS environment as closely as possible, to minimize the possibility of problems.
When you deploy your application to PWS, you are required to select a memory limit for the application. The memory limit sets an upper bound on how much memory the application can access when it runs. If your application attempts to exceed this limit by any amount, the platform will kill the application and restart it.
Because the system simply kill's your process when you exceed the memory limit, it can be a little tricky to tell the difference between an application crash and running out of memory. Both result in the application going down and being restarted, however running out of memory usually results in an exit code of 255 (exit codes are visible by running `cf events` or `cf logs`) whereas an application crash would have some application specific exit code.
If you're seeing an unexplained crash when deploying your application to PWS or if you're seeing an exit code of 255, try increasing the memory limit for the application. Once the application stabilizes you can use `cf app` to view memory usage or enable monitoring with a tool like NewRelic to further investigate the memory needs of your application.
Not Listening for a Connection
With many languages (Go, Python, Ruby, Node.js, etc..) it is the responsibility of the application to listen for incoming HTTP requests (i.e. there is no application server like with Java or PHP). For languages like this, it is perfectly acceptable for an application running locally to listen on a common port like 5000, 8000 or 8080, however, this is not acceptable when running on PWS.
The Cloud Foundry platform that runs PWS does not allow for individual applications to pick the port where they will listen. Instead, the platform assigns a port to your application (through the PORT environment variable) and requires your application to listen on that specific port. If your app does not listen on the assigned port, the system will think it did not start or has crashed.
If you have an application that directly listens for incoming HTTP requests, please make sure that you are listening on the correct port by examining the `PORT` environment variable and listening on the port contained in it. Your application will very likely run locally with the custom port, but not on PWS.
When your application runs on PWS, it will be deployed within a restricted environment. The only way to access the application is via ports 80 (HTTP), 443 (HTTPS) and 4443 (Secure WebSockets). It is not possible to make direct TCP connections to your application and multicast traffic from the application is not permitted. As far as outbound connections are concerned, PWS does not restrict your application in any way. The platform allows you to connect to any publicly routable server.
If you have an application that runs locally but not on PWS, make sure that you are not attempting to break one of the network restrictions above and make sure that any resources your application is trying to access, like database or REST services, are available on the public Internet. When in doubt, use a third party "ping" service like Pingdom to validate that services accessed by the application are publicly accessible.
Most developers will have services running locally for use during development and testing. These services are often not accessible remotely and not suitable for production workloads. If your application is failing when run on PWS, please check your application's service configuration and make sure that it is not still trying to access your development servers.
As mentioned in the last section on networking, it is possible for your applications to connect to any publicly accessible service. The PWS Marketplace provides an excellent set of services that you can use, but you do not have to. If you choose to use a non-marketplace service, you should check two things both of which can cause problems for your app running on PWS.
- That the service is hosted as geographically close to the PWS Servers as possible. This will reduce latency and make your applications perform better. All of the services available through the PWS Marketplace satisfy this recommendation.
- If the service maintains a whitelist of valid incoming IP addresses. For services that require a whitelist, you can either provide the entire pool of IP addresses used by PWS or you can use the QuotaGuard service for a private set of IP addresses.