41–50 of 55 posts
While we're on the topic can anyone recommend a system for rolling out (Java) applications across server farms that doesn't use containers? We have a bunch of shell scripts that are pretty horrible. We could containerize, but we dont need that right now.
Using a container orchestrator for deployment is pretty much better than using a CM tool in every way... and it's certainly better than trying to half-ass one with bash scripts.
Earlier quoted context omitted.
The one feature that to me seems to be essential but appears to be missing from all these container orchestrators is the ability to tie a remote volume (Ceph/Gluster/Lustre/etc) to a container so that if a container is scheduled to run on a certain node, the volume will automatically be mounted on the same node. It seems from the mailing list that at least Nomad will have that at some point, but I have not seen much…
we tried using EFS for shared storage but quickly depleted our I/O bursting credits and our throughput dropped to a grinding halt, because our app's worklaod is both disk write and read intensive. No solutions yet
I am kind of surprised with negativity about Docker and Swarm. Both of them but UX first and technology second. This is the correct approach to get adoption (and also the reason why they are popular). Getting started with Docker and Swarm is really really simple and it's very hard to dislike simple things. Compared to that mesos and openstack and other tech stacks like that are garaguntan and imo have very bad UX.
Docker itself is mostly targeted as a tool for developers: you, the developer, dockerize your application, resulting in a container-image. Sure, that container-image then has to get deployed by someone (who isn't necessarily you), but the reason it's getting deployed at all is that a developer, at some point, made a decision to use Docker as part of the development process. Everyone else has to just deal with that.
Docker Swarm, meanwhile, is infrastructure, pure and simple. Developers don't touch it; ops people do. And ops people have very different opinions on what makes for a good piece of software than developers do. "Good UX" comes second to things like "stable" and "low overhead" and "predictable failure modes" and "configurable from a central source of truth."
I am kind of surprised with negativity about Docker and Swarm. Both of them but UX first and technology second. This is the correct approach to get adoption (and also the reason why they are popular). Getting started with Docker and Swarm is really really simple and it's very hard to dislike simple things. Compared to that mesos and openstack and other tech stacks like that are garaguntan and imo have very bad UX.
Consider that they have different target audiences. Docker itself is mostly targeted as a tool for developers : you, the developer, dockerize your application, resulting in a container-image. Sure, that container-image then has to get deployed by someone (who isn't necessarily you), but the reason it's getting deployed at all is that a developer, at some point, made a decision to use Docker as part of the development…
I am kind of surprised with negativity about Docker and Swarm. Both of them but UX first and technology second. This is the correct approach to get adoption (and also the reason why they are popular). Getting started with Docker and Swarm is really really simple and it's very hard to dislike simple things. Compared to that mesos and openstack and other tech stacks like that are garaguntan and imo have very bad UX.
Consider that they have different target audiences. Docker itself is mostly targeted as a tool for developers : you, the developer, dockerize your application, resulting in a container-image. Sure, that container-image then has to get deployed by someone (who isn't necessarily you), but the reason it's getting deployed at all is that a developer, at some point, made a decision to use Docker as part of the development…
Startups begin as small companies and small companies have a single team that decide how to develop and deploy. Usually developers deploy and take care of production too. What's convenient for development often trumps what's convenient for production, at least for the first months or years.
Earlier quoted context omitted.
Consider that they have different target audiences. Docker itself is mostly targeted as a tool for developers : you, the developer, dockerize your application, resulting in a container-image. Sure, that container-image then has to get deployed by someone (who isn't necessarily you), but the reason it's getting deployed at all is that a developer, at some point, made a decision to use Docker as part of the development…
In big companies ops trumps devs, and it's correct because they develop for 6-12 months and then operate that sw for 6 or 12 years. Been there, saw that (a mobile phone operator). So if ops says that docker is no-no for deployment, the dev has to work with another technology or convince them that everybody is going to benefit from it. Startups begin as small companies and small companies have a single team that decid…
Earlier quoted context omitted.
In big companies ops trumps devs, and it's correct because they develop for 6-12 months and then operate that sw for 6 or 12 years. Been there, saw that (a mobile phone operator). So if ops says that docker is no-no for deployment, the dev has to work with another technology or convince them that everybody is going to benefit from it. Startups begin as small companies and small companies have a single team that decid…
You're presuming that the same company develops and deploys the software. My company runs many third-party Docker container-images in production—precisely because a Docker container-image is the only format that software comes in.
I am kind of surprised with negativity about Docker and Swarm. Both of them but UX first and technology second. This is the correct approach to get adoption (and also the reason why they are popular). Getting started with Docker and Swarm is really really simple and it's very hard to dislike simple things. Compared to that mesos and openstack and other tech stacks like that are garaguntan and imo have very bad UX.
Consider that they have different target audiences. Docker itself is mostly targeted as a tool for developers : you, the developer, dockerize your application, resulting in a container-image. Sure, that container-image then has to get deployed by someone (who isn't necessarily you), but the reason it's getting deployed at all is that a developer, at some point, made a decision to use Docker as part of the development…
Earlier quoted context omitted.
Consider that they have different target audiences. Docker itself is mostly targeted as a tool for developers : you, the developer, dockerize your application, resulting in a container-image. Sure, that container-image then has to get deployed by someone (who isn't necessarily you), but the reason it's getting deployed at all is that a developer, at some point, made a decision to use Docker as part of the development…
In big companies ops trumps devs, and it's correct because they develop for 6-12 months and then operate that sw for 6 or 12 years. Been there, saw that (a mobile phone operator). So if ops says that docker is no-no for deployment, the dev has to work with another technology or convince them that everybody is going to benefit from it. Startups begin as small companies and small companies have a single team that decid…
I (single dev at my startup at that time) adopted Docker 0.4 alpha and i have grown with the docker ecosystem. Today we pay for codeship,etc.
there is zero chance i would have a Docker buy-in if I could not get started then. This is the case with Docker Swarm and k8s today.
I'm struggling with k8s... while the evolution of Docker -> Docker Compose -> Docker Swarm is fairly easy and incremental.
In 2 years time when I have a large devops team... i will spend money on Swarm. Docker Swarm is conquering from the bottom. K8s still has a chance... but it is choosing to compete with OpenStack rather than Docker Compose, which is a big mistake IMHO.