{"id":19964323,"url":"https://github.com/bu-ist/webrouter-nonprod","last_synced_at":"2025-05-03T23:30:28.776Z","repository":{"id":44595187,"uuid":"118637378","full_name":"bu-ist/webrouter-nonprod","owner":"bu-ist","description":"Webrouter for routing web services to backends","archived":false,"fork":false,"pushed_at":"2025-02-21T01:51:56.000Z","size":748,"stargazers_count":1,"open_issues_count":2,"forks_count":3,"subscribers_count":15,"default_branch":"syst","last_synced_at":"2025-04-07T22:51:13.486Z","etag":null,"topics":["aws","codepipeline"],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/bu-ist.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-01-23T16:30:11.000Z","updated_at":"2024-08-27T18:29:12.000Z","dependencies_parsed_at":"2023-09-23T10:08:42.607Z","dependency_job_id":"d11fd8fa-85f1-488f-a5e9-4783bb1c513f","html_url":"https://github.com/bu-ist/webrouter-nonprod","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bu-ist%2Fwebrouter-nonprod","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bu-ist%2Fwebrouter-nonprod/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bu-ist%2Fwebrouter-nonprod/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bu-ist%2Fwebrouter-nonprod/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/bu-ist","download_url":"https://codeload.github.com/bu-ist/webrouter-nonprod/tar.gz/refs/heads/syst","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":252269026,"owners_count":21721239,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aws","codepipeline"],"created_at":"2024-11-13T02:22:55.540Z","updated_at":"2025-05-03T23:30:28.373Z","avatar_url":"https://github.com/bu-ist.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Over view\n\nThis repo contains the landscape specific files for the BU web router.  In general updates to this repo are\nsafe to release to in a change restriction period.  That is because:\n\n- The version of the base image is date tagged to ensure that no software updates accidently sneak through.\n- The config files in this repo are limited to map files\n- The CodeBuild part of the release process will run nginx -t to ensure that there are no map errors prior\n  to release.\n- The CodePipeline will back out to the old running version if the updated version does not stabilize.\n\n# Operational Tasks\n\n## Changing a map entry\n\n1. Use `git pull` to ensure that we are operating with the latest version of the configuration.\n2. Use `git status` to double-check that you are on the correct landscape.  If not then do `git checkout landscape`\n3. Edit landscape/LANDSCAPE/maps/sites.map to reflect our map path.\n4. Use `git status` to double-check status of files.\n5. Use `git diff` to see what changed.\n6. Use `git add` to select files for inclusion.\n7. Use `git commit -m \"description\" ` to commit the change with the description of the change\n8. Use `git push` to push these changes out to the GitHub repo.  This will trigger the CodePipeline update.\n9. Watch the CodePipeline release through the web console or cli for any issues.\n\n## Updating to a newer base image\n\nDuring initial builds and configuration we are using the tag latest.\n\n1. Use `git pull` to ensure that we are operating with the latest version of the configuration.\n2. Use `git status` to double-check status of files.\n3. Edit Dockerfile and change the tag as part of the `FROM dsmk/web-router-base:date`\n4. Use `git status` to double-check status of files.\n5. Use `git diff` to see what changed.\n6. Use `git add` to select files for inclusion.\n7. Use `git commit -m \"description\" ` to commit the change with the description of the change\n8. Use `git push` to push these changes out to the GitHub repo.  This will trigger the CodePipeline update.\n9. Watch the CodePipeline release through the web console or cli for any issues.\n\n## Adding a new landscape\n\n1. Clone a new directory with the landscape name `git clone git@github.com:dsmk/web-router-nonprod.git test`\n2. Cd into the directory and create and checkout the new branch: `cd test; git checkout -b test`\n3. Create the landscape specific subdirectory: `mkdir -p landscape/test/maps`\n4. Copy initial files from a previous landscape except for the sites.map which comes from landscape/common/sites-common.map\n5. Edit files as appropriate.\n6. For sites.map, use PHPMAP and the filesystem scan to find things.\n\n\nThis repo has all the data for the BU AWS web front-end proof of concept.  The architecture sets up a fairly \nstandard AWS Elastic Container Service (ECS) environment with CloudFront in front of it.  The CloudFormation \ntemplates are in the aws/ subdirectory but eventually should be in a separate location.\n\nThis is still a work in progress and we still need to address the following issues:\n\n- Patching model for ECS EC2 instances: ECS does not seem to handle this by default.  Is the correct approach\n  to use EC2 Systems Manager?\n\n- Method of updating route configuration: This version bakes the routing into the Docker image and relies upon\n  building a new Docker image when we change the configuration.  The CodePipeline makes that more straightforward\n  but a nice to have would be a simple interface to adjust the change as long as it does not add much complexity \n  to the solution.  \n\n- Release mechanism for multiple landscapes: This POC code only handles one landscape (test).  I have seen a\n  different approaches to multiple landscapes:  1) Have a single CodePipeline for multiple landscapes with a \n  manual approval step prior to production; 2) Have multiple CodePipelines like the POC based on different \n  repos and/or tags.  \n\n- Approach for handling redirection of both entire subdirectories and singleton URLs: Redirection ideally \n  should be managed by Help Center folks.  I have seen a few references to lambda/API gateway and S3 bucket \n  based approaches.  If we use those solutions then hopefully the routing table could just have a \"redirect\" \n  backend that points to the solution.\n\n- Internal load balancers for backends: Our existing front-ends handle load balancing for the WordPress and \n  Django backends (mod_proxy_balancer Apache 2.2).  One refinement would be to have internal application load\n  balancers so all load balancing is handled (and monitored/tracked) by AWS load balancing services.  In \n  addition, the WordPress ALB could potentially handle selecting between Application and Asset servers which \n  would simplify this NGINX/HTTPD configuration even more. \n\nThe general workflow while we are building the system is to:\n\n1) Update the test/sut/test_app.sh script to test the new functionality with the current Solaris.  This involves \n   running the script like so `./test/sut/test_app.sh -S test www-test.bu.edu`  - the -S disables the check for \n   upstream headers (only configured in NGINX for now).\n\n2) Once that is done then one needs to update the NGINX configuration to implement the same functionality as \n   Solaris.  This mainly will involve the \\*.conf.erb files in the main directory but make involve new environment\n   entries.  One can test this on a local build box by running `docker-compose -f www-test.bu.edu.yaml up --build` \n   and then `./test/sut/test_app.sh test`  This is testing with the normal www-test backends.\n\n3) Next the automatic testing needs to be configured.  This involves two sets of changes - `autotest-test.yml` \n   docker-compose file and updates to the `test/backend` Docker image.  The docker-compose file will create a\n   container to run the tests, an NGINX frontend container, and a test backend container which emulates test\n   responses.  The goal of this test framework is to test and minimize regressions in the frontend containers.  It\n   is not intended to be a test of whole services.\n\n4) One can pretest the automatic testing by doing `docker-compose -f autotest-test.yaml up --build ` - if \n   everything is OK then the last line will end \"exited with code 0.\"  Control-C to exit from the test and \n   it will stop all the containers set up.  The test output is stored in the `test/results/` directory and you \n   can see the specific test that failed by searching for `exit code: 1` \n\n5) When you are ready to release changes you need to check the changes into Git and push them to GitHub.  Here \n   are some common commands:\n        a) `git status` - see which files have been modified, which are new, what is selected for commiting, and \n           the branch.\n        b) `git diff [file]` - see what has changed from the last commit.\n        c) `git add file` - add a file to the list of things to check in.\n        d) `git commit -m 'msg'` - commit added files with the message msg (include INC* and ENC* where appropriate)\n        e) `git push` - push the changes to github\n\n6) Right now one needs to go to hub.docker.com/r/dsmk/bufe-buedu, select \"Build Settings\", and select the Trigger\n   to start the build.  This will be replaced later.  You can see the status of the build by going to \"Build Details\"\n\n7) Once the new image is done you can replace the existing container by going to the ECS web console, selecting\n   the task we want to modify (bufe-bu.edu-bufe:num), select \"Create new revision\", and then selecting \"Create\".  \n   This will take a while to run because ECS will create a new container, add it to the ELB/ALB, and wait for the \n   old one to drain completely before being done.  This will be replaced later.\n\nURLs for this process:\n- https://sanderknape.com/2016/06/getting-ssl-labs-rating-nginx/\n- https://sanderknape.com/2017/08/custom-cloudformation-resource-example-codedeploy/?__s=1qw3d4dssvntsxck5tuk\n- https://aws.amazon.com/blogs/compute/managing-secrets-for-amazon-ecs-applications-using-parameter-store-and-iam-roles-for-tasks/\n\n- http://blog.xebia.com/docker-container-secrets-aws-ecs/\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbu-ist%2Fwebrouter-nonprod","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbu-ist%2Fwebrouter-nonprod","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbu-ist%2Fwebrouter-nonprod/lists"}