Permalink
Browse files

update

remove opml
add html
encourage contributions
describe doozer
update router description (there are now two of them)
update data services (filesystem is no longer an exception)
  • Loading branch information...
1 parent 6d26e1a commit 82dcdb1e7f508bbc27f751318cbed9c9a7b28c4d @ttilley committed Aug 19, 2012
Showing with 390 additions and 41 deletions.
  1. +1 −0 README.md
  2. +1 −0 index.html
  3. +370 −0 stackato.html
  4. +18 −6 stackato.md
  5. +0 −35 stackato.opml
View
1 README.md
View
1 index.html
View
370 stackato.html
370 additions, 0 deletions not shown because the diff is too large. Please use a local Git client to view these changes.
View
24 stackato.md
@@ -1,11 +1,20 @@
# Stackato Essentials #
-This document is fairly loosely collected at the moment. Hopefully someone will still find it useful while it works its way towards equilibrium. ;)
+My personal goal with this document is to provide a somewhat more gentle introduction to Cloud Foundry and Stackato than you might otherwise receive, as well as to shine light on components and functionality that might not be documented in sufficient detail elsewhere.
+
+If you find any of the information here useful, you can thank me by [providing feedback](https://github.com/ttilley/StackatoEssentials/issues). *Please* feel free to fork, improve, and submit pull requests.
## Core Components ##
+![General Architecture](http://docs.stackato.com/_images/stackato-architecture-diagram.png "stackato general architecture")
+
### Doozerd ###
+> Doozer is a highly-available, completely consistent store for small amounts of extremely important data. When the data changes, it can notify connected clients immediately (no polling), making it ideal for infrequently-updated data for which clients want real-time updates.
+> <https://github.com/ActiveState/doozerd>
+
+Doozer is a [recent addition](http://www.activestate.com/blog/2012/08/doozer-distributed-configuration-used-heroku-and-stackato) to the stack that is unique to Stackato, replacing most configuration sources used by other implementations of Cloud Foundry. In standard Cloud Foundry one might SSH into the machine running a service to configure it (via YAML files), and restart said service to pick to those configuration changes. In Stackato you are able to configure the entire cluster from a single location and services react to configuration changes themselves. You are also able to query doozer for information on currently connected nodes.
+
### Prealloc ###
### Stager ###
@@ -20,7 +29,9 @@ The Cloud Controller handles all state transitions, manages users/apps/services,
### Router ###
-The router handles all HTTP traffic into the cluster and maintains distributed routing state. The router responds to realtime updates from DEA nodes. Crude load balancing is performed when an app has multiple instances.
+The router handles all HTTP traffic into the cluster and maintains distributed routing state. The router responds to realtime updates from DEA nodes. Load balancing is performed when an app has multiple instances.
+
+There are currently two implementations of the router component in Stackato (as of 2.2). In order to make use of websockets, one must use router2g rather than the default router.
### NATS ###
@@ -97,7 +108,9 @@ Message passing, via NATS, is the foundation of the Cloud Foundry architecture.
### Data Services ###
-All data services, with the notable exception of the filesystem service, come as three subcomponents: Node, Provisioner, and Gateway. The Node implements the actual service backend. The provisioner handles various logic around provisioning and unprovisioning a specific instance of the service. The gateway provides a REST interface to the provisioner. In practice the provisioner and gateway are usually implemented as a singular daemon.
+All data services have three subcomponents: Node, Provisioner, and Gateway. The Node implements the actual service backend. The provisioner handles various logic around provisioning and unprovisioning a specific instance of the service. The gateway provides a REST interface to the provisioner. In practice the provisioner and gateway are usually implemented as a singular daemon.
+
+Prior to Stackato 2.2, the filesystem service was a special exception to this rule. It did not have a gateway, and was assumed to exist on a singular node. This limitation has since been lifted.
## Application Deployment Flow ##
@@ -120,7 +133,7 @@ This is a shortened version of what happens when you deploy an application:
### Fog ###
-````ruby
+```
require 'rubygems'
require 'fog'
@@ -156,8 +169,7 @@ curl -k "https://api.$(hostname).local/stackato/license" \
-d "email=#{STACKATO_EMAIL}&password=#{STACKATO_PASSWORD}&unix_password=#{STACKATO_PASSWORD}"
EOF
)
-
-````
+```
### Chef ###
View
35 stackato.opml
@@ -1,35 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<opml version="1.0">
-<body>
-<outline text="Stackato Essentials" _note="This document is fairly loosely collected at the moment. Hopefully someone will still find it useful while it works its way towards equilibrium. ;)&#10;"><outline text="Core Components" _note=""><outline text="Doozerd" _note=""></outline>
-<outline text="Prealloc" _note=""></outline>
-<outline text="Stager" _note=""></outline>
-<outline text="DEA" _note=""></outline>
-<outline text="Cloud Controller" _note="The Cloud Controller handles all state transitions, manages users/apps/services, and provides the external REST API used by the stackato client (or VMC, should you so desire).&#10;"></outline>
-<outline text="Health Manager" _note=""></outline>
-<outline text="Router" _note="The router handles all HTTP traffic into the cluster and maintains distributed routing state. The router responds to realtime updates from DEA nodes. Crude load balancing is performed when an app has multiple instances.&#10;"></outline>
-<outline text="NATS" _note="NATS is a lightweight cloud messaging system by Derek Collison, who was previously Chief Architect for TIBCO's messaging products.&#10;&#10;Message passing, via NATS, is the foundation of the Cloud Foundry architecture. It is used for addressing and component discovery, command and control, heartbeats, and various other tasks.&#10;"><outline text="Cloud Controller" _note="* Publish: dea.discover&#10;* Publish: dea.find.droplet&#10;* Publish: dea.locate&#10;* Publish: dea.start&#10;* Publish: dea.stop&#10;* Publish: dea.update&#10;* Publish: droplet.updated&#10;* Publish: healthmanager.health&#10;* Publish: healthmanager.status&#10;* Publish: router.register&#10;* Publish: router.unregister&#10;* Publish: vcap.cc.events&#10;* Publish: vcap.component.announce&#10;* Publish: vcap.stager.{queue}&#10;* Subscribe: cloudcontroller.bulk.credentials&#10;* Subscribe: cloudcontrollers.hm.requests&#10;* Subscribe: dea.advertise&#10;* Subscribe: router.start&#10;* Subscribe: vcap.component.discover&#10;"></outline>
-<outline text="DEA" _note="* Publish: dea.advertise&#10;* Publish: dea.heartbeat&#10;* Publish: dea.start&#10;* Publish: droplet.exited&#10;* Publish: router.register&#10;* Publish: router.unregister&#10;* Publish: vcap.component.announce&#10;* Subscribe: dea.discover&#10;* Subscribe: dea.find.droplet&#10;* Subscribe: dea.locate&#10;* Subscribe: dea.status&#10;* Subscribe: dea.stop&#10;* Subscribe: dea.update&#10;* Subscribe: dea.{uuid}.start&#10;* Subscribe: droplet.status&#10;* Subscribe: healthmanager.start&#10;* Subscribe: router.start&#10;* Subscribe: vcap.component.discover&#10;"></outline>
-<outline text="Health Manager" _note="* Publish: cloudcontrollers.hm.requests&#10;* Publish: healthmanager.start&#10;* Publish: vcap.component.announce&#10;* Subscribe: dea.heartbeat&#10;* Subscribe: droplet.exited&#10;* Subscribe: droplet.updated&#10;* Subscribe: healthmanager.health&#10;* Subscribe: healthmanager.status&#10;* Subscribe: vcap.component.discover&#10;"></outline>
-<outline text="Router" _note="* Publish: router.start&#10;* Publish: vcap.component.announce&#10;* Subscribe: router.register&#10;* Subscribe: router.unregister&#10;* Subscribe: vcap.component.discover&#10;"></outline>
-<outline text="Stager" _note="* Subscribe: vcap.stager.{queue}&#10;"></outline>
-</outline>
-<outline text="Data Services" _note="All data services, with the notable exception of the filesystem service, come as three subcomponents: Node, Provisioner, and Gateway. The Node implements the actual service backend. The provisioner handles various logic around provisioning and unprovisioning a specific instance of the service. The gateway provides a REST interface to the provisioner. In practice the provisioner and gateway are usually implemented as a singular daemon.&#10;"></outline>
-</outline>
-<outline text="Application Deployment Flow" _note="This is a shortened version of what happens when you deploy an application:&#10;&#10;1. stackato push&#10;2. framework detection&#10;3. create app in CloudController&#10;4. framework staging plugin&#10;5. droplet creation&#10;6. request DEA for app&#10;7. an available DEA node responds&#10;8. droplet is deployed to the DEA&#10;9. DEA starts the app&#10;10. upon successful start, the router creates a route&#10;"></outline>
-<outline text="Cluster Setup" _note=""><outline text="Roles" _note=""></outline>
-<outline text="Fog" _note="````ruby&#10;require 'rubygems'&#10;require 'fog'&#10;&#10;STACKATO_V207_AMI = &quot;ami-595bf530&quot;&#10;&#10;AWS_ACCESS_KEY_ID = ENV[&quot;AWS_ACCESS_KEY_ID&quot;]&#10;AWS_SECRET_ACCESS_KEY = ENV[&quot;AWS_SECRET_ACCESS_KEY&quot;]&#10;EC2_REGION = ENV[&quot;EC2_REGION&quot;] || &quot;us-east-1&quot;&#10;EC2_AVAILABILITY_ZONE = ENV[&quot;EC2_AVAILABILITY_ZONE&quot;] || &quot;us-east-1d&quot;&#10;&#10;STACKATO_EMAIL = ENV[&quot;STACKATO_EMAIL&quot;] || &quot;stackato@stackato.local&quot;&#10;STACKATO_PASSWORD = ENV[&quot;STACKATO_PASSWORD&quot;] || &quot;stackato&quot;&#10;&#10;connection = Fog::Compute.new({&#10; :provider =&gt; :AWS,&#10; :aws_access_key_id =&gt; AWS_ACCESS_KEY_ID,&#10; :aws_secret_access_key =&gt; AWS_SECRET_ACCESS_KEY,&#10; :region =&gt; EC2_REGION&#10;})&#10;&#10;server = connection.servers.bootstrap({&#10; :private_key_path =&gt; &quot;~/.ec2/default.pem&quot;, &#10; :public_key_path =&gt; &quot;~/.ec2/default.pem.pub&quot;, &#10; :availability_zone =&gt; EC2_AVAILABILITY_ZONE, &#10; :username =&gt; &quot;ubuntu&quot;, &#10; :image_id =&gt; STACKATO_V207_AMI,&#10; :flavor_id =&gt; &quot;m1.small&quot;,&#10; :bits =&gt; 64&#10;})&#10;&#10;server.ssh(&lt;&lt;EOF&#10;curl -k &quot;https://api.$(hostname).local/stackato/license&quot; \&#10; -d &quot;email=#{STACKATO_EMAIL}&amp;password=#{STACKATO_PASSWORD}&amp;unix_password=#{STACKATO_PASSWORD}&quot;&#10;EOF&#10;)&#10;&#10;````&#10;"></outline>
-<outline text="Chef" _note=""></outline>
-<outline text="CloudInit" _note=""><outline text="risks" _note=""></outline>
-</outline>
-</outline>
-<outline text="Monitoring" _note=""><outline text="Ganglia" _note=""></outline>
-</outline>
-<outline text="Auto-Scaling" _note=""></outline>
-<outline text="Troubleshooting" _note=""><outline text="Application Crash" _note="If an application crashes, the linux container for that app sticks around for about an hour by default before getting cleaned up. This allows you to ssh into the container and perform any necessary debugging. Logs will also be available to you this way, even if they are not directly available via the dashboard any longer.&#10;&#10;&gt;Note: you can access an app as it's owner, or as an admin with the --group='owner@email' option to the stackato CLI. The way option ordering works, the group option must come before the ssh command:&#10;&gt;````&#10;&gt;stackato --group='owner@email.com' ssh appname&#10;&gt;````&#10;&#10;In the scenario of an application crash:&#10;&#10;1. The DEA node detects the unexpected exit and broadcasts a message to NATS&#10;2. Routers remove the crashed app from the routing table&#10;3. The Health Manager notifies the Cloud Controller&#10;4. The Cloud Controller re-starts the instance&#10;"></outline>
-<outline text="DEA Crash" _note="In the scenario of a DEA node crash:&#10;&#10;1. Applications handled by the DEA become unavailable&#10;2. The Health Manager notices the missing instances and notifies the Cloud Controller&#10;3. The Cloud Controller requests DEA nodes for the apps&#10;4. As DEA nodes reply, application instances will be started on these new DEA nodes&#10;&#10;Note that as part of the Prealloc/DEA init that occurs when starting the DEA service, previously existing linux containers are cleaned up and removed. If you need any of that data for debugging or analysis then you will want to copy it to another location than /lxc/containers or /mnt/lxc/containers.&#10;"></outline>
-<outline text="Inotify" _note="````&#10;fs.inotify.max_user_instances = 4096&#10;fs.inotify.max_user_watches = 32768&#10;fs.inotify.max_queued_events = 65536&#10;````&#10;"></outline>
-</outline>
-</outline>
-</body>
-</opml>

0 comments on commit 82dcdb1

Please sign in to comment.