----- Original Message -----
> > [...]
> >
> > Bottom line, instead of separate Dockerfiles for these different usage
> > cases, we could ship -shell scripts- that invoke the basic docker
> > images differently.
>
> well, basically we already do, but instead of supplying different shell
> scripts to exec on the docker-run command line for containers of a common
> underlying image, we use layering to share the underlying image as the origin
> of several snapshots, and supply specific RUN and CMD labels to specify
> what to run in the resulting containers. The atomic command extracts the
> RUN label and uses it to invoke the docker run command, but the underlying
> storage uses inexpensive snapshots of the common base image (Fedora +
> pcp-base).
Layering is good IMO - people should be able to pick the bits they want and
construct containers that suit their environment. IMO, once selected (i.e.
pmcd on, pmdaapache on, pmdaelasticsearch on, etc) in the container image,
it should be fully configured (PMDAs ./Install'd) & ready to go.
This ship-everything-and-let-user-interaction-via-scripts-do-all-the-work
model means we need to do things differently to people who'll add PMDAs for
their own production environments (custom, in-house PMDAs). In the current
plan these were going to (be able to) arrive as layered images just like
all the other optional PCP PMDAs. This still seems a good approach to me.
Remember that some PMDAs will pull in perl &| python, which means a ton of
extra stuff - and the vast majority of people do not need or want these.
> I'd like to keep this discussion going though - e.g. with pcp-collector (for
> live pmcd) and pcp-pmlogger (for archive logs) the premise for enabling
> non-default PMDAs is that we would docker-exec into a running container
> and make the configuration changes.
There were two alternate plans, with the above being the easiest hack IIRC.
The alternative was separate images layered on pcp-collector-with-default-PMDAs
which still seems better to me, although more work.
cheers.
--
Nathan
|