On 06/26/2015 11:46 AM, Frank Ch. Eigler wrote:
thanks for the feedback Frank, this stuff is all so new and evolving
that it's really important to get other opinions and ideas where we can
mgoodwin wrote:
[...]
Also, whilst we're discussing it - I've been thinking of changing the
naming a bit, to make it super obvious what each container does, e.g.
pcp-base : base container for layering all other pcp containers
AIUI, that'd be an *image* only.
yes correct - I've been using the terms interchangeably, but really
a container is an instance of a container image - doesn't need to
necessarily be running though - under the covers the container image
is a thin snapshot of it's base image (e.g. pcp-base), which may itself
be a snapshot (e.g. of the standard Fedora base image). And becasue
they're snapshots (or overlays, or whatever, depending on the storage
driver that's in use) they have persistence and thus can be stopped,
restarted, upgraded, etc.
So for now we start with the Fedora base image, upgrade it to the latest
Fedora packages, then install the PCP packages from a local Makeimages
build to create the pcp-base image. Other container images are layered
on that. 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.
pcp-live-collector - live host pmcd, layered over pcp-base
pcp-archive-collector - archive collection, using pmlogger [...]
pcp-monitor - monitoring tools, including gui and py deps. [...]
pcp-pmie or some such name ... for inference and alerting tasks [...]
Perhaps unmixing the container & image terminology can simplify
matters here. The image just needs to contain the software; it's not
a container until some part of it is actually running. And a
container does not have to run all the software in the image.
It's as though we only need a few base images: one for collection side
(smaller), and one for all the monitoring tools (larger). Then,
depending on how the image is run - turned into a container, one could
get a pmlogger or pmie or whatever running inside. i.e., something
like:
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 and CMD (command
to run as pid1). In the above scenario, you're using the optional command
and arguments that can be supplied to docker-run to override the default
program (pid1) to run in the container.
e.g. the pcp-collector container image is based on the pcp-base image,
with the addition of a few extra packages and it's own RUN label, and
a few other things. On disk, pcp-collector is a snapshot of pcp-base,
and thus initially consumes almost no extra space.
We could also consider a pcp-data container or something, where PCP
archives and var/lib data such as pmdaCache and so forth would
reside and be commonly shared [...]
Perhaps that could be a container created from the pcp-base image,
analogously to the "training/postgres" example at [1].
[1]
https://docs.docker.com/userguide/dockervolumes/#creating-and-mounting-a-data-volume-container
thanks, I'll have a look at that
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).
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. But that would have to be done in both
containers at the moment since they're independent shapshots and they're not
currently sharing the pmlogconf configs, nor the pmdaCache data, etc. An
alternative would be to run all PCP services in the same container (pmcd,
pmlogger, pmie, etc, started via an uber rc script that launches all desired
PCP rc scripts and then sits there in pmpause until killed).
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. THat's much the same as the PCP client/server design where
we clearly separate collection from monitoring, whether it's local, remote,
live or archive replay.
sorry for waffling on so much, but we need to get this nailed down asap.
Cheers
-- Mark
|