Persistant modification of config file

[drewwells]

Mounting the config file is a more reliable way of configuring a container.

[kurtharriger]

While there is nothing wrong with mounting your own config file, I prefer the current workflow.

When no config file exists docker-sinopia will generate one with a unique random password. Thus modifying the config is only required if the defaults are insufficent. If users just download a default file rather than modifying the generated file, they will not get a uniquely generated password.

Additionally, this method requires access to the docker host. The current method only requires a docker client.

[drewwells]

This makes the install very difficult and user unfriendly for a perceived
permission problem. Root has access to the container not the host. You
would never use a system like this as container only, it just doesn't make
any sense to lose all your private modules on every container death.
On Tue, Nov 25, 2014 at 7:20 PM Kurt Harriger notifications@github.com
wrote:

While there is nothing wrong with mounting your own config file, I prefer
the current workflow.

When no config file exists docker-sinopia will generate one with a unique
random password. Thus modifying the config is only required if the defaults
are insufficent. If users just download a default file rather than
modifying the generated file, they will not get a uniquely generated
password.

Additionally, this method requires access to the docker host. The current
method only requires a docker client.

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[kfatehi]

Can we have both? It's a README so we should explain pros and cons of either approaches

[kurtharriger]

The container is not destroyed with the process dies. If the process dies you simply need to restart it with docker sinopia start. Docker run requires an image and creates a new container, docker start takes an existing container and reruns it. The data can be accessed from another container using --volumes-from sinopia when starting a new container e.g. to create a backup. In docker 1.3 you could also use docker exec in which case you don't even need mount the volume into a separate container.

Keeping the data in the container makes it easy to get started but at some point you probably want to upgrade sinopia without losing your data. The simplest way to do this is to point the new image at the container with the data:

docker stop sinopia 
docker run --name sinopia-v14 -d -p 4873:4873 --volumes-from sinopia keyvanfatehi/sinopia:0.13.0

Unfortunately, this means that you need to drag around the initial installation for forever, but seemed tiny compared to artifact storage. A better strategy might be to use a data only container to more cleanly separate app code and data.

Mounting a host volume is a great alternative to data only containers if you don't mind making some configuration changes to the host. You will need to mkdir the mount point, create user on the host with id 1000 and chown/chmod the mount point.

It seems unnecessary to me to separate the config from the data since you probably want to backup both the config file and your modules.

[drewwells]

You can reference old containers but containers are best utilized as throwaway environments. As described in num. 3 here: http://nathanleclaire.com/blog/2014/07/12/10-docker-tips-and-tricks-that-will-make-you-sing-a-whale-song-of-joy/.

Containers are difficult to pass around, images are dead simple to pass around. When a container is removed, all data is lost. Data added to images is easily used to build any number of containers.

The common practice for container configuration like this is to allow overriding of configuration via environment variables passed to the container. This would make the setup even easier to get docker-sinopia going rather than requiring people to checkout a config file and mount it inside the container.

docker run -it -e PORT=10000 --rm sinopia 

[kurtharriger]

I agree that docker is easiest to deploy for throwaway services. But sinopia does need to persist its data... so you need to put it somewhere.

We have generic chef recipes to provision a docker host, host customizations require additional provisioning steps that need to be automated with chef.. yuck. If you don't mind customizing your docker host a host volume mount is a great solution and you should do that, but I prefer just using the docker container.

In either case you need to backup your data to recover from a host failure. If the data is stored in the container you can use docker export to create a backup from any machine with a docker client installed (e.g. jenkins job that exports data and uploads backup to aws s3). If the data is on the host, well then you need to login to the host to create a cron job to do the backup since the files on the host rather than in the container. The export tar file can easily be used to create a new image, or to restore your data into a new container if you would rather do that rather than keeping the old container around.

PORT does not need to change in the config file since you can map it to any host port when you run sinopia for the first time. But I otherwise agree that any commonly changed config settings such as enabling the web ui or maybe for setting the initial admin password could be specified via env. gen_config can then check the env for common overrides so that the user gets the right config from the start... but there are lots of options and I don't think it makes sense for every option to have an env setting. Ideally, the defaults should be reasonable enough that most users don't need to change anything.

[preflightsiren]

@drewwells thanks for PR, lets include both options for creating/managing the config