+1 This sounds really interesting. Keep me apprised, please? I'd love to see if there's some integration work we can do here (on top of the kubernetes => mesos integration)
Charles Butler <charles.but...@canonical.com> - Juju Charmer Come see the future of modeling your datacenter: http://jujucharms.com On Thu, Nov 24, 2016 at 9:47 AM, Tom Barber <t...@spicule.co.uk> wrote: > 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 > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
