Hey thank you for getting back to me and I apologize for waiting several days I’ve had a busier week than normal.
Alright, code.
For some reason I had in my head that I could not use docker-compose on Windows machine and that it had given me errors but checking it now it works fine. Huh. I guess I can’t even trust myself.
From reading here: docker: 'compose' is not a docker command when installing using convenience scripts · Issue #8630 · docker/compose (github.com)
I would think there is no difference between using ‘docker-compose’ command vs ‘docker compose’ command.
Even so I will test the difference.
Test 1: Using the Windows machine and Docker Desktop I’m gonna run one test using docker-compose and another using docker compose to see if that is where the output difference is coming from.
Using the same dockerfile provided in the demonstration github repo:
FROM internetsystemsconsortium/bind9:9.16
VOLUME /etc/bind
COPY ./master/ns1.named.conf /etc/bind/named.conf
COPY db.example.internal /etc/bind/db.example.internal
RUN chown root:bind /etc/bind ; chmod g+rwx /etc/bind
RUN chown root:bind /etc/bind/named.conf ; chown root:bind /etc/bind/db.example.internal
#USER bind
Run 1 Commands:
docker volume prune
docker-compose -f .\ns1.docker-compose.yml build #Result: Success
docker-compose -f .\ns1.docker-compose.yml up #Result: Success
docker-compose -f .\ns1.docker-compose.yml down #Result: Success
Run 2 Commands:
docker volume prune # Just to be sure
docker-compose -f .\ns1.docker-compose.yml down # Just to be sure
docker-compose -f .\ns1.docker-compose.yml up build # Success
docker-compose -f .\ns1.docker-compose.yml up # Success
docker-compose -f .\ns1.docker-compose.yml down # Success
docker volume prune # Cleanup
Results: On the Windows system both commands produced the same results.
Note: Docker Desktop which I use on Windows did get an update this week to move to v2.0.0-rc.3
Test 2: I think it’s interesting that the chown command is not needed for a Mac. I’m going to test the same on my Windows and Ubuntu Machines. The result on both the linux and the Windows machines is that the container is automatically owned by the bind group. That’s good news
Test 3: No longer using docker-compose but using just docker and using the following Dockerfile. Both systems are running Docker version 20.10.8, build 3967b7d
FROM internetsystemsconsortium/bind9:9.16
RUN chmod g+rwx /etc/bind
Windows:
docker image build -t mybind:latest .
# Builds fine
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 31B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/internetsystemsconsortium/bind9:9.16 1.9s
=> [1/2] FROM docker.io/internetsystemsconsortium/bind9:9.16@sha256:741c12d794f1af570898d37288635366ead7d9a1ee4a 0.0s
=> CACHED [2/2] RUN chmod g+rwx /etc/bind 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:9cf71c8cd1ff3bab424702906965b1d597773d447820bb915fd8e19a44be44b8 0.0s
=> => naming to docker.io/library/mybind:latest
docker run mybind:latest ls -la /etc/bind
# Results: Looks good.
total 56
drwxrwsr-x 2 root bind 4096 Sep 26 01:59 .
drwxr-xr-x 1 root root 4096 Sep 26 01:59 ..
-rw-r--r-- 1 root root 1991 Sep 16 07:55 bind.keys
-rw-r--r-- 1 root root 237 Sep 16 07:54 db.0
-rw-r--r-- 1 root root 271 Sep 16 07:54 db.127
-rw-r--r-- 1 root root 237 Sep 16 07:54 db.255
-rw-r--r-- 1 root root 353 Sep 16 07:54 db.empty
-rw-r--r-- 1 root root 270 Sep 16 07:54 db.local
-rw-r--r-- 1 root bind 463 Sep 16 07:54 named.conf
-rw-r--r-- 1 root bind 498 Sep 16 07:54 named.conf.default-zones
-rw-r--r-- 1 root bind 165 Sep 16 07:54 named.conf.local
-rw-r--r-- 1 root bind 846 Sep 16 07:54 named.conf.options
-rw-r----- 1 bind bind 100 Sep 21 19:30 rndc.key
-rw-r--r-- 1 root root 1317 Sep 16 07:54 zones.rfc1918
Linux:
docker image build -t mybind:latest .
# Built fine
Sending build context to Docker daemon 2.048kB
Step 1/2 : FROM internetsystemsconsortium/bind9:9.16
---> 225a67715eb2
Step 2/2 : RUN chmod g+rwx /etc/bind
---> Running in 70f313e8dbaa
Removing intermediate container 70f313e8dbaa
---> 7bc872eeee26
Successfully built 7bc872eeee26
Successfully tagged mybind:latest
docker run mybind:latest ls -la /etc/bind
# Ahhhh there it is.
total 56
drwxr-sr-x 2 root bind 4096 Sep 26 02:09 .
drwxr-xr-x 1 root root 4096 Sep 26 02:09 ..
-rw-r--r-- 1 root root 1991 Aug 20 12:41 bind.keys
-rw-r--r-- 1 root root 237 Aug 20 12:40 db.0
-rw-r--r-- 1 root root 271 Aug 20 12:40 db.127
-rw-r--r-- 1 root root 237 Aug 20 12:40 db.255
-rw-r--r-- 1 root root 353 Aug 20 12:40 db.empty
-rw-r--r-- 1 root root 270 Aug 20 12:40 db.local
-rw-r--r-- 1 root bind 463 Aug 20 12:40 named.conf
-rw-r--r-- 1 root bind 498 Aug 20 12:40 named.conf.default-zones
-rw-r--r-- 1 root bind 165 Aug 20 12:40 named.conf.local
-rw-r--r-- 1 root bind 846 Aug 20 12:40 named.conf.options
-rw-r----- 1 bind bind 100 Aug 25 14:43 rndc.key
-rw-r--r-- 1 root root 1317 Aug 20 12:40 zones.rfc1918
So that’s an interesting find. It’s not even with Docker compose. It’s with Docker. Both systems are running the same version. Same build. One produces one result, another produces a different result.
I’m thinking I should post this as an issue in the Docker github.