Just started learning salt stack for infrastructure provisioning. But it makes so much sense just to build all requirements in the container itself. Did anybody already moved from tools like salt/puppet to container only approach?
Running containers without Docker
101–110 of 140 posts
Re: Running containers without Docker
#102I 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…
> but they don't want to use Docker, at least not immediately, because it requires to learn a few Docker commands
That's not what the blog post says. They don't want to use docker because it does a lot of things. They use rkt because it does fewer things. It's not about learning commands, it's about complexity of software. They selected rkt because it does less stuff, not because it's easier to learn.
Re: Running containers without Docker
#103What is the motivation and benefit for running containers without docker? Docker is by far the more mature and adopted development tool. It also runs great on windows, macos and linux. While k8s can run containers via the rkt runtime, it's still pretty new and will probably introduce unnecessary headache and edge cases. Docker also has a head start on a vibrant ecosystem for base images. In my opinion it would be bet…
> What is the motivation and benefit for running containers without docker? I believe that Docker bet the company on the wrong business model. Therefore knowing that you can run containers without Docker can be desirable, as it gives you options in case Docker turns out to be not viable. Docker made it easy to build and run containers from the command line. This technology was released at the right time and in the ri…
> In my view it is unlikely to work for Docker.
Docker has realised the money is in the platform. So they're competing against Red Hat, who have OpenShift.
They're also my employers, Pivotal, and IBM, and HP, and SAP and every other company with a Cloud Foundry distribution.
The problem for Docker is that Red Hat, Pivotal et al started with selling an entire platform to F1000s. Docker and Kubernetes have great groundswell in the community, but the difference is that Docker need to make money from a sold platform and Google don't -- their play is GCP.
> For orchestration solution they are engineering against Google's Kubernetes.
Let's not forget Mesos, Nomad, Diego (the Cloud Foundry bits) and so on. And yes, it turns out this problem is actually very hard. Much harder than it looks.
> Due to Docker's need to protect their business model, there is no true community in the sense that there is an open exchange of ideas.
This is one of the reasons Pivotal donated Cloud Foundry IP to the Cloud Foundry Foundation, and it's why the Foundation rules are written to grant voting rights to members which contribute engineering effort. Red Hat are relevant as a large and critical part of an ecosystem. So it is for other successful OSS companies. But being the "owner" tends not to go as well. People who buy from us want to know that they can switch to IBM without much disruption and vice versa.
> This situation would make it hard for Docker to justify their valuation.
I can't blame them for trying. And I suppose they didn't see Kubernetes coming to suck the oxygen out of a big part of their platform.
The weird story of Docker will be of a company that created a PaaS, abandoned it for a component, then tried to build a PaaS.
Disclosure: as I noted above, I work for Pivotal. As Docker moves into platforms, we are competitors. Though we cooperate on runC.
Re: Running containers without Docker
#104Earlier quoted context omitted.
Docker founder here. > What is the motivation and benefit for running containers without docker? I regularly hear from people who want to run containers without Docker. There are several motivations, all of which are perfectly valid: 1. Learning . It's fun to build things from scratch to understand how they work under the hood. 2. Bad experience . Early versions of Docker were quite buggy, and we initially struggled…
You missed another, big reason: "Fewer, simpler moving parts" is the main reason I would prefer if Kubernetes could run without Docker as a container runtime. At the moment, Kubelet needs to control the Docker daemon (a somewhat brittle relationship), and a bunch of concepts — from networking to volume management — could be simplified by making the container runtime more K8s-specific and less general-purpose. A tight…
Docker have broken out some Docker logic into libraries, which is why the Garden team swapped out their driver to use runC. Kubernetes could presumably follow suit and target the libraries instead of the Docker daemon.
The experience of the Garden API (a containerising system that ultimately predates Docker) is that tighter coupling is actually a mistake.
If Garden had been tightly bound to its implementation or orchestrator, it'd still be using raw Linux system calls and running under a 2nd-generation orchestrator.
Instead it's now using runC, OS X or Windows APIs to create containers and runs under multiple consumers -- most heavily under Diego, a 3rd-generation orchestrator and Concourse, a project automation tool.
Disclosure: I work for Pivotal. Many, but not all, of the engineers who've worked on Garden work for Pivotal also.
Re: Running containers without Docker
#105Earlier 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…
> We vendors are everywhere, and we are biased as hell.
As a Pivot, I can confirm: I am biased as hell.
Re: Running containers without Docker
#106Earlier quoted context omitted.
Docker founder here. Great! There is one question I would like to have answered, by you and you alone: if I'm using SmartOS, and therefore zones, and all my applications and configurations are packaged into OS packages, and I use imgadm(1M), vmadm(1M), and Smart DataCenter (SDC), what do I need Docker for?
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 response back. I enjoy it even more when I am able to perform mass in-place upgrades of configuration, on tens of thousands of systems, in parallel, because I'm performing configuration management using operating system packages, or simply destroy the system's boot block, reboot it, and have the network instantiate it, from bare metal to fully configured virtual servers ready to serve data, 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. No extra software or daemons required or needed, other than what ships with the OS.
Fully isolated, virtualized UNIX servers. Servers are cattle, not pets. Deployments in up to 25 seconds.
That was the challenge. And it was fun to solve.
Have fun maintaining OS packages.
Oh I am! It's incredibly satisfying to be able to run systems where no human has ever logged into, and no file has ever been manually modified, and all the files and all the changes are accounted for by the operating system.
See also, not quite the same, but very much related and relevant to your comment:
http://www.perkin.org.uk/posts/building-packages-at-scale.ht...
https://blog.nimbleci.com/2016/10/11/how-to-deploy-jenkins-c...
https://news.ycombinator.com/item?id=12750685
Configuration management at scale, using an operating system's software management subsystem is the old, new-new thing. It is the foundation and the future of even more massive cloud computing. Now you'll be able to say someday in the future: "ha! I read that on Hacker News years ago!", and point to this post.
Re: Running containers without Docker
#107Earlier quoted context omitted.
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.
Send the AWS alarms to opsgenie or pager duty and they will nag you based on a single event, including escalations.
Nagios or a SaaS, we're still back to something else other than containers to manage the alerts, though.
Re: Running containers without Docker
#108I think when it comes to containers HN has been guilty of a shocking lack of scrutiny and unilaterally hyping Docker. For example Docker was based on LXC till 0.9 but was so successful in hype and misdirection of the project it's based on that till today most commentators here do not seem to have a proper idea of the LXC project and whatever ideas they have are negative. How did this come to be? I don't know how heal…
Docker is a case where "the whole is greater than the sum of its parts". Yes, LXC and cgroups and aufs and overlayfs and whatever else do a lot of the heavy lifting, but Docker glued it all together in a way that was approachable by any developer, not just Linux geeks. I remember briefly looking into LXC ~6 years ago and being totally lost. Then Docker came along with a simple command line interface and growing repos…
> LXC and cgroups and aufs and overlayfs and whatever else do a lot of the heavy lifting, but Docker glued it all together
For being just glue, Docker has an unjustifiably large code base, it's quite opaque and a lot of stuff to learn if you want to go beyond "hello world"
If a bash script can do the same (admittedly, using btrfs) using 100 lines of code something is wrong^W hyped up.
Re: Running containers without Docker
#109Earlier quoted context omitted.
My main concern is coming across a an issue only to research it and find a "won't fix"[closed] and 100 +1s asking for it. When I have something super important in actual production this scares me way too much to trust.
Just curious: Which issue(s) are you talking about?
One that comes to mind is folks asking for relative path support in Dockerfiles (though I understand why the Docker folks don't want to do that).
Re: Running containers without Docker
#110I think when it comes to containers HN has been guilty of a shocking lack of scrutiny and unilaterally hyping Docker. For example Docker was based on LXC till 0.9 but was so successful in hype and misdirection of the project it's based on that till today most commentators here do not seem to have a proper idea of the LXC project and whatever ideas they have are negative. How did this come to be? I don't know how heal…
> HN has been guilty of shocking lack of scrutiny and unilaterally hyping Docker
Spot on. It's sad how often people behind code that does the real work (LXC, Overlayfs and many more) get overlooked, while marketing-fueled operations get all the glory.
It's also worrying to see that people driving technical decisions are so easily swayed by hype and fail to investigate what's under the hood.