Snap! Websites
An Open Source CMS System in C++
In order to install snapwebsites, we created bundles.
bundles are XML files that include information on how to install various parts of the software.
If we had a script, it would probably work too, however, over time, i's very easy to end up with parts that you want to update or enhance or parts you want to move from one server to another. The bundle definitions are helping greatly in those matters.
The other reason to having bundles is that you need to install and setup many parts on many computers. A valid installation requires many computers:
Although everything can work on a single computer, the Cassandra database is not safe if run on less than 4 computers (i.e. whenever you need to update a computer, you need to reboot and without at least 4 computers, you break your cluster while the reboot is happening)
The bundles simplify your server setup through the use of the snapmanager system. It will tell the manager what package to install and it also has some pre- and post-installation and pre- and post-removal script capabilities. At times, only those scripts run (at this time, setting up the swap file is just a script.)
Since third party plugins may include their own bundles, we can't just offer one package with the bundles in it and have them installed at the time you insall the snapmanager package. For that reason, we have a folder accessible on the Internet where we can add the bundles. This defines the necessary parameter to install the corresponding packages on your machine.
At this time, our bundles are available on http://bundles.snapwebsites.info/ (we are likely to change that URL to our .org at some point.) For a machine to get a list of bundles, it reads the directory.xml file. This includes a <dir> tag which includes a list of <bundle> tags. At this point there are no attributes to these.
Third party bundles would be found on their own websites. The snapmanager system supports any number of sources for bundles.
Note: For the core modules, this is very similar to the sources.list mechanism as offered by Ubuntu and Debian. The third party bundles are similar to a PPA.
The snapfirewall is not an absolute requirement. You could use your own trusted firewall system instead. However, our bundles and packages include automatic firewall integration which you may have to otherwise handle by hand if you don't use our bundle and package.
Especially, snapfirewall is capable of blocking any one IP address on ALL the computers that run a Snap! Website cluster. So if you have 100 computers running snap and one boso is attacking your systems, he will get blocked by the 100 computers with less than a second (assuming everything is installed properly, of course.) This mechanism won't prevent DoS attacks 100%, but it sure will help without you having to use a 3rd party system such as CloudFlare.
This is why in all our lists below, the bundle::firewall appears everywhere.
Snap! Websites is defined to allow a large break down of the system on many computers.
There are 3 main types computers to setup, but you could have more. For example, ecah backends could be installed on a separate computer. The front ends can be broken in two levels, the "very front end" and "the actual Snap! server".
If you control the computers 100% (i.e. you have your own data center and are running the computers there) then you do not have to run a firewall on each computer, although it is still strongly advice that you do. After all, if a hacker accesses your front ends, what prevents them from accessing your backends if they don't have any firewall setup?
Front end servers with both, snap.cgi and snapserver use the following bundles:
A very front end server with only snap.cgi. This is done for two reasons: added security and to eventually better distribute the load. However, know that the major part of the load will be on the Cassandra cluster, not so much on the front end computers.
The first level backend servers that only run snapserver use the following bundles:
The snapserver gets sent Apache requests through snap.cgi (which is found in "bundle::frontend".) The difference in this case is that you need Very Front End computers which communicate to your Front End Backend computers.
The backend computers are used to run processes against the database whenever time allows.
Note that the DNS is necessary on at least 2 machines. You could also have it installed on one of your front end computers. It is pretty lightweight, especially if you have just one website.
The MySQL bundle works with the List Deamon and the Snap Log deamon. It is required, but not crucial. That is, if the MySQL cluster goes down for a little time, things will recover just fine. At this time we do not offer a way to install the MySQL on a server other than the one running snaplistd and snaplog, but the goal is to allow such installations to happen.
The snapbackend adds a new tab with a list of backends. You may break down your installation to one backend per server or one server with all those backends. If you have a powerful server (i.e. 8 processors, 256Gb, 2Tb of hard drive...) you can use as the backend, one such server is enough.
Each time you want to install a Cassandra node, you can use the bundle::cassandra. This eliminates all dealing with the Cassandra cluster setup. We do it all in our scripts. You have to provide a few parameters such as an IP address to another existing node or whether that node is the first one. Everything is pretty much automatic from there. Snap! takes care of creating the data environment (context, tables, etc.)
Notice that the bundle::swap is on purpose NOT installed. You must make sure that you have a computer that respects the minimum requirements for a Cassandra cluster. This means several things:
You may want to specifically check the version of Cassandra that you want to install to make sure you have the necessary computer to do so. You may have to create your own bundle if you want to install a version other than our default Cassandra bundle offers.
Snap! Websites
An Open Source CMS System in C++
