But im not happy with recreating containers, i saw in config.yaml, that this file contain wallet address param.
If i will uncomment it, and specify there new wallet address will container use it after restart?
Why not ? It doesn’t destroy your data or harm your computer. Its like restarting your computer for new changes to take effect. Try it!
No, docker parameters take precedence over config.yaml entries. When you have same parameter in config and docker run command then docker’s parameter will be used.
I stopped, removed and restarted my containers countless times, changing various parameters. The data or the image of the container are not affected. When you start a container, you tell Docker: hey Docker, start an instance of a program with the name storagenode1, using as source the image storagenode/latest and with these parameters x y z, and use as data the data in folder …storage and extraconfig that I didn’t already specified in run the parameters in …config.
The images for containers you download in Docker with pull, are downloaded from an online source (aka Docker repository if you didn’t specify other sources), are stored in a local library and reused each time you recreate a container. The image is not affected by anything you do with containers, it’s just like an installation CD. You have the image for storagenode and the image for watchtower. And these are kept by updater to the latest version. I’m still not sure what updater is though, but I believe the Docker itself pulls the latest verions of images and the watchtower just recreates the containers with your run parameters and the newest image when there is a new one.
I hope you get the picture. It’s somehow harder to understand at the begining how things work in Docker, but once you get the picture… I still learning after 3 years .
storagenode image is more sophisticated. Usually docker pulls the image, if it has a different tag from the downloaded already, in case of :latest, it will not do so unless you (or the watchtower) explicitly call the docker pull command.
But our image working in a different way, not a docker-way. It has only a base OS (Debian), a downloader (wget) and a supervisor. The downloader downloads storagenode-updater, and execute it with a supervisor. storagenode-updater downloads the actual storagenode binary archive and unpack it, then starts as a separate process with help of supervisor. Now both services are running inside the container and storagenode-updater periodically checks for updates. Since they both share the same config.yaml, storagenode-updater complains to the logs about unknown (to it) keys like a wallet or email address, etc. but this doesn’t affect anything.
When the updater detects a new version of itself, downloads a new version of itself if it’s available, kill the current and start a new one with a supervisor, the new storagenode-updater process will checks its own version and if it’s updated, it checks for a new version of storagenode. If it detects a new version for storagenode, it compares NodeID with a cursor on version.storj.io, if it’s allowed to update, it downloads a new version of the storagenode archive, kill the current storagenode process, unpacks the archive and start a new version of storagenode with help of the supervisor.
Off top, where I can find list of all params that I can use while creating container?
Like disable filewalker (or limit his intensity), limit logs size etc?
this is not part of the storagenode’s responsibility. Usually this done by the OS, depending on how do you store logs.
If you didn’t redirect logs to the file, your logs are managed by Local file logging driver | Docker Docs
If you redirected logs to the file, then you may use a logrotate service to manage your logs, for example: