Setup staging

[valiafetisov]

Goal

Working staging environment re-deployed on merge to main

Context

Since there is something sensible to display now (after merging #29) we would want to deploy this project. Note, that currently it will have 3 services: api, frontend and the database. Have a look at the docker-compose.yaml file as well as nginx.conf for inspiration. Although currently the database is set to be sqlite, in production it will always be postgresql. Note, in this project we're currently using prisma (but that might change in the future).

One additional complexity here is that this repo is not owned by our github organisation. We anyway have access to github actions which are already enabled and utilised.

Tasks

• Please ask questions if there any left related to the service structure, ingress rules
• Please check that dockerfiles are correct
• Setup secrets
  • Make sure that JWT_SECRET contains a long password-like string
• Add CD scripts
• Make sure everything works
  • Frontend page displayed here available under /
  • Playground page displayed here available under /api
  • Playground have access to graphql endpoint and can successfully query it
    • i.e. query { coreUnits { id } } should return no errors

[DeusAvalon]

I assume the staging environment will be deployed in our cluster?
If yes i need to be able to setup secrets in github to access our chamber otherwise im not able to parse the dedicated AWS credentials safely to the runner.

Not sure if you have the needed access to set up secrets either @valiafetisov

[valiafetisov]

I assume the staging environment will be deployed in our cluster?

I assume so too 🙂

to access our chamber

Please make sure that those keys doesn't have access to the complete chamber, but rather only to secrets needed by this concrete project.

Not sure if you have the needed access to set up secrets either @valiafetisov

No, I don't. I suppose only @wkampmann have. Or does @BracketJohn also have more rights than I do?

In any case, @DeusAvalon, I would ask you to a) specify what exact rights do you need for this repo (if you think they can be safely given to you) or b) to write a concrete step-by-step instruction on what exactly need to be set where. If b) is required, maybe we can first setup CD on a fork of this repo to our org?

[DeusAvalon]

I assume so too

:D

Please make sure that those keys doesn't have access to the complete chamber, but rather only to secrets needed by this concrete project.

Yes ofc i would create a dedicated IAM role with only access to the specific SSM path for chamber :)

In any case, @DeusAvalon, I would ask you to a) specify what exact rights do you need for this repo (if you think they can be safely given to you) or b) to write a concrete step-by-step instruction on what exactly need to be set where. If b) is required, maybe we can first setup CD on a fork of this repo to our org?

According to the official docs i would need to become an admin of the repository to create encrypted secrets.

And a repo fork into our own org would definitly be a simple solution to deploy the application without juggling permissions!

[BracketJohn]

No, I don't. I suppose only @wkampmann have. Or does @BracketJohn also have more rights than I do?

sadly do not -> Wouter will need to create any github-side credentials. Can we find a workaround in the meantime + make sure that we ping him with a constructive & clear task-list once we have that?

If b) is required, maybe we can first setup CD on a fork of this repo to our org?
And a repo fork into our own org would definitly be a simple solution to deploy the application without juggling permissions!

I agree with this proposition + think it even makes sense that we go this route through, so that in the end we have a very clear picture of what Wouter will need to do, to keep his required involvement to a minimum.

[valiafetisov]

Ok, so let's start working on the fork and see if Wouter will grant @DeusAvalon admin rights in the meantime or if we need to ask them to set secrets themselves

[DeusAvalon]

@valiafetisov can you prepare the fork and ping me when everything looks good? :) From this point on i will take over and add the deployment

[valiafetisov]

Here is the fork. It's ready to be deployed unless you have some specific requirements

[DeusAvalon]

For Kubernetes to know if the pods are in a healthy state a healthcheck endpoint is required.
Usually the standard endpoint we are using is /api/healthz but any other endpoint would be fine too for me.
(see t4f-gxmanager or hos projects for inspiration)

Please add one ASAP, in the meanwhile i will disable the healthcheck to allow kubernetes to start the containers.

[valiafetisov]

The staging pipeline was implemented using Argo CD in a central (private) repo, therefore it's hasn't been automatically closed. The staging is currently available at https://powerhouse.switchboard.k8s.sidestream.tech