Confirmed users
66
edits
Web Operations/Reference Specification: Difference between revisions
Jump to navigation
Jump to search
m
Web Operations/Reference Specification (view source)
Revision as of 23:38, 24 July 2014
, 24 July 2014Readability edits and adding some links
(Add clarity around unsupported technology) |
m (Readability edits and adding some links) |
||
| Line 171: | Line 171: | ||
== What technical solutions are we proposing? == | == What technical solutions are we proposing? == | ||
By the virtue of making decisions in section two it is necessary to propose certain technology solutions. Nonetheless, section three is by no means complete, there are many technical solutions yet to be selected. This will require additional time in discovery and testing of solutions before final recommendations can be made. | By the virtue of making decisions in section two it is necessary to propose certain technology solutions. Nonetheless, section three is by no means complete, there are many technical solutions yet to be selected. This will require additional time in discovery and testing of solutions before final recommendations can be made. | ||
* Librarian-puppet & r10k | |||
A number of technology decisions come with discussions and rationalizations. In an attempt to capture this we have created a collection of [https://wiki.mozilla.org/Web_Operations/Reference_Specification/Discussion_Pages discussion pages]. Many are also linked as footnotes herein. | |||
* [https://github.com/rodjek/librarian-puppet Librarian-puppet] & [http://rubydoc.info/gems/r10k/1.2.1/frames r10k] | |||
* Use Puppet Roles and Profiles model | * Use Puppet Roles and Profiles model | ||
* Cloud based infrastructure | * Cloud based infrastructure | ||
** | ** [http://www.openstack.org/ OpenStack] for in house | ||
** (AWS or Rackspace) for off | ** ([http://aws.amazon.com/ AWS] or [http://www.rackspace.com/cloud/ Rackspace]) for off premises | ||
* HOT ([https://wiki.openstack.org/wiki/Heat/DSL#Heat_Orchestration_Template_.28HOT.29 Heat Orchestration Template]) for the cloud API YAML file | * HOT ([https://wiki.openstack.org/wiki/Heat/DSL#Heat_Orchestration_Template_.28HOT.29 Heat Orchestration Template]) for the cloud API YAML file | ||
** Should work for managing AWS resources as well as | ** Should work for managing AWS resources as well as OpenStack resources | ||
** Solves autoscaling | ** Solves autoscaling | ||
** Centralized service description for each application | ** Centralized service description for each application | ||
* <strike>[https://github.com/racker/dreadnot/ Dreadnot]</strike> | * <strike>[https://github.com/racker/dreadnot/ Dreadnot]</strike> | ||
* [https://github.com/mozilla/captain Captin] [https://github.com/mozilla/shove Shove] | * [https://github.com/mozilla/captain Captin] / [https://github.com/mozilla/shove Shove] | ||
** Likely replacement for Chief | ** Likely replacement for Chief | ||
* Logging? | * Logging? | ||
* Monitoring? | * Monitoring? | ||
** | ** Easy to set up basic [http://www.nagios.org/ Nagios] and/or [http://newrelic.com/server-monitoring New Relic monitoring]… is that enough? | ||
** Nimsoft? | ** Nimsoft? | ||
** How would we tie into MOC monitoring? AFAIK they don’t have a dashboard yet. :( | ** How would we tie into MOC monitoring? AFAIK they don’t have a dashboard yet. :( | ||
| Line 191: | Line 194: | ||
** Best Practice for creating status pages that Nagios (or Nimsoft) can check | ** Best Practice for creating status pages that Nagios (or Nimsoft) can check | ||
* Backups? | * Backups? | ||
** | ** Existing tape-backup solution is not automated and ownership is poorly defined | ||
** AWS S3/Glacier? | ** AWS S3/Glacier? | ||
** NetApp is HA, but very expensive- not cost-effective by itself | ** NetApp is HA, but very expensive- not cost-effective by itself | ||
* | * Configuration settings for applications will be?? | ||
** ex: GA API keys, ADMINS blocks, etc… stuff that can’t go in public github, but should not be IT-managed. That is, stuff where we are currently just keyboard-monkeys for them. | ** ex: GA API keys, ADMINS blocks, etc… stuff that can’t go in public github, but should not be IT-managed. That is, stuff where we are currently just keyboard-monkeys for them. | ||
** whatever it is, devs need to have the ability to add settings themselves | ** whatever it is, devs need to have the ability to add settings themselves | ||
** zookeeper | ** [http://zookeeper.apache.org/ ZooKeeper] | ||
** [http://docs.openstack.org/admin-guide-cloud/content/section_metadata-service.html Metadata API] | ** [http://docs.openstack.org/admin-guide-cloud/content/section_metadata-service.html Metadata API] | ||
** Other ideas? | ** Other ideas? | ||
* The HOT template from production will be used to deploy development environments | * The HOT template from production will be used to deploy development environments | ||
* PaaS?? | * PaaS?? | ||
** Plan to move Stackato over (and potentially auto-scale DEAs) | ** Plan to move [http://www.activestate.com/stackato Stackato] over (and potentially auto-scale DEAs) | ||
** Potential for drop-in OpenShift | ** Potential for drop-in [https://www.openshift.com/ OpenShift] | ||
** Can we figure out how to replace this with an easy-to-use API that uses OpenStack directly? RH/Docker are looking into this already. | ** Can we figure out how to replace this with an easy-to-use API that uses OpenStack directly? RH/Docker are looking into this already. | ||
* There will be a puppet root repository. It will contain: | * There will be a puppet root repository. It will contain: | ||
** Contain all modules (managed by librarian-puppet) | ** Contain all modules (managed by [https://github.com/rodjek/librarian-puppet librarian-puppet]) | ||
** Contain all profile definitions | ** Contain all profile definitions | ||
** Contain all role definition | ** Contain all role definition | ||
| Line 217: | Line 220: | ||
** The checked out contents of the root puppet tree (at a certain tag) | ** The checked out contents of the root puppet tree (at a certain tag) | ||
*** The tag needs to be specified when the image is being built | *** The tag needs to be specified when the image is being built | ||
** A sane version of hiera | ** A sane version of [https://projects.puppetlabs.com/projects/hiera hiera] | ||
** A puppet client | ** A puppet client | ||
*** It doesn't matter which version as the root puppet | *** It doesn't matter which version as the root puppet repository will install its own version | ||
** An init script that | ** An init script that (described below) | ||
* When a machine is spun up it will do the following via an init script: | * When a machine is spun up it will do the following via an init script: | ||
** Introspect the nova-metadata-api to find: | ** Introspect the [http://docs.openstack.org/grizzly/openstack-compute/admin/content/metadata-service.html nova-metadata-api] to find: | ||
*** It's puppet roll | *** It's puppet roll | ||
*** Where | *** Where ZooKeper is (Possibly? Maybe we should use a global DNS name) | ||
*** Might use hira backed by ZooKeeper | |||
** Run puppet applying the correct puppet roll | ** Run puppet applying the correct puppet roll | ||
*** (v1) Heira will be configured to use a yaml file pulled in via the clone of the root puppet tree. Secrets will be stored in a git submodule | *** (v1) Heira will be configured to use a yaml file pulled in via the clone of the root puppet tree. Secrets will be stored in a git submodule | ||
*** (v2) Heira will look to | *** (v2) Heira will look to ZooKeper for configuration data | ||
* The yaml file will look something like this:: | * The yaml file will look something like this:: | ||
** resources: | ** resources: | ||