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 :smile:

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 :wink:

[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).

[TimWolla]

@cglacet

Does that mean some people use adminer to access their database in production?

Reading the comments above and also the other issues that are created in this repository: Yes, they do.

In fact for a local test database that is not reachable via the Internet the request to store credentials probably would be less important, because a username / password combination of root:root would be acceptable from a security perspective and it would also be easy enough to type in quickly.

[mtariqsajid]

these environments are not working.

are they implemented in this docker image of adminer? or they will be implemented in future ?

ADMINER_DEFAULT_USER: $DB_USER
ADMINER_DEFAULT_PASSWORD: $DB_PASS
ADMINER_DEFAULT_TYPE: msqyl

[lucasbasquerotto]

@mtariqsajid They are variables that a user above posted as a request (example), I don't think the docker image supports it, and I don't know if it will support (it is what this issue is about tough).

[mtariqsajid]

user above p

they should support this it will much easy to set adminer with multiple docker images for development

[TimWolla]

As I explained many times before I won't be supporting these environment variables. I've explained possible solutions if you want to use these for your specific use-case.

[lucasbasquerotto]

I think this issue should be closed then (if the feature will not be implemented).

[DasSkelett]

Can we at least get

ADMINER_DEFAULT_USER: $DB_USER
ADMINER_DEFAULT_TYPE: msqyl

?

Not allowing configuration of the password is an argument I can understand, even though I don't agree. But db type and user are not security sensitive (talking about the default postgres user in a dev env here), and would already solve most of the inconveniences I have with this Docker image.

[mk-pmb]

I guess the better path forward would be to request on the upstream Adminer repo to read config from environment variables. Requesting it here for just the docker image, for me seems to be the wrong place.

[mk-pmb]

However, I agree that the readme here should describe which env vars it adds, and what ways there are to configure upstream Adminer via env vars. (Even in case the latter currently is "none".)

[zipzit]

Here's my dilemma. I need to be able to view, review and edit database content in initial development. docker-compose.yml test:

version: "3.8"
services:
    mysql_db:
        image: mysql:latest
        ports: 
          -  3307:3307
        environment:
          -  MYSQL_ROOT_PASSWORD=secret
        volumes:
            - ./mysql_db_data:/var/lib/mysql
            
    phpmyadmin:
        image: phpmyadmin
        restart: always
        environment:
          PMA_HOST: mysql_db
          PMA_USER: root
          PMA_PASSWORD: secret
        ports:
          - 8081:80
          
    adminer_container:
        image: adminer:latest
        environment: 
            ADMINER_DEFAULT_SERVER: mysql_db
            ADMINER_DESIGN: galkaev
            ADMINER_PASSWORD: secret
            ADMINER_USERNAME: root
        ports: 
          - 8080:8080
          
volumes:
    mysql_db_data: {}

I understand the security issues. Try this for yourself. docker-compose up -d . Then http://localhost:8080 (for adminer) http://localhost:8081 (for phpmyadmin)

Phpmyadmin works great, right out of the box. Adminer, No go.

This failure to populate login/password seems to be a sales pitch (for those of us who are admittedly often busy) the use of phpmyadmin instead of adminer. My focus needs to remain on coding a solution to the clients need not one off customizations of what should be standard tooling for my team. Keep it simple, make it work. Am I looking at this wrong?

By the way. Don't mean to be demeaning or ungrateful to Tim and the folks that support this repo. They've obviously put in a whole lot of work. Many thanks. I'm just frustrated that this one miss degrades the entire effort to use this amazing package. And that just drives me crazy. Again, many thanks to Tim.

[mk-pmb]

@zipzit

Adminer, No go.

Indeed. Unfortunately the main Adminer repo is not open for issues, and their forum is cumbersome. Nevertheless, the request for easy server config via environment variables is a feature request best sent to upstream, i.e. Adminer itself, not for this docker wrapper.

@TimWolla Considering how often this feature is requested here, I think it's even worth explaining in the readme, where to beg for this feature.

[agates4]

For my use case, because of this lack of docs, I switched to SqlPad

[TimWolla]

However, I agree that the readme here should describe which env vars it adds, and what ways there are to configure upstream Adminer via env vars. (Even in case the latter currently is "none".)

@mk-pmb Feel free to propose changes as a PR over in docker-library/docs and simply ping me so I can review them.

I think it's sufficiently explained though, all the available configuration knobs are documented and what's not documented isn't there. Pretty simple.

Keep it simple, make it work. Am I looking at this wrong?

@zipzit Not sure if you are looking at this wrong. Let me give a different PoV, though: I'm keeping this image simple by not adding a large number of additional configuration knobs you have to think about when setting up this image.

Additionally upstream Adminer's Number 1 priority is “Security”. Providing database credentials to anyone able to access Adminer does not really fit in there.

Maybe Adminer simply isn't for you? If phpMyAdmin with its configurability better solves your requirements/problems, then I recommend to use phpMyAdmin.

[mk-pmb]

@agates4 Thanks for that recommendation!

@TimWolla In case SqlPad turns out useful for local development with prefilled login, should I add that to the docs PR as well?

[TimWolla]

@TimWolla In case SqlPad turns out useful for local development with prefilled login, should I add that to the docs PR as well?

I'd rather not reference any external products/alternatives, especially products that are not available as an official Docker Image.

[zipzit]

Turns out for my use case (initial software development of a new application), VSCode has a plugin that enables simple queries to mySQL. Reference.... No Adminer, no Phpmyadmin, one less container. No excessive security worries. Less is more.

No offense intended. Again many thanks to the Adminer team for an intriguing product.

[fnagel]

@TimWolla

As I explained many times before I won't be supporting these environment variables. I've explained possible solutions if you want to use these for your specific use-case.

It might help to document those possible solutions.

This works for me when trying to increase upload limits using docker-compose: https://github.com/TimWolla/docker-adminer/issues/36#issuecomment-967527831