avniproject / avni-infra Goto Github PK

We have 2 classic load balancers and 4 application load balancers.
A single application load balancer should be sufficient for our needs - we can route based on the request URL.

0. We might need a separate AWS account that runs production. This means eventually we will be running atleast 3 different AWS accounts - 5d
1. Come up with list of target entities - 1d
2. Come up wit privileges for those target entities - 1d
3. Come up with env based grouping of target entities and privileges - 1d
4. Come up with Base set of roles (Target entity + Privilege + environment => Role), includes - 2d
   -- AWS console access -
   -- SSH access to servers
   -- AWS service access (Ec2, RDS, Cognito, S3, etc)
5. UserGroups will be assigned one or more Roles - 1d
6. Users will be a part one or more userGroups - 0d
7. We’ll then do staggered switch from old way of access to the new approach - 0d
8. Deprecate the old SSH keys and AWS credentials which grant role/user-group agnostic access - 2d

Total: 8d * 2(Ramp-up, Misc tasks, bugs/issues) = 20d => 4 weeks - High Level estimate

service openchs restart doesn't work

Avni load-balancing, networking and system update considerations

• Growing number of application modules which we have in Avni (avni-server, rules-server, avni-webapp, avni-media-server, avni-media-client, etl, avni-integration-service and avni-int-admin-app, keycloak, Minio)
• The need for these modules to easily interact with each other over network
• The need to ease of deployment and maintenance of these app modules
• Optimize resource utilization
• Load-balancing needs that might arise in future
• Reporting software upgrades
• SSL certificates upgrades and using a single chained one

Proposed solution:

In-order to handle the above considerations, we should seriously consider using Docker Containers and Kubernetes clusters along with some auth layer rework of Avni

Create docker container config for avni apps - 20d

• avni-server - 2d
• webapp - 2d
• rules-server - 2d
• integration-service - 1d
• integration-admin-app -1d
• etl - 2d
• avni-media-server - 1d
• avni-media-client - 1d
• keycloak - 1d
• Minio - 1d
• JasperServer - 2d
• Metabase - 2d
• Superset - 2d

Create Kubernetes config for Avni - 22d

• Create docker hub - 0
• Load-balancers - 3d
• network config for inter app communication - 5d
• Reverse-proxy - 2d
• services - 3d
• deployments - 5d
• HorizontalPodAutoscaler for few apps - 2d
• SSL cert in-front of ReverseProxy - 2d

Handle logging, uptime and debugging aspects - 5d

Handle build and deploy of applications using CirceCI(or other CI tools) - 10d

Setup staging env using kubernetes - 2d

Setup Prod env using kubernetes - 2d

Switch Prod DB from avni-server standalone to kubernetes avni-server. - 2d

Total - 63days

Upgrade Avni Prod master Database instance type to t3.medium.
Also choose Reserved-instance with 1 yea tenure.

We are still paying on-demand prices for AWS resources though we have always-on systems.

Reserved instances give 20-30% savings. There are options to make zero upfront payment for 1 year which are convertible to other resource classes and can give us quick easy savings. Resources across the same resource class type can share any reservations we setup i.e. if we setup a t3.medium RI, it will get applied to any t3 resource we have.. it doesn't necessarily tie to a t3.medium resource.

Context:
When we were using gp2 disks for the database, the only cost effective way to get additional IOPS was to bump up the disk size as a result of which we have 300GB database but our usage is less than 10GB. Now that we have moved to gp3, IOPS is not tied to disk size and we can lower the database size.

The DB backups also contribute to the cost impact of this storage size.

RDS does not offer an easy way (from the console) to do this and this will require a custom solution. Refer for methods