| | |
| | | = Ansible Agnostic Deployer |
| | | This repository contains various Ansible playbooks, templates, and other support |
| | | files used to provision OpenShift environments onto AWS. |
| | | == Overview |
| | | |
| | | == Prerequisites |
| | | |
| | | There are several prerequisites for using this repository, scripted and detailed |
| | | instructions for usage are available in the following the |
| | | link:./Preparing_your_workstation.adoc[Preparing Your Workstation] document. |
| | | [estimated effort 5-10 minutes] |
| | | |
| | | * AWS Credentials and Policies: |
| | | - AWS user account with credentials to provision resources |
| | | - A route53 link:http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html[public hosted zone] |
| | | is required for the scripts to create the various DNS entries for the |
| | | resources it creates. The "HostedZoneId" will need to be provided in the |
| | | variable file. |
| | | - An EC2 SSH keypair should be created in advance and you should save the key |
| | | file to your system. (command line instructions can be found in the |
| | | link:./Preparing_your_workstation.adoc[Preparing Your Workstation] document.) |
| | | * Software required on provisioning workstation: |
| | | - [Python](https://www.python.org) version 2.7.x (3.x untested and may not work) |
| | | - [Python Boto](http://docs.pythonboto.org) version 2.41 or greater |
| | | - [Git](http://github.com) any version would do. |
| | | - [Ansible](https://github.com/ansible/ansible) version 2.1.2 or greater |
| | | - [awscli bundle](https://s3.amazonaws.com/aws-cli/awscli-bundle.zip) tested |
| | | with version 1.11.32 |
| | | Ansible Agnostic Deployer, AKA *AAD*, AKA *AgnosticD*, is a fully automated 2 |
| | | Phase deployer for building and deploying everything from basic infrastructure |
| | | to fully configured running application environments running on either public |
| | | Cloud Providers or OpenShift clusters. |
| | | |
| | | |
| | | == Standard Configurations |
| | | *AgnosticD* is not an OpenShift Deployer, though it can and does that, it is |
| | | however also a deployer that just happens to be used to deploy a lot of |
| | | OpenShift and OpenShift workloads, amongst other things. |
| | | |
| | | * Several "Standard Configurations" are included in this repository. |
| | | * A "Standard Configurations" or "Config" are a predefined deployment examples |
| | | that can be used or copied and modified by anyone. |
| | | * A "Config" will include all the files, templates, pre and post playbooks that |
| | | a deployment example requires to be deployed. |
| | | * "Config" specific Variable files will be included in the "Config" directory as |
| | | well. |
| | | === Make your first Deployment |
| | | |
| | | NOTE: Until we implement using Ansible Vault, each "Config" has two vars files |
| | | `_vars` and `_secret_vars`. The `example_secret_vars` file shows the format for |
| | | what to put in your `CONFIGNAME_secret_vars` file. |
| | | Check out this link:https://www.youtube.com/watch?v=lfHYwXJhKB0[Video Introduction to deploying with Ansible AgnosticD]! |
| | | |
| | | Get started and use agnosticd to deploy on OpenStack with link:docs/First_OSP_Env_walkthrough.adoc[First OSP Environment Walkthrough]. |
| | | |
| | | == Running the Ansible Playbooks |
| | | There are many link:./ansible/configs[configs] you can choose from, here are three |
| | | that you can start with and modify to fit your needs: |
| | | |
| | | Once you have installed your prerequisites and have configured all settings and |
| | | files, simply run Ansible like so: |
| | | * link:./ansible/configs/just-some-nodes-example/[Just some nodes] - Simple, multi-cloud. |
| | | |
| | | ---- |
| | | ansible-playbook -i 127.0.0.1, ansible/main.yml -e "env_type=config-name" -e "aws_region=ap-southeast-2" -e "guid=youruniqueidentifier" |
| | | * link:./ansible/configs/three-tier-app/README.adoc[Three Tier App] - Relatively |
| | | simple environment, which deploys by default just a bunch of Linux hosts ready |
| | | to be configured. |
| | | |
| | | ---- |
| | | * link:./ansible/configs/ocp4-workshop/README.adoc[OCP4 Workshop] - If a fully |
| | | installed OpenShift Cluster is what you are looking for then take a look here. There is link:ansible/configs/ocp4-cluster[one for OSP too]. |
| | | |
| | | NOTE: Be sure to exchange `guid` for a sensible prefix of your choosing. |
| | | * link:./ansible/roles/ocp-workload-rhte-mw-api-biz/readme.adoc[API as a Business demo Deployment] - Want to deploy a workload onto your existing OpenShift Cluster? |
| | | or local instance running on your laptop? 3Scale is an example of one of |
| | | around *30* OpenShift workloads ready to go. |
| | | |
| | | For "opentlc-shared" standard config, check out the link:./ansible/configs/opentlc-shared/README.adoc[README] file |
| | | === How AgnosticD Deploys |
| | | |
| | | == Cleanup |
| | | * For OpenShift _Workloads_ *AgnosticD* executes an ansible *role* against an |
| | | existing OpenShift cluster. Roles can be found link:./ansible/roles/[here] and |
| | | begin `ocp-workload-*`. |
| | | |
| | | * S3 Bucket |
| | | - An S3 bucket is used to back the Docker registry. AWS will not let you delete a |
| | | non-empty S3 bucket, so you must do this manually. The `aws` CLI makes this |
| | | easy: |
| | | + |
| | | ---- |
| | | aws s3 rm s3://bucket-name --recursive |
| | | ---- |
| | | * For _Configs_ each contain 5 deployment playbooks and supporting files executed |
| | | in sequence and combined with a Cloud Provider to deploy basic infrastructure |
| | | through to fully configured applications. |
| | | |
| | | - Your bucket name is named `{{ env_type }}-{{ guid }}`. So, in the case of a |
| | | `bu-workshop` environment where you provided the `guid` of "Atlanta", your S3 |
| | | bucket is called `bu-workshop-atlanta`. |
| | | image::docs/images/agnosticd_flow.png[width=100%] |
| | | .AgnosticD deployment workflow |
| | | |
| | | * CloudFormation Template |
| | | - Just go into your AWS account to the CloudFormation section in the region where |
| | | you provisioned, find the deployed stack, and delete it. |
| | | === Getting Started |
| | | |
| | | * SSH config |
| | | - This Ansible script places entries into your `~/.ssh/config`. It is recommended |
| | | that you remove them once you are done with your environment. |
| | | The accompanying documentation explains how to achieve all this, extend it and |
| | | add both your own environments, hereafter called _configs_ and a lot lot more. |
| | | Well designed _configs_, can be easily abstracted to allow deployment to multiple |
| | | different Public and Private Clouds including AWS, Azure, and others. |
| | | |
| | | == Troubleshooting |
| | | * link:./docs/[The Documentation Set] Start Here |
| | | * link:./ansible/[./ansible] The working ansible directory |
| | | ** link:./ansible/main.yml[main.yml] The main entry point for `ansible-playbook` |
| | | * link:./ansible/roles[Roles directory] Home to the `ocp-workload-*` roles |
| | | * link:./ansible/configs[Configs directory] Home to the _Configs_ |
| | | |
| | | Information will be added here as problems are solved. So far it's pretty |
| | | vanilla, but quite slow. Expect at least an hour for deployment, if not two or |
| | | more if you are far from the system(s). |
| | | The Contributors Guides explore the relevant structures in significantly more detail: |
| | | |
| | | === EC2 instability |
| | | It has been seen that, on occasion, EC2 is generally unstable. This manifests in |
| | | various ways: |
| | | |
| | | * The autoscaling group for the nodes takes an extremely long time to deploy, or |
| | | will never complete deploying |
| | | |
| | | * Individual EC2 instances may have terrible performance, which can result in |
| | | nodes that seem to be "hung" despite being reachable via SSH. |
| | | |
| | | There is not much that can be done in this circumstance besides starting over |
| | | (in a different region). |
| | | |
| | | === Re-Running |
| | | While Ansible is idempotent and supports being re-run, there are some known |
| | | issues with doing so. Specifically: |
| | | |
| | | * You should skip the tag `nfs_tasks` with the `--skip-tags` option if you |
| | | re-run the playbook **after** the NFS server has been provisioned and |
| | | configured. The playbook is not safe for re-run and will fail. |
| | | |
| | | * You may also wish to skip the tag `bastion_proxy_config` when re-running, as |
| | | the tasks associated with this play will re-write the same entries to your SSH |
| | | config file, which could result in hosts becoming unexpectedly unreachable. |
| | | * link:docs/Creating_an_OpenShift_Workload.adoc[Creating an OpenShift Workload Guide] |
| | | * link:docs/Creating_a_config.adoc[Creating a Config Guide] |
| | | // * link:docs/Creating_a_cloud_deployer.adoc[Creating a Cloud Deployer Guide] |