| | 1 | = Developer Guidelines: DeploymentTools = |
| | 2 | |
| | 3 | == Introduction == |
| | 4 | The coapp needs to allow users to deploy Eden on Linux Servers that may be EC2 instances (preferred). We also need to support features such as: |
| | 5 | * 3-tier Deployment |
| | 6 | * Amazon AutoScaling |
| | 7 | * Management Tasks (Clean Tables/Pull Eden) |
| | 8 | * Allow edition of configuration files |
| | 9 | |
| | 10 | The requirements demand the need of a library which allows us to communicate with servers and install packages and issue commands remotely. We're using Ansible [http://ansible.com/] for this task. |
| | 11 | |
| | 12 | == Workflow == |
| | 13 | |
| | 14 | * Deploy the coapp using the instructions at [http://eden.sahanafoundation.org/wiki/InstallationGuidelines/Amazon#InstallingDeploymentCoapponEC2] |
| | 15 | * Access the coapp, register a user and create a new Deployment |
| | 16 | * User may add a signle role (all) or multiple roles (db, webserver, eden) |
| | 17 | * User may only associate a single instance (prod/demo) while creating the deployment. Others may be added after succesful deployment of the first one. |
| | 18 | * On form submit, a YML file is generated in the yaml/ directory of the application (examples [https://github.com/gnarula/eden_playbook/tree/master/examples] and ansible is ran using the web2py scheduler. |
| | 19 | * The success/failure is reported once the scheduler task is completed. |
| | 20 | * If successful, the user may further add instances (eg. demo/test) to the same deployment or issue management tasks using tabs/buttons in the rheader (TODO) |
| | 21 | |
| | 22 | == Schema == |
| | 23 | |
| | 24 | TODO: ER Diagram? |
| | 25 | The detailed schema is available at http://paste.ubuntu.com/7872567/ |
| | 26 | |
| | 27 | The setup_deployment table is used to store various attributes related to the deployment. |
| | 28 | |
| | 29 | The setup_instance table is used to store the type of instances along with its URL and a FK to scheduler_id. Each time an instance is added to the deployment, a YAML file is created in the background and ansible is called using the web2py scheduler. |
| | 30 | |
| | 31 | The setup_server_role table is used to store the role (all/db/webserver/eden) of a particular host in the deployment along with its IP and hostname. |
| | 32 | |
| | 33 | The setup_host table acts as a link table to link all the 3 tables above. |
| | 34 | |
| | 35 | '''Background Workflow''' |
| | 36 | * S3SQLInlineComponent/S3SQLInlineLink allows addition of entries in setup_server_role and setup_instance. |
| | 37 | * After form submission and record creation, an entry is added to the scheduler_task table to run ansible (row id of scheduler_task is stored in setup_instance table). Ansible playbook (yaml file) takes in the values of variables from the user input in the create form. |
| | 38 | * Success/Failure of the deployment is displayed on the "read" method of the deployment |
