Supposed lifecycle

[mgumerov]

Hello! I do not know docker well yet, but from what I learned, one cannot "re-run" a container.
So, from my perspective which is probably wrong, there are but two approaches to using "db-instance".

1. We run the image, thus producing a container. There in a shell we execute .\createInstance, which makes some changes to a running container. Then we stop a container (say, our host machine needs to be shut down), and all the changes are lost, since we did not commit them. Then after power-on we remove the container, and once again "run" the image. This approach works fine, but it's both clumsy since the necessity to manually remove dead containers, and likely useless since no one will want to use enterprise grade database with no data persistence :)
2. We run the image, thus producing a container; with that command, we also specify options to mount data volumes for database storage. Then in a container shell we execute .\createInstance, which makes some changes to a running container. We then commit the container, so that in the future we can just "start" it from that point and it will "resume" servicing the database. Since the database itself resides in a mounted data volume, it is persistent.

Is there another way to use the image AND provide persistense? Without using "commit", every time we "run" or "start" the image, the container will be in an "initial" state: no user created, no db2start on a path, etc; worse, createInstance fails if the database already exists. Say, I would like to simply start up a DB2 TCP server and use the database created in a previous "run"; I start it, but now I cannot use createInstance! Well, I can and it even does something, but the TCP server is not started, and somewhere along the way I see an error message about database already being there. I suppose I could simply use db2start but it's not on a path and I am not even sure the container is ready to use it in this state, maybe it still requires some preparations, like creating a user.

In principle, the (2) approach works for me. It's bad from the automation point of view, though: I will have some script on a first run to run the image with keeping stdin open, and DON'T wait for completion lest the wait will be infinite; but, not waiting for completion, I will still want to wait for completion, to understand when it's time to (automatically, not manually) commit the container and maybe stop it. Or, I could have the script run the image without keeping stdin open and wait for completion, that's much easier, but this stores in a config that "this container does not require keeping stdin open", and when later I "start" it, guess what? it simply shuts down by itself, since no commands come from the user ("start -a -i" does not help). And if there is a way to "run" the container without "-t -i" and then somehow turning them ON in config for subsequent "start", I am not aware of it :(

Maksim