11–20 of 36 posts
Earlier quoted context omitted.
By shipping only in a Docker container you will limit the audience for your app. That is the reason we ship GitLab as Omnibus packages (deb/rpm).
While deb/rpm packages are better than a monolithic container, having used one of your rpms, I'd say they're only just barely better.
So I want to plug a project I've been contributing to: https://github.com/CiscoCloud/microservices-infrastructure
We're trying to make it super easy to deploy these tools. For example every time you launch a docker container, it will register with consul and be added to haproxy. The nice thing about using Mesos is we can support data like workloads Cassandra, HDFS, and Kafka on the same cluster your run Docker images on.
We use terraform to deploy to multiple clouds so you don't get locked in to something like cloudformation.
Obviously that doesn't work for Windows systems.
I think the main problem with all of these systems is that are just so damn complex. Docker, its great if you have no state. But then if you have no state shit is easy. Mapping images to highspeed storage securely and reliably is genuinely hard. (unless you use NFSv4 and kerberos) Mesos is just over kill for everything. How many people actually need shared image programs bigger than a 64 core machine with 512gigs of…
You might like Lattice[0], which is extracted from Cloud Foundry. Basically, everyone is racing back to PaaSes. Heroku pioneered it and are still out there. Red Hat have OpenShift and are making noises about turning it into a Docker+Kubernetes thing in version 3. Cloud Foundry has been around for a few years now. There are other also-rans. The thing is that apart from Heroku, you've not heard of installable PaaSes be…
They've already decided that, and have even reached code-freeze. Their conference is later this month, so that's when it's going to all be announced and rollout plans detailed.
Is anyone running Marathon in production? Real production. The kind where any downtime means lost money. I see a lot of intro-level tutorials, but almost nothing on the more advanced side. My (completely casual) experience with Marathon is pretty bad, with the main process crashing quite regularly even under no load, so I'm wondering if people who write about these systems have actually used them for non-trivial task…
There were indeed issues with the 0.7.x series of Marathon, but we've made a big effort to focus on stability and performance in 0.8.x, and onward. As with any new software project, there tend to be issues in early releases.
The Circle CI post http://blog.circleci.com/its-the-future/ reads as a parody on this one.
I think the main problem with all of these systems is that are just so damn complex. Docker, its great if you have no state. But then if you have no state shit is easy. Mapping images to highspeed storage securely and reliably is genuinely hard. (unless you use NFSv4 and kerberos) Mesos is just over kill for everything. How many people actually need shared image programs bigger than a 64 core machine with 512gigs of…
Docker is great also to hide complexity during implementation. Discourse.org is doing a great work "enveloping" their complex rails app in containers to easy the install process. And is not stateless.
The result is that their forum software requires another operating system to run. Had they been more disciplined in their development approach, Docker would have been merely a convenient way to test Discourse, and not the only supported option.
Is anyone running Marathon in production? Real production. The kind where any downtime means lost money. I see a lot of intro-level tutorials, but almost nothing on the more advanced side. My (completely casual) experience with Marathon is pretty bad, with the main process crashing quite regularly even under no load, so I'm wondering if people who write about these systems have actually used them for non-trivial task…
Marathon does not make using Docker or building microservices simple. There are many important pieces that Marathon does not provide. Sure your operations team can tie in Mesos-DNS / Bamboo / Consul / whatever else, but it's going to take time, requires a specialized team, and leaves you feeling nervous about what happens if everything crashes in the middle of the night. Even when tying in these third party tools, it is likely you will have to make significant code updates to utilize features such as service-discovery / SRV records. You will inevitably end up with a hobbled-together system that needs serious support from your operations team.
I am fairly frustrated as a whole with Mesosphere, and expected more from a company who raised so much capital.
Is anyone running Marathon in production? Real production. The kind where any downtime means lost money. I see a lot of intro-level tutorials, but almost nothing on the more advanced side. My (completely casual) experience with Marathon is pretty bad, with the main process crashing quite regularly even under no load, so I'm wondering if people who write about these systems have actually used them for non-trivial task…
It has worked remarkably well and allowed us to scale up/down during peak hours or unexpected high traffic peaks.
I think the main problem with all of these systems is that are just so damn complex. Docker, its great if you have no state. But then if you have no state shit is easy. Mapping images to highspeed storage securely and reliably is genuinely hard. (unless you use NFSv4 and kerberos) Mesos is just over kill for everything. How many people actually need shared image programs bigger than a 64 core machine with 512gigs of…
Docker is great also to hide complexity during implementation. Discourse.org is doing a great work "enveloping" their complex rails app in containers to easy the install process. And is not stateless.
You mean hide ugly sprawling uninstallable messes of rube goldberg code? :)
I'm referring to things that require PHP+MySQL, Node, Redis, and an old JVM process running Struts/Spring all managed by nginx except for that one situation where Apache2 .htaccess semantics are required for rewrite rules in which case it runs Apache proxied by nginx.