-
Notifications
You must be signed in to change notification settings - Fork 0
Pallet
Pallet is a library written in Clojure that enables the programmer to automate management of cloud infrastructure. It provides multiple abstractions that are useful for implementing tools to manage your cloud infrastructure.
Here is a short slide-deck describing how pallet sets up your cloud configuration: http://www.scribd.com/doc/51959794/Pallet-at-ArchCamp
There are other tools designed to help manage cloud infrastructure. Two commonly known tools are Puppet and Chef.
Pallet was chosen over tools like Puppet and Chef because it is more simple.
- http://news.ycombinator.com/item?id=3557620
- https://groups.google.com/d/msg/pallet-clj/eFAS0aQgi94/tXMFlxy3UrcJ
Because Pallet is a library, not a framework, it is easier to configure and include in the rest of your system administration toolset.
Another benefit, is you can leverage all of the dependency management tools the java ecosystem provides for versioning your crates. Since crates are simply jar files.
Pallet does all its work by SSHing into the nodes it is configuring and executing shell scripts there. This can be done from any machine, whether the machine your workstation or is in your cloud.
This is a big point of contrast with Chef and Puppet. With these two systems there is some portion of your cloud that is responsible for command-and-control of the rest of the system. For example, in Chef there is a central node which stores all the configuration for your system, and all the other nodes periodically connect to this central authority to check if there is any change in their configuration. This is junk. It couples all sorts of things which shouldn't be coupled, not to mention the unneeded network traffic involved with that polling.
Protocols enable extending core pallet abstractions. For example, using this software construct we can easily extend new cloud provider libraries (which we didn't write) to use Pallet's core abstractions. This way we can harness new cloud services and tools without modifying our cloud management infrastructure.
A hardware specification. This configures things like:
- number of cores
- amount of RAM
- which ports are open in the firewall
- etc.
Example:
(def default-node-spec
(node-spec
:image {:os-family :debian}
:network {:inbound-ports [5984]}
:hardware {:min-cores 1 :min-ram 600}))This is typically used to provide the detailed steps that need to be taken to install and configure a software package. So, it's similar to a .deb or .rpm or a Chef recipe.
However, it does not need to install software. All a crate really is is a construct that bundles related operations that are to be run on a node in the cloud.
A software configuration. This specifies which crates are to be applied. This specification is independent of a physical node. This abstraction basically specifies some abstract role that is to be played by some unspecified number of machines in your cloud. It is only later when you specify a group and, potentially a cluster, that which exact machines and how many of them will fulfill this role.
For example, a pallet server specification can indicate that the Apache and mod_php crates are to be installed (ie. a web server role).
(def
^{:doc "Define a server spec for couchdb"}
couchdb-server
(server-spec
:phases
{:configure (phase-fn
cloudmill.crate.couchdb/install
cloudmill.crate.couchdb/configure
cloudmill.crate.couchdb/start)}))This binds a Node specification to a Server specification. An example specification:
(def
^{:doc "Defines a group spec that can be passed to converge or lift."}
couchdb
(group-spec
"couchdb"
:extends [base-server couchdb-server]
:node-spec default-node-spec))This binds multiple groups together. So, you can specify a web-serving cluster by specifying there should be 3 Apache/mod_php Groups, 2 Database Groups, and 1 Load Balancing Group.