Ubuntu Wiki

   1 [19:00] <m_3> thanks larsu
   2 [19:00] <m_3> hi all
   3 [19:01] <m_3> I'll be talking about some fairly new tools we've recently added to Ubuntu Server
   4 [19:02] <m_3> I've got notes and a demo session set up at the following URL:
   5 === sayan_ is now known as sayan
   6 [19:02] <m_3> http://ec2-107-22-155-155.compute-1.amazonaws.com/
   7 [19:02] <m_3> you can either go there in a browser or just ssh directly in
   8 [19:02] <m_3> the username and password are both 'guest'
   9 [19:02] <m_3> I've got a little overview of where we are in the talk and then a demo session open as well
  10 [19:03] <m_3> ok, so Juju!
  11 [19:04] <m_3> juju's a set of tools that help out when you're managing services involving multiple servers... real or virtual
  12 [19:04] <m_3> in fact... we're really trying to shift the way people think about configuring services on ubuntu server
  13 [19:04] <m_3> instead of thinking about configuring _servers_
  14 [19:04] <m_3> you configure the _services_ themselves
  15 [19:04] <m_3> let's look at some simple examples first
  16 [19:05] <m_3> (dragging heels a bit here to let peeps get connected to the demo site)
  17 [19:05] <m_3> so if we think about a simple stack of services... wordpress for example
  18 [19:06] <m_3> if you're putting this together on servers, you've got a bit of a pain in waiting for one server to reach a certain point of the install, then going to the other one... adding some config... then waiting again
  19 [19:07] <m_3> this really is a synchronization problem or what we like to call "service orchestration"
  20 [19:07] <m_3> well juju solves that problem well
  21 [19:08] <m_3> we can use a handful of really simple examples to deploy a stack of services
  22 [19:08] <m_3> I'll deploy some in real-time while we're chatting
  23 [19:09] <m_3> and that's really it... we just need to wait for those instances to start up
  24 [19:09] <m_3> first question to ask is where are these starting up at?
  25 [19:10] <m_3> these are spun up using a "local" provider (note the addresses)
  26 [19:10] <m_3> ok, well no addresses yet
  27 [19:10] <m_3> :)
  28 [19:10] <m_3> it's building out little ubuntu server instances using lxc containers
  29 [19:10] <m_3> well local provider is only one type
  30 [19:11] <m_3> we can use juju to control services on ec2 cloud, hp cloud (openstack in general)
  31 [19:11] <m_3> as well as orchestrate services on bare metal with MaaS (metal-as-a-service)
  32 [19:11] <m_3> I'll show a couple of examples of providers as we go
  33 [19:12] <m_3> it's worth noting that this is somewhat of a "toy" example
  34 [19:12] <m_3> but don't be fooled by that...
  35 [19:13] <m_3> we can do more sophisticated stacks... consider the mature mediawiki stack for a second
  36 [19:13] <m_3> we'll cover more details here, but I just want to point out that we can use juju to manage a real production-grade stack of services
  37 [19:14] <m_3> mysql with read-only replicas
  38 [19:14] <m_3> multiple wikis
  39 [19:14] <m_3> each with heads fronting multiple nodes
  40 [19:14] <m_3> all attached to the databases with monitoring and caching
  41 [19:14] <m_3> etc
  42 [19:14] <m_3> it's pretty cool from that regard
  43 [19:14] <m_3> so let's back up to our simple example
  44 [19:15] <m_3> so the services we can deploy are numerous
  45 [19:16] <m_3> the template sorta things we use to deploy services are called "charms"
  46 [19:16] <m_3> we've got lots of them already as we saw in the more complex example
  47 [19:16] <m_3> jujucharms.com shows lots more
  48 [19:16] <m_3> ok, let's check in on the simple stack we spun up a sec ago
  49 [19:17] <m_3> ok, we're golden
  50 [19:17] <m_3> note that we have two service units... mysql/0 and wordpress/0
  51 [19:17] <m_3> yes, the /0 implies that there could even be a /1000
  52 [19:17] <m_3> multiple "units" of the same "service"
  53 [19:17] <m_3> juju scales really well, but we'll get back to that in a big
  54 [19:18] <m_3> s/big/bit/
  55 [19:18] <m_3> ok note that these services have ip addrs
  56 [19:18] <m_3> well they've each got dedicated lxc containers
  57 [19:18] <m_3> we could... for instance... ssh into one of them
  58 [19:18] <m_3> so I've ssh'd to a local instance inside of this one
  59 [19:19] <m_3> similarly, if we look at the same stack up on somewhere like ec2
  60 [19:19] <m_3> (I spun this up before the talk)
  61 [19:19] <m_3> node the addresses
  62 [19:19] <m_3> and familiar service units
  63 [19:19] <m_3> mysql/0
  64 [19:19] <m_3> etc
  65 [19:21] <m_3> we can verify that the charm is up and running properly...
  66 [19:21] <m_3> which is as expected once wordpress is up
  67 [19:22] <m_3> note that when we're working on the local provider things respond a bit faster than when using remote cloud providers
  68 [19:23] <m_3> ok, so charms are the templates we use for deploying services
  69 [19:23] <m_3> and we've seen a little bit of the local provider's usefulness
  70 [19:23] <m_3> I'll leak a couple of other tips early here... charmtools
  71 [19:24] <m_3> ok, so a charm is pretty simple
  72 [19:25] <m_3> it's capturing the community's best practice for how to deploy and scale a service
  73 [19:25] <m_3> but it does it through a fairly simple structure
  74 [19:25] <m_3> the hooks/ are the magic
  75 [19:25] <m_3> they're called by juju at the right time
  76 [19:25] <m_3> _that_'s what provides the synchronization / orchestration
  77 [19:27] <m_3> the metadata for each charms shows how the "plug" together
  78 [19:27] <m_3> note the provides and requires
  79 [19:28] <m_3> tic tock
  80 [19:28] <m_3> here we can see how the ones we deployed earlier fit together
  81 [19:29] <m_3> a couple more things about charms
  82 [19:29] <m_3> the hooks are just scripts
  83 [19:29] <m_3> then can be written in any language with an ubuntu runtime
  84 [19:29] <m_3> or even compiled
  85 [19:30] <m_3> they've just gotta play nicely with shell exit codes for juju to know if they errored out or not
  86 [19:30] <m_3> ok, so the talk's supposed to be about tips-n-tricks and not just all about charms
  87 [19:31] <m_3> before I move on, are there any questions about juju in general or charms and the basics of how they work?
  88 [19:32] <m_3> ok, so tips
  89 [19:32] <m_3> we already saw "local provider"
  90 [19:32] <m_3> basics are... use it first and it's a lot quicker
  91 [19:32] <m_3> it really makes for a somewhat production-realistic dev environment
  92 [19:33] <m_3> concurrency issues'll show up earlier here than other local dev methods
  93 [19:33] <m_3> and boom
  94 [19:34] <m_3> now I've caused all sorts of problems for development if the code doesn't handle scaling or concurrencly
  95 [19:34] <m_3> it's cheap and easy for developers to test that out now... _before_ it gets into production
  96 [19:34] <m_3> we see haproxy is pending
  97 [19:35] <m_3> and that we now have a second unit of wordpress
  98 [19:35] <m_3> if you're having troubles with ajaxterm, please just ssh directly into the instance
  99 [19:35] <m_3> there's a limit to how many peeps can connect to ajaxterm at once in this incarnation of the byobu-classroom charm
 100 [19:36] <m_3> and yes, we _are_ eating dogfood here :)
 101 [19:36] <m_3> ok, so local providers cool
 102 [19:36] <m_3> next tip is about managing environments in production
 103 [19:37] <m_3> so juju manages security and access to nodes via ssh
 104 [19:37] <m_3> if you don't tell it otherwise, it injects the cli user's default ssh keys
 105 [19:37] <m_3> well in order for either a.) me to manage the env from multiple machines, or b.) multiple people to manage the environment
 106 [19:38] <m_3> then you've got to either share the private side of that key
 107 [19:38] <m_3> um... don't do that...it's bad :)
 108 [19:38] <m_3> or you set juju up with a list of additional keys to inject into everything
 109 [19:38] <m_3> juju is configured with an environments.yaml file in ~/.juju/environments.yaml
 110 [19:39] <m_3> I'll show you a sanitized version
 111 [19:39] <m_3> I've got three providers in here... local, ec2, and hp's openstack cloud
 112 [19:40] <m_3> the way to add other users to manage an environment is just the `authorized-leys` tag
 113 [19:40] <m_3> we can take a peek in the local mysql
 114 [19:41] <m_3> sorry, local provider sometimes behaves a little differently
 115 [19:41] <m_3> but we see the keys we asked it to inject
 116 [19:41] <m_3> the last one is for that instance we're controlling from
 117 [19:41] <m_3> ok, so next tip
 118 [19:42] <m_3> when we deploy like this...
 119 [19:42] <m_3> we were deploying straight from the ubuntu charmstore
 120 [19:42] <m_3> where you'll get the latest and greatest
 121 [19:43] <m_3> juju caches the version of the charm it deploys with, but only for the lifetime of the service
 122 [19:43] <m_3> that's so I can add extra units later (like we did with wordpress) and it'll use the same version as the first one
 123 [19:43] <m_3> but in general, in production it's a good idea to deploy services you care about from local repos
 124 [19:44] <m_3> note the `--repository` in the second script
 125 [19:44] <m_3> that's going to use the local one
 126 [19:44] <m_3> what I recommend here is that for infrastructure services like haproxy or mysql
 127 [19:44] <m_3> things you'd never really tweak that much except for the (extensive) config they offer
 128 [19:45] <m_3> deploy those services from the store
 129 [19:45] <m_3> custom charms or charms for things that're critical to your infrastructure.... deploy from local repositories
 130 [19:45] <m_3> it's fine to mix and match within a single environment
 131 [19:46] <m_3> now our local env has some charms from the store and some from local
 132 [19:46] <m_3> you can tell from the namespace 'cs' -vs- 'local'
 133 [19:46] <m_3> ok, next tip for production
 134 [19:47] <m_3> I usually set up a dedicated "client" environment to manage a production environment
 135 [19:47] <m_3> we leave a tmux session up that has the right views into the infrastructure
 136 [19:47] <m_3> then people can attach/detach at will
 137 [19:48] <m_3> I've found this easier to manage than to make sure every ops person in the mgmt group has the right cli setup
 138 [19:48] <m_3> ok, just noticed the time...
 139 [19:48] <m_3> there's some cool ones left
 140 [19:48] <m_3> juju ssh takes args
 141 [19:48] <m_3> so...
 142 [19:50] <m_3> that's really useful
 143 [19:50] <m_3> ok, so next trick
 144 [19:50] <ClassBot> There are 10 minutes remaining in the current session.
 145 [19:50] <m_3> jitsu is short for 'juju-jitsu'
 146 [19:50] <m_3> it's pretty much just a set of juju plugins
 147 [19:50] <m_3> lets you pipe juju status to gource
 148 [19:51] <m_3> (can't demo this here... but if you haven't seen gource, google it it rocks!)
 149 [19:51] <m_3> lets you do things like http://www.youtube.com/watch?v=Jfnxl1Kh9SY&feature=g-upl
 150 [19:51] <m_3> the coolest
 151 [19:52] <m_3> and I mean paradigm-shifting coolest thing in this talk
 152 [19:52] <m_3> is the ability to export and import between environments
 153 [19:52] <m_3> that means between _providers_ even
 154 [19:52] <m_3> I can slurp my data out of one region and into another
 155 [19:53] <m_3> we'll do A->B b/c it's simple
 156 [19:54] <m_3> and yes, that worked
 157 [19:54] <m_3> here's vid of local->hp http://www.youtube.com/watch?v=Jfnxl1Kh9SY&feature=g-upl
 158 [19:55] <m_3> and vid of ec2->hp http://www.youtube.com/watch?v=HUtR3_YlKXU&feature=g-upl
 159 [19:55] <m_3> sorry they're pretty raw (dry), but they were backup videos for a demo in case we lost networking at oscon
 160 [19:55] <ClassBot> There are 5 minutes remaining in the current session.
 161 [19:55] <m_3> note that this doesn't move data
 162 [19:56] <m_3> we'd have to do something like the 'juju ssh -e ec2-A mysqldump | juju ssh -e ec2-B mysql'
 163 [19:56] <m_3> ok, that's all folks
 164 [19:56] <m_3> I'll hang around and answer questions in #ubuntu-classroom-chat
 165 [19:57] <m_3> but we live in #juju during mostly west europe and us hours
 166 [19:57] <m_3> thanks!