To protect persistent data it's common to use a VOLUME in the Dockerfile to automatically generate and mount a volume for the container on the host.
Best practice when running these containers should be to used a named volume at that point to ensure persistent when the container is updated.
If VOLUME is not in the Dockerfile then there is a risk of data loss on container updates with an admin not paying attention to which data should be persistent.
I'd suggest we should allow VOLUME in the guidelines for the container maintainer to be clear what is considered important data that must be persisted but we should have a way of making it clear what should be declared at runtime.
An example would be the owncloud container review request which makes the httpd and owncloud configuration directories volumes for persistence and allow customisation, and makes the owncloud data directory a volume to prevent data loss.
Metadata Update from @dustymabe: - Issue tagged with: containers
Metadata Update from @jberkus: - Issue tagged with: VFAD
Metadata Update from @jberkus: - Issue untagged with: VFAD - Issue set to the milestone: 2017-03-10 VFAD
Suggested text for the guidelines here:
https://fedoraproject.org/wiki/Talk:Container:Guidelines
Update from VFAD: Maintainers will be required to explicitly declare all required Volumes in the Dockerfile. RUN/USAGE should contain examples of mounting the volumes. HELP should contain a verbose description of each Volume and what its requirements are.
Container guidelines being updated.
Metadata Update from @jberkus: - Issue assigned to jhogarth
@jhogarth I looked at your suggested guidelines.
One I think we should add is:
"Unless the image is intended for use as a system container intended for system administration, volumes must be defined so as to mount system directories which are exclusive to the container. For example, the container must mount /etc/application-name/ for config files, not /etc/."
jberkus to merge jhogarth's text into the Container:Guidelines, then assign to jasonbrooks for tracking.
Metadata Update from @jberkus: - Assignee reset
Metadata Update from @jberkus: - Issue assigned to jberkus
Guidelines updated. Turing over to @jasonbrooks to track for notifying maintainers.
Metadata Update from @dustymabe: - Issue assigned to jasonbrooks (was: jberkus)
Log in to comment on this ticket.