Dev Week -- Ubuntu Juju Tips and Tricks -- m_3 -- Wed, Aug 29th, 2012
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!