SCIENTIFIC-LINUX-USERS Archives

November 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Sun, 9 Nov 2014 13:47:02 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (48 lines)
On Sun, Nov 9, 2014 at 1:20 PM, Vladimir Mosgalin
<[log in to unmask]> wrote:
> Hi Nico Kadel-Garcia!
>
>  On 2014.11.09 at 12:55:08 -0500, Nico Kadel-Garcia wrote next:
>
>> > E.g. we had a goal "use SL7 on database host, but run PostgreSQL with
>> > some related services inside SL6 container, until we get enough time to
>> > make it work on SL7 natively (after which we'll move it from container
>> > to base system)".
>> > Having nearly complete virtual host with sshd, postgresql server and
>> > related tools would be cumbersome in docker. This task can be solved
>> > with LXC, however.
>>
>> Out of curiosity: what was the problem? I'd assume that SSH, for
>> remote configuration management inside the container, and the actual
>> running service itself inside the container, would be common
>> configurations.
>
> First of all, it's not considered to be best practice to run sshd:
> http://jpetazzo.github.io/2014/06/23/docker-ssh-considered-evil/

I just read it. I'm afraid he's handwaving a lot. There is a *lot* of
infrastructure built around SSH access to particular servers, whether
they exist as hardware, VM's, or potentially as docker containers. The
same is true for many web based management tools of particular
services. Re-architecting that is.... expensive, and potentially quite
fragile.

> The problem is with design, with docker you use external configuration
> and everything is controlled by it. You use small separate containers
> for each kind of service.
>
> Our usage scenario relies on multiple virtual servers, each running
> lots of various services, with exact configuration (network, which
> services to run and so on; often there is a need to stop bunch of services
> on one container and run then on another) controlled by chef. It works
> fine with KVM hosts, OpenVZ or LXC containers, but kind of conflicts
> with how you're supposed to use docker.

Got it.

> Using chef client "from inside" container to change system configuration
> or even its purpose is very different from docker "create container for
> this or that service" usage pattern.

Got it. Thanks for the heads up!

ATOM RSS1 RSS2