When building container images, we should include only the services that are absolutely essential for the application the container will host. Anything extra wastes resources and widens the potential attack vector that could ultimately lead to security problems. For example, it is not good to run an SSH server inside the container because we can use the Docker exec call to interact with the containerized application. The related suggestions here are to create a new directory and include the Dockerfile and other relevant files in that directory. Also consider using .dockerignore to remove any logs, source code, and so on before creating the image. Furthermore, make it a habit to remove any downloaded artifacts after they are unzipped.
It is not correct to use different images or even different tags in development, testing, staging, and production environments. The image that is the source of truth should be created once and pushed to a repository. That image should be used for different environments going forward. Any system integration testing should be done on the image that will be pushed into production.
The containers produced by the Docker image should be as ephemeral as possible. By ephemeral, it is meant that it can be stopped and destroyed and a new one can be built and put in place with an absolute minimum of setup and configuration.
The best practice is to not keep critical data inside containers. There are two prime reasons for this. When containers collapse inadvertently or deliberately, the data inside them gets lost immediately. The second reason is that the security situation of containers is not as good as virtual machines, and hence storing confidential, critical, customer, and corporate information, inside containers is not a way forward. For persisting data, there are mechanisms to be used. The popular ELK stack could be used to store and process logs. If managed volumes are used during the early testing process, then it is recommended to remove them using the -v switch with the docker rm command.
Also, do not store any security credentials in the Dockerfile. They are in clear text and this makes them completely vulnerable. Do not forget to use -e to specify passwords as runtime environment variables. Alternatively, --env-file can be used to read environment variables from a file. Also, go for CMD or ENTRYPOINT to specify a script, and this script will pull the credentials from a third party and then configure the application.