search

snipe / snipe-it

A free open source IT asset/license management system
https://snipeitapp.com
GNU Affero General Public License v3.0
10.88k stars 3.14k forks source link

docker-compose env file not recognized after initially working with "docker run" #11720

Open miltonh26 opened 2 years ago

miltonh26 commented 2 years ago

Debug mode

Describe the bug

Snipe Docker version:

OS OS: Linux, Manjaro Plasma

Issue: The environment file not found when creating containers using "docker run" and docker-compose.

Expected behavior: That the environment file be found no matter which method is used to create containers.

Description: Ran Snipe-IT successfully creating and running the 2 containers (snipe-it, mariadb) with "docker run" following the snipe online instructions. Started and restarted the containers manually many times and everything worked correctly.

Next, attempted to use docker-compose (after removing the 2 containers) and encountered an issue where the environment file was not recognized, though the file had worked previously when using "docker run". The containers started OK:

$ docker-compose up -d                                                                                                                                                                               
[+] Running 3/3
⠿ Network snipe-it_default       Created    0.0s
⠿ Container snipe-mysql         Started      0.5s
⠿ Container snipe-it-snipe-it-1  Started
$ docker ps -a                                                                                                                                                                                        
CONTAINER ID   IMAGE                        COMMAND                  CREATED          STATUS                     PORTS                                             NAMES
fc85900e980c   snipe/snipe-it               "/startup.sh"            41 minutes ago   Up 41 minutes                 443/tcp, 0.0.0.0:7777->80/tcp, :::7777->80/tcp    snipe-it-snipe-it-1
4339c3369429   mariadb:latest               "docker-entrypoint.s…"   41 minutes ago   Up 41 minutes      3306/tcp                                          snipe-mysql

When I accessed using the webapp I received a DB error in PHP because the env file was not found:

image

Here is the docker-compose.yml file contents:

version: '3'`

services:

  snipe-mysql:
    container_name: snipe-mysql
    image: mariadb:latest
    env_file:
      - .env
    volumes:
      - snipesql-vol:/var/lib/mysql
    command: --default-authentication-plugin=mypassword
    expose:
      - "3306"

  snipe-it:
    image: snipe/snipe-it
    env_file:
      - .env
    ports:
      - "7777:80"
    depends_on:
      - snipe-mysql

volumes:
  snipesql-vol:

Next, went back to creating the containers manually using "docker run" and both snipe-it and mariadb containers reported they could not find the env file:

$ docker run --name snipe-mysql --env-file /home/milton/Applications/Snipe-IT/.env  --mount source=snipesql-vol,target=/var/lib/mysql -d -P mariadb:latest                                               ✔ 
docker: open /home/milton/Applications/Snipe-IT/.env : no such file or directory.
See 'docker run --help'.

Next, started over completely by deleting both the snipe/snipe-it and maria:latest images and ran again using "docker run" for each. They ran and both containers were created successfully, The same PHP DB error occurred from the webapp as above.

I confirmed that docker is not the issue by creating a temp container using an env file and it worked perfectly, so it appears to be an issue with snipe and not docker.

I am at a loss as to why this is happening. Clearly, I did something to trip it up but am not certain what that was with all the changes. Any ideas or suggestions on how to correct to ensure the env is found? Is this a bug?

Thanks.

Reproduction steps

See above

Expected behavior

See above

Screenshots

No response

Snipe-IT Version

docker latest

Operating System

Manjaro

Web Server

none

PHP Version

in docker

Operating System

No response

Browser

No response

Version

No response

Device

No response

Operating System

No response

Browser

No response

Version

No response

Error messages

No response

Additional context

No response

welcome[bot] commented 2 years ago

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

miltonh26 commented 2 years ago

Ran the same docker-compose on a Fedora VM and it too had the same error. Here is the docker-compose log output:

$ docker-compose logs -f Attaching to snipe-it_snipe-it_2_1, snipe-mysql snipe-it_2_1 | Module ssl disabled. snipe-it_2_1 | To activate the new configuration, you need to run: snipe-it_2_1 | service apache2 restart snipe-it_2_1 | snipe-it_2_1 | Illuminate\Database\QueryException snipe-it_2_1 | snipe-it_2_1 | SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Name or service not known (SQL: select * from information_schema.tables where table_schema = snipeit and table_name = migrations and table_type = 'BASE TABLE') snipe-it_2_1 | snipe-it_2_1 | at vendor/laravel/framework/src/Illuminate/Database/Connection.php:712 snipe-it_2_1 | 708▕ // If an exception occurs when attempting to run a query, we'll format the error snipe-it_2_1 | 709▕ // message to include the bindings with SQL, which will make this exception a snipe-it_2_1 | 710▕ // lot more helpful to the developer instead of just the database's errors. snipe-it_2_1 | 711▕ catch (Exception $e) { snipe-it_2_1 | ➜ 712▕ throw new QueryException( snipe-it_2_1 | 713▕ $query, $this->prepareBindings($bindings), $e snipe-it_2_1 | 714▕ ); snipe-it_2_1 | 715▕ } snipe-it_2_1 | 716▕ } snipe-it_2_1 | snipe-it_2_1 | +36 vendor frames snipe-it_2_1 | 37 artisan:35 snipe-it_2_1 | Illuminate\Foundation\Console\Kernel::handle() snipe-it_2_1 | Configuration cache cleared! snipe-it_2_1 | Configuration cache cleared! snipe-it_2_1 | Configuration cached successfully! snipe-it_2_1 | 2022-08-25 01:10:18,011 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message. snipe-it_2_1 | 2022-08-25 01:10:18,015 INFO supervisord started with pid 1 snipe-it_2_1 | 2022-08-25 01:10:19,017 INFO spawned: 'exit_on_any_fatal' with pid 56 snipe-it_2_1 | 2022-08-25 01:10:19,027 INFO spawned: 'apache' with pid 57 snipe-it_2_1 | 2022-08-25 01:10:19,039 INFO spawned: 'run_schedule' with pid 58 snipe-it_2_1 | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.19.0.3. Set the 'ServerName' directive globally to suppress this message snipe-it_2_1 | No scheduled commands are ready to run. snipe-it_2_1 | 2022-08-25 01:10:20,107 INFO success: exit_on_any_fatal entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) snipe-it_2_1 | 2022-08-25 01:10:20,107 INFO success: apache entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) snipe-it_2_1 | 2022-08-25 01:10:20,108 INFO success: run_schedule entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) snipe-it_2_1 | No scheduled commands are ready to run. snipe-it_2_1 | No scheduled commands are ready to run. snipe-it_2_1 | No scheduled commands are ready to run. snipe-it_2_1 | No scheduled commands are ready to run. snipe-it_2_1 | [2022-08-25T08:15:21+07:00] Running scheduled command: '/usr/bin/php7.4' 'artisan' auth:clear-resets > '/dev/null' 2>&1 snipe-it_2_1 | No scheduled commands are ready to run. [remainder truncated]

miltonh26 commented 2 years ago

Started over once more with "docker run" and this time it worked using maria:latest and snipe:latest. My old DB content was picked up. So, still not understanding what happened, but at least it is running again. Could be that my previous APP_KEY was left behind and not deleted before running "docker run" and docker-compose. If that is the case, then a more meaningful error message would be most helpful.

Just ran docker-compose in the Fedora VM and made certain the APP_KEY was not set using the env file. Containers were created but the webapp would not run. Got a 404 error.

uberbrady commented 2 years ago

So glad you got yourself back up and running! But I do think I need to do some work here, regardless, so I’ll keep this open and assigned to me.