Re: [dev] containers opinion

[Anselm R Garbe]

On 23 September 2016 at 19:19, stephen Turner
 wrote:
> whats the suckless view of containers and why? what about a

Containers are an indicator of conceptual decay. Application developer
code has now become infrastructure and is due to the juniority far
away from any half-standardized protocols. In times with agile
software development, architects lost track of the _overall_ system
architecture. System daemons seem not to be enough anymore or too hard
for junior application developer people to base some services on. Also
it is hard to write a daemon in J2EE Java or nodejs...

Since application programmers started developing (system)
infrastructure you now need to put their dependency hell into some
manageable "containers" to keep your base server infrastructure
somehow manageable.

But the introduction of containers will not lead to a better
architecture, it is just the opener for uncaring developers to do
system programming in nodejs etc.

Remember what the introduction of all programming paradigms into C++ led to.

-Anselm

Re: [dev] containers opinion

[hiro]

> Docker daemon is a single, statically
> linked binary.

that's irrelevant. you still need the right version of loonix with
namespaces support, etc.
containers are not independent of the operating system.

Re: [dev] containers opinion

[Kamil Cholewiński]

On Fri, 23 Sep 2016, stephen Turner  wrote:
> whats the suckless view of containers and why? what about a
> containerized init helper where sinit calls the container program and
> then runs daemons and the rest of the system from containers? Do you
> feel containers offer additional security/stability?

Containers DO NOT add any security. Unsharing resources does. If you are
serious about security, proper privilege separation is the way to go.
But it requires thought and careful design, something chronically
missing in that whole the "move fast, break things" crowd.

Stability - no. Unstable and shitty code is going to stay unstable and
shitty, no matter how many layers you wrap it in. A Good operating
system will shield one application from misbehaviors of another,
**by default**.

> Just thinking about "cloud" stuff again and daydreaming about servers.

Yes, this is where containers shine. The developer writes a Dockerfile,
builds and tests the image on his laptop, does it work? :shipit:

Then the sysop guy just clicks around on the GCP admin panel to spin up
a Kubernetes cluster, points it at the image, and viola, fuken deployed.

For me, as a sysop, the image/container workflow finally makes the pain
of deploying the unstable and shitty code to production bearable,
because it confines the unimaginably imaginative developers' inventions
into a conceptually simple and uniform package. Finally I only have to
deal with one kind of crap, as opposed to 20 different kinds of crap.

I welcome containers with ovations and fanfares.

> I suppose with a system as small as suckless offers it might be a moot
> point by the time you fire up several VM instances. VM's would add a
> semi redundancy in the event of a single failure in that it wouldn't
> take down the other services but then you have other issues if the
> system fails anyways right?!

Last time I checked, sta.li was shifting focus to the embedded space.
Maybe I'm too old for this job, but I just... don't run my production
workloads on a bag of potatoes.

Also... Face it. The reason why we have containers, is because most
applications are a stinking pile of crap, and we needed a way to confine
them into something manageable. If the people that wrote all of that
shitty code cared about being suckless, they'd have to harakiri.

Now once you have a container, it doesn't matter at all, which host OS
is it running under. On AWS, your cluster runs Amazon Linux, some sort
of bastardised CentOS knockoff. On GCP, your clusters run on Debian
Wheezy. (Yes, I WTF'd and LOL'd, but hey, if it works, it ain't broke.)
Is there any difference? No, the Docker daemon is a single, statically
linked binary.

<3,K.

Re: [dev] containers opinion

[Ben Woolley]

> On Sep 23, 2016, at 12:18 PM, hiro <23h...@gmail.com> wrote:
> 
> containers are there to emulate static linking or the common portable
> windows programs in the form of a single .exe
> 
> there is no security benefit of running more people's software on your 
> computer.
> 

I am reminded of the fact that the main proponent of categorical imperatives 
never ventured far from his home. 

Re: [dev] containers opinion

[Daniel Abrecht]

I am new here. I am using devuan + libvirt + lxc containers. I think in
terms of security, it's less secure than a VM, since it shares the
kernel & resources with the host system. But I think it's easier to
backup & update containers. I like that I can just copy a container to
another computer, and only need to set it up once. Also, if I update one
container, it can't break the other containers. Also, each of my
Container contains devuan and has its own network interfaces, it's like
having many different and complete servers with own IPs, hostnames,
etc., but without many expensive computers or crazy amounts of ram for
VMs. However, I always have a physical second fallback & backup systems
if the first one fails, because a single computer is still a single
point of failure.

Since I use containers as if they where normal computers, I don't see
why I need to be able to control the services from the host system, I
just ssh to the container if I need to restart a service. I think if I
just want to isolate a single service, I would just use a simple chroot.
I don't think an container is much more secure than a chroot.

Am 23.09.2016 um 17:19 schrieb stephen Turner:
> whats the suckless view of containers and why? what about a
> containerized init helper where sinit calls the container program and
> then runs daemons and the rest of the system from containers? Do you
> feel containers offer additional security/stability?
>
> Just thinking about "cloud" stuff again and daydreaming about servers.
>
> I suppose with a system as small as suckless offers it might be a moot
> point by the time you fire up several VM instances. VM's would add a
> semi redundancy in the event of a single failure in that it wouldn't
> take down the other services but then you have other issues if the
> system fails anyways right?!
>
> just random thoughts.
>
> thanks,
> stephen
>

Re: [dev] containers opinion

[hiro]

containers are there to emulate static linking or the common portable
windows programs in the form of a single .exe

there is no security benefit of running more people's software on your computer.

Re: [dev] containers opinion

[Thomas Levine]

My personal view is that separate users are enough software separation
for everything that I have ever wanted to do. Dunno about the party line
though.

On Fri, Sep 23, 2016, at 05:19 PM, stephen Turner wrote:
> whats the suckless view of containers and why? what about a
> containerized init helper where sinit calls the container program and
> then runs daemons and the rest of the system from containers? Do you
> feel containers offer additional security/stability?
> 
> Just thinking about "cloud" stuff again and daydreaming about servers.
> 
> I suppose with a system as small as suckless offers it might be a moot
> point by the time you fire up several VM instances. VM's would add a
> semi redundancy in the event of a single failure in that it wouldn't
> take down the other services but then you have other issues if the
> system fails anyways right?!
> 
> just random thoughts.
> 
> thanks,
> stephen
> 

[dev] containers opinion

[stephen Turner]

whats the suckless view of containers and why? what about a
containerized init helper where sinit calls the container program and
then runs daemons and the rest of the system from containers? Do you
feel containers offer additional security/stability?

Just thinking about "cloud" stuff again and daydreaming about servers.

I suppose with a system as small as suckless offers it might be a moot
point by the time you fire up several VM instances. VM's would add a
semi redundancy in the event of a single failure in that it wouldn't
take down the other services but then you have other issues if the
system fails anyways right?!

just random thoughts.

thanks,
stephen