-
Notifications
You must be signed in to change notification settings - Fork 11
Home
- treetracker.org - 188.166.33.48 (Digital Ocean droplet)
- dev.treetracker.org - 178.62.253.53 (Digital Ocean droplet)
- treetracker-api-dev - 45.55.4.155 (Digital Ocean droplets)
- Shared hosting 69.163.172.21 (donated by DreamHost.com) Currently Greenstand.org
- Shared hosting 156.67.236.37 (donated by EcoSystems East Africa Ltd, www.esea.co.tz.) Future Greenstand.org
- Registered on GoDaddy
- DNS on DO (ns1-3.digitalocean.com)
- mx is gsuite - Can manage DNS directly by hand on DO’s network tab
Suggestion - use tools such as Terraform or bash script calling doctl to be declarative and check into GitHub (IAC pattern, Infrastructure as Code)?
- Registered on GoDaddy
- DNS GoDaddy
Suggestion - put DNS somewhere else (cloudflare would be cool, exploring other options would also be worthwhile).*
Two Paid G Suite mx accounts, plus one free G-Suit account.
Suggestion - put all domains on a single g suite account*
Review domains ability to send mail, if this will be a necessary pursuit it’s good to have SPF, transactional mail, dkim, etc in place.
Laravel/PHP being rewritten to use a different backend.
Database type the app will use and where they want to place that.
Min viable - all services on one virtual server, using Apache vhosts for dev, www/naked domain (prod), database (mysql, etc). Cons - single point of failure, server is a pet and not cattle. Maintenance is a tricky, manual process.
MVP++: multi-tier architecture Database layer - consider DBaaS ( mLab, firebase, databaselabs.io, heroku), or continue to use DO and create DB cluster with droplets. If the database is to be fault tolerant or highly available, multiple virtual servers are required and it’s best to replicate to another DC. Hypervisors can go offline for ‘maintenance’ at DO’s discretion. Object storage - images, static assets App layer - Node.js application deployed to virtual server(s), communicating to DB layer, object storage, and front end web service or LB. redundancy provided by multiple app servers in a load balanced pool Web service, reverse proxy and load balancer - DO’s LB product ($20 per month) works by creating two droplets running an HAProxy-like LB service, one acting as a primary LB and the other droplet available as a standby. There’s a floating IP issued to the pair - the primary is assigned the floating IP but the IP is assigned to the secondary in the event the primary is unavailable. A single HAProxy LB is not fault tolerant and can result in application outage if redundant LBs are not available to fail over to. Use of a CDN such as CloudFlare is also recommended to perform edge caching and CF provides similar load balancing services.
Optimization can be done at various layers - for example, the app layer can be containerized with use of Docker, the underlying virtual server infra can be provisioned with devops tooling, etc.