Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing of environment variables does not match behaviour of docker-compose #491

Open
ztane opened this issue May 2, 2022 · 8 comments
Open
Labels
bug Something isn't working

Comments

@ztane
Copy link

ztane commented May 2, 2022

Given compose file

---
version: '3.7'
services:
  test:
    image: ubuntu:20.04
    container_name: ubuntu
    environment:
    - FOO
    command: bash -c 'set | grep FOO'

and having the FOO set in .env, the variable is not passed into the container. Using - FOO=${FOO} works but either one works with docker-compose.

podman-compose version: 1.0.4
using podman version: 3.4.2

@ztane ztane added the bug Something isn't working label May 2, 2022
@ztane ztane changed the title Passing environment variables do not match docker-compose Passing of environment variables does not match behaviour of docker-compose May 2, 2022
@john-waczak
Copy link

Just ran into the same issue

@acteq
Copy link

acteq commented May 27, 2022

agree

@ifoughal
Copy link

ifoughal commented Jul 1, 2022

I've also run into this issue, including the fact that I can't map my variables to my docker-compose values.

Eg:

---
version: '3.7'
services:
  test:
    image: $DIST:$VERSION
    container_name: $DIST
    environment:
    - FOO

This build would fail, as podman-compose fails to load the DIST and VERSION while attempting to spin up the container.

@l3ender
Copy link

l3ender commented Jul 15, 2022

We ran into issues when environment variables had quotes, e.g. - FOO="abc". Once we removed quotes, the - FOO=${FOO} approach worked.

@xmnlab
Copy link

xmnlab commented Oct 25, 2022

I had the same issue here.

I am used to use something like this with docker-compose:

ports:
      - ${POSTGRES_PORT}:${POSTGRES_PORT}

and it gets the value from the .env file:

env_file:
      - ../.env

with podman-compose it doesn't work.

but if I export this variable before I run the podman-compose command, it works just fine.

@devurandom
Copy link

devurandom commented Dec 8, 2022

When running docker-compose -f docker-compose.yml -f docker-compose.extras.yml up with these files:

# docker-compose.yml
version: "3.2"
services:
  srv:
    environment:
      - MY_VAR

and

# docker-compose.extras.yml
version: "3.2"
  srv:
    environment:
      - MY_VAR=value

I get:

['podman', '--version', '']
using podman version: 4.3.1
Traceback (most recent call last):
  File "/usr/bin/podman-compose", line 33, in <module>
    sys.exit(load_entry_point('podman-compose==1.0.3', 'console_scripts', 'podman-compose')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/podman_compose.py", line 1774, in main
    podman_compose.run()
  File "/usr/lib/python3.11/site-packages/podman_compose.py", line 1021, in run
    self._parse_compose_file()
  File "/usr/lib/python3.11/site-packages/podman_compose.py", line 1090, in _parse_compose_file
    rec_merge(compose, content)
  File "/usr/lib/python3.11/site-packages/podman_compose.py", line 917, in rec_merge
    ret = rec_merge_one(target, source)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/podman_compose.py", line 907, in rec_merge_one
    rec_merge_one(value, value2)
  File "/usr/lib/python3.11/site-packages/podman_compose.py", line 907, in rec_merge_one
    rec_merge_one(value, value2)
  File "/usr/lib/python3.11/site-packages/podman_compose.py", line 907, in rec_merge_one
    rec_merge_one(value, value2)
  File "/usr/lib/python3.11/site-packages/podman_compose.py", line 895, in rec_merge_one
    raise ValueError("can't merge value of {} of type {} and {}".format(key, type(value), type(value2)))
ValueError: can't merge value of HOSTING_DOMAIN of type <class 'NoneType'> and <class 'str'>

@superev12
Copy link

Also have this issue. For docker-compose.yaml with the content

services:
  postgres:
    image: "postgres"
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=postgres
    ports:
      - "5432:5432"

When running the container,
POSTGRES_USER=user
POSTGRES_PASSWORD=pass
POSTGRES_DB=db

and port 5432 is instead mapped to 35432.

@Movion
Copy link

Movion commented Dec 15, 2023

Any news for this? I also had the problem with podman-compose & mattermost as root when using variables

When im using the recommended .env file example and change postgres information, it is not forwarded to the container.

How to reproduce:
Use the env example file of mattermost, copy to .env, change the postgres information,:

POSTGRES_USER=mmuser
POSTGRES_PASSWORD=yourbelovedpassword
POSTGRES_DATABASE=mattermost

docker-compose.yml is having this information:

      # necessary Postgres options/variables
      - POSTGRES_USER
      - POSTGRES_PASSWORD
      - POSTGRES_DB

When you hit the command to start:
podman-compose --env-file=./.env -f docker-compose.yml -f docker-compose.nginx.yml up -d

The containers are starting up, but the variables are not forwarded
Seeing in the logs of the postgres container:
postgres mm db

Fix:
It got fixed by adding the =${varibale} in the docker-compose.yml

      # necessary Postgres options/variables
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=${POSTGRES_DB}

Than it works.. had todo this to all other variables too.

Docker also "recomment" todo this: https://docs.docker.com/compose/environment-variables/set-environment-variables/

The result is similar to the one above but Compose gives you a warning if the DEBUG variable is not set in the shell environment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

9 participants