diff options
| author | D Delmar Davis <don@suspectdevices.com> | 2025-12-06 19:00:25 -0800 |
|---|---|---|
| committer | D Delmar Davis <don@suspectdevices.com> | 2025-12-06 19:00:25 -0800 |
| commit | 5927e42f20ff81109e30c37cfd149dbe2cde7a9b (patch) | |
| tree | 4033c0015e30be4a4af8add2df9a0e4d87252e5c /docs | |
| parent | 634ae1eb9e2f39d8dcc4391ae0cb62ece2d69623 (diff) | |
I can has engrish.
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/rethinkeverything/k8s-Docker/makingdockerbehave.md | 69 |
1 files changed, 34 insertions, 35 deletions
diff --git a/docs/rethinkeverything/k8s-Docker/makingdockerbehave.md b/docs/rethinkeverything/k8s-Docker/makingdockerbehave.md index 89c9302..6ab5353 100644 --- a/docs/rethinkeverything/k8s-Docker/makingdockerbehave.md +++ b/docs/rethinkeverything/k8s-Docker/makingdockerbehave.md @@ -4,30 +4,35 @@ Where I work there are that use docker and hosts that are dedicated to hosting t ## Deployments as code -Ok if everything has to be code it should good coding discipline as well as being a good guest on the host. For docker deployments a git repository should be created for each service. The repo should include all resources that are needed to deploy/configure the service. Resources on the host should be documented in the repositories README.md file +Ok, if everything has to be code, it should practice good coding discipline as well as being a good guest on the host. For docker deployments a git repository should be created for each service. The repo should include all resources that are needed to deploy/configure the service. -## Repositories target location +### Documentation and Dependencies -For docker host deployments, the repository containing any docker-compose files and related resources should be cloned to a predictable path. The pattern we use at work and at home is. +Service repositories should had a README.md file containing instructions on how to deploy the service. + +In addition to the readme file a brief description of the service should be placed in the repository +This file should should contain a one or two line description that can be easily found when trying to resolve issues. An example of this might be a motd fragment that is displayed when logging into the applications host. -/usr/local/<organization>/service/<repo_name>/ +Deployments should be as self contained as possible. Data such as ssl certificates should be kept within the repository unless there is a good reason to leave them elsewhere. Nfs mounted data directories or environmental files needed by the deployment should be clearly documented in the deployments README.md file. -## Brief description of the service should be placed in your Repository +### Repositories target location -This file should should contain a one ro two line description that can be easily found when trying to resolve issues. An example of this might be a motd fragment that is displayed when logging into the applications host. +For docker host deployments, the repository containing any docker-compose files and related resources should be cloned to a predictable path. The pattern we use at work and at home is. -## Docker Tagging +/usr/local/\<organization\>/service/\<repo_name\>/ -Publicly hosted images which do not require rebuilding can reference the image directly in a production envirement NEVER use the 'latest' tag. If docker, the application or the host are restarted upstream changes may break the service. ## Making Docker Behave Docker out of the box is an undisciplined pig. If given enough time the logs alone will fill disks with its logs, It may not restart if interupted and it may not start at all and not tell you. +### Docker Tagging + +Publicly hosted images which do not require customization can reference the image directly, However, in a production environment NEVER use the 'latest' tag. If docker, the application, or the host are restarted upstream changes may break the service. ### Logging Configuration -There are a bagillian ways for docker applications to log errors and other messages but regardless of the method used it needs to limit the size of the files it creates and must not block if the network logging is temporarily unavaliable. +There are a bagillian ways for docker applications to log errors and other messages but regardless of the method used it needs to limit the size of the files it creates and must not block if the network logging is temporarily unavaliable. Here is an example of limits set in a hosts /etc/docker/daemon.json file @@ -40,7 +45,21 @@ Here is an example of limits set in a hosts /etc/docker/daemon.json file } } -### Health Checks +### Restart Policy + +Restart policy establishes the behavior of the docker deployment if it, the docker daemon or server fails. + +Unless there is a clear reason for a different configuration all docker compose files should set: + + +```sh +restart: unless-stopped +``` + +for their containers. + + +### Health Checks (This is mostly @mhix but it stands as common sense and within the bounds of docker documentation, I will discuss the issues of using it verbatum) @@ -50,36 +69,16 @@ What command you can run depends on what is available inside the container. Heal What command you run is arbitrary, but it should have no external dependencies, execute quickly, and not require very many system resources. -Please refer to the docker compose documentation for the timing parameters interval, timeout, and retries here: Docker Compose Health Check Reference - -Example with bashto check an open TCP port: - -healthcheck: - test: "bash -c 'exec 6<> /dev/tcp/localhost/5432'" - interval: 10s - timeout: 1s - retries: 3 - -Example with curl: +Please refer to the docker compose documentation for the timing parameters interval, timeout, and retries [here](https://docs.docker.com/reference/dockerfile/#healthcheck) +```sh healthcheck: test: "curl -o /dev/null -q http://localhost:8080/" interval: 15s timeout: 1s retries: 3 - -### Restart Policy - -Unless there is a clear reason for a different configuration all docker compose files should set - -restart: unless-stopped - -for their containers. - -Dependencies - -Docker deployments should be as self contained as possible. Data such as ssl certificates should be kept within the repository unless there is a good reason to leave them elsewhere. Nfs mounted data directories or environmental files needed by the deployment must be documented in the deployments README.md file. - +``` ## References -https://www.dash0.com/guides/mastering-docker-logs
\ No newline at end of file +- https://www.dash0.com/guides/mastering-docker-logs +- https://docs.docker.com/reference/dockerfile/#healthcheck
\ No newline at end of file |
