Hi, Mark -
> [...] Later, if newer PCP packages are released for the same version
> of Fedora, end-users can docker exec into a container of that image
> and upgrade PCP and/or whatever other packages. That can also enable
> non-default PMDAs and make configuration changes, etc.
(Or permanentish configuration changes could be expressed by end-users
as new container images (COPYing over /etc/pcp files in the
Dockerfile).)
> [...]
> > docker run pcp-collector /etc/rc.d/rc_pmie
> > docker run pcp-collector /etc/rc.d/rc_pmlogger
> >
> >One image, two containers running different software.
>
> that would work, but it's kind of at odds with the RUN label and
> layering concepts used by atomic where container images are inexpensive
> snapshots of a base image, each with it's own RUN label [...]
Sure, the atomic labels function here like shell scripts creating
docker command line options. (Docker per se doesn't have that
ability.) So are we targeting atomic?
> [...] Perhaps we should be thinking of PCP services as "the
> application" to be run in one container, much as you
> suggested. i.e. a 'collector' container image for the pmcd, pmlogger
> and pmie services, and a 'monitor' container image for the
> monitoring tools. [...]
Or container(image)s as deployment scenarios: local collection only
(pmcd), local default pcp ops (pmcd + pmlogger + pmie), central
monitoring (-> pmmgr), web rendering (-> pmwebd) etc.
> sorry for waffling on so much, but we need to get this nailed down
> asap.
(Well, perhaps not ... random Dockerfiles are not in that high demand,
even if blessed by a project. They are by design easy to build for
site-specific needs. My guess is that others might use the pcp
build/container files as a model to emulate or get educated by, not
for actual deployment.)
- FChE
|