Could you update the image documentation to include all of the environment variables and what they do?

[salimfadhley]

This would make it much easier to get started with the container: A simple list of each environment variable, along with it's intended use.

Thanks

[TimWolla]

Can you clarify what exactly you are missing? I believe the documentation in https://github.com/docker-library/docs/tree/master/adminer contains all the custom environment variables.

[agates4]

I am trying to define the Adminer connection in my docker-compose file.

The only env documented is ADMINER_DEFAULT_SERVER=mysql

Is this the only env available to configure? Is this supposed to be the entire engine params?

[TimWolla]

Is this the only env available to configure?

As documented here you can also configure the style and plugins: https://github.com/docker-library/docs/tree/master/adminer

Is this supposed to be the entire engine params?

This is the only this that can be configured about the login and it's only there, because the default of localhost is absolutely useless in the context of Docker. If you'd like an automated login have a look at #13.

[agates4]

for local development and easy of onboarding developers (using docker to achieve that goal) how can we pass plugins through via the docker-compose file?

[TimWolla]

You'll need to either bind mount the plugin (or plugin configuration) into the container or compile it into a customer Dockerfile.

I don't know docker-compose and thus don't know whether there's an easier solution.

[GottZ]

I am trying to define the Adminer connection in my docker-compose file.

i feel like this was left unnoticed in this issue since this is the actual reason i'm writing here right now.

to give you a small insight in how docker-compose works..

it magically links containers together and ensures they are started in correct order. it also does watchdog stuff.

now to kinda reflect what users like us desire:

version: '3.7'

networks:
  magic:

services:
  db:
    image: postgres:12.2
    restart: unless-stopped
    networks:
      - magic
    environment:
      POSTGRES_USER: $DB_USER
      POSTGRES_PASSWORD: $DB_PASS
    volumes:
      - ./postgresql/data:/var/lib/postgresql/data

  adminer:
    image: adminer:4.7.6
    restart: unless-stopped
    networks:
      - magic
    depends_on:
      - db
    ports:
      - 127.0.0.55:8080:8080
    environment:
      ADMINER_DEFAULT_SERVER: db
      ADMINER_DEFAULT_USER: $DB_USER
      ADMINER_DEFAULT_PASSWORD: $DB_PASS
      ADMINER_DEFAULT_TYPE: postgresql
      ADMINER_DEFAULT_PORT: 5432
      ADMINER_DEFAULT_DB: magic

  actual application:
    ...

why is it so hard to specify these defaults..

one might say "oh no but it's unsafe. don't do that"

i might reply: "oh no. you cannot access 127.0.0.55 anyways so why you bother"

[GottZ]

lol. just stumbled across this abandoned repository: https://github.com/michalhosna/adminer-docker

[TimWolla]

to give you a small insight in how docker-compose works..

I am aware of what docker-compose is on a high level. “Not knowing” is rather “Never used”.

why is it so hard to specify these defaults..

It's out of scope for this image which attempts to provide a “packaged Adminer”. The only bit that modifies the inner workings of Adminer is the replacement of the localhost default value. The remaining modifications do not touch Adminer itself, but rather create a symlink (style) or preconfigure the Adminer plugin array.

one might say "oh no but it's unsafe. don't do that"

Yes, I consider hardcoding the credentials unsafe, because it's too easy to misconfigure.

[lucasbasquerotto]

@TimWolla I agree that being able to assign those settings, be it in environment variables or in a configuration file would be great. I already do that with phpMyAdmin and MySQL and it works great. I found adminer and found it great too, and it's very cool that it can connect to other databases aside from MySQL. But having to enter login and other stuff would be a pain in my case (especially when handling more than 1 server).

The adminer service would be accessible only through a a private network and authenticated with basic auth, and we prefer to use the credentials of the basic auth for our private services (not only adminer) which are easier to rotate passwords (it's just a file) instead of having to rotate passwords on a per service basis, which would be much more complex and error prone when automating. We also use a protection at the reverse proxy layer against CSRF. Furthermore, the credentials to the database would be mostly read-only. So, I don't think it would be unsafe in our case.

Yes, I consider hardcoding the credentials unsafe, because it's too easy to misconfigure.

In our use case we use ansible to automate the server deployment, the docker-compose file is generated from a template and the .env file that will have the password assigned is also created dynamically (and have the correct permissions) with variables coming from a trusted source, with the password encrypted in the source, so it's not hardcoded.

For me environment variables like @GottZ used would be really useful! If there is already a way of doing that using a file I haven't found.

I'm not saying that it must be done just because of my use case, I'm just giving my 2 cents, but it seems there are more people with the same request, so I came here to give a feedback.

[edomato]

Looking for something else I stumbled with this issue 😄

I agree with Tim on this one that hardcoding credentials on files is unsafe.

Adminer is a web based management system for different databases done in PHP.

Saying that, what I do is, if I'm tired to enter the credentials at the login page all the time, I just save them with the browser option to remember credentials that is far more secure that having them around on a file.

Just my two cents 😉

[pollier]

Being able to configure servers / plugins / credentials by using environment variables is just an absolute standard in the docker / kubernetes world, this is not unsafe, hardcoding here is a docker compose problem not an adminer one.

• As an Adminer user i want to use adminer on my company DB host without having to seek credentials that are rotated every day.
• As a devops i want to deploy adminer to my kubernetes cluster, the adminer pods must share credentials from my application secrets which are exposed as env vars or files
• As a devops i don't want to send DB credentials to people every day as adminer is deployed behind corporate SSO that already handle authentication & 2FA

[TimWolla]

@pollier I'm aware of the the concept of using environment variables to pass credentials and in the context of Kubernetes this might be safely done, because the are not directly exposed to the user and can be changed in a central location.

But Kubernetes is not the only way this Docker image is going to be consumed. I'm seeing and using this primarily as a development tool, because IMO one should not poke around in a production database manually, but properly reviewed scripts / Ansible Playbooks / whatever.

Further different consumers have different needs and Adminer contains a plugin system that allows you to configure the authentication to your needs. Here's a non-core plugin that should be able to do the trick: https://github.com/giofreitas/one-click-login. You can access environment variables in PHP using $_ENV['stuff'].

Anything that I'll build in the image will cause limitations for someone and diverge the image from the stock Adminer experience.

[cglacet]

Yes, I consider hardcoding the credentials unsafe, because it's too easy to misconfigure.

Does that mean some people use adminer to access their database in production? I've always though adminer was only used locally to access a test database (with only mocked up data in it).