[ale] Containers... use?

Jerald Sheets questy at gmail.com
Mon Sep 18 10:24:53 EDT 2017


> On Sep 18, 2017, at 9:39 AM, DJ-Pfulio <DJPfulio at jdpfu.com> wrote:
> 
> Jerald, I bet a presentation on your docker deployment techniques would
> have a full house of interested ALEer.
>   Oct or Nov meetings need a topic. ;)
> 

Unfortunately, I can share with you guys in a semi-private forum.  I cannot share publicly nor can I speak publicly.

I’ve got the lawyers working on my approval just to present on Puppet at a local users group without my employer’s name attached.  It’s a nightmare.


> 
> On 09/18/2017 09:18 AM, Jerald Sheets wrote:
>> 
>> FUD doesn’t play well here, and this smacks of FUD to me.
> 
> Some things require time to be proven.  Old guys have learned that hype
> is seldom true.  We've been burned before.  Things need time to mature
> if you don't want to be bleeding edge, spinning with constant updates.
> 
> When I was 25, bleeding edge seemed like the best place.  Around 45 ...
> not so much.  We had systems that worked, where predictable, and met the
> requirements better than previously deployed stuff.
> 

I’m 50.  I’ve been doing this since CP/M was my primary desktop and Vax/VMS was my playground.  I’m not new to this.


> From the outside, there are some technologies that have great hype and
> may prove to be great - someday - after they mature a little.
> 
> Remember when openstack was all the rage?  How many years did it take to
> NOT need a fork-lift upgrade between versions?

I implemented that for AMEX.  They did upgrades atomically over time.  Not an issue.  The problem was that no one at OpenStack (whoever the heck’s implementation you chose) could tell you the proper foundation for a smooth architecture.  If you happened to stumble over it, good on you.  We didn’t until we had someone who had show us what to do.  Everything there forward was cake.

> 
> Docker/Containers seem very useful, but it wasn't that long ago that
> root escalation break-outs were being found every few months, regardless
> of the claims from the container people.  I think the docker container
> format has "won the war", but the requirement for docker to run as root
> on the docker-host is still troubling.  Just a little more maturity is
> needed.
> 


Eh?

containerd definitely runs as root (like Apache, NginX, et al.) because daemon.  However, root is not needed to work with the container.  I just had this grippiest with a guy internally here.  Everything was done post-install by just adding individual users to the docker group.  No sudo necessary, and no root access required.  After all, if daemon control is the only thing requiring root interaction (by the sysadmin), I don’t see a problem there.

Second, the people who were ding root escalations had intimate knowledge of cgroups.  Once the vendors realized they couldn’t get away with “we’ll just leave that for now to make a ship date” any more, things started to clean up nicely.

There are also several security methodologies out there…  we’ve built our own proprietary ones involving chrooting, zoned access, ingress/egress rules, and quite a bit of tomfoolery, honestly, but the product is mostly secure OOTB and is securable with an easily automatable process.  Time to secure?  About one Puppet run.


> Is that FUD?
> 
> And for about 6 videos from Redhat reps for container best practices,
> look on youtube for the SELF 2016 conference. Some more details provided
> beyond what Jerald is saying here with a little more depth in those.


That’s good fodder there, but always remember that those guys are extremely myopic in their views, statements, and architectures.  YMMV when trying to apply the principles to a self-rolled environment.


—jms



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20170918/f38fa8f9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.ale.org/pipermail/ale/attachments/20170918/f38fa8f9/attachment.sig>


More information about the Ale mailing list