output credentials in a folder/file that can be mounted by other containers

iby / docker-riak-cs

AWS S3 inside a Docker container

MIT License

48 stars 19 forks source link

output credentials in a folder/file that can be mounted by other containers #8

Open allan-simon opened 8 years ago

allan-simon commented 8 years ago

We would like to use your container to provide our developers environment (based on a set of docker images) with a local s3, we're using a Vagrantfile to combine the different containers and to do the linking/mounting/provisionning

The problem we're having with your containers is that we can not create a user with read/write access on a bucket (as you state in the readme, if we set the RIAK_CS_KEY_ACCESS and RIAK_CS_KEY_SECRET it fails )

it would be nice to either

output the admin credentials that are currently output in stdout, in a file, e.g /var/whatever/credentials , so that we can mount /var/whatever from other containers
- have environment variables that if set , create a non-admin user that have the read/write rights on the created buckets

iby commented 8 years ago

Output the admin credentials that are currently output in stdout, in a file, e.g /var/whatever/credentials , so that we can mount /var/whatever from other containers.

Nice. Will implement.

Have environment variables that if set, create a non-admin user that have the read/write rights on the created buckets.

Initial feeling is that this is outside the scope of a base image. A few reasons, main – you have admin credentials, you can do this yourself. Out of curiosity, what's your use case?

allan-simon commented 8 years ago

my use case is developer environments and automated tests

for developer environments, the goal we have is that you "vagrant up" and "it just works (tm)" , it it will setup the postgresql database (easy with env variables and default docker image) , install developments tools on top of https://github.com/phusion/baseimage-docker, so here not having to docker logs etc. to get admin credentials permits you to destroy/recreate your environment with minimal steps
for automated tests, the platform we use (gitlab-ci) only permits you to control 1 container directly, and for the others you can only do things permitted by their env variables.

iby commented 6 years ago

2018… 😥 Sorry guys, I'm busy as never before and don't have time for this right now. This is a great idea, if anyone wants to PR I'll happily review it!