Failed update (we see the healthcheck fail on the new container)
Container refuses to start because MaxRetryAttempts has happened (when no existing container is up - this is typically when you're trying to deploy the app for the first time)
Handling missing healthchecks gracefully
Overall goals are: make it work and keep it fast.
All of these will rely on healthchecks on each container, so, we need to implement them in all our apps and make them standard from now on, unfortunately...but I am getting better at understanding how they work! I have hope.
Seems like a default new deploy: ... configuration is emerging:
Where you ensure that the service won't be in a restart loop forever.
Closes https://git.autonomic.zone/coop-cloud/abra/issues/165.
Cases to be solved from my testing:
- [x] Sucessful deployment
- [x] Failed update (we see the healthcheck fail on the new container)
- [ ] Container refuses to start because MaxRetryAttempts has happened (when no existing container is up - this is typically when you're trying to deploy the app for the first time)
- [x] Handling missing healthchecks gracefully
Overall goals are: *make it work and keep it fast*.
All of these will rely on healthchecks on each container, so, we need to implement them in all our apps and make them standard from now on, unfortunately...but I am getting better at understanding how they work! I have hope.
Seems like a default new `deploy: ...` configuration is emerging:
```
deploy:
update_config:
failure_action: rollback
order: start-first
rollback_config:
order: start-first
restart_policy:
max_attempts: 3
```
Where you ensure that the service won't be in a restart loop forever.
The default settings are really default. A redis container is up in like 3 seconds but the first healthcheck won't run until 30 seconds. So by tailoring each of these values to some better default, we can get speedy deployments and abra doesn't have to manage it. It pushes the complexity to swarm itself which is ideal.
It seems a core element of making this run fast is configuring the healthcheck:
- https://docs.docker.com/engine/reference/builder/#healthcheck
- https://docs.docker.com/compose/compose-file/compose-file-v3/#healthcheck
The default settings are really default. A redis container is up in like 3 seconds but the first healthcheck won't run until 30 seconds. So by tailoring each of these values to some better default, we can get speedy deployments and `abra` doesn't have to manage it. It pushes the complexity to swarm itself which is ideal.
Also:
> https://engineering.issuu.com/2018/09/12/confident-deployments
OK, I'm gonna merge this as is now, one edge case is still not covered. Example output:
INFO: works_r5_should_also_work is healthy!
INFO: works_r4_disabled_health_check has no healthcheck configured, cannot guarantee this service comes up successfully...
INFO: Deploying: 2/5 (timeout: 1/60)
INFO: works_r3_no_health_check has no healthcheck configured, cannot guarantee this service comes up successfully...
INFO: Deploying: 3/5 (timeout: 2/60)
INFO: Deploying: 3/5 (timeout: 3/60)
INFO: Deploying: 3/5 (timeout: 4/60)
INFO: works_r1_should_work is healthy!
INFO: Deploying: 4/5 (timeout: 5/60)
WARNING: Healthcheck for new instance of works_r2_broken_health_check is failing (exit code: 127)
WARNING: /bin/sh: foobar: not found
ERROR: healthcheck for works_r2_broken_health_check is failing, this deployment did not succeed :(
OK, I'm gonna merge this as is now, one edge case is still not covered. Example output:
```
INFO: works_r5_should_also_work is healthy!
INFO: works_r4_disabled_health_check has no healthcheck configured, cannot guarantee this service comes up successfully...
INFO: Deploying: 2/5 (timeout: 1/60)
INFO: works_r3_no_health_check has no healthcheck configured, cannot guarantee this service comes up successfully...
INFO: Deploying: 3/5 (timeout: 2/60)
INFO: Deploying: 3/5 (timeout: 3/60)
INFO: Deploying: 3/5 (timeout: 4/60)
INFO: works_r1_should_work is healthy!
INFO: Deploying: 4/5 (timeout: 5/60)
WARNING: Healthcheck for new instance of works_r2_broken_health_check is failing (exit code: 127)
WARNING: /bin/sh: foobar: not found
ERROR: healthcheck for works_r2_broken_health_check is failing, this deployment did not succeed :(
```
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes https://git.autonomic.zone/coop-cloud/abra/issues/165.
Cases to be solved from my testing:
Overall goals are: make it work and keep it fast.
All of these will rely on healthchecks on each container, so, we need to implement them in all our apps and make them standard from now on, unfortunately...but I am getting better at understanding how they work! I have hope.
Seems like a default new
deploy: ...configuration is emerging:Where you ensure that the service won't be in a restart loop forever.
f151018f10toc7f838178cIt seems a core element of making this run fast is configuring the healthcheck:
The default settings are really default. A redis container is up in like 3 seconds but the first healthcheck won't run until 30 seconds. So by tailoring each of these values to some better default, we can get speedy deployments and
abradoesn't have to manage it. It pushes the complexity to swarm itself which is ideal.Also:
c7f838178cto4ed9f119d84ed9f119d8to7322105fd97322105fd9to4593451dab4593451dabto62999a1732OK, I'm gonna merge this as is now, one edge case is still not covered. Example output:
62999a1732todccfff0c87dccfff0c87to93714a593bWIP: make ensure_stack_deployed reliableto Make ensure_stack_deployed more reliable