Cloud Based API Instance for Developers

[palisadoes]

We need to have a cloud based API instance for developers to test against. It must:

1. Be integrated into our CI/CD pipeline so that the app is rebuilt with every newly merged PR.
2. Initialize the database to a known working state with appropriate services will be restarted when this happens: (there are existing API calls for this):
   1. with each CI/CD update
   2. every 24 hours
3. Use a talawa.io sub-domain as the endpoint
4. The API instance will have a rate limiting mechanism to reduce the risk of abuse
5. Preferably use a free service
6. Use a palisadoes role based account for management
7. The demo cloud API must be easily switched between branches as the code source. We will be migrating to master as the default branch soon.

Please coordinate these efforts with @noman2002 and @kb-0311. Ask to be assigned this task by them.

[kirtanchandak]

@noman2002 @kb-0311 I can give this issue a try

[kirtanchandak]

there is file named push-documentation.yml in github/workflows folder. Do we need to make changes here or create a new file?

[palisadoes]

1. We used to have this working with Heroku using this file. https://github.com/PalisadoesFoundation/talawa-api/blob/develop/.github/workflows/ci.yml.archive
2. There was some setup that was required with the Heroku cloud to make it work correctly whenever we did a merge. We decided to stop using Heroku due to the cost of having the instance running. We would like to use a fremium service.

[noman2002]

@kirtanchandak Please proceed with this. You can use that file, you just need to do some minor changes. But I would suggest please check other solutions like render.com instead of Heroku.

[vasujain275]

Hi @noman2002 @kirtanchandak, I have been working on this same issue containerization talawa-api using docker here - #1418 that was merged yesterday and was working on developing a ci/cd pipeline for this exact use case, @kirtanchandak can I work on this issue if you haven't made any significant progress yet?

[palisadoes]

One issue per person

[vasujain275]

One issue per person

Okay

[github-actions]

This issue did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please check if the develop branch has fixed it and report again or close the issue.

[palisadoes]

@kirtanchandak Are you still working on this?

[vasujain275]

@palisadoes I can work on this if @kirtanchandak is not working on this

[palisadoes]

Assigning to@vasujain275. Please work with @noman2002 and @kb-0311 for comments, advice and reviewing the PR

[vasujain275]

Hi @noman2002 and @kb-0311, I did some research and found that the MongoDB Atlas free tier is good enough for our use case. I looked into redis free tier at render.com, it has 25 MB of memory with a 50 connection limit and no persistence storage. We can also host our API on render.com but it will be shut down after an inactivity of 5 minutes and will be restarted when called again. Will that render.com's inactivity delay or redis free tier will be a problem?

[kb-0311]

@vasujain275

1. Instead of render are there other free tier cloud instances that we can use to deploy our application?
2. Well in production the Redis server was to be used as an in-memory cache, not a global cache so we also need to have the option to access the file system/ services of the server where the API is deployed.
3. Render and stuff is fine but if possible can you also explore free credit use of GCP and/or Azure? Do let me know if those are feasible.

[vasujain275]

@kb-0311 We can use the AWS free tier, which will have a t2.micro ec2 instance free for 12 months per account ( we will need a credit card to avail this 12-month free tier ). We can use the docker file and docker-compose file I created in a recent issue, we can set a ci/cd pipeline to push our image to the docker hub on each push and then pull to e2c using GitHub actions. We can then run docker-compose on e2c also using GitHub ci/cd that can run containers of both redis and MongoDB, although I think it will be best to run MongoDB on Atlas as it has a good free tier and will reduce the load on our t2.micro ec2 instance if we run it on atlas. We can also use azure/gcp, they also have this exact free tier of 12 months that requires a credit card on signup.

[palisadoes]

@vasujain275 Ideally we also want:

1. A single account to manage all the required resources.
2. The ability to have trusted contributors update the cloud service parameters to make sure the CI/CD functions
3. Ensure that only one person has the right to purchase new services or upgrade any existing ones. This will help reduce long term costs and potential abuse.

Other:

1. @kb-0311 @noman2002 Do you have anything else to add?
2. Is the most recent comment from @vasujain275 in keeping with the desired outcome?

[vasujain275]

@palisadoes

1. Only a single aws account is required to manage this cloud instance.
2. We only need to add the cloud service parameters as github secrets of this talawa-api repo. Then the secrets can be safely and easily used in our github actions using environment variables.
3. Addition of github secrets can be done by any trusted contributors.
4. Only the person who will sign up for aws instance will have the right to purchase new services or upgrade any existing ones.
5. No one will need to directly ssh into the instance to make changes, as they will be done via ci/cd pipeline.
6. As for MongoDB Atlas, we will only need to add the MongoDB Atlas Cluster url as github secret of this repo.

Q. How can github actions do all the changes in our aws instance?
Ans. Docker Containers, we will never install the talwa api directly to our aws instance instead we will use docker container of our api that can be rebuilt and restarted every time we push changes to our repo.

My proposed solution -

1. Firstly, I will create all github actions files and docker compose files required to completely set up talawa-api instance on aws via ci/cd.
2. I will then test all the github actions and compose files on my personal aws ec2 instance to make sure all the things are working as intended. This way I will not be required to have direct access to talawa-api actual production ec2 instance.
3. When all the github actions are completed and tested by me then one of the trusted contributors can signup for aws instance and MongoDB Atlas. Then he will set up the required env variables as github secrets in this repo.

@noman2002 @kb-0311 , appreciate your feedback on possible improvements in this approach

[palisadoes]

1. Based on your answer we will need to manage two cloud accounts. Can this be done using only one account?
2. We need to make sure that more than one person can access the AWS dashboard for purposes of troubleshooting. Can this be done without them having access to the credit card information to add new services?
3. If we use a MongoDB Atlas account, how can we guarantee the same AWS access requirement above?

[kb-0311]

@vasujain275

1. Yes your solution and flow make sense to me.
2. At this stage it would be easier to showcase the CI/CD pipeline using your forked talawa-api instance as the base for now and your free tier AWS ec2 instance as the deployment server.
3. Create a new branch and configure the docker-compose file as necessary, since you are the owner of the forked repo you can also add the GitHub secrets for Altas and aws.
4. Then make demo PR merges to that branch and demonstrate how to CI/CD pipeline will work using a video.
5. This will help us understand potential problems that could occur at a given point more precisely.

@palisadoes

1. Can you elaborate on the two accounts? Are you referring to one account for aws and another for MongoDB Atlas or something else?
2. In aws and MongoDB I think there are certain ABAC and RBAC features for this purpose. Maybe we can take a look at that? @vasujain275

[vasujain275]

@palisadoes

1. By two accounts, If you referring to one account for aws and another for MongoDB Atlas then in my opinion it's better to have them separated as it will decrease the load on our ec2 machine.
2. As @kb-0311 suggests there is role-based access in both aws and MongoDB Atlas that we can use to give limited access to another person for troubleshooting purposes.

@kb-0311
I will start working on this by creating a new branch "deployment" in my forked repo and will follow the process you mentioned in the previous comment.

[palisadoes]

1. Yes one in AWS and the other with Mongo
2. Remember this will be solely for demo purposes not a heavily used system with only a few transactions per hour for developers to test against. Keep this in mind with your final recommendation.

[vasujain275]

@palisadoes Okay I will keep that in mind

[vasujain275]

@palisadoes

We don't need two different environments for talawa api, the production one will be sufficient to handle both requests from talawa admin/app and developers.

Do we also need Apollo Graphql Playground Hosted on the VPS? Because it will be resource intensive as it requires self hosting a standalone apollo server. Currently the prod build disables the Apollo playground i.e. /graphql endpoint.

[adithyanotfound]

@palisadoes

The production environment should be enough. Although having a development instance would be nice since we can then implement CD pipelines which would make deployment more easier. But due to limited resources, the best course of action would be to just have the prod instance. The current PR workflow should be sufficient to handle most cases. Occasionally, any errors can be addressed when the main branch is merged with the develop branch, if necessary.

[palisadoes]

1. Lets get rid of the development environment all together. I'll create an issue for it.
2. The resource intensity is too great in dev.

[vasujain275]

@palisadoes There is no need to remove dev docker files, developers can use that on their local machines for local development. We will use production docker files in cloud instance anyway.

[palisadoes]

Thanks

[palisadoes]

Here is the issue

• Remove the Development environment from the code base #2800

[vasujain275]

@palisadoes

I will in the meantime update the cloud instance scripts, production docker files and test them on vasu user on the vps.

[palisadoes]

This will be an interesting issue. Get ready for the migration!

• MinIO Async Deletion Service - develop-postgres branch #2808

[vasujain275]

@palisadoes

Should I wait for this postgres migration to complete first? Or are we planning to go with mongodb for now?

[palisadoes]

1. We'll run everything on the server using develop.
2. Just before the migration starts I'll merge develop-postgres into develop

[vasujain275]

@palisadoes

Okay, I will wait for the merge then modify the docker files and scripts for postgres only.

[palisadoes]

@vasujain275

1. We need this functioning. Only on develop.
2. I've just merged the latest Admin develop-postgres into develop
   1. Merge the latest develop-postgres to develop for Cloud instance talawa-admin#3183
3. Please try to get this running by the weekend.

[vasujain275]

@palisadoes

I am free this weekend, will try to get this running by this monday

[palisadoes]

@vasujain275

1. We only need the cloud instance for the develop branch at this time for both the API and Admin.
2. We are a long way away from having a working develop-postgres branch.

[palisadoes]

@vasujain275

1. Were you able to make any progress?
2. Our deadline is to get this running before February 11 when our GSoC organization application is submitted.
3. Can you meet that deadline? We need to redouble our efforts.

[palisadoes]

1. I need a volunteer to take this issue over as @vasujain275 doesn't seem to be available.
   • Cloud Based API Instance for Developers #1428
2. The API needs to run under the talawa-api user and Admin needs to run under the talawa-admin user
3. The host is api-demo.talawa.io which is the same OS instance as admin-demo.talawa.io
4. Whoever is interested in working on this, contact me on slack to post their public SSH key so they can login to the server. They will also get sudo access.
5. This absolutely needs to be resolved this weekend. We are highlighting the demo as part of our GSoC 2025 application, as justifiable validation of our progress.

[vasujain275]

@palisadoes Sorry for the inactivity and delayed response, due to personal reasons I am not able to give time to this issue and will not able to meet the GSOC deadline.

[palisadoes]

@vasujain275

I hope you persevere to overcome the recent challenges. Please stay in touch.

[hkumar1729]

@palisadoes @noman2002 @kb-0311 I would like to continue working on this issue. Please assign me and provide any necessary details to proceed. Thanks!

[PurnenduMIshra129th]

@palisadoes i want to work on this issue. please assign i will solve it.

[PurnenduMIshra129th]

@noman2002 @kb-0311 please assign i will try to solve it.

[palisadoes]

This is being worked on

[palisadoes]

I'm going to close this. It's mostly solved.