Closed peterrus closed 6 years ago
You are correct, there is a file and it could be put in a volume. I have not created lots of configuration possibilities but one solution would be to supply a config file path when starting up websync.
I am trying to get websync to run on my pc, in order to try writing a more robust dockerfile. ~~But for ~~some reason npm/'node-gyp rebuild' keeps recompiling modules (I'm not ~~
experienced with node).
fixed
I am now stuck at #12
configuration seems to be persisted across container lifetimes when running the container in the following way:
sudo docker run -d -p 3000:3000 -v /data-2/backup/hello:/hello -v /srv/data/websync.json:/src/wsdata.json -w /src furier/websync node server.js
I had to touch an empty websync.json file in order for the container to be created
I am now trying to build the container just to test a very small change to the dockerfile, I am wondering, if you have time, if you could make this change for me, it has been quite a hassle to get a build environment working.
The change I am trying to make is:
Add the 'node server.js' startup command at the end of the file (WORKDIR /src) and (CMD node server.js)
Thanks in advance!
I am unsure what you want me to do here, in the Dockerfile I start /src/server.js
with node
as parameters for the CMD
command.
you want me to set it as this?
WORKDIR /src
CMD ["node", "server.js"]
You are totally right, my bad, so if I understand correctly there is no need to specify 'node server.js' in the docker startup command? (as you state in the README.MD).
What readme.md is that? :P
tir. 5. jan. 2016 kl. 18.52 skrev peterrus notifications@github.com:
You are totally right, my bad, so if I understand correctly there is no need to specify 'node server.js' in the docker startup command? (as you state in the README.MD).
— Reply to this email directly or view it on GitHub https://github.com/furier/websync/issues/31#issuecomment-169079899.
Because the configuration of the application is not managed through a volume, every time you recreate the container, all configuration is lost. This breaks one of the basics of containerization, and in practicality is just not that great, because I tend to recreate my container when migrating servers or pulling in a new version of the image.
I'm not entirely familiar with websync yet, but there must be some configuration database or file that can be put in a volume.