To deal with data going away once the container is shut,
I’m trying to implement a command to mount a persistent volume. That way, people can swap the containers(for upgrades, etc) aggressively without fearing loss of data.
root@docker-ubuntu-9:~/apache2-Docker# docker run -it -d -p 9000:9000 -p 8000:8000 -P --name mavenLOG -v /root/apache2-Docker/mavenLOG/:/var/log maven-apache2-test02
27125546z622992f301788c49ab99279cfe71e30a399b26bbc8a5c83050cd56c
root@docker-ubuntu-9:~/apache2-Docker#
root@docker-ubuntu-9:~/apache2-Docker# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
27125546z622 maven-apache2-test02 "/usr/bin/supervisord" 16 seconds ago Exited (2) 16 seconds ago mavenLOG
Want:
(1) Host has this folder
root@docker-ubuntu-9:~/apache2-Docker# ls
all-in-one mavenLOG
(2) Container has /var/log going on and writes when apps start
(3) I want to new containers to respect the data already present and NOT overwrite or replace but read and write from then on
(4) We have existing ports being used that I used to spawn with “docker run -it -d -p 9000:9000 -p 8000:8000 maven-apache2-test02” BEFORE the persistent command
But container keeps on dying. What am I doing wrong here?
Is simply volume/folder mapping not allowed in Docker? I don’t need to mount any new volumes on the container.
Why not make a volume using docker volume create and share that (passed to the containers using -v volumename:/mount/path notation)? This will persist them and that would allow you to share in a slightly more robust way than bind mounts (no need to bring the host filesystem into it unless you have to).
$ docker volume create --name logdir
logdir
$ docker run -v logdir:/var/log alpine sh -c 'echo INFO Web request served in 200ms >>/var/log/server.log'
$ docker run -v logdir:/var/log alpine sh -c 'echo INFO Web request served in 180ms >>/var/log/server.log'
$ docker run -v logdir:/var/log alpine cat /var/log/server.log
INFO Web request served in 200ms
INFO Web request served in 180ms
Impossible to say without more information – what does docker logs say?
Also, usually it’s best to only run one processes (I think you want maven here) in the container directly, and not use things like supervisord unless you are 100% you know you need them.
We need “supervisord” for running simultaneous app(s).
It’s been working great until the “persistent volume” came in. (we used to manually export data until now).
logs below. Would love to make this work under supervisorD.
root@docker-ubuntu-9:~# docker logs 27125546z622
/usr/lib/python2.7/dist-packages/supervisor/options.py:295: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
'Supervisord is running as root and it is searching '
No, you don’t. You can run each in its own container, and view them with docker ps. Running multiple (unrelated) processes together inside of one container will cause you reliability, scalability, and debugging problems down the line (e.g. you will have to restart the DB even if you only need to restart the webapp).
If you’re adamant about running init in a container, at least run one-init-per-service. But supervisord is overkill if you don’t have a very specific reason (e.g. zombie reap) that you need it.
The type of problem you’re seeing here is exactly what I’m talking about. You’re stuck debugging an opaque supervisord error instead of debugging your app directly.
At any rate, why don’t you specify the configuration file explicitly (using -c) like the error message suggests?