|
| 1 | +# Troubleshooting Applications |
| 2 | + |
| 3 | +This document describes how one can troubleshoot common issues when deploying or debugging an |
| 4 | +application that fails to start or deploy. |
| 5 | + |
| 6 | + |
| 7 | +## Application has a Dockerfile, but a Buildpack Deployment Occurs |
| 8 | + |
| 9 | +When you deploy an application to Workflow using `git push deis master` and the [Builder][] |
| 10 | +attempts to deploy using the Buildpack workflow, check the following steps: |
| 11 | + |
| 12 | +1. Are you deploying the correct project? |
| 13 | +2. Are you pushing the correct git branch (`git push deis <branch>`)? |
| 14 | +3. Is the `Dockerfile` in the project's root directory? |
| 15 | +4. Have you committed the `Dockerfile` to the project? |
| 16 | + |
| 17 | +## Application was Deployed, but is Failing to Start |
| 18 | + |
| 19 | +If you deployed your application but it is failing to start, you can use `deis logs` to check |
| 20 | +why the application fails to boot. Sometimes, the application container may fail to boot without |
| 21 | +logging any information about the error. This typically occurs when the healthcheck configured for |
| 22 | +the application fails. In this case, you can start by |
| 23 | +[troubleshooting using kubectl][troubleshooting-kubectl]. You can inspect the application's current |
| 24 | +state by examining the pod deployed in the application's namespace. To do that, run |
| 25 | + |
| 26 | + $ kubectl --namespace=myapp get pods |
| 27 | + NAME READY STATUS RESTARTS AGE |
| 28 | + myapp-cmd-1585713350-3brbo 0/1 CrashLoopBackOff 2 43s |
| 29 | + |
| 30 | +We can then describe the pod and determine why it is failing to boot: |
| 31 | + |
| 32 | + |
| 33 | + Events: |
| 34 | + FirstSeen LastSeen Count From SubobjectPath Type Reason Message |
| 35 | + --------- -------- ----- ---- ------------- -------- ------ ------- |
| 36 | + 43s 43s 1 {default-scheduler } Normal Scheduled Successfully assigned myapp-cmd-1585713350-3brbo to kubernetes-node-1 |
| 37 | + 41s 41s 1 {kubelet kubernetes-node-1} spec.containers{myapp-cmd} Normal Created Created container with docker id b86bd851a61f |
| 38 | + 41s 41s 1 {kubelet kubernetes-node-1} spec.containers{myapp-cmd} Normal Started Started container with docker id b86bd851a61f |
| 39 | + 37s 35s 1 {kubelet kubernetes-node-1} spec.containers{myapp-cmd} Warning Unhealthy Liveness probe failed: Get http://10.246.39.13:8000/healthz: dial tcp 10.246.39.13:8000: getsockopt: connection refused |
| 40 | + |
| 41 | +In this instance, we set the healthcheck initial delay timeout for the application at 1 second, |
| 42 | +which is too aggressive. The application needs some time to set up the API server after the |
| 43 | +container has booted. By increasing the healthcheck initial delay timeout to 10 seconds, the |
| 44 | +application is able to boot and is responding correctly. |
| 45 | + |
| 46 | +See [Custom Health Checks][healthchecks] for more information on how to customize the application's |
| 47 | +health checks to better suit the application's needs. |
| 48 | + |
| 49 | + |
| 50 | +[builder]: ../understanding-workflow/components.md#builder-builder-slugbuilder-and-dockerbuilder |
| 51 | +[healthchecks]: ../applications/managing-app-configuration.md#custom-health-checks |
| 52 | +[troubleshooting-kubectl]: kubectl.md |
0 commit comments