<commit_before># homework
A ruby hello_app build/deployment configuration exercise.

Uses docker/docker composer directly if you want or vagrant + ubuntu + puppet if you want to keep the changes away from your desktop.

Hello_app is a ruby application deployed to a docker container with phusion passendger, nginx and postgres. During the container startup, the DB is provisioned and the application is downloaded from Git. With this strategy, it is possible to have a fresh version of the application by just starting a new version of the container, which makes the environment ready for development and testing. 

From a security perspective, the puppet scripts are sanitizing the VM in the similar way we would sanitize a production environment, making the development/testing machines closer to a production one. 

Openshift was used for the sake of testing routing and usage outside of a developer's realm.

## Instructions
 - local machine via docker-compose (https://docs.docker.com/compose/install/)
 	- docker-compose up

 - local machine via vagrant (which will run puppet + docker)
 	- vagrant up

 - PaaS deployment using Openshift (You don't need permission to run privileged containers)
 	- oc new-project homework-dev
 	- oc new-app https://github.com/slaterx/homework --name=hello-app --strategy=docker -e TZ=Pacific/Auckland
 	- oc expose service hello-app --hostname=hello-app.example.com

## Improvements
* **DB**: The docker composer is ready to host another container with postgres and bootstrap the DB, but the application is using so far a local one. We need to move the migration step from Dockerfile to the my_init.d, so there will be proper networking in place for the external connection to happen.

* **Load Balancing**: This exercise has no in-house load balancing capability. On one hand, it would be better to have it available for earlier testing, although this would also add more complexity to the overall solution. On the other hand, when getting closer to production, it's very likely the load balancing role would be played by a component outside of this solution, either because it would be in a shared tenancy, or because its management may belong to another department for which we couldn't have control.<commit_msg>Added AWS ECS support via eb<commit_after># homework
A ruby hello_app build/deployment configuration exercise.

Uses docker/docker composer directly if you want or vagrant + ubuntu + puppet if you want to keep the changes away from your desktop. Just clone it to your computer and select one of the deployment options.

Hello_app is a ruby application deployed to a docker container with phusion passendger, nginx and postgres. During the container startup, the DB is provisioned and the application is downloaded from Git. With this strategy, it is possible to have a fresh version of the application by just starting a new version of the container, which makes the environment ready for development and testing. 

From a security perspective, the puppet scripts are sanitizing the VM in the similar way we would sanitize a production environment, making the development/testing machines closer to a production one. 

Openshift was used for the sake of testing routing and usage outside of a developer's realm.

## Instructions
 - Local machine via docker-compose (Linux) (https://docs.docker.com/compose/install/)
 	- docker-compose up

 - Local machine via vagrant (OSX, Windows) (which will run puppet + docker)
 	- vagrant up

 - PaaS deployment of a dual node using Openshift (You don't need permission to run privileged containers)
 	- oc new-project homework-staging
 	- oc new-app https://github.com/slaterx/homework --name=hello-app --strategy=docker -e TZ=Pacific/Auckland
 	- oc expose service hello-app --hostname=hello-app-stag.example.com
 	- (If you want high availability on the app) oc scale dc hello-app --replicas=2

 - PaaS deployment of a dual node using AWS Elastic Beanstalk
 	- eb init hello-app
 	- eb create hello-app-staging --scale 2

## Problems found (and how they were mitigated)
 - **Lack of flexibility on the database configuration**: The application uses hardcoded database names. The easiest way to overcome this was to open config/databases.rb to get the DB names and add them inside the deployment strategy. The best way to address this would be to change the source to accept variables and pass then as part of our deployment, in the same way we are passing the username and password.

## Improvements
* **DB**: The docker composer is ready to host another container with postgres and bootstrap the DB, but the application is using so far a local one. We need to move the migration step from Dockerfile to the my_init.d, so there will be proper networking in place for the external connection to happen.

* **Load Balancing**: This exercise has no in-house load balancing capability. On one hand, it would be better to have it available for earlier testing, although this would also add more complexity to the overall solution. On the other hand, when getting closer to production, it's very likely the load balancing role would be played by a component outside of this solution, either because it would be in a shared tenancy, or because its management may belong to another department for which we couldn't have control.
{'fraction_non_alphanumeric': 0.047762316660398645, 'fraction_numerical': 0.000376081233546446, 'mean_word_length': 4.313686313686314, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4751063', 'n_tokens_mistral': 1337, 'n_tokens_neox': 1232, 'n_words': 777}