Cloud Definition 摘要

Resources

• https://martinfowler.com/bliki/CloudComputing.html
• https://www.thoughtworks.com/insights/blog/infrastructure-code-iron-age-cloud-age
• http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
• http://kief.com/automated-server-management-lifecycle.html
• http://kief.com/configuration-drift.html

Summary

The defining characteristic of our move beyond the "Iron Age" and into the "Cloud Age" is that infrastructure can now be treated like software. We get the most value out of this shift when we bring effective software development practices along too, and take advantage of the growing ecosystem of tools designed to support the change,

Digest

Iron Age :

Releasing a new server application meant finding some physical hardware to run it on, configuring that hardware to support the needs of the application, and deploying that application to the hardware. Getting hold of that hardware was usually expensive, but also long winded, usually a matter of months.

Cloud :

Firing up a new server is a matter of seconds, requiring no more than an internet connection and a credit card. This is a dynamic infrastructure where software commands are used to create servers (often virtual machines, but can be installations on bare metal), provision them, and tear them down, all without going anywhere near a screwdriver.

• Five essential characteristics:
  • on demand self-service
  • broad network access : different devices
  • resource pooling : computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand.
  • rapid elasticity : Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.
  • measured service : resource usaging monitoring;
• three service models:
  • software
  • platform
  • infrastructure
• four deployment models
  • private
  • community
  • public
  • hybrid

Server Management Lifecycle

• Package Image -> Provision Instance -> Run Time Update -> Destory
• Manual v.s. Automation
• Run-Time Ad-hoc update should be very tightly controlled to avoid Configuration Drift

Work Content

• Install Bare OS
• Apply System (OS) Customization
  • User Accounts
  • Added Software Packages
  • ...
• Assign SERVICE Role
• Install Service Software and Configuration
• Apply OS System Updates
• Update SERVICE Software and Configuration

Approaches

	Package	Provision
Purpose	Produce Machine Image	Provision Instance based on Machine Image
Tools	CD/ISO/Ghost/Docker	Ansible/Puppet/Others
At least	OS (CD or Build Package), for example JeOS (Just Enough OS)	Service Configuration, for example Connection String
Downside	More Images to Maintain	More Scripts to Maintain and Run
Note	CloningExistingMachineInstances (Not good, since may contains other run time things, for example log, or wrong config) TemplatedMachineInstances	GenericTemplate RoleSpecificTemplates (for specific services)

 

Infrastructure as Code

Benifit

Infrastructure as Code techniques scale effectively to manage large clusters of servers, both in configuring the servers and specifying how they should interact.

Efficiency

All of this allows us to take advantage of dynamic infrastructure by starting up new servers easily, and safely disposing of servers when they are replaced by newer configurations or when load decreases. Creating new servers is just a case of running the script to create as many server instances as needed. This approach is a good fit with PhoenixServers and ImmutableServers

Consistency

Using code to define the server configuration means that there is greater consistency between servers. With manual provisioning different interpretations of imprecise instructions (let alone errors) lead to snowflakes with subtly different configurations, which often leads to tricky faults that are hard to debug. Such difficulties are often made worse by inconsistent monitoring, and again using code ensures that monitoring is consistent too.

Safe & Trackablity & Revertability

Most importantly using configuration code makes changes safer, allowing upgrades of applications and system software with less risk. Faults can be found and fixed more quickly and at worst changes can be reverted to the last working configuration.

Having your infrastructure defined as version-controlled code aids with compliance and audit. Every change to your configuration can be logged and isn't susceptible to faulty record keeping.

Practice

Use Definition Files

All configuration is defined in executable configuration definition files,

• Shell scripts
• Ansible playbooks
• Chef recipes
• Puppet manifests.

At no time should anyone log into a server and make on-the-fly adjustments. Any such tinkering risks creating SnowflakeServers, and so should only be done while developing the code that acts as the lasting definition. This means that applying an update with the code should be fast. Fortunately computers execute code quickly, allowing them to provision hundreds of servers faster than any human could type.

Self-documented systems and processes: 

Rather than instructions in documents for humans to execute with the usual level of human reliability, code is more precise and consistently executed. If necessary, other human readable documentation can be generated from this code.

Version all the things

Keep all this code in source control. That way every configuration and every change is recorded for audit and you can make ReproducibleBuilds to help diagnose problems.

Continuously test systems and processes

Tests allow computers to rapidly find many errors in infrastructure configuration. As with any modern software system, you can set up DeploymentPipelines for your infrastructure code which allows you to practiceContinuousDelivery of infrastructure changes.

Small changes rather than batches

The bigger the infrastructure update, the more likely it is to contain an error and the harder it is to detect that error, particularly if several errors interact. Small updates make it easier to find errors and are easier to revert. When changing infrastructure FrequencyReducesDifficulty.

Keep services available continuously

Increasingly systems cannot afford downtime for upgrades or fixes. Techniques such as BlueGreenDeployment and ParallelChange can allow small updates to occur without losing availability

 

 

 

转载于:https://my.oschina.net/u/3551123/blog/995675