This cookbook was developed based on official Mesosphere documentation for installing the Enterprise Edition of DC/OS (https://docs.mesosphere.com/getting-started/installing/installing-enterprise-edition/)
Because of the current installation method of DC/OS, you will need to provision a separate VM to serve as the bootstrapping node. dcos::bootstrap will download the shell script provided by Mesosphere, read the Chef generated config.yaml template, then shares the custom deployment script generated by the first script. dcos::default will prep the cluster nodes by installing/configuring Docker and a few necessary packages, download the deployment script from the bootstrap node, and execute it. The node will be configured based on its ['dcos']['role'] attribute (allowed values are 'master' and 'slave').
Currently this cookbook has the following assumptions/limitations:
- You are using static IPs for your bootstrap and master nodes
- You are not using a load balancer (should work by only specifying the LB IP as your master but is untested)
- You are using Zookeeper as your storage backend
kitchen converge will produce a lot of nodes that conflict with each other, so you'll need to target your suite. kitchen converge 1m1s will create a bootstrap/zookeeper node in the internal Vagrant network at 192.168.33.10, a master node at 192.168.33.15, and a slave node at 192.168.33.20. The included .kitchen.yml is a bit hackish since test-kitchen is not designed to test multiple nodes.
The cookbook will reboot each node if it detects the need to disable SELinux. Docker will currently refuse to even start if SELinux is in "Permissive" mode. I recommend using an image with SELinux and IPv6 already disabled either manually or using something like Packer. Otherwise, you will need to converge each node twice before it is completely configured. If you don't disable IPv6, you will have networking issues with your Docker containers.
For a list of currently customizable attributes, take a look at attributes/default.rb. You'll likely only need to update ['master-list'] (a hash of the IPs of your master nodes), ['bootstrap']['address'] (the IP of your bootstrap node), ['exhibitor']['zk_hosts'] (also likely the IP of your bootstrap node, but if you have a dedicated ZK cluster already, use that), ['dns'][resolvers] (set to your internal DNS if you have them), and ['dns']['search'] (set to your search domain).
kitchen converge 1m1s-bootstrap
Wait for the node to reboot. It will "fail" after rebooting, but don't worry, this is expected.
kitchen converge 1m1s-bootstrap
kitchen converge 1m1s
Wait for the master and slave nodes to reboot.
kitchen converge 1m1s
Browse to http://192.168.33.15 (The management UI can take a little time to come up)
TODO:
- Create a configuration section as hashes for automatic generation of config.yaml
- Add smart parameterization to config.yaml (if, then)
- Investigate deployment without bootstrap node, which would allow for post-deployment management of masters/slaves with Chef
- Allow custom IP discovery scripts
- Write more tests
- Write more detailed README
- Use nginx to serve generated config from bootstrap node