The volume mount should definitely work whether there’s the -d option or not. I do it all the time.
docker run --rm -p 8888:8888 myluceecontainern
Runs your myluceecontainern image.
However, since you’re just mounting your source directly into the lucee image, we don’t need your built image at all, we can call the lucee/lucee4 image directly:
docker run --rm -p 8888:8888 -v /home/userme/lucee/www:/var/www lucee/lucee4
Accomplishes the same thing but runs lucee/lucee4 as the image (:latest is implicit) rather than the one you built. That’s the only difference.
And yes, if you DON’T use -d, I’d normally use -it (interactive, terminal) so that I can see everything interactively, ctrl-c to make go away.
If you DO use -d, then it’ll go in the background immediately and not show any output - but you can GET the console output using docker logs on the container.
i.e. docker ps
Get the container id
docker logs -f containerid
At that point you’re watching the output from the container just like not using -d - but when you control c you abort the LOGS process not the LUCEE process…
With -d you’d shut down the container with that container id, docker stop containerid, etc.
Your option 2 IS similar… sometimes when you fork a process (not docker) into background with &, it’s still attached to your tty, so when you close ssh it’ll kill the process… since you’re not running with -it it’ll probably just work that way too, or you could introduce setsid, it’s just the -d option is literally there to make the container go into the background, so might as well use it Especially cuz what’s happening architecturally is the docker daemon is running runc and creating a container all in another process so it’s in the background anyway, docker is doing MORE work to show you the output from that background process… so might as well tell it we don’t care and just use -d.
Bonus points: I’m too lazy to type all that crap out, so I just create a docker-compose.yml file:
version: '2.2'
services:
lucee:
image: lucee/lucee4:latest
init: true
container_name: my-lucee-dev
ports:
- 8888:8888
volumes:
- /home/userme/lucee/www:/var/www
environment:
- TZ=US/Eastern
hostname: lucee-dev.local
(container name, environment, tz, hostname all optional - I can’t stand UTC containers)
You need docker-compose: (one-ish liner here)
And then you just hop into your lucee folder and:
docker-compose up
for it to stay on your console, or
docker-compose up -d
to go in the background.
docker-compose down
when you’re done.
Other things you might consider - creating ~/lucee/log and mapping it into your container… I’ll map system logs, tomcat logs, lucee logs etc with volume mounts as well so 1) they persist, and 2) I can access them easily. Sure, lucee’s giving the basic tomcat output, but if you want to dig into the access log, or system logs, or catalina logs directly, you’re going to end up exec bash’ing into the container and mucking around - it can be more convenient to map that outside the container for troubleshooting. Especially if later you decide you want to move up to a lucee4-nginx image and now you have MORE logs to deal with.
[Obligatory discourse on docker logging in general, using ELK/EFK, logstash, filebeat, syslog replication and any other method of NOT volume mapping logs deliberately omitted]