Okay, it transpires some of my Java guys also know C.... who knew. Anyway, they have been tasked with adding LXC/LXD support to Apache Mesos which we'll push upstream assuming they want it. My plan is to then extend Marathon to support LXD deployments and from that we'll then build a Juju provider for Juju 2 to do juju deploy to Mesos..... who knows what pitfalls lie ahead but work has begun!.
Tom On Fri, Nov 18, 2016 at 3:31 PM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > 2016-11-18 15:43 GMT+01:00 Tom Barber <t...@spicule.co.uk>: > >> You mention stateless, thats fine, but for example, if you have sessions >> in a web app, you'd need to share the sessions etc, so autoscaling isn't >> really any different to juju add-unit except you've got some stuff to >> monitor load and do it without user intervention. Also you'll find the flip >> side to the autoscaling argument where nodes could shutdown mid flow or >> ditch sessions etc, so whilst Im sure in a lot of places it works great, >> you still have to create containers that work properly in a scaling >> environment, which is exactly the same as when you design charms :) >> >> > Yes! Kubernetes autoscaling only works for stateless services. These > services should connect to an external datastore if they want stuff like > sessions. > > Applications that aren't "cloud-native" can't be autoscaled by Kubernetes > because they require more than "spin up another service and connect it to > the load balancer and the datastore". They need more complex configuration; > configuration that Juju is great at! Kubernetes is great at scheduling, > Juju is great at orchestration. Hence Juju + K8s = goodness. > > >> I agree with the image stuff to some extent, certainly I've used that as >> a selling point, the flip side of course is, do you run apt-get update when >> you start a container? Maybe, but most people won't, what about the latest >> security flaws in applications that will go unpatched? It also makes for >> complacency . >> >> > The sane way to use Docker is to build the image as part of a CI/CD > pipeline. Dev triggers a rebuild when code changes, ops triggers a rebuild > to fix security issues. After a rebuild, the ci system tests the image > heavily. If all tests succeed, the image gets deployed to production and > you are 100% sure that all prod images will be 100% what you just tested. > Reproducability so that wat runs in production is exactly what is tested. > > Although many people think that Docker means "what the dev runs on his > machine is what runs in production" which is obviously a bad idea and no > technology will fix that. > > Of course I agree, plenty of large businesses do run their stuff in >> docker, I use docker in production, I'm not saying don't use docker :) I'm >> just saying that in reality its not the panacea a lot of people who want to >> do high volume scale out apps think it is, not without writing a lot of >> code around it for your own solution :) >> >> On Fri, Nov 18, 2016 at 2:34 PM, Merlijn Sebrechts < >> merlijn.sebrec...@gmail.com> wrote: >> >>> I'm mostly working with researchers and people developing early >>> prototypes. I can't blame them for using technologies that aren't >>> production ready. That said, I attended pragmatic docker days a while back >>> and there were some companies, like Yelp, who found a good way to run >>> Docker in production so it is possible, given you have a boatload of good >>> ops people. >>> >>> Big Data Europe <https://www.big-data-europe.eu/> seems to be going >>> towards Docker containers for scalable Hadoop setups >>> <https://www.big-data-europe.eu/scalable-sparkhdfs-workbench-using-docker/>. >>> Not that it's a production ready setup, but with a name like that and H2020 >>> funding, we (big data researchers) can't really ignore them... >>> >>> Juju is awesome for us (big data researchers) because we have a bunch of >>> short-lived projects that use Hadoop etc. in a bunch of different setups, >>> and >>> >>> 1. we don't want to be writing a new wrapper around the Hadoop chef >>> cookbook for every project; >>> 2. we don't want to be creating a new "Hadoop + X" Docker container >>> for every setup. >>> >>> However, we can't ignore the advantages of Docker vs Juju: >>> >>> 1. image-based so the same setup is 100% reproducible if you have >>> the image; >>> 2. auto scaling and failure recovery. >>> >>> So we want the stateless, auto-scalable, auto-recoverable images from >>> Docker and we want Juju's relations and automatic configuration. So how to >>> we get docker containers that can be configured at run-time by Juju? Ben is >>> working on something to configure containers >>> <https://github.com/bcsaller/layercake>, but afaik, no integration with >>> Juju planned. >>> >>> PS: We're interested in Mesos but, as always, our time-to-put-into-it is >>> limited.. >>> >>> >>> >>> 2016-11-18 12:27 GMT+01:00 Tom Barber <t...@spicule.co.uk>: >>> >>>> I'll fork this so we're not hijacking another thread. >>>> >>>> Mesos runs Mesos tasks via frameworks or Docker/Rocket containers >>>> currently. Annoyingly they used to have a scriptable container endpoint I >>>> was hoping to knock up a POC against but they removed it, and my C is >>>> woeful so implementing it will take some time. I also asked on the Mesos >>>> mailing lists and they couldn't grok the use case, apparently docker does >>>> everything anyone needs ;) >>>> >>>> When I was at the Pentaho meetup last week, there's already a bunch of >>>> data folk who run DC/OS or Mesos to manage their workloads which sorta >>>> validated my use case as prior to that it was only theoretical. >>>> >>>> There are certainly a bunch of useful docker containers, I wouldn't >>>> deny that for a second, but the docker reality in production is often a lot >>>> like the Big Data stuff a few years back, it works but does it work well >>>> enough. In some places certainly, but in others not so much. We make a lot >>>> of use of Docker recently on some NASA projects, but I'm under no illusions >>>> that in reality Juju running containers would be a much improved plan, but >>>> they already have Mesos etc running so why upset the apple cart? Similarly >>>> at ApacheCon we had developers praising Docker and Systems Administrators >>>> saying its the bane of their life. >>>> >>>> That said, you don't really see people spin up a scalable hadoop setup >>>> in Docker because it would be annoying to maintain, but you could easily do >>>> that in Juju on whatever, or Puppet etc. Of course you can do it, and it >>>> will become more common over time especially with k8s auto scaling etc for >>>> sure. >>>> >>>> Who said Mesos or DC/OS providers and charms wouldn't get official >>>> support? That said currently we're just lacking bandwidth to build them(I >>>> speak entirely as an impartial observer I have no real idea if they'd get >>>> Canonical support, but why not?) ;) >>>> >>>> Tom >>>> >>>> On Fri, Nov 18, 2016 at 9:59 AM, Merlijn Sebrechts < >>>> merlijn.sebrec...@gmail.com> wrote: >>>> >>>>> Wait, wouldn't this require juju to have an "mesos" provider, so juju >>>>> can request lxc containers from mesos? I've heard something like this >>>>> mentioned at the Summit, will this become a reality? [that would be >>>>> awesome!] >>>>> >>>>> We want support for Docker containers because: >>>>> - A lot devs we work with create their prototypes in docker >>>>> - There are a bunch of useful docker containers with stuff that isn't >>>>> charmed yet >>>>> >>>>> We want Kubernetes because: >>>>> - Auto scaling >>>>> - Auto failure recovery >>>>> - It has a future beyond Docker >>>>> - The Charms are officially supported by Canonical (hence Kubernetes >>>>> > Mesos) >>>>> >>>>> >>>>> 2016-11-18 10:41 GMT+01:00 Tom Barber <t...@spicule.co.uk>: >>>>> >>>>>> What you want Merlijn is LXC on Apache Mesos so you can provision a >>>>>> Mesos cluster on MAAS and then provision Juju Charms into LXC on the >>>>>> infinitely scalable cluster! Docker is cool but until it releases the >>>>>> proper orchestration stuff, it comes a poor second to deploying workloads >>>>>> with Juju ;) >>>>>> >>>>>> That's not a slight at the great work Adam, Chuck and co are doing, >>>>>> but feedback I got from people at the Pentaho User meetup last weekend >>>>>> and >>>>>> ApacheCon this week who all get 'stuck' with Docker once the convenience >>>>>> factor has gone away. Anyway, I digress.... Amazing getting proper Docker >>>>>> running on LXD as well. >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> >>> >> >> >> -- >> Tom Barber >> CTO Spicule LTD >> t...@spicule.co.uk >> >> http://spicule.co.uk >> >> GB: +44(0)5603641316 >> US: +18448141689 >> >> >> > -- Tom Barber CTO Spicule LTD t...@spicule.co.uk http://spicule.co.uk GB: +44(0)5603641316 US: +18448141689
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
