Metadata is mostly for organizing and presenting Parameters in a better way when using CloudFormation in the AWS Web UI.
These are the input parameters for this template. All of these parameters must be supplied for this template to be deployed.
If DEV, TST, we only want a single, timer-based application instance If STG, we want A1 to be a 24/7 KFS application instance, B1 to be timer-based KFS application instance. Rice will be 24/7 instances. If SUP, we don't do anything extra since its deployment is controlled by MET If PRD, want A to be 24/7 application instance, B to be timer-based application instance If it is a prototype, this will be a single NON timer instance handled by Jenkins and cloud-custodian WeekDayTimerEnv is for those environments it is decided to be up only on weekdays mon - fri.
These are all of the actual AWS resources created for this application.
This defines a Layer in the OpsWorks stack. It sets up the Chef cookbooks to pull in from S3, as well as a list of specific Chef recipes to run.
You have to mount the EFS volumes BEFORE installing and running docker, otherwise docker doesn't pick up the mounts.
This defines a Layer in the OpsWorks stack for rice. It sets up the Chef cookbooks to pull in from S3, as well as a list of specific Chef recipes to run.
You have to mount the EFS volumes BEFORE installing and running docker, otherwise docker doesn't pick up the mounts.
This defines the application for the OpsWorks stack. There's one Application for eac Docker container to be deployed. For KFS its just the one container.
The Application mostly provides a secure place to store secret texts for use with the Docker container passed in via environment variables.
This env var sets up an EFS volume to be mounted at '/efs/shared'. The chef recipe ecs-utilities::efs_mount does this.
Docker env variables used by kfs_docker_pull_deploy chef recipe
This part is a bit of a mess, because we have to splice in the environment name into the list of paths to mount into the docker container. There's a single "Non-Prod" and "Prod" EFS volume, and the specific environments will be folders in there, ie "dev", "tst", etc. So for this specific environment being deployed, only the appropriate folder should be mapped in.
The other folders, conf, security, and logs are not shared across EFS, they're built out on the host by the kfs::install_configs chef recipe
Really, these values should ONLY be in the Rice app, and the Rice app should do its own configuration hydration, but at the moment KFS is the only app set up to hydrate configuration files, so now it's responsible for hydrating ALL the configuration files.
Now that we need multiple docker containers, we need multiple OpsWorks Apps.
The way the ecs-docker Chef recipes deal with multiple Apps requires the Docker Login environment variables be on their own App, rather than just part of the single App.
In order to properly respond to initial HTTP traffic on port 80, we need some way to detect and redirect that traffic to HTTPS on 443. This App launches a very stripped down nginx container which only does that.
UAFAWS-301 : Add these two variables hydrated by jenkins, so kfs_docker_pull_deploy can calculate CloudWatch LOG_Group_Name
In order to properly respond to initial HTTP traffic on port 80, we need some way to detect and redirect that traffic to HTTPS on 443. This App launches a very stripped down nginx container which only does that.
This is hardcoded to match the Shortname property of the RiceApplicationLayer
UAFAWS-301 : Add these two variables hydrated by jenkins, so kfs_docker_pull_deploy can calculate CloudWatch LOG_Group_Name
Rhubarb is used to run batch jobs, and is deployed as a separate container along side the application container on the same host.
KFS 7 uses a standalone Rice installation
The prototype Stack will now have -proto appended to their names. Because of the limitations of Cloud custodian + Cloud Formation templates we are going this route.
This defines the OpsWork stack itself. Mostly its network configs and defaults. The main thing in here is the source for the Chef Cookbooks to be used by any layers.
This creates and turns on an OpsWorks EC2 Instance to actually run the application. It is assigned to a specific layer, and that's where it gets the Chef recipes to run.
Currently only a single App Instance is created. Subsequent instances could be created in OpsWorks. IMPORTANT! Any resources created outside of CloudFormation cannot be removed via CloudFormation stack deletion. To be safe, delete all Instances out of OpsWorks before deleting the CloudFormation Stack.
5am - 10pm (non-inclusive) AZ time = 12 - 05 (non-inclusive) UTC 24 hour time
KFS Application node for weekdays only This type of instance will be a timed instance up Monday - Friday 5AM - 10PM
5am - 10pm (mon - fri) AZ time = 12 - 05 (non-inclusive) UTC 24 hour time
5am - 8pm (non-inclusive) AZ time = 12 - 03 (non-inclusive) UTC 24 hour time
5am - 8pm (non-inclusive) AZ time = 12 - 03 (non-inclusive) UTC 24 hour time
5am - 8pm (non-inclusive) AZ time = 12 - 03 (non-inclusive) UTC 24 hour time
These are the various hosts for the Rice application
This creates and turns on an OpsWorks EC2 Instance to actually run the application. It is assigned to a specific layer, and that's where it gets the Chef recipes to run.
Currently only a single App Instance is created. Subsequent instances could be created in OpsWorks. IMPORTANT! Any resources created outside of CloudFormation cannot be removed via CloudFormation stack deletion. To be safe, delete all Instances out of OpsWorks before deleting the CloudFormation Stack.
5am - 10pm (non-inclusive) AZ time = 12 - 05 (non-inclusive) UTC 24 hour time
Rice Application node for weekdays only This type of instance will be a timed instance up Monday - Friday 5AM - 10PM
5am - 10pm (non-inclusive) AZ time = 12 - 05 (non-inclusive) UTC 24 hour time
Defines the Load Balancer for KFS. http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-elb.html UAFAWS-198 - To change subnets(in Jenkins) and Scheme (in ELB) to Private network; Two option available for ELB Scheme: "internet-facing" (public) vs "internal" (private)
Defines the Load Balancer for Rice. http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-elb.html UAFAWS-198 - To change subnets(in Jenkins) and Scheme (in ELB) to Private network; Two option available for ELB Scheme: "internet-facing" (public) vs "internal" (private)
CloudWatch Alarm For ELB and Instances
This is the IAM role that will be applied to the OpsWorks EC2 Instances. Any AWS specific permissions that the node might need should be defined here.
Access to the S3 Bucket which holds application specific files that need to be loaded on each application node. (ojdbc.jar, encrypted keystores, etc)
Access to CloudWatch for the log group and log stream from each application environment.
Access to the S3 Bucket which holds application specific files that need to be loaded on each application node. (ojdbc.jar, encrypted keystores, etc)
Allow the Rhubarb container on this host to update ELB Listeners
Create a CloudWatch Log Group for each application environment. This allows us to set the retention timeframe. UAFAWS-302 - Create dependency on CWlog Log group and EC2 instance with CWlogs agent. During CF template delete CW agent has access to recreate log group after first pass
This is just a little construct to connect a set of roles together into a profile. The profile is referenced in the OpsWorks stack itself.
Security group for the OpsWorks application instances themselves. Needs to permit incoming traffice from the ELB, and any other authorized incoming sources.
Maintenance Page port
Rice ports
Zabbix port
This is the Security Group that wraps the Load Balancer. This controls what network traffic is allowed into the ELB. Just web traffic is allowed from anywhere.
Create a DNS entry in Route53 for the KFS ELB. This creates a CNAME pointing at the DNS name of the KFS Load Balancer.
Create a DNS entry in Route53 for the Rice ELB. This creates a CNAME pointing at the DNS name of the Rice Load Balancer.
Output values that can be viewed from the AWS CloudFormation console.
KFS Environment CloudFormation Deployment
This CloudFormation template will build out a whole KFS environment, including an OpsWorks stack, Load Balancer, Application nodes and Database.