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

[varshith257]

👍

…

On Sun, 24 Mar, 2024, 9:36 am Vasu Jain, ***@***.***> wrote: @varshith257 <https://github.com/varshith257> Okay, I will take docker files from your pr and paste it in my fork to test the ci cd pipeline — Reply to this email directly, view it on GitHub <#1428 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4BF3HCL7T6Y6QMMPR6ZPY3YZZGK7AVCNFSM6AAAAAA7O5GJSWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGY4DKOBRHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[vasujain275]

@varshith257 Okay, I will take docker files from your pr and paste it in my fork to test the ci cd pipeline

Sorry for no progress last week on this issue, I was not well. Resuming the work again

[varshith257]

@vasujain275 Are you fine now?

[vasujain275]

@vasujain275 Are you fine now?

Better now, thanks for asking

[varshith257]

Any progress on this?

[vasujain275]

Any progress on this?

Yeah, I am researching a solution that will be effective than current one. Currently, we are using npm run dev on the demo api server containers. Does the build process issue you were working on is fixed? If it is resolved, we can then serve pre built html css js files directly.

[varshith257]

Yes the build issue is fixed

[vasujain275]

Yes the build issue is fixed

Great, is it merged?

[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.

[vasujain275]

PR for #1751 by @varshith257 merged yesterday only, will work on this from today

[palisadoes]

I haven’t been paying much attention to this, however I noticed that Talawa-API Docker instances do not import sample data. The CLI commands in the INSTALLATION.md file execute without error but don’t populate the Docker Mongo instance database. The setup script doesn’t prompt to load data either.

This is covered in this issue:

• Setup script doesn't handle Docker intuitively #2270

My understanding was that the GoDaddy API deployment was via Docker, and that there would be a job running to periodically overwrite the database with sample data to reduce the risk of abuse.

The discovery of this issue means that the instance is not functional in that the data will always be blank.

I’ve also noticed that the cloud deployments have been failing too. Why is that?

We should have this working and eventually well documented in INSTALLATION.md in summary form and docs.talawa.io in more detail.

Please give a status update on this. It’s not clear to me.

[vasujain275]

@palisadoes Sorry for late reply, I am currently busy at school due to end sem exams till 30 May. I can continue the work after that If anybody do not solve this issue till them. Sorry for the inconvenience

[palisadoes]

@vasujain275

1. Thanks. This can wait.
2. We have an issue created to fix the Docker data importation which should help when you return.

[vasujain275]

Thanks for understanding

[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.

[vasujain275]

@varshith257 Did you fix the build issues as I am not able to get the server up and running in production mode, here is the list of commands I run -

npm install
npm setup
npm run prebuild
npm run build
npm run start

Please take a look into it

PS: I am successfully able to run the server in dev mode using - npm run dev

[palisadoes]

@noman2002 @Cioppolo14 This is a cloud instance issue to follow.

[vasujain275]

I have reviewed the Issue that was raised to fix the build errors - #1916 but saw that was not able to successfully fix all errors in the build process due to stability issues.

@palisadoes shall we continue with dev images only as we are doing currently? They will 3x the size of production docker images (600MB -> 1.8GB) but this is the only viable option imo right now

[varshith257]

Why 1.8GB image size is required? The multi-stage build has been done to reduce image size, it is now ~500MB of dev and prod (~200MB).

[varshith257]

@varshith257 Did you fix the build issues as I am not able to get the server up and running in production mode, here is the list of commands I run -

It won't because we are still pointing it to a stale file. There needs a refactoring of the codebase to support the production environment. I have closed the issue by fixing some of them, But it needs to be fixed with tsconfig and fixing of the errors emitted. The compiler from ts-> js is accompanied by incompatibility and it breaks down due to some libraries being built of ECMA.

[palisadoes]

1. We just need an instance up and running on the GoDaddy server.
2. It must work whenever we update the main / or develop branch. (I'm not sure which yet in my mind)
3. We are paying for a docker hub account that we are not using. I'd prefer to shut it down until we are ready. Can I do that?

[varshith257]

@vasujain275 You can go with testing it with dev image. As we are developing this for developers dev image could be right one to go with IMO

[vasujain275]

@palisadoes

1. Okay, I will go with dev images only as the build process is not ready yet.
2. Yes CI/CD pipeline will ensure to update the instance on every new commit.
3. Why are we paying for a Docker Hub account?? I specifically mentioned that we don't need a docker hub paid account, please downgrade that account to a free account.

[palisadoes]

1. We had to use a paid account as we needed to register as an organization.
2. Individuals can get free accounts, but we don't want to be tied to someone who could walk away from the project.

Do we need a docker account at this stage?

[vasujain275]

@palisadoes If we need a paid account for docker hub then I can implement the pipeline without docker hub. Docker hub would make this a little easier but we can implement the pipeline without it too.

[palisadoes]

OK. I'll shutdown the docker account over the weekend.