Hi,
On 12.10.19 19:00, Tomas Pospisek wrote:
> However running a service ("a single application") often implies
> surrounding services. F.ex. you want logs to be saved? Maybe you need to
> run cron or at? Maybe you want to get notified about problems, stats,
> whatever via email?
That's the point of containerization though: a site-wide service
orchestrator keeps track of services and their dependencies. You likely
only need a single mailer instance for however many of your application
containers you run, and your application should only talk to some
abstract service provider through a well-defined interface, so the
actual implementation behind it can be scaled and updated independently.
Containers and systemd solve the same problem at different scales
(site-wide vs per-host).
Stacking two systems that implement the same feature on top of each
other usually gives you bad side effects. Linux knows that virtio disks
should have an arbitrarily long command queue and no scheduler, because
I/O schedulers do not stack. RAID controllers rely on harddisks to
report read errors immediately instead of retrying. TCP-over-TCP behaves
erratically.
The only place where I could see a potential use would be exporting dbus
services between containers, similar to DCOM in Windows, but everyone
seems to be happy with socket connections and per-application protocol
definitions.
Simon
Attachment:
signature.asc
Description: OpenPGP digital signature