So it makes sense that the above dir is not accessible by the service.
So the problem was solved by performing a
chgrp -R nogroup /prometheus_data
https://stackoverflow.com/questions/54232891/docker-compose-directory-permission-errors-on-bind-mount
nogroup
is the group analog to the nobody
user. It is used for unprivileged processes so that even if something goes wrong the process does not have the permissions to cause any serious damage to an important user or group.https://unix.stackexchange.com/questions/22520/what-is-nogroup-groups-purpose
useful tips:
// Multiple email in alertmanager
https://stackoverflow.com/questions/47921028/multiple-email-receivers-in-prometheus-alertmanager-to-field
// For docker-compose.yml is always good to add restart always in the each service so when OS rebooted, this service will automatically restart
services:
xxx:
image: xxx/xxx
networks:
- back
ports:
- 9091:9091
restart: always
to field.
// Docker rebuild a running container without building rebuilding dependecies
$docker container stop <container_id> / <service_name>
$docker-compose up -d --no-deps --build <service_name>
#<service_name> is the service name specified in docker-compose.yml file
--no-deps - Don't start linked services.
--build - Build images before starting containers.
https://stackoverflow.com/questions/36884991/how-to-rebuild-docker-container-in-docker-compose-yml
// Docker compose builddocker-compose up -d
// Docker logs
Don't use "docker logs". Use "docker-compose logs flask" to see the logs of that restarting containers. With your options:
docker-compose logs -f --tail=50
// Go inside docker containerdocker exec -it <mycontainer> bash
No comments:
Post a Comment