Live data from Hacker News

Running containers without Docker

jvns.ca

111–120 of 140 posts

Re: Running containers without Docker

#111

I don't get the author. So to sum it up, they like what Docker did with containers, but they don't want to use Docker, at least not immediately, because it requires to learn a few Docker commands and a bit other stuff and therefore they decided to build their own hybrid shit, which will take them probably more time to build than to learn Docker and then on top of that still need to train their employees on that as we…

article is really low on details. they use naked lxc? what does it mean just launch containers in docker and rkt? wishy washy it sounds to me. I want details.

Re: Running containers without Docker

#112
post #87

Earlier quoted context omitted.

Nothing. You've already spent all the time and effort that Docker would save you. Have fun maintaining OS packages.

As I wrote previously, the question is for the founder of Docker and him alone, but since you volunteered your opinion, I am extremely pleased to inform you that I love making OS packages and performing configuration management at scale that way. I especially enjoy being able to ask the operating system's software management subsystem exactly which configuration changes have been done to it, and get a precise respons…

So what are you bugging shykes for? You have achieved everything Docker offers, and you had fun in the process. Seems like you're smart enough to realize that.

Anyway, someday in the future I might look back on this and think "ha! someone put all that effort in even though NixOS already existed".

Re: Running containers without Docker

#113
post #87

Earlier quoted context omitted.

Nothing. You've already spent all the time and effort that Docker would save you. Have fun maintaining OS packages.

As I wrote previously, the question is for the founder of Docker and him alone, but since you volunteered your opinion, I am extremely pleased to inform you that I love making OS packages and performing configuration management at scale that way. I especially enjoy being able to ask the operating system's software management subsystem exactly which configuration changes have been done to it, and get a precise respons…

> by just using Kickstart, JumpStart(TM), or SDC, without any additional code. No Chef. No Puppet. No cfxengine. No Salt. No Ansible. No Docker. No KVM. No XEN. No Kubernetes. No Mesos.

Thank you for saying this! Building OS packages and OS images and provisioning servers was done automatically 10 to 12 years ago with much less work.

It's still the preferred choice for many large tech companies and nobody talks about it because it just works and it's nothing new. Fast deployments, immutable infrastructure, modularity.

Re: Running containers without Docker

#114
post #8

Earlier quoted context omitted.

Containers existed before Docker and will exist after Docker, and articles like these are desperate attempts to remind everyone of that in the face of Docker's unilateral destruction of the concept. I know I'm right because of comments like these that presuppose "well, if you're doing containers, use Docker, the alternatives just aren't there." Except they were, before Docker, and after Docker. Docker is a developer…

So what is your alternative? Run containers your own unique way and roll your own distribution mechanism and networking to fragment yourself from the tools in the "container" space?

When "your own unique way" requires less development time and efforts and it's easier to learn for new hires, yes. That's why you hire system engineers - to write good automation.

Re: Running containers without Docker

#115
post #112

Earlier quoted context omitted.

As I wrote previously, the question is for the founder of Docker and him alone, but since you volunteered your opinion, I am extremely pleased to inform you that I love making OS packages and performing configuration management at scale that way. I especially enjoy being able to ask the operating system's software management subsystem exactly which configuration changes have been done to it, and get a precise respons…

So what are you bugging shykes for? You have achieved everything Docker offers, and you had fun in the process. Seems like you're smart enough to realize that. Anyway, someday in the future I might look back on this and think "ha! someone put all that effort in even though NixOS already existed".

So what are you bugging shykes for?

All I did was ask a question.

Is critical thinking, even just asking questions, undesirable now, unless someone is being praised to high heavens? Is that what we're down to now?

"ha! someone put all that effort in even though NixOS already existed"

SmartOS virtualization is based on Solaris zones, which existed long before people on GNU/Linux even realized that containers were the way to go. The groundwork, and my own work was laid down long before any of this became hype. Project Kevlar, nee zones was started around the same time as NixOS, and another participant already mentioned that large companies did large scale deployments and configuration management via OS packages, which is both true and correct.

Re: Running containers without Docker

#116
post #78
post #66

Earlier quoted context omitted.

All of the early Kubernetes resources I can find describe it as involving Docker. Was running it without Docker really a thing early on?

No. Kubernetes was launched at the first Dockercon, with a very specific focus of "we want to help expand what can be done with Docker by leveraging the significant operational experience we accumulated at Google". They delivered very successfully on that promise. The focus on diversifying away from Docker is very recent, and is the direct result of the competitive tension I talk about earlier in the thread. It's com…

My day job is not related to containers, but yes, working in the industry has of course biased me (but my opinions are still my own).

Re: Running containers without Docker

#117

Try systemd containers (e.g, systemd-nspawn) if you're on a systemd distro like Ubuntu 16.04.

rkt actually uses systemd-nspawn to run and namespace the container. What rkt "adds" before that is downloading, verifying managing the container image and setting up the cgroup for resource limitation. https://github.com/coreos/rkt/blob/master/Documentation/deve...

Doesn't systemd do that already (via machinectl, e.g.)?

Re: Running containers without Docker

#118
post #68

Earlier quoted context omitted.

Convox founder here. Thanks for the shout out! We are indeed building a private Heroku like platform so you don't have to. It's a simple of layer around AWS so it doesn't add extra craziness some other approaches do. As for the OP, her approach is spot on! Containerizing your app is the first step in future proofing it. Doing so correctly will remove layers and therefore simplify things. You now are looking at a pack…

I hate nagios as much as the next op, but what is so magical about containers that your services will no longer require an outage alerting mechanism?

It's not containers, it's AWS. You get CloudWatch events that can turn into alerts for many parts of the platform. With the ECS and ELB/ALB integration, we get paged about downtime and 500s without Nagios.

Re: Running containers without Docker

#119
post #74

Earlier quoted context omitted.

> run containers on ECS Presumably ECS has its own alerting mechanisms similar to CloudFormation and ElasticBeanstalk (I've only used the latter two, not the former).

In my experience, AWS alerting only sends one alert once per issue. If you're asleep when the single SMS comes through, tough. Nagios will nag you until you do something about it... Maybe ECS is different. I haven't played with it, but I imagine it's "make an SNS topic" like everything else.

You can integrate CloudWatch Alarms to PagerDuty with an SNS webhook. PagerDuty keeps nagging until the CloudWatch Alarm auto-resolves.

Re: Running containers without Docker

#120
post #76

Try systemd containers (e.g, systemd-nspawn) if you're on a systemd distro like Ubuntu 16.04.

systemd-nspawn is great! The workflow feels much more native than Docker on GNU/Linux host. The easy integration with networking, BTRFS snapshots, etc is very powerful.

When I "discovered" systemd-nspawn, I kept thinking "why aren't people using this? This is easier to understand in every way."
Post reply on HN