All of this was in an organised company!<\/p>\n
The Now<\/h2>\n
The new norm is to use hosted instances. You can scale these up and down So, how can we take advantage of the flexibility of containers to help What if you could have an Auto Scaling Group (ASG) with an On-Demand Go to the Catalog > Community and select AutoSpotting. Fill in the AWS Access Key and Secret Key. (These are the only autoscaling:DescribeAutoScalingGroups<\/p>\n autoscaling:DescribeLaunchConfigurations<\/p>\n autoscaling:AttachInstances<\/p>\n autoscaling:DetachInstances<\/p>\n autoscaling:DescribeTags<\/p>\n autoscaling:UpdateAutoScalingGroup<\/p>\n ec2:CreateTags<\/p>\n ec2:DescribeInstances<\/p>\n ec2:DescribeRegions<\/p>\n ec2:DescribeSpotInstanceRequests<\/p>\n ec2:DescribeSpotPriceHistory<\/p>\n ec2:RequestSpotInstances<\/p>\n ec2:TerminateInstances<\/p>\n Optionally, set the Tag Name. By default, it will look for Add the tag (user-specified or spot-enabled, with a value of
\nbased on requirements and demand. Servers are available in a matter of
\nseconds. With containers, you no longer care about actual servers. You
\nonly care about compute resource. Once you have an orchestrator like
\nRancher<\/a>, you don\u2019t need to worry
\nabout maintaining scale or setting where containers run, as Rancher
\ntakes care of all of that. Rancher continuously monitors and assesses
\nthe requirements that you set and does its best to ensure that
\neverything is running. Obviously, we need some compute resource, but it
\ncan run for days or hours. The fact is, with containers, you pretty much
\ndon\u2019t need to worry.<\/p>\nReducing Cost<\/h2>\n
\nus reduce costs? There are a couple of things that you can do. Firstly
\n(and this goes for VMs as well as containers), do you need all your
\nenvironments running all the time? In a world where you own the kit and
\nthere is no cost advantage to shutting down environments versus keeping
\nthem running, this practice was accepted. But in the on-demand world,
\nthere is a cost associated with keeping things running. If you only
\nutilise a development or testing environment for eight hours a day, then
\nyou are paying four times as much by keeping it running 24 hours a day!
\nSo, shutting down environments when you\u2019re not using them is one way to
\nreduce costs. The second thing you can do (and the main reason behind
\nthis post) is using Spot Instances<\/a>.
\nNot heard of them? In a nutshell, they\u2019re a way of getting cheap
\ncompute resource in AWS. Interested in saving up to 80% of your AWS EC2
\nbill? Then keep reading. The challenge with Spot Instances is that they
\ncan terminate after only two minutes\u2019 notice. That causes problems for
\ntraditional applications, but containers handle this more fluid nature
\nof applications with ease. Within AWS, you can directly request Spot
\nInstances, individually or in a fleet, and you set a maximum price for
\nthe instance. Once you breach this price, AWS gives you two minutes and
\nthen terminates the instance.<\/p>\nAutoSpotting<\/h2>\n
\nInstance type to which you could revert if you breached the Spot
\nInstance price? Step forward an awesome piece of open-source software
\ncalled AutoSpotting. You can find the source and more information on
\nGitHub<\/a>. AutoSpotting works by
\nreplacing On-Demand Instances from within an ASG with individual Spot
\nInstances. AutoSpotting takes a copy of the launch config of the ASG and
\nstarts a Spot Instance (of equivalent spec or more powerful) with the
\nexact same launch config. Once this new instance is up and running,
\nAutoSpotting swaps out one of the On-Demand Instances in the ASG with
\nthis new Spot Instance, in the process terminating the more expensive
\nOn-Demand Instance. It will continue this process until it replaces all
\ninstances. (There is a configuration option that allows you to specify
\nthe percentage of the ASG that you want to replace. By default, it\u2019s
\n100%.) AutoSpotting isn\u2019t application aware. It will only start a
\nmachine with an identical configuration. It doesn\u2019t perform any
\ngraceful halting of applications. It purely replaces a virtual instance
\nwith a cheaper virtual instance. For these reasons, it works great for
\nDocker containers that are managed by an orchestrator like Rancher. When
\na compute instance disappears, then Rancher takes care of maintaining
\nthe scale. To facilitate a smoother termination, I\u2019ve created a helper
\nservice, AWS-Spot-Instance-Helper, that monitors to see if a host is
\nterminating. If it is, then the helper uses the Rancher evacuate
\nfunction to more gracefully transition running containers from the
\nterminating host. This helper isn\u2019t tied to AutoSpotting, and anyone
\nwho is using Spot Instances or fleets with Rancher can use it to allow
\nfor more graceful terminations. Want an example of what it does to the
\ncost of running an environment?
\n![\"\"](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2017\/10\/13065924\/aws-auto.png\")
<\/a>
\nCan you guess which day I implemented it? OK, so I said up to 80%
\nsavings but, in this environment, we didn\u2019t replace all instances at the
\npoint when I took this measurement. So, why are we blogging about it
\nnow? Simple: We\u2019ve taken it and turned it into a Rancher Catalog
\napplication so that all our Rancher AWS users can easily consume it.<\/p>\n3 Simple Steps to Saving Money<\/h2>\n
Step 1<\/h3>\n
\n![\"\"](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2017\/10\/13070030\/auto-247x300.png\")
<\/a><\/p>\nStep 2<\/h3>\n
\nmandatory fields.) The user must have the following AWS permissions:<\/p>\n
\nspot-enabled. I\u2019ve slightly modified the original code to allow the
\nflexibility of running multiple AutoSpotting containers in an
\nenvironment. This modification allows you to use multiple policies in
\nthe same AWS account. Then, click Launch.<\/p>\nStep 3<\/h3>\n
\ntrue) to any AWS ASGs on which you want to save money. Cheap (and
\noften more powerful) Spot Instances will gradually replace your
\ninstances. To deploy the AWS-Spot-Instance-Helper service, simply
\nbrowse to the Catalog > Community and launch the application.
\n![\"\"](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2017\/10\/13070120\/helper-250x300.png\")
<\/a>
\nThanks goes out to Cristian M\u0103gheru\u0219an-Stanciu and other
\ncontributors<\/a>
\nfor writing such a great piece of open-source software.<\/p>\nAbout the Author<\/h3>\n
![\"\"](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2017\/11\/21103711\/ChrisUrwin-300x286.jpg\")
Chris Urwin works
\nas a field engineer for Rancher Labs based out of the UK, helping our
\nenterprise clients get the most out of Rancher.<\/p>\n