On Tue, 14 Oct 2014, Jay Pipes wrote:
This means you now have to know the system administrative comments and setup
for two operating systems ... or go find a Fedora20 image for mysql
somewhere.
For sake of conversation and devil's advocacy let me ask, in
response to this paragraph, "why [do you] have to know [...]?"
If you've got a docker container that is running mysql, IME that's _all_
it should be doing and any (post-setup) management you are doing of it
should be happening by creating a new container and trashing the one
that is not right, not manipulating the existing container. The
operating system should be as close to invisible as you can get it.
Everything in the Dockerfile should be about getting the service to
a fully installe and configured state and it should close with the
one command or entrypoint it is going to run/use, in the mysql case
that's one of the various ways to get mysqld happening.
If the goal is to use Docker and to have automation I think it would
be better to automate the generation of suitably
layered/hierarchical Dockerfiles (using whatever tool of choice),
not having Dockerfiles which then use config tools to populate out
the image. If such config tools are necessary in the container it is
pretty much guaranteed that the container is being overburdened with
too many responsibilities.
[1] Is there an official MySQL docker image? I found 553 Dockerhub
repositories for MySQL images...
https://github.com/docker-library/mysql
Docker-library appears to be the place for official things.
By layered model, are you referring to the bottom layer being the Docker
image and then upper layers being stuff managed by a configuration management
system?
I assume it's the layering afforded by union file systems: Makes
building images based on other images cheap and fast. The cheapness
and fastness is one of the reasons why expressive Dockerfiles[1] are
important: each line is a separate checkpointed image.
[1] That is, Dockerfiles which do the install and config work rather
than calling on other stuff to do the work.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
