Skip to content

Commit d212da1

Browse files
authored
DOC: Documentation updates for devtron installation, ingess, liveness and readiness probe (#1115)
1 parent d904746 commit d212da1

File tree

4 files changed

+31
-2
lines changed

4 files changed

+31
-2
lines changed

docs/setup/install/install-devtron-helm-2.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -70,6 +70,11 @@ kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync
7070
```
7171

7272
The install commands initiates Devtron-operator which spins up all the Devtron micro-services one by one in about 20 mins. You can use the above command to check the status of the installation if the installation is still in progress, it will print `Downloaded`. When the installation is complete, it prints `Applied`.
73+
Meanwhile, you can check logs of the installer by executing the following command:
74+
75+
```bash
76+
kubectl logs -f -l app=inception -n devtroncd
77+
```
7378

7479
## Access Devtron dashboard
7580

docs/setup/install/install-devtron-helm-3.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -63,6 +63,11 @@ kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync
6363
```
6464

6565
The install commands initiates Devtron-operator which spins up all the Devtron micro-services one by one in about 20 mins. You can use the above command to check the status of the installation if the installation is still in progress, it will print `Downloaded`. When the installation is complete, it prints `Applied`.
66+
Meanwhile, you can check logs of the installer by executing the following command:
67+
68+
```bash
69+
kubectl logs -f -l app=inception -n devtroncd
70+
```
6671

6772
## Access Devtron dashboard
6873

docs/setup/install/install-devtron-using-kubectl.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -35,7 +35,11 @@ kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync
3535
```
3636

3737
The install commands initiates Devtron-operator which spins up all the Devtron micro-services one by one in about 20 mins. You can use the above command to check the status of the installation if the installation is still in progress, it will print `Downloaded`. When the installation is complete, it prints `Applied`.
38+
Meanwhile, you can check logs of the installer by executing the following command:
3839

40+
```bash
41+
kubectl logs -f -l app=inception -n devtroncd
42+
```
3943
## Access Devtron dashboard
4044

4145
If you did not provide a **BASE\_URL** during install or have used the default installation, Devtron creates a loadbalancer for you on its own. Use the following command to get the dashboard url.

docs/user-guide/creating-application/deployment-template/rollout-deployment.md

Lines changed: 17 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -106,6 +106,9 @@ LivenessProbe:
106106
successThreshold: 1
107107
timeoutSeconds: 5
108108
failureThreshold: 3
109+
command:
110+
- python
111+
- /etc/app/healthcheck.py
109112
httpHeaders:
110113
- name: Custom-Header
111114
value: abc
@@ -121,6 +124,7 @@ LivenessProbe:
121124
| `successThreshold` | It defines the number of successes required before a given container is said to fulfil the liveness probe. |
122125
| `timeoutSeconds` | It defines the time for checking timeout. |
123126
| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as live. |
127+
| `command` | The mentioned command is executed to perform the livenessProbe. If the command returns a non-zero value, it's equivalent to a failed probe. |
124128
| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
125129
| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
126130
| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
@@ -161,6 +165,9 @@ ReadinessProbe:
161165
successThreshold: 1
162166
timeoutSeconds: 5
163167
failureThreshold: 3
168+
command:
169+
- python
170+
- /etc/app/healthcheck.py
164171
httpHeaders:
165172
- name: Custom-Header
166173
value: abc
@@ -176,6 +183,7 @@ ReadinessProbe:
176183
| `successThreshold` | It defines the number of successes required before a given container is said to fulfill the readiness probe. |
177184
| `timeoutSeconds` | It defines the time for checking timeout. |
178185
| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as ready. |
186+
| `command` | The mentioned command is executed to perform the readinessProbe. If the command returns a non-zero value, it's equivalent to a failed probe. |
179187
| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
180188
| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
181189
| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
@@ -241,9 +249,11 @@ ingress:
241249
annotations: {}
242250
hosts:
243251
- host: example1.com
252+
pathType: "ImplementationSpecific"
244253
paths:
245254
- /example
246255
- host: example2.com
256+
pathType: "ImplementationSpecific"
247257
paths:
248258
- /example2
249259
- /example2/healthz
@@ -266,8 +276,9 @@ ingress:
266276
| :--- | :--- |
267277
| `enabled` | Enable or disable ingress |
268278
| `annotations` | To configure some options depending on the Ingress controller |
269-
| `path` | Path name |
270279
| `host` | Host name |
280+
| `pathType` | Path in an Ingress is required to have a corresponding path type. Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`. |
281+
| `path` | Path name |
271282
| `tls` | It contains security details |
272283

273284
### Ingress Internal
@@ -282,9 +293,11 @@ ingressInternal:
282293
annotations: {}
283294
hosts:
284295
- host: example1.com
296+
pathType: "ImplementationSpecific"
285297
paths:
286298
- /example
287299
- host: example2.com
300+
pathType: "ImplementationSpecific"
288301
paths:
289302
- /example2
290303
- /example2/healthz
@@ -295,8 +308,10 @@ ingressInternal:
295308
| :--- | :--- |
296309
| `enabled` | Enable or disable ingress |
297310
| `annotations` | To configure some options depending on the Ingress controller |
298-
| `path` | Path name |
299311
| `host` | Host name |
312+
| `pathType` | Path in an Ingress is required to have a corresponding path type. Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`. |
313+
| `path` | Path name |
314+
| `pathType` | Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`.|
300315
| `tls` | It contains security details |
301316

302317
### Init Containers

0 commit comments

Comments
 (0)