I'm learning to create a docker enviroment.
I got stuck on creating volumes:
after I run the following, I get a DB lock in linux.
Volumes:
- ./data/test:/data/test
I tried to run, but sadly it is not working.
Volumes:
- ./data/test:/data/test:rw
Any sugestions ???
Related
Trying to install nextcloud on rpi4.
I'm getting below error when trying to install nextcloud on rpi4 running buster
Initializing nextcloud 23.0.4.1 ...,
touch: setting times of '/var/www/html/nextcloud-init-sync.lock': Operation not permitted,
Initializing nextcloud 23.0.4.1 ...,
Another process is initializing Nextcloud. Waiting 10 seconds...,
My docker-compose looks like this
version: '2'
services:
db:
image: yobasystems/alpine-mariadb:latest
command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
restart: always
volumes:
- /nextcloud:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=YOURROOTPASSWORD
- MYSQL_PASSWORD=YOURPASSWORD
- MYSQL_DATABASE=nextcloud
- MYSQL_USER=nextcloud
app:
image: nextcloud
ports:
- 8181:80
links:
- db
volumes:
- /nextcloud:/var/www/html
restart: always
Please help!
Remove /var/www/html/nextcloud-init-sync.lock to unlock the installation process
I had the same issue and I could fixed it by mounting /var/www/html to a separate nextcloud volume. On the same level like service add this:
volumes:
nextcloud:
in your app volumes set the volume like this:
- nextcloud:/var/www/html
Recently I had the same problem with nextcloud 25.0.3.2 on Raspberry Pi 4 and did some research.
This causes the problem:
Unfortunately Raspbian uses some very old
packages. There is nothing we can fix in our image. 😕
Source: https://github.com/nextcloud/docker/issues/1589#issuecomment-923371168
There is a workaround, by giving extended privileges to the nextcloud container:
I did another investigation and deleted the lock file many times.
After some time I found out that if I run the nextcloud container as
priviliged, the error touch: setting times of
'/var/www/html/nextcloud-init-sync.lock': Operation not permitted does
not happen again and I could upgrade to 23.0.4.
Source: https://github.com/nextcloud/docker/issues/1742#issuecomment-1133837814
But beware:
The --privileged flag gives all capabilities to the container. When
the operator executes docker run --privileged, Docker will enable
access to all devices on the host as well as set some configuration in
AppArmor or SELinux to allow the container nearly all the same access
to the host as processes running outside containers on the host.
Additional information about running with --privileged is available on
the Docker Blog.
Source: https://docs.docker.com/engine/reference/run/
tl;dr: Give extended privileges to nextcloud container
...
app:
image: nextcloud
privileged: true
I'm using docker-compose to create a Docker network of containers with InfluxDB, a python script and Grafana to harvest and visualize response codes, query times & other stats of different websites.
I am using Grafana image 7.3.0 with a volume,
I have modified the paths environment variables so I'll have to use only one volume to save all the data.
When I start the Grafana container it logs:
GF_PATHS_CONFIG='/etc/grafana/grafana.ini' is not readable.
GF_PATHS_DATA='/etc/grafana/data' is not writable.
GF_PATHS_HOME='/etc/grafana/home' is not readable.
You may have issues with file permissions, more information here: http://docs.grafana.org/installation/docker/#migration-from-a-previous-version-of-the-
docker-container-to-5-1-or-later
mkdir: can't create directory '/etc/grafana/plugins': Permission denied
But here is the thing, I'm not migrating from below 5.1 I'm not even migrating at all!
So I tried to follow their instruction to change permissions of files but it did not worked.
I tried to set the user id in the docker-compose but it did not help.
(as-said in the docs 472 == post 5.1, 104 == pre 5.1 but both did not worked)
I can't even change permissions manually (which is not a satisfying solution btw) because the container is crashing.
I normally don't ask questions because they already have answers but I've seen no one with this trouble using 7.3.0 so I guess it's my time to shine Haha.
Here is my docker-compose.yml (only the grafana part)
version: '3.3'
services:
grafana:
image: grafana/grafana:7.3.0
ports:
- '3000:3000'
volumes:
- './grafana:/etc/grafana'
networks:
- db-to-grafana
depends_on:
- db
- influxdb_cli
environment:
- GF_PATHS_CONFIG=/etc/grafana/grafana.ini
- GF_PATHS_DATA=/etc/grafana/data
- GF_PATHS_HOME=/etc/grafana/home
- GF_PATHS_LOGS=/etc/grafana/logs
- GF_PATHS_PLUGINS=/etc/grafana/plugins
- GF_PATHS_PROVISIONING=/etc/grafana/provisioning
user: "472"
Thank you very much for your potential help!
Edit : I've been wondering if there is a grafana user in latest version (8.0), I think that build a home dir for grafana using a Dockerfile could be the solution I just need to find that user.
I'm here to close this subject.
So this was kind of a noob mistake but I could not have known.
The problem came from the fact that Grafana won't chown and chmod the volume folder. The error does not occures but it won't work because it does not save the data.
The solution was to remove the env variables and changing permissions of the local './grafana' folder wich contained the volume.
So I did
chown -R <personal local user> /path/to/local/volume/folder && \
chmod -R 777 /path/to/local/volume/folder
And now it works normally
Here is my new docker compose
docker-compose.yml
grafana:
image: grafana/grafana
ports:
- '3000:3000'
volumes:
- './grafana:/var/lib/grafana'
networks:
- db-to-grafana
depends_on:
- db
- influxdb_cli
Thanks everybody four your help !
Just replace your user's id that you will get on the following command:
$ id -u
Im running 'id -u' in my terminal and getting '1000'. SO, I replaced user: "xxxx" to user: "1000" in docker-compose.yml
version: '3.3'
services:
grafana:
image: grafana/grafana:7.3.0
ports:
- '3000:3000'
volumes:
- './grafana:/etc/grafana'
networks:
- db-to-grafana
depends_on:
- db
- influxdb_cli
environment:
- GF_PATHS_CONFIG=/etc/grafana/grafana.ini
- GF_PATHS_DATA=/etc/grafana/data
- GF_PATHS_HOME=/etc/grafana/home
- GF_PATHS_LOGS=/etc/grafana/logs
- GF_PATHS_PLUGINS=/etc/grafana/plugins
- GF_PATHS_PROVISIONING=/etc/grafana/provisioning
user: "1000"
I have a docker container which is brought up with the help of a docker-compose file along with a database container. I want to do this:
Keep the database container running
Schedule the container with my python program to run daily, generate results and stop again
This is my configuration file:
version: '3.7'
services:
database:
container_name: sql_database
image: mysql:latest
command: --init-file /docker-entrypoint-initdb.d/init.sql
ports:
- 13306:3306
environment:
MYSQL_ROOT_PASSWORD: root
volumes:
- ./backup.sql:/docker-entrypoint-initdb.d/init.sql
python-container:
container_name: python-container
build: ./python_project
command: python main.py
depends_on:
- database
volumes:
- myvol:/python_project/data
volumes:
myvol:
Can someone please help me with this? Thanks!
I was just about to ask the same thing. Seems silly to keep a container going 24/7 just to run one job a day (in my case, certbot renew).
I think there may be a way to fake this using the RESTART_POLICY option with a long delay and no maximum retries, but I haven't tried it yet.
EDIT: Apparently restart_policy only works for swarms. Pity.
If the underlying container has a bash shell, you set the command to run a loop with a delay, like this:
while true; do python main.py; sleep 1; done
So I'm trying to setup some docker-compose scripts using some of the latest compose 3.5 features. The big one is being able to name networks. So there are some containers that I end up reproducing over and over again, such as a Postgres database, with various apps I work on. My goal is to be able to have a docker-compose script for something like Postgres, with a named network, which I can then have other apps with their own docker-compose scripts just add on to. It feels more re-usable that way.
Anyway, here is the docker-compose script I'm working with:
version: '3.5'
services:
postgres:
image: postgres:11
container_name: postgres
networks:
- pg_network
environment:
- POSTGRES_PASSWORD=password
- POSTGRES_USER=user
ports:
- 5432:5432
volumes:
- ~/.postgresql/data:/var/lib/postgresql/data
- ~/.postgresql/init:/docker-entrypoint-initdb.d
pgadmin:
image: dpage/pgadmin4
container_name: pgadmin
networks:
- pg_network
ports:
- 5433:80
environment:
- PGADMIN_DEFAULT_EMAIL=user#gmail.com
- PGADMIN_DEFAULT_PASSWORD=password
volumes:
- ~/.postgresql/pgadmin:/var/lib/pgadmin
networks:
pg_network:
name: pg_network
I am trying to use the "custom name" feature new in Docker Compose 3.5. See this link for the documentation: https://docs.docker.com/compose/networking/
However, when I try to run docker-compose up -d, I get the following error:
ERROR: The Compose file './docker-compose.yml' is invalid because:
networks.pg_network value Additional properties are not allowed ('name' was unexpected)
I'm not sure what I'm doing wrong. I'm on Ubuntu 18.04, I'm running the docker commands with sudo (because that seems to be a requirement on Ubuntu).
Here are my Docker and Docker Compose versions:
Docker version 18.09.2, build 6247962
docker-compose version 1.17.1, build unknown
I've tried upgrading them with APT, but it says they are up to date.
So, either I'm making a mistake in my compose script, or there's something screwy with my Docker version. I would appreciate any insight that can be offered. Thank you.
I want to restart a container if it crashes automatically. I am not sure how to go about doing this. I have a script docker-compose-deps.yml that has elasticsearch, redis, nats, and mongo. I run this in the terminal to set this up: docker-compose -f docker-compose-deps.yml up -d. After this I set up my containers by running: docker-compose up -d. Is there a way to make these containers restart if they crash? I noticed that docker has a built in restart, but I don't know how to implement this.
After some feedback I added restart: always to my docker-compose file and my docker-compose-deps.yml file. Does this look correct? Or is this how you would implement the restart always?
docker-compose sample
myproject-server:
build: "../myproject-server"
dockerfile: Dockerfile-dev
restart: always
ports:
- 5880:5880
- 6971:6971
volumes:
- "../myproject-server/src:/src"
working_dir: "/src"
external_links:
- nats
- mongo
- elasticsearch
- redis
myproject-associate:
build: "../myproject-associate"
dockerfile: Dockerfile-dev
restart: always
ports:
- 5870:5870
volumes:
- "../myproject-associate/src:/src"
working_dir: "/src"
external_links:
- nats
- mongo
- elasticsearch
- redis
docker-compose-deps.yml sample
nats:
image: nats
container_name: nats
restart: always
ports:
- 4222:4222
mongo:
image: mongo
container_name: mongo
restart: always
volumes:
- "./data:/data"
ports:
- 27017:27017
If you're using compose, it has a restart flag which is analogous to the one existing in the docker run command, so you can use that. Here is a link to the documentation about this part -
https://docs.docker.com/compose/compose-file/
When you deploy out, it depends where you deploy to. Most container clusters like kubernetes, mesos or ECS would have some configuration you can use to auto-restart your containers. If you don't use any of these tools you are probably starting your containers manually and can then just use the restart flag just as you would locally.
Looks good to me. What you want to understand when working on Docker policies is what each one means. always policy means that if it crashes for any reason automatically restart.
So if it stops for any reason, go ahead and restart it.
So why would you ever want to use always as opposed to say on-failure?
In some cases, you might have a container that you always want to ensure is running such as a web server. If you are running a public web application chances are you want that server to be available 100% of the time.
So for web application I expect you want to use always. On the other hand if you are running a worker process on a file and then naturally exit, that would be a good use case for the on-failure policy, because the worker container might be finished processing the file and you probably want to let it close out and not have it restart.
Thats where I would expect to use the on-failure policy. So not just knowing the syntax, but when to apply which policy and what each one means.