MVP-1 Stack Administration Documentation

[christian-westbrook]

User Statement

As a System Administrator, I would like access to a clearly defined process for administering a web service stack so that I can efficiently and repeatably provide administration services in support of the portfolio web system.

Engineering Response

We will develop and document a clearly defined process for administering a web service stack in support of the portfolio web system. The process provided will necessarily be tied to our chosen deployment solution, but this will at least serve as a starting point from which we can add support for more deployment solutions and environments in the future. Documentation will be made available in the repository wiki and in README.md. Any scripting will be made available in the repository.

Technical Breakout

We should start by selecting a deployment solution for ourselves and then document the chosen solution. Our documentation should make it clear that this is only one potential solution for deployment among many, and we can potentially look to expand this documentation in the future to include other deployment solutions.

Considerations for a deployment solution:

• Must be low-cost
• Must support PHP web applications

Acceptance Criteria

• Process for administering a web service stack is clearly defined and documented
• Process for administering a web service stack is demonstrably repeatable

[christian-westbrook]

Attempted to deploy locally to a Raspberry Pi, but was blocked by ISP port restrictions. Rather than attempt to circumvent the port restrictions, I'm looking for a third party to host my site.

[christian-westbrook]

Attempted to deploy to an Amazon Linux 2 EC2 instance using AWS and succeeded. This is an option, but continuing to look for better solutions to avoid incurring any accidental costs.

[christian-westbrook]

Ended up deploying the web system locally to a Raspberry Pi device, which I configured to serve web content over HTTPS using an Apache HTTP Server and an SSL certificate from CloudFlare. Serving content over HTTPS only fixed my issue with the blocked HTTP port. The complete stack looks like the following:

• Domain name registered with Google Domains
• DNS managed by CloudFlare
• CloudFlare routes traffic to my public IP, hiding its value behind a proxy
• Router forwards HTTPS traffic at my public IP to the Raspberry Pi
• Apache HTTP Server services requests onboard the Raspberry Pi
• Portfolio Web System serves as the content being served, also deployed to the Raspberry Pi

[christian-westbrook]

Although at this time the stack itself is relatively understood, the complete process of configuring the given stack for a system deployment is not entirely understood or documented. The best course of action for properly documenting this process would be to re-create the process in a fresh environment, which in our case would require another Raspberry Pi device for practicing a stack generation from scratch.

Due to this, my recommendation is to keep this issue and its requirements intact, but to move it out of the first Iteration. In its stead, introduce a new issue only requiring that knowledge of the components making up the stack be documented. In the future, when we gain access to another Raspberry Pi device or when we are forced to perform these steps again, we will re-introduce this issue and fulfill its request for complete documentation.