artsy-github-io-sroaub.txt (18422B)
1 [1] 2 3 • [2]API 4 • [3]Careers 5 • [4]@artsyopensource 6 • [5]Artsy.net 7 8 [6]Open Source 9 10 [7]Artsy 11 12 [8]Engineering Blog 13 14 toggle menu 15 [10] 16 17 Introduction to AWS OpsWorks 18 19 Aug 27, 2013 20 21 [11]Joey Aghion 22 23 [12]@joeyAghion 24 25 OpsWorks is a new service from Amazon that promises to provide high-level tools 26 to manage your EC2-based deployment. From [13]the announcement: 27 28 AWS OpsWorks features an integrated management experience for the entire 29 application lifecycle including resource provisioning, configuration 30 management, application deployment, monitoring, and access control. It will 31 work with applications of any level of complexity and is independent of any 32 particular architectural pattern. 33 34 After scratching our heads about exactly what that meant, we tried it anyway. 35 If you’ve been straining at the limits of your Platform as a Service (PaaS) 36 provider, or just wishing for more automation for your EC2 deployment, you may 37 want to try it out too. 38 39 Artsy has been experimenting with OpsWorks for a few months now and recently 40 adopted it for the production [14]artsy.net site. We’re excited to share what 41 we’ve learned in the process. 42 43 [15] OpsWorks overview 44 45 Why OpsWorks? 46 47 If you’ve worked with the confusing array of AWS services in the past, you’re 48 already wondering how OpsWorks fits in. Amazon’s own [16]Elastic Beanstalk or 49 PaaS providers such as [17]Heroku typically focus on making your application as 50 simple as possible to deploy. You don’t have to worry about the underlying 51 hardware or virtual resources; the platform manages that transparently. 52 Dependencies (such as a data-store, cache, or email server) often take the form 53 of external services. 54 55 But this simplicity comes at a cost. Your application’s architecture is 56 constrained to a few common patterns. Your functionality may be limited by the 57 system packages available in the standardized environment, or your performance 58 may be limited by the available resources. OpsWorks offers more flexibility and 59 control, allowing you to customize the types of servers you employ and the 60 layers or services that make up your application. It’s a lower-level tool than 61 those PaaS providers. 62 63 Conversely, OpsWorks offers higher-level control than [18]CloudFormation or 64 than managing EC2 instances and related services directly. By focusing on the 65 most commonly used AWS services, instance types, and architectures, it can 66 provide greater automation and more robust tools for configuration, 67 authorization, scaling, and monitoring. Amazon CTO [19]Werner Vogels rendered 68 it thus: 69 70 [20] How OpsWorks fits in AWS offerings 71 72 Historically, Artsy delegated dev-ops concerns to Heroku. They worried about 73 infrastructure, freeing us to focus on our application’s higher-level goals. 74 Increasingly though, we were forced to work around limitations of the 75 platform’s performance, architecture, and customizability. (We even blogged 76 about it [21]here, [22]here, [23]here, [24]here, and [25]here.) Rather than 77 continue to work against the platform, we turned to OpsWorks for greater 78 flexibility while keeping administrative burden low. 79 80 OpsWorks Overview 81 82 OpsWorks comes with a new vocabulary. Let’s look at the major concepts: 83 84 • A Stack is the highest-level container. It groups custom configuration and 85 houses one or more applications. To manage a simple to-do list site, you’d 86 create a todo stack, although you might choose to have separate 87 todo-production and todo-staging stacks. 88 • Each stack has one or more Layers. Think of these as definitions for 89 different server roles. A simple static web site might have a single Nginx 90 layer. A typical web application might instead have a load-balancer layer, 91 a Rails layer, and a MySQL layer. OpsWorks defines plenty of [26]built-in 92 layers (for Rails, HAProxy, PHP, Node, Memcached, MySQL, etc.), but you can 93 also define your own. 94 • Applications are your code, sourced from a git or subversion repository, an 95 S3 bucket, or even an external web site. A typical Rails site might have a 96 single application defined, but you can define multiple applications if 97 you’d like to configure, scale, and monitor them together. 98 • Finally, we define Instances and assign each to one or more layers. These 99 are the EC2 servers themselves. You can start instances manually, or 100 configure them to start and stop on a schedule or in response to load 101 patterns. 102 103 Configuring your stack 104 105 If your app employs a common architecture, you can probably use the OpsWorks 106 dashboard to define layers, add a few instances, link your git repo and be up 107 and running. Examples: 108 109 • A static web site hosted on Nginx 110 • A single-server PHP app 111 • A Rails app with an [27]HAProxy load-balancer, unicorn app servers, and 112 MySQL database 113 • A Node.js app using [28]Elastic Load Balancer and a Memcached cache 114 115 You can find [29]detailed walk-throughs of a few such common use cases in the 116 OpsWorks docs. 117 118 [30] PHP app instances (image from AWS blog) 119 120 If the built-in layers don’t quite satisfy your needs, there are several 121 facilities for customization. But first, it’s useful to understand how OpsWorks 122 manages your instances. 123 124 Chef cookbooks 125 126 OpsWorks uses [31]Chef to configure EC2 instances. If you’re unfamiliar, Chef 127 is a popular tool for making server configuration more automated and 128 repeatable—like code. The Chef “recipes” that configure each layer are 129 open-source and available in the [32]opsworks-cookbooks github repo. (Cookbooks 130 contain one or more “recipes”—get it?) There, you can see precisely what 131 commands are run in response to server lifecycle events (i.e., as servers are 132 started, configured, deployed to, and stopped). These recipes write out 133 configuration files, restart services, authorize users for SSH access, ensure 134 logs are rotated, etc.—everything typical deployments might need. 135 136 For example, the recipes that set up an HAProxy instance look like this: 137 138 [33] Built-in recipes for the HAProxy layer 139 140 Overriding configuration “attributes” 141 142 Chef cookbooks accept parameters in the form of “node attributes.” The default 143 attributes will serve you well in most cases. To override them, edit the 144 stack’s [34]custom Chef JSON. For example, to configure Unicorn to run 8 145 workers instead of 16 and Memcached to bind to port 11212 instead of 11211, 146 you’d enter the following for your stack’s custom JSON: 147 148 [35] <img src=”/images/2013-08-27-introduction-to-aws-opsworks/custom_json.png” 149 alt=”{“rails:” {“max_pool_size”: 8}, “memcached”: {“port”: 11212}}” style=””> 150 151 Custom cookbooks 152 153 If setting node attributes isn’t sufficient, you can go further and override 154 the files written out by your layer’s recipes. Simply toggle the Use custom 155 Chef cookbooks option in your stack settings and provide a link to a git, 156 subversion, S3, or HTTP location for your [36]custom cookbooks. 157 158 [37] Enabling custom cookbooks 159 160 Your custom cookbooks bundle can also contain original or [38]borrowed recipes 161 that perform any other custom configuration. Tell OpsWorks when to run your 162 recipes by associating them with the desired events in your layer settings. For 163 example, we use custom recipes at our Rails layer’s setup stage to perform 164 additional Nginx configuration, install a JavaScript runtime, and send logs to 165 [39]Papertrail. 166 167 [40] custom Chef recipes 168 169 OpsWorks shares details about the entire stack with recipes via node 170 attributes, allowing custom recipes to connect to other instances as required. 171 172 Custom layers 173 174 If the built-in layers don’t satisfy your needs even after customization, you 175 can create custom layers. The base OpsWorks configuration is provided (for SSH 176 authorization, monitoring, etc.) and your custom recipes do the rest. For 177 example, we created a custom layer to process background jobs: 178 179 [41] custom background jobs layer 180 181 Down the road, we might introduce additional layers for Redis, Solr, or 182 MongoDB. (Even better, AWS may introduce built-in support for these.) 183 184 Performance 185 186 OpsWorks makes most [42]EC2 instance types available, so we can choose an 187 appropriate balance of CPU power, memory, disk space, network performance, and 188 architecture for each instance. This can be a huge boon to the performance of 189 resource-constrained applications. It probably still pales in comparison to 190 running directly on physical hardware, but this benefit alone could make 191 OpsWorks a worthwhile choice over providers of “standard” computing resources. 192 193 While not a rigorous comparison, the experience of one of our particularly 194 memory-constrained applications illustrates this. The application’s responses 195 took an average of 638 milliseconds when running on Heroku’s [43]“2x” (1 GB) 196 dynos. The same application responded in only 134 milliseconds on 197 OpsWorks-managed m1.large instances (with 7.5 GB). That’s a ~80% (5x) 198 improvement! 199 200 [44] OpsWorks performance superimposed on Heroku performance (chart: New Relic) 201 202 Troubleshooting 203 204 That’s all well and good, but what about when things aren’t working? 205 206 We’ve experienced our fair share of failures with both OpsWorks and Heroku. 207 PaaS providers like Heroku offer a pleasant abstraction, but in doing so reduce 208 our visibility into the systems running our application. (Want to know why a 209 dyno seems to be performing poorly? Good luck diagnosing resource contention, 210 disk space problems, or network latency.) Instead, we’re reduced to repeatedly 211 issuing restart commands. 212 213 In contrast, I can easily SSH into an OpsWorks instance and notice that a 214 runaway process has pegged the CPU or that a chatty log has filled the disk. 215 (Of course, the additional control afforded by OpsWorks increases the chance 216 that I’ve caused the problem myself.) 217 218 Which do we prefer? We’d probably be safer with Heroku’s experts in charge, but 219 I’ll happily accept light sysadmin duties in exchange for the flexibility 220 OpsWorks affords. And by sticking with the OpsWorks default recipes as much as 221 possible, we benefit from the platform’s combined experience. 222 223 Scaling and recovery 224 225 Scalability and recovery are critical, so how does OpsWorks compare to 226 full-featured PaaS providers? Pretty well, actually. 227 228 OpsWorks instances can be launched in multiple AWS availability zones for 229 greater redundancy. And if an instance fails for any reason, OpsWorks will stop 230 it and start a new one in its place. 231 232 Especially useful is the automatic scaling, which can be time-based or 233 load-based. This nicely matches the horizontal scaling needs of our app: we’ve 234 chosen to run additional Rails app servers during peak business hours, and 235 additional background workers when load on existing servers exceeds a certain 236 threshold. 237 238 [45] time-based scaling 239 240 [46] load-based scaling 241 242 When background workers are busy, new instances spin up automatically to tackle 243 the growing queue. That is dev-ops gold. 244 245 Monitoring 246 247 OpsWorks provides a monitoring view of each stack, with CPU, memory, load, and 248 process statistics aggregated by layer. You can drill down to individual 249 instances and review periods anywhere from 1 hour to 2 weeks long. 250 251 [47] OpsWorks monitoring view 252 253 We haven’t tried it, but OpsWorks also offers a built-in [48]Ganglia layer that 254 automatically collects metrics from each of your stack’s instances. 255 256 Conveniently, AWS also sends these metrics to its own [49]CloudWatch monitoring 257 service, where you can configure custom alerts. 258 259 Integration with other AWS services 260 261 You might be noticing a theme here: OpsWorks leverages AWS’s other tools and 262 services quite a bit. 263 264 [50]Identity and Access Management (IAM) allows you to define individual user 265 accounts within an umbrella account for your organization. These users can be 266 authorized for varying levels of access to your OpsWorks stacks. From the 267 Permissions view of each stack, you can then grant them SSH and sudo rights on 268 an individual basis. 269 270 [51] OpsWorks permissions view 271 272 Other tools such as the [52]EC2 Dashboard and [53]AWS API work as you’d hope, 273 with all of the usual functions being applicable to your OpsWorks-managed 274 instances and other services like elastic IPs and EBS volumes. 275 276 Cost 277 278 Pricing is simple and enticing. There’s no charge for using OpsWorks; you pay 279 only for your underlying usage of other AWS resources like EC2 instances, S3 280 storage, bandwidth, elastic IPs, etc. If you’ve purchased [54]reserved 281 instances, those savings will apply as usual. 282 283 Unfortunately, OpsWorks doesn’t yet support [55]spot instances (but I imagine 284 that’s in the works). 285 286 Roadmap 287 288 In the few months since its launch, OpsWorks has added support for [56]ELB, 289 monitoring, custom AMIs, and more recent versions of Chef and Ruby. There’s 290 also an [57]active discussion forum where developers and Amazon employees 291 circulate issues and request features. It’s a relatively new service and can 292 occasionally be rough around the edges, but–knowing AWS–we expect the current 293 pace of enhancements to continue. 294 295 We’ve already launched one major app on OpsWorks and will be looking for more 296 opportunities as it gains a following and grows in sophistication. 297 298 Look for a follow-up post where we document our experience transitioning an app 299 from Heroku to OpsWorks! 300 301 Posted by 302 [58] Joey Aghion 303 [59]Site [60]GitHub [61]@joeyAghion 304 305 Categories: [62]AWS, [63]Heroku, [64]OpsWorks, [65]dev-ops 306 307 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 308 309 Comments 310 311 Please enable JavaScript to view the [66]comments powered by Disqus. 312 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 313 314 [67]« Normalizing GMail E-Mail Addresses with CanonicalEmails [68]Upgrading to 315 Mongoid 4.x » 316 317 • [69]API 318 • [70]Careers 319 • [71]@artsyopensource 320 • [72]Artsy.net 321 322 323 References: 324 325 [1] https://www.artsy.net/ 326 [2] https://developers.artsy.net/ 327 [3] https://www.artsy.net/jobs 328 [4] http://twitter.com/artsyopensource 329 [5] http://www.artsy.net/ 330 [6] https://artsy.github.io/open-source 331 [7] https://artsy.github.io/ 332 [8] https://artsy.github.io/ 333 [10] https://artsy.github.io/blog/2013/08/27/introduction-to-aws-opsworks/ 334 [11] https://artsy.github.io/author/joey 335 [12] https://twitter.com/joeyAghion 336 [13] http://aws.typepad.com/aws/2013/02/aws-opsworks-flexible-application-management-in-the-cloud.html 337 [14] http://artsy.net/ 338 [15] https://artsy.github.io/images/2013-08-27-introduction-to-aws-opsworks/opsworks.png 339 [16] http://aws.amazon.com/elasticbeanstalk/ 340 [17] http://heroku.com/ 341 [18] https://aws.amazon.com/cloudformation/ 342 [19] http://www.allthingsdistributed.com/2013/02/aws-opsworks.html 343 [20] https://artsy.github.io/images/2013-08-27-introduction-to-aws-opsworks/aws_control.png 344 [21] http://artsy.github.io/blog/2012/01/31/beyond-heroku-satellite-delayed-job-workers-on-ec2/ 345 [22] http://artsy.github.io/blog/2012/11/15/how-to-monitor-503s-and-timeout-on-heroku/ 346 [23] http://artsy.github.io/blog/2012/12/13/beat-heroku-60-seconds-application-boot-timeout-with-a-proxy/ 347 [24] http://artsy.github.io/blog/2013/02/01/master-heroku-command-line-with-heroku-commander/ 348 [25] http://artsy.github.io/blog/2013/02/17/impact-of-heroku-routing-mesh-and-random-routing/ 349 [26] http://docs.aws.amazon.com/opsworks/latest/userguide/workinglayers.html 350 [27] http://haproxy.1wt.eu/ 351 [28] http://aws.amazon.com/elasticloadbalancing/ 352 [29] http://docs.aws.amazon.com/opsworks/latest/userguide/walkthroughs.html 353 [30] https://artsy.github.io/images/2013-08-27-introduction-to-aws-opsworks/standard_instances.png 354 [31] http://www.opscode.com/chef/ 355 [32] http://github.com/aws/opsworks-cookbooks 356 [33] https://artsy.github.io/images/2013-08-27-introduction-to-aws-opsworks/haproxy_recipes.png 357 [34] http://docs.aws.amazon.com/opsworks/latest/userguide/workingstacks-json.html 358 [35] https://artsy.github.io/images/2013-08-27-introduction-to-aws-opsworks/custom_json.png 359 [36] http://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-installingcustom-enable.html 360 [37] https://artsy.github.io/images/2013-08-27-introduction-to-aws-opsworks/custom_cookbooks.png 361 [38] http://docs.opscode.com/essentials_cookbooks.html 362 [39] https://papertrailapp.com/ 363 [40] https://artsy.github.io/images/2013-08-27-introduction-to-aws-opsworks/custom_recipes.png 364 [41] https://artsy.github.io/images/2013-08-27-introduction-to-aws-opsworks/custom_layer.png 365 [42] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html 366 [43] https://devcenter.heroku.com/articles/dyno-size 367 [44] https://artsy.github.io/images/2013-08-27-introduction-to-aws-opsworks/new_relic_comparison.png 368 [45] https://artsy.github.io/images/2013-08-27-introduction-to-aws-opsworks/time-based_scaling.png 369 [46] https://artsy.github.io/images/2013-08-27-introduction-to-aws-opsworks/load-based_scaling.png 370 [47] https://artsy.github.io/images/2013-08-27-introduction-to-aws-opsworks/monitoring.png 371 [48] http://docs.aws.amazon.com/opsworks/latest/userguide/workinglayers-ganglia.html 372 [49] http://aws.amazon.com/cloudwatch/ 373 [50] http://aws.amazon.com/iam/ 374 [51] https://artsy.github.io/images/2013-08-27-introduction-to-aws-opsworks/permissions.png 375 [52] https://console.aws.amazon.com/ec2 376 [53] http://docs.aws.amazon.com/AWSRubySDK/latest/frames.html 377 [54] http://aws.amazon.com/ec2/reserved-instances/ 378 [55] http://aws.amazon.com/ec2/spot-instances/ 379 [56] http://aws.amazon.com/elasticloadbalancing/ 380 [57] https://forums.aws.amazon.com/forum.jspa?forumID=153 381 [58] https://artsy.github.io/author/joey 382 [59] http://joey.aghion.com/ 383 [60] https://github.com/joeyAghion 384 [61] https://twitter.com/joeyAghion 385 [62] https://artsy.github.io/blog/categories/aws/ 386 [63] https://artsy.github.io/blog/categories/heroku/ 387 [64] https://artsy.github.io/blog/categories/opsworks/ 388 [65] https://artsy.github.io/blog/categories/dev-ops/ 389 [66] http://disqus.com/?ref_noscript 390 [67] https://artsy.github.io/blog/2013/06/23/normalizing-gmail-email-addresses-with-canonical-emails/ 391 [68] https://artsy.github.io/blog/2013/11/07/upgrading-to-mongoid4/ 392 [69] https://developers.artsy.net/ 393 [70] https://www.artsy.net/jobs 394 [71] http://twitter.com/artsyopensource 395 [72] http://www.artsy.net/